interoperability specification (ios) for ultra mobile ... · 17 2.2.2.1.1.2 session information...

COPYRIGHT © 2007, 3GPP2 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.

3GPP2 A.S0020-0 v1.0

Date: November 2007

Interoperability Specification (IOS) for Ultra Mobile 1

Broadband (UMB) Radio Access Network Interfaces 2

3

4

3GPP2 A.S0020-0 v1.0

i

Table of Contents 1

Foreword.................................................................................................................................................... xiv 2

1 Introduction...................................................................................................................................1-1 3

1.1 Overview.......................................................................................................................................1-1 4

1.1.1 Purpose..........................................................................................................................................1-1 5

1.1.2 Scope.............................................................................................................................................1-1 6

1.1.3 Document Convention ..................................................................................................................1-1 7

1.2 References.....................................................................................................................................1-1 8

1.2.1 Normative References...................................................................................................................1-1 9

1.2.2 Informative References.................................................................................................................1-2 10

1.3 Terminology..................................................................................................................................1-3 11

1.3.1 Acronyms......................................................................................................................................1-3 12

1.3.2 UMB Definitions ..........................................................................................................................1-4 13

1.3.3 UMB Notations.............................................................................................................................1-5 14

1.3.3.1 Tunneling of Reverse-link Route Protocol Packet ....................................................1-5 15

1.3.3.2 Tunneling of Forward-link Route Protocol Packet ...................................................1-6 16

1.4 UMB IOS Architecture Reference Model ....................................................................................1-7 17

1.4.1 Network Element Functional Descriptions ...................................................................................1-8 18

1.4.1.1 Access Gateway ........................................................................................................1-8 19

1.4.1.2 Evolved Base Station.................................................................................................1-8 20

1.4.1.3 Session Reference Network Controller .....................................................................1-9 21

1.4.2 Reference Point Descriptions........................................................................................................1-9 22

1.4.3 Protocol Interface Descriptions.....................................................................................................1-9 23

1.5 Message Body, Coding, Ordering, and Interpretation of IEs......................................................1-10 24

1.6 Forward Compatibility Guidelines .............................................................................................1-10 25

1.7 Message Processing Guidelines ..................................................................................................1-11 26

1.8 Message Definition Guidelines...................................................................................................1-12 27

1.9 UMB IOS Assumptions ..............................................................................................................1-12 28

1.9.1 Connectivity Assumptions among Network Elements ...............................................................1-12 29

1.9.2 PMIP Bearer Tunnel Management Guidelines ...........................................................................1-13 30

1.9.3 UMB Mobility Concepts.............................................................................................................1-13 31

1.9.4 UMB Security Key Concepts......................................................................................................1-14 32

1.10 UMB Feature Descriptions .........................................................................................................1-16 33

1.10.1 Explicitly Supported Features.....................................................................................................1-16 34

1.10.1.1 AT Originates a UMB Session................................................................................1-16 35

1.10.1.2 Route Set Add and Remove ....................................................................................1-16 36

1.10.1.3 Session Negotiation.................................................................................................1-16 37

3GPP2 A.S0020-0 v1.0

ii

1.10.1.4 UMB Data Delivery (both AT Terminated and AT Originated).............................1-16 1

1.10.1.5 Forward and Reverse Link Serving eBS (FLSE/RLSE) Switch .............................1-16 2

1.10.1.6 Data Attachment Point (DAP) Handoff ..................................................................1-16 3

1.10.1.7 Idle and Active Session Reference Transfer ...........................................................1-16 4

1.10.1.8 Idle State Mobility and Paging................................................................................1-16 5

1.10.1.9 Packet Data Session Release ...................................................................................1-16 6

1.10.1.10 UMB Session Release .............................................................................................1-16 7

1.10.1.11 AT and Network Initiated Neighbor Discovery ......................................................1-16 8

2 UMB IOS Interfaces .....................................................................................................................2-1 9

2.1 Transport Network IP Quality of Service (QoS) Framework for GRE Tunnels...........................2-1 10

2.2 IAS (Inter-ANRI Signaling) Interface ..........................................................................................2-1 11

2.2.1 IAS Interface Network/Transport Protocol Specification.............................................................2-1 12

2.2.2 IAS Interface Message Procedures ...............................................................................................2-2 13

2.2.2.1 IAS-Session Information Request .............................................................................2-3 14

2.2.2.1.1 Successful Operation.................................................................................................2-3 15

2.2.2.1.1.1 Session Information Retrieval triggered by RouteOpenRequest...............................2-3 16

2.2.2.1.1.2 Session Information Retrieval triggered by Session Updated ...................................2-4 17

2.2.2.1.1.3 Session Information Retrieval Triggered by UMB Session Release Procedure 18

Initiated by SRNC .....................................................................................................2-4 19

2.2.2.1.2 Failure Operation.......................................................................................................2-4 20

2.2.2.2 IAS-Session Information Response...........................................................................2-4 21


2.2.2.2.1.1 Session Retrieval as a result of RouteOpenRequest..................................................2-4 23

2.2.2.2.1.2 Session Retrieval as a result of Session Update ........................................................2-5 24


2.2.2.3 IAS-Session Information Update Request.................................................................2-7 26



2.2.2.4 IAS-Session Information Update Response ..............................................................2-7 29



2.2.2.5 IAS-SRNC Transfer Request ....................................................................................2-9 32



2.2.2.6 IAS-SRNC Transfer Response..................................................................................2-9 35

2.2.2.6.1 Successful Operation...............................................................................................2-10 36

2.2.2.6.1.1 SRNC Transfer to ANRI in the current Route Set ..................................................2-10 37

3GPP2 A.S0020-0 v1.0

iii

2.2.2.6.1.2 SRNC Transfer to outside the current Route Set.....................................................2-11 1

2.2.2.6.2 Failure Operation.....................................................................................................2-12 2

2.2.2.7 IAS-Session Release ...............................................................................................2-13 3


2.2.2.7.1.1 Session Release for AT in Connected State ............................................................2-13 5

2.2.2.7.1.2 Session Release for AT in Idle State .......................................................................2-13 6


2.2.2.8 IAS-Session Release Ack........................................................................................2-14 8



2.2.2.9 IAS-UATI Update ...................................................................................................2-14 11


2.2.2.9.1.1 UATI Change Operation .........................................................................................2-14 13

2.2.2.9.1.2 Route Set Add Operation ........................................................................................2-15 14


2.2.2.10 IAS-UATI Update Ack ...........................................................................................2-15 16



2.2.2.11 IAS-Paging Request ................................................................................................2-16 19



2.2.2.12 IAS-Paging Request Ack.........................................................................................2-16 22



2.2.2.13 IAS-Page .................................................................................................................2-17 25



2.2.2.14 IAS-Page Ack..........................................................................................................2-18 28



2.2.2.15 IAS-Neighbor Discovery Request...........................................................................2-19 31



2.2.2.16 IAS-Neighbor Discovery Report.............................................................................2-19 34



2.2.2.17 IAS-Neighbor Discovery Report Ack .....................................................................2-20 37

3GPP2 A.S0020-0 v1.0

iv



2.2.2.18 IAS-Reject ...............................................................................................................2-20 3



2.2.3 IAS Interface Protocol Procedures..............................................................................................2-20 6

2.2.3.1 Procedure for Maintaining the Access Counter.......................................................2-20 7

2.2.3.2 Procedure for Including Derived MSK Parameter SSIR in the Session State 8

Information Record IE.............................................................................................2-21 9

2.2.3.3 Procedure for Determining whether the Derived MSK is Valid .............................2-21 10

2.2.3.4 Procedure for Maintaining the Route Counter ........................................................2-22 11

2.2.3.5 Procedure for Maintaining the Session Signature ...................................................2-22 12

2.2.3.6 Exclusive Control of Session State Information Record.........................................2-23 13

2.2.3.6.1 Unlock State ............................................................................................................2-23 14

2.2.3.6.2 Lock State................................................................................................................2-23 15

2.3 IPT (IP Tunneling) Interface.......................................................................................................2-23 16

2.3.1 IPT Interface Network/Transport Protocol Specification ...........................................................2-24 17

2.3.2 IPT data L2TPv3 Headers...........................................................................................................2-24 18

2.3.3 IPT Interface Network/Transport Protocol Procedure ................................................................2-26 19

2.3.3.1 IPT Packet Tunneling Operations ...........................................................................2-26 20

2.3.3.1.1 GRE packet is Received from the AGW while the AT is active.............................2-26 21

2.3.3.1.2 Forward-link IPT Packet is Received while the AT is active..................................2-27 22

2.3.3.1.3 Forward-link Packet is Received either through GRE or IPT while 23

the AT is Idle...........................................................................................................2-27 24

2.3.3.1.4 Reverse-link IP Packet is Received.........................................................................2-27 25

2.3.3.1.5 Reverse-link IPT Packet is Received ......................................................................2-28 26

2.3.4 IPT Interface Protocol Procedure................................................................................................2-28 27

2.3.4.1 Procedure for Maintaining DAP Counter................................................................2-28 28

2.3.5 IPT Interface Message Procedures..............................................................................................2-29 29

2.3.5.1 IPT-Notification ......................................................................................................2-29 30


2.3.5.1.1.1 FLSE Switch Operation - Target FLSE Procedure .................................................2-29 32

2.3.5.1.1.2 FLSE Switch Operation - Source FLSE Procedure.................................................2-30 33

2.3.5.1.1.3 FLSE Switch Operation - DAP Procedure ..............................................................2-30 34

2.3.5.1.1.4 RLSE Switch Operation - Target RLSE Procedure ................................................2-30 35

2.3.5.1.1.5 RLSE Switch Operation - Source RLSE Procedure................................................2-31 36

2.3.5.1.1.6 DAP Switch Operation............................................................................................2-31 37

2.3.5.1.1.7 Connection Close Operation ...................................................................................2-31 38

3GPP2 A.S0020-0 v1.0

v

2.3.5.1.1.8 Connection Lost Operation .....................................................................................2-32 1

2.3.5.1.1.9 Route Set Add Operation ........................................................................................2-32 2

2.3.5.1.1.10 Route Set Remove Operation ..................................................................................2-33 3

2.3.5.1.1.11 Packet Data Session Release ...................................................................................2-33 4


2.3.5.2 IPT-Notification Ack...............................................................................................2-33 6






2.3.5.2.1.5 DAP Switch Operation - FLSE Procedure ..............................................................2-35 12

2.3.5.2.1.6 DAP Switch Operation - DAP Procedure ...............................................................2-35 13


2.3.5.3 IPT-Flush.................................................................................................................2-35 15







2.3.5.4 IPT-Reject ...............................................................................................................2-36 22



2.4 LLT (Link-Layer Tunneling) Interface.......................................................................................2-36 25

2.4.1 LLT Interface Network/Transport Protocol Specification..........................................................2-36 26

2.4.2 LLT Interface Network/Transport Protocol Procedure...............................................................2-39 27

2.4.2.1 LLT Packet Tunneling Operations ..........................................................................2-39 28

2.4.2.1.1 An ANRI Generates a Unicast Link-layer Packet ...................................................2-39 29

2.4.2.1.2 An ANRI Receives a Unicast Forward-link LLT Packet ........................................2-40 30

2.4.2.1.3 An ANRI Receives a Reverse-link LLT Packet......................................................2-40 31

2.4.2.1.4 An RLSE Receives a Tunneled Link-layer Packet Over the Air 32

for Another Route....................................................................................................2-41 33

2.4.2.1.5 An eBS Needs to Tunnel a Broadcast Message through Another eBS ...................2-42 34

2.5 PMIP (Proxy Mobile IP) Interface..............................................................................................2-42 35

2.5.1 PMIP Signaling Interface............................................................................................................2-43 36

2.5.1.1 PMIP Signaling Interface Network/Transport Protocol Specification ....................2-43 37

3GPP2 A.S0020-0 v1.0

vi

2.5.1.2 PMIP Tunnel Establishment....................................................................................2-43 1

2.5.1.2.1 Initial PMIP Tunnel Setup with the AGW ..............................................................2-44 2

2.5.1.2.1.1 Successful Operation...............................................................................................2-44 3

2.5.1.2.1.2 Failure Operation.....................................................................................................2-45 4

2.5.1.2.2 eBS Added to the Route Set ....................................................................................2-45 5



2.5.1.2.3 eBS Becomes the DAP............................................................................................2-46 8

2.5.1.3 PMIP Signaling-Only Binding ................................................................................2-47 9

2.5.1.3.1 PMIP Signaling-Only Binding Establishment Procedures......................................2-47 10

2.5.1.3.2 PMIP Signaling-Only Binding Configuration.........................................................2-47 11

2.5.1.3.3 AGW Sends Data Notification to SRNC or eBS.....................................................2-47 12



2.5.1.4 PMIP Registration Refresh......................................................................................2-47 15

2.5.1.4.1 PMIP Registration Refresh Procedures ...................................................................2-47 16



2.5.1.5 PMIP Binding Release ............................................................................................2-48 19

2.5.1.5.1 eBS or SRNC-Initiated PMIP Tunnel Release Procedures .....................................2-48 20



2.5.1.5.2 AGW-Initiated PMIP Tunnel Release Procedures ..................................................2-49 23



2.5.1.6 Procedure for PMIP Registration Request Message Fields.....................................2-49 26

2.5.2 PMIP Bearer Interface ................................................................................................................2-52 27

2.5.2.1 PMIP Bearer Interface Procedure............................................................................2-54 28

2.6 AAA (Authentication, Authorization and Accounting) Interface...............................................2-54 29

2.6.1 Accounting Requirements...........................................................................................................2-54 30

2.6.2 Accounting Report Procedure.....................................................................................................2-55 31

2.6.2.1 Successful Operation...............................................................................................2-55 32

2.6.2.2 Failure Operation.....................................................................................................2-55 33

3 UMB IOS Call Flows....................................................................................................................3-1 34

3.1 AT-Initiated Origination and Call Re-activation ..........................................................................3-1 35

3.1.1 AT Originates UMB Session ........................................................................................................3-1 36

3.1.2 AT Registration in Idle State ........................................................................................................3-5 37

3GPP2 A.S0020-0 v1.0

vii

3.1.3 AT Initiated Call Re-activation from Idle State............................................................................3-5 1

3.2 UMB Session Release and Packet Data Session Release .............................................................3-6 2

3.2.1 UMB Session Release for an Active AT - Initiated by the AT or SRNC.....................................3-6 3

3.2.2 UMB Session Release for an Idle AT - Initiated by the SRNC ....................................................3-8 4

3.2.2.1 SRNC Initiated UMB Session Release for an Idle AT (Case 1: DAP eBS) .............3-9 5

3.2.2.2 SRNC Initiated UMB Session Release for an Idle AT (Case 2: DAP SRNC)........3-10 6

3.2.3 AGW Initiated Packet Data Session Release for an Active AT..................................................3-11 7

3.2.4 AGW Initiated Packet Data Session Release for an Active AT that is no Longer Authorized...3-14 8

3.2.5 AGW Initiated Packet Data Session Release for an Idle AT (Case 1: DAP eBS)......................3-17 9

3.2.6 AGW Initiated Packet Data Session Release for an Idle AT (Case 2: DAP SRNC) ..................3-20 10

3.3 Route Set Management ...............................................................................................................3-23 11

3.3.1 UMB Route Set Management Overview ....................................................................................3-23 12

3.3.2 Route Set Add.............................................................................................................................3-23 13

3.3.3 Route Set Remove.......................................................................................................................3-25 14

3.3.4 Route Set Remove with Multiple Tunnels..................................................................................3-26 15

3.4 UMB Session Negotiation ..........................................................................................................3-27 16

3.4.1 UMB Session Negotiation Overview..........................................................................................3-27 17

3.4.2 UMB Session Negotiation ..........................................................................................................3-27 18

3.5 Serving eBS Switch ....................................................................................................................3-28 19

3.5.1 FLSE Switch ...............................................................................................................................3-28 20

3.5.2 FLSE Switch - Error Recovery ...................................................................................................3-30 21

3.5.3 FLSE Switch - Error Recovery from False Handoff Detection ..................................................3-32 22

3.5.4 RLSE Switch...............................................................................................................................3-34 23

3.6 DAP Handoff ..............................................................................................................................3-36 24

3.6.1 Intra-AGW DAP Handoff without Multiple Tunnels .................................................................3-36 25

3.6.2 Intra-AGW DAP Handoff with Multiple Tunnels ......................................................................3-38 26

3.6.3 Intra-AGW DAP Handoff - Recovery from Invalid Timestamp ................................................3-39 27

3.6.4 Intra-AGW DAP Handoff before IPT-Notification Message is Received at the Target DAP....3-41 28

3.6.5 Inter-AGW DAP Handoff...........................................................................................................3-43 29

3.7 Session Reference Transfer.........................................................................................................3-46 30

3.7.1 Session Reference Transfer during Idle Mobility Events ...........................................................3-46 31

3.7.1.1 AT Registers at eBS not Supported by Source SRNC - Session Anchor 32

ANRI Moves to Target SRNC ................................................................................3-46 33

3.7.1.2 AT Registers at eBS not Supported by Source SRNC - Session Moves 34

to Local eBS ............................................................................................................3-49 35

3.7.1.3 Session Reference Transfer during Idle Mobility Events with 36

SRNC-PMIP Binding Update .................................................................................3-51 37

3.7.1.4 Inter-AGW AT Idle Handoff...................................................................................3-53 38

3GPP2 A.S0020-0 v1.0

viii

3.7.2 Session Reference Transfer during Active Service Events.........................................................3-56 1

3.7.2.1 Session Reference Transfer during Active Services ...............................................3-57 2

3.7.2.2 Session Reference Transfer - Route Set Add during SRNC Transfer .....................3-58 3

3.7.2.3 Session Reference Transfer - Session Negotiation during SRNC Transfer ............3-59 4

3.7.2.4 Session Reference Transfer - Connection Lost before UATIAssignment 5

is Received ..............................................................................................................3-61 6

3.7.2.5 Session Reference Transfer - Connection Lost before UATIComplete 7

is Received ..............................................................................................................3-63 8

3.7.2.6 Session Reference Transfer - Route Add after UATI Assignment 9

during SRNC Transfer.............................................................................................3-65 10

3.8 Idle State Mobility and Paging ...................................................................................................3-67 11

3.8.1 AT Initiated Graceful Connection Close ....................................................................................3-67 12

3.8.2 AN Initiated Graceful Connection Close - PMIP Signaling-Only Binding to SRNC ................3-68 13

3.8.3 Non-Graceful Connection Close.................................................................................................3-71 14

3.8.4 PMIP Binding Between SRNC and AGW in Idle State .............................................................3-73 15

3.8.5 DAP Requests AGW to Buffer Data in Idle State ......................................................................3-74 16

3.8.6 Idle AT Registration - Successful Scenario ................................................................................3-74 17

3.8.7 Paging with Data or Data Notification to eBS - Successful Scenario.........................................3-75 18

3.8.8 Paging - Successful Scenario with Local Fanout........................................................................3-77 19

3.8.9 Paging with Data Notification to the SRNC - Successful Scenario............................................3-79 20

3.9 Miscellaneous UMB Call Flows.................................................................................................3-81 21

3.9.1 Neighbor Discovery ....................................................................................................................3-81 22

3.9.1.1 Neighbor Discovery - AT (Pilot Report) Initiated ..................................................3-81 23

3.9.1.2 Neighbor Discovery - eBS Initiated ........................................................................3-82 24

4 Messages, IEs and Timer Definitions ...........................................................................................4-1 25

4.1 Message Definitions......................................................................................................................4-1 26

4.1.1 IAS Message Definitions ..............................................................................................................4-1 27

4.1.1.1 IAS-Session Information Request .............................................................................4-1 28

4.1.1.2 IAS-Session Information Response...........................................................................4-1 29

4.1.1.3 IAS-Session Information Update Request.................................................................4-2 30

4.1.1.4 IAS-Session Information Update Response ..............................................................4-3 31

4.1.1.5 IAS-SRNC Transfer Request ....................................................................................4-3 32

4.1.1.6 IAS-SRNC Transfer Response..................................................................................4-4 33

4.1.1.7 IAS-Session Release .................................................................................................4-4 34

4.1.1.8 IAS-Session Release Ack..........................................................................................4-5 35

4.1.1.9 IAS-UATI Update .....................................................................................................4-5 36

4.1.1.10 IAS-UATI Update Ack .............................................................................................4-6 37

4.1.1.11 IAS-Paging Request ..................................................................................................4-6 38

3GPP2 A.S0020-0 v1.0

ix

4.1.1.12 IAS-Paging Request Ack...........................................................................................4-7 1

4.1.1.13 IAS-Page ...................................................................................................................4-7 2

4.1.1.14 IAS-Page Ack............................................................................................................4-8 3

4.1.1.15 IAS-Neighbor Discovery Request.............................................................................4-8 4

4.1.1.16 IAS-Neighbor Discovery Report...............................................................................4-8 5

4.1.1.17 IAS-Neighbor Discovery Report Ack .......................................................................4-9 6

4.1.1.18 IAS-Reject .................................................................................................................4-9 7

4.1.2 IPT Message Definitions.............................................................................................................4-10 8

4.1.2.1 IPT-Notification ......................................................................................................4-10 9

4.1.2.2 IPT-Notification Ack...............................................................................................4-10 10

4.1.2.3 IPT-Reject ...............................................................................................................4-11 11

4.1.2.4 IPT-Flush.................................................................................................................4-11 12

4.1.3 PMIP Message Definitions .........................................................................................................4-12 13

4.1.4 AAA Message Definitions..........................................................................................................4-12 14

4.2 IE Definitions..............................................................................................................................4-12 15

4.2.1 IAS IE Definitions ......................................................................................................................4-12 16

4.2.1.1 IAS IE Identifiers ....................................................................................................4-12 17

4.2.1.2 Cross Reference of IEs with Messages ...................................................................4-13 18

4.2.1.3 IAS Message Type ..................................................................................................4-16 19

4.2.1.4 AT Identity ..............................................................................................................4-17 20

4.2.1.5 Network Identity (Endpoint ID) ..............................................................................4-18 21

4.2.1.6 RouteOpenRequest..................................................................................................4-19 22

4.2.1.7 Session Signature ....................................................................................................4-20 23

4.2.1.8 Cause .......................................................................................................................4-20 24

4.2.1.9 PMIP Root Key .......................................................................................................4-21 25

4.2.1.10 Neighbor Connection Information ..........................................................................4-22 26

4.2.1.11 New UATI 128........................................................................................................4-23 27

4.2.1.12 SRNC Record..........................................................................................................4-23 28

4.2.1.13 Paging Control Record ............................................................................................4-25 29

4.2.1.14 Neighbor Discovery Record....................................................................................4-25 30

4.2.1.15 Sector Parameters ....................................................................................................4-27 31

4.2.1.16 Session Request Record ..........................................................................................4-27 32

4.2.1.17 Page Attempt Timer ................................................................................................4-28 33

4.2.1.18 IAS DAP Record .....................................................................................................4-28 34

4.2.1.19 Session State Information Record ...........................................................................4-32 35

4.2.1.20 Network Session Record .........................................................................................4-32 36

4.2.1.21 IAS Reject Record...................................................................................................4-33 37

3GPP2 A.S0020-0 v1.0

x

4.2.1.22 AIS Paging Information Record..............................................................................4-34 1

4.2.2 IPT IE Definitions.......................................................................................................................4-34 2

4.2.2.1 IPT IE Identifiers.....................................................................................................4-34 3

4.2.2.2 Cross Reference of IEs with Messages ...................................................................4-35 4

4.2.2.3 IPT Message Type...................................................................................................4-36 5

4.2.2.4 AT Identity ..............................................................................................................4-36 6

4.2.2.5 Network Identity (Endpoint ID) ..............................................................................4-38 7

4.2.2.6 Notification Record .................................................................................................4-39 8

4.2.2.7 IPT-DAP Record .....................................................................................................4-40 9

4.2.2.8 LinkID .....................................................................................................................4-41 10

4.2.2.9 Access Counter........................................................................................................4-42 11

4.2.2.10 Cause .......................................................................................................................4-42 12

4.2.2.11 Notification Correlation ID .....................................................................................4-43 13

4.2.2.12 Flush Information ....................................................................................................4-43 14

4.2.2.13 Message Timestamp................................................................................................4-44 15

4.2.2.14 IPT Reject Record ...................................................................................................4-44 16

4.3 Timer Definitions........................................................................................................................4-45 17

4.3.1 Timer Descriptions......................................................................................................................4-45 18

4.3.1.1 Timer Tacct-aaa.......................................................................................................4-45 19

4.3.1.2 Timer Tndrpt-ias .....................................................................................................4-46 20

4.3.1.3 Timer Tndrptack-ias ................................................................................................4-46 21

4.3.1.4 Timer Tpgack-ias ....................................................................................................4-46 22

4.3.1.5 Timer Tpgreq-ias.....................................................................................................4-46 23

4.3.1.6 Timer Tsir-ias ..........................................................................................................4-46 24

4.3.1.7 Timer Tsr-ias ...........................................................................................................4-46 25

4.3.1.8 Timer Tstr-ias ..........................................................................................................4-46 26

4.3.1.9 Timer Tsur-ias .........................................................................................................4-46 27

4.3.1.10 Timer Tuupd-ias ......................................................................................................4-46 28

4.3.1.11 Timer Tflflush-ipt....................................................................................................4-46 29

4.3.1.12 Timer Tnot-ipt .........................................................................................................4-46 30

4.3.1.13 Timer Trlflush-ipt....................................................................................................4-47 31

4.3.1.14 Timer Twaitdap-ipt .................................................................................................4-47 32

4.3.1.15 Timer Trrq-pmip .....................................................................................................4-47 33

Annex A Format of the AIS Paging Information Blob............................................................A-1 34

35

3GPP2 A.S0020-0 v1.0

xi

Table of Figures 1

2

Figure 1.3.3.1-1 RL Route Protocol Packet - Receiving eBS is RLSE...................................................1-5 3

Figure 1.3.3.1-2 Tunneled RL Route Protocol Packet - Receiving eBS is not RLSE.............................1-6 4

Figure 1.3.3.1-3 Logical Representation of AT Sending a Tunneled Route Protocol Packet to an eBS 1-6 5

Figure 1.3.3.2-1 FL Route Protocol Packet - Originating eBS is FLSE..................................................1-6 6

Figure 1.3.3.2-2 FL Tunneled Route Protocol Packet - Originating eBS is not FLSE 7

But Knows the Identity of the FLSE ............................................................................1-7 8

Figure 1.3.3.2-3 FL Tunneled Route Protocol Packet - Originating eBS is not FLSE and 9

Does not Know the Identity of the latest FLSE............................................................1-7 10

Figure 1.3.3.2-4 Logical Representation of an eBS Sending a Tunneled Route Protocol 11

Packet to the AT ...........................................................................................................1-7 12

Figure 1.4-1 UMB IOS Architecture Reference Model ....................................................................1-8 13

Figure 1.9.3-1 UMB Mobility Concepts ...........................................................................................1-14 14

Figure 1.9.4-2 UMB Security Key Concepts .....................................................................................1-15 15

Figure 2.5.2-1 GRE Encapsulated User Traffic .................................................................................2-52 16

Figure 2.5.2-2 3GPP2 GRE Header ...................................................................................................2-53 17

Figure 3.1.1-1 AT Originates UMB .....................................................................................................3-2 18

Figure 3.1.3-1 AT Initiated Call Re-activation from Idle State ...........................................................3-5 19

Figure 3.2.1-1 AT or SRNC Initiated UMB Session Release for an Active AT..................................3-7 20

Figure 3.2.2.1-1 SRNC Initiated UMB Session Release for an Idle AT (Case 1: DAP eBS).................3-9 21

Figure 3.2.2.2-1 SRNC Initiated UMB Session Release for an Idle AT (Case 2: DAP SRNC) ...........3-10 22

Figure 3.2.3-1 AGW Initiated Packet Data Session Release for an Active AT .................................3-12 23

Figure 3.2.4-1 AGW Initiated Packet Data Session Release for an Active AT that 24

is no Longer Authorized .............................................................................................3-15 25

Figure 3.2.5-1 AGW Initiated Packet Data Session Release for an Idle AT (Case 1: DAP eBS)......3-18 26

Figure 3.2.6-1 AGW Initiated Packet Data Session Release for an idle AT (Case 2: DAP SRNC) ..3-21 27

Figure 3.3.2-1 Route Set Add.............................................................................................................3-24 28

Figure 3.3.3-1 Route Set Remove ......................................................................................................3-25 29

Figure 3.3.4-1 Route Set Remove with Multiple Tunnels..................................................................3-26 30

Figure 3.4.2-1 Session Negotiation ....................................................................................................3-27 31

Figure 3.5.1-1 FLSE Switch...............................................................................................................3-29 32

Figure 3.5.2-1 FLSE Switch - Error Recovery...................................................................................3-31 33

Figure 3.5.3-1 FLSE Switch - Error Recovery...................................................................................3-33 34

Figure 3.5.4-1 RLSE Switch ..............................................................................................................3-35 35

Figure 3.6.1-1 Intra-AGW DAP Handoff without Multiple Tunnels.................................................3-37 36

Figure 3.6.2-1 Intra-AGW DAP Handoff with Multiple Tunnels......................................................3-38 37

Figure 3.6.3-1 Intra-AGW DAP Handoff - Recovery from Invalid Timestamp................................3-40 38

3GPP2 A.S0020-0 v1.0

xii

Figure 3.6.4-1 Intra-AGW DAP Handoff before IPT-Notification Message is 1

Received at the Target DAP .......................................................................................3-42 2

Figure 3.6.5-1 Inter-AGW DAP Handoff ..........................................................................................3-44 3

Figure 3.7.1.1-1 AT Registers at eBS not Supported by Source SRNC - Session Moves 4

to Target SRNC ..........................................................................................................3-47 5

Figure 3.7.1.2-1 AT Registers at eBS not Supported by Source SRNC - Session Moves 6

to Local eBS ...............................................................................................................3-50 7

Figure 3.7.1.3-1 Intra-AGW Session Reference Transfer during Idle Mobility Events 8

with SRNC-PMIP Binding Update.............................................................................3-52 9

Figure 3.7.1.4-1 Inter-AGW Handoff in Idle State ...............................................................................3-54 10

Figure 3.7.2.1-1 Session Reference Transfer during Active Services...................................................3-57 11

Figure 3.7.2.2-1 Session Reference Transfer - Route Set Add during SRNC Transfer ........................3-58 12

Figure 3.7.2.3-1 Session Reference Transfer - Session Negotiation during SRNC Transfer................3-60 13

Figure 3.7.2.4-1 Session Reference Transfer - UATIAssignment Lost ................................................3-62 14

Figure 3.7.2.5-1 Session Reference Transfer - UATIComplete Lost....................................................3-63 15

Figure 3.7.2.6-1 Session Reference Transfer - Route Set Add after UATI Assignment 16

during SRNC Transfer................................................................................................3-65 17

Figure 3.8.1-1 AT Initiated Graceful Connection Close ....................................................................3-67 18

Figure 3.8.2-1 AN Initiated Graceful Connection Close - PMIP Signaling-Only 19

Binding to SRNC........................................................................................................3-69 20

Figure 3.8.3-1 Non-Graceful Connection Close ................................................................................3-71 21

Figure 3.8.4-1 PMIP Binding Between SRNC and AGW in Idle State .............................................3-73 22

Figure 3.8.5-1 DAP Requests AGW to Buffer Data in Idle State ......................................................3-74 23

Figure 3.8.6-1 Idle AT Registration - Successful Scenario................................................................3-74 24

Figure 3.8.7-1 Paging - Successful Scenario......................................................................................3-75 25

Figure 3.8.8-1 Paging - Successful Scenario with Local Fanout........................................................3-77 26

Figure 3.8.9-1 Paging with Data Notification to the SRNC - Successful Scenario ...........................3-79 27

Figure 3.9.1.1-1 Neighbor Discovery - AT (Pilot Report) Initiated......................................................3-81 28

Figure 3.9.1.2-1 Neighbor Discovery - eBS Initiated ...........................................................................3-82 29

30

31

3GPP2 A.S0020-0 v1.0

xiii

Table of Tables 1

2

Table 2.2.2-1 IAS Message Section and Port Reference ....................................................................2-2 3

Table 2.3.5-1 IPT Message Section and Port Reference...................................................................2-29 4

Table 2.5.2-1 Data Protocol Stack ....................................................................................................2-52 5

Table 2.6-1 AAA Protocol Stack ...................................................................................................2-54 6

Table 4.2.1.2-1 Cross Reference of IEs with Messages.......................................................................4-13 7

Table 4.2.1.3-1 Message Type .............................................................................................................4-16 8

Table 4.2.1.4-1 AT Identity - Type of Identity Coding .......................................................................4-17 9

Table 4.2.1.5-1 Network Identity Type - Type of Identity Coding......................................................4-19 10

Table 4.2.1.8-1 Cause Value - Type of Identity Coding......................................................................4-21 11

Table 4.2.1.8-2 Allowable Cause Values by Message.........................................................................4-21 12

Table 4.2.1.10-1 SRNC Address - Type of Identity Coding..................................................................4-22 13

Table 4.2.1.12-1 SRNC Record - Type of Identity Coding ...................................................................4-24 14

Table 4.2.1.14-1 IOS Interface Identity - Type of Identity Coding .......................................................4-26 15

Table 4.2.1.14-2 Network Identity - Type of Identity Coding...............................................................4-27 16

Table 4.2.1.18-1 IAS AGW Record - Type of Identity Coding.............................................................4-29 17

Table 4.2.1.18-2 IAS AGW Address - Type of Identity Coding ...........................................................4-30 18

Table 4.2.1.18-3 DAP Information - Type of Identity Coding ..............................................................4-31 19

Table 4.2.1.20-1 Network Session Info - Type of Identity Coding .......................................................4-33 20

Table 4.2.2.2-1 Cross Reference of IEs with Messages.......................................................................4-35 21

Table 4.2.2.3-1 Message Type .............................................................................................................4-36 22

Table 4.2.2.4-1 AT Identity - Type of Identity Coding .......................................................................4-37 23

Table 4.2.2.5-1 Network Identity - Type of Identity Coding...............................................................4-38 24

Table 4.2.2.6-1 Notification Info .........................................................................................................4-39 25

Table 4.2.2.6-2 Notification Info .........................................................................................................4-39 26

Table 4.2.2.7-1 IPT AGW Record - Type of Identity Coding .............................................................4-40 27

Table 4.2.2.7-2 AGW Address Type - Type of Identity Coding .........................................................4-41 28

Table 4.2.2.10-1 Cause Value - Type of Identity Coding......................................................................4-42 29

Table 4.2.2.10-2 Allowable Cause Values by Message.........................................................................4-43 30

31

3GPP2 A.S0020-0 v1.0

xiv

Foreword 1

This document describes the interface protocols and procedures to support the Ultra Mobile Broadband™ 2

(UMB™)1 Interoperability Specification (IOS) features listed in section 1.1. 3

4

Revision History

November 2007 Version 1.0 (Initial publication)

5

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

3GPP2 A.S0020-0 v1.0

xv

1

(This page intentionally left blank) 2

3

4

5

3GPP2 A.S0020-0 v1.0

1-1

1 Introduction 1

2

1.1 Overview 3

This document includes a description of the interface protocols and procedures to support the following 4

features and functions. 5

• AT (Access Terminal) originates a UMB session. 6

• Data delivery (both AT terminated and AT originated). 7

• UMB session release. 8

• Packet data session release. 9

• Route set add and remove. 10

• UMB session negotiation. 11

• Forward and Reverse Link Serving eBS (FLSE/RLSE) switch. 12

• Intra- and Inter-AGW Data Attachment Point (DAP) handoff. 13

• Idle and active session reference transfer. 14

• Idle state mobility and paging. 15

• AT and network initiated neighbor discovery. 16

17

1.1.1 Purpose 18

The purpose of this document is to provide a standard and call flows for the UMB IOS interfaces within 19

the Radio Access Network (RAN). 20

1.1.2 Scope 21

This document provides an interoperability specification for a RAN that supports UMB. This document 22

contains message procedures and formats necessary to obtain this interoperability. 23

1.1.3 Document Convention 24

“Shall” and “shall not” identify requirements to be followed strictly to conform to the standard and from 25

which no deviation is permitted. “Should” and “should not” indicate that one of several possibilities is 26

recommended as particularly suitable, without mentioning or excluding others; that a certain course of 27

action is preferred but not necessarily required; or (in the negative form) that a certain possibility or 28

course of action is discouraged but not prohibited. “May” and “need not” indicate a course of action 29

permissible within the limits of the standard. “Can” and “cannot” are used for statements of possibility 30

and capability, whether material, physical, or causal. 31

1.2 References 32

References are either normative or informative. A normative reference is used to include another doc-33

ument as a mandatory part of a 3GPP2 specification. Documents that provide additional non-essential in-34

formation are included in the informative references section. 35

1.2.1 Normative References 36

[1] 3GPP2 C.S0084-000-0 v2.0, Overview for Ultra Mobile Broadband (UMB) Air Interface 37

Specification, August 2007. 38

3GPP2 A.S0020-0 v1.0

1-2

3GPP2 C.S0084-001-0 v2.0, Physical Layer for Ultra Mobile Broadband (UMB) Air Interface 1

Specification, August 2007. 2

3GPP2 C.S0084-002-0 v2.0, Medium Access Control Layer for Ultra Mobile Broadband 3

(UMB) Air Interface Specification, August 2007. 4

3GPP2 C.S0084-003-0 v2.0, Radio Link Layer for Ultra Mobile Broadband (UMB) Air 5

Interface Specification, August 2007. 6

3GPP2 C.S0084-004-0 v2.0, Application Layer for Ultra Mobile Broadband (UMB) Air 7


3GPP2 C.S0084-005-0 v2.0, Security Functions for Ultra Mobile Broadband (UMB) Air 9


3GPP2 C.S0084-006-0 v2.0, Connection Control Plane for Ultra Mobile Broadband (UMB) 11

Air Interface Specification, August 2007. 12

3GPP2 C.S0084-007-0 v2.0, Session Control Plane for Ultra Mobile Broadband (UMB) Air 13


3GPP2 C.S0084-008-0 v2.0, Route Control Plane for Ultra Mobile Broadband (UMB) Air 15


3GPP2 C.S0084-009-0 v2.0, Broadcast-Multicast Upper Layer for Ultra Mobile Broadband 17

(UMB) Air Interface Specification, August 2007. 18

[2] 3GPP2 X.S0054-0 v1.0, CAN Wireless IP Network Specification. 19

Editor's Note: The above document is a work in progress and should not be referenced unless 20

and until it is approved and published. Until such time as this Editor’s Note is removed, the 21

inclusion of the above document is for informational purposes only. 22

[3] IETF RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and 23

Analysis, March 1992. 24

[4] IETF RFC 1662, PPP in HDLC-like Framing, July 1994. 25

[5] IETF RFC 2475, An Architecture for Differentiated Services, December 1998. 26

[6] IETF RFC 2784, Generic Routing Encapsulation (GRE), March 2000. 27

[7] IETF RFC 2794, Mobile IP Network Access Identifier Extension for IPv4, March 2000. 28

[8] IETF RFC 2865, Remote Authentication Dial In User Service (RADIUS), June 2000. 29

[9] IETF RFC 2866, RADIUS Accounting, June 2000. 30

[10] IETF RFC 2890, Key and Sequence Number Extensions to GRE, September 2000. 31

[11] IETF RFC 3344, IP Mobility Support for IPv4, August 2002. 32

[12] IETF RFC 3543, Registration Revocation in Mobile IPv4, August 2003. 33

[13] draft-yegani-gre-key-extension-03, GRE Key Extension for Mobile IPv4, June 2007. 34

Editor's Note: The above document is a work in progress and should not be referenced unless 35

and until it is approved and published. Until such time as this Editor’s Note is removed, the 36

inclusion of the above document is for informational purposes only. 37

38

1.2.2 Informative References 39

[I-1] IETF RFC 3931, Layer Two Tunneling Protocol - Version 3 (L2TPv3), March 2005. 40

41

3GPP2 A.S0020-0 v1.0

1-3

1.3 Terminology 1

2

1.3.1 Acronyms 3

3GPP2 3rd Generation Partnership Project 2 AAA Authentication, Authorization and Accounting ADR Airlink Data Record AGW Access Gateway AIS Air Interface Signaling AN Access Network ANID Access Network IDentifier ANRI Access Network Route Instance AT Access Terminal ATI Access Terminal Identifier CAN Converged Access Network CRC Cyclic Redundancy Check CRIT CAN-RAN IP Tunneling DAP Data Attachment Point EAP Extensible Authentication Protocol eBS Evolved Base Station ERP EAP Reauthentication Protocol FL Forward Link FLSE Forward Link Serving eBS GRE Generic Routing Encapsulation HA Home Agent IE Information Element IEI Information Element Identifier IAS Inter-ANRI Signaling IOS Inter-Operability Specification IP Internet Protocol IPT Internet Protocol Tunneling L2TPv3 Layer 2 Tunneling Protocol Version 3 LLT Link Layer Tunneling LMA Local Mobility Anchor LSB Least Significant Bit MAG Mobility Access Gateway MSB Most Significant Bit MSK Master Session Key NAI Network Access Identifier ND Neighbor Discovery NTP Network Time Protocol PMIP Proxy Mobile Internet Protocol

3GPP2 A.S0020-0 v1.0

1-4

PMK Pair-wise Master Key PMN Proxy Mobile Node RAN Radio Access Network RL Reverse Link RLSE Reverse Link Serving eBS SID Session Identifier SRNC Session Reference Network Controller SSID Stable Session Identifier SSIR Session State Information Record TTL Time To Live UATI Unicast Access Terminal Identifier UDP User Datagram Protocol UDR Usage Data Record UMB Ultra Mobile Broadband

1

1.3.2 UMB Definitions 2

Access Procedure The access procedure is the over-the-air procedure that an idle 3

AT uses to establish an air link connection with an eBS. Refer to 4

[1]. 5

Access Terminal Identifier (ATI) The access terminal identifier for UMB is composed of a two-bit 6

ATI Type field and a 128-bit ATI field. Refer to [1] for 7

definition of these fields. 8

ANRI An Access Network Route Instance (ANRI) is a logical function 9

that has an open route with an AT. An eBS and an SRNC may 10

support an ANRI function. An ANRI is referred to as an Access 11

Network (AN) in [1]. For the definition of route, refer to [1]. 12

DAP eBS The Data Attachment Point (DAP) eBS is the eBS that receives 13

forward-link user traffic for the AT from the Access Gateway 14

(AGW). 15

DAP SRNC An SRNC function which terminates a Signaling-Only binding 16

type from the AGW. 17

FLSE The Forward-Link Serving eBS (FLSE) is the eBS that serves 18

forward-link user traffic to the AT over-the-air. The FLSE may 19

be different from the DAP eBS. 20

Link Layer Packet A Link layer packet is the Application Layer Protocol Data Unit 21

specified in [1]. 22

Packet Data Session The packet data session is the IP session negotiated between the 23

AT and the AGW. An AT has a packet data session with an 24

AGW if it has one of the following PMIP bindings - Primary, 25

RL+Primary or Signaling-Only - to that AGW. 26

Primary binding Primary binding refers to a PMIP binding that can support traffic 27

for both the forward link and the reverse link between a DAP 28

and an AGW. A PMIP binding without Binding Type Extension 29

is considered to be a Primary binding. 30

3GPP2 A.S0020-0 v1.0

1-5

RL-Only binding A reverse link only (RL-Only) binding refers to a PMIP binding 1

that can only support traffic for the reverse link between an eBS 2

and an AGW. If supported, any eBS in the Route Set may 3

establish an RL-Only binding with an AGW. An AGW that 4

supports simultaneous bindings may have one Primary binding 5

and zero or more RL-Only bindings at any point in time. 6

RL+Primary binding An RL+Primary binding is a PMIP binding that is used by the 7

eBS to create a Primary binding and additionally to indicate to 8

the AGW that the eBS is capable of supporting RL-Only PMIP 9

bindings. When the DAP moves to a different eBS, the Primary 10

binding is converted to an RL-Only binding. 11

RLSE The Reverse-Link Serving eBS (RLSE) is the eBS that receives 12

reverse-link user traffic from the AT over-the-air. The RLSE 13

may be different from the DAP eBS or the FLSE. 14

Route Set The set of all ANRIs that have a route with the AT. The Session 15

Anchor ANRI is in the SRNC and is always in the Route Set. 16

Signaling-Only binding A Signaling-Only binding refers to a PMIP binding that is used 17

to trigger the AGW to buffer forward link IP packets for the AT. 18

Signaling-Only binding is mutually exclusive with Primary 19

binding. When a Signaling-Only binding is established, the 20

existing Primary binding is removed and RL-Only binding 21

remains, if it already exists. 22

Stable Session Identifier (SSID) The SSID is a 160-bit AT identifier that is globally unique 23

throughout the lifetime of the session. Its 128 MSBs are identical 24

to the first UATI assigned to the AT when the session is created. 25

Its 32 LSBs are the 32 MSBs of the NTP timestamp format. 26

Refer to [3]. 27

UMB Session The UMB session is the session negotiated between the RAN 28

and the AT. While the UMB session exists, the SRNC maintains 29

the reference copy of the AT’s UMB session. UMB session 30

release triggers packet data session release. The word “session” 31

in this document refers to UMB session unless otherwise 32

specified. 33

34

1.3.3 UMB Notations 35

This section identifies call flow notations used in the UMB IOS document. 36

1.3.3.1 Tunneling of Reverse-link Route Protocol Packet 37

There are two ways in which an AT sends a Route Protocol Packet (e.g., an air-interface signaling 38

message) to an ANRI in the Route Set: directly or indirectly. If the destination ANRI is the RLSE then 39

the AT sends the packet directly over-the-air to the RLSE. A solid-line arrow from the AT to the RLSE 40

represents this case. An example is shown in Figure 1.3.3.1-1. 41

A T

R ou te P ro toco l P acke t

eB S 1(R LS E )

42

Figure 1.3.3.1-1 RL Route Protocol Packet - Receiving eBS is RLSE 43

3GPP2 A.S0020-0 v1.0

1-6

If the destination ANRI is not the RLSE then the AT sends the packet indirectly via tunneling. It is 1

assumed that the RLSE can tunnel the packet to the correct ANRI based on the Inter-Route Tunneling 2

Protocol header, using information in the RouteMap packet if necessary. The AT sends the packet to the 3

RLSE, which then forwards the signaling packet to the ANRI through the Link-Layer Tunnel (LLT) 4

interface. In this case, each packet is represented by solid-line arrows from the AT to the RLSE and from 5

the RLSE to the destination eBS. An over-the-air reverse-link Route Protocol Packet to be tunneled is 6

labeled “[eBSx] Route Protocol Packet”, where eBSx identifies the destination eBS of the packet. The 7

packet tunneled between eBS1 and eBS2 is labeled “LLT: Route Protocol Packet” to emphasize that the 8

packet is tunneled through the LLT interface and that the RLSE does not interpret the content of the 9

tunneled packet. An example is shown in Figure 1.3.3.1-2. 10

AT

[eBS2] Route Protocol Packet

eBS1(RLSE)

eBS2

LLT: Route Protocol Packet

11

Figure 1.3.3.1-2 Tunneled RL Route Protocol Packet - Receiving eBS is not RLSE 12

To simplify the UMB IOS, we use the notation in Figure 1.3.3.1-3 to represent both cases of the AT 13

transmitting a Route Protocol Packet to the eBS. The destination eBS may or may not be the RLSE; even 14

if an intermediate RLSE exists it may not be shown. The packet is represented by a dashed-line arrow 15

labeled “Route Protocol Packet.” 16

AT

Route Protocol Packet

eBS2

17

Figure 1.3.3.1-3 Logical Representation of AT Sending a Tunneled Route Protocol Packet to an 18

eBS 19

1.3.3.2 Tunneling of Forward-link Route Protocol Packet 20

There are three ways in which an ANRI in an AT’s route set can send a Route Protocol Packet (e.g., an 21

air-interface signaling message) to the AT. If the source ANRI is the FLSE then the ANRI sends the 22

packet directly over-the-air to the AT. A solid-line arrow from the FLSE to the AT represents this case. 23

An example is shown in Figure 1.3.3.2-1. 24

A T

R oute P ro toco l P acket

eB S 1(FLS E )

25

Figure 1.3.3.2-1 FL Route Protocol Packet - Originating eBS is FLSE 26

If the source ANRI is not the FLSE but knows the identity of the FLSE based on the IPT-Notification 27

packet then the ANRI forwards the signaling packet to the FLSE through the link LLT interface. The 28

FLSE then transmits the packet to the AT by including the Inter-Route Tunneling Protocol header. Refer 29

to [1]. A solid-line arrow represents this case. The tunneled packet between eBS2 and eBS1 is labeled 30

“LLT: Route Protocol Packet” to emphasize that the packet is tunneled through the LLT interface and the 31

FLSE does not interpret the content of the tunneled packet. An over-the-air forward-link Route Protocol 32

Packet is labeled “[eBSx] Route Protocol Packet” where eBSx represents the eBS that is the original 33

transmitter of the packet. An example is shown in Figure 1.3.3.2-2. 34

3GPP2 A.S0020-0 v1.0

1-7

A T

[eB S 2] R oute P ro toco l P acke t

eB S 1(F LS E )

eB S 2

LLT : R oute P ro toco l P acke t

1

Figure 1.3.3.2-2 FL Tunneled Route Protocol Packet - Originating eBS is not FLSE But Knows the 2

Identity of the FLSE 3

If the source ANRI is not the FLSE and does not know the identity of the latest FLSE, then the source 4

ANRI tunnels the packet to its last known FLSE. This may happen for example because the notification 5

of the latest identity of the FLSE has not yet reached the ANRI that originates the packet. The eBS that is 6

the last known FLSE receives the packet via the LLT interface, recognizes that it is not the FLSE, and 7

forwards the packet to the current FLSE. The FLSE then transmits the packet to the AT. In this case, each 8

packet is represented by solid-line arrows. An example is shown in Figure 1.3.3.2-3. 9

AT

[eBS3] Route Protocol Packet

eBS1(FLSE)

eBS2(previous

FLSE)

LLT: Route Protocol Packet LLT: Route Protocol Packet

eBS3

10

Figure 1.3.3.2-3 FL Tunneled Route Protocol Packet - Originating eBS is not FLSE and Does not 11

Know the Identity of the latest FLSE 12

To simplify the UMB IOS, we use the notation in Figure 1.3.3.2-4 to represent all cases of an eBS 13

transmitting a Route Protocol Packet to the AT. The source ANRI may or may not be the FLSE; even if 14

intermediate eBSs (including an previous FLSE) exist they may not be shown in the call flow. The packet 15

is represented by a dashed-line arrow labeled “Route Protocol Packet.” 16

A T

R ou te P ro to co l P a cke t

e B S 3

17

Figure 1.3.3.2-4 Logical Representation of an eBS Sending a Tunneled Route Protocol Packet to 18

the AT 19

20

1.4 UMB IOS Architecture Reference Model 21

The UMB IOS interfaces are based on the Architectural Reference Model shown in Figure 1.4-1. 22

Network elements shown in Figure 1.4-1 are functional entities. The functional entities defined in this 23

specification are described in section 1.4.1. Solid lines in Figure 1.4-1 indicate interface reference points 24

between functional entities. An interface reference point may contain one or more protocol interfaces. 25

Different reference points may utilize the same protocol. Refer to section 1.4.2 for a description of each 26

reference point. 27

In this specification, an Access Network (AN) is not considered a network element. An AN in this 28

specification is a functional entity that contains an AN Route Instance (ANRI) for the purpose of logically 29

communicating with the Access Terminal (AT), and is included for reference purposes to align with [1] 30

only. An ANRI shall support control signaling communication with the AT and may support bearer 31

communication with the AT. Communication by an ANRI that is not currently serving the AT on a 32

3GPP2 A.S0020-0 v1.0

1-8

forward or reverse radio link is accomplished logically by tunneling UMB Route Protocol Packets 1

through the FLSE and RLSE. 2

3

Figure 1.4-1 UMB IOS Architecture Reference Model 4

1.4.1 Network Element Functional Descriptions 5

The UMB IOS Radio Access Network and associated Packet Data Network are comprised of several 6

network elements as described herein. 7

1.4.1.1 Access Gateway 8

The Access Gateway (AGW) provides the “point of IP attachment” to the Packet Data network for ATs. 9

As such, the AGW is effectively the first-hop router for the AT. Refer to [2]. The AGW may consist of 10

Control-plane (C-plane) to handle signaling messages between eBS/SRNC and the AGW, and User-plane 11

(U-plane) to handle bearer traffic. C-plane and U-plane may have different IP endpoint. C-plane 12

terminates PMIP signaling interface and AAA interface. U-plane terminates PMIP bearer interface. 13

1.4.1.2 Evolved Base Station 14

An evolved Base Station (eBS) can support over-the-air bearer communication with the AT. Each non-15

DAP eBS contains an ANRI for each AT it is serving. A DAP eBS may not have a route to a given AT, in 16

which case it will not contain an ANRI for that AT. An eBS can be in zero or more of the following states 17

for an AT: Forward Link Serving eBS (FLSE), Reverse Link Serving eBS (RLSE), or DAP. 18

The DAP is the bearer-plane point-of-contact for the AT to the AGW for forward-link data. The AGW 19

sends the data and control signaling related to the AT to the DAP. Reverse link data from the AT is 20

forwarded to the DAP to be sent to the AGW when a single PMIP binding is established with an AGW, or 21

is sent directly by the eBS to the AGW when multiple bindings are established with an AGW. If the RAN 22

is in secure environment, the eBS may send reverse link data directly to the AGW though RL-Only 23

binding is not established. 24

3GPP2 A.S0020-0 v1.0

1-9

The DAP can be relocated to a different eBS during the lifetime of the packet data session based on 1

several factors, such as performance considerations. An example may be to move the DAP when the eBS 2

hosting the DAP is not one of the active route members. 3

1.4.1.3 Session Reference Network Controller 4

The Session Reference Network Controller (SRNC) is responsible for maintaining the session reference 5

with the AT. The SRNC is also responsible for supporting idle state management of the AT, and provid-6

ing paging control functions when the AT is idle. The SRNC contains a Session Anchor ANRI for each 7

AT it is supporting. AGW selection is performed by the SRNC for the AT. An SRNC may assume the 8

DAP SRNC function to establish a Signaling-Only binding with the AGW when the AT is idle. The 9

SRNC is also the authenticator for access authentication. 10

Note: Interoperability between different implementation options (e.g., the SRNC may be in a standalone 11

entity, or it may be collocated in an eBS or in an AGW) is transparently supported in this specification. 12

Additionally, if the SRNC is collocated with the eBS, the eBS and SRNC may share the same ANRI. 13

1.4.2 Reference Point Descriptions 14

Each reference point in Figure 1.4-1 provides different functionalities for the UMB system. Each refer-15

ence point contains one or more protocol interfaces defined in this specification. For a description of each 16

protocol interface, refer to section 1.4.3. 17

U1 The U1 reference point carries control and bearer information between the eBS and the AGW. 18

U2 The U2 reference point carries control information between the SRNC and eBS. 19

U3 The U3 reference point carries control and bearer information between two eBSs. 20

U4 The U4 reference point carries control information between SRNCs. 21

U6 The U6 reference point carries control information between the SRNC and AGW. 22

1.4.3 Protocol Interface Descriptions 23

The protocol interfaces defined in this specification are described as follows. 24

• AAA (Authentication, Authorization and Accounting) Interface. This interface allows performing 25

authentication, authorization and accounting. This interface is part of U1 and U6 reference points. 26

Refer to section 2.6, for detailed specification. 27

• IAS (Inter-ANRI Signaling) Interface. This interface is part of the U2, U3 and U4 reference points 28

and allows for signaling of session information and paging information for an AT between ANRIs 29

and between ANRIs and DAP (if DAP is not in the route set). 30

• IPT (IP Tunneling) Interface. This interface allows for signaling between ANRIs, between ANRIs 31

and DAP (if DAP is not in the route set), and tunneling of user IP packets between eBSs for an AT. 32

The interface is composed of two parts. The first part, called the IPT signaling interface, is part of the 33

U2 and U3 reference points, and carries the signaling messages necessary to notify and redirect 34

tunneled traffic based on the mobility of the AT. The second part, called the IPT data interface, is part 35

of the U3 reference point and encapsulates the tunneled user IP packets to be transmitted between 36

eBSs. 37

• LLT (Link-Layer Tunneling) Interface. This interface is part of the U2 and U3 reference points 38

and allows for tunneling link-layer packets to FLSE or DAP and from RLSE. The LLT interface is 39

composed of a single message that encapsulates the link layer packet (i.e., Route Protocol Packet in 40

the Inter-Route Tunneling Protocol payload [1]). The LLT interface is shown as a dotted line in call 41

flows. 42

• PMIP (Proxy Mobile IP) Interface. This interface allows for tunneling of user IP packets between 43

the AGW and the eBSs and also for signaling data buffering and data notification between the AGW 44

and eBS/SRNC. This interface consists of two parts. The first part called the PMIP signaling interface 45

is part of the U1 and U6 reference points which carries the signaling messages necessary to setup, 46

3GPP2 A.S0020-0 v1.0

1-10

refresh and teardown PMIP binding between the AGW and eBS/SRNC for an AT. The second part 1

called the PMIP bearer interface is part of the U1 reference point and allows for tunneling of user IP 2

packets between the AGW and the eBS. 3

4

1.5 Message Body, Coding, Ordering, and Interpretation of IEs 5

Each message of each interface defined in the UMB IOS has a number of information elements (IEs) that 6

are individually defined in section 4.2. In section 4.1, each IE in a given message is tagged with a 7

reference and a required/conditional type (R/C) indicator. Some IEs are reused in multiple messages. 8

The inclusion of IEs in each message is specified as follows: 9

R Required. IEs which are required for a given message shall be present and appear in the 10

order shown in the message definitions. Refer to section 1.7, Message Processing 11

Guidelines. 12

C Conditional. IEs which are conditional for a given message are included as needed for 13

specific conditions. The conditions for inclusion of such IEs are defined in the oper-14

ation(s) where the message is used and in footnotes associated with the table. When 15

included, they shall appear in the order shown in the message definitions. 16

An IE may be required for some messages and conditional for other messages. 17

The following conventions are assumed for the sequence of transmission of bits and bytes: 18

• Each bit position is marked as 0 to 7. For interfaces whose messages are defined in this standard, bit 0 19

is the least significant bit. 20

• In a message, octets are identified by number. Octet 1 is transmitted first, then octet 2, etc. 21

For all IEs, except Message Type, a length indicator is included. This indicates the number of octets 22

following in the IE. 23

IEs shall always use the same Information Element Identifier (IEI) for all occurrences on a specific UMB 24

interface. Insofar as possible, the same IEI shall be used for a given IE when it is used on more than one 25

interface. 26

For future expansion purposes, some of these IEs contain fields that have been reserved. All reserved bits 27

are set to ‘0’, unless otherwise indicated. To allow compatibility with future implementation, messages 28

shall not be rejected simply because a reserved bit is set to ‘1’. 29

30

1.6 Forward Compatibility Guidelines 31

This standard is intended to evolve to accommodate new features and capabilities. To ensure that 32

equipment implemented to one revision level interoperates with equipment implemented to later revision 33

levels, the following guidelines are defined for the processing of messages and for the development of 34

messages in future revisions of this standard. 35

Unexpected signaling information may be received at an entity due to differing revision levels of 36

signaling protocol at different entities within a network: an entity using a more enhanced version of the 37

protocol may send information to an entity implemented at a lower level of the protocol which is outside 38

the protocol definition supported at that receiving entity. 39

It may happen that an entity receives unrecognized signaling information, i.e., messages, IE types or IE 40

values. This can typically be caused by the upgrading of the protocol version used by other entities in the 41

network. In these cases the following message processing guidelines are invoked to ensure predictable 42

network behavior. 43

3GPP2 A.S0020-0 v1.0

1-11

The sending entity shall send messages that are correctly formatted for the version of the IOS 1

implemented by the sending entity. 2

1.7 Message Processing Guidelines 3

A Version field is included in the IAS and IPT Message Type IE for every IAS and IPT message. When a 4

message cannot be processed at the receiving entity according to the previous version of this specification, 5

then the version shall be incremented. The version need not be incremented based on the addition to a 6

message of an IE that is not required to be processed by the receiver. If no new message or IEs are added 7

that are required to be processed at the receiving entity then the version shall not be incremented. 8

The following message processing guidelines apply to all interfaces whose messages are defined in this 9

standard unless overridden by explicit processing directions in other places within this standard. 10

The guidelines in this section address required and conditional IEs as indicated in the message tables in 11

section 4.1. 12

1. If an IAS or IPT message is received containing a version in the IAS or IPT Message Type IE which 13

is not defined for the revision level implemented then the message shall be discarded and the IAS or 14

IPT-Reject message returned, providing information on the rejected message and indicating all the 15

versions that the sender supports. Refer to sections 2.2.2.18 and 2.3.5.4. There shall be no change in 16

state or in timers due to receipt of an unknown message. 17

2. The Version field in the IAS and IPT Message Type IEs of the IAS and IPT-Reject messages shall be 18

set to 00H by the sender and ignored by the receiver. An IAS or IPT-Reject message shall not be sent 19

in response to an IAS or IPT-Reject message. 20

3. If a message is received containing a Message Type value which is not defined for the revision level 21

implemented then the message shall be discarded and ignored. There shall be no change in state or in 22

timers due to receipt of an unknown message. The recipient of the message may send a reject 23

message (e.g., IAS-Reject message) in this case if the sender of the message is considered trusted. 24

4. If a message is received with out-of-order IEs or without an expected required IE then the message 25

shall be processed to the extent possible and failure handling initiated if call processing cannot 26

continue. If the message cannot be processed it is discarded and ignored and there shall be no change 27

in state or in timers due to receipt of the message. The recipient of the message may send a reject 28

message (e.g., IAS-Reject message) in this case if the sender of the message is considered trusted. 29

5. If a message is received that contains an IE which is defined for the revision level implemented but 30

contains invalid values in some fields, these fields shall be ignored and the remainder of the IE 31

processed to the extent possible. The message and all other IEs shall be processed to the extent 32

possible. Failure handling may be initiated if call processing cannot continue. For failure handling, an 33

IAS or IPT-Reject message may be sent to indicate the IE(s) that caused the message to be rejected. 34

Also refer to message processing guidelines 11 and 12. 35

6. If a message is received that contains an IEI which is not defined for the revision level implemented 36

then that IE shall be discarded and ignored. The message shall be processed to the extent possible. 37

Failure handling may be initiated if call processing cannot continue. 38

7. If a known but unexpected conditional IE is received, that IE shall be ignored. The message and all 39

other IEs shall be processed. 40

8. If a message is received without an expected conditional IE the message shall be processed to the 41

extent possible. Failure handling may be initiated if call processing cannot continue. 42

9. If a field within a received IE contains a value which is specified as “reserved” or is otherwise not 43

defined in the revision level implemented, this field shall be ignored and the remainder of the IE 44

processed to the extent possible. In this situation, all other IEs shall be processed to the extent 45

possible. 46

3GPP2 A.S0020-0 v1.0

1-12

10. Octets and bits designated as “Reserved” or which are undefined for the revision implemented shall 1

be set to zero by a sending entity and ignored by a receiving entity even if the value is nonzero. 2

11. If an IE is received containing a field that is larger than expected, i.e., is indicated as having more 3

bits/octets than expected, then the expected bits/octets of that field shall be processed to the extent 4

possible and the additional bits/octets shall be ignored. 5

12. If an IE is received containing a field that is smaller than expected, i.e., is indicated as having fewer 6

bits/octets than expected, then the length field or other indicator shall be considered correct and the 7

bits/octets actually present in the IE shall be processed to the extent possible. Failure handling may be 8

initiated if call processing cannot continue. For failure handling, an IAS or IPT-Reject message may 9

be sent to indicate the IE(s) that caused the message to be rejected. If a required IE has Length = 0, an 10

IAS or IPT-Reject message should be sent to indicate the IE(s) that caused the message to be rejected. 11

1.8 Message Definition Guidelines 12

1. New messages shall have a Message Type that has never been previously used on that interface. 13

2. IEIs shall not be reused in future revisions. 14

3. Defined valid values of IEs may be changed in future revisions. The new version shall define the 15

error handling when previously valid values are received. 16

4. Octets and bits which are undefined or which are defined as reserved may be used in future revisions. 17

5. The required/conditional designation of IEs within a message shall not change. 18

6. Messages shall include IEs in the order specified in section 4.1. 19

7. New IEs in a message shall be defined after all previously defined IEs. 20

8. All IEs shall be defined with a length field. IEI values in the range A0H-BFH inclusive shall be 21

defined to have a 2 octet length field. All other IEI values shall be defined to have a 1 octet length 22

field. 23

9. New information may be added to the end of an existing IE. 24

1.9 UMB IOS Assumptions 25

This section provides a listing of UMB IOS assumptions. 26

1.9.1 Connectivity Assumptions among Network Elements 27

The following are the details of the connectivity assumptions among network elements in UMB RAN that 28

are required for session and connection continuity during mobility. 29

1. Any eBS can reach any SRNC directly by sending IP packets via the IAS, IPT and LLT interfaces. If 30

the SRNC cannot be reached, then the eBS closes the session and the AT may restart power-up 31

procedure. 32

2. An eBS can reach at least one AGW directly by sending IP packets via the PMIP interface. 33

3. An eBS may be able to communicate with several AGWs. However, the eBS will only communicate 34

with a single AGW for each AT. 35

4. An eBS can reach any other eBSs by sending IP packets via the IAS, IPT and LLT interfaces. 36

5. Any SRNC can reach any eBS directly by sending IP packets via the IAS, IPT and LLT interfaces. 37

6. Any SRNC can reach any other SRNC directly by sending IP packets via the IAS interface. 38

7. An SRNC can reach at least one AGW directly by sending IP packets via the PMIP interface. 39

8. An ANRI can communicate with other ANRIs in the route set. 40

3GPP2 A.S0020-0 v1.0

1-13

1

1.9.2 PMIP Bearer Tunnel Management Guidelines 2

The following are the details of the PMIP Bearer Tunnel maintenance assumptions and guidelines. 3

1. For each AT having a packet data session with the AGW, there is one PMIP tunnel between the 4

AGW and either the DAP eBS or the DAP SRNC. If the binding is with the DAP eBS then it is of 5

type Primary, RL+Primary or Signaling-Only. If the binding is with a DAP SRNC then it is of type 6

Signaling-Only. It is assumed that establishment of a Primary, RL+Primary, or Signaling-Only 7

binding with an AGW automatically clears the binding information for any other Primary, 8

RL+Primary, or Signaling-Only binding that may exist for the same AT at that AGW. 9

2. Based on operator policy, one RL-Only PMIP tunnel can also be provided between each non-DAP 10

eBS in the Route Set and the AGW for each AT. 11

3. The procedures for authentication of the AT and for the establishment of the security keys between 12

the AT, eBS, SRNC and AGW are described in [2] and shall be performed before initiating the 13

establishment of the PMIP Tunnel(s) between the eBS and the AGW. Refer to section 3.1.1. for 14

details. 15

4. The eBS shall perform Mobility Access Gateway (MAG) functions of PMIPv4 protocol for packet 16

tunneling between AGW-eBS. The AGW shall provide the corresponding Local Mobility Anchor 17

(LMA) capabilities for packet tunneling between AGW-eBS. 18

5. If an RL Tunnel is not used between the eBS and the AGW, and the eBS is to become the DAP, the 19

eBS/DAP initiates establishment of the Primary PMIP Tunnel with the AGW. 20

6. If an RL Tunnel is used between the eBS and the AGW: 21

a) When an eBS in the route set is to become the DAP, it initiates establishment of a ‘RL+Primary’ 22

PMIP Tunnel with the AGW. 23

b) Each non-DAP eBS in the Route Set of the AT may initiate establishment of the ‘RL-Only’ 24

PMIP tunnel with the AGW. The route set of an AT may include some non-DAP eBSs that use 25

RL-Only PMIP tunnels and some others that tunnel RL data to the DAP. 26

7. If an RL Tunnel is not used between the eBS and the AGW, as long as the eBS is the DAP, the 27

eBS/DAP refreshes the Primary PMIP Tunnel according to the PMIPv4 procedures. For AT-assisted 28

DAP handoff mode, the AT is required to send a DAPMoveRequest message before the PMIP 29

lifetime2 expires. 30

8. If an RL Tunnel is enabled at the eBS: 31

a) As long as the eBS is the DAP, the eBS/DAP refreshes the ‘RL+Primary’ PMIP Tunnel 32

according to the PMIPv4 procedures. 33

b) As long as a non-DAP eBS is in the Route Set of the AT and the RL tunnel has been established, 34

the eBS refreshes the RL-Only PMIP Tunnel according to the PMIPv4 procedures. 35

9. The eBS initiates teardown of the PMIP Tunnel according to PMIPv4 procedures. 36

10. The AGW may initiate teardown of the PMIP Tunnel according to PMIPv4 Revocation procedures. 37

11. Methods to handle the transport of in-flight packets and the packets still buffered at the old-AGW 38

before removing the PMIP binding at the old-DAP/eBS and the old-AGW are for further study. 39

1.9.3 UMB Mobility Concepts 40

Figure 1.9.3-1 provides a conceptual view of different levels of packet data mobility. 41

2 PMIP lifetime is communicated to the AT via the DAPRefreshTime value received in the DAPAssignment message [1].

3GPP2 A.S0020-0 v1.0

1-14

1

Figure 1.9.3-1 UMB Mobility Concepts 2

• Inter-eBS and Inter-SRNC mobility based on the UMB air-interface and IOS procedures are 3

described in this specification. 4

• Mobility between AGWs is described in section 3.6.5, 3.7.1.4 and [2]. 5

1.9.4 UMB Security Key Concepts 6

This section describes UMB security key concepts on how UMB security keys are generated and 7

delivered to each network elements when ERP is not used. For normative and detailed description, refer 8

to [2] and [1]. Figure 1.9.4-2 illustrates an overview of key generation and delivery. 9

3GPP2 A.S0020-0 v1.0

1-15

1

Figure 1.9.4-2 UMB Security Key Concepts 2

a. The AT and the AAA have a PSK (Pre Shared Key). 3

b. The AT and the SRNC establishes a UMB session. 4

c. The AAA generates MSK (Master Session Key) using PSK and delivers the MSK to the SRNC via 5

the AGW as a result of access authentication. The AT also generates MSK using PSK stored in the 6

AT. 7

d. The AT and the SRNC generate PMK (Pair-wise Master Key) for SRNC from the MSK. 8

e. TSK for the SRNC route is generated by KEP (Key Exchange Protocol) specified in [1]. 9

f. The AT and the SRNC generate several security keys for the SRNC route based on the TSK 10

generated at step ‘e’. 11

g. The AT opens a route with the eBS. 12

h. The eBS sends an IAS-Session Information Request message to retrieve a session information. 13

i. The AT and the SRNC generate a derived MSK for security association between the AT and the eBS. 14

j. The SRNC sends the derived MSK to the eBS in an IAS-Session Information Response message. 15

k. The AT and the SRNC generate PMK for SRNC from derived MSK. 16

l. TSK for the eBS route is generated by KEP specified in [1]. 17

m. The AT and the eBS generate several security keys for the eBS route based on the TSK generated at 18

step ‘l’. 19

3GPP2 A.S0020-0 v1.0

1-16

1

1.10 UMB Feature Descriptions 2

This section provides a description of the features supported by the UMB IOS. 3

1.10.1 Explicitly Supported Features 4

These features are explicitly supported by the UMB IOS. 5

1.10.1.1 AT Originates a UMB Session 6

This feature supports the ability to originate a UMB session. 7

1.10.1.2 Route Set Add and Remove 8

This feature supports the ability to add or remove an ANRI to/from the route set for an AT. 9

1.10.1.3 Session Negotiation 10

This feature supports the ability to update UMB session information at the SRNC and the AT, and 11

provide updated session information to all ANRIs in the route set. 12

1.10.1.4 UMB Data Delivery (both AT Terminated and AT Originated) 13

This feature supports the ability of the AT to terminate and originate data delivery. 14

1.10.1.5 Forward and Reverse Link Serving eBS (FLSE/RLSE) Switch 15

This feature supports the ability of the AT to move between different serving eBSs. 16

1.10.1.6 Data Attachment Point (DAP) Handoff 17

This feature supports the ability of the DAP for an AT to move between different eBSs under the same or 18

different AGWs. 19

1.10.1.7 Idle and Active Session Reference Transfer 20

This feature supports the ability of the AT to move between different SRNCs under the same or different 21

AGWs. 22

1.10.1.8 Idle State Mobility and Paging 23

This feature supports the ability of the network to locate and page an AT. 24

1.10.1.9 Packet Data Session Release 25

This feature supports the ability of the AGW to initiate release of a packet data session. 26

1.10.1.10 UMB Session Release 27

This feature supports the ability of the AT or an ANRI to initiate release of a UMB session. 28

1.10.1.11 AT and Network Initiated Neighbor Discovery 29

This feature supports the ability of the eBS to discover new neighboring eBSs or provide an update of its 30

own provisioned information to neighboring eBSs. 31

32

3GPP2 A.S0020-0 v1.0

2-1

2 UMB IOS Interfaces 1

This section describes the RAN interfaces associated with this specification. 2

2.1 Transport Network IP Quality of Service (QoS) Framework for GRE Tunnels 3

To ensure that the transport network provides the necessary performance characteristics, the end nodes 4

and transport network interfaces which require transport QoS shall support the Differentiated Services 5

(DiffServ) framework as specified in [5], with the following clarifications: 6

• The portions of the RAN transport network supporting the U1 and U3 reference points may be over-7

provisioned in comparison to the air interface (AT to eBS) capacity, and the network traffic loads on 8

the interfaces of the U1 and U3 reference points, or both. In case a RAN transport network is over-9

provisioned, the QoS framework in this section is not applicable to that transport network. 10

• Transport nodes (e.g., interior routers) shall support the following: 11

o Per packet classification according to the Type of Service (TOS)/Differentiated Services Code 12

Point (DSCP) field in the IPv4 header 13

o One or more queuing disciplines to meet the interface’s delay/jitter requirements. 14

• Edge transport nodes (e.g., border routers) shall support the following: 15

o Policing disciplines to meet the traffic flow requirements. 16

• End host nodes (e.g., eBSs) shall support the following when required: 17

o Per packet marking of a DSCP via the IPv4 TOS octet. 18

o Four or more traffic classes as defined by the relevant interface. The parameters of each class 19

include mandatory and optional traffic types, service delay, and packet loss rate. 20

The user’s IP traffic associated with the packet data service is tunneled between DAP and AGW using 21

GRE/IP transport. The inner IP packet is the packet transmitted between the user (e.g. AT) and its 22

correspondent node (e.g., Internet server). The outer IP packet transports (or tunnels) a portion of the 23

inner packet between the RAN components (i.e., eBS, AGW). 24

If the RAN supports QoS on the transport interfaces of the U1 and U3 reference points, the RAN shall 25

have a local RAN transport network QoS policy which indicates which outer DSCP values can be used by 26

the AGW and eBS for traffic. 27

2.2 IAS (Inter-ANRI Signaling) Interface 28

For this revision of the specification, the version number for the IAS interface is 01H. 29

This interface is part of the U2, U3 and U4 reference points and allows for signaling of UMB session in-30

formation and paging information between ANRIs for an AT as well as neighbor discovery between eBSs. 31

2.2.1 IAS Interface Network/Transport Protocol Specification 32

The UMB IOS protocol stack for the IAS signaling interface is defined as follows. 33

34

IOS Application UDP

IP

The underlying physical transport medium under IP is left to the discretion of operators and 35

manufacturers. The following UDP port value is reserved for signaling on the IAS interface: 36

• IAS 4594/udp - This is the registered UDP port number to be used for signaling interconnection of 37

session related information between ANRIs on the U2, U3, and U4 reference points. 38


paging related information between ANRIs on the U2 and U3 reference points. 40

3GPP2 A.S0020-0 v1.0

2-2


neighbor discovery related information between eBSs on the U2 and U3 reference points. 2

Identification of port usage for specific messages is identified in Table 2.2.2-1. 3

2.2.2 IAS Interface Message Procedures 4

This section describes the message procedures used between ANRIs on the IAS interface. The interface 5

consists of the following messages identified in Table 2.2.2-1. 6

7

Table 2.2.2-1 IAS Message Section and Port Reference

Message Name Section Port Transaction Initiation Message

IAS-Session Information Request 2.2.2.1 4594 yes1

IAS-Session Information Response 2.2.2.2 4594 no2

IAS-Session Information Update Request 2.2.2.3 4594 yes1

IAS-Session Information Update Response 2.2.2.4 4594 no2

IAS-SRNC Transfer Request 2.2.2.5 4594 yes1

IAS-SRNC Transfer Response 2.2.2.6 4594 no2

IAS-Session Release 2.2.2.7 4594 yes1

IAS-Session Release Ack 2.2.2.8 4594 no2

IAS-UATI Update 2.2.2.9 4594 yes1

IAS-UATI Update Ack 2.2.2.10 4594 no2

IAS-Paging Request 2.2.2.11 4595 yes1

IAS-Paging Request Ack 2.2.2.12 4595 no2

IAS-Page 2.2.2.13 4595 yes1

IAS-Page Ack 2.2.2.14 4595 no2

IAS-Neighbor Discovery Request 2.2.2.15 4596 yes1

IAS-Neighbor Discovery Report 2.2.2.16 4596 yes3

IAS-Neighbor Discovery Report Ack 2.2.2.17 4596 no2

IAS-Reject 2.2.2.18 4594, 4595, 4596

no2

3GPP2 A.S0020-0 v1.0

2-3

Note 1: The destination port number in the UDP packet that carries a transaction initiation message 1

shall be set to the port value specified in Table 2.2.2-1. 2

Note 2: The receiver of a transaction initiation message shall set the <source port, source IP address> 3

and <destination port, destination IP address> of the UDP packet that carries the corresponding 4

transaction response message to the <destination port, destination IP address> and <source port, 5

source IP address> of the UDP packet that carried the transaction initiation message, 6

respectively. 7

Note 3: If this message is sent unsolicited, the destination port number in the UDP packet that carries a 8

transaction initiation message shall be set to the port value specified in Table 2.2.2-1. 9

Otherwise, the receiver of a transaction initiation message shall set the <source port, source IP 10

address> and <destination port, destination IP address> of the UDP packet that carries the 11

corresponding transaction response message to the <destination port, destination IP address> 12

and <source port, source IP address> of the UDP packet that carried the transaction initiation 13

message, respectively. 14

15

2.2.2.1 IAS-Session Information Request 16

The IAS-Session Information Request message is sent by an eBS to retrieve session information from the 17

SRNC. Refer to section 4.1.1.1, IAS-Session Information Request, for the format and content of this 18

message. 19

2.2.2.1.1 Successful Operation 20

2.2.2.1.1.1 Session Information Retrieval triggered by RouteOpenRequest 21

When an eBS receives a request to open a route (e.g., a RouteOpenRequest message) from the AT and it 22

can establish a route with the AT, the eBS sends an IAS-Session Information Request message to the 23

SRNC. The SRNC is identified using the UATI of the AT which is received either over-the-air during 24

access procedure or received in the LLT tunneling header (refer to 2.4.1, for LLT header]). Refer to [1] on 25

how to derive ANID and IP address of the SRNC from the UATI. The fields in the message shall be set as 26

follows: 27

• The AT Identity IE of the message shall be set to the UATI of the AT; 28

• The sender Endpoint ID shall be set to the ANID of this eBS and the receiver Endpoint ID shall be set 29

to the ANID of the SRNC; 30

• The RouteOpenRequest IE shall include information from the RouteOpenRequest message that is 31

received from the AT at the sending eBS and the Access/Tunneled bit shall be set to indicate whether 32

the message is received during access procedure or is received via a tunnel; 33

• The Session Signature IE shall be included and is set to the value of the latest session signature, e.g., 34

the value received in the SessionUpdated message from the AT. 35

• The Session Request Record IE shall be included with the Derived MSK Required bit set to ‘1’ when 36

the sending entity requires a derived master session key from the SRNC. The Route Counter is used 37

for MSK derivation. Refer to [2]. 38

Upon sending the message, the eBS starts timer Tsir-ias and awaits arrival of the IAS-Session Information 39

Response message that has the same Correlation ID as the IAS-Session Information Request message. 40

3GPP2 A.S0020-0 v1.0

2-4

2.2.2.1.1.2 Session Information Retrieval triggered by Session Updated 1

When an eBS receives an indication from the AT that the session has been updated3, the eBS sends an 2

IAS-Session Information Request message to the SRNC. The SRNC is identified using the UATI of the 3

AT. The fields in the message shall be set as follows: 4

• The AT Identity IE of the message shall be set to the SSID and the UATI of the AT; 5

• The sender Endpoint ID shall be set to the ANID of this eBS and the receiver Endpoint ID shall be set 6

to the ANID of the SRNC; 7

• The RouteOpenRequest IE shall not be included; 8

• The Session Signature IE shall be included and is set to the value of the latest session signature, e.g., 9

the value received in the SessionUpdated message from the AT. 10




Upon sending the message, the eBS starts timer Tsir-ias and awaits arrival of the IAS-Session Information 14

Response message that has the same Correlation ID as the IAS-Session Information Request message. 15

2.2.2.1.1.3 Session Information Retrieval Triggered by UMB Session Release Procedure Initiated by 16

SRNC 17

When the SRNC receives an IAS-Session Information Request message after the SRNC has initiated the 18

UMB session release procedure for an AT in idle state, the SRNC responds with an IAS-Session 19

Information Response message with the cause value set to ‘Requested session not found’. Upon sending 20

the IAS-Session Information Response message, the SRNC purges the UMB session for the AT. 21

2.2.2.1.2 Failure Operation 22

If timer Tsir-ias expires, the eBS may resend the IAS-Session Information Request message to the SRNC 23

and restart timer Tsir-ias an implementation-dependent number of times. If the IAS-Session Information 24

Response message is not received from the SRNC, the eBS should close the route with the AT. 25

2.2.2.2 IAS-Session Information Response 26

The IAS-Session Information Response message is sent by the SRNC to another ANRI that sent an IAS-27

Session Information Request message to the SRNC. Refer to section 4.1.1.2, IAS-Session Information 28

Response, for the format and content of this message. 29


2.2.2.2.1.1 Session Retrieval as a result of RouteOpenRequest 31

If the IAS-Session Information Request message is received from an ANRI that is not in the route set, 32

then the SRNC shall authenticate the RouteOpenRequest IE, i.e., verify that the Authentication Tag 33

included in the message is valid according to [1] Part 008, Route Control Plane. 34

If the RouteOpenRequest IE is successfully authenticated, then the SRNC shall respond to the sender with 35

an IAS-Session Information Response message with the fields in the message set as follows: 36

• The AT Identity IE of the message shall be set to be the same as the AT Identity IE in the IAS-37

Session Information Request message; 38

• The sender Endpoint ID shall be set to the ANID of the SRNC and the receiver Endpoint ID shall be 39

set to the value of the sender Endpoint ID field in the IAS-Session Information Request message; 40

• The Cause IE shall be set to ‘Successful event’; 41

3 E.g., the indication can be the receipt of the SessionUpdated message from the AT with a new SessionSignature [1].

3GPP2 A.S0020-0 v1.0

2-5

• The IAS DAP Record IE shall contain AGW IP Address, LinkID, DAP Information (if available), 1

GRE key, and DAP Time Stamp, and the EAP NAI [2] for each AGW to which the AT connects. The 2

EAP NAI field shall be set to the NAI that the SRNC receives as part of the access authentication. 3

When a new route set member is added or when the PMN-AN-RK1 key has changed, the IAS DAP 4

Record IE shall contain the PMN-AN-HA1 key and the PMN-AN-HA1 Sequence Number (set to the 5

value of the route counter with MSBs set to zero), refer to [2], for each AGW to which the AT 6

connects. During route set add, the SRNC shall also provide the AAA-Session-ID and the EAP NAI 7

(received in EAP Identity Response) for accounting purposes; 8

• If the Session Signature IE in the received IAS-Session Information Request message contains a 9

session signature that the SRNC has assigned to the AT but has not received confirmation from the 10

AT yet, then the SRNC shall include the Session State Information Record IE and the Network 11

Session Information IE corresponding to the received Session Signature. This is implicit confirmation 12

of the received session signature. Otherwise, the SRNC shall include the Session State Information 13

Record IE and the Network Session Record IE corresponding to the current session signature at the 14

SRNC; 15

• The SRNC Record IE shall be included and set to the current information regarding the SRNC. The 16

Largest Route Counter field shall be set to the Largest Route Counter at the SRNC. Refer to section 17

2.2.3.4. The Access Counter field shall be included for use in IPT-Notification messages as an 18

indication of message freshness. Refer to section 2.2.3.1 for the procedure for maintaining (and 19

incrementing) the Access Counter at the SRNC. The Data Capable bit shall be set to ‘0’ when the 20

SRNC is not capable of handling data, otherwise, the Data Capable bit shall be set to ‘1’. 21

If the SRNC is paging the AT and the Access/Tunneled field in the RouteOpenRequest IE is set to ‘0’ for 22

‘Access’, then the SRNC shall stop paging the AT, stop timer Tpgreq-ias and enter the active state. 23

Upon receipt of the IAS-Session Information Response message with ‘Successful event’ Cause IE, the 24

ANRI shall store the information in the message for future operations. Subsequently, if the ANRI can 25

establish a route with the AT, it shall also accept the RouteOpenRequest from the AT. If the Derived 26

MSK Parameter SSIR4 (refer to [1]) is included in the Session State Information Record IE and the 27

included Derived MSK is valid (refer to section 2.2.3.3), then the ANRI shall perform Key Exchange with 28

the AT to establish a secure communication. Otherwise, the ANRI shall use other means, e.g., ERP [2], to 29

exchange cryptographic key before securing over-the-air communication using key exchange procedure. 30

Upon receipt of the IAS-Session Information Response message, the receiving ANRI stops timer Tsir-ias 31

corresponding to this message. 32

2.2.2.2.1.2 Session Retrieval as a result of Session Update 33

If the IAS-Session Information Request message is received from another ANRI in the route set, then the 34

SRNC shall respond to the sender with an IAS-Session Information Response message with the fields in 35

the message set as follows: 36






• The IAS DAP Record IE shall contain AGW IP Address, LinkID, DAP Information, GRE key, DAP 42

Time Stamp, and the EAP NAI as specified in [2] for each AGW to which the AT connects. The EAP 43

NAI field shall be set to the NAI that the SRNC receives as part of the access authentication. When a 44

new route set member is added or when the PMN-AN-RK1 key has changed, the IAS DAP Record IE 45

shall contain the PMN-AN-HA1 key and the PMN-AN-HA1 Sequence Number (set to the value of 46

the route counter with MSBs set to zero), refer to [2], for each AGW to which the AT connects. 47

4 This SSIR is currently referred to as PMK Parameter SSIR in [1] but will be referred to as Derived MSK Parameter SSIR in

later version of the specification.

3GPP2 A.S0020-0 v1.0

2-6

During route set add, the SRNC shall also provide the AAA-Session-ID and the EAP NAI (received 1

in EAP Identity Response) for accounting purposes; 2

• If the Session Signature IE in the IAS-Session Information Request message contains a session 3

signature that the SRNC has assigned to the AT but has not received confirmation from the AT yet, 4

then the SRNC shall include the Session State Information Record IE and the Network Session 5

Record IE corresponding to the received Session Signature IE. This is implicit confirmation of the 6

received session signature. Otherwise, the SRNC shall include the Session State Information Record 7

IE and the Network Session Record IE corresponding to the confirmed session signature at the 8

SRNC; 9

• The SRNC Record IE shall be included and set to the current information regarding the SRNC. The 10

Largest Route Counter field shall be set to the largest Route Counter at the SRNC. Refer to section 11

2.2.3.4. The Access Counter field shall be included and is set to the current value of the Access 12

Counter at the SRNC. The Data Capable bit shall be set to ‘0’ when the SRNC is not capable of 13

handling data, otherwise, the Data Capable bit shall be set to ‘1’. 14


If an IAS-Session Information Request message is received with any of the following conditions: 16

• The RouteOpenRequest IE cannot be authenticated; 17

• The AT Identity IE is invalid, i.e., the receiving ANRI is not the session anchor ANRI for the AT 18

identified in the message; 19

• The sending ANRI is not in the Route Set of the AT and RouteOpenRequest IE is not included; 20

• The AT Identity IE is an AT that the SRNC has not paged and the RouteOpenRequestReason is ‘Page 21

Response’; 22

• The included RouteCounter in the message is considered stale by the SRNC. Refer to section 2.2.3.4; 23

then the SRNC should respond5 to the sender with an IAS-Session Information Response message with 24

the fields in the message set as follows: 25





• If the Session Anchor Route ID field of the RouteOpenRequest message does not match the RouteID 30

of the SRNC and SRNC transfer is pending, then the Cause IE shall be set to ‘Session Anchor Route 31

ID mismatch’ and the SRNC Record IE (with the new SRNC record) according to the confirmed 32

session signature shall be included. If the AT Identity IE is invalid, the Cause IE shall be set to 33

'Requested Session Not Found’ or to Stale message if the RouteCounter in the message is considered 34

stale by the SRNC or to ‘SRNC did not page this UATI’ if the SRNC did not send a page to this AT6. 35

Otherwise, the Cause IE shall be set to ‘Authentication failure’; 36

• The Correlation ID shall be set to the value received in the corresponding IAS-Session Information 37

Request message. 38

• All of the other IEs shall be omitted. 39

Upon receipt of the IAS-Session Information Response message with ‘Session Anchor Route ID 40

mismatch’ Cause IE, the ANRI should resend another IAS-Session Information Request message based 41

on the SRNC Record IE of the received IAS-Session Information Response message. The receiving 42

ANRI also stops timer Tsir-ias corresponding to this message. 43

5 For example, the sender may not reply with an IAS-Session Information Response message if it determines that the request

is part of a denial of service attack.

6 Note that the SRNC may choose to reassign the PagingID if this scenario occurs, in order to minimize the likelihood of future PagingID collisions.

3GPP2 A.S0020-0 v1.0

2-7

Upon receipt of the IAS-Session Information Response message with ‘Authentication failure’ Cause IE, 1

the ANRI shall close the route with the AT. The receiving ANRI also stops timer Tsir-ias corresponding to 2

this message. 3

If an IAS-Session Information Request message cannot be accepted for reasons other than what have been 4

specified above then the Cause IE shall be set to ‘Request rejected - reason unspecified’. 5

Upon receipt of the IAS-Session Information Response message with ‘Requested Session Not Found’, 6

‘Stale message’ or ‘Request rejected - reason unspecified’ Cause IE, the ANRI shall close the session 7

with the AT using the appropriate cause value (refer to [1]). The receiving ANRI also stops timer Tsir-ias 8


2.2.2.3 IAS-Session Information Update Request 10

The IAS-Session Information Update Request message is sent by an ANRI to the SRNC to request a 11

change in the session information of the AT. Refer to section 4.1.1.3, IAS-Session Information Update 12

Request, for the format and content of this message. 13


If an ANRI that is not the Session Anchor ANRI has negotiated a session with the AT, then the ANRI 15

shall send an IAS-Session Information Update Request message to the SRNC. The SRNC is identified 16

using the UATI of the AT. The fields in the message shall be set as follows: 17


• The sender Endpoint ID shall be set to the ANID of this ANRI and the receiver Endpoint ID shall be 19

set to the ANID of the SRNC; 20

• The Session Signature IE shall be set to the value of the session signature at the sending ANRI before 21

session negotiation in the sending ANRI; 22

• The Session State Information Record IE and the Network Session Record IE shall include the 23

updated session information; 24

Upon sending the message, the ANRI starts timer Tsur-ias and awaits arrival of the IAS-Session 25

Information Update Response message that has the same Correlation ID as the IAS-Session Information 26

Update Request message. 27


If timer Tsur-ias expires, the sender may resend the IAS-Session Information Update Request message to 29

the SRNC and restart timer Tsur-ias an implementation-dependent number of times. If the IAS-Session 30

Information Update Response message is not received, the sender should close the connection with the 31

AT. 32

2.2.2.4 IAS-Session Information Update Response 33

The IAS-Session Information Update Response message is sent by the SRNC in response to the ANRI 34

that sent an IAS-Session Information Update Request message to the SRNC. Refer to section 4.1.1.4, 35

IAS-Session Information Update Response, for the format and content of this message. 36


If the IAS-Session Information Update Request message is received from an ANRI in the route set by the 38

SRNC, then the SRNC shall respond with an IAS-Session Information Update Response message with 39

the fields in the message set as follows: 40


Session Information Update Request message; 42


set to the value of the sender Endpoint ID field in the IAS-Session Information Update Request 44

message; 45

3GPP2 A.S0020-0 v1.0

2-8

• If the Session Signature IE of the IAS-Session Information Update Request message contains the 1

current session signature at the SRNC and the session is not locked, then the Cause IE of the IAS-2

Session Information Update Response message shall be set to ‘Successful event’ and the Session 3

Signature IE of the IAS-Session Information Update Response shall be set to a new session signature 4

for the AT. The SRNC shall store session information for the new session signature and await the 5

confirmation from the AT either through the SessionUpdated message or the IAS-Session 6

Information Request/IAS-SRNC Transfer Request message containing the new session signature. 7

Upon confirmation of new signature, SRNC shall delete the session associated with the old session 8

signature. If the new session signature is never confirmed, the connection is lost and the subsequent 9

access from the AT uses the old session signature, then the SRNC shall discard the new session 10

signature and session information associated with the new session signature; 11

• If the Session Signature IE of the IAS-Session Information Update Request message contains the 12

current session signature at the SRNC but the session is locked, then the Cause IE of the IAS-Session 13

Information Update Response message shall be set to ‘Requested session locked’ and the Session 14

Signature IE of the IAS-Session Information Update Response shall be set to the current session 15

signature for the AT. 16

• If the Session Signature IE of the IAS-Session Information Update Request message does not contain 17

the current session signature at the SRNC, then the Cause IE of the IAS-Session Information Update 18

Response message shall be set to ‘Invalid session signature’ and the Session Signature IE of the IAS-19

Session Information Update Response shall be set to the current session signature for the AT at the 20

SRNC. 21

Upon receipt of the IAS-Session Information Update Response message with ‘Successful event’ Cause IE, 22

the receiving ANRI shall complete session configuration with the AT, i.e., by sending the new session 23

signature included in the Session Signature IE in the IAS-Session Information Update Response message 24

to the AT. The receiving ANRI also stops timer Tsur-ias corresponding to this message. 25

Upon receipt of the IAS-Session Information Update Response message with ‘Requested session locked’ 26

Cause IE, the receiving ANRI stops timer Tsur-ias corresponding to this message and should wait until the 27

new UATI for the AT is received before resending the IAS-Session Information Update Request message 28

to the SRNC identified by the new UATI. 29

Upon receipt of the IAS-Session Information Update Response message with ‘Invalid session signature’ 30

Cause IE, the ANRI shall abort session configuration with the AT. The receiving ANRI also stops timer 31

Tsur-ias corresponding to this message. The receiving ANRI may send an IAS-Session Information 32

Request message to the SRNC to retrieve session information using the updated session signature from 33

the SRNC. 34


If an IAS-Session Information Update Request message is received with any of the following conditions 36

• The AT Identity IE is invalid, e.g., the AT identity is not recognized; 37

• The sending ANRI is not in the Route Set of the AT; 38

then the ANRI responds with an IAS-Session Information Update Response message with the fields in the 39

message set as follows: 40

• The AT Identity IE of the message shall be set to the AT Identity IE in the IAS-Session Information 41

Update Request message; 42

• The sender Endpoint ID shall be set to the ANID of the sender and the receiver Endpoint ID shall be 43

set to the value of the sender Endpoint ID field in the IAS-Session Information Update Request 44

message; 45

• The Cause IE shall be set to ‘Requested session not found’ if the AT Identity IE is invalid, to ‘UATI 46

has changed’ if the ANRI is no longer the session anchor ANRI for the AT, or to ‘Requesting ANRI 47

not in Route Set’ if the sending ANRI is not in the Route Set; 48

• The Correlation ID shall be set to the value received in the corresponding IAS-Session Information 49

Update Request message; 50

3GPP2 A.S0020-0 v1.0

2-9


If an IAS-Session Information Update Request message cannot be accepted for reasons other than what 2

have been specified above then the Cause IE shall be set to ‘Request rejected - reason unspecified’. 3

Upon receipt of the IAS-Session Information Update Response message with ‘Requested session not 4

found’ or ‘Requesting ANRI not in Route Set’ or ‘Request rejected - reason unspecified’ Cause IE, the 5

ANRI shall close the route with the AT. The receiving ANRI also stops timer Tsur-ias corresponding to 6

this message. 7

2.2.2.5 IAS-SRNC Transfer Request 8

The IAS-SRNC Transfer Request message is sent by the target SRNC to the source SRNC to request 9

SRNC transfer. Refer to section 4.1.1.5, IAS-SRNC Transfer Request, for the format and content of this 10

message. 11


When the target SRNC decides to become the SRNC for the AT, the target SRNC sends an IAS-SRNC 13

Transfer Request message to the source SRNC identified by the current UATI of the AT. Refer to [1] on 14

how to derive ANID and IP address of the SRNC from the UATI. The fields in the message shall be set as 15

follows: 16

• The message shall include the current UATI of the AT assigned by the source SRNC, and the SSID of 17

the AT if it is available (e.g., refer to section 3.7.1.2); 18

• The sender Endpoint ID shall be set to the ANID of the target SRNC and the receiver Endpoint ID 19

shall be set to the ANID of the SRNC; 20

• If the target SRNC is also opening a route with the AT, then the RouteOpenRequest IE shall be 21

included and contains information from the RouteOpenRequest message received from the AT and 22

the Session Signature IE shall be included. Otherwise, the RouteOpenRequest IE shall be omitted and 23

the Session Signature IE shall be included and contains the current session signature in the target 24

SRNC; 25

• The New UATI 128 IE shall be included and contains the new UATI to be assigned to the AT. 26




Upon sending the message, the target SRNC starts timer Tstr-ias and awaits arrival of the IAS-SRNC 30

Transfer Response message that has the same Correlation ID as the IAS-SRNC Transfer Request message. 31


If timer Tstr-ias expires, the target SRNC may resend the IAS-SRNC Transfer Request message to the 33

current SRNC and restart timer Tstr-ias an implementation-dependent number of times. The retransmitted 34

IAS-SRNC Transfer Request message shall use the same Correlation ID as the first IAS-SRNC Transfer 35

Request message. If the source SRNC receives the IAS-SRNC Transfer Request message with the same 36

Correlation ID that it has transmitted in the IAS-SRNC Transfer Response message within the Tstr-ias 37

timer period, then it shall respond with the same IAS-SRNC Transfer Response message. 38

If the target SRNC does not receive the IAS-SRNC Transfer Response message, the target SRNC should 39

abort session reference transfer procedure and close the connection with the AT. The source SRNC 40

remains session anchor ANRI. 41

2.2.2.6 IAS-SRNC Transfer Response 42

The IAS-SRNC Transfer Response message is sent by the source SRNC to the target SRNC that sent the 43

IAS-SRNC Transfer Request message to the source SRNC. Refer to section 4.1.1.6, IAS-SRNC Transfer 44

Response, for the format and content of this message. 45

3GPP2 A.S0020-0 v1.0

2-10


2.2.2.6.1.1 SRNC Transfer to ANRI in the current Route Set 2

Upon receipt of the IAS-SRNC Transfer Request message from another ANRI in the Route Set, the 3

source SRNC checks whether any of the following events are in progress: 4

• Access Authentication and Re-authentication; 5

• The IAS-Session Information Update Response message with ‘Successful event’ Cause IE has been 6

sent and the source SRNC is waiting for the Session Updated message from the AT with the new 7

Session Signature; 8

• Session is locked. 9

When none of the above events are in progress, the source SRNC locks the session, i.e., it rejects any 10

further session modification and does not initiate EAP authentication with the AT while locked but still 11

accepts request for a copy of the session and still accepts request to page the AT. The source SRNC also 12

responds with an IAS-SRNC Transfer Response message. The fields in the message shall be set as 13

follows: 14

• The message shall include the new UATI of the AT assigned by the target SRNC, and the SSID; 15

• The sender Endpoint ID shall be set to the ANID of the source SRNC and the receiver Endpoint ID 16

shall be set to the ANID of the target SRNC; 17


• If the value of the Session Signature IE matches with the current session signature at the source 19

SRNC, then the Session State Information Record IE and the Network Session Record IE are omitted. 20

Otherwise, the Session State Information Record IE and the Network Session Record IE are included 21

and shall be set to reflect the latest session information for the AT at the source SRNC; 22

• The DAP Record IE shall be included and is set to include information about DAP on each AGW that 23

the AT communicates with. The Sequence Number field in the IE shall be set to the value of the route 24

counter with MSBs set to zero. Refer to [2]. 25

• The SRNC Record IE shall be included and its fields shall be set as follows: 26

o The UATI field shall be set to the new UATI from the target SRNC. 27

o The value of UATI_SeqNo field shall be incremented by one. 28

o The Session Signature field shall be set to the current session signature of the AT. 29

o The value of the Largest Route Counter field shall be set to the largest RouteCounter from the AT 30

either that the source SRNC has received from the AT or from the previous SRNC. Refer to 31

section 2.2.3.4. 32

o The Access Counter shall be included and set to the value of the current Access Counter. 33

o The Data Capable bit shall be set to ‘0’ when the SRNC is not capable of handling data, 34

otherwise, the Data Capable bit shall be set to ‘1’. 35

• The PMIP Root Key IE shall be included to provide the PMIP signaling message protection key. 36

Upon receipt of the IAS-SRNC Transfer Response message with the ‘Successful event’ Cause IE, the 37

target SRNC stops timer Tstr-ias and shall assign the UATI that was included in the IAS-SRNC Transfer 38

Request message. 39

After the source SRNC sends the IAS-SRNC Transfer Response message, if the source SRNC later 40

receives an IAS-Session Information Request message with the UATI of the source SRNC, an 41

‘Access/Tunneled’ bit set to ‘Access’ and the Route Counter in the RouteOpenRequest IE is greater than 42

the current RouteCounter at the SRNC, then the source SRNC shall unlock the session, accept the request 43

for session by sending an IAS-Session Information Response with the session information, update the 44

current RouteCounter and resume being the SRNC for the AT. The source SRNC also sends an IAS-45

UATI Update message with the fields in the message set as follows: 46

• The UATI in the AT identity IE shall be set to the UATI of the target SRNC received in the IAS-47

SRNC Transfer Request message. 48

• The SRNC Record IE shall contain the UATI of the source SRNC. 49

3GPP2 A.S0020-0 v1.0

2-11

1

2.2.2.6.1.2 SRNC Transfer to outside the current Route Set 2

Upon receipt of the IAS-SRNC Transfer Request message from outside the Route Set, then the source 3

SRNC shall authenticate the RouteOpenRequest IE, i.e., verify that the Authentication Tag included in the 4

message is valid according to [1] Part 008, Route Control Plane. 5

If the RouteOpenRequest IE is successfully authenticated, then the source SRNC shall respond to the 6

target SRNC with an IAS-SRNC Transfer Response message with the fields in the message set as 7

follows: 8

• The message shall include the new UATI of the AT assigned by the target SRNC, and the SSID; 9


set to the value of the sender Endpoint ID field in the IAS-SRNC Transfer Request message; 11


• The IAS DAP Record IE shall contain AGW IP Address, LinkID, DAP Information, GRE key, DAP 13

Time Stamp, PMN-AN-HA1 key, PMN-AN-HA1 Sequence Number value (set to the value of the 14

route counter with MSBs set to zero, and the EAP NAI (refer to [2]) for each AGW to which the AT 15

connects. The EAP NAI field shall be set to the NAI that the SRNC receives as part of the access 16

authentication; 17

• If the Session Signature IE in the received IAS-SRNC Transfer Request message contains a session 18

signature that the SRNC has assigned to the AT but has not received confirmation from the AT yet, 19

then the SRNC shall include the Session State Information Record IE and the Network Session 20

Record IE corresponding to the received Session Signature. Otherwise, the SRNC shall include the 21

Session State Information Record IE and the Network Session Record IE corresponding to the current 22

session signature at the SRNC; 23

• The SRNC Record IE shall be included and its fields shall be set as follows: 24

o The UATI field shall be set to the new UATI from the target SRNC. 25

o The Session Signature field shall be set to the session signature that corresponds to the Session 26

State Information Record IE and the Network Session Record IE; 27

o The value of UATI_SeqNo shall be incremented by one. 28

o The value of the Largest Route Counter field shall be set to the largest RouteCounter from the AT 29

either that the source SRNC has received from the AT or from the previous SRNC. Refer to 30

section 2.2.3.4. 31

o The Access Counter field shall be included for use in IPT-Notification messages as an indication 32

of message freshness. Refer to section 2.2.3.1 for the procedure for maintaining (and 33

incrementing) the Access Counter at the SRNC. 34

o The Data Capable bit shall be set to ‘0’ when the SRNC is not capable of handling data, 35

otherwise, the Data Capable bit shall be set to ‘1’. 36

• The PMIP Root Key IE shall be included to provide the PMIP signaling message protection key. 37

If the SRNC is paging the AT and the Access/Tunneled field in the RouteOpenRequest IE is set to ‘0’ for 38

‘Access’, then the SRNC shall stop paging the AT and enter the active state. 39

Upon receipt of the IAS-SRNC Transfer Response messages, the target SRNC stops timer Tstr-ias and 40

shall assigns a new UATI to the AT along with accepting the RouteOpenRequest from the AT. This 41

UATI shall be the same with the new UATI included in the IAS-SRNC Transfer Request message. The 42

target SRNC shall also store information in the message for future operations. If the Derived MSK7 43

Parameter SSIR is included in the Session State Information Record IE and the included Derived MSK is 44

valid (refer to section 2.2.3.3), then the ANRI shall perform Key Exchange with the AT to establish a 45

secure communication. Otherwise, the ANRI shall use other means, e.g., ERP [2], to exchange 46

7 This SSIR is currently referred to as PMK Parameter SSIR in [1] but will be referred to as Derived MSK Parameter SSIR in

later version of the specification.

3GPP2 A.S0020-0 v1.0

2-12

cryptographic key before securing over-the-air communication using key exchange procedure. Upon 1

receipt of the IAS-Session Information Response message, the receiving ANRI stops timer Tsir-ias 2



If an IAS-SRNC Transfer Request message is received with any of the following conditions: 5

• The AT Identity IE is invalid, i.e., the ANRI is not the session anchor ANRI for the AT identified in 6

the message; 7

• The sending ANRI is not in the Route Set of the AT and RouteOpenRequest IE is not included; 8

• The RouteOpenRequest IE cannot be authenticated, 9

• The included RouteCounter in the message is considered stale by the SRNC. Refer to section 2.2.3.4; 10

then the source SRNC should respond to the target SRNC with an IAS-SRNC Transfer Response message 11

with the fields in the message set as follows: 12

• The AT Identity IE of the message shall be set to be the same as the AT Identity IE in the IAS-SRNC 13

Transfer Request message; 14

• The sender Endpoint ID shall be set to the ANID of the source SRNC and the receiver Endpoint ID 15

shall be set to the value of the sender Endpoint ID field in the IAS-Session Information Request 16

message; 17

• If the Session Anchor Route ID field of the RouteOpenRequest message does not match with the 18

RouteID of the SRNC and the SRNC transfer is pending, then the Cause IE shall be set to ‘Session 19

Anchor Route ID mismatch’ and the current SRNC Record IE (with the new SRNC record) according 20

to the confirmed session signature shall be included. If the AT identity is invalid, the Cause IE shall 21

be set to ‘Requested Session Not Found’ or to Stale message if the RouteCounter in the message is 22

considered stale by the SRNC. Otherwise, the Cause IE shall be set to ‘Authentication Failure’; 23


Upon receipt of the IAS-SRNC Transfer Response message with ‘Session Anchor Route ID mismatch’ 25

Cause IE, the ANRI should resend another IAS-SRNC Transfer Request message based on the SRNC 26

Record IE of the received IAS-SRNC Transfer Response message. The target SRNC also stops timer Tstr-27

ias corresponding to this message. 28

Upon receipt of the IAS-SRNC Transfer Response message with ‘Authentication failure’ Cause IE, the 29

target SRNC shall close the route with the AT. The target SRNC also stops timer Tstr-ias corresponding to 30

this message. 31

If an IAS-SRNC Transfer Request message cannot be accepted for reasons other than what have been 32

specified above then the Cause IE shall be set to ‘Request rejected - reason unspecified’. 33

Upon receipt of the IAS-SRNC Transfer Response message with ‘Requested session not found’, Stale 34

message or ‘Request rejected - reason unspecified’ Cause IE, the ANRI shall close the session with the 35

AT. The receiving ANRI also stops timer Tstr-ias corresponding to this message. 36

Upon receipt of the IAS-SRNC Transfer Request message from another ANRI in the Route Set and any 37

of the following events are in progress: 38

• Access Authentication and Re-authentication; 39

• The IAS-Session Information Update Response message with ‘Successful event’ Cause IE has been 40

sent and the source SRNC is waiting for the SessionUpdated message from the AT with the new 41

Session Signature and the Access/Tunneled flag in the IAS-SRNC Transfer Request is not set to 42

Access; 43

• Session is locked; 44

then the SRNC responds with an IAS-SRNC Transfer Response message with the fields in the message 45

set as follows: 46

3GPP2 A.S0020-0 v1.0

2-13

• The AT Identity IE of the message shall be set to the AT Identity IE in the IAS-SRNC Transfer 1

Request message; 2


set to the value of the sender Endpoint ID field in the IAS-SRNC Transfer Request message; 4

• If the session is locked then the Cause IE shall be set to ‘Requested Session Locked’. Otherwise, the 5

Cause IE shall be set to ‘SRNC busy - Retry later’; 6


Upon receipt of the IAS-SRNC Transfer Response message with ‘SRNC busy - Retry later’ Cause IE, the 8

target SRNC should wait for an implementation specific amount of time before reattempting to transfer 9

SRNC from the source SRNC. The target SRNC also stops timer Tstr-ias corresponding to this message. 10

Upon receipt of the IAS-SRNC Transfer Response message with ‘Requested Session Locked’ Cause IE, 11

the target SRNC should wait for an IAS-UATI Update message indicating a new SRNC before 12

reattempting to move SRNC. 13

2.2.2.7 IAS-Session Release 14

The IAS-Session Release message is sent by an ANRI to another ANRI or DAP to indicate that the UMB 15

session has been released (either AN-initiated or AT-initiated). Refer to 4.1.1.7, IAS-Session Release, for 16

the format and content of this message. 17


2.2.2.7.1.1 Session Release for AT in Connected State 19

When an ANRI has released the UMB session for the AT, it sends an IAS-Session Release message to all 20

ANRIs in the route set and the DAP (if it is not in the route set). For each IAS-Session Release message 21

sent, the ANRI starts an instance of timer Tsr-ias and awaits arrival of the IAS-Session Release Ack 22

message with the same Correlation ID as the IAS-Session Release message. The fields in the message 23

shall be set as follows: 24



set to the ANID of the receiving ANRI; 27

• The Cause Value in the Cause IE shall be set to indicate the reason for the UMB session release. 28

When an ANRI receives an IAS-Session Release message, the ANRI deallocates resources related to the 29

AT and releases the PMIP binding with the AGW if it exists. If the message is received at the DAP, the 30

DAP releases the PMIP binding with the AGW (if it has not already done so). 31

2.2.2.7.1.2 Session Release for AT in Idle State 32

When the SRNC decides to perform UMB session release for an AT in idle state and the DAP is in the 33

eBS, the SRNC sends an IAS-Session Release message to the DAP to release the PMIP binding, starts 34

timer Tsr-ias and awaits arrival of an IAS-Session Release Ack message with the same Correlation ID as 35

the IAS-Session Release message. 36

When the SRNC decides to perform UMB session release for an AT in idle state and the PMIP binding 37

exists between the SRNC and an AGW, the SRNC releases the PMIP binding with AGW. 38

If the IAS-Session Release message was sent to release the UMB session for an AT in idle state for a 39

reason other than expiration of the air interface keep alive timer for timer based registration, the SRNC 40

starts the paging procedure to release the UMB session with the AT. Refer to section 3.2.5 and 3.2.6. 41


If timer Tsr-ias expires, the SRNC may resend the IAS-Session Release message to the ANRI and restart 43

timer Tsr-ias an implementation-dependent number of times. If the IAS-Session Release Ack message is 44

3GPP2 A.S0020-0 v1.0

2-14

not received from the ANRI, the SRNC should cease all operation and clear all context for the AT’s 1

session. 2

2.2.2.8 IAS-Session Release Ack 3

The IAS-Session Release Ack message is sent in response to an IAS-Session Release message. Refer to 4

section 4.1.1.8, IAS-Session Release Ack, for the format and content of this message. 5


Upon receipt of the IAS-Session Release message, the ANRI responds with an IAS-Session Release Ack 7

message. The IAS-Session Release Ack message shall contain the same AT Identity IE and Correlation 8

ID that was received in the IAS-Session Release message. Upon receipt of the IAS-Session Release Ack 9

message, the SRNC stops timer Tsr-ias. The information contained in the IAS-Session Release Ack 10

message shall be set as follows: 11


Session Release message; 13

• The sender Endpoint ID shall be set to the ANID of the ANRI and the receiver Endpoint ID shall be 14

set to the value of the sender Endpoint ID field in the IAS-Session Release message. 15

• The Cause IE of the message shall be set to Successful Event. 16


Upon receipt of the IAS-Session Release message, the ANRI responds with an IAS-Session Release Ack 18

message. If an IAS-Session Release message cannot be accepted for unspecified reasons then the Cause 19

IE shall be set to ‘Request rejected - reason unspecified’. The IAS-Session Release Ack message shall 20

contain the same AT Identity IE and Correlation ID that was received in the IAS-Session Release 21

message. Upon receipt of the IAS-Session Release Ack message, the SRNC stops timer Tsr-ias. The 22

information contained in the IAS-Session Release Ack message shall be set as follows: 23

• The AT Identity IE of the message shall be set to be the same as the AT Identity IE in the IAS 24

Session Release message; 25

• The sender Endpoint ID shall be set to the ANID of the ANRI and the receiver Endpoint ID shall be 26

set to the value of the sender Endpoint ID field in the IAS-Session. 27

• The Cause IE of the message shall be set to Request rejected - reason unspecified’ 28

2.2.2.9 IAS-UATI Update 29

The IAS-UATI Update message is sent by the SRNC to inform all ANRIs in the Route Set and the DAP 30

of the latest information in the SRNC Record IE. Refer to section 4.1.1.9, IAS-UATI Update, for the 31

format and content of this message. 32


2.2.2.9.1.1 UATI Change Operation 34

When an SRNC assigns a new UATI to the AT and has received confirmation from the AT through any 35

of the following events: 36

• The SRNC receives a signaling message confirming the receipt of the new UATI in the AT; 37

• The SRNC receives an IAS-Session Information Request message or IAS-SRNC Transfer Request 38

message with all of the following conditions: 39

o The AT Identity IE containing the new UATI of the SRNC that has been assigned to the AT; 40

o The Route Counter in the RouteOpenRequest IE is larger than the current RouteCounter at the 41

SRNC. 42

Then the SRNC becomes the Session Anchor ANRI for the AT. If the ANRI is the target SRNC, then it 43

unlocks the session for the AT, i.e., UMB session information in the target SRNC can now be changed. 44

3GPP2 A.S0020-0 v1.0

2-15

The SRNC then sends an IAS-UATI Update message to each ANRI in the route set and the DAP (even if 1

DAP is not in the route set). For each IAS-UATI Update message sent, the SRNC starts an instance of 2

timer Tuupd-ias and awaits arrival of the IAS-UATI Update Ack message that has the same Correlation ID 3

as the IAS-UATI Update message. The fields in the IAS-UATI Update message shall be set as follows: 4

• The first AT Identity (SSID) IE of the message shall be set to the SSID of the AT; 5

• The second AT Identity (RATI/UATI) IE of the message shall be set to the old UATI assigned by the 6

source SRNC. If the update is being sent as a result of assigning a UATI to an AT that previously had 7

no UATI, then the RATI shall be sent; 8

• The SRNC Record IE shall contain the new UATI that the SRNC has received confirmation for, from 9

the AT, the current session signature, current RouteCounter, current Access Counter at the SRNC and 10

the new UATI_SeqNo corresponding to the UATI contained in this IE. The UATI_SeqNo shall be 11

larger than the previous UATI_SeqNo by one. The Data Capable bit shall be set to ‘0’ when the 12

SRNC is not capable of handling data, otherwise, the Data Capable bit shall be set to ‘1’. 13

2.2.2.9.1.2 Route Set Add Operation 14

When the SRNC receives RouteMap message from the AT, it checks whether there is a new ANRI in the 15

route set that has not received the most up to date copy of the session from the SRNC. If so, the SRNC 16

sends an IAS-UATI Update message to each new ANRI in the route set. For each IAS-UATI Update 17

message sent, the SRNC starts an instance of timer Tuupd-ias and awaits arrival of the IAS-UATI Update 18

Ack message that has the same Correlation ID as the IAS-UATI Update message. The information 19

contained in the IAS-UATI Update message shall be set as follows: 20

• The first AT Identity (SSID) IE of the message shall be set to the SSID of the AT; 21

• The second AT Identity (RATI/UATI) IE of the message shall be set to the current UATI of the AT; 22


set to the value of the ANID of the recipient of the message; 24

• The SRNC Record IE shall contain the UATI that the SRNC has received confirmation for, from the 25

AT, the current session signature, current RouteCounter, current Access Counter at the SRNC and the 26

new UATI_SeqNo corresponding to the UATI contained in this IE. The Data Capable bit shall be set 27

to ‘0’ when the SRNC is not capable of handling data, otherwise, the Data Capable bit shall be set to 28

‘1’. 29


If timer Tuupd-ias expires, the SRNC may resend the IAS-UATI Update message to the receiver and restart 31

timer Tuupd-ias an implementation-dependent number of times. If the IAS-UATI Update Ack message is 32

not received from the receiver, the sender should close the connection with the AT. 33

2.2.2.10 IAS-UATI Update Ack 34

The IAS-UATI Update Ack message is sent by an ANRI or the DAP to the SRNC that sent the IAS-35

UATI Update message. Refer to section 4.1.1.10, IAS-UATI Update Ack, for the format and content of 36

this message. 37


Upon receipt of the IAS-UATI Update message, the ANRI or the DAP responds with an IAS-UATI 39

Update Ack message. The IAS-UATI Update Ack message shall contain the UATI of the AT assigned by 40

the target SRNC, the SSID and the same Correlation ID that was received in the IAS-UATI Update 41

message. The receiving ANRI or the DAP also checks whether the UATI_SeqNo contained in the IAS-42

UATI Update message is greater than the UATI_SeqNo associated with the current UATI for the AT at 43

the ANRI or the DAP. 44

If the received UATI_SeqNo is greater than the existing UATI_SeqNo, the receiving ANRI or the DAP 45

updates the UATI and UATI_SeqNo for the AT. If the received session signature is different from the 46

current session signature at the ANRI or the DAP, the ANRI or the DAP shall request session information 47

3GPP2 A.S0020-0 v1.0

2-16

associated with the new session signature. Refer to section 4.1.1.1. If the receiving ANRI is the source 1

SRNC, then it is no longer the SRNC for the AT and can close its route with the AT when appropriate. 2

If the received UATI_SeqNo is not greater than the existing UATI_SeqNo, the receiving ANRI or the 3

DAP ignores the received SRNC Record IE. 4

Upon receipt of the IAS-UATI Update Ack message, the SRNC stops timer Tuupd-ias corresponding to 5

this message. 6


If an eBS receives an IAS-UATI Update message from outside the AT’s route set or with an invalid AT 8

Identity IE, the receiving eBS may send an IAS-UATI Update Ack with a Cause value indicating ‘AT not 9

recognized’. 10

Upon receipt of the IAS-UATI Update Ack message, the SRNC stops timer Tuupd-ias corresponding to 11

this message. 12

2.2.2.11 IAS-Paging Request 13

The IAS-Paging Request message is sent from the DAP to the SRNC to request the recipient to initiate a 14

paging procedure for an AT. Refer to section 4.1.1.11, IAS-Paging Request, for the format and content of 15

this message. 16


When the DAP has a PMIP binding in idle state with the AT and is triggered to page the AT (either by 18

receiving data for the AT from the AGW or by receiving a Data Notification message that AGW has data 19

for the AT), it sends an IAS-Paging Request message to the SRNC. The DAP starts timer Tpgack-ias and 20

awaits arrival of the IAS-Paging Request Ack message with the same Correlation ID as the IAS-Paging 21

Request message. The information contained in the IAS-Paging Request message shall be set as follows: 22


• The sender Endpoint ID shall be set to the ANID of the DAP and the receiver Endpoint ID shall be 24


• The Paging Control Record IE shall set the Local Fanout Required bit to ‘0’. 26


If timer Tpgack-ias expires, the DAP may resend the IAS-Paging Request message to the SRNC and restart 28

timer Tpgack-ias an implementation-dependent number of times. If the IAS-Paging Request Ack message 29

is not received from the SRNC, the DAP should stop attempting to page the AT for an implementation-30

dependent timer. 31

32

2.2.2.12 IAS-Paging Request Ack 33

The IAS-Paging Request Ack message is sent in response to an IAS-Paging Request message. Refer to 34

section 4.1.1.12, IAS-Paging Request Ack, for the format and content of this message. 35


Upon receipt of the IAS-Paging Request message, the SRNC responds with an IAS-Paging Request Ack 37

message. The IAS-Paging Request Ack message shall contain the same AT Identity IE and Correlation ID 38

that was received in the IAS-Paging Request message. The information contained in the IAS-Paging 39

Request Ack message shall be set as follows: 40

• The AT Identity IE of the message shall be set to the AT Identity IE in the IAS-Paging Request 41

message; 42

3GPP2 A.S0020-0 v1.0

2-17

• The sender Endpoint ID shall be set to the ANID of the sending ANRI and the receiver Endpoint ID 1

shall be set to the value of the sender Endpoint ID field in the IAS-Paging Request message; 2

• The Page Attempt Timer IE shall be set to the duration that the SRNC will attempt to page the AT. 3

• The Cause Value shall be set to 01H for a successful processing of the page request or 09H if the AT 4

to be paged is not recognized, or 0EH if the AT has performed Power Down Registration and has not 5

accessed back. 6

Upon receipt of the IAS-Paging Request Ack message, the DAP stops timer Tpgack-ias. The DAP also 7

starts timer Tpgreq-ias based on the value of the Page Attempt Timer IE to await the arrival of a response to 8

this paging request (i.e., an IPT-Notification message from the FLSE). The DAP should not attempt to 9

send another IAS-Paging Request message to the SRNC for this AT if subsequent data arrives, until after 10

timer Tpgreq-ias expires. If the timer Tpgreq-ias expires, then the DAP should discard any stale data and 11

should send IAS-Paging Request message to SRNC again if new data arrives for the AT. If the Cause IE 12

value in the IAS-Paging Request Ack message is ‘0EH - Power Down’, the DAP should cease sending 13

more IAS-Paging Request message to the SRNC for this AT. If the Cause IE value in the IAS-Paging 14

Request Ack message is ‘09H - AT not recognized’, the DAP should initiate PMIP tunnel release 15

procedures (refer to section 2.5.1.5). 16


If an IAS-Paging Request message cannot be accepted then the Cause IE shall be set to ‘Request rejected 18

- reason unspecified’. The receiver and the sender shall stop paging related procedures after 19

receiving/sending IAS-Paging Request Ack with the above mentioned cause value. 20

2.2.2.13 IAS-Page 21

The IAS-Page message is sent to request the recipient to initiate a paging procedure for an AT. Refer to 22

section 4.1.1.13, IAS-Page, for the format and content of this message. 23


When the SRNC is triggered to page the AT (either by receiving a data notification from the AGW or by 25

receiving an IAS-Paging Request message from the DAP and the AT has not performed power down 26

registration), it sends an IAS-Page message to one or more eBS in the paging area, and awaits arrival of 27

the IAS-Session Information Request message. 28

The SRNC has two options for selecting the set of eBSs to which the IAS-Page message is sent. 29

If the SRNC determines the paging area of the AT based on the eBS from which the AT performed the 30

last registration (LastRegistered-eBS), then the SRNC should send the IAS-Page message to all eBSs that 31

are within a paging area around the LastRegistered-eBS. The determination of the paging area is outside 32

the scope of this specification, and may depend on the RegistrationRadius used by the AT, or the 33

registration zones used in the deployment. This option is called “Central Fanout”. 34

If the SRNC decides to have the LastRegistered-eBS determine the paging area of the AT, then the SRNC 35

should send the IAS-Page message to the LastRegistered-eBS, where the LastRegistered-eBS is 36

responsible for forwarding the message to eBSs in the appropriate paging area. This option is called 37

“Local Fanout”. 38

The information contained in the IAS-Page message shall be set as follows: 39




• The Paging Control Record IE shall set the Local Fanout Required bit to ‘1’ if Local Fanout is 43

required, and to ‘0’ otherwise. 44

• The AIS Paging Information Record IE shall include the parameters required at the receiving eBS to 45

page the AT. Refer to Annex A; 46

3GPP2 A.S0020-0 v1.0

2-18

• If the SRNC is being transferred and the new UATI has not been confirmed, the SRNC shall include 1

the new UATI128 IE; 2

Upon sending the IAS-Page message with Local Fanout Required bit set to ‘1’, the SRNC starts timer 3

Tpgack-ias and awaits arrival of the IAS-Page Ack message with the same Correlation ID as the IAS-Page 4

message. 5

Upon receipt of the IAS-Page message, the eBS shall page the AT based on the included AIS Paging 6

Information Record IE and information in Paging Control Record IE. 7

Upon receipt of the IAS-Page message with the Local Fanout Required bit equal to ‘1’, the receiving eBS 8

shall determine the paging area to be used based on the AIE Paging Information Record IE that is 9

included in the IAS-Page message, and shall forward the IAS-Page message to eBSs in the paging area. 10

The forwarded message shall have the Local Fanout bit in the Paging Control Record IE set to ‘0’ and the 11

sender Endpoint ID shall be set to the ANID of the sending eBS. 12


If the SRNC does not receive the IAS-Session Information Request or IAS-SRNC Transfer Request 14

message for the AT, the SRNC may send new IAS-Page messages to one or more eBSs. The SRNC 15

should stop attempting to page the AT after an implementation-dependent timer which should be equal or 16

greater than the value included in the Page Attempt Timer IE in the IAS-Paging Request Ack message, if 17

sent. 18

If Local Fanout is used and the timer Tpgack-ias expires, then the SRNC should resend the IAS-Page 19

message. If the IAS-Page Ack is not received after a certain number of retries, then the eBS performing 20

the local fanout may be unreachable. In this case, the SRNC may initiate recovery procedures such as 21

paging over a wide area. 22

If the IAS-Page message was triggered by PMIP binding release with the AGW and the SRNC 23

determines that the page procedure has failed, the SRNC may perform any of the following actions (i) 24

resend the IAS-Page message, (ii) abort page procedure but keep the UMB session, or (iii) abort page 25

procedure and release the UMB session. 26

2.2.2.14 IAS-Page Ack 27

The IAS-Page Ack message is sent in response to an IAS-Page message when local fanout is required. 28

Refer to section 4.1.1.14, IAS-Page Ack, for the format and content of this message. 29


Upon receipt of the IAS-Page message with Local Fanout Required bit, the eBS responds with an IAS-31

Page Ack message. The IAS-Page Ack message shall contain the same AT Identity IE and Correlation ID 32

that was received in the IAS-Page message. The information contained in the IAS-Page Ack message 33


• The AT Identity IE of the message shall be set to the AT Identity IE in the IAS-Page message; 35

• The sender Endpoint ID shall be set to the ANID of the sending ANRI and the receiver Endpoint ID 36

shall be set to the value of the sender Endpoint ID field in the IAS-Page message; 37

• The Cause Value shall be set to 01H for a successful processing of the page request. 38

Upon receipt of an IAS-Page Ack message that is sent in response to an IAS-Page message, the SRNC 39

stops timer Tpgack-ias. 40


None. 42

43

3GPP2 A.S0020-0 v1.0

2-19

2.2.2.15 IAS-Neighbor Discovery Request 1

The IAS-Neighbor Discovery Request message may be sent to initiate neighbor discovery procedures. 2

Refer to section 4.1.1.15, IAS-Neighbor Discovery Request, for the format and content of this message. 3


When an eBS or SRNC determines that it requires neighbor discovery information from another eBS (e.g., 5

an AT reports a Pilot ID that is not recognized by the eBS or SRNC) it may send an IAS-Neighbor 6

Discovery Request message to the neighboring eBS. The sending eBS or SRNC starts timer Tndrpt-ias and 7

awaits arrival of the IAS-Neighbor Discovery Report message that has the same Correlation ID as the 8

IAS-Neighbor Discovery Request message. The fields in the IAS-Neighbor Discovery Request message 9



set to the value of the ANID of the recipient of the message. 12


If timer Tndrpt-ias expires, the eBS or SRNC may resend the IAS-Neighbor Discovery Request message to 14

the receiver and restart timer Tndrpt-ias an implementation-dependent number of times. If the IAS-15

Neighbor Discovery Report message is not received from the receiver, the sender ceases attempting 16

neighbor discovery procedures with the receiver. 17

If the ANRI cannot contact the neighbor using the IP address provided, for an implementation specific 18

amount of time, it should discard that neighbor information. 19

2.2.2.16 IAS-Neighbor Discovery Report 20

The IAS-Neighbor Discovery Report message is sent in response to an IAS-Neighbor Discovery Request 21

message or it may be sent unsolicited. Refer to section 4.1.1.16, IAS-Neighbor Discovery Report, for the 22



When an eBS receives a request for neighbor discovery or it chooses to send an unsolicited update of its 25

own neighbor information, it sends an IAS-Neighbor Discovery Report message to the neighbor ANRI. 26

The receiving eBS or SRNC stops timer Tndrpt-ias if it is running. 27

If the eBS sends an unsolicited IAS-Neighbor Discovery Report message to an eBS or SRNC it starts 28

timer Tndrptack-ias and awaits arrival of the IAS-Neighbor Discovery Report Ack message that has the 29

same Correlation ID as the IAS-Neighbor Report message. 30

The fields in the IAS-Neighbor Discovery Report message shall be set as follows: 31



• The ANRI shall include its Neighbor Discovery Information, including interface protocol revisions 34

supported and neighbor ANID information; 35

• The eBS shall include its SectorParameters message from every sector under this eBS in the Sector 36

Parameters IE. 37


If timer Tndrptack-ias expires, the eBS may resend the unsolicited IAS-Neighbor Discovery Report 39

message to the receiver and restart timer Tndrptack-ias an implementation-dependent number of times. If 40

the IAS-Neighbor Discovery Report Ack message is not received from the receiver, the sender ceases 41

attempting neighbor discovery procedures with the receiver. 42

3GPP2 A.S0020-0 v1.0

2-20

2.2.2.17 IAS-Neighbor Discovery Report Ack 1

The IAS-Neighbor Discovery Report Ack message is sent in response to an unsolicited IAS-Neighbor 2

Discovery Report message. Refer to section 4.1.1.17, IAS-Neighbor Discovery Report Ack, for the 3



Upon the receipt of an unsolicited IAS-Neighbor Discovery Report message the eBS or SRNC responds 6

with a IAS-Neighbor Discovery Report Ack message. The IAS-Neighbor Discovery Report Ack message 7

shall contain the same Correlation ID that was sent in the IAS-Neighbor Discovery Report message. 8

The receiving eBS stops timer Tndrptack-ias. 9

The fields in the IAS-Neighbor Discovery Report Ack message shall be set as follows: 10




None 14

2.2.2.18 IAS-Reject 15

The IAS-Reject message is sent in response to an IAS message that can not be properly processed or has 16

an unrecognized version in the IAS Message Type IE. Refer to section 4.1.1.18, IAS-Reject, for the 17



When an eBS/SRNC receives an IAS message that can not be properly processed, the eBS/SRNC may 20

respond with an IAS-Reject message. When an eBS/SRNC receives an IAS message with an 21

unrecognized version in the IAS Message Type IE, the eBS/SRNC shall respond with an IAS-Reject 22

message. The IAS-Reject message version shall be recognized as 00H. Refer to 1.7. The IAS-Reject IEs 23

in the message shall be set as follows: 24



• The Cause IE shall be included and set to the reason for the reject. 27

• The IAS Reject Record IE shall include the rejected message and if the Cause IE is set to “Reject - 28

version not supported” it shall also include all versions supported by the sending eBS/SRNC. 29

When an eBS/SRNC receives an IAS-Reject message from another eBS/SRNC, it should stop 30

retransmission of the rejected message, stop any timer(s) running and address operations pending the 31

message that was rejected. The receiving eBS/SRNC may also use the IAS Reject Record IE to determine 32

an acceptable version for sending messages to this entity. 33


None. 35

2.2.3 IAS Interface Protocol Procedures 36

2.2.3.1 Procedure for Maintaining the Access Counter 37

The Access Counter is incremented by the SRNC for each connection set up from the AT. The access 38

counter is made available to each eBS that is in the Route Set of the AT and is included in every IPT-39

Notification message. Both the eBS and the SRNC receiving the IPT-Notification can check the Access 40

Counter in the IPT-Notification message with the value of the Access Counter for the existing connection. 41

The IPT-Notification message with a non-matching Access Counter value shall be rejected. 42

3GPP2 A.S0020-0 v1.0

2-21

The procedure for maintaining Access Counter in the SRNC is as follows: 1

1. Access Counter (16 bits) is part of the SRNC Record and is given to each new ANRI during Route 2

Set Add procedure. The value of the Access Counter shall be reset to zero once it has reached the 3

maximum value and needs to be incremented further. 4

2. Access Counter shall be initialized to zero when the UMB session is created for the AT. 5

3. Access Counter shall incremented by one by the SRNC on any of the following conditions 6

a. The SRNC receives either 7

• an IAS-Session Information Request message with a RouteOpenRequest IE and the 8

Access/Tunneled flag set to Access and the SRNC responds with an IAS-Session Information 9

Response message with the ‘Successful event’ cause value. 10

• an IAS-SRNC Transfer Request message with a RouteOpenRequest IE and the 11

Access/Tunneled flag set to Access and the SRNC responds with an IAS-SRNC Transfer 12

Response message with the ‘Successful event’ cause value. 13

b. During SRNC transfer, this condition applies to either the source or the target SRNC. 14

c. The AT directly accesses an eBS/SRNC8. 15

The procedure for maintaining Access Counter in a non-Session Anchor ANRI is as follows: 16

1. The ANRI that is not the Session Anchor ANRI shall store the Access Counter received from the 17

SRNC when the ANRI was added into the Route Set or when the ANRI was the Session Anchor 18

ANRI. 19

2. The ANRI that is not the Session Anchor ANRI shall not modify the value of its Access Counter. 20

2.2.3.2 Procedure for Including Derived MSK Parameter SSIR 9 in the Session State 21

Information Record IE 22

The Derived MSK Parameter SSIR shall be included in the Session State Information Record IE in an 23

IAS message by the SRNC and is set according to [2]-100 if all of the following conditions are true: 24

• The SRNC has a new Derived MSK for the receiving ANRI, i.e., the Derived MSK that has not been 25

sent to the receiving ANRI before. 26

• The Session State Information Record IE is included in the message. 27

• One of the following condition is true: 28

o EAP Fast Reauthentication is not supported at the receiving ANRI, i.e., 29

InitiateEAPFastReauthentication attribute indicates that access terminal will not initiate EAP Fast 30

Reauthentication when Route Open is initiated. 31

o The Derived MSK Required Flag in the IAS-Session Information Request or IAS-SRNC Transfer 32

Request flag are set to ‘1’. 33

2.2.3.3 Procedure for Determining whether the Derived MSK is Valid 34

When an ANRI receives Derived MSK Parameter SSIR from the SRNC, the included Derived MSK in 35

the Derived MSK Parameter SSIR is valid, i.e., the ANRI can use the included key for over-the-air 36

security if all of the following conditions are true: 37

• The ValidDerivedMSKExists field is set to ‘1’. 38

• The current time at the ANRI is less than the DerivedMSKExpiryTime field10 for the Derived MSK. 39

8 Access Based Handoff does not cause the Access Counter to be incremented.

9 This SSIR is currently referred to as PMK Parameter SSIR in [1] but will be referred to as Derived MSK Parameter SSIR in later version of the specification.

3GPP2 A.S0020-0 v1.0

2-22

2.2.3.4 Procedure for Maintaining the Route Counter 1

The route counter is used for two purposes. 2

First, the route counter of an ANRI serves as a nonce in derivation of the derived MSK and PMN-AN-3

HA1 key. Each ANRI shall store the route counter it receives in the RouteOpenRequest message from the 4

AT when the ANRI is created. This route counter value shall be included in the IAS-Session Information 5

Request and IAS-SRNC Transfer Request messages. 6

Second, the highest route counter at the SRNC is used to detect whether or not a RouteOpenRequest from 7

the AT is stale. The procedure for maintaining the highest route counter is as follows: 8

1. For every successful IAS-Session Information Request or IAS-SRNC Transfer Request message with 9

a tunneled flag, the SRNC stores the route counter value in the message as the new highest route 10

counter value if the received value is greater than the existing value. Note that the comparison shall 11

be made subject to possible wraparound of the route counter. 12

2. If the IAS-Session Information Request or IAS-SRNC Transfer Request message is received with an 13

access flag, and the route counter value in the message is considered stale when compared to the 14

highest route counter value at the SRNC, the SRNC should respond with cause value ‘Stale message’. 15

2.2.3.5 Procedure for Maintaining the Session Signature 16

The session signature is generated by the SRNC after each session information update. The procedure for 17

maintaining session signature in the SRNC is as follows: 18

1. When an ANRI assigns a UATI to the AT so the ANRI becomes the Session Anchor ANRI, the 19

ANRI shall set the session signature to the last received SessionSignature field, e.g., in the IAS-20

Session Information Response message. 21

2. When the SRNC receives SessionUpdated message from the AT, 22

a. The SRNC shall update its session signature to the value received in the message if the SRNC has 23

previously assigned the session signature in an IAS-Session Information Update Response 24

message. 25

b. The SRNC shall close the UMB session if the SessionUpdated message is received from the AT 26

containing an unrecognized session signature, i.e., neither the pending session signature in IAS-27

Session Information Update Response message nor the current session signature. 28

3. When the SRNC receives a valid IAS-Session Information Update Request message, the SRNC shall 29

store new session information associated with the updated session and shall assign a new session 30

signature in the IAS-Session Information Update Response message. 31

a. The SRNC shall not use the new value of session signature until it receives confirmation that the 32

AT has received new session signature, i.e., SessionUpdated message or an IAS-Session 33

Information Request/IAS-SRNC Transfer Request message with access flag, an incremented 34

route counter, and the new session signature. 35

b. If the SRNC receives an IAS-Session Information Request/IAS-SRNC Transfer Request message 36

with access flag, an incremented route counter, and the current session signature, then the SRNC 37

shall purge the new session signature and the associated update session. 38

The procedure for maintaining session signature in a non-Session Anchor ANRI is as follows: 39

1. When the route is being opened, the ANRI shall set the session signature to the SessionSignature field 40

in the RouteOpenRequest message from the AT. 41

2. The ANRI shall update its session signature to the value received in the following messages. 42

10 This field does not exist in PMK Parameter SSIR in [1] but will be included in later version of the specification. The value

of this field is equivalent to GenerationTime + MaxLifetime of the key.

3GPP2 A.S0020-0 v1.0

2-23

a. SessionUpdated message from the AT 1

b. IAS-UATI Update from the SRNC 2

The ANRI shall also trigger session information retrieval using IAS-Session Information Request 3

message upon receipt of the new session signature in the above messages unless it already has the session 4

information associated with the new session signature. 5

3. The ANRI shall update its session signature to the value received in the following messages. 6

a. IAS-Session Information Response from the SRNC 7

b. IAS-SRNC Transfer Response from the SRNC 8

The ANRI shall not trigger session information retrieval using IAS-Session Information Request message 9

upon receipt of the new session signature in the above messages. 10

11

2.2.3.6 Exclusive Control of Session State Information Record 12

The SRNC maintains the master copy of session state information record of the UMB session. The SRNC 13

grants change privilege for a session state information record on an exclusive basis to achieve the 14

following: 15

• Avoid modifying session state information record during SRNC transfer and 16

• Avoid performing SRNC transfer during access authentication 17

18

The SRNC uses two states to perform exclusive control: unlock state and lock state. 19

2.2.3.6.1 Unlock State 20

In unlock state, the SRNC is allowed to modify session state information record and is allowed to perform 21

SRNC transfer. Unlock state is the initial state of the SRNC when the UMB session is created. 22

SRNC enters unlock state when; 23

• Access authentication is completed, 24

• (Source) SRNC receives a message with access indication, or 25

• (Target) SRNC completes UATI assignment procedure. 26

2.2.3.6.2 Lock State 27

In lock state, SRNC rejects any modification to session state information record and does not initiate 28

access authentication. 29

SRNC enters lock state when; 30

• SRNC is performing access authentication, 31

• (Source) SRNC starts SRNC transfer procedure (i.e., source SRNC receives an IAS-SRNC Transfer 32

Request and accepts it), or 33

• (Target) SRNC requests SRNC transfer procedure (i.e., target SRNC sends an IAS-SRNC Transfer 34

Request). 35

36

2.3 IPT (IP Tunneling) Interface 37

For this revision of the specification, the version number for the IPT interface is 01H. 38

This interface allows for tunneling of user IP packets between eBSs for an AT. The interface comprises of 39

two parts. The first part called the IPT signaling interface is part of the U2 and U3 reference points which 40

3GPP2 A.S0020-0 v1.0

2-24

carries the signaling messages necessary to notify and redirect tunneled traffic based on the mobility of 1

the AT. The second part called the IPT data interface is part of the U3 reference point which encapsulates 2

the tunneled user IP packets to be transmitted between eBSs. 3

2.3.1 IPT Interface Network/Transport Protocol Specification 4

The UMB IOS protocol stack for the IPT signaling interface is defined as follows. 5

IOS Application UDP

IP

The underlying physical transport medium under IP is left to the discretion of operators and manufact-6

urers. The following UDP port value is reserved for signaling on the IPT interface: 7

• IPT 4593/udp - This is the registered UDP port number to be used for signaling interconnection of IP 8

tunnels between ANRIs on the U2 and U3 reference points. 9

The UMB IOS protocol stack for the IPT data interface is defined as follows. 10

Encapsulated User IP datagram L2TPv3

IP


urers. IPT data message is comprised of an outer IP header (for routing purpose between source and 12

destination), a four octet L2TPv3 main header (refer to [I-1]), an L2TPv3 sub-layer header and the 13

encapsulated user IP datagram. 14

Identification of port usage for specific messages is identified in Table 2.3.5-1. 15

16

2.3.2 IPT data L2TPv3 Headers 17

The L2TPv3 header for IPT data interface is defined as follows. 18

IPT data interface L2TPv3 Header

7 6 5 4 3 2 1 0 Octet

(MSB) Session ID = 55 4D 42 34H (IPv4) or 55 4D 42 36H (IPv6) 1

… … (LSB) 4

where: 19

Session ID11: This is a 32-bit field set to 55 4D 42 34H if the encapsulated packet is IPv4. This field is 20

set to 55 4D 42 36H if the encapsulated packet is IPv612. 21

The IPT data L2TPv3 sub-layer header follows immediately after the L2TPv3 header and is defined as 22

follows. 23

11 The Session ID ’55 4D 42 31H’ is ASCII representation of ‘UMB1.

12 The Session ID ’55 4D 42 34H’ and ’55 4D 42 36H’ are ASCII representations of ‘UMB4’ and ‘UMB6’, respectively.

3GPP2 A.S0020-0 v1.0

2-25

IPT data interface L2TPv3 Sub-layer Header

7 6 5 4 3 2 1 0 Octet

Version Reserva-tion

Valid

Direction AGW IP Addr. Ver.

(MSB) L2TPv3 TTL

(LSB) 1

Reservation Label 2

Reserved = 00000 FLSE Forwarde

d

DAP Counter 3

IF (AGW IP Address Version = ‘0’) {1:

(MSB) AGW IPv4 Address 4

… …

(LSB) 7

} ELSE IF (AGW IP Address Version = ‘1’) {1:

(MSB) AGW IPv6 Address 4

… …

(LSB) 19

} END IF

(MSB) AGW Mobile Key j

… …

(LSB) j+3

(MSB) CRC k (LSB) k+1

where: 1

Version This is a 3-bit field which identifies the version of the header. For this 2

revision this field is set to ‘01’. 3

Reservation Valid This is a 1-bit field which is set to ‘1’ if the Reservation Label associated 4

with the Encapsulated Packet is available. Otherwise this field is set to 5

‘0’. 6

Direction This is a 1-bit field which is set to ‘1’ if the encapsulated user IP 7

datagram is from RL or ‘0’ if the encapsulated user IP datagram is for FL 8

direction. 9

AGW IP Address Version This is a 1-bit field which is set to ‘0’ if the AGW address field contains 10

an IPv4 address or ‘1’ if the AGW address field contains an IPv6 11

address. 12

L2TPv3 TTL This is a 3-bit field which is set to the time to live for the packets in 13

number of eBS hops. 14

Reservation Label If the Reservation Valid field is set to ‘1’, then this field contains the 15

reservation label for QoS treatment of tunneled packets as defined in [1]. 16

Otherwise, this field shall be set to zero and ignored by the receiving 17

entity. 18

3GPP2 A.S0020-0 v1.0

2-26

FLSE Forwarded If the sender of the L2TPv3 packet is the previous FLSE of the AT 1

forwarding to the current FLSE of the AT, then this bit shall be set to ‘1’. 2

Otherwise, this bit shall be set to ‘0’. 3

DAP Counter This is a 2-bit field which is set to the number that represents the identity 4

of the DAP. This number is incremented at every DAP handoff. This 5

field shall be set to ‘00’ by the sender and ignored by the receiver for 6

reverse-link packets. 7

AGW Address This field is set to the 32-bit IPv4 address of AGW associated with the 8

encapsulated user IP datagram if the IP Version field is set to ‘0’ or the 9

128-bit IPv6 address of the AGW associated with the encapsulated user 10

IP datagram if the IP Version field is set to ‘1’. This field shall be set to 11

U-plane IP endpoint of the AGW. 12

AGW Mobile Key This field is set to the 32-bit GRE Key (refer to [13]) assigned by the 13

AGW for this AT. 14

CRC This field is set to the 16-bit CRC covering the L2TPv3 header and 15

L2TPv3 sub-layer header preceding and not including this field and is 16

computed using the method specified for FCS-16 in [4]. 17

18

2.3.3 IPT Interface Network/Transport Protocol Procedure 19

2.3.3.1 IPT Packet Tunneling Operations 20

2.3.3.1.1 GRE packet is Received from the AGW while the AT is active 21

When an eBS receives a GRE packet from the AGW and the eBS is the FLSE, then the eBS buffers the 22

encapsulated IP packet and associated information in the GRE header and schedules transmission of the 23

encapsulated IP packet over-the-air using its own ANRI. 24

When an eBS that is not the FLSE receives a GRE packet or has a buffered GRE packet from the AGW, 25

then the eBS shall tunnel the packet through IPT or LLT to the FLSE, if known, or else through IPT to the 26

DAP. All of the following conditions shall be true in either case: 27

• If the packet is being forwarded to the FLSE, the LinkID of the FLSE is the same as the LinkID of 28

this eBS or if the packet is being forwarded to the DAP, the LinkID of the DAP is the same as the 29

LinkID of this eBS. The same LinkID implies that both the eBS and the FLSE/DAP routes are bound 30

to the same IP interface at the AT; 31

• AT is not idle, e.g., connection with the AT is not closed. 32

The IPT L2TPv3 sublayer header shall be set as follows: 33

1. The AGW IP Address Version field and the AGW Address field shall be set based on the IP Address 34

type and the AGW U-plane IP Address of the AGW that sent the GRE packet; 35

2. The AGW Mobile Key field shall be set to the value of the GRE key from the GRE header; 36

3. The L2TPv3 TTL field shall be set to an implementation-specific non-zero value; 37

4. The Direction field shall be set to zero, i.e., indicating that this is a forward-link packet. 38

5. The sender may set the Reservation Label field to the Reservation Label corresponding to the 39

encapsulated IP packet. 40

6. If the sender is the previous FLSE for the AT forwarding the packet to the current FLSE, then the 41

FLSE Forwarded bit shall be set to one. Otherwise, it shall be set to zero. 42

7. The sender shall include its DAP Counter value in the DAP Counter field. Refer to section 2.3.4.1. 43

3GPP2 A.S0020-0 v1.0

2-27

The Encapsulated User IP Packet field shall be set to the IP packet encapsulated in the received GRE 1

packet. The ToS field of the outer IP header should replicate the ToS value in the inner IP header. The 2

ToS field of the outer IP header may also be set based on local policy. 3

If the LinkID of the FLSE is different from the LinkID of this eBS, this implies the FLSE is connected to 4

a new AGW with a different IP interface to the AT. In this case the eBS shall process all remaining data 5

received from the old AGW and send it to the FLSE over LLT, which will result in the data being 6

processed at the AT using the corresponding IP interface to the AGW. Refer to section 2.4. 7

2.3.3.1.2 Forward-link IPT Packet is Received while the AT is active 8

When a forward-link IPT packet is received and the eBS is the FLSE, then the eBS buffers the IPT packet 9

and schedules transmission of the encapsulated IP packet over-the-air using its own ANRI. The receiving 10

eBS may use the included Reservation Label to determine the QoS treatment of the tunneled packet if the 11

Reservation Valid bit is set to ‘1’. The receiving eBS may use the included FLSE Forwarded bit and the 12

DAP Counter value to determine the priority of the IP packets to be scheduled for transmissions on flows 13

that require in-order delivery. 14

When an IPT packet is received at an eBS or when an eBS that is not the FLSE has a buffered IP packet 15

received from another eBS, the eBS shall generate an IPT packet and send the generated IPT packet to the 16

FLSE if all of the following conditions are true: 17

• The receiving eBS is not the FLSE; 18

• The Direction field in the received IPT packet is set to zero, i.e., forward-link; 19

• The eBS has the same LinkID as the FLSE; 20

• The L2TPv3 TTL field of the received IPT packet is non-zero; 21

• Connection with the AT is not closed. 22

The new IPT packet will contain the same IPT L2TPv3 sub-layer header as the original IPT packet, with 23

the exception of the L2TPv3 TTL field which shall be decremented by one before being transmitted and 24

the CRC field shall be recalculated according to the decremented L2TPv3 TTL field. The ToS field of the 25

outer IP header should replicate the ToS value in the IP inner header. The ToS field of the outer IP header 26

may also be based on local policy. 27

If the LinkID of the FLSE is different from the LinkID of this eBS, this implies the FLSE is connected to 28

a new AGW with a different IP interface to the AT. In this case the eBS shall process all remaining data 29

received from the old AGW and send it to the FLSE over LLT, which will result in the data being 30

processed at the AT using the corresponding IP interface to the AGW. Refer to section 2.4. 31

If the L2TPv3 TTL field of the received IPT packet is zero and the eBS is not the FLSE, then the packet 32

shall be discarded. 33

If the CRC field of the received IPT packet does not match with the CRC calculated from the header by 34

the receiving eBS, then the packet shall be discarded. 35

2.3.3.1.3 Forward-link Packet is Received either through GRE or IPT while the AT is Idle 36

If the connection with the AT is closed, then the eBS should send each buffered IP packet to the DAP 37

with the IPT L2TPv3 sublayer header of each packet as described in section 2.3.3.1.1 and section 38

2.3.3.1.2. If the eBS is the DAP, then the eBS shall initiate paging procedure with the SRNC. Refer to 39

section 2.2. 40

2.3.3.1.4 Reverse-link IP Packet is Received 41

When an IP packet is received at an eBS on the UMB reverse-link and the eBS can tunnel packet back to 42

the AGW, the eBS shall send the packet to the AGW through PMIP tunnel. 43

3GPP2 A.S0020-0 v1.0

2-28

When an IP packet is received at an eBS on the UMB reverse-link and the receiving eBS cannot send the 1

IP packet back to the AGW through PMIP tunnel, the eBS shall generate an IPT packet and send the 2

generated IPT packet to the eBS that is DAP for this LinkID. In this case, the IPT L2TPv3 sub-layer 3

header from the eBS to the DAP shall be set as follows: 4

• The AGW IP Address Version field and the AGW U-plane IP Address field shall be set based on the 5

AGW address associated with the AT; 6

• The AGW Mobile Key field shall be set to the value of the GRE key associated with the AT; 7

• The L2TPv3 TTL field shall be set to implementation-specific non-zero value; 8

• The Direction field shall be set to one, i.e., indicating that this is a reverse-link packet. 9

• The Reservation Valid bit shall be set to zero and the Reservation Label field shall be set to zero. 10

The ToS field in the IP inner header may be set by the first eBS receiving the packet from the AT based 11

on the Subscriber QoS profile. This value should be replicated in the outer IP header. 12

2.3.3.1.5 Reverse-link IPT Packet is Received 13

When a reverse-link IPT packet is received at an eBS and the eBS can tunnel packet back to the AGW, 14

the eBS shall send the packet to the AGW through PMIP tunnel. 15

When an IPT packet is received at an eBS, the eBS shall generate an IPT packet and send the generated 16

IPT packet to the eBS that is the DAP with the same LinkID if all of the following conditions are true: 17

• The receiving eBS cannot send the IP packet to the AGW through PMIP tunnel; 18

• The Direction field in the received IPT packet is set to one, i.e., reverse-link; 19

• The L2TPv3 TTL field in the L2TPv3 header of the received IPT packet is non-zero. 20

The new IPT packet will contain the same IPT L2TPv3 sub-layer header as the original packet, with the 21

exception that the L2TPv3 TTL field is decremented by one before being transmitted and the CRC has 22

been recalculated according to the decremented L2TPv3 TTL field. The ToS field of the outer IP header 23

should replicate the ToS value in the inner IP header. The ToS field of the outer IP header may also be 24

based on local policy. 25

If the L2TPv3 TTL field of the received IPT packet is zero and the eBS cannot send the encapsulated IP 26

packet to the AGW through PMIP tunnel, then the packet shall be discarded. 27

If the CRC field of the received IPT packet does not match with the CRC calculated from the header by 28

the receiving eBS, then the packet shall be discarded. 29

2.3.4 IPT Interface Protocol Procedure 30

2.3.4.1 Procedure for Maintaining DAP Counter 31

DAP Counter is a 2-bit value associated with each IP packet forwarded on the IPT data interface. DAP 32

Counter value represents the identity of the DAP that first received the IP packet. DAP Counter will be 33

included in the IPT data packet to identify the DAP that first received the IP packets from the AGW. This 34

information can be used to assist the FLSE to determine the order the packets should be served at the 35

FLSE. 36

The procedure for maintaining DAP Counter is as follows: 37

1. DAP Counter is part of the DAP Information in the IAS-DAP Record and is given to each new ANRI 38

during Route Set Add procedure. 39

2. When an eBS or SRNC successfully performs PMIP binding with the AGW, the eBS or SRNC shall 40

send IPT-Notification message to all ANRIs in the Route Set and DAP with the DAP Counter value 41

(in the IPT-DAP Record) set as follows: 42

3GPP2 A.S0020-0 v1.0

2-29

a. The value of the DAP Counter shall be set to zero if the latest DAP Information in the DAP 1

Record (before the successful PMIP binding) was set to null. 2

b. The value of the DAP Counter shall be incremented by one (subject to wrap around) from the 3

value of the DAP Counter in the latest DAP Information in the DAP Record before the successful 4

PMIP binding. 5

3. Each ANRI shall store the latest received value of the DAP Counter and update the value when new 6

IAS-DAP Record or IPT-DAP Record are received. 7

2.3.5 IPT Interface Message Procedures 8

This section describes the message procedures used between ANRIs, and the DAP if not in the route set, 9

on the IPT interface. The interface consists of the following messages identified in Table 2.3.5-1. 10

11

Table 2.3.5-1 IPT Message Section and Port Reference

Message Name Section Port Transaction Initiation Message

IPT-Notification 2.3.5.1 4593 yes1

IPT-Notification Ack 2.3.5.2 4593 no2

IPT-Reject 2.3.5.4 4593 no2

Note 1: The destination port number in the UDP packet that carries a transaction initiation message 12

shall be set to the port value specified in Table 2.3.5-1. 13

Note 2: The receiver of a transaction initiation message shall set the <source port, source IP address> 14

and <destination port, destination IP address> of the UDP packet that carries the corresponding 15

transaction response message to the <destination port, destination IP address> and <source port, 16

source IP address> of the UDP packet that carried the transaction initiation message, 17

respectively. 18

19

2.3.5.1 IPT-Notification 20

The IPT notification message is sent between ANRIs, and the DAP if it is not in the route set, to provide 21

notification of a change in the route of the packet between the AT and the AGW. Refer to section 4.1.2.1, 22

IPT-Notification, for the format and content of this message. 23


2.3.5.1.1.1 FLSE Switch Operation - Target FLSE Procedure 25

When an eBS detects that the AT has selected one of its sectors as the forward-link serving sector and it is 26

not the FLSE, the eBS shall send to all ANRIs in the route set and the DAP with the following exception - 27

if the DAP is known, then the eBS should not send to the ANRI that explicitly indicated it is not data 28

capable. 29

For each IPT-Notification message sent, the eBS starts an instance of timer Tnot-ipt and awaits arrival of 30

the IPT-Notification Ack message that has the same Correlation ID as the IPT-Notification message. The 31

information contained in the IPT-Notification message includes: the SSID of the AT, the ANID of the 32

sending eBS and the ANID of the receiving ANRI or DAP if it is not in the route set, the Notification 33

3GPP2 A.S0020-0 v1.0

2-30

Record IE indicating that the sending eBS is the FLSE, the LinkID of the sending eBS and the optional 1

Message TimeStamp IE. Upon sending these messages, the sending eBS becomes the FLSE. 2

2.3.5.1.1.2 FLSE Switch Operation - Source FLSE Procedure 3

An eBS that considers itself to be the FLSE stops being the FLSE when both of the following conditions 4

are true: 5

• The eBS receives an IPT-Notification message from another ANRI in the route set identifying itself 6

as the current FLSE; 7

• The eBS detects that the AT no longer selects its sector as the forward-link serving sector. When an 8

eBS stops being the FLSE, it shall forward any buffered forward-link IP packets and forward-link 9

link-layer packets to the new FLSE. 10

The buffered forward-link IP packets shall be forwarded on IPT interface or LLT interface if the current 11

FLSE advertises the same LinkID as this eBS. Refer to section 2.3.3.1 and section 2.4.2.1. If the eBS still 12

detects that the AT still selects its sector as the forward-link serving sector, then the eBS continues 13

serving packets to the AT on the forward-link and starts notifying all ANRIs and the DAP if it is not in 14

the route set, that it is the FLSE. 15

If the RLSE and FLSE switch occur at the same time, the new serving eBS may send a single IPT-16

Notification message to indicate both events. 17

When the FLSE receives an IPT-Notification message from another ANRI or the DAP, if it is not in the 18

route set indicating that the sender no longer considers the receiving ANRI to be the FLSE, the receiving 19

eBS is no longer the FLSE for the AT. If the eBS still detects that the AT still selects its sector as the 20

forward-link serving sector, then the eBS continues serving packets to the AT on the forward-link and 21

starts notifying all ANRIs in the route set and the DAP (even if the DAP is not in the route set), that it is 22

the FLSE. If the eBS no longer detects that the AT still selects its sector as the forward-link serving sector, 23

the eBS shall forward any buffered forward-link IP packets and forward-link link-layer packets to the 24

DAP if the new FLSE is not known. If the new FLSE is known and it advertises the same LinkID as this 25

eBS then the buffered forward-link IP packets shall be forwarded on IPT interface if the current FLSE 26

advertises the same LinkID with this eBS. Otherwise, the buffered forward-link IP packets shall be 27

forwarded on LLT interface. Refer to section 2.3.3.1 and section 2.4.2.1. 28

2.3.5.1.1.3 FLSE Switch Operation - DAP Procedure 29

When the DAP receives an IPT-Notification message from an eBS indicating that it has become the FLSE, 30

the DAP determines which eBS is the current FLSE and which eBS is the previous FLSE. This 31

determination may be based on the order that the IPT-Notification messages are received or may be 32

determined by the Message Timestamp IE if it is included. The DAP shall send an IPT-Notification Ack 33

message to this eBS and an IPT-Notification message to the eBS that was the previous FLSE. This is 34

done because two FLSE switches may have occurred in a short period of time; refer to section 3.5.2. The 35

DAP starts timer Tnot-ipt and awaits arrival of the IPT-Notification Ack message that has the same 36

Correlation ID as the IPT-Notification message it sent. The information contained in the IPT-Notification 37

message includes: the SSID of the AT, the ANID of the DAP and the receiving ANRI, and the 38

Notification Record IE indicating that the DAP no longer considers receiving ANRI to be FLSE. Upon 39

sending this message, the DAP starts forwarding any packets on the forward-link to the new FLSE. 40

2.3.5.1.1.4 RLSE Switch Operation - Target RLSE Procedure 41

When an eBS detects that the AT has selected a sector in the eBS as the reverse-link serving sector and it 42

is not the RLSE, the eBS sends an IPT-Notification message to each ANRI and the DAP if it is not in the 43

route set except for the ANRI that is not data capable. The eBS need not send the IPT-Notification 44

message to the SRNC if it knows that the SRNC does not need the notification. For each IPT-Notification 45

message sent, the eBS starts an instance of timer Tnot-ipt and awaits arrival of the IPT-Notification Ack 46

message that has the same Correlation ID as the IPT-Notification message. The information contained in 47

the IPT-Notification message includes: the SSID of the AT, the ANID of the sending eBS and the 48

3GPP2 A.S0020-0 v1.0

2-31

receiving ANRI or DAP if it is not in the route set, and the Notification Record IE indicating that the 1

sending eBS is the RLSE. Upon sending these messages, the sending eBS becomes the RLSE. 2

If the RLSE and FLSE switch occur at the same time, the new serving eBS may send a single IPT-3

Notification message to indicate both events. 4

2.3.5.1.1.5 RLSE Switch Operation - Source RLSE Procedure 5

When the RLSE receives an IPT-Notification message from another ANRI indicating that the sending 6

ANRI is the RLSE, the receiving eBS is no longer the RLSE for the AT and may deallocate any 7

scheduled radio resources related to the AT on the reverse-link. 8

2.3.5.1.1.6 DAP Switch Operation 9

When an ANRI successfully performs PMIP registration with the AGW and redirects the forward IP 10

packets from the AGW to the ANRI, or when an ANRI successfully performs PMIP Signaling-Only 11

binding, the ANRI sends an IPT-Notification message to each ANRI in the route set and the DAP (even if 12

DAP is not in the route set). For each IPT-Notification message sent, the ANRI starts an instance of timer 13

Tnot-ipt and awaits arrival of the IPT-Notification Ack message that has the same Correlation ID as the 14

IPT-Notification message. The information contained in the IPT-Notification message includes: the SSID 15

of the AT, the ANID of the sending ANRI and the receiving ANRI or DAP if it is not in the route set, the 16

IPT-DAP Record IE indicating that the sending ANRI is the DAP, and the LinkID of the sending eBS. 17

The IPT-DAP Record IE shall contain the AGW C-plane IP address to which the ANRI performed PMIP 18

registration, the AGW U-plane IP address, the GRE key used for the PMIP tunnel with the AGW, the 19

PMIP timestamp which the ANRI used in the successful PMIP registration request message. Upon 20

sending this message, the sending ANRI becomes the DAP. 21

If the DAP receives an IPT-Notification message with the IPT-DAP Record IE indicating that the sending 22

ANRI is the DAP for the same AGW, the receiver is no longer the DAP and may deallocate any resources 23

related to the AT if it is not in the route set and there is no pending PMIP binding update at the receiver. 24

When the FLSE receives IP packets that do not require in-order delivery from the target DAP, the FLSE 25

may serve the packets immediately. Upon receipt of tunneled IP packets from the target DAP or IPT-26

Notification message indicating that the DAP has changed, the FLSE shall start timer Twaitdap-ipt and 27

buffers new IP packets that require in-order delivery from the target DAP. Upon expiration of the timer 28

Twaitdap-ipt, the FLSE may start serving tunneled IP packets from the target DAP over-the-air. The FLSE 29

should give scheduling priority to the tunneled IP packets from the source DAP before the tunneled IP 30

packets from the target DAP. 31

2.3.5.1.1.7 Connection Close Operation 32

When an ANRI receives a ConnectionClose message from the AT (either independently or in response to 33

the ANRI sending a ConnectionClose message), or after an implementation specific time if the AT does 34

not respond to a ConnectionClose message, the ANRI sends an IPT-Notification message to each ANRI 35

in the route set and the DAP (even if the DAP is not in the route set). If the SRNC is not data capable, the 36

SRNC may record the sender of the IPT-Notification message indicating Connection Close as last FLSE 37

for the AT for location registration. For each IPT-Notification message sent, the ANRI starts an instance 38

of timer Tnot-ipt and awaits arrival of the IPT-Notification Ack message that has the same Correlation ID 39

as the IPT-Notification message. The information contained in the IPT-Notification message includes: the 40

SSID of the AT, the ANID of the sending ANRI and the receiving ANRI or DAP if it is not in the route 41

set, and the Notification Record IE indicating that the connection with the AT is closed. Upon sending 42

these messages, the sending ANRI forwards any IP packets that have not been transmitted to the AT, to 43

the DAP (if the sending ANRI is not the DAP). It also enters idle state if it is the DAP or the SRNC of the 44

AT. Otherwise, it may immediately deallocate any resources allocated to the AT. If the receiving ANRI is 45

not the SRNC, then it may stop serving as an ANRI for the AT. The DAP may retain the packet filter for 46

the AT after connection close for identifying reservation of the incoming packet for paging purpose. Refer 47

to section 2.2.2.11. 48

3GPP2 A.S0020-0 v1.0

2-32

When an ANRI receives an IPT-Notification message with the Notification Record IE indicating that the 1

connection with the AT is closed, the ANRI forwards any IP packets that have not been transmitted to the 2

AT, to the DAP (if the sending ANRI is not the DAP). It also enters idle state if it is the DAP or the 3

SRNC of the AT. If it is not the DAP or the SRNC of the AT, it may immediately deallocate any 4

resources allocated to the AT. If the receiving ANRI is not SRNC, then it may stop serving as an ANRI 5

for the AT. 6

2.3.5.1.1.8 Connection Lost Operation 7

When the FLSE fails air-link supervision timer with the AT, the FLSE sends an IPT-Notification message 8

to each ANRI in the route set and the DAP (even if DAP is not in the route set). The SRNC should record 9

the sender of the IPT-Notification message indicating Connection Lost as last FLSE for the AT for 10

location registration. For each IPT-Notification message sent, the FLSE starts an instance of timer Tnot-ipt 11

and awaits arrival of the IPT-Notification Ack message that has the same Correlation ID as the IPT-12

Notification message. The information contained in the IPT-Notification message includes: the SSID of 13

the AT, the ANID of the sending ANRI and the receiving ANRI or DAP if it is not in the route set, and 14

the Notification Record IE indicating that the connection with the AT is lost. Upon sending these 15

messages, the sending ANRI forwards any IP packets that have not been transmitted to the AT to the 16

DAP (if the sending ANRI is not the DAP). It also enters idle state if it is the DAP or the SRNC of the AT. 17

The DAP may retain the packet filter for the AT after connection close for identifying reservation of the 18

incoming packet for paging purpose. Refer to section 2.2.2.11. 19

When an ANRI or the DAP, if it is not in the route set, receives an IPT-Notification message with the 20

Notification Record IE indicating that the connection with the AT is lost, the receiving entity forwards 21

any IP packets that have not been transmitted to the AT, to the DAP (if the receiver is not the DAP). It 22

also enters idle state if it is the DAP or the SRNC of the AT. If the receiver is an ANRI and is not the 23

SRNC, then it may stop serving as an ANRI for the AT after its Connection Keep Alive timer expires [1]. 24

2.3.5.1.1.9 Route Set Add Operation 25

If the DAP is in the AT’s route set, when the DAP receives a RouteMap message from the AT (via the 26

RLSE), it checks whether there is a new ANRI in the route set. If so, the DAP sends an IPT-Notification 27

message to each new ANRI in the route set. For each IPT-Notification message sent, the DAP starts an 28

instance of timer Tnot-ipt and awaits arrival of the IPT-Notification Ack message that has the same 29

Correlation ID as the IPT-Notification message. The information contained in the IPT-Notification 30

message includes: the SSID of the AT, the ANID of the DAP and the receiving ANRI, and the IPT-DAP 31

Record IE indicating that the sender is the DAP. The IPT-DAP Record IE shall contain the AGW C-plane 32

IP address to which the DAP performed PMIP registration, the AGW U-plane IP address, the GRE key 33

used for the PMIP tunnel with the AGW, and the PMIP timestamp which the DAP used in the successful 34

registration request message. 35

When the FLSE receives a RouteMap message from the AT, it checks whether there is a new ANRI in the 36

route set. If so, the FLSE sends an IPT-Notification message to each new ANRI and the DAP if it is not in 37

the route set. For each IPT-Notification message sent, the FLSE starts an instance of timer Tnot-ipt and 38

awaits arrival of the IPT-Notification Ack message that has the same Correlation ID as the IPT-39

Notification message. The information contained in the IPT-Notification message includes: the SSID of 40

the AT, the ANID of the sending ANRI and the receiving ANRI or DAP if it is not in the route set, and 41

the Notification Record IE indicating that the sending eBS is the FLSE. 42

If the ANRI is both the DAP and the FLSE, then it may send an IPT-Notification message which contains 43

both the Notification Record IE indicating that the sending eBS is the FLSE and the IPT-DAP Record IE 44

indicating that the sending ANRI is the DAP. 45

3GPP2 A.S0020-0 v1.0

2-33

2.3.5.1.1.10 Route Set Remove Operation 1

For AN-initiated DAP handoff, when the FLSE receives a RouteMap message from the AT, it checks 2

whether the DAP is still in the route set. If the DAP is not in the route set, the FLSE should become the 3

DAP by performing the DAP switch operation in section 2.3.5.1.1.6. 4

2.3.5.1.1.11 Packet Data Session Release 5

When the DAP receives a PMIP-Registration Revocation message to release the packet data session or 6

when the PMIP tunnel lifetime has expired, if the DAP is in the route set, the DAP sends an IPT-7

Notification message to all ANRIs in the route set. Otherwise, the DAP sends an IPT Notification 8

message to the SRNC. The DAP starts timer Tnot-ipt and awaits arrival of the IPT-Notification Ack 9

message with the same Correlation ID as the IPT Notification message. The fields in the IPT Notification 10

message shall be set as follows: 11


• The sender Endpoint ID shall be set to the ANID of the DAP and the receiver Endpoint ID shall be 13

set to the ANID of the SRNC; 14

• The IPT-DAP Record IE shall be included and the Lifetime field shall be set to zero. 15

When the SRNC receives an IPT-Notification message with the Lifetime field in IPT-DAP Record IE set 16

to zero, the SRNC responds with an IPT-Notification Ack message. Upon receipt of the IPT-Notification 17

message, the SRNC should send a signaling message to the AT to reset the IP interface. If the AT is idle, 18

the SRNC should invalidate the DAP Record and AGW record associated with the released packet data 19

session and should page the AT. 20

21


If timer Tnot-ipt expires, the sender may resend the IPT-Notification message to the receiver and restart 23

timer Tnot-ipt an implementation-dependent number of times. If the IPT-Notification Ack message is not 24

received from the receiver, the sender should close the connection with the AT. 25

If an ANRI receives an IPT-Notification message that contains an ANID that is not in the AT’s route set 26

or the DAP, the receiving ANRI may process the message if it trusts the sender by means outside the 27

scope of this specification. Otherwise, it should silently discard the message. If DAP is not in the Route 28

Set, then DAP shall process the received IPT-Notification message. 29

2.3.5.2 IPT-Notification Ack 30

The IPT-Notification Ack message is sent by an ANRI or the DAP if it is not in the route set, to 31

acknowledge the receipt of an IPT-Notification message. Refer to section 4.1.2.2, IPT-Notification Ack, 32

for the format and content of this message. 33


When an IPT-Notification message is received with an Access Counter that matches the current Access 35

Counter at the receiving ANRI, the receiver shall send an IPT-Notification Ack message to the sender of 36

the IPT-Notification message. The IPT-Notification Ack message shall contain the same AT Identity IE 37

and Correlation ID that was received in the IPT-Notification message. The Cause value shall be set to 38

“Successful event”. 39

If the Access Counter IE in the IPT-Notification message contains a value that does not match the current 40

Access Counter at the receiving ANRI, the receiver shall not process the content of the message and shall 41

respond with an IPT-Notification Ack message containing the ‘Stale message” cause value. 42

If DAP is not in the Route Set, the Access Counter value is ignored. 43

3GPP2 A.S0020-0 v1.0

2-34

Upon receipt of the IPT-Notification Ack message, the receiving ANRI or DAP, if it is not in the route set, 1

stops timer Tnot-ipt corresponding to this message. For FLSE switch operation, the target FLSE should not 2

schedule packet for transmission before reception of the corresponding IPT-Notification Ack message. 3


Upon receipt of the IPT-Notification message indicating that the sender is the current FLSE, the source 5

FLSE shall immediately send an IPT-Notification Ack message to the current FLSE. The source FLSE 6

should also include the following IEs in the IPT-Notification Ack message if it determines that it is no 7

longer the FLSE for the AT: 8

• The Notification Record IE indicating that the source FLSE is the previous FLSE. 9

• The Flush Information IE indicating whether the source FLSE still has buffered forward-link IP 10

packets on reservations that require in-order delivery. 11


Upon receipt of the IPT-Notification Ack message with the indication that the sender is the previous 13

FLSE or upon receipt tunneled data from the source FLSE, the target FLSE should complete over-the-air 14

handoff with the AT. If the IPT-Notification Ack message from the previous FLSE also contains an “In-15

Order FL IP Data Pending” flag set to one, the target FLSE starts timer Tflflush-ipt and awaits arrival of a 16

tunneled IP packet from the source FLSE or the IPT-Flush message with the “In-Order FL IP Data 17

Pending” flag set to zero. The timer Tflflush-ipt is reset for each IP packet that is received from the source 18

FLSE. 19

The target FLSE should give over-the-air scheduling priority on reservations that require in-order delivery 20

in the following order: (i) tunneled link-layer packets containing re-transmissions (ii) the tunneled link-21

layer packets containing first time transmissions, (iii) the tunneled IP packets on IPT interface from the 22

source FLSE and (iv) the tunneled IP packets on IPT interface from the DAP. The target FLSE may serve 23

the tunneled IP packets while some tunneled link-layer packets are still in transmission. The target FLSE 24

shall not serve tunneled IP packets from the DAP on reservations that require in-order delivery until the 25

timer Tflflush-ipt expires, or when IPT-Notification Ack/IPT-Flush message with the “In-Order FL Data 26

Pending” flag set to zero is received, or when another FLSE handoff occurs. 27


Upon receipt of the IPT-Notification message indicating that the sender is the current RLSE, the source 29

RLSE shall immediately send an IPT-Notification Ack message to the current RLSE and shall also 30

include the following IEs in the IPT-Notification Ack message: 31

• The Notification Record IE indicating that the source RLSE is the previous RLSE 32

• The Flush Information IE indicating whether the source RLSE still awaits reverse-link link-layer 33

packets on reservations that require in-order delivery. 34


Upon receipt of the IPT-Notification Ack message with the indication that the sender is the previous 36

RLSE, the target RLSE should complete over-the-air handoff with the AT. If the IPT-Notification Ack 37

message from the previous RLSE also contains an “In-Order RL Data Pending” flag set to one, the target 38

RLSE starts timer Trlflush-ipt and awaits arrival of an IPT-Flush message with the “In-Order RL Data 39

Pending” flag set to zero. 40

The target RLSE shall not tunnel reverse-link IP packets to the DAP or AGW on reservations that require 41

in-order delivery until the timer Trlflush-ipt expires, or when IPT-Notification Ack/IPT-Flush message with 42

the “In-Order RL L2 Data Pending” flag set to zero is received, or when another RLSE handoff occurs. 43

3GPP2 A.S0020-0 v1.0

2-35

2.3.5.2.1.5 DAP Switch Operation - FLSE Procedure 1

Upon receipt of the IPT-Notification message indicating that the sender is the current DAP, the FLSE 2

shall send an IPT-Notification Ack message to the current DAP and shall also include the following IE in 3

the IPT-Notification Ack message: 4

• The Notification Record IE indicating that the sender is the current FLSE. 5

Upon receipt of tunneled IP packets from the target DAP or IPT-Notification message indicating that the 6

DAP has changed, the FLSE shall start timer Twaitdap-ipt and buffers new IP packets that require in-order 7

delivery from the target DAP. Upon expiration of the timer Twaitdap-ipt, the FLSE may start serving 8

tunneled IP packets from the target DAP over-the-air. The FLSE should give scheduling priority to the 9

tunneled IP packets from the source DAP before the tunneled IP packets from the target DAP. 10

2.3.5.2.1.6 DAP Switch Operation - DAP Procedure 11

Upon receipt of the IPT-Notification Ack message with Notification Record IE indicating that the sender 12

is the current FLSE, the DAP updates its identity of the FLSE, if different from the identity of the FLSE 13

that it currently has. 14


If the timer Tflflush-ipt expires, the target FLSE shall serve tunneled IP packets from the DAP on 16

reservations that require in-order delivery. 17

If the timer Trlflush-ipt expires, the target RLSE shall tunnel reverse-link IP packets to the DAP or AGW, 18

subject to configuration, on reservations that require in-order delivery. 19

2.3.5.3 IPT-Flush 20

The IPT-Flush message is sent by an ANRI to indicate that its buffered data has not been depleted. Refer 21

to section 4.1.2.4, IPT-Flush, for the format and content of this message. 22



If the source FLSE has sent the Flush Information IE with “In-Order FL IP Data Pending” flag set to one 25

to the target FLSE, the source FLSE should send an IPT-Flush message to the target FLSE once it has 26

determined that all IP packets on any reservations that require in-order delivery have been tunneled to the 27

target FLSE. The message shall contain “In-Order FL IP Data Pending” flag set to zero. 28


Upon receipt of the IPT-Flush message with the “In-Order FL Data Pending” flag set to zero, the target 30

FLSE shall serve tunneled IP packets from the DAP on reservations that require in-order delivery. 31


If the source RLSE has sent the Flush Information IE with “In-Order RL L2 Data Pending” flag set to one 33

to the target RLSE, the source RLSE should send an IPT-Flush message to the target RLSE once it no 34

longer awaits any link-layer packets on reservations that require in-order delivery. The message shall 35

contain “In-Order RL L2 Data Pending” flag set to zero. 36


Upon receipt of the IPT-Flush message with the “In-Order RL L2 Data Pending” flag set to zero, the 38

target RLSE shall tunnel reverse-link IP packets to the DAP or AGW, subject to configuration, on 39

reservations that require in-order delivery. 40

3GPP2 A.S0020-0 v1.0

2-36


If an ANRI receives an IPT-Flush message containing ANID that is not in the AT’s route set or the DAP, 2

the receiving ANRI should silently discard the message. 3

2.3.5.4 IPT-Reject 4

The IPT-Reject message is sent in response to an IPT message that can not be properly processed (e.g., 5

having an unrecognized version in the IPT Message Type IE or with one or more IEs containing invalid 6

values in some fields such that the message can not be processed). Refer to section 4.1.2.3, IPT-Reject, 7

for the format and content of this message. 8


When an eBS/SRNC receives an IPT message that can not be properly processed, the eBS/SRNC may 10

respond with an IPT-Reject message. When an eBS/SRNC receives an IPT message with an unrecognized 11

version in the IPT Message Type IE, the eBS/SRNC shall respond with an IPT-Reject message. The IPT-12

Reject message version shall be recognized as 00H. Refer to 1.7. The IPT-Reject IEs in the message shall 13

be set as follows: 14



• The Cause IE shall be included and set to the reason for the reject. 17

• The IPT Reject Record IE shall include the rejected message and if the Cause IE is set to “Reject - 18

version not supported” it shall also include all versions supported by the sending eBS/SRNC. 19

When an eBS/SRNC receives an IPT-Reject message from another eBS/SRNC, it should stop 20

retransmission of the rejected message, stop any timer(s) running and address operations pending the 21

message that was rejected. The receiving eBS/SRNC may also use the IPT Reject Record IE to determine 22

an acceptable version for sending messages to this entity. 23


None. 25

2.4 LLT (Link-Layer Tunneling) Interface 26

For this revision of the specification, the version number for the LLT interface is 01H. 27

This interface is part of the U2 and U3 reference points and allows for tunneling link-layer packets to 28

FLSE and from RLSE. The LLT interface only comprises of a single message that encapsulates the link 29

layer packet (i.e., Route Protocol Packet in the Inter-Route Tunneling Protocol payload [1]) of an AT. 30

When the RLSE tunnels an RL link-layer packet to another ANRI, it uses the information contained in the 31

Inter-Route Tunneling Protocol header to identify the destination. When an ANRI needs to tunnel a FL 32

link-layer packet to the AT, it uses the information from the IPT signaling interface to identify to which 33

FLSE to send the encapsulated link-layer packet. 34

2.4.1 LLT Interface Network/Transport Protocol Specification 35

The UMB IOS protocol stack for the LLT interface is defined as follows. 36

Link Layer Packet L2TPv3

IP


urers. LLT signaling is comprised of an outer IP header (for routing purpose between source and 38

destination), a four octet L2TPv3 header (refer to [1]), an L2TPv3 sub-layer header and the encapsulated 39

link-layer packet which is formatted according to the payload of Inter-Route Tunneling Protocol (refer to 40

[1]). 41

3GPP2 A.S0020-0 v1.0

2-37

The IPT L2TPv3 header is defined as follows. 1

LLT Interface L2TPv3 Header

7 6 5 4 3 2 1 0 Octet

(MSB) Session ID = 55 4D 42 32H 1

… … (LSB) 4

where: 2

Session ID: This is a 32-bit field set to 55 4D 42 32H for a link-layer tunnel13. 3

The LLT L2TPv3 sub-layer header is defined as follows. 4

LLT L2TPv3 Sub-layer Header

7 6 5 4 3 2 1 0 Octet

Version Direction Retransmitted

RouteID Type 1

RouteID Valid

(MSB) RouteID (LSB) 2

(MSB) Reservation Label/StreamID (LSB) 3 Reservat-ion Valid

(MSB) L2TPv3 TTL

(LSB) SSID Included

ATI Included

ATI Type 4

IF (ATI Included = ‘1’) {1:

(MSB) ATI 5

… … (LSB) 20

} END IF

IF (SSID Included = ‘1’) {1:

(MSB) SSID 5

… … (LSB) 24

} END IF

IF (RouteID Type = ‘1000’) {1:

(MSB) PilotID j (LSB) j+1

} ELSE {1:

(MSB) ANIDmsb j

… … (LSB) j+7

} END IF

13 The Session ID ’55 4D 42 32H’ is ASCII representation of ‘UMB2’.

3GPP2 A.S0020-0 v1.0

2-38

LLT L2TPv3 Sub-layer Header

7 6 5 4 3 2 1 0 Octet

(MSB) CRC k (LSB) k+1

where: 1

Version This is a 3-bit field which identifies the version of the header. For this 2

revision this field is set to ‘01’. 3

Direction This is a 1-bit field which is set to ‘1’ if the encapsulated link-layer 4

packet is from reverse-link or ‘0’ if the encapsulated link-layer packet is 5

for forward-link direction. 6

Retransmitted This is a 1-bit field which is set to ‘1’ if the encapsulated link-layer 7

packet is a retransmitted packet on the forward-link. Otherwise, this field 8

shall be set to ‘0’. 9

RouteID Type This is a 4-bit field which is set to the HeaderType field in the Inter-10

Route Tunneling Protocol Header defined in [1]. 11

RouteID Valid This is a 1-bit field which is set to ‘1’ if the RouteID field is valid. 12

Otherwise this field is set to ‘0’. 13

RouteID This is a 7-bit field which is set to the RouteID defined in [1]. This field 14

is valid only if the RouteID Valid field is set to ‘1’. Otherwise this field 15

shall be set to zero by the sending entity and ignored by the receiving 16

entity. 17

Reservation Label/StreamID If the Reservation Valid field is set to ‘1’, then this is contains the 18

reservation label for QoS treatment of tunneled packets as defined in [1]. 19

Otherwise this field shall be set to the stream associated with the packet 20

by the sending entity. 21

Reservation Valid This is a 1-bit field which is set to ‘1’ if the Reservation Label associated 22

with the Encapsulated Packet is available. Otherwise this field is set to 23

‘0’. 24

L2TPv3 TTL This is a 3 bit field which is set to the time to live for the packets in the 25

number of forwarding hops. 26

SSID Included This is a 1-bit field which is set to ‘1’ if SSID is present or ‘0’ otherwise. 27

ATI Included This is a 1-bit field which is set to ‘1’ if ATI is present or ‘0’ otherwise. 28

ATI Type This is a 2-bit field which specifies the type of 128-bit ATI. The field is 29

set to ‘00’ for Broadcast ATI, to ‘10’ for Unicast ATI, and to ‘11’ for 30

Random ATI. The value of ‘01’ is reserved. This field is only valid if the 31

ATI Included field is set to ‘1’. Otherwise this field shall be set to ‘00’ 32

by the sending entity and ignored by the receiving entity. 33

ATI If the ATI Included field is set to ‘1’ and the ATI Type field is set to ‘10’ 34

or ‘11’, then this field is set to the 128-bit ATI identifier. Otherwise, this 35

field is omitted. 36

SSID This field is set to the 160-bit SSID of the AT if the SSID Included field 37

is set to ‘1’. Otherwise, this field is omitted. 38

3GPP2 A.S0020-0 v1.0

2-39

PilotID If the RouteID Type field is set to ‘1000’, then this field includes the 1

value of the PilotID (refer to [1]) expressed as a 16-bit unsigned integer. 2

Otherwise, this field is omitted. 3

ANIDmsb This field is set to the 64 MSBs of ANID if the RouteID Type field is not 4

set to ‘1000’. Otherwise, this field is omitted. 5

CRC This field is set to the 16-bit CRC covering the L2TPv3 header and 6

L2TPv3 sub-layer header preceding and not including this field and is 7

computed using the method specified for FCS-16 in [4]. 8

9

2.4.2 LLT Interface Network/Transport Protocol Procedure 10

11

2.4.2.1 LLT Packet Tunneling Operations 12

2.4.2.1.1 An ANRI Generates a Unicast Link-layer Packet 13

When an ANRI generates a link-layer packet (i.e., Route Protocol packet [1]), then the ANRI shall send 14

the packet to the AT if the ANRI is the FLSE. 15

Otherwise, if all of the following conditions are true, then the ANRI shall send an LLT packet to the 16

FLSE, if known, or otherwise to DAP: 17

• The ANRI is not the FLSE 18

• The AT is not idle 19

The LLT L2TPv3 sublayer header shall be set as follows: 20

1. If the SSID for the AT is available14: 21

a. Then the SSID Included field shall be set to one and the SSID field shall be set to the SSID of the 22

AT. The ATI included field shall be set to zero and the ATI field shall not be included; 23

b. Otherwise, the SSID Included field shall be set to zero and the SSID field is omitted; The ATI 24

included field shall be set to one and the ATI field shall be set to the RATI of the AT; 25

2. The Direction field is set to zero indicating this is a forward-link packet; 26

3. The RouteID Type field shall be set to ‘0000’ and the ANIDmsb field shall be set based on the ANID 27

of the sending ANRI; 28

4. The RouteID valid field shall be set to one and the RouteID field shall be set to the RouteID assigned 29

to the ANRI by the AT; 30

5. If there is a Reservation Label associated with the link-layer packet, then the Reservation Valid field 31

shall be set to one and the Reservation Label field shall be set to the Reservation Label associated 32

with the stream that generated the link-layer packet. Otherwise, the Reservation Valid field shall be 33

set to zero and the Reservation Label/StreamID field shall be set to the StreamID associated with the 34

packet; 35


7. If the Encapsulated Link-Layer Packet is a retransmitted packet, then the Retransmitted field shall be 37

set to one. Otherwise, it shall be set to zero. 38

14 SSID is provided to an ANRI from SRNC when it is added into the route set. If the Session Anchor ANRI creates the SSID,

i.e., it is the SRNC that assigns UATI to the AT when the AT accesses with RATI, then SSID will be available after the IAS-UATI Update Ack message is received at the Session Anchor ANRI from the FLSE.

3GPP2 A.S0020-0 v1.0

2-40

The Encapsulated Link-Layer Packet shall be the Route Protocol packet for the AT. Refer to [1]. 1

If the AT is idle and the ANRI is not the Session Anchor ANRI, then the packet shall be discarded. 2

If the AT is idle, the ANRI is the Session Anchor ANRI, and the packet can be transmitted to the AT in 3

idle state, e.g., registration response message, then the Session Anchor ANRI shall send an LLT packet to 4

the last eBS that the AT registered through. The LLT L2TPv3 sublayer header shall be set as follows: 5

1. The SSID Included field shall be set to zero and the SSID field is omitted; 6

2. The ATI included field shall be set to one and the ATI field shall be set to the UATI of the AT; 7

3. The Direction field is set to zero indicating this is a forward-link packet; 8

4. The RouteID Type field shall be set to ‘0000’ and the ANIDmsb field shall be set based on the ANID 9

of the sending ANRI; 10

5. The RouteID valid field shall be set to one and the RouteID field shall be set to the RouteID assigned 11

to the Session Anchor ANRI by the AT; 12

6. The Reservation Valid field shall be set to zero and the Reservation Label/StreamID field shall be set 13

to the StreamID associated with the packet; 14


8. If the Encapsulated Link-Layer Packet is a retransmitted packet, then the Retransmitted field shall be 16

set to one. Otherwise, it shall be set to zero. 17

Otherwise, the Session Anchor ANRI shall initiate paging procedure with the idle AT. Refer to section 18

2.2. 19

2.4.2.1.2 An ANRI Receives a Unicast Forward-link LLT Packet 20

When an ANRI receives an LLT packet and the ANRI is in the FLSE, then the ANRI shall send the 21

encapsulated link-layer packet to the AT through Inter-Route Tunneling Protocol. The IRTP HeaderType 22

shall be set to ‘0’ and the RouteID in the Inter-Route Tunneling Protocol header shall be set to the 23

RouteID of the received LLT packet. Refer to [1]. 24

When an LLT packet is received at an ANRI and the ANRI is not in the FLSE, if all of the following 25

conditions are true the ANRI shall forward the received LLT packet to the FLSE, if known, or otherwise 26

to DAP: 27

• The Direction field in the received LLT packet is set to zero, i.e., forward-link 28

• The L2TPv3 TTL field of the received LLT packet is non-zero 29

• Connection with the AT is not closed 30

The L2TPv3 TTL field shall be decremented by one before being transmitted and the CRC field shall be 31

calculated accordingly. 32

If the L2TPv3 TTL field of the received LLT packet is zero and the ANRI is not in the FLSE, then the 33

packet shall be discarded. 34

If the connection with the AT is closed, then the packet shall be discarded. 35

2.4.2.1.3 An ANRI Receives a Reverse-link LLT Packet 36

When an ANRI receives an LLT packet and the included RouteID and ANIDmsb match with the included 37

AT identity, the ANRI processes the included LLT packet using its UMB air-interface route. 38

When an ANRI receives an LLT packet and the ANRI has a record for the AT identity in the header but 39

the included RouteID and ANIDmsb do not match with the ANRI’s record for that AT, the ANRI silently 40

discards the packet. 41

3GPP2 A.S0020-0 v1.0

2-41

When an eBS or SRNC receives an LLT packet and the eBS or SRNC does not have a record for the AT 1

identity in the header, then it creates a route with the AT if the encapsulated message contains a 2

RouteCreation Header. If the encapsulated message does not contain a RouteCreation Header, the 3

receiving eBS or SRNC should silently discard the packet. 4

When an eBS receives an LLT packet with a valid PilotID, then it creates a route with the AT using the 5

included ATI if the encapsulated message contains a RouteCreation Header. Refer to 2.2. If the 6

encapsulated message does not contain a RouteCreation Header, the receiving eBS should silently discard 7

the packet. 8

2.4.2.1.4 An RLSE Receives a Tunneled Link-layer Packet Over the Air for Another Route 9

When the RLSE has received a link-layer packet over the air for another ANRI on the reverse link, the 10

RLSE shall send an LLT packet to the ANRI identified in the Inter-Route Tunneling Protocol header [1]. 11

If the IRTP HeaderType is ‘1000’, the receiving ANRI is identified using a look-up procedure based on 12

provisioning of PilotID or through neighbor discovery procedure. Refer to section 2.2.2.15. The LLT 13

L2TPv3 sublayer header shall be set as follows: 14

1. If the SSID for the AT is available, then the SSID Included field shall be set to ‘1’and the SSID field 15

shall be set to the SSID of the AT. Otherwise, the SSID Included field shall be set to ‘0’ and the SSID 16

field is omitted; 17

2. The ATI included field shall be set to ‘1’and the ATI field shall be set to the ATI associated with the 18

AT; 19

3. The Direction field is set to ‘1’indicating this is a reverse-link packet; 20

4. The RouteID Type field shall be set to ‘1000’ and the PilotID field shall be set to the PilotID in the 21

IRTP header; 22

5. The RouteID valid field shall be set to ‘1’and the RouteID field shall be set to the RouteID in the 23

IRTP header; 24

6. The Reservation Valid field shall be set to ‘0’and the Reservation Label/StreamID field shall be set to 25

the StreamID associated with the packet; 26

7. The L2TPv3 TTL field shall be set to ‘000’; 27

If the IRTP HeaderType is ‘1001’, the receiving ANRI is identified using the value of the received 28

ANIDmsb. Refer to [1]. The LLT L2TPv3 sublayer header shall be set as follows: 29


shall be set to the SSID of the AT. Otherwise, the SSID Included field shall be set to ‘0’and the SSID 31

field is omitted; 32

2. The ATI included field shall be set to ‘1’and the ATI field shall be set to the ATI value associated 33

with the AT; 34


4. The RouteID Type field shall be set to ‘1001’and the ANIDmsb field shall be set based on the ANID 36

in the IRTP header; 37


IRTP header; 39




3GPP2 A.S0020-0 v1.0

2-42

If the IRTP HeaderType is ‘0’, the receiving ANRI is identified using the latest RouteMap message 1

received from the AT or from the Route Protocol header. Refer to [1]. The LLT L2TPv3 sublayer header 2



shall be set to the SSID of the AT. Otherwise, the SSID Included field shall be set to ‘0’and the SSID 5

field is omitted; 6

2. If the SSID for the AT is not included, then the ATI shall be included and is set to the ATI value 7

associated with the AT. Otherwise, the ATI included field shall be set to ‘0’and the ATI field shall 8

not be included; 9


4. The RouteID Type field shall be set to ‘0000’and the ANIDmsb field shall be set to the ANID 11

mapped to the RouteID in the latest RouteMap message from the AT or from the Route Protocol 12

header; 13


IRTP header; 15




In all cases, the Encapsulated Link-Layer Packet shall be the received Route Protocol packet in the IRTP 19

packet. Refer to [1]. 20

2.4.2.1.5 An eBS Needs to Tunnel a Broadcast Message through Another eBS 21

When an eBS has generated a Route Protocol packet that is to be broadcasted over the air through another 22

eBS, e.g., overhead message, the generating eBS shall send an LLT packet to the receiving eBS. The LLT 23

L2TPv3 sublayer header shall be set as follows: 24

1. The SSID Included field shall be set to ‘0’and the SSID field is omitted; 25

2. The ATI included field shall be set to ‘1’, the ATI Type field shall be set to ‘00’, i.e., Broadcast ATI 26

and the ATI field shall not be included; 27

3. The Direction field is set to ‘0’indicating this is a forward-link packet; 28

4. The RouteID Type field shall be set to ‘1000’and the PilotID field shall be set to the PilotID of the 29

sending eBS; 30

5. The RouteID valid field shall be set to ‘0’and the RouteID field shall be set to ‘0000000’; 31




The receiving eBS shall broadcast the encapsulated link-layer packet if the RouteID Type field is set to 35

‘1000’, and SSID Included field, ATI Type field and the RouteID valid field are set to ‘0’while the ATI 36

Included field is set to ‘1’. The IRTP header type shall be set to ‘1000’, the RouteID shall not be included 37

and the PilotID shall be set to the PilotID received in the LLT packet. 38

39

2.5 PMIP (Proxy Mobile IP) Interface 40

Proxy MobileIPv4 protocol framework [2] is used for managing the eBS-AGW and SRNC-AGW PMIP 41

bindings. The following sections detail the PMIP binding establishment and maintenance procedures. 42

This interface consists of two parts. The first part called the PMIP signaling interface (section 2.5.1) is 43

3GPP2 A.S0020-0 v1.0

2-43

part of U1 and U6 reference points which carries the signaling messages necessary to setup, refresh and 1

teardown PMIP binding between the AGW and eBS/SRNC for an AT. The second part called the PMIP 2

bearer interface (section 2.5.2) is part of U1 reference point and allows for tunneling of user IP packets 3

between the AGW and the eBS. 4

2.5.1 PMIP Signaling Interface 5

The following sections describe the messages and procedures for managing PMIP bindings between the 6

AGW and the eBS or SRNC. 7

The details in these following sections are organized as follows: 8

• PMIP Signaling Interface Network/Transport Protocol Specification 9

• PMIP Tunnel Establishment Procedures 10

• PMIP Signaling-Only Binding Procedures 11

• PMIP Registration Refresh Procedures 12

• PMIP Binding Release Procedures 13

• Procedure for PMIP-Registration Request Message Fields 14

15

2.5.1.1 PMIP Signaling Interface Network/Transport Protocol Specification 16

The protocol and signaling messages for the PMIP Signaling Interface are defined in [2]. PMIP-17

Registration Request and PMIP-Registration Reply messages shall be used for the establishment and 18

maintenance of the PMIP Binding(s) between the eBS(s), SRNC and the AGW. PMIP-Registration 19

Revocation and PMIP-Registration Revocation Ack messages shall be used for terminating PMIP binding 20

from the AGW. PMIP-Data Notification and PMIP-Data Notification Ack messages shall be used to 21

notify that the AGW has data for the AT when the AGW is buffering data. In this reference model, the 22

eBS performs Mobility Access Gateway (MAG) functions of PMIPv4 protocol. The AGW provides the 23

corresponding Local Mobility Anchor (LMA) capabilities [2]. 24

The UMB IOS protocol stack for the PMIP signaling interface is defined as follows. 25

26

PMIP Signaling UDP

IP


urers. The transport and message format of PMIP signaling messages are defined in [2]. 28

eBS/SRNC shall send all messages defined in PMIP interface to the IP endpoint of the AGW C-plane. 29

2.5.1.2 PMIP Tunnel Establishment 30

Any eBS in the Route Set of the AT may setup a PMIP binding with the AGW when the AT is active. 31

The SRNC for the AT may setup a PMIP binding with the AGW when the AT is idle. 32

PMIP-Registration Request message is sent from the eBS/SRNC to the AGW for setting up of the PMIP 33

Tunnel. The sub-sections that follow describe the setting up a PMIP Tunnel between the eBS/SRNC and 34

the AGW for the following operational scenarios: 35

1. Initial PMIP Tunnel Setup with the AGW. After the eBS receives the AGW identity and other 36

parameters from the SRNC, and after successful session configuration between the AT and the eBS, 37

the eBS is ready to assume the role of the DAP. In case of AT initiated DAP-assignment, the eBS 38

waits for the receipt of DAPMoveRequest message from the AT before initiating the establishment of 39

the PMIP tunnel. For AN-initiated DAP assignment, the eBS can initiate establishment of the PMIP 40

tunnel at this stage. Depending on whether support for multiple RL tunnels is Enabled or Not-Enabled 41

at the eBS, the eBS initiates establishment of a RL+Primary or Primary PMIP tunnel with the AGW 42

3GPP2 A.S0020-0 v1.0

2-44

respectively. eBS indicates to the AGW the establishment of an RL+Primary tunnel establishment by 1

including the Binding Type Extension CVSE in the PMIP-Registration Request message, with the 2

value set to RL+Primary Binding. eBS indicates to the AGW the establishment of a Primary tunnel 3

by not including a Binding Type Extension CVSE in the PMIP-Registration Request message. Refer 4

to [2] for the definition of the Binding Type Extension CVSE. 5

2. When the AT initiates procedures for adding the eBS to the Route Set by sending RouteOpenRequest 6

message. In case support for RL Tunnel is Enabled at the eBS, the eBS may initiate establishment of 7

an RL-Only PMIP Bearer tunnel with the AGW, by including the Binding Type Extension CVSE in 8

the PMIP-Registration Request message, with the value set to RL-Only Binding. 9

3. When an eBS wants to become a DAP, the eBS initiates establishment of a RL+Primary or a Primary 10

PMIP tunnel with the AGW, depending on whether support for RL Tunnel at the eBS is Enabled or 11

Not-Enabled respectively. 12

13

2.5.1.2.1 Initial PMIP Tunnel Setup with the AGW 14

This specification assumes that SRNC performs AGW selection for the AT if there is no existing PMIP 15

binding for the AT. After AGW selection, the SRNC receives the AT’s AAA-Session-ID and PMN-AN-16

RK1 key to be used in the PMIP binding signaling from the AGW during access authentication procedure. 17

The SRNC shall derive a PMN-AN-HA1 key as specified in [2]. The SRNC and the FLSE for the AT 18

exchange signaling messages, as detailed in section 2.2, in which the SRNC sends AGW identity and the 19

associated LinkID, AT’s AAA-Session-ID, PMN-AN-HA1 key and associated sequence number to the 20

FLSE where it can setup the initial PMIP binding with the AGW. Alternatively, the AAA-Session-ID and 21

PMN-AN-HA2 key may be obtained at the eBS via EAP Reauthentication Protocol [2]. 22

When the eBS decides to become initial DAP for the AT after power-up, the eBS sends a PMIP-23

Registration Request message to the AGW. The AGW may accept or reject the PMIP tunnel setup request 24

message. If PMIP tunnel setup request is acceptable, the AGW returns PMIP-Registration Reply message 25

with a registration accept indication, and a PMIP tunnel for this AT is established between the eBS/DAP 26

and the AGW. The fields in PMIP-Registration Request message shall be set according to procedure in 27

section 2.5.1.6. 28

2.5.1.2.1.1 Successful Operation 29

The eBS initiates setup of the PMIP Bearer tunnel by sending PMIP-Registration Request message to the 30

AGW and starts timer Trrq-pmip. The PMIP-Registration Request message is structured as specified in [11], 31

with various fields and parameters set as specified in section 2.5.1.6. 32

If PMIP Tunnel setup request is acceptable, the AGW updates its tunnel binding record for this AT, by 33

creating an association between the NAI of the AT and the IP address of the eBS. The AGW also assigns 34

a GRE Key (refer to [13]), specific to the AT and associates the GRE Key (refer to [13]) with the binding 35

record of this AT. In case the 3GPP2 specific Binding Type extension is not included in the PMIP-36

Registration Request message, the AGW allows the setup of Primary PMIP tunnel for this AT. If the 37

3GPP2 specific Binding Type extension included in the PMIP-Registration Request is RL+Primary, the 38

AGW sets up the RL+Primary PMIP tunnel for this AT. Other information in the binding record is set as 39

specified in [11]. 40

The AGW then returns a PMIP-Registration Reply message with a registration accept indication, 41

including the configured Lifetime for the PMIP Tunnel. The PMIP-Registration Reply message is 42

structured as specified in [11], with various fields and parameters set as specified in [2]. The Key field in 43

the GRE Key (refer to [13]) Extension is set to the GRE Key (refer to [13]) assigned to this AT. In case 44

the 3GPP2 specific Binding Type extension has been received in the PMIP-Registration Request message, 45

the PMIP-Registration Reply message includes the Binding Type extension as well, with the binding-46

type-value field set to the same value as received in the PMIP-Registration Request message. 47

3GPP2 A.S0020-0 v1.0

2-45

On receipt of a PMIP-Registration Reply message, the eBS stops timer Trrq-pmip. Receipt of a PMIP-1

Registration Reply message with an accept indication results in is the eBS/DAP also updating its tunnel 2

binding record for this AT, by creating an association between the NAI of the AT, the IP address of the 3

AGW and the assigned GRE Key (refer to [13]). In case the 3GPP2 specific Binding Type extension is 4

not included in the PMIP-Registration Reply message, the eBS allows the setup of Primary PMIP tunnel 5

for this AT. In case the 3GPP2 specific Binding Type extension is included in the PMIP-Registration 6

Reply message, the eBS allows the setup of RL+Primary PMIP Bearer tunnel for this AT. 7

Successful setup of the PMIP Bearer tunnel results in both the eBS and the AGW having a GRE Key 8

(refer to [13]) that is used as the identifying field for the transport of user bearer data between the eBS and 9

the AGW. The eBS becomes the DAP for the AT and sends IPT-Notification messages indicating that it 10

has become the DAP for the AT. The included DAP Record shall include information related to the 11

successful PMIP binding. Refer to section 2.3.5.1. 12

Refer to section 2.5.1.6 for the content of the PMIP-Registration Request message. 13

2.5.1.2.1.2 Failure Operation 14

The eBS/DAP initiates setup of the PMIP Bearer tunnel by sending PMIP-Registration Request message 15

to the AGW and starts timer Trrq-pmip. If the AGW does not accept the PMIP Bearer tunnel setup request, it 16

returns a PMIP-Registration Reply message with a reject result code. 17

If the AGW receives a PMIP-Registration Request message with a Binding Type Extension that it does 18

not support, the AGW discards the PMIP-Registration Request message. 19

On receipt of a PMIP-Registration Reply message, the eBS stops timer Trrq-pmip. If the eBS or SRNC 20

receives a valid PMIP-Registration Reply message before timer Trrq-pmip expires that indicates 21

identification mismatch error code (Code value 85H), the eBS or SRNC should adjust the clock that it 22

uses for communication with the AGW based on the returned identification field. It shall also start timer 23

Trrq-pmip. Upon expiration of the timer, the eBS or SRNC may retransmit the PMIP-Registration Request 24

message with a newly generated Identification field based on the procedure in section 2.5.1.6 and restart 25

timer Trrq-pmip. 26

On receipt of a valid PMIP-Registration Reply message with an unsuccessful result code other than 85H, 27

the DAP shall send an IPT-Notification message to the SRNC with lifetime set to zero. On the receipt of 28

the IPT-Notification message with Lifetime set to zero the SRNC invalidates the existing DAP Record. 29

Subsequently the SRNC may select an AGW, complete the EAP procedures with AT and new AGW. If 30

EAP authentication is successful, the SRNC should add the new AGW into the DAP record. Subsequently, 31

any eBS may establish a Primary PMIP binding with the AGW based on the updated DAP record. 32

On receipt of a PMIP-Registration Reply message with an accept indication (i.e., 00H) that does not 33

include expected extensions specified in [2] Part 100, e.g., GRE KEY Extension, or an included extension 34

is not valid, the DAP shall consider the call as failed after retransmitting the PMIP-Registration Request 35

message an implementation-dependent number of times and shall initiate the packet data session release 36

procedure. Refer to section 1.10.1.9. The DAP may also attempt to deregister with the AGW for an 37

implementation-dependent number of times. 38

As specified in [11], the PMIP-Registration Request message may be retransmitted if no PMIP-39

Registration Reply message is received within an implementation-dependent time. A call is considered to 40

have failed if no PMIP-Registration Reply message is received after an implementation-dependent 41

number of PMIP-Registration Request retransmissions. 42

2.5.1.2.2 eBS Added to the Route Set 43

When another eBS or an SRNC wants to perform PMIP Registration with the AGW after the initial PMIP 44

binding setup, the PMIP Registration Request message shall contain the same GRE key received in the 45

initial PMIP registration. The information necessary for subsequent PMIP registration is contained in the 46

DAP Record IE sent from SRNC to eBS in over IAS interface (refer to section 2.2). If the eBS supports 47

RL-only tunnel binding with the AGW, the eBS may perform RL-only tunnel setup and refresh with the 48

3GPP2 A.S0020-0 v1.0

2-46

AGW at anytime while it is in the route set or RL+Primary binding when it wants to become the DAP for 1

the AT. 2


When the eBS is successfully added into the route set, i.e., RouteOpenAccept message is sent to the AT 4

and the session already exists for the AT, and the eBS supports RL Tunnel binding, the eBS may initiate 5

establishment of an RL-Only PMIP Bearer tunnel with the AGW. The eBS initiates setup of the RL-only 6

PMIP Bearer tunnel by sending PMIP-Registration Request message to the AGW and starts timer Trrq-pmip. 7

The PMIP-Registration Request message is structured as specified in [11], with various fields and 8

parameters set as specified in section 2.5.1.6. 9

If RL-only PMIP Bearer Tunnel setup request is acceptable, the AGW updates its tunnel binding record 10

for this AT by creating an association between the NAI of the AT and an RL-Only binding for IP address 11

of the eBS. Other information in the binding record is set as specified in [11]. How the AGW manages the 12

binding record for the RL-only PMIP Bearer tunnel is left to vendor implementation and not specified in 13

this standard. 14

The AGW then returns a PMIP-Registration Reply message with an accept indication, including the 15

configured Lifetime for this RL-Only PMIP Tunnel. The PMIP-Registration Reply message is structured 16

as specified in [11], with various fields and parameters set as specified in section 2.5.1.6. The Key field in 17

the GRE Key (refer to [13]) Extension is set to the Key field received in the PMIP-Registration Request 18

message. The Binding Type extension is included as well, with the binding-type-value field set to the 19

same value as received in the PMIP-Registration Request message. 20

On receipt of a PMIP-Registration Reply message, the eBS stops timer Trrq-pmip. Receipt of a PMIP-21

Registration Reply message with a accept indication results is the eBS also updating its tunnel binding 22

record for this AT, by creating an association between the NAI of the AT, and an RL-Only binding for the 23

IP address of the AGW. The eBS may tunnel RL IP packets to the AGW in the established tunnel. 24


The eBS initiates setup of the RL-only PMIP Bearer tunnel by sending PMIP-Registration Request 26

message to the AGW and starts timer Trrq-pmip. If the AGW does not accept the RL-only PMIP Bearer 27

tunnel setup request, it returns a PMIP-Registration Reply message with a reject result code. 28

If the AGW receives a PMIP-Registration Request message with a Binding Type Extension that it does 29

not support, the AGW discards the PMIP-Registration Request message. 30

If the eBS receives a valid PMIP-Registration Reply message before timer Trrq-pmip expires that indicates 31

identification mismatch error code (Code value 85H) with the RL-only binding type, the eBS should 32

adjust the clock that it uses for communication with the AGW based on the returned identification field. It 33

shall also start timer Trrq-pmip. Upon expiration of the timer, the eBS may retransmit the PMIP-34

Registration Request message with a newly generated Identification field based on the procedure in 35

section 2.5.1.6 and restart timer Trrq-pmip. 36

On receipt of all other unsuccessful PMIP-Registration Reply messages, the eBS stops timer Trrq-pmip and 37

may retry registering its RL-Only binding with the AGW again an implementation-dependent number of 38

times. 39


Registration Reply is received within an implementation-dependent time. Attempt to set up RL-only 41

PMIP Bearer tunnel is abandoned if no PMIP-Registration Reply is received after an implementation-42

dependent number of PMIP-Registration Request retransmissions. 43

2.5.1.2.3 eBS Becomes the DAP 44

In the AN-initiated DAP Handoff, any eBS in the route set of the AT may become the DAP for the AT 45

and initiate PMIP binding setup at anytime. In the AT-assisted DAP Handoff, an eBS shall initiate PMIP 46

3GPP2 A.S0020-0 v1.0

2-47

binding setup only after receipt of the DAPMoveRequest message. If the eBS wants to become DAP in 1

the AT-assisted DAP Handoff, the eBS shall send DAPMoveRequestRequest message to the AT to 2

trigger DAPMoveRequest message from the AT. Refer to [1]. 3

The message procedure for PMIP-Registration Request in this scenario is identical to the initial PMIP 4

Tunnel setup procedure except the inclusion of the GRE key. Refer to section 2.5.1.6. In this case, the 5

PMIP-Registration Request message shall contain the GRE key assigned by the AGW to the session, as 6

received in the DAP Record IE from SRNC to eBS over the IAS interface 2.2. 7

If the eBS already has established an RL-only tunnel binding with the AGW and is to become the DAP 8

for the AT, the eBS shall include the Binding Type Extension CVSE set to value RL+Primary Binding in 9

the PMIP-Registration Request message sent to the AGW. If the request from eBS to become the new 10

DAP for the AT fails, then the RL-only eBS-AGW tunnel shall remain and the existing DAP shall remain 11

the DAP for the AT. 12

2.5.1.3 PMIP Signaling-Only Binding 13

2.5.1.3.1 PMIP Signaling-Only Binding Establishment Procedures 14

An eBS or SRNC sends a PMIP-Registration Request message for PMIP Signaling-Only binding to 15

request that the AGW begin buffering forward link bearer packets for the AT. Such a request may be sent 16

from SRNC or from an eBS. The message procedure for PMIP-Registration Request in this scenario is 17

identical to the initial PMIP Tunnel setup procedure except the inclusion of the GRE key and Signaling-18

Only binding type. Refer to section 2.5.1.6. Upon accepting a Signaling-Only binding for an AT, the 19

AGW initiates release of any other Signaling-Only or Primary bindings for that AT and any existing 20

RL+Primary binding will become RL-Only. 21

From an AGW perspective, existence of the Signaling-Only binding type indicates that the AGW buffers 22

forward link packets for the AT. For a given AT, existence of a Signaling-Only binding is mutually 23

exclusive with any other Primary binding at that AGW. One or more RL-Only bindings may co-exist with 24

a Signaling-Only binding. 25

2.5.1.3.2 PMIP Signaling-Only Binding Configuration 26

A PMIP Signaling-Only binding may be used either between the SRNC-AGW or between the eBS-AGW 27

to indicate to the AGW to start buffering the data for the AT. 28

2.5.1.3.3 AGW Sends Data Notification to SRNC or eBS 29


Upon receipt of forward link data for an AT with a Signaling-Only binding, the AGW buffers the data 31

and sends a PMIP-Data Notification message to the eBS or SRNC that has the PMIP-Signaling-Only 32

binding with the AGW. Upon receipt of the PMIP-Data Notification message, the receiver shall respond 33

with a PMIP-Data Notification Ack message with ‘success’ status code. The PMIP-Data Notification 34

message has been successfully delivered when the AGW receives the PMIP-Data Notification Ack 35

message. 36


None. 38

2.5.1.4 PMIP Registration Refresh 39

2.5.1.4.1 PMIP Registration Refresh Procedures 40

The eBS or SRNC periodically refresh their PMIP bindings with the AGW by sending PMIP-Registration 41

Request message. Such periodic re-registration messages are sent for all type of PMIP bindings, e.g., 42

Primary, RL+Primary, RL-only and Signaling-Only PMIP bindings. An entity (e.g., eBS or SRNC) that 43

3GPP2 A.S0020-0 v1.0

2-48

has PMIP binding with the AGW should refresh its binding with the AGW before the PMIP binding 1

lifetime expires. 2


The eBS or SRNC refresh the PMIP binding with the AGW by sending the PMIP-Registration Request 4

message before the PMIP registration lifetime expires, as per procedures in [11]. The PMIP-Registration 5

Request message shall set or exclude the 3GPP2 specific Binding Type extension with binding-type-value 6

set to the type of tunnel being refreshed. The AGW returns the PMIP-Registration Reply message with an 7

accept indication, including the refreshed Lifetime timer value of the PMIP binding. The 3GPP2 specific 8

Binding Type extension is included in the PMIP-Registration Reply message if and as received in the 9

PMIP-Registration Request message. 10

The message procedure for PMIP-Registration Request in this scenario is identical to the initial PMIP 11

Tunnel setup procedure except the inclusion of the GRE key. Refer to section 2.5.1.6. 12



Registration Reply message is received within an implementation-dependent time. If no PMIP-15

Registration Reply message is received after an implementation-dependent number of PMIP-Registration 16

Request re-transmissions, the PMIP binding is released. If the binding type is RL+Primary, Signaling-17

Only or Primary, the eBS or SRNC shall initiate Packet Data Session Release procedure (refer to section 18

2.3.5.1.1.11. If the type of the binding is RL-Only, the eBS shall clear the expired binding and commence 19

forwarding any RL data received from the AT to the DAP. If the AGW allows RL-Only tunnels for a 20

session, upon expiration of the lifetime of an RL-Only tunnel, the AGW clears the binding information 21

for this tunnel only and retains the rest of the packet data session information. If authentication-failed 22

error Code is received in a PMIP-Registration Reply message during registration refresh of RL+Primary, 23

Signaling-Only or Primary binding, the packet data session is released on expiration of the lifetime. If the 24

eBS or SRNC receives a valid PMIP-Registration Reply message before timer Trrq-pmip expires that 25

indicates identification mismatch error code (Code value 85H), the eBS or SRNC should adjust the clock 26

that it uses for communication with the AGW based on the returned identification field. It shall also start 27

timer Trrq-pmip. Upon expiration of the timer, the eBS or SRNC may retransmit the PMIP-Registration 28

Request message with a newly generated Identification field based on the procedure in section 2.5.1.6 to 29

refresh the tunnel again and restart timer Trrq-pmip. 30

2.5.1.5 PMIP Binding Release 31

2.5.1.5.1 eBS or SRNC-Initiated PMIP Tunnel Release Procedures 32

An entity (eBS or SRNC) with an existing PMIP binding of type Primary or Signaling-Only should clear 33

its internal resources related to the PMIP binding upon receipt of an IPT-Notification message containing 34

a DAP Record IE (and should not send deregistration to the AGW) because the entity assumes that the 35

AGW has autonomously removed this entity’s binding. 36

An entity (eBS) with an existing PMIP binding of type RL+Primary will become RL-Only on receipt of 37

an IPT-Notification message containing a DAP Record IE (and should not send deregistration of the 38

Primary binding to the AGW) because the entity assumes that the AGW has autonomously changed this 39

entity’s binding to RL-Only. 40

An existing PMIP binding of type RL-Only at an entity (eBS) is not affected by an IPT-Notification 41

message containing a DAP Record IE. 42

When the eBS that has RL-Only binding with the AGW is removed from the route set, the eBS shall 43

deregister its RL-Only binding with the AGW, except if the UMB session or the packet data session is 44

released. 45

3GPP2 A.S0020-0 v1.0

2-49

During the inter-AGW handoff, the eBS that has a PMIP binding with the source AGW may initiate 1

PMIP binding release procedures with the source AGW after an IPT-Notification message indicating that 2

a new DAP has established PMIP binding with the target AGW. Deterministic methods to handle the 3

transport of in-flight packets and the packets still buffered at the (old) source AGW before removing any 4

existing PMIP bindings at the source AGW are for further study. 5

When UMB session has been released or IAS-Session Release message is received, the eBS or SRNC 6

shall initiate release of all existing PMIP bindings with the AGW. 7


The eBS or SRNC initiates release of the PMIP binding by sending a PMIP-Registration Request message 9

with Lifetime field set to ‘zero’, and starts timer Trrq-pmip. The PMIP-Registration Request message is 10

structured as specified in section 2.5.1.6. 11

On receipt of a PMIP-Registration Request message with Lifetime set to ‘zero’; and either without 3GPP2 12

specific Binding Type extension, or with 3GPP2 Binding Type extension; the AGW verifies if its PMIP 13

binding for this AT points to the entity that has sent the PMIP-Registration Request message with 14

Lifetime set to ‘zero’. If so, the AGW responds with a PMIP-Registration Reply message with Lifetime 15

set to ‘zero’ and registration accept indication. 16

On receipt of a PMIP-Registration Reply message, the eBS or SRNC stops timer Trrq-pmip. Receipt of a 17

PMIP-Registration Reply with an accept indication results is the eBS also removing the binding for this 18

AT and initiate procedure for packet data session release (refer to section 2.3.5.1.1.11). 19


On failure to receive a PMIP-Registration Reply in response to an implementation-dependent number of 21

PMIP-Registration Request re-transmissions, the eBS or SRNC remove its binding for the AT and initiate 22

procedure for packet data session release (refer to section 2.3.5.1.1.11). In case the AGW does not receive 23

a valid PMIP-Registration Request message for renewing the registration before the tunnel lifetime 24

expires, the AGW also removes the binding for the AT. 25

2.5.1.5.2 AGW-Initiated PMIP Tunnel Release Procedures 26

The AGW may revoke its PMIP binding with the eBS or SRNC using PMIP Registration Revocation 27

message [12]. The AGW includes the appropriate binding type corresponding to the current binding type 28

at the eBS or SRNC in the PMIP Registration Revocation message. 29


When the eBS or SRNC receive a valid PMIP-Registration Revocation message, it responds with PMIP-31

Registration Revocation Ack message. The eBS or SRNC shall also initiate packet data session release 32

procedure upon receipt of the valid PMIP-Registration Revocation message. 33


None. 35

2.5.1.6 Procedure for PMIP Registration Request Message Fields 36

The eBS/SRNC shall formulate the PMIP Registration Request message to be transmitted to the AGW as 37

follows: 38

1. The Home Address field shall be set to all zeros. 39

2. The IP source address (IP header) and the Care-of-Address field of the PMIP-Registration Request 40

message are set to the PMIP Interface IP address of the eBS/SRNC. 41

3GPP2 A.S0020-0 v1.0

2-50

3. The IP destination address in the IP header and the Home Agent field in the PMIP-Registration 1

Request are set to the PMIP Signaling Interface IP address of the AGW that was in the DAP Record 2

IE received from the SRNC. 3

4. GRE extension as specified in [13] shall be included: 4

a. If PMIP binding for the AT does not exist at the AGW, i.e., the DAP Information in the DAP 5

record received from the SRNC is null, then the eBS set the GRE key extension in the PMIP-6

Registration Request message with the GRE key value set to a special value (all zeros) to request 7

the AGW to assign a symmetric GRE key used for both forward direction and reverse direction. 8

b. If PMIP binding for the AT already exists at the AGW, i.e., the DAP Information in the DAP 9

record received from/available at the SRNC contains a non-null value, then the eBS/SRNC sets 10

the GRE key extension in the PMIP-Registration Request message with the GRE key value 11

included in the GRE key field corresponding to this AGW entry in the DAP record received from 12

the SRNC. 13

5. For PMIP binding establishment and refresh, the Lifetime field is set to an implementation-dependent 14

non-zero value. For PMIP binding teardown, the Lifetime field is set to zero. 15

6. The Identification field in the PMIP-Registration Request is used for matching PMIP-Registration 16

Requests with PMIP-Registration Replies and also for protecting against replay attacks of registration 17

messages. Timestamp based replay protection method (refer to section 5.7, [11]) is used in this 18

standard. 19

a. The identification field in a PMIP-Registration Request from the eBS or SRNC to the AGW shall 20

be set to a timestamp value which is determined as follows: 21

• If the timestamp of the last successful PMIP-Registration Request message is available 22

(either from the last received IPT-Notification (DAP), its own PMIP-Registration Request 23

message, or from the DAP record received from the SRNC) and is less than the current time 24

at the eBS or SRNC or if the timestamp is not available, then the timestamp shall be set to the 25

current time at the eBS or SRNC. 26

• Otherwise, the timestamp shall be set to a value greater than the timestamp of the last 27

accepted PMIP-Registration Request message. 28

7. If ERP is not used at the eBS, the MN-HA Authentication Extension is set based on the received 29

PMN-AN-HA1 key from the SRNC. The 28 LSBs of the SPI field in the MN-HA Authentication 30

Extension shall be set to the PMN-AN-HA1 Sequence Number received from the SRNC and the 4 31

MSBs of the SPI field shall be set based on the eBS capability. Refer to [2]. If ERP is used at the eBS, 32

the MN-HA Authentication Extension shall be set based on the PMN-AN-HA2 key received from the 33

AGW during ERP procedure. The SPI field shall be set to the value received from PMN-AN-SPI 34

attribute from the AGW during ERP procedure. Refer to [2]. 35

8. The NAI of the AT is included in the Mobile IP Network Access Identifier Extension [7] of the 36

PMIP-Registration Request message. The eBS forms PMIP NAI in the format of username@realm 37

where realm is the realm portion of the EAP NAI and username is the ASCII hex representation of 38

the AAA-Session-ID received from the SRNC in the IAS-DAP Record IE. 39

If an eBS supports establishment of multiple RL-Only tunnels then the eBS constructs the PMIP-40

Registration Request message as follows: 41

a. If the eBS wants to become DAP for an AT then binding-type-value is set to ‘RL+Primary’. Any 42

existing PMIP bindings at any other eBS/SRNC for this AT gets modified (without explicit 43

signaling with AGW) as mentioned below. AGW autonomously modifies the corresponding 44

PMIP bindings at its end. 45

o RL+Primary binding becomes RL-Only. 46

o Primary binding (Binding with no specific Binding type extension in PMIP PMIP-47

Registration Request message) is cleared. 48

3GPP2 A.S0020-0 v1.0

2-51

o Signaling-Only binding is cleared. 1

o RL-Only binding remains unaffected. 2

b. If the eBS/SRNC wants to establish a Signaling-Only binding, the binding-type-value is set to 3

Signaling-Only. Any existing PMIP bindings at any other eBS/SRNC for this AT gets modified 4

(without explicit signaling with AGW) as mentioned below. AGW autonomously modifies the 5

corresponding PMIP bindings at its end. 6






c. If the eBS wants to establish RL-Only binding then binding-type-value is set to ‘RL-Only’. The 12

establishment of RL-Only binding does not have any impact on any existing PMIP bindings 13

between the eBS/SRNC and the AGW for the AT. 14

If an eBS does not support establishment of multiple RL-Only tunnels then the eBS constructs the PMIP-15

Registration Request message as follows: 16

a. If the eBS wants to become DAP then the binding-type extension is not included in the PMIP-17

Registration Request. Any existing PMIP bindings at any other eBS/SRNC for this AT gets 18

modified (without explicit signaling with AGW) as mentioned below. AGW autonomously 19

modifies the corresponding PMIP bindings at its end. 20






b. If the eBS/SRNC wants to establish a Signaling-Only binding, the binding-type-value is set to 26

Signaling-Only. Any existing PMIP bindings at any other eBS/SRNC for this AT gets modified 27

(without explicit signaling with AGW) as mentioned below. AGW autonomously modifies the 28

corresponding PMIP bindings at its end. 29






The SRNC shall formulate the PMIP Registration Request message to be transmitted to the AGW as 35

follows: 36

1. The Home Address field shall be set to all zeros. 37

2. The IP source address (IP header) and the Care-of-Address field of the PMIP-Registration Request 38

message are set to the PMIP Interface IP address of the SRNC. 39

3. The IP destination address in the IP header and the Home Agent field in the PMIP-Registration 40

Request are set to the PMIP Interface IP address of the AGW which is contained in the DAP Record 41

IE. 42

4. GRE extension as specified in [13] shall be included and is set to the GRE key value included in the 43

GRE key field corresponding to this AGW entry in the DAP record. 44

5. For PMIP binding establishment and refresh, the Lifetime field is set to an SRNC configured non-45

zero value. For PMIP binding teardown, the Lifetime field is set to zero. 46

6. Refer to item 6 above for the eBS case. 47

3GPP2 A.S0020-0 v1.0

2-52

7. If ERP is not used at the eBS, the MN-HA Authentication Extension is set based on the received 1

PMN-AN-HA1 key from the SRNC. The 28 LSBs of the SPI field in the MN-HA Authentication 2

Extension shall be set to the PMN-AN-HA1 Sequence Number received from the SRNC and the 4 3

MSBs of the SPI field shall be set based on the eBS capability. Refer to [2]. If ERP is used at the eBS, 4

the MN-HA Authentication Extension shall be set based on the PMN-AN-HA2 key received from the 5

AGW during ERP procedure. The SPI field shall be set to the value received from PMN-AN-SPI 6

attribute from the AGW during ERP procedure. Refer to [2]. 7

8. The NAI of the AT is included in the Mobile IP Network Access Identifier Extension [7] of the 8

PMIP-Registration Request message. The eBS forms PMIP NAI in the format of username@realm 9

where realm is the realm portion of the EAP NAI and username is the ASCII hex representation of 10

the AAA-Session-ID received from the SRNC in the IAS-DAP Record IE. 11

9. The 3GPP2 specific Binding Type extension in the PMIP-Registration Request message shall be 12

included [2] and the binding-type-value is set to ‘Signaling-Only’. 13

14

2.5.2 PMIP Bearer Interface 15

This interface allows for tunneling of user IP packets between the AGW and the eBS. The PMIP bearer 16

interface is part of the U1 reference point. The PMIP bearer interface protocol stack is shown in Table 17

2.5.2-1. The Generic Route Encapsulation (GRE) protocol is used to provide a tunnel for bearer traffic 18

between the eBS and the AGW. The tunnel is set up using PMIP messages. 19

Table 2.5.2-1 Data Protocol Stack 20

eBS-AGW Application User Data (e.g. IP

datagram) GRE

IP (access network internet)

The PMIP bearer interface message uses the GRE protocol as defined in [5] and extended in [7]. The 21

underlying physical transport medium under IP is left to the discretion of operators and manufacturers. 22

IP network layer packets carried between the eBS and the AGW are encapsulated in GRE packets, which 23

in turn are carried over IP. The eBS network-layer IP Address and the AGW access-network layer IP 24

Address are used in the source address and destination address fields of the IP header used with the GRE 25

packet. 26

GRE encapsulates user traffic as shown in Figure 2.5.2-1. 27

GRE Frame GRE Header GRE Payload User Traffic

Figure 2.5.2-1 GRE Encapsulated User Traffic 28

Figure 2.5.2-2 shows the structure of the 3GPP2 GRE Header. 29

3GPP2 A.S0020-0 v1.0

2-53

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1C r K S Reserved Ver Protocol Type

Key Sequence number (Conditional)

Figure 2.5.2-2 3GPP2 GRE Header 1

The 3GPP2 GRE header shall be encoded as follows: 2

C (Checksum Present) ‘0’ 3

r (reserved) ‘0’ 4

K (Key Present) ‘1’ 5

S (Sequence Number Present) ‘0 or 1’ 6

The AGW shall set the S indicator to ‘1’ for forward link data if the 7

AGW is configured to include sequence number. Otherwise, the AGW 8

shall set the S indicator to ‘0’ for forward link data. The eBS shall set the 9

S indicator to ‘1’ for reverse link data if the eBS is configured to include 10

sequence number. Otherwise, the eBS shall set the S indicator to ‘0’. 11

Reserved ‘000000000’ 12

Ver (Version Number) ‘000’ 13

Protocol Type ’08 00H’ for IPv4 packet 14

‘86 DDH’ for IPv6 packet 15

If the receiving entity does not recognize the value of this field, it should 16

discard the GRE frame. 17

Key The Key field contains a four-octet number. The Key field is used for 18

identifying an individual PMIP bearer interface. The Key is exchanged 19

via initial PMIP setup between an eBS and an AGW. 20

In the bearer traffic direction from the AGW to the eBS, the key field in 21

the GRE header contains the Session Identifier (SID) that indicates to 22

which a set of eBS-AGW connections a particular payload packet 23

belongs. An eBS-AGW connection is defined as a bearer association 24

between an eBS and an AGW. Multiple eBS-AGW connections can be 25

associated with an AT if multiple binding is applied. 26

In the bearer traffic direction from the eBS to the AGW, the key field in 27

the GRE header contains the identical SID. 28

Sequence number If the link layer/network layer protocol requires that the GRE packets be 29

delivered in sequence (e.g. if a state-full compression mechanism is in 30

use) over the connection or receiver of the GRE packet needs to detect 31

packet loss or out-of-order delivery, the S indicator shall be set to ‘1’ and 32

the sequence number field shall be included in each GRE packet sent 33

over the connection. The eBS shall be capable of set S bit to ‘1’. The 34

sequence number field may be used for in-order delivery of the 35

encapsulated user data. For each GRE connection (identified by the Key 36

field) and direction, the sending and receiving entities shall each 37

maintain at most one Sequence Number counter independent of the 38

3GPP2 A.S0020-0 v1.0

2-54

Protocol Type field. When the sequence number field is included, the 1

sender and receiver shall perform the following: 2

• The sequence numbers shall be set to zero after the connection is 3

established. 4

• The sequence number shall be incremented according to [7] in each 5

subsequent packet sent on the same connection (i.e., there is no 6

dependency on the GRE sequence number between eBSs). 7

• Out of sequence packet handling is optional. If performed, receipt 8

and processing of an out-of-sequence packet on a connection shall be 9

handled according to [7]. 10

2.5.2.1 PMIP Bearer Interface Procedure 11

After establishment of the Primary or RL+Primary PMIP binding, user data traffic (inclusive of upper 12

layer signaling and bearer traffic) can pass over the connection in both directions via GRE framing. For 13

the case of RL-only binding, the user data transport is supported only in the eBS to AGW direction. The 14

AGW accepts these GRE frames, strips the GRE header, and processes the incoming user traffic as 15

appropriate. For the case of Primary and RL+Primary tunnels, the other direction behaves analogously, 16

with the AGW encapsulating the user data traffic in GRE, and the eBS/DAP stripping the GRE header 17

before passing the user data traffic to the AT or tunneling to another eBS. Refer to sections 2.3 and 2.4. 18

If the eBS is notified of a U-plane IP endpoint in a PMIP-Registration Reply message, the eBS shall send 19

reverse link packets to the U-plane IP endpoint at the AGW. If the eBS is not notified of the U-plane IP 20

endpoint in the PMIP-Registration Reply message, eBS shall treat the C-plane IP endpoint as the U-plane 21

IP end point. 22

23

2.6 AAA (Authentication, Authorization and Accounting) Interface 24

This interface allows performing authentication, authorization and accounting. This interface is part of U1 25

and U6 reference points. The AAA interface is based on the Remote Authentication Dial-In User Service 26

(RADIUS) protocol as defined in [8], and [9]. The interface is shown in Figure 1.4-1. 27

The requirements for AAA interface for authentication are specified in [2]. 28

eBS/SRNC shall send all messages defined in AAA interface to the IP endpoint of the AGW C-plane. 29

The AAA interface for accounting consists of the following messages: 30

• Accounting-Request 31

• Accounting-Response 32

The AAA protocol stack is shown in Table 2.6-1. 33

Table 2.6-1 AAA Protocol Stack 34

RADIUS UDP

IP

35

2.6.1 Accounting Requirements 36

• An ANRI identify a reservation for a particular AT by a combination of the EAP NAI, AAA-Session-37

ID, the reservation label and direction indicator. This identification information is contained in the 38

Airlink Data Record (ADR) reported to the AGW. Accounting messages using the RADIUS protocol 39

with vendor specific attributes shall be supported by the eBSs. Refer to [2]. 40

3GPP2 A.S0020-0 v1.0

2-55

• Every eBS in an AT’s route set shall be capable of performing Per Reservation accounting for each 1

reservation. 2

• The ANRI that forms link-layer packets shall count forward IP packets and octets for each forward 3

reservation when the reservation is open. The ANRI that assembles IP packets (from link-layer 4

packets) shall count reverse IP packets and octets for each reverse reservation when the reservation is 5

open. The accounting information shall be based on uncompressed IP packets and octets for both 6

forward and reverse directions. 7

2.6.2 Accounting Report Procedure 8

2.6.2.1 Successful Operation 9

Accounting information, i.e., Airlink Data Record (ADR), is sent from an ANRI to the AGW via AAA-10

Accounting-Request message upon the following conditions: 11

• An ANRI shall send an AAA-Accounting-Request message with Acct-Status-Type = Start when the 12

first reservation (including best-effort) is able to send IP packets. 13

• An ANRI shall send an AAA-Accounting-Request message with Acct-Status-Type = Stop when there 14

are no remaining reservation(s) that can send IP packets after AAA-Accounting-Request message 15

with Acct-Status-Type = Start has been sent. 16

• An ANRI may send an AAA-Accounting-Request message with Acct-Status-Type = Interim-Update 17

to the AGW to report accounting information on a periodic basis. The interim reporting period should 18

begin at the successful AAA-Accounting-Request (Start) exchange for the accounting session at the 19

ANRI. The frequency of interim reports is based on local policy, or interim interval information 20

received from the AGW in (ACCT-Interim-Interval attribute). Note: The frequency of interim reports 21

expected by the HAAA should be delivered to the AGW when a user’s profile is delivered. This 22

information should be sent to the SRNC and stored as part of the user’s session information. An 23

ANRI shall generate reports for all the reservations of the user’s session at an interval as indicated by 24

the ACCT-Interim-Interval attribute. If the interim frequency is absent, the ANRI shall generate 25

reports as dictated by a local policy. 26

Upon sending the AAA-Accounting-Request message, the ANRI starts timer Tacct-aaa and awaits receipt 27

of a corresponding AAA-Accounting-Response message. Upon receipt of the AAA-Accounting-Response 28

message, the ANRI stops timer Tacct-aaa. 29

2.6.2.2 Failure Operation 30

If timer Tacct-aaa expires, the ANRI may resend the AAA-Accounting-Request message to the AGW and 31

restart timer Tacct-aaa an implementation-dependent number of times. If the AAA-Accounting-Response 32

message is not received from the AGW, the ANRI should close its connection with the AT. 33

34

3GPP2 A.S0020-0 v1.0

2-56


2

3

3GPP2 A.S0020-0 v1.0

3-1

3 UMB IOS Call Flows 1

This section describes the call flows associated with a UMB AT. Air interface messages and message 2

sequences shown in the message flows in this document are informative only. It is possible that different 3

air interface messages or different sequences of air interface messages may provide equivalent or better 4

functionality. It is also possible that the use of one or more of the air interface messages may become less 5

desirable 6

3.1 AT-Initiated Origination and Call Re-activation 7

This section describes the call flows associated with AT power up and AT-initiated call re-activation from 8

idle state. 9

3.1.1 AT Originates UMB Session 10

This scenario describes the call flow where the AT performs authentication and negotiates a UMB session 11

in order to receive IP data services. This call flow assumes that AGW selection is performed by the 12

SRNC during access authentication. This call flow assumes that the AT does not have a UMB session at 13

the beginning of the call flow. 14

15

3GPP2 A.S0020-0 v1.0

3-2

timeAT eBS1 AGWSRNC

UATIComplete

RouteMap

RouteOpenAccept (UATI)

RouteOpenRequest

RouteOpenAccept

RouteOpenRequest (RATI)

g

k

e

c

d

b

a

l

RouteCreate (SRNC AN ID)

RouteMap

i

** = conditional

cc

z

ii

kk

PMIP-Registration Reply

ll

mm

DAPAssignment

Data

y

Data

Session Configuration

DAPMoveRequest

PMIP-Registration Request

x

w

t

u

SessionUpdated (Session Signature)

ConfigStart

Tsir-iasIAS-Session Info Request

IAS-Session Info Response

RouteMapRequest

RouteMap

o*

IP address assignment

Key exchange

Key exchange

EAP access authentication

Tuupd-iasIAS-UATI Update Ack

IAS-UATI Update (UATI, SSID)

m

n

SessionUpdated (Session Signature)

dd*

p**

LinkIDAssignment


v

* = optional

Trrq-pmip

AAA-Accounting-Request (Start)

AAA-Accouting-Response

IPT-Notification Ack

IPT-Notification jjTnot-ipt

hh

ggTacct-aaa

ff

ee

SessionUpdated (new Session Signature) bb

ConfigComplete (new Session Signature)

IAS-Session Information Update Request (Session)

IAS-Session Information UpdateResponse (new Session Signature)

Tsur-ias

aa

s

r

q

Tnot-ipt


IPT-Notification

j

f

h

1

Figure 3.1.1-1 AT Originates UMB 2

The UMB air-interface allows the eBS to use its ANRI as the Session Anchor ANRI. In that implemen-3

tation option, steps ‘c’-‘g’, ‘i’-‘l’, ‘o’-‘q’, ‘t’-‘bb’, ‘jj’-‘kk’, are omitted. 4

a. When the AT without a UMB session accesses the UMB system, e.g., the AT powers up after its 5

UMB session has expired, the AT sends a RouteOpenRequest message using RATI to open a route 6

with eBS1. 7

3GPP2 A.S0020-0 v1.0

3-3

b. Upon receipt of the RouteOpenRequest message from the AT, eBS1 creates a route for the AT and 1

sends a RouteOpenAccept message to the AT. eBS1 is configured to create a session in the SRNC 2

therefore it does not allocate UATI in the RouteOpenAccept message. 3

c. eBS1 selects the SRNC based on the SRNC selection algorithm outside the scope of this specification 4

and then sends a RouteCreate message to the AT to trigger the AT to create a route with the SRNC. 5

The message contains the ANID of the SRNC. This step can occur in parallel with step ‘b’. 6

d. The AT sends a RouteOpenRequest message with the RouteOpenRequestReason field set to 7

'Response to RouteCreate message' to the SRNC via eBS1. The LLT tunneling header includes RATI 8

to identify the AT and Route ID to identify the route at the AT. 9

e. Upon receipt of the tunneled RouteOpenRequest message, the SRNC tunnels the RouteOpenAccept 10

message back to AT through eBS1 to complete the route open procedure with the AT. The message 11

contains the UATI that the SRNC assigns for the AT. The LLT tunneling header includes RATI to 12

identify the AT and Route ID to identify the Session Anchor route at the AT. 13

f. Upon receipt of the RouteOpenAccept message, the AT sends the updated RouteMap to eBS1. 14

g. Upon receipt of the RouteOpenAccept message, the AT also sends the updated RouteMap to the 15

SRNC. 16

h. Upon assignment of the new UATI, the AT sends a UATIComplete message to the SRNC to 17

acknowledge that the new UATI is now being used by the AT. 18

Upon receipt of the UATIComplete message, the SRNC sends an IAS-UATI Update message to all ANRI 19

in the Route Set. The message contains the UATI assigned to the AT (or the RATI, if the update is being 20

sent as a result of assigning a UATI to an AT that previously had no UATI) and also the SSID of the AT. 21

Upon receipt of the IAS-UATI Update message, all ANRIs use SSID as the identity of the AT instead of 22

RATI. 23

i. The SRNC sends an IAS-UATI Update message to eBS1 and starts timer Tuupd-ias. 24

j. Upon receipt of the IAS-UATI Update message, eBS1 responds with an IAS-UATI Update Ack. 25

Upon receipt of the IAS-UATI Update Ack message, the SRNC stops timer Tuupd-ias. 26

k. eBS1 sends an IPT-Notification message to the SRNC indicating eBS1 is FLSE and starts timer Tnot-27

ipt.The message contains the ANID of the eBS1 which is the FLSE. Step ‘k’ can occur anytime after 28

step ‘f’. 29

l. Upon receipt of the IPT-Notification message, the SRNC sends an IPT-Notification Ack message to 30

the eBS1. The eBS1 stops timer Tnot-ipt. 31

m. Upon receipt of the IAS-UATI Update Ack message, the SRNC initiates EAP authentication with the 32

AT through the AGW. The SRNC selects the AGW. Refer to section 2.5.1.2.1. This step occurs 33

anytime after the step ‘h’. 34

n. Upon the successful EAP authentication, the SRNC initiates key exchange procedure with the AT to 35

exchange the security key for this route. 36

o. Upon completion of the key exchange in step ‘n’, message exchanges between the AT and the SRNC 37

are now secured. The SRNC may send a RouteMapRequest message to the AT to request a secured 38

RouteMap for the AT. 39

p. Upon receipt of the RouteMapRequest message, the AT sends a RouteMap message to the SRNC to 40

update the route mapping at the SRNC. 41

q. The SRNC sends a ConfigStart message to the AT to initiate configuration of the Session Anchor 42

route with the AT. 43

r. The SRNC and the AT performs the Session Anchor route configuration. 44

3GPP2 A.S0020-0 v1.0

3-4

s. Upon completion of the session configuration, the AT sends a SessionUpdated message to eBS1. This 1

message contains the new session signature of the AT. 2

t. Upon completion of the session configuration, the AT sends a SessionUpdated message to the SRNC. 3

This message contains the new session signature of the AT. 4

u. Upon receipt of the SessionUpdated message from the AT with the new session signature, eBS1 5

sends an IAS-Session Information Request message to the SRNC and starts timer Tsir-ias. 6

v. Upon receipt of the IAS-Session Information Request message, the SRNC responds with an IAS-7

Session Information Response message. This message contains the session of the AT and the DAP 8

record including the selected AGW identity, its LinkID and null DAP Information, which informs 9

eBS1 that it should become the DAP. Upon receipt of the IAS-Session Information Response 10

message, eBS1 stops timer Tsir-ias. 11

w. Upon receipt of the session of the AT, eBS1 initiates key exchange procedure with the AT. 12

x. eBS1 initiates session configuration for personality associated with eBS1 after receiving the session 13

from the SRNC. Refer to section 3.4.2. 14

Note: Session configuration can only occur after access authentication and completion of key exchange. 15

y. eBS1 sends an IAS-Session Information Update Request message to the SRNC with the session 16

information and start timer Tsur-ias. 17

z. The SRNC responds with an IAS-Session Information Update Response message which includes the 18

new session signature. Upon receipt of the IAS-Session Information Update Response message, eBS1 19

stops timer Tsur-ias. 20

aa. eBS1 sends a ConfigurationComplete message to the AT to indicate that the session has been updated. 21

The message contains the new session signature assigned by the SRNC. 22

bb. The AT notifies all ANRIs in the Route Set of the updated session by sending a SessionUpdated 23

message with the new session signature to each ANRI in the Route Set. 24

cc. Upon receipt of the session of the AT, eBS1 also assigns the Link ID for the AT so that the AT can 25

start IP service. This step may occur anytime after step ‘v’. 26

dd. Upon assignment of the Link ID, if the AT is configured to use AT-assisted DAP handoff, the AT 27

sends a DAPMoveRequest message to eBS1 to trigger initial PMIP tunnel setup with the AGW. If the 28

AT-assisted DAP handoff is not configured, eBS1 autonomously continues with the following step. 29

ee. eBS1 sends a PMIP-Registration Request message to the AGW (identified in the DAP Record IE in 30

the IAS-Session Information Response message in step ‘v’) to initiate PMIP tunnel setup. If multiple 31

RL-Only bindings are enabled, then the RL+Primary binding type extension is also included 32

indicating that eBS1 has both the primary and RL-Only binding for the AT. eBS1 starts timer Trrq-33

pmip. 34

ff. The AGW sends a PMIP-Registration Reply message to complete PMIP tunnel setup with eBS1. 35

eBS1 is now the DAP for the AT. Upon receipt of the PMIP-Registration Reply message, eBS1 stops 36

timer Trrq-pmip. If PMIP tunnel establishment between eBS1 and AGW fails, then eBS1 may retry for 37

an implementation-dependent number of times. If PMIP tunnel establishment still fails, then eBS1 38

should close the session with the AT. 39

gg. eBS1 creates Air Link Record for the AT, sends AAA-Accounting-Request (Start) message to the 40

AGW and starts timer Tacct-aaa. 41

hh. Upon receipt of the AAA-Accounting-Request (Start) message, the AGW creates a Usage Data 42

Record (UDR) for this AT and sends an AAA-Accounting-Response message to eBS1. eBS1 stops 43

timer Tacct-aaa. 44

ii. eBS1 sends a DAPAssignment message to the AT. 45

3GPP2 A.S0020-0 v1.0

3-5

Upon completion of step ‘ff’, the DAP eBS1 sends an IPT-Notification message to all ANRIs in the 1

Route Set. 2

jj. The eBS1 sends an IPT-Notification message to the SRNC and starts timer Tnot-ipt. The message 3

indicates that the eBS1 is now the DAP. The message also contains the timestamp that the eBS1/DAP 4

used in updating the PMIP tunnel with the AGW. 5

kk. The SRNC responds with an IPT-Notification Ack message and the eBS1/DAP stops timer Tnot-ipt. 6

ll. Upon assignment of the DAP for a new LinkID, the AT presents IP interface to the application and 7

may request IP address from the AGW any time after this step. 8

mm. Upon completion of the IP address assignment procedure, IP packet data service between the AT 9

and the AGW is established. 10

3.1.2 AT Registration in Idle State 11

This scenario describes the call flow where the AT powers up, acquires the UMB system, and performs 12

registration. This scenario assumes that the AT has an unexpired UMB session at the beginning of the call 13

flow. 14

After the AT acquires the UMB system and enters idle state, the AT performs idle AT registration as 15

shown in steps ‘b’ - ‘d’ in Figure 3.8.6-1. 16

17

3.1.3 AT Initiated Call Re-activation from Idle State 18

This scenario describes the call flow where the AT re-activates its call from idle state. This call flow 19

assumes that the AT has an unexpired UMB session whose SRNC and DAP are shown in Figure 3.1.3-1. 20

timeAT

b

c

eBS1 SRNC

d

e

IAS-Session Information Request (Session Signature, Access)Tsir-ias

IAS-Session Information Response (Session, DAP)

f

RouteOpenRequest

RouteOpenAccept

Key Exchange

i

j

nData

DAP

Data

RouteMap

IPT-Notification (eBS1 is FLSE)Tnot-ipt


AGW

eBS1 becomes DAP m

IPT-Notification (eBS1 is FLSE)


Tnot-iptk

l

a

AAA-Accounting-Request [Start]

AAA-Accounting-Response

g

h

Tacct-aaa

21

Figure 3.1.3-1 AT Initiated Call Re-activation from Idle State 22

3GPP2 A.S0020-0 v1.0

3-6

1

a. The AT sends a RouteOpenRequest message to eBS1 to open a route with eBS1. 2

b. Upon receipt of the RouteOpenRequest message, eBS1 sends an IAS-Session Information Request 3

message with a flag indicating access to the SRNC to request a copy of the session and starts timer 4

Tsir-ias. If the previous session reference transfer was incomplete where the SRNC was the source or 5

target SRNC of the incomplete session reference transfer, the SRNC also notifies the target or source 6

SRNC of the previous session reference transfer (refer to sections 3.7.2.4 or 3.7.2.5, respectively). 7

c. The SRNC sends an IAS-Session Information Response message to eBS1 including the session 8

information and the ANID of the DAP. Upon receipt of the IAS-Session Information Response 9


d. eBS1 sends RouteOpenAccept message to the AT to complete route establishment with the AT. 11

In AN-initiated DAP Handoff mode the AT may begin sending RL data to eBS1 anytime after step ‘d’. 12

e. eBS1 completes Key Exchange procedure with the AT. This step can occur in parallel with step ‘d’. 13

f. The AT updates the RouteMap with both eBS1 and the SRNC. 14

After sending RouteOpenAccept message to the AT, eBS1 notifies all ANRIs in the route set and the 15

previous DAP of the AT that it has become the FLSE for the AT. 16

g. eBS1 creates an Air Link Record for the AT, sends an AAA-Accounting-Request (Start) message to 17

the AGW and starts timer Tacct-aaa. 18

h. Upon receipt of the AAA-Accounting-Request (Start) message, the AGW sends an AAA-19

Accounting-Response message to eBS1. eBS1 stops timer Tacct-aaa. 20

i. Based on the ANID of eBS2 (which is the DAP for the AT), eBS1 sends an IPT-Notification message 21

to eBS2 indicating that eBS1 is the FLSE. eBS1 also starts timer Tnot-ipt. 22

j. Upon receipt of the IPT-Notification message, eBS2 acknowledges with an IPT-Notification Ack 23

message to eBS1. Upon receipt of the IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 24

k. eBS1 sends an IPT-Notification message to the SRNC indicating that eBS1 is the FLSE. eBS1 also 25

starts timer Tnot-ipt. 26

l. Upon receipt of the IPT-Notification message, the SRNC acknowledges with an IPT-Notification Ack 27


m. DAP is moved to eBS1 because it is the FLSE. Refer to section 3.6. 29

n. Data can be exchanged between the AT and the AGW via the new DAP (eBS1). 30

31

3.2 UMB Session Release and Packet Data Session Release 32

This section describes the call flows associated with UMB session release and packet data session release. 33

UMB session release always triggers packet data session release, but the converse is not true. Once the 34

UMB session has been released, if the AT needs to communicate via UMB, it needs to go through the 35

power-up procedure. 36

3.2.1 UMB Session Release for an Active AT - Initiated by the AT or SRNC 37

This scenario describes the call flow associated with a UMB session release for an active AT initiated 38

either by an AT or an ANRI in the Route Set of the AT. This call flow assumes that the SRNC is the 39

ANRI that initiates or receives the SessionClose message from the AT. This call flow assumes that an 40

RL-Only PMIP binding exists between the eBS1/FLSE/RLSE and AGW. RL+Primary PMIP bindings 41

exist between the DAP and the AGW. For the single binding case, there is only Primary PMIP binding 42

3GPP2 A.S0020-0 v1.0

3-7

between DAP and AGW. The UMB session release triggers the SRNC to initiate tearing down the 1

primary tunnel with the AGW, resulting in packet data session release at the AGW. 2

3

Figure 3.2.1-1 AT or SRNC Initiated UMB Session Release for an Active AT 4

a. The DAP has active RL+Primary PMIP tunnels with the AGW. 5

b. The eBS1/FLSE/RLSE has an active RL-only PMIP tunnel with the AGW. 6

c. The AT or an ANRI for the AT initiates UMB Session Release. Refer to [1] Part 007, Session Control 7

Plane. This call flow assumes that the ANRI is the SRNC. 8

After the SRNC releases the UMB session of the AT, the SRNC shall send an IAS-Session Release 9

message to all ANRIs in the Route Set and DAP. Steps ‘d’-‘e’ and ‘f’-‘g’ may occur in parallel. If eBS1 10

were the ANRI that sends/receives SessionClose message to/from AT, it would be the eBS1 that would 11

send IAS-Session Release message(s) to all ANRIs in the Route Set and DAP. 12

d. The SRNC sends an IAS-Session Release message to eBS1/FLSE/RLSE and starts timer Tsr-ias. The 13

message indicates that the SRNC has released the current UMB session and that eBS1/FLSE/RLSE 14

should deallocate resources assigned to the AT and purge the AT’s UMB session in 15

eBS1/FLSE/RLSE. 16

e. Upon receipt of the IAS-Session Release message, eBS1/FLSE/RLSE sends an IAS-Session Release 17

Ack message to the SRNC. The SRNC stops timer Tsr-ias. 18

3GPP2 A.S0020-0 v1.0

3-8

f. The SRNC sends an IAS-Session Release message to the DAP and starts timer Tsr-ias. The message 1

indicates that the SRNC has released the current UMB session and the DAP should deallocate 2

resources assigned to the AT, purge the AT’s UMB session in the DAP if the UMB session exists, 3

and release the PMIP tunnel between the AGW and DAP. 4

g. Upon receipt of the IAS-Session Release message, the DAP sends an IAS-Session Release Ack 5

message to the SRNC. The SRNC stops timer Tsr-ias. 6

h. If there is any Air Link Record created for the AT in DAP, DAP sends an AAA-Accounting-Request 7

(Stop) message to the AGW, DAP starts timer Tacct-aaa. This step shall not occur for single binding 8

case. 9

i. The AGW sends AAA-Accounting-Response message to the DAP. Upon receipt of the AAA-10

Accounting-Response message, the DAP stops timer Tacct-aaa. 11

j. Upon receipt of the IAS-Session Release message from the SRNC, the DAP sends a PMIP-12

Registration Request message to the AGW with a Lifetime timer value of zero to release the PMIP 13

tunnel between the AGW and DAP for the AT. The message indicates that the AGW should 14

deallocate resources assigned to the AT and release the AT’s packet data session. The DAP starts 15

timer Trrq-pmip. 16

k. Upon receipt of the PMIP-Registration Request message from DAP, the AGW releases the tunnel and 17

sends a PMIP-Registration Reply message to DAP. The RL-Only binding will be automatically 18

released when the primary PMIP Tunnel is released. Upon receipt of the PMIP-Registration Reply 19

message, the DAP stops timer Trrq-pmip. 20

l. eBS1/FLSE/RLSE sends an AAA-Accounting-Request(Stop) message to the AGW, eBS1 starts timer 21

Tacct-aaa. This step can occur anytime after step ‘e’. 22

m. The AGW sends AAA-Accounting-Response message to the eBS1. Upon receipt of the AAA-23

Accounting-Response message, the eBS1 stops timer Tacct-aaa. 24

25

3.2.2 UMB Session Release for an Idle AT - Initiated by the SRNC 26

This section describes the call flows associated with a UMB session release for an idle AT initiated by the 27

SRNC. The UMB session release triggers the SRNC to initiate packet data session release with the AGW. 28

29

3GPP2 A.S0020-0 v1.0

3-9

3.2.2.1 SRNC Initiated UMB Session Release for an Idle AT (Case 1: DAP eBS) 1

2

3

Figure 3.2.2.1-1 SRNC Initiated UMB Session Release for an Idle AT (Case 1: DAP eBS) 4

a. The connection between the AT and the FLSE is closed. The AT, SRNC and DAP are all in idle state. 5

b. The SRNC decides to perform UMB Session Release based on a certain criteria outside the scope of 6

this specification. 7

c. The SRNC sends an IAS-Session Release message to the DAP to trigger release of the PMIP binding 8

with the AGW and starts timer Tsr-ias. 9

d. Upon receipt of the IAS-Session Release message, the DAP responds with an IAS-Session Release 10

Ack message. Upon receipt of the IAS-Session Release Ack message, the SRNC stops timer Tsr-ias. 11

e. Upon receipt of the IAS-Session Release message, the DAP releases the PMIP binding by sending a 12

PMIP-Registration Request message to the AGW with Lifetime of zero and starts timer Trrq-pmip. 13

f. Upon receipt of the PMIP-Registration Request message, the AGW responds with a PMIP-14

Registration Reply message and releases the packet data session. Upon receipt of the PMIP-15

Registration Reply message, the DAP stops timer Trrq-pmip and releases resources for the AT. The 16

AGW purges the packet data session for the AT. 17

Step ‘g’ can occur anytime after step ‘d’. 18

3GPP2 A.S0020-0 v1.0

3-10

g. The SRNC sends an IAS-Page message to each eBS in the paging area of the AT. This call flow 1

assumes that eBS1 and eBS2 are in the paging area. The IAS-Page message indicates that Local 2

Fanout is not required. The message also contains information on the time for initiating the page 3

procedure over the air and priority of the page. 4

h. eBS1 and eBS2 page the AT at the specified channel and time. 5

i. Upon receipt of the page, the AT sends RouteOpenRequest Message to the SRNC. 6

j. Upon receipt of the RouteOpenRequest message, eBS1 also sends an IAS-Session Information 7

Request message with a flag indicating access to the SRNC to requests a copy of the session and 8

starts timer Tsir-ias. If the previous session reference transfer was incomplete where the SRNC was the 9

source or target SRNC of the incomplete session reference transfer, the SRNC also notifies the target 10

or source SRNC of the previous session reference transfer (refer to sections 3.7.2.4 or 3.7.2.5, 11

respectively). 12

k. The SRNC sends an IAS-Session Information Response message to eBS1 including the cause value 13

set to ‘Requested session not found’. Upon receipt of the IAS-Session Information Response message, 14

eBS1 stops timer Tsir-ias. Upon sending the IAS-Session Information Response message, the SRNC 15

purges the UMB session for the AT. 16

l. eBS1 sends a SessionClose message to the AT to release the UMB session. When the AT receives the 17

SessionClose message, the AT purges the packet data session and the UMB session. 18

19

3.2.2.2 SRNC Initiated UMB Session Release for an Idle AT (Case 2: DAP SRNC) 20

21

22

Figure 3.2.2.2-1 SRNC Initiated UMB Session Release for an Idle AT (Case 2: DAP SRNC) 23

3GPP2 A.S0020-0 v1.0

3-11

a. The connection between the AT and the FLSE is closed. The AT, SRNC and DAP are all in idle state. 1

b. The SRNC decides to perform UMB Session Release based on a certain criteria outside the scope of 2

this specification. 3

c. The SRNC sends a PMIP-Registration Request message with lifetime value set to zero and starts 4

timer Trrq-pmip. 5

d. Upon receipt of the PMIP-Registration Request message, the AGW sends a PMIP-Registration Reply 6

message to the SRNC and releases the packet data session. Upon receipt of the PMIP-Registration 7

Reply message, the SRNC stops timer Trrq-pmip. The AGW purges packet data session for the AT. 8

e. The SRNC sends an IAS-Page message to each eBS in the paging area of the AT. This call flow 9

assumes that eBS1 and eBS2 are in the paging area. The IAS-Page message indicates that Local 10

Fanout is not required. The message also contains information on the time for initiating the page 11

procedure over the air and priority of the page. 12

f. eBS1 and eBS2 page the AT at the specified channel and time. 13

g. Upon receipt of the Paging message, the AT sends a RouteOpenRequest Message to the SRNC. 14

h. Upon receipt of the RouteOpenRequest message, eBS1 also sends an IAS-Session Information 15

Request message with a flag indicating access to the SRNC to requests a copy of the session and 16

starts timer Tsir-ias. If the previous session reference transfer was incomplete where the SRNC was the 17

source or target SRNC of the incomplete session reference transfer, the SRNC also notifies the target 18

or source SRNC of the previous session reference transfer (refer to sections 3.7.2.4 or 3.7.2.5, 19

respectively). 20

i. The SRNC sends an IAS-Session Information Response message to eBS1 including the cause value 21

set to ‘Requested session not found’. Upon receipt of the IAS-Session Information Response message, 22

eBS1 stops timer Tsir-ias. Upon sending the IAS-Session Information Response message, the SRNC 23

purges the UMB session for the AT. 24

j. eBS1 sends a SessionClose message to the AT to release the UMB session. When the AT receives the 25

SessionClose message, the AT purges the packet data session and the UMB session. 26

27

3.2.3 AGW Initiated Packet Data Session Release for an Active AT 28

This scenario describes the call flow associated with a packet data session release initiated by the AGW. 29

This scenario may occur because of administrative reasons or other reasons outside the scope of this 30

specification. This call flow assumes that AGW1 releases the PMIP binding for the AT and the AT 31

creates new packet data session through AGW2. This call flow assumes that eBS1 and the SRNC are 32

already in the Route Set. 33

3GPP2 A.S0020-0 v1.0

3-12

1

Figure 3.2.3-1 AGW Initiated Packet Data Session Release for an Active AT 2

a. The AGW sends a PMIP-Registration Revocation message to the DAP. 3

b. Upon receipt of the PMIP-Registration Revocation message, the DAP sends a PMIP-Revocation 4

Acknowledgment message to the AGW. 5

3GPP2 A.S0020-0 v1.0

3-13

c. The DAP sends an IPT-Notification message to the SRNC, indicating that the Lifetime value of the 1

PMIP tunnel at the DAP is now zero, and starts timer Tnot-ipt. The message indicates that the packet 2

data session has been released. Upon receipt of the IPT-Notification message, the SRNC invalidates 3

the existing DAP and AGW Record. 4

After step ‘c’, this call flow assumes that the SRNC does not close the UMB session. Based on local 5

policy, the SRNC may also close the UMB session. Refer to section 3.2.1. 6

d. Upon receipt of the IPT-Notification message, the SRNC sends an IPT-Notification Ack message to 7

the DAP. The DAP stops timer Tnot-ipt and releases the resources related to the AT. 8

e. The DAP sends an IPT-Notification message to eBS1, indicating that the Lifetime value of the PMIP 9

tunnel at the DAP is now zero, and starts timer Tnot-ipt. The message indicates that the packet data 10

session has been released. Upon receipt of the IPT-Notification message, eBS1 does not send RL data 11

to AGW1. If eBS1 has an RL-only binding, it is automatically released upon receipt of the IPT-12

Notification message. 13

f. Upon receipt of the IPT-Notification message, eBS1 sends an IPT-Notification Ack message to the 14

DAP. The DAP stops timer Tnot-ipt. 15

g. Upon receipt of the IPT-Notification message indicating that the packet data session has been 16

released for the AT, the SRNC initiates restarting of the IP interface in the AT. This results in 17

connection close and restart of the IP interface in the AT. Refer to [1] Part 007, Route Control Plane. 18

The SRNC also reset the ValidPMK flag in its SSIR hence the AT needs to be authenticated in the 19

next access. 20

h. The AT sends ConnectionClose message to the FLSE. 21

i. Upon receipt of the ConnectionClose message from the AT, the FLSE sends an IPT-Notification 22

message to all ANRIs in the route set (including the SRNC) indicating that the connection has been 23

closed and starts timer Tnot-ipt. 24

j. Upon receipt of the IPT-Notification message from the FLSE, the SRNC sends an IPT-Notification 25

Ack message to the FLSE. Upon receipt of the IPT-Notification Ack message, the FLSE stops timer 26

Tnot-ipt and releases resources related to the AT. 27

k. The AT accesses again and sends a RouteOpenRequest message using UATI to open a route with 28

eBS1. 29

l. Upon receipt of the RouteOpenRequest message from the AT, eBS1 sends an IAS-Session 30

Information Request message to the SRNC and starts timer Tsir-ias to retrieve the session information 31

of the AT. 32

m. Upon receipt of the IAS-Session Information Request message from eBS1, the SRNC responds with 33

an IAS-Session Information Response message. The message contains session information for the AT. 34

It also contains an empty DAP Record with no AGW identity. Upon receipt of the IAS-Session 35

Information Response message from the SRNC, eBS1 stops timer Tsir-ias. 36

n. Upon receipt of the IAS-Session Information Response message, eBS1 responds to the AT with a 37

RouteOpenAccept message. The message does not contain a LinkID. 38

o. Upon receipt of the RouteOpenAccept message, the AT sends the updated RouteMap to eBS1 and the 39

SRNC. 40

p. Upon receipt of the RouteMap, the eBS1 sends an IPT-Notification message to the SRNC, indicating 41

that eBS1 is the FLSE, and starts timer Tnot-ipt. 42

q. Upon receipt of the IPT-Notification message, the SRNC sends an IPT-Notification Ack message 43

back to eBS1. Upon receipt of the IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 44

3GPP2 A.S0020-0 v1.0

3-14

r. The SRNC initiates access authentication with the AT through AGW2. AGW2 is selected based on 1

the AGW selection algorithm outside the scope of this specification. 2

s. Upon the successful access authentication, the SRNC initiates key exchange procedure with the AT to 3


t. The SRNC and the AT performs the Session Anchor route configuration. 5

u. Upon completion of the session configuration, the AT sends a SessionUpdated message to eBS1 and 6

the SRNC. This message contains the new session signature of the AT. 7

v. Upon receipt of the SessionUpdated message from the AT with the new session signature, eBS1 8


w. Upon receipt of the IAS-Session Information Request message, the SRNC responds with an IAS-10


record containing the AGW2 identity, its LinkID and null DAP Information. Upon receipt of the IAS-12

Session Information Response message, eBS1 stops timer Tsir-ias. 13

x. Upon receipt of the session of the AT, eBS1 initiates key exchange procedure with the AT. 14

y. eBS1 initiates session configuration for personality associated with eBS1 after receiving the session 15

from the SRNC. 16

Note: Session configuration can only occur after access authentication. 17

z. Upon receipt of the session of the AT, eBS1 also assigns the Link ID for the AT so that the AT can 18

start IP service. This step may occur in parallel with step ‘w’. 19

aa. Upon assignment of the Link ID, if the AT is configured to use AT-assisted DAP handoff, the AT 20

sends a DAPMoveRequest message to eBS1 to trigger initial PMIP tunnel setup with AGW2. 21

bb. eBS1 sends a PMIP-Registration Request message to AGW2 to initiate PMIP tunnel setup. If 22

multiple RL-Only bindings are enabled, then the RL extension is also included indicating that eBS1 23

has both the primary and RL-Only binding for the AT. 24

cc. AGW2 sends a PMIP-Registration Reply message to complete PMIP tunnel setup with eBS1. eBS1 is 25

now the DAP for the AT. If PMIP tunnel establishment between eBS1 and AGW2 fails, then eBS1 26

may retry for an implementation-dependent number of times. If PMIP tunnel establishment still fails, 27

then eBS1 should close the session with the AT. 28

dd. eBS1 creates Air Link Record for the AT, sends an AAA-Accounting-Request (Start) message to 29

AGW2 and starts timer Tacct-aaa. 30

ee. Upon receipt of the AAA-Accounting-Request (Start) message, AGW2 creates a UDR for this AT 31

and sends an AAA-Accounting-Response message to eBS1. eBS1 stops timer Tacct-aaa. 32

ff. Upon receipt of the successful PMIP-Registration Response message and the LinkID for the eBS 33

changes from null to LinkID of AGW2, eBS1 responds to the AT with a DAPAssignment message. 34

Upon receipt of the DAPAssignment message, the AT presents IP interface to the application. 35

gg. The AT may request IP address from the AGW at any time. 36

hh. Upon completion of the IP address assignment procedure, IP packet data service between the AT and 37

the AGW is established. 38

39

3.2.4 AGW Initiated Packet Data Session Release for an Active AT that is no Longer Authorized 40


This scenario may occur because of the service authorization for the user has been revoked. For an 42

implementation option where the SRNC is collocated with the AGW, this scenario may not be needed as 43

3GPP2 A.S0020-0 v1.0

3-15

the collocated SRNC/AGW may instead initiate UMB session release as described in section 3.2.2. This 1

call flow assumes that eBS1 and the SRNC are already in the Route Set. 2

3

Figure 3.2.4-1 AGW Initiated Packet Data Session Release for an Active AT that is no Longer 4

Authorized 5









the DAP. The DAP stops timer Tnot-ipt and releases resources related to the AT. 14

e. If there is any Airlink Record created for the AT in the DAP, the DAP sends an AAA-Accounting-15

Request (Stop) message to the AGW and starts timer Tacct-aaa. The message includes the Airlink 16

Record in the DAP. 17

3GPP2 A.S0020-0 v1.0

3-16

f. Upon receipt of the AAA-Accounting-Request (Stop) message from the DAP, the AGW sends an 1

AAA-Accounting-Response message to the DAP. When the accounting report has been successfully 2

confirmed by the AGW, the DAP deallocates resources for the AT. The DAP stops timer Tacct-aaa 3

g. The DAP sends an IPT-Notification message to eBS1, indicating that the Lifetime value of the PMIP 4

tunnel at the DAP is now zero, and starts timer Tnot-ipt. The message indicates that the packet data 5

session has been released. If eBS1 has an RL-only binding, it is automatically released upon receipt 6

of the IPT-Notification message. 7

h. Upon receipt of the IPT-Notification message, eBS1 sends an IPT-Notification Ack message to the 8

DAP. The DAP stops timer Tnot-ipt. 9

i. If there is any Airlink Record created for the AT in eBS1, eBS1 sends an AAA-Accounting-Request 10

(Stop) message to the AGW and starts timer Tacct-aaa. The message includes the Airlink Record in 11

eBS1. 12

j. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS1, the AGW sends an AAA-13

Accounting-Response message to eBS1. When the accounting report has been successfully confirmed 14

by the AGW, eBS1 deallocates resources for the AT. eBS1 stops timer Tacct-aaa. 15

k. Upon receipt of the IPT-Notification message indicating that the packet data session has been 16

released for the AT, the SRNC initiates restarting of the IP interface in the AT. This results in 17

connection close and restart of the IP interface in the AT. Refer to [1] Part 007, Route Control Plane. 18

The SRNC also reset the ValidPMK flag in its SSIR hence the AT needs to be authenticated in the 19

next access. 20

l. The AT sends ConnectionClose message to the FLSE. 21

m. Upon receipt of the ConnectionClose message from the AT, the FLSE sends an IPT-Notification 22

message to all ANRIs in the route set (including the SRNC) indicating that the connection has been 23

closed and starts timer Tnot-ipt. 24

n. Upon receipt of the IPT-Notification message from the FLSE, the SRNC sends an IPT-Notification 25

Ack message to the FLSE. Upon receipt of the IPT-Notification Ack message, the FLSE stops timer 26

Tnot-ipt and releases resources related to the AT. 27

o. The AT accesses again and sends a RouteOpenRequest message using UATI to open a route with 28

eBS1. 29

p. Upon receipt of the RouteOpenRequest message from the AT, eBS1 sends an IAS-Session 30


of the AT. 32

q. Upon receipt of the IAS-Session Information Request message from eBS1, the SRNC responds with 33




r. Upon receipt of the IAS-Session Information Response message, eBS1 responds to the AT with a 37


s. Upon receipt of the RouteOpenAccept message, the AT sends the updated RouteMap to eBS1 and the 39

SRNC. 40

t. Upon receipt of the RouteMap, the eBS1 sends an IPT-Notification message to the SRNC, indicating 41

that eBS1 is the FLSE and starts timer Tnot-ipt. 42

u. Upon receipt of the IPT-Notification message, the SRNC sends an IPT-Notification Ack message 43


3GPP2 A.S0020-0 v1.0

3-17

v. The SRNC initiates access authentication with the AT through AGW2. AGW2 is selected based on 1

the AGW selection algorithm outside the scope of this specification. The access authentication fails as 2

the AT is no longer authorized. 3

w. The SRNC sends a SessionClose message to the AT to close the UMB session. 4

x. The SRNC sends an IAS-Session Release message to eBS1 and starts timer Tsr-ias. 5

y. Upon receipt of the IAS-Session Release message, eBS1 responds with an IAS-Session Release Ack 6

message and releases resources related to the AT. Upon receipt of the IAS-Session Release Ack 7

message, the SRNC stops timer Tsr-ias and release UMB session for the AT. 8

9

3.2.5 AGW Initiated Packet Data Session Release for an Idle AT (Case 1: DAP eBS) 10

This scenario describes the call flow associated with a packet data session release initiated by the AGW 11

when the PMIP binding is at the DAP. 12

3GPP2 A.S0020-0 v1.0

3-18

1

Figure 3.2.5-1 AGW Initiated Packet Data Session Release for an Idle AT (Case 1: DAP eBS) 2




3GPP2 A.S0020-0 v1.0

3-19






the DAP. The DAP stops timer Tnot-ipt and releases the resources related to the AT. 6

After step ‘d’, this call flow assumes that the SRNC does not close the UMB session. Based on local 7


e. Upon receipt of the IPT-Notification message indicating that the packet data session has been 9

released for the AT, the SRNC initiates the paging procedures for the AT. 10

f. The AT accesses and sends a RouteOpenRequest message using UATI to open a route with eBS1. 11

g. Upon receipt of the RouteOpenRequest message from the AT, eBS1 sends an IAS-Session 12


of the AT. 14

h. Upon receipt of the IAS-Session Information Request message from eBS1, the SRNC responds with 15




i. Upon receipt of the IAS-Session Information Response message, eBS1 responds to the AT with a 19


j. Upon receipt of the RouteOpenAccept message, the AT sends the updated RouteMap to eBS1 and the 21

SRNC. 22

k. Upon receipt of the RouteMap, the eBS1 sends an IPT-Notification message to the SRNC, indicating 23


l. Upon receipt of the IPT-Notification message, the SRNC sends an IPT-Notification Ack message 25


m. The SRNC initiates access authentication with the AT through AGW2. AGW2 is selected based on 27


n. Upon the successful access authentication, the SRNC initiates key exchange procedure with the AT to 29


o. The SRNC and the AT performs the Session Anchor route configuration. 31

p. Upon completion of the session configuration, the AT sends a SessionUpdated message to eBS1 and 32


q. Upon receipt of the SessionUpdated message from the AT with the new session signature, eBS1 34


r. Upon receipt of the IAS-Session Information Request message, the SRNC responds with an IAS-36




s. Upon receipt of the session of the AT, eBS1 initiates key exchange procedure with the AT. 40

t. eBS1 initiates session configuration for personality associated with eBS1 after receiving the session 41

from the SRNC. 42


3GPP2 A.S0020-0 v1.0

3-20

u. Upon receipt of the session of the AT, eBS1 also assigns the Link ID for the AT so that the AT can 1


v. Upon assignment of the Link ID, if the AT is configured to use AT-assisted DAP handoff, the AT 3


w. eBS1 sends a PMIP-Registration Request message to AGW2 to initiate PMIP tunnel setup. If 5



x. AGW2 sends a PMIP-Registration Reply message to complete PMIP tunnel setup with eBS1. eBS1 is 8




y. The eBS1 creates Air Link Record for the AT, sends an AAA-Accounting-Request (Start) message to 12

AGW2 indicating Connection Open and starts timer Tacct-aaa. 13

z. Upon receipt of the AAA-Account-Request (Start) message, AGW2 creates a UDR for this AT and 14

sends an AAA-Accounting-Response message to the eBS1. eBS1 stops timer Tacct-aaa. 15

aa. Upon receipt of the successful PMIP-Registration Response message and the LinkID for the eBS 16



bb. The AT may request IP address from the AGW at any time. 19

cc. Upon completion of the IP address assignment procedure, IP packet data service between the AT and 20


3.2.6 AGW Initiated Packet Data Session Release for an Idle AT (Case 2: DAP SRNC) 22


3GPP2 A.S0020-0 v1.0

3-21

1

Figure 3.2.6-1 AGW Initiated Packet Data Session Release for an idle AT (Case 2: DAP SRNC) 2

a. The AGW sends a PMIP-Registration Revocation message to the SRNC. 3

b. Upon receipt of the PMIP-Registration Revocation message, the SRNC sends a PMIP-Revocation 4


After step ‘b’, this call flow assumes that the SRNC does not close the UMB session. Based on local 6


c. Upon receipt of the PMIP-Registration Revocation message indicating that the packet data session 8

has been released for the AT, the SRNC initiates the paging procedures with the eBS1 and eBS2. 9

d. The AT accesses and sends a RouteOpenRequest message using UATI to open a route with eBS1. 10

3GPP2 A.S0020-0 v1.0

3-22

e. Upon receipt of the RouteOpenRequest message from the AT, eBS1 sends an IAS-Session 1


of the AT. 3

f. Upon receipt of the IAS-Session Information Request message from eBS1, the SRNC responds with 4




g. Upon receipt of the IAS-Session Information Response message, eBS1 responds to the AT with a 8


h. Upon receipt of the RouteOpenAccept message, the AT sends the updated RouteMap to eBS1 and the 10

SRNC. 11

i. Upon receipt of the RouteMap, the eBS1 sends an IPT-Notification message to the SRNC, indicating 12


j. Upon receipt of the IPT-Notification message, the SRNC sends an IPT-Notification Ack message 14


k. The SRNC initiates access authentication with the AT through AGW2. AGW2 is selected based on 16


l. Upon the successful access authentication, the SRNC initiates key exchange procedure with the AT to 18


m. The SRNC and the AT performs the Session Anchor route configuration. 20

n. Upon completion of the session configuration, the AT sends a SessionUpdated message to eBS1 and 21


o. Upon receipt of the SessionUpdated message from the AT with the new session signature, eBS1 23


p. Upon receipt of the IAS-Session Information Request message, the SRNC responds with an IAS-25




q. Upon receipt of the session of the AT, eBS1 initiates key exchange procedure with the AT. 29

r. eBS1 initiates session configuration for personality associated with eBS1 after receiving the session 30

from the SRNC. 31


s. Upon receipt of the session of the AT, eBS1 also assigns the Link ID for the AT so that the AT can 33


t. Upon assignment of the Link ID, if the AT is configured to use AT-assisted DAP handoff, the AT 35


u. eBS1 sends a PMIP-Registration Request message to AGW2 to initiate PMIP tunnel setup. If 37



v. AGW2 sends a PMIP-Registration Reply message to complete PMIP tunnel setup with eBS1. eBS1 is 40




3GPP2 A.S0020-0 v1.0

3-23

w. The eBS1 creates Air Link Record for the AT, sends an AAA-Accounting-Request (Start) message to 1

AGW2 indicating Connection Open and starts timer Tacct-aaa. 2

x. Upon receipt of the AAA-Account-Request (Start) message, AGW2 creates a UDR for this AT and 3

sends an AAA-Accounting-Response message to the eBS1. eBS1 stops timer Tacct-aaa. 4

y. Upon receipt of the successful PMIP-Registration Response message and the LinkID for the eBS 5



z. The AT may request IP address from the AGW at any time. 8

aa. Upon completion of the IP address assignment procedure, IP packet data service between the AT and 9


11

3.3 Route Set Management 12

This section describes the call flows associated with Route Set Management. 13

3.3.1 UMB Route Set Management Overview 14

To add another ANRI to the Route Set, the AT first creates a route to the entity hosting the ANRI, e.g., 15

eBS. This can be done via link-layer tunneling of the air-interface RouteOpenRequest message from the 16

RLSE to the ANRI that the AT wants to add into the Route Set. Upon receiving this message, the ANRI 17

uses the embedded UATI and SessionSignature to retrieve the latest session information of the AT from 18

the SRNC. After the session is retrieved, the ANRI can complete the Route setup process by sending a 19

RouteOpenAccept message to the AT. The AT then needs to update the RouteID mapping for all ANRIs 20

in the Route Set by sending an updated RouteMap message to each ANRI in the Route Set. 21

Once a new RouteMap message is received, the DAP, SRNC, and FLSE compare the new Route Set with 22

the existing Route Set and identifies any new ANRIs in the Route Set. If any new ANRIs exist, then the 23

DAP, SRNC and FLSE send the latest notification messages to the new ANRIs. For example, the DAP 24

sends the IPT-Notification (DAP) message to the new ANRIs while the SRNC sends the IAS-UATI 25

Update message to the new ANRIs. 26

To remove an ANRI from the Route Set, either the ANRI or the AT sends a Route Close message to close 27

the Route. Subsequently, the AT sends the updated RouteMap message to all remaining ANRIs in the 28

Route Set. Based on the updated RouteMap, the remaining ANRIs in the Route Set terminate all 29

communications to the removed ANRI for this AT. 30

3.3.2 Route Set Add 31

This scenario describes the call flow for adding an ANRI (eBS2 in the call flow) into the Route Set. This 32

call flow assumes that eBS1 and the SRNC are already in the Route Set. 33

3GPP2 A.S0020-0 v1.0

3-24

timeAT

b

c

e

a

g

eBS1(FLSE/DAP)

d

eBS2 SRNC

RouteOpenAccept

Tsir-ias

AT is in Connected State with eBS1 and the SRNC in the Route Set

IAS-Session Info Request

IAS-Session Info Response

AT is in Connected State with eBS1, eBS2, and SRNC in the Route Set

l

IAS-UATI Update (UATI_SeqNo, UATI, SessionSignature)

IAS-UATI Update Ack k**Tuupd-ias

h*

RouteOpenRequest

RouteMap

IPT-Notification (DAP=eBS1, FLSE=eBS1)


Tnot-ipt

m

** = conditional

AGW



Trrq-pmip

* = optional

j**

i**

f

1

Figure 3.3.2-1 Route Set Add 2

a. The AT is currently in the Connected State with eBS1 and the SRNC in the Route Set. 3

b. The AT tunnels a RouteOpenRequest message to eBS2 to add eBS2 into the Route Set. The LLT 4

tunneling header contains the UATI of the AT which allows for eBS2 to locate the SRNC. 5

c. eBS2 sends an IAS-Session Information Request to the SRNC and starts timer Tsir-ias. The message 6

includes the Session Signature which identifies the latest session information. 7

d. The SRNC responds to eBS2 with an IAS-Session Information Response message, including the 8

session information. Upon receipt of the IAS-Session Information Response message, eBS2 stops 9

timer Tsir-ias. 10

e. eBS2 sends a RouteOpenAccept message to the AT. 11

f. The AT is in the Connected State with eBS1, eBS2 and SRNC in the Route Set. 12

g. The AT sends a RouteMap message to each ANRI in the Route Set. 13

h. If multiple RL-Only bindings are enabled, eBS2 sends a PMIP-Registration Request message to the 14

AGW to establish an additional data tunnel. The RL extension is also included indicating that eBS2 15

has an RL-Only binding for the AT and that eBS2 may send reverse traffic. eBS2 starts timer Trrq-16

pmip. This step may occur anytime after step ‘d’. 17

i. The AGW sends a PMIP-Registration Reply message to grant the data tunnel. eBS2 stops timer Trrq-18

pmip. 19

j. Upon receipt of the updated RouteMap, the SRNC sends an IAS-UATI Update message to eBS2 and 20

starts timer Tuupd-ias. This step may occur any time after step ‘g’. This step is used to confirm that 21

eBS2 has the latest UATI, UATI_SeqNo and Session Signature (in SRNC Record IE) (e.g., if SRNC 22

3GPP2 A.S0020-0 v1.0

3-25

transfer occurs during Route Set Add (refer to section 3.7.2.2). This step may be omitted if the SRNC 1

is certain that eBS2 has the latest UATI, UATI_SeqNo and SessionSignature. 2

k. Upon receipt of the IAS-UATI Update message, eBS2 sends an IAS-UATI Update Ack message back 3

to the SRNC. Upon receipt of the IAS-UATI Update Ack message, the SRNC stops timer Tuupd-ias. 4

l. Upon receipt of the RouteMap message in step ‘g’, the FLSE and DAP need to inform the new ANRI 5

in the Route Set of their respective identities. Since eBS1 is both FLSE and DAP in this call flow, it 6

sends a single IPT-Notification message to eBS2 identifying itself as both the FLSE and the DAP and 7

starts timer Tnot-ipt. This step may occur any time after step ‘g’. 8

m. Upon receipt of the IPT-Notification message, eBS2 sends an IPT-Notification Ack message back to 9

the FLSE and DAP. Upon receipt of the IPT-Notification Ack message, the FLSE and DAP stop 10

timer Tnot-ipt. 11

3.3.3 Route Set Remove 12

This scenario describes the call flow for removing an ANRI (eBS2 in this call flow) from the Route Set. 13

This call flow assumes that eBS1, eBS2 and the SRNC are in the Route Set at the beginning of the call 14

flow. 15

timeAT

c

d

b

a

eBS1 eBS2 SRNC

AT is in Connected State with eBS1, eBS2 and SRNC in the Route Set

AT is in Connected State with eBS1 and SRNC in the Route Set

RouteClose

RouteMap

AAA-Accounting-Request [Stop, RouteDrop]

e**

f**

AGW

** conditional


Tacct-aaa

16

Figure 3.3.3-1 Route Set Remove 17

a. The AT is currently in the Connected State with eBS1, eBS2 and the SRNC in the Route Set. 18

b. Either an ANRI or the AT can send a RouteClose message. The sender deallocates air-interface 19

resources for this route immediately after sending this message. If the message is not received at the 20

eBS, the eBS deallocate resources on this route after the ConnectionKeepAlivePeriod timer expires. 21

c. After the AT removes the route, the AT updates all ANRIs in the Route Set of the new RouteMap by 22

sending a RouteMap message to all ANRIs remaining in the Route Set. Based on the new RouteMap 23

message, both eBS1 and the SRNC stop all communications to the removed eBS for this AT. 24

d. The AT remains in the Connected State with eBS1 and the SRNC in the Route Set. 25

e. If there is any Airlink Record created for the AT in eBS2, eBS2 sends an AAA-Accounting-Request 26


eBS2. 28

f. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS2, the AGW sends an AAA-29



3GPP2 A.S0020-0 v1.0

3-26

1

3.3.4 Route Set Remove with Multiple Tunnels 2

This scenario describes the call flow for removing an ANRI (eBS2 in this call flow) from the Route Set. 3

This call flow assumes that eBS1, eBS2 and the SRNC are in the Route Set at the beginning of the call 4

flow. This call flow also assumes that eBS1 and eBS2 each have a data tunnel with the AGW. 5

timeAT

a

b

eBS1 eBS2 SRNC

AT is in Connected State with eBS1, eBS2 and the SRNC in the Route Set

AT is in Connected State with eBS1 and the SRNC in the Route Set e

h

dRouteClose

RouteMap

i

AGW



Trrq-pmipg

f

c

PMIP Tunnel

PMIP Tunnel

PMIP Tunnel



j**

k**** Conditional

PMIP TunnelData

Tacct-aaa

6

Figure 3.3.4-1 Route Set Remove with Multiple Tunnels 7

a. The AT is currently in the Connected State with eBS1, eBS2 and SRNC in the Route Set. 8

b. eBS1 has the primary PMIP tunnel with the AGW. 9

c. eBS2 has an RL-Only tunnel with the AGW. 10

d. Either an ANRI or the AT can send a RouteClose message. If this message is lost, then the intended 11

recipient of the message deallocates its resources for the route when its ConnectionKeepAlivePeriod 12

timer expires. 13

e. The AT remains in the Connected State with eBS1 and the SRNC in the Route Set. 14

f. After the AT removes the route, the AT updates all ANRIs in the Route Set of the new RouteMap by 15

sending a RouteMap message to all ANRIs remaining in the Route Set. Based on the new RouteMap 16

message, both eBS1 and the SRNC stop all communications to the removed eBS2 for this AT. 17

g. Upon completing all communications for this AT, eBS2 deletes the PMIP tunnel binding by sending a 18

PMIP-Registration Request message to the AGW with lifetime value set to zero. eBS2 starts timer 19

Trrq-pmip. 20

h. Upon receipt of the PMIP-Registration Request message, the AGW removes the data tunnel to eBS2 21

and acknowledges the eBS2 request by sending a PMIP-Registration Reply message. eBS2 stops 22

timer Trrq-pmip. 23

i. eBS1 continues to have the primary tunnel with the AGW. 24

3GPP2 A.S0020-0 v1.0

3-27

j. After the RouteClose message is received by eBS2 or when the ConnectionKeepAlivePeriod timer 1

expires, if there is any Airlink Record created for the AT in eBS2, eBS2 sends an AAA-Accounting-2

Request (Stop) message to the AGW and starts timer Tacct-aaa. The message includes the Airlink 3

Record in eBS2. 4

k. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS2, the AGW sends an AAA-5



8

3.4 UMB Session Negotiation 9

This section describes the call flows associated with UMB session negotiation. 10

3.4.1 UMB Session Negotiation Overview 11

Session negotiation between the AT and an ANRI can either be performed directly over-the-air or through 12

link-layer tunnel. Session negotiation can be initiated either by the AT or any ANRI in the Route Set. 13

Since the AT supports only a single InConfiguration instance, the AT can perform session negotiation 14

with only one ANRI at a time. 15

When session configuration concludes, the newly configured ANRI updates the session information with 16

the SRNC. The SRNC then assigns a new session signature for the updated session. The ANRI then sends 17

the new session signature to the AT and the AT subsequently sends SessionUpdated message to all 18

ANRIs in the Route Set to trigger these ANRIs to retrieve the updated session from the SRNC. 19

3.4.2 UMB Session Negotiation 20

This scenario describes the call flow for UMB session negotiation. This call flow assumes that eBS1, 21

eBS2 and the SRNC are already in the Route Set. 22

timeAT

b

a

c

eBS1 eBS2 SRNC

d

e

IAS-Session Information Update Request(Old Session Signature, New Session)Tsur-ias

IAS-Session Information Update Response(new Session Signature)

f

g

hAll ANRIs have the updated session

ConfigComplete (new Session Signature)

IAS-Session Information Request (Session Signature)

IAS-Session Information Response (Session)

Tsir-ias

SessionUpdated (new Session Signature)

AT and eBS2 negotiate session

23

Figure 3.4.2-1 Session Negotiation 24

a. The AT and eBS2 negotiate the session and conclude the negotiation. The AT is waiting for eBS2 to 25

send the updated SessionSignature using a ConfigurationComplete message. 26

b. eBS2 sends an IAS-Session Information Update Request message to the SRNC with the session 27

information and starts timer Tsur-ias. 28

3GPP2 A.S0020-0 v1.0

3-28

c. The SRNC responds with an IAS-Session Information Update Response message which includes the 1

new session signature. Upon receipt of the IAS-Session Update Response message, eBS2 stops timer 2

Tsur-ias. 3

d. eBS2 sends a ConfigurationComplete message to the AT to indicate that the session has been updated. 4

The message contains the new session signature assigned by the SRNC. 5

e. The AT notifies all ANRIs in the Route Set of the updated session by sending a SessionUpdated 6

message with the new session signature to each ANRI in the Route Set. 7

f. Upon receipt of the SessionUpdated message with a different session signature, eBS1 sends an IAS-8

Session Information Request message to the SRNC to retrieve a copy of the updated session and 9

starts timer Tsir-ias. This message contains the session signature that eBS1 has received from the AT 10

in step ‘e’. 11

g. The SRNC responds with an IAS-Session Information Response. This message contains the latest 12

session as indicated by the session signature. Upon receipt of the IAS-Session Information Response 13


h. All ANRIs in the Route Set have the updated session information. 15

16

3.5 Serving eBS Switch 17

This section describes the call flows associated with the switching of the serving eBS. 18

3.5.1 FLSE Switch 19

This scenario describes the call flow for a successful FLSE switch. In this call flow, it is assumed that the 20

source FLSE, the target FLSE and the DAP are different eBSs. If the source FLSE and the DAP are the 21

same or if the target FLSE and the DAP are the same, the steps corresponding to the signaling between 22

these eBSs are omitted. In this call flow, the source FLSE uses Route B when communicating with the 23

AT and the target FLSE uses Route A when communicating with the AT. This call flow assumes that the 24

tunnels among all eBSs in the Route Set and among eBSs and the AGW (if multiple PMIP tunnels are 25

allowed) were established when each eBS was added into the Route Set. 26

3GPP2 A.S0020-0 v1.0

3-29

Tflflush-ipt

timeAT

c

d

f

b

a

g

TargetFLSE

(Route A)

e

Data (IP)

SourceFLSE

(Route B)DAP

Data (Route B)

IPT-Notification(target is FLSE)

IPT-Notification Ack(Prev FLSE, Pending Data)

Route B packets (encapsulated in Route A)

RLP Route B (partially sent packets / compressed packets)

Tunneled data (full IP packets)Data (Route A for flows that do

not require in-order)

IPT-Notification (target is FLSE)

IPT-Notification AckTnot-ipt

i

Source FLSE tunnels buffered full IP packets to target FLSE

Data (Route A – IP from Source FLSE)

h

IPT-Notification (source is not FLSE)


j

k

AT selects target FLSE

IPT-Flush

Data (Route A for all flows)

l

m

Tnot-ipt

1

Figure 3.5.1-1 FLSE Switch 2

a. The AT is currently connected to the source FLSE which receives IP packets from the DAP. The 3

source FLSE sends the packets to the AT on Route B. 4

b. The AT decides to select the target FLSE. 5

Upon detecting that the AT has selected the target FLSE as the forward link serving eBS, the target FLSE 6

notifies all ANRIs in the Route Set and the DAP (if it is not in the route set) that it has become the new 7

FLSE. 8

Steps ‘c’-‘d’ and ‘g’-‘h’ may occur in parallel. 9

c. The target FLSE sends an IPT-Notification message to the source FLSE and starts timer Tnot-ipt. The 10

message contains the ANID of the target FLSE which is the new FLSE. 11

d. Upon receipt of the IPT-Notification message, the source FLSE sends an IPT-Notification Ack 12

message to the target FLSE. The message contains the flag indicating that the sender is the source 13

FLSE and also whether there is remaining buffered IP packets in the source FLSE that requires in-14

order delivery. This call flow assumes that the source FLSE has buffered IP packets that requires in-15

order delivery. Upon receipt of the IPT-Notification Ack message, the target FLSE stops timer Tnot-ipt 16

and, since the buffered in-order data flag is set, starts timer Tflflush-ipt. The target FLSE starts serving 17

tunneled link-layer packets. Also, it serves IP packets from DAP on flows that do not require in-order 18

delivery. 19

3GPP2 A.S0020-0 v1.0

3-30

e. Upon receipt of the IPT-Notification message, the source FLSE tunnels all partially sent packets or 1

header-compressed packets destined for the AT to the target FLSE in the link-layer tunnel. These 2

packets are encapsulated in Route B to the target FLSE. The target FLSE encapsulates the fragments 3

in Route A packets before transmitting to the AT. This step may occur anytime after step ‘c’. 4

f. Upon receipt of the IPT-Notification message, the source FLSE forwards any buffered IP packets to 5

the target FLSE through the IP tunnel it has with the target FLSE. The target FLSE transmits these 6

packets to the AT using Route A. The target FLSE serves the tunneled IP packets to the AT before 7

the tunneled IP packets it received from the DAP on flows that required in-order delivery. This step 8

may occur anytime after step ‘c’ 9

g. The target FLSE sends an IPT-Notification message to the DAP and starts timer Tnot-ipt. The message 10

contains the ANID of the target FLSE to which the DAP will send new IP packets. 11

h. Upon receipt of the IPT-Notification message, the DAP sends an IPT-Notification Ack message to the 12

target FLSE. The target FLSE stops timer Tnot-ipt. 13

i. New IP packets from the DAP are then tunneled from the DAP to the target FLSE through the IP 14

tunnel. The target FLSE transmits the packets that do not require in-order delivery to the AT via 15

Route A. This step may occur anytime after step ‘g’. 16

Steps ‘j’-‘k’ may occur anytime after step ‘g’. 17

j. Upon receiving notification that the FLSE has moved, the DAP sends an IPT-Notification message to 18

the source FLSE to indicate to the source FLSE that the DAP will no longer forward IP packets to the 19

source FLSE. The DAP starts timer Tnot-ipt. 20

k. Upon receipt of the IPT-Notification message, the source FLSE sends an IPT-Notification Ack 21

message to the DAP. This is done because two FLSE switches may have occurred in a short period of 22

time; refer to section 3.5.2. Upon receipt of the IPT-Notification Ack message, the DAP stops timer 23

Tnot-ipt. If the source eBS detects that it is FLSE, the source eBS has to repeat the steps in this call 24

flow as a target FLSE (refer to section 3.5.2). 25

l. When the source FLSE determines that there is no longer any in-order data buffered or being 26

transferred in-flight from the DAP, the source FLSE sends an IPT-Flush message to the target FLSE. 27

Upon receipt of the IPT-Flush message, the source FLSE stops timer Tflflush-ipt. 28

m. Upon receipt of the IPT-Flush message or the expiration of timer Tflflush-ipt, the target FLSE starts 29

serving IP packets from the DAP on flows that require in-order delivery. 30

31

3.5.2 FLSE Switch - Error Recovery 32

This scenario describes the call flow for a successful error recovery during FLSE switch. In this call flow, 33

it is assumed that successive FLSE switches occur in a short period of time and the notification messages 34

for these two successive switches are received out-of-order at the DAP. This scenario may also occur as a 35

result of false FLSE detection at one of the eBSs. As a result, the DAP sends the forward link data to the 36

incorrect FLSE. This call flow demonstrates how the error situation is self-corrected after a short period 37

of time. Note that there is no interruption in the user traffic as the incorrect FLSE can still forward data to 38

the correct FLSE. This call flow assumes that the tunnels among all eBSs in the Route Set and among 39

eBSs and the AGW (if multiple PMIP tunnels are allowed) were established when each eBS was added 40

into the Route Set. 41

3GPP2 A.S0020-0 v1.0

3-31

Tnot-ipt

timeAT

b

d

a

f

eBS1

c

Data (IP)

eBS2 DAP

h

g


i

j





Tnot-ipt

k*

l

m

n

o

Tnot-ipt

Tnot-ipt

AT selects eBS1 as FLSE

IPT-Notification (eBS2 is not FLSE)


Data (link-layer packet Route B)


eBS2 detects it is still FLSE and restarts FLSE switch procedure as target FLSE


* This step is triggered from step ‘b’ but is received out -of-order at the DAP after step i

IPT-Notification (eBS1 is FLSE) e

Tnot-ipt

AT selects eBS2 as FLSE


1

Figure 3.5.2-1 FLSE Switch - Error Recovery 2

a. eBS2 is the FLSE which receives IP packets from the DAP and then transmits these packets to the AT. 3

b. The AT selects eBS1 as the FLSE. 4

Upon detecting that the AT has selected eBS1 as the FLSE, eBS1 notifies all ANRIs in the Route Set and 5

the DAP (if it is not in the route set) that it has become the new FLSE. However, before the notification is 6

received at the DAP, the AT selects eBS2 as the FLSE again and the notification generated from eBS2 is 7

received at the DAP first. 8

c. eBS1 sends an IPT-Notification message to eBS2 and starts timer Tnot-ipt. The message contains the 9

ANID of eBS1 which is the new FLSE. 10

d. Upon receipt of the IPT-Notification message, eBS2 sends an IPT-Notification Ack message to eBS1. 11

eBS1 stops timer Tnot-ipt. 12

e. eBS1 sends an IPT-Notification message to DAP and starts timer Tnot-ipt. The message contains the 13

ANID of eBS1 which is the new FLSE. The message is lost and DAP does not receive the message. 14

f. The AT selects eBS2 as the FLSE. Upon detecting that the AT has selected eBS2 as the FLSE, eBS2 15

notifies all ANRIs in the Route Set that it has become the new FLSE. 16

Steps ‘g’-‘h’ and ‘i’-‘j’ may occur in parallel. 17

g. eBS2 sends an IPT-Notification message to eBS1 and starts timer Tnot-ipt. The message contains the 18


h. Upon receipt of the IPT-Notification message, eBS1 sends an IPT-Notification Ack message to eBS2. 20


3GPP2 A.S0020-0 v1.0

3-32

i. eBS2 sends an IPT-Notification message to the DAP and starts timer Tnot-ipt. The message contains 1

the ANID of eBS2 which is the new FLSE. 2

j. Upon receipt of the IPT-Notification message, the DAP sends an IPT-Notification Ack message to 3

eBS2. eBS2 stops timer Tnot-ipt. Note: since eBS2 is the FLSE to which the DAP is currently sending 4

IP packets, the DAP does not perform any further action. 5

k. The timer Tnot-ipt in eBS1 expires. The IPT-Notification message is retransmitted and arrives at the 6

DAP. The message contains the ANID of eBS1 as the FLSE. The DAP now forwards IP packets to 7

eBS1 instead of eBS2. Any packets received by eBS1 will be forwarded to eBS2 which is the correct 8

FLSE. If eBS1 does not know the correct FLSE, then it forwards these IP packets back to the DAP. 9

l. Upon receipt of the IPT-Notification message, the DAP sends an IPT-Notification Ack message to 10

eBS1. eBS1 stops timer Tnot-ipt. 11

m. Upon receipt of the IPT-Notification message from eBS1, the DAP sends an IPT-Notification 12

message to the previous FLSE (from the perspective of the DAP), which is eBS2 in this call flow, to 13

inform eBS2 that it is no longer the FLSE. The DAP then starts timer Tnot-ipt. 14

n. Upon receipt of the IPT-Notification message, eBS2 sends an IPT-Notification Ack message back to 15

the DAP. The DAP stops timer Tnot-ipt. 16

o. eBS2 still detects over the UMB air-interface that AT is currently selecting eBS2 as the FLSE. 17

Therefore, it restarts the FLSE switch procedure as the target FLSE (refer to section 3.5.1). 18

19

3.5.3 FLSE Switch - Error Recovery from False Handoff Detection 20

This scenario describes the call flow for a successful error recovery when an eBS detects a FLSE switch 21

request from the access terminal, when the access terminal did not send such a request. This error may 22

occur due to a poor channel condition. This call flow demonstrates how the error situation is self-23

corrected after a short period of time. 24

3GPP2 A.S0020-0 v1.0

3-33

Tnot-ipt

timeAT

b

d

a

f

eBS1

c

Data (IP)

eBS2 DAP

h

g


i

j





Tnot-ipt

k

l

m

nTnot-ipt



Data (RLP Route B)


eBS2 detects handoff request from the AT

IPT-Notification (eBS1 is FLSE) eTnot-ipt

AT continues to select eBS2 as FLSE


eBS1 wrongly detects a handoff request from the AT

p

o



1

Figure 3.5.3-1 FLSE Switch - Error Recovery 2

a. eBS2 is the FLSE which receives IP packets from the DAP and then transmits these packets to the AT. 3

b. eBS1 has a false alarm, and detects that AT selects eBS1 as the FLSE. The AT continues to select 4

eBS2 as FLSE. 5

Because eBS1 wrongly detects that it is the FLSE, eBS1 notifies all ANRIs in the Route Set and the DAP 6

that it has become the new FLSE. 7

c. eBS1 sends an IPT-Notification message to eBS2 and starts timer Tnot-ipt. The message indicates that 8

eBS1 is the FLSE for the AT. 9

d. Upon receipt of the IPT-Notification message, eBS2 sends an IPT-Notification Ack message to eBS1. 10


e. eBS1 sends an IPT-Notification message to DAP and starts timer Tnot-ipt. The message contains the 12


f. Upon receipt of the IPT-Notification message, the DAP sends an IPT-Notification Ack message to 14

eBS1, and starts forwarding packets to eBS1. Upon receiving the IPT-Notification Ack message, 15


g. Upon receipt of the IPT-Notification message from eBS1, the DAP sends an IPT-Notification 17


inform eBS2 that it is no longer the FLSE. The DAP then starts timer Tnot-ipt. The DAP starts sending 19

data packets to eBS1. Any packets that eBS1 transmit to the AT will be lost because the AT is not 20

monitoring eBS1 for forward link packets. After error recovery is completed, these erroneous packets 21

may be retransmitted again to the AT by tunneling through eBS2. 22

3GPP2 A.S0020-0 v1.0

3-34

h. Upon receipt of the IPT-Notification message, eBS2 sends an IPT-Notification Ack message back to 1


i. The AT continues to select eBS2 as the FLSE. 3

j. Upon detecting that the AT has selected eBS2 as the FLSE, eBS2 notifies all ANRIs in the Route Set 4

and the DAP that it has become the new FLSE. This detection at eBS2 may happen anytime after step 5

‘g’. 6

Steps ‘k’-‘l’ and ‘m’-‘n’ may occur in parallel. 7

k. eBS2 sends an IPT-Notification message to eBS1 and starts timer Tnot-ipt. The message contains the 8


l. Upon receipt of the IPT-Notification message, eBS1 sends an IPT-Notification Ack message to eBS2. 10


m. eBS2 sends an IPT-Notification message to the DAP and starts timer Tnot-ipt. The message contains 12

the ANID of eBS2 which is the new FLSE. 13

n. Upon receipt of the IPT-Notification message, the DAP sends an IPT-Notification Ack message to 14

eBS2. eBS2 stops timer Tnot-ipt. 15

o. Upon receipt of the IPT-Notification message from eBS2, the DAP sends an IPT-Notification 16


inform eBS1 that it is no longer the FLSE. The DAP then starts timer Tnot-ipt. The DAP starts sending 18

data packets to eBS2. 19

p. Upon receipt of the IPT-Notification message, eBS1 sends an IPT-Notification Ack message back to 20


22

3.5.4 RLSE Switch 23

This scenario describes the call flow for a successful reverse link serving eBS switch. In this call flow, it 24

is assumed that the source RLSE, the target RLSE and the DAP are different eBSs. If the source RLSE 25

and the DAP are the same or if the target RLSE and the DAP are the same entity, the steps corresponding 26

to the signaling between these eBSs are omitted. In this call flow, the AT uses Route B when 27

communicating with the source RLSE and uses Route A when communicating with the target RLSE. 28

Note: This call flow assumes that the AGW configuration requires the IP packets from RLSE to be 29

tunneled back to the DAP. If AGW configuration allows any eBS in the Route Set to directly relay 30

reverse-link IP packets to the AGW, then reverse-link IP packets from the RLSE in the call flow will 31

terminate at the AGW instead of the DAP. 32

3GPP2 A.S0020-0 v1.0

3-35

Trlflush-ipt

tim eAT

b

a

TargetRLSE

(Route A)

Data (IP)

SourceRLSE

(Route B )DAP

Data (Route B )

Data (Route B packets) Route B packets

Tunneled data (all full IP packets)

Data (Route A )

Data (IP) g

h

Tnot-ipt

IPT-Notification (target is RLSE )

IPT-Notification Ack(Prev RLSE, Pending Data)

Tnot-iptIPT-Notification (target is RLSE )


c

d

e

f

AT selects target RLSE

Tunneled data (full IP packets that do not require in -order)

IPT-Flush i

j

1

Figure 3.5.4-1 RLSE Switch 2

a. The AT is currently connected to and sending packets to the source RLSE on Route B. The source 3

RLSE sends the IP packets either to the DAP or the AGW. 4

b. The AT decides to select the target RLSE. 5

The target RLSE sends an IPT-Notification message to all ANRIs in the Route Set. Steps ‘c’-‘d’ and ‘e’-6

‘f’ may occur in parallel. 7

c. The target RLSE sends an IPT-Notification message to the source RLSE and starts timer Tnot-ipt. The 8

message indicates that the target RLSE has become the current RLSE and the previous RLSE may 9

deallocate reverse airlink resources assigned to the AT. 10

d. Upon receipt of the IPT-Notification message, the source RLSE sends an IPT-Notification Ack 11

message to the target RLSE. The message contains the indication that the sender is the previous 12

RLSE and also whether the source RLSE is awaiting data that requires in-order delivery. This call 13

flow assumes that the source RLSE is waiting for some data that requires in-order delivery. Upon 14

receipt of the IPT-Notification Ack message, the target RLSE stops timer Tnot-ipt and since the In-15

Order RL L2 Data Pending is set, starts timer Trlflush-ipt. 16

e. The target RLSE sends an IPT-Notification message to the DAP and starts timer Tnot-ipt. The message 17

indicates that the target RLSE has become the current RLSE and the previous RLSE may deallocate 18

reverse air-link resources assigned to the AT. This message is only sent to route set members and not 19

the DAP if it is outside of the route set. 20

f. Upon receipt of the IPT-Notification message, the DAP sends an IPT-Notification Ack message to the 21

target RLSE. The target RLSE stops timer Tnot-ipt. 22

g. The AT sends all partially sent packets to the target RLSE in Route B packets via Route A. The target 23

RLSE tunnels these Route B packets to the source RLSE which then forwards IP packets either to the 24

DAP or the AGW, subject to the system configuration. This step may occur anytime after step ‘b’. 25

h. New IP packets from the AT are transmitted to the target RLSE via Route A. The target RLSE 26

forwards the IP packets that do not require in-order delivery to the DAP through the IP tunnel or to 27

3GPP2 A.S0020-0 v1.0

3-36

the AGW, subject to the system configuration. The target RLSE buffers the packets that require in-1

order delivery. This step may occur anytime after step ‘b’. 2

i. When the source RLSE has determined there is no pending in-order data, the source RLSE sends an 3

IPT-Flush message to the target RLSE. Upon receipt of the IPT-Flush message, the target RLSE stops 4

timer Trlflush-ipt. 5

j. Upon receipt of the IPT-Flush message or the expiration of timer Trlflush-ipt., the target RLSE starts 6

forwarding IP packets on flows that require in-order delivery to the DAP through the IP tunnel or to 7

the AGW, subject to the system configuration. 8

9

3.6 DAP Handoff 10

This section describes the call flows associated with a DAP handoff. 11

The DAP is the eBS to which the AGW points its forward-link tunnel to according to the latest binding 12

that the DAP has performed with the AGW. A DAP handoff can occur when the AT moves between 13

different serving eBSs. The main purpose of DAP handoff is to increase routing efficiency, e.g., if the AT 14

becomes stationary, then it is beneficial for the FLSE to become the DAP to remove triangular routing 15

from AGW to DAP and then to FLSE. Also because of mobility, the FLSE and RLSE of an AT may be 16

far away from the DAP such that the DAP is no longer in the Route Set of the AT. In this scenario, the 17

DAP should also be moved to some ANRI in the Route Set to reduce packet forwarding latency. 18

DAP handoff has two modes: AT-assisted and AN-initiated. 19

• For AT-assisted mode, the AT sends a DAPMoveRequest message (refer to [1]) to the target DAP to 20

assists the DAP handoff. The target DAP may accept or reject the request. If the request is accepted, 21

the target DAP updates the PMIP binding with the AGW and notifies all of the ANRIs in the Route 22

Set of the AT. 23

• For AN-initiated mode, the target DAP may decide to become DAP and updates the PMIP binding 24

with the AGW. The AN-initiated mode is transparent to the AT. 25

3.6.1 Intra-AGW DAP Handoff without Multiple Tunnels 26

This scenario describes the call flow for an intra-AGW DAP handoff. 27

3GPP2 A.S0020-0 v1.0

3-37

IP packets (in-order)

Tnot-ipt

timeAT

a*

d**

f

g

h

Target DAP

SRNC

b


Source DAP

Tnot-ipt

DAPMoveRequest

DAPAssignment (Accept Ind = 1, Lifetime)


AGW

i

c

IPT-Notification (DAP Record, Timestamp)

IPT Notification (DAP Record, Timestamp)

* = optional** = conditional

Trrq-pmip

PMIP-Registration Request (Timestamp)

PMIP-Registration Reply(Code 0 – registration accepted, timestamp)

FLSE

IP Packets

IP Packets

Twaitdap-ipt

e

jIPT Notification (DAP Record, Timestamp)

IPT-Notification Ack (FLSE)Tnot-ipt

IP packets(delay-sensitive)

IP Packets

k

l

1

Figure 3.6.1-1 Intra-AGW DAP Handoff without Multiple Tunnels 2

a. In the AT-assisted DAP handoff mode, the AT initiates a DAP handoff and sends a 3

DAPMoveRequest message to the target DAP. This step may be omitted in the AN-initiated DAP 4

handoff mode. 5

b. The target DAP updates the PMIP binding with the AGW by sending a PMIP-Registration Request 6

message to the AGW and starts timer Trrq-pmip. The timestamp in the Identification field is used for 7

replay protection as part of PMIP procedure. Refer to section 2.5.1.6. 8

c. The AGW confirms the binding update by sending a PMIP-Registration Reply message to the target 9

DAP along with the lifetime of the tunnel. The target DAP stops timer Trrq-pmip. 10

d. In the AT-assisted DAP handoff mode, the target DAP responds to the AT with a DAPAssignment 11

message indicating acknowledgement, whether or not the DAP handoff succeeded and the remaining 12

lifetime of the binding. 13

e. Upon sending the successful PMIP-Registration Reply message, the AGW starts forwarding new IP 14

packets to the target DAP, which then forwards the packets to the FLSE. The FLSE serves the IP 15

packets that do not require in-order delivery from the target DAP immediately. The FLSE also starts 16

timer Twaitdap-ipt upon receipt of new IP packets from the target DAP and buffers new IP packets that 17

require in-order delivery from the target DAP. 18

Upon completion of step ‘c’, the target DAP sends an IPT-Notification message to all ANRIs in the Route 19

Set, including the SRNC and the previous DAP of the AT. Note that the DAP always sends the IPT-20

Notification (DAP) messages to all ANRIs in the Route Set (and the old DAP, if exists) after reception of 21

the PMIP-Registration Reply message from the AGW, even if the PMIP tunnel establishment procedure 22

is triggered by the lifetime expiration. Steps ‘f’, ‘h’ and ‘j’ may occur in parallel. 23

3GPP2 A.S0020-0 v1.0

3-38

f. The target DAP sends an IPT-Notification message to the SRNC and starts timer Tnot-ipt. The 1

message indicates that the target DAP is now the current DAP. The message also contains the 2

timestamp that the target DAP used in updating the PMIP tunnel with the AGW. 3

g. The SRNC responds with an IPT-Notification Ack message and the target DAP stops timer Tnot-ipt. 4

h. The target DAP sends an IPT-Notification message to the source DAP and starts timer Tnot-ipt. The 5

message indicates that the target DAP is now the current DAP. The message also contains the time-6

stamp that the target DAP used in updating the data attachment binding with the AGW. 7

i. Upon receipt of the IPT-Notification message, the source DAP responds with an IPT-Notification 8

Ack message. Upon receipt of the IPT-Notification Ack message, the target DAP stops timer Tnot-ipt. 9

j. The target DAP sends an IPT-Notification message to the FLSE and starts timer Tnot-ipt. The message 10

indicates that the target DAP is now the current DAP. The FLSE also starts timer Twaitdap-ipt if it has 11

not been started. The message also contains the timestamp that the target DAP used in updating the 12

data attachment binding with the AGW. 13

k. Upon receipt of the IPT-Notification message, the FLSE responds with an IPT-Notification Ack 14

message. Upon receipt of the IPT-Notification Ack message, the target DAP stops timer Tnot-ipt. 15

l. Upon expiration of timer Twaitdap-ipt, the FLSE starts serving IP packets that required in-order 16

delivery which are received from the DAP. 17

18

3.6.2 Intra-AGW DAP Handoff with Multiple Tunnels 19

This scenario describes the call flow for an intra-AGW DAP handoff. This call flow also assumes that an 20

RL+Primary binding and an RL-Only binding, respectively, exist from the source DAP and the target 21

DAP to the AGW before the handoff begins. 22

timeAT

b

c*

Source DAP

Target DAP

d

e

f**

DAPMoveRequest

DAPAssignment (Accept Ind = 1, Lifetime)

g

h

l

SRNC

IPT-Notification (DAP Information, Timestamp)Tnot-ipt


AGW

k

IPT-Notification (DAP Information, Timestamp)


i

j

a

PMIP-Registration Reply (Lifetime, Timesstamp)

Tnot-ipt

Trrq-pmip

* = optional

RL-Only Tunnel

RL +Primary PMIP Tunnel

RL PMIP Tunnel

RL+Primary PMIP Tunnel

PMIP-Reg. Req. (RL + Primary, Timesstamp)

** = conditonal 23

Figure 3.6.2-1 Intra-AGW DAP Handoff with Multiple Tunnels 24

a. The source DAP has an active PMIP tunnel to the AGW. 25

3GPP2 A.S0020-0 v1.0

3-39

b. The target DAP has an active Reverse Link PMIP tunnel to the AGW prior to the handoff. 1

c. In the AT-assisted DAP handoff mode, the AT initiates a DAP handoff and sends a 2

DAPMoveRequest message to the target DAP. This step may be omitted in the AN-initiated DAP 3

handoff mode. 4

d. The target DAP switches the PMIP binding with the AGW by sending a PMIP-Registration Request 5

message to the AGW and starts timer Trrq-pmip. The PMIP-Registration Request message contains a 6

CVSE which indicates that both the RL and FL (primary) tunnel directions are active. Since the AGW 7

can only maintain one active FL tunnel, the AGW autonomously deactivates the FL tunnel associated 8

with the source DAP. 9

e. The AGW confirms the binding update by sending a PMIP-Registration Reply message to the target 10

DAP along with the lifetime of the tunnel. The target DAP stops timer Trrq-pmip. 11

f. In the AT-assisted DAP handoff mode, the target DAP responds to the AT with a DAPAssignment 12



Upon completion of step ‘e’, the target DAP sends an IPT-Notification message to all ANRIs in the Route 15

Set, including the SRNC and the previous DAP of the AT. Steps ‘g’ and ‘i’ may occur in parallel. 16

g. The target DAP sends an IPT-Notification message to the SRNC and starts timer Tnot-ipt. The 17


stamp that the target DAP used in updating the PMIP tunnel with the AGW. 19

h. The SRNC responds with an IPT-Notification Ack message and the target DAP stops timer Tnot-ipt. 20

i. The target DAP sends an IPT-Notification message to the source DAP and starts timer Tnot-ipt. The 21


stamp that the target DAP used in updating the data attachment binding with the AGW. 23

j. Upon receipt of the IPT-Notification message, the source DAP responds with an IPT-Notification 24

Ack message. Upon receipt of the IPT-Notification Ack message, the target DAP stops timer Tnot-ipt. 25

k. The target DAP has an active Forward (primary) and Reverse Link PMIP tunnel to the AGW. 26

l. The source DAP maintains an active RL-Only tunnel to the AGW as long as it remains in the route 27

set. 28

29

3.6.3 Intra-AGW DAP Handoff - Recovery from Invalid Timestamp 30

This scenario describes the call flow for an intra-AGW DAP handoff. This call flow assumes that the 31

system time in eBS1 and eBS2 are not synchronized and PMIP tunnel binding with the AGW occur very 32

close to each other. This call flow assumes that the value of Timestamp1 is less than or equal to 33

Timestamp2. Note that there is no interruption to the user’s traffic in this call flow. 34

3GPP2 A.S0020-0 v1.0

3-40

Tnot-ipt

timeAT

a*

k

l

eBS2

b


eBS1

Tnot-ipt


AGW

j

IPT-Notification (DAP, Timestamp3)

IPT Notification (DAP, Timestamp2)

PMIP-Registration Reply(Code 0 - registration accepted,Timestamp2)

Tnot-ipt

e

g

h

i

DAPMoveRequest

DAPAssignment

c

d**

DAPMoveRequest

DAPAssignment

n

o

f*

m**

Trrq-pmip

PMIP-Registration Request (Timestamp2)

* = optional** = conditional

IPT Notification (DAP, Timestamp2)

Trrq-pmip

PMIP-Registration Request (Timestamp1)

PMIP-Registration Reply (Code 133 - identification mismatch, Timestamp-AGW)

Trrq-pmipPMIP-Registration Request (Timestamp3)

PMIP-Registration Reply (Code 0 – registration accepted, Timestamp 3)

1

Figure 3.6.3-1 Intra-AGW DAP Handoff - Recovery from Invalid Timestamp 2

a. In the AT-assisted DAP handoff mode, the AT initiates a DAP handoff and sends a 3

DAPMoveRequest message to the target DAP. This call flow assumes that the target DAP in this step 4

is eBS2. This step may be omitted in the AN-initiated DAP handoff mode. 5

b. eBS2 updates the data attachment binding with the AGW by sending a PMIP-Registration Request 6

message to the AGW. The message contains the value Timestamp2. eBS2 starts timer Trrq-pmip. 7

c. The AGW confirms the binding update by sending PMIP-Registration Reply message to eBS2 along 8

with the lifetime of the tunnel. eBS2 stops timer Trrq-pmip. 9

d. In the AT-assisted DAP handoff mode, the target DAP responds to the AT with a DAPAssignment 10



Upon completion of step ‘c’, eBS2 sends an IPT-Notification message to all ANRIs in the Route Set, 13

including the SRNC and the previous DAP of the AT. 14

e. eBS2 sends an IPT-Notification message to eBS1 and starts timer Tnot-ipt. However, the message is 15

lost and eBS1 does not receive the message. 16

f. In the AT-assisted DAP handoff mode, the AT initiates another DAP handoff and sends a 17

DAPMoveRequest message to the target DAP. This call flow assumes that the target DAP in this step 18

is eBS1. This step may be omitted in the AN-initiated DAP handoff mode. 19

g. eBS1 requests PMIP binding with the AGW by sending PMIP-Registration Request message to the 20

AGW. eBS1 starts timer Trrq-pmip. The message contains the value Timestamp1 which is assumed to 21

be less than or equal to Timestamp2 because both eBSs do not have synchronized system time. Note 22

3GPP2 A.S0020-0 v1.0

3-41

that if Timestamp1 is greater than Timestamp2 then the request will succeed and the remainder of the 1

call flow is identical to the call flow in section 3.6.1. 2

h. Because Timestamp1 is not greater than Timestamp2, the PMIP-Registration Request from eBS1 fails 3

replay protection at the AGW. The AGW then sends a PMIP-Registration Reply message containing 4

Code 133 - registration identification mismatched to eBS1. eBS1 stops timer Trrq-pmip. Upon receipt 5

of the PMIP-Registration Reply message, eBS1 waits for the value of Tnot-ipt or until a new IPT-6

Notification message containing the new Timestamp used by eBS2 is received before trying to 7

register with the AGW again. 8

i. Timer Tnot-ipt at eBS2 expires. eBS2 retransmits the IPT-Notification message in step ‘e’. 9

j. Upon receipt of the IPT-Notification message, eBS1 responds with an IPT-Notification Ack message 10

to eBS2. Upon receipt of the IPT-Notification Ack message, eBS2 stops timer Tnot-ipt. 11

k. Upon receipt of the IPT-Notification message, eBS1 requests PMIP binding with the AGW by 12

sending a PMIP-Registration Request message to the AGW. eBS1 starts timer Trrq-pmip. The message 13

contains the value Timestamp3 which is greater than Timestamp2. Timestamp3 may be eBS1 system 14

time if it is greater than Timestamp2. Otherwise, eBS1 should set Timestamp3 to be greater than 15

Timestamp2 by one second. 16

l. The AGW confirms the binding update by sending PMIP-Registration Reply message to eBS1 along 17

with the lifetime of the tunnel. eBS1 stops timer Trrq-pmip. 18

m. In the AT-assisted DAP handoff mode, eBS1 responds to the AT with a DAPAssignment message 19

indicating acknowledgement, whether or not the DAP handoff succeeded and the remaining lifetime 20

of the binding. 21

Upon completion of step ‘l’, eBS1 sends an IPT-Notification message to all ANRIs in the Route Set, 22

including the SRNC and the previous DAP of the AT. 23

n. eBS1 sends an IPT-Notification message to eBS2 and starts timer Tnot-ipt. The message indicates that 24

the eBS1 is now the current DAP. The message also contains the timestamp that eBS1 used in 25

updating the PMIP tunnel with the AGW. If eBS2 has an RL+Primary binding with the AGW, the 26

binding between eBS2 and the AGW is changed to RL-Only. 27

o. eBS2 responds with an IPT-Notification Ack message. Upon receipt of the IPT-Notification Ack 28

message, eBS1 stops timer Tnot-ipt. 29

30

3.6.4 Intra-AGW DAP Handoff before IPT-Notification Message is Received at the Target DAP 31

This scenario describes the call flow for an intra-AGW DAP handoff where a new DAP handoff is 32

initiated before the IPT-Notification message triggered by the previous PMIP registration is received at 33

the target DAP. This scenario may occur when the target DAP initiates DAP handoff while the source 34

DAP is refreshing its PMIP tunnel lifetime with the AGW. Note that there is no interruption to the user’s 35

traffic in this call flow. 36

3GPP2 A.S0020-0 v1.0

3-42

Tnot-ipt

timeAT

h

i

eBS2

b


eBS1 AGW

g

PMIP-Registration Reply(Code 0 - registration accepted,Timestamp-a)

d

f

c

j

Trrq-pmip

PMIP-Registration Request (Timestamp-a)

IPT Notification (DAP, Timestamp-a)

Trrq-pmipPMIP-Registration Request (Timestamp-b)

PMIP-Registration Reply (Code 0 – registration accepted, Timestamp-b)

Tnot-iptIPT Notification (DAP, Timestamp-b)


eBS1 is the DAP

eBS2 decides to become the DAP

a

e

eBS2 can retry to become DAP again

1

Figure 3.6.4-1 Intra-AGW DAP Handoff before IPT-Notification Message is Received at the 2

Target DAP 3

a. eBS1 is the current DAP and eBS2 decides to become the DAP for the AT. 4

b. eBS2 updates the PMIP binding with the AGW by sending a PMIP-Registration Request message to 5

the AGW and starts timer Trrq-pmip. The message contains the value Timestamp-a. 6

c. The AGW confirms the binding update by sending a PMIP-Registration Reply message to eBS2 7

along with the lifetime of the tunnel. eBS2 stops timer Trrq-pmip. 8

d. Before the IPT-Notification message from eBS2 is received by eBS1, eBS1 refreshes its PMIP 9

binding with the AGW by sending a PMIP-Registration Request message to the AGW and starts 10

timer Trrq-pmip. The message contains the value Timestamp-b which is larger than Timestamp-a. 11

If the value Timestamp-b is not larger than Timestamp-a, the AGW rejects the PMIP-Registration 12

Request message. Refer to 3.6.1 for details. 13

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

along with the lifetime of the tunnel. eBS1 stops timer Trrq-pmip. 15

f. Upon receipt of the successful PMIP-Registration Reply message, eBS2 transmits an IPT-Notification 16

message indicating that eBS2 is the DAP for the AT with Timestamp-a to each ANRI in its route set, 17

including eBS1. eBS2 starts timer Tnot-ipt. 18

g. Upon receipt of the IPT-Notification message, eBS1 responds with an IPT-Notification Ack message. 19

Upon receipt of the IPT-Notification Ack message, eBS2 stops timer Tnot-ipt. 20

h. Upon receipt of the successful PMIP-Registration Reply message, eBS1 transmits an IPT-Notification 21

message indicating that eBS1 is the DAP for the AT with Timestamp-b to each ANRI in its route set, 22

including eBS2. eBS1 starts timer Tnot-ipt. 23

i. Upon receipt of the IPT-Notification message with Timestamp-b, eBS2 realizes that it is no longer the 24

DAP for the AT and responds with an IPT-Notification Ack message. Upon receipt of the IPT-25

Notification Ack message, eBS1 stops timer Tnot-ipt. 26

j. eBS2 may retry DAP Handoff procedure as described in section 3.6.1 again. 27

28

3GPP2 A.S0020-0 v1.0

3-43

3.6.5 Inter-AGW DAP Handoff 1

This scenario describes the call flow for an inter-AGW handoff. This call flow assumes that initially the 2

AT is served by eBS1 which is the DAP for the AT and is connected to AGW1. SRNC1 is initially the 3

SRNC for the AT. Later, eBS2 is added to the route set and eBS2 cannot connect to AGW1. Note that 4

throughout this call flow there is no interruption to user traffic as IP packets arriving in eBS1 on the 5

forward-link can be encapsulated in link-layer packets of eBS1 ANRI and tunneled to the AT through 6

eBS2’s link-layer tunnel if eBS2 becomes the FLSE. On the reverse-link, the AT will not send packets 7

with IP address belonging to AGW1 through eBS2 route as the LinkID of eBS2 is different from eBS1. 8

Instead, the AT will also encapsulate IP packets in link-layer packets of eBS1 and tunnel the packets 9

through eBS2’s link-layer tunnel, if eBS2 is the RLSE. 10

3GPP2 A.S0020-0 v1.0

3-44

tim eA T e B S 2e B S 1 A G W 2

P M IP -R e g is tra tio n R e p ly

IA S -S ess ion In fo rm -a tio n R eq u e st

IA S -S R N CT ra n s fe rR e q u est

T n o t-ip t

IP T -N o tifica tion

T str-ia s

R o u te O p e n R e qu e st

R o u te C re a te (S R N C 2 A N ID )

S R N C 1 S R N C 2 A G W 1

IA S -S e ss ion In fo rm -a tio n R espo n se

R o u te O pe n A cce p t

R o u te O p e n R e qu e st

IA S -S R N C T ra ns fe rR e sp on se

R ou teO p en A cce p t (n ew U A T I)

E A P A cce ss A u th e n tica tio n E A P A cce ss A u th en tica tio n

S e ss ion C o n fig u ra tion

L in k ID A ss ig n m en t

D A P M o ve R e q ue stR e qu e st

D A P M ove R e q u est

P M IP -R e g is tra tio n R eq u e st

D A P A ss ign m e n t

IP A d dre ss A ss ign m e n t a n d M o b ile IP b in d in g u p da te

IP T -N o tifica tio n A ck

IP T -N o tifica tio n

IP T -N o tifica tion

IP T -N o tifica tio nA ck

R o u te M a p

U A T IC om p le te

IA S -U A T I U p d a te

IA S -U A T I U p d a te

IA S -U A T I U p da te

IA S - U A T I U pd a te A ck

IA S - U A T I U pd a te A ck

IA S - U A T I U p d a te A ck

D a taD a ta

T n o t-ip t

T n o t-ip t

T u u p d -ia s

T u u p d -ia s

T u u p d -ia s

T sir-ia s

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

p

q

r

s

t

u

w **

x

y

cc**

d d **

e e

ff

g g

h h

ii

jj

z

* = o p tio na l** = con d itio n a l

T rrq -p m ip

A A A -A cco un ting -R eq u e st [S ta rt]

A A A -A ccou n tin g -R esp o n se

v *

a a

b b

IP T -N o tifica tion A ck

D a ta D a ta

T a cc t-a a a

1

Figure 3.6.5-1 Inter-AGW DAP Handoff 2

a. eBS1 is the DAP for the AT under AGW1. Data on both the forward-link and the reverse-link is 3

exchanged through eBS1 between AT and AGW1. 4

b. The AT detects pilots from eBS2 and adds eBS2 to the Route Set of the AT by tunneling 5

RouteOpenRequest message to eBS2. 6

3GPP2 A.S0020-0 v1.0

3-45

c. Upon receipt of the RouteOpenRequest message from the AT, eBS2 sends an IAS-Session 1

Information Request message to SRNC1 to retrieve the session information of the AT from SRNC1 2

and starts timer Tsir-ias. 3

d. Upon receipt of the IAS-Session Information Request message from eBS2, SRNC1 sends an IAS-4

Session Information Response message to eBS2. The message contains the information record of the 5

current AGW, i.e., AGW1. Upon receipt of the IAS-Session information Response message, eBS2 6

stops timer Tsir-ias. 7

e. eBS2 sends a RouteOpenAccept message back to the AT to complete Route Setup procedure. 8

f. eBS2 sends a RouteCreate message to the AT to create a route for SRNC2. The message contains the 9

ANID of SRNC2. 10

g. Upon receipt of the RouteCreate message, the AT tunnels a RouteOpenRequest message to SRNC2. 11

h. Upon receipt of the RouteOpenRequest message, SRNC2 triggers SRNC transfer from SRNC1 by 12

sending an IAS-SRNC Transfer Request to SRNC1 and starts timer Tstr-ias. 13

i. Upon receipt of the IAS-SRNC Transfer Request message, SRNC1 accepts SRNC transfer request 14

message by sending an IAS-SRNC Transfer Response message to SRNC2. Upon receipt of the IAS-15

SRNC Transfer Response message, SRNC2 stops timer Tstr-ias. 16

j. SRNC2 completes Route Setup procedure by sending a RouteOpenAccept message to the AT. The 17

message also contains a new UATI assigned by SRNC2 for the AT. 18

k. Upon establishing the new route, the AT sends a new RouteMap message to each ANRI in the Route 19

Set. 20

l. Upon being assigned a new UATI, the AT changes the SessionAnchorRoute to the route correspond-21

ing to SRNC2 and sends a UATIComplete message to SRNC2. 22

Upon receipt of the UATIComplete message from the AT, SRNC2 sends an IAS-UATI Update message 23

to all ANRIs in the route set and DAP. Steps ‘m’, ‘o’ and ‘q’ may occur in parallel. 24

m. SRNC2 sends an IAS-UATI Update message to SRNC1 and starts timer Tuupd-ias. 25

n. Upon receipt of the IAS-UATI Update message, SRNC1 responds with an IAS-UATI Update Ack 26

message. SRNC1 may then close its route with the AT. Upon receipt of the IAS-UATI Update Ack 27

message, SRNC2 stops timer Tuupd-ias. 28

o. SRNC2 sends an IAS-UATI Update message to eBS2 and starts timer Tuupd-ias. 29

p. Upon receipt of the IAS-UATI Update message, eBS2 responds with an IAS-UATI Update Ack 30

message. Upon receipt of the IAS-UATI Update Ack message, SRNC2 stops timer Tuupd-ias. 31

q. SRNC2 sends an IAS-UATI Update message to eBS1 and starts timer Tuupd-ias. 32

r. Upon receipt of the IAS-UATI Update message, eBS1 responds with an IAS-UATI Update Ack 33

message. Upon receipt of the IAS-UATI Update Ack message, SRNC2 stops timer Tuupd-ias. 34

s. SRNC2 triggers EAP Access Authentication with the AT. 35

t. SRNC2 performs session configuration with the AT. After session configuration is completed, the AT 36

sends a SessionUpdated message to all ANRIs in the route set. The ANRIs in the route set send an 37

IAS-Session Information Request message to SRNC2 to retrieve a copy of the session and also the 38

information record of the current AGW, i.e., AGW1, and the new AGW, i.e., AGW2. 39

u. Upon receiving new session information with the new AGW information records, eBS2 assigns the 40

LinkID to the AT. 41

v. In the AT-assisted DAP Handoff mode, eBS2 sends a DAPMoveRequestRequest message to trigger 42

the AT to send a DAPMoveRequest message to eBS2. 43

3GPP2 A.S0020-0 v1.0

3-46

w. Upon receipt of the DAPMoveRequestRequest message from eBS2, the AT sends a 1

DAPMoveRequest message to eBS2. This step can be omitted in AN-initiated DAP Handoff mode. 2

x. eBS2 performs PMIP binding at AGW2 by sending a PMIP-Registration Request message to AGW2. 3

eBS2 starts timer Trrq-pmip. 4

y. Upon receipt of the PMIP-Registration Request message, AGW2 accepts binding request from eBS2 5

by sending a PMIP-Registration Reply message to eBS2. eBS2 stops timer Trrq-pmip. 6

z. eBS2 sends a DAPAssignment message to the AT after receiving the PMIP-Registration Reply 7

message. 8

aa. eBS2 creates an Air Link Record for the AT, sends an AAA-Accounting-Request (Start) message to 9

AGW2 and starts timer Tacct-aaa. 10

bb. Upon receipt of the AAA-Accounting-Request (Start) message, AGW2 creates a UDR for this AT 11


Upon receipt of the successful PMIP-Registration Reply message from AGW2, eBS2 sends an IPT-13

Notification message to each ANRI in the route set (and to the previous DAP if it is not in the route set) 14

and becomes the DAP for AGW2. The message contains the DAP record of AGW2. Steps ‘cc’, ‘ee and 15

‘gg’ may occur in parallel. If SRNC1 is not in the route set (refer to step ‘n’) then steps ‘cc’ and ‘dd’ are 16

omitted. 17

cc. eBS2 sends an IPT-Notification message to SRNC1 and starts timer Tnot-ipt. 18

dd. Upon receipt of the IPT-Notification message, SRNC1 responds with an IPT-Notification Ack 19

message. Upon receipt of the IPT-Notification Ack message, eBS2 stops timer Tnot-ipt. 20

ee. eBS2 sends an IPT-Notification message to SRNC2 and starts timer Tnot-ipt. 21

ff. Upon receipt of the IPT-Notification message, SRNC2 responds with an IPT-Notification Ack 22


gg. eBS2 sends an IPT-Notification message to eBS1 and starts timer Tnot-ipt. 24

hh. Upon receipt of the IPT-Notification message, eBS1 responds with an IPT-Notification Ack message. 25

eBS1 may remove its route with the AT and may terminate its PMIP tunnel with AGW1. Upon 26

receipt of the IPT-Notification Ack message, eBS2 stops timer Tnot-ipt. 27

ii. Upon presenting a new IP interface to the AT in step ‘u’, the AT can now request a new IP address 28

assignment and new Mobile IP registration. 29

jj. eBS2 is the DAP for the AT under AGW2. Data on both the forward-link and the reverse-link is 30

exchanged through eBS2 between AT and AGW2. 31

32

3.7 Session Reference Transfer 33

This section describes the call flows for UMB session reference transfer during idle mobility and active 34

service events. 35

3.7.1 Session Reference Transfer during Idle Mobility Events 36

This section describes the call flows for session reference transfer during idle mobility events. 37

3.7.1.1 AT Registers at eBS not Supported by Source SRNC - Session Anchor ANRI Moves to 38

Target SRNC 39

This scenario describes the call flow when the AT registers with an eBS that is not supported by the 40

current SRNC. Subsequently, the Session Anchor ANRI is moved to another SRNC. SRNC transfer under 41

3GPP2 A.S0020-0 v1.0

3-47

the same AGW does not require EAP procedures. This call flow assumes that the AT is idle before step 1

‘a’. 2

timeAT eBS1 AGW

Tuupd-ias

z

aa

IPT-Notification(eBS1 is FLSE)Tnot-ipt

eBS1 becomes DAP

RouteOpenRequest

eBS2(DAP)

SourceSRNC

TargetSRNC






RouteMap

IAS-UATI Update Ack

IAS-UATI Update

Tuupd-ias

IAS-UATI UpdateTuupd-ias

IAS-UATI Update

IAS-UATI Update Ack

IAS-UATI Update Ack

UATIComplete (new UATI)

RouteOpenAccept (new UATI)

IAS-SRNC Transfer Request

Tstr-ias

y

x

w

v

u

IAS-SRNC Transfer Response

RouteCreate(Target SRNC ANID)

RouteMap

RouteOpenAccept

IAS-Session Information Response

IAS-Session Information RequestTsir-ias

RouteOpenRequest(Registration failed)

Registration

Registration Response (Type = RouteOpen required)

a

b

c

d

e

f

g

h

i

j

k

l

n

m

o

p

q

r

s

t

3

Figure 3.7.1.1-1 AT Registers at eBS not Supported by Source SRNC - Session Moves to 4

Target SRNC 5

a. The AT registers with the source SRNC. The registration message is tunneled through eBS1. 6

b. The source SRNC determines that eBS1 should be served by another SRNC (e.g., because the source 7

SRNC does not have paging area database around eBS1) and responds to the AT with a Registration 8

Response message with the cause value of RouteOpen required. 9

c. Upon receipt of the Registration Response message with the cause value of RouteOpen required, the 10

AT sends a RouteOpenRequest to eBS1 with an indication that registration with the SRNC has failed. 11

3GPP2 A.S0020-0 v1.0

3-48

d. Upon receipt of the RouteOpenRequest message with a registration failed cause value, eBS1 sends an 1

IAS-Session Information Request to the source SRNC to retrieve session information of the AT and 2

starts timer Tsir-ias. 3

e. Upon receipt of the IAS-Session Information Request message, the source SRNC responds by 4

sending an IAS-Session Information Response message to eBS1. This message includes the session 5

information of the AT and the AGW address. Upon receipt of the IAS-Session Information Response 6


f. Upon receipt of the IAS-Session Information Response message, eBS1 sends a RouteOpenAccept 8

message to the AT. 9

g. The AT sends a RouteMap message to all ANRIs in the Route Set. 10

h. Upon receipt of the RouteOpenRequest message with the registration failed cause value, eBS1 also 11

sends a RouteCreate message with the target SRNC ANID to the AT. 12

i. Upon receipt of the RouteCreate message with the target SRNC ANID, the AT sends a 13

RouteOpenRequest message to the target SRNC through eBS1. The tunneling header of this message 14

contains both the SSID of the AT and the current UATI of the AT. 15

j. Upon receipt of the RouteOpenRequest message with UATI in the tunneling header, the target SRNC 16

sends an IAS-SRNC Transfer Request message to the source SRNC to request a session reference 17

transfer and starts timer Tstr-ias. 18

k. The source SRNC responds to the target SRNC with an IAS-SRNC Transfer Response message. 19

Once the source SRNC sends the IAS-SRNC Transfer Response message, it locks its session, i.e., it 20

rejects any further session modification but still accepts requests for a copy of the session and still 21

accepts requests to page the AT. Upon receipt of the IAS-SRNC Transfer Response message, the 22

target SRNC stops timer Tstr-ias. The target SRNC also locks its session. The source SRNC stores the 23

new UATI and new UATI_SeqNo received in the IAS-SRNC Transfer Request and the mapping 24

between the new UATI (assigned by the target SRNC) and the current (old) UATI, which is an index 25

to the current session information for the AT stored at the source SRNC. 26

l. Upon receipt of the IAS-SRNC Transfer Response message, the target SRNC sends a Route-27

OpenAccept message to the AT. The message contains the new UATI of the AT. 28

m. Upon receiving the new UATI, the AT sends a UATIComplete message to the target SRNC. The 29

target SRNC ANRI has become the Session Anchor ANRI for the AT. 30

Upon receipt of the UATIComplete message or signaling message addressed to the new UATI, the target 31

SRNC unlocks its session, i.e., it allows session configuration, becomes the SRNC for the AT, and sends 32

an IAS-UATI Update message to all ANRIs in the Route Set and the DAP of the AT. Steps ‘n’ ‘p’ and ‘r’ 33

may occur in parallel. 34

n. The target SRNC sends an IAS-UATI Update message with the new UATI and the new 35

UATI_SeqNo to the DAP and starts timer Tuupd-ias. 36

o. Upon receipt of the IAS-UATI Update message, the DAP sends an IAS-UATI Update Ack message 37

back to the target SRNC. Upon receipt of the IAS-UATI Update Ack message, the target SRNC stops 38

timer Tuupd-ias. 39

p. The target SRNC sends an IAS-UATI Update message with the new UATI and the new 40

UATI_SeqNo to the source SRNC and starts timer Tuupd-ias. 41

q. Upon receipt of the IAS-UATI Update message, the source SRNC releases the old UATI and sends 42

an IAS-UATI Update Ack message back to the target SRNC. The source SRNC may terminate its 43

route with the AT anytime after this step. Upon receipt of the IAS-UATI Update Ack message, the 44

target SRNC stops timer Tuupd-ias. 45

3GPP2 A.S0020-0 v1.0

3-49

r. The target SRNC sends an IAS-UATI Update message with the new UATI and the new 1

UATI_SeqNo to eBS1 and starts timer Tuupd-ias. 2

s. Upon receipt of the IAS-UATI Update message, eBS1 sends an IAS-UATI Update Ack message back 3

to the target SRNC. Upon receipt of the IAS-UATI Update Ack message, the target SRNC stops 4

timer Tuupd-ias. 5

t. The AT sends RouteMap message to all ANRIs in the Route Set, including the target SRNC. 6

After step ‘k’, eBS1 notifies all ANRIs in the route set and the DAP of the AT that it has become the 7

FLSE for the AT. Steps ‘u’ ‘w’ and ‘y’ may occur in parallel. 8

u. Based on the ANID of the DAP, eBS1 sends an IPT-Notification message to the DAP indicating that 9

eBS1 is the FLSE. eBS1 also starts timer Tnot-ipt. 10

v. Upon receipt of the IPT-Notification message, the DAP acknowledges with an IPT-Notification Ack 11


w. eBS1 sends an IPT-Notification message to the source SRNC indicating that eBS1 is the FLSE. eBS1 13

also starts timer Tnot-ipt. 14

x. Upon receipt of the IPT-Notification message, the source SRNC acknowledges with an IPT-15

Notification Ack message to eBS1. Upon receipt of the IPT-Notification Ack message, eBS1 stops 16

timer Tnot-ipt. 17

y. eBS1 sends an IPT-Notification message to the target SRNC indicating that eBS1 is the FLSE. eBS1 18


z. Upon receipt of the IPT-Notification message, the target SRNC acknowledges with an IPT-20


timer Tnot-ipt. 22

aa. DAP is moved to eBS1 which is the FLSE. Refer to section 3.6. 23

24

3.7.1.2 AT Registers at eBS not Supported by Source SRNC - Session Moves to Local eBS 25

This scenario describes the call flow when the AT registers with an eBS that is not supported by the 26

current SRNC. Subsequently, the Session Anchor ANRI is moved to local eBS. SRNC transfer under the 27

same AGW does not require EAP procedures. This call flow assumes that the AT is idle in the beginning. 28

This scenario depicts an implementation option, whereby an eBS and SRNC are co-located. 29

3GPP2 A.S0020-0 v1.0

3-50

1

Figure 3.7.1.2-1 AT Registers at eBS not Supported by Source SRNC - Session Moves to 2

Local eBS 3

a. The AT registers with the source SRNC. The registration message is tunneled through eBS1. 4

b. The source SRNC determines that eBS1 should be served by another SRNC (e.g., because the SRNC 5

does not have paging area database around eBS1) and responds to the AT with a Registration 6

Response message with the cause value of RouteOpen required. 7



d. eBS1 decides to host Session Anchor ANRI and sends an IAS-SRNC Transfer Request to the source 10

SRNC and starts timer Tstr-ias. 11

e. Upon receipt of the IAS-SRNC Transfer Request message with the SessionRequest flag, the source 12

SRNC responds by sending an IAS-SRNC Transfer Response message to eBS1. This message in-13

cludes the session information of the AT, and the AGW address. Upon receipt of the IAS-SRNC 14

Transfer Response message, eBS1 stops timer Tstr-ias. 15

f. Upon receipt of the IAS-SRNC Transfer Response message, eBS1 sends a RouteOpenAccept 16

message to the AT. This message includes the new UATI for the AT. 17

g. Upon assignment of the new UATI, the AT sends a UATIComplete message to eBS1. The target 18

SRNC ANRI has become the Session Anchor ANRI for the AT. 19

3GPP2 A.S0020-0 v1.0

3-51

Upon receipt of the UATIComplete message, eBS1 unlocks its session, i.e., it allows session configur-1

ation, becomes the SRNC for the AT and sends an IAS-UATI Update message to all ANRIs in the Route 2

Set. Steps ‘h’ and ‘j’ may occur in parallel. 3

h. eBS1 sends an IAS-UATI Update message with the new UATI and the new UATI_SeqNo to the 4

source SRNC and starts timer Tuupd-ias. 5

i. Upon receipt of the IAS-UATI Update message, the source SRNC releases the old UATI and sends 6

an IAS-UATI Update Ack message back to eBS1. The source SRNC may terminate its route with the 7

AT anytime after this step. Upon receipt of the IAS-UATI Update Ack message, the target SRNC 8

stops timer Tuupd-ias. 9

j. eBS1 sends an IAS-UATI Update message with the new UATI and the new UATI_SeqNo to the 10

DAP and starts timer Tuupd-ias. 11

k. Upon receipt of the IAS-UATI Update message, the DAP sends an IAS-UATI Update Ack message 12

back to eBS1. Upon receipt of the IAS-UATI Update Ack message, the target SRNC stops timer 13

Tuupd-ias. 14

l. The AT sends RouteMap message to all ANRIs in the Route Set, including the target SRNC. Note 15

that steps ‘g’ and ‘l’ may occur in parallel. 16

After step ‘e’, eBS1 notifies all ANRIs in the route set and the DAP of the AT that it has become the 17

FLSE for the AT. Steps ‘m’ and ‘o’ may occur in parallel. 18

m. Based on the ANID of the DAP received from the source SRNC, eBS1 sends an IPT-Notification 19

message to the DAP indicating that eBS1 is the FLSE. eBS1 also starts timer Tnot-ipt. 20

n. Upon receipt of the IPT-Notification message, the DAP acknowledges with an IPT-Notification Ack 21


o. eBS1 sends an IPT-Notification message to the source SRNC indicating that eBS1 is the FLSE. eBS1 23


p. Upon receipt of the IPT-Notification message, the source SRNC acknowledges with an IPT-25


timer Tnot-ipt. 27

q. DAP is moved to eBS1 which is the FLSE. Refer to section 3.6. 28

29

3.7.1.3 Session Reference Transfer during Idle Mobility Events with SRNC-PMIP Binding 30

Update 31

This section describes the call flows for session reference transfer during idle mobility events in the case 32

that the AGW buffers bearer data when the AT is idle and when the PMIP Signaling interface is 33

supported. In the call flow, the AT registers with an eBS that the current SRNC does not want to continue 34

to serve as SRNC, e.g., the SRNC does not have paging area information around the eBS. Subsequently, 35

the Session Anchor ANRI is moved to another SRNC. SRNC transfer under the same AGW does not 36

require EAP procedures. This call flow assumes that the AT is idle in the beginning. 37

3GPP2 A.S0020-0 v1.0

3-52

timeAT eBS1 AGW

SourceSRNC

TargetSRNC

a

d

e

f

g

h

Trrq-pmip

DAP is moved from eBS1 to SRNC

i

j

SRNC transfer

AT is in Idle State

ConnectionClose(Normal Close)

Tnot-ipt

IPT-Notification (Connection Close)


Tnot-iptIPT-Notification Ack

IPT-Notification

PMIP Registration Request (Signaling-Only)

PMIP Registration Reply

c

b

1

Figure 3.7.1.3-1 Intra-AGW Session Reference Transfer during Idle Mobility Events with 2

SRNC-PMIP Binding Update 3

a. The connection between the AT and the FLSE is closed. The AT, SRNC, and eBS1 are all in the idle 4

state. 5

b. The target SRNC triggers an SRNC transfer procedure. Refer to 3.7.1.1. The AT registers at eBS1, 6

which is not supported by the source SRNC. Therefore, the session moves to the target SRNC as 7

shown in 3.7.1.1. It is assumed that eBS1 is the DAP after the SRNC transfer and the AT is in 8

connected state. Note also that EAP is not required during the SRNC transfer since the IAS-SRNC 9

Transfer Response message contains UATI, SSID, PMN-AN-HA1 key, PMN-AN-HA1 Sequence 10

Number, PMN-AN-RK1, derived MSK, AAA-Session-ID, AGW IP Address, and GRE key. 11

c. After the SRNC Transfer procedure, this call flow assumes that the AT returns to idle state because it 12

does not have an active session. Therefore, the AT sends a ConnectionClose to eBS1. 13

d. eBS1 sends an IPT-Notification message to the target SRNC with an indication of connection close 14

and starts timer Tnot-ipt. eBS1 may release RF resources at this point. 15

e. Upon receipt of the IPT-Notification message with the connection close indication, the target SRNC 16

responds to eBS1 with an IPT-Notification Ack message. Upon receipt of the IPT-Notification Ack 17

message, eBS1 stops timer Tnot-ipt. 18

f. Upon entering idle mode, the target SRNC sends a PMIP Registration Request message with the 19

Signaling-Only Binding type to the AGW. The target SRNC starts timer Trrq-pmip. 20

g. Upon receipt of the PMIP-Registration Request message, the AGW sends a PMIP-Registration Reply 21

message to the target SRNC. If the AGW accepts the Signaling-Only binding type registration, it 22

removes any existing Signaling-Only or Primary binding. Any existing RL+Primary binding becomes 23

RL-Only binding. Upon receipt of the PMIP-Registration Reply message, the target SRNC stops 24

timer Trrq-pmip. 25

h. Upon receipt of the PMIP-Registration Reply message, the target SRNC sends an IPT-Notification 26

message to eBS1 indicating that the target SRNC has a PMIP binding with the AGW. This IPT-27

Notification message notifies eBS1 that it is no longer the DAP. The target SRNC starts timer Tnot-ipt. 28

i. Upon receipt of the IPT-Notification message with indication that it is no longer the DAP, eBS1 29

responds to the target SRNC with an IPT-Notification Ack message. eBS1 may release DAP 30

3GPP2 A.S0020-0 v1.0

3-53

resources at this point. Upon receipt of the IPT-Notification Ack message, the target SRNC stops 1

timer Tnot-ipt. 2

j. The target SRNC, AGW, and eBS1 are coordinated with respect to the DAP move. 3

4

3.7.1.4 Inter-AGW AT Idle Handoff 5

This scenario describes the call flow for the inter-AGW handoff when the AT is in idle state and the 6

Mobile IP protocol is used. This call flow assumes that initially the AT is registered in AGW1. Before AT 7

performs the handoff it is in idle state. The DAP resides in eBS1 and the Session Anchor is in SRNC1. 8

Later, when AT crosses the domain’s boundary, the Session Anchor is moved to SRNC2, AGW2 9

becomes a serving gateway for the AT and eBS2 becomes DAP for AGW2. SRNC1 and eBS1 reside in 10

the domain of AGW1, and SRNC2 and eBS2 reside in the domain of AGW2. 11

12

3GPP2 A.S0020-0 v1.0

3-54

timeAT eBS1 AGW2

Tuupd-ias

ff

gg

IPT-Notification-AckTnot-ipt

AGW1SRNC2eBS2

IPT-Notification

Tnot-ipt

IAS-UATI Update Ack

IAS-UATI Update

IAS-UATI Update AckTuupd-ias

IAS-UATI Update

DAPMoveRequest

RouteClose

IAS-SRNC Transfer Request

Tstr-ias

ee

dd

cc

bb

IAS-SRNC Transfer Response

RouteOpenAccept (new UATI)

Tsir-ias

RouteOpenRequest(Registration failed)

Registration Response (Type=RouteOpen required)

RouteCreate (SRNC2 ANID)

c

d

e

g

h

i

j

k

l

m

o

r

q

s

t

u

v

w

x*

SRNC1

IP address assignment and Mobile IP binding update

IPT-Notification


DAPAssignment aa**


PMIP-Registration Request (RL+Primary)Trrq-pmip

z

y

LinkID Assignment


EAP Access authentication EAP Access auth

IAS-UATI Update Ack

IAS-UATI UpdateTuupd-ias

p**

UATIComplete

RouteMap

n

RouteOpenRequest

RouteOpenAccept f

IAS-Session Info Request (UATI)

IAS-Session Info Response (Session,

DAP, AGW IP)

Registration a

b

AT goes to Idle State

1

Figure 3.7.1.4-1 Inter-AGW Handoff in Idle State 2

a. The AT in idle state crosses the domain boundary and registers with the source SRNC1, which has a 3

Session Anchor for the AT. The registration message is tunneled through eBS2. 4

b. The SRNC1 determines that eBS2 should be served by another SRNC2 (e.g., because the SRNC does 5

not have paging area database around eBS2) and responds to the AT with a Registration Response 6

message with the cause value of RouteOpen required. 7



3GPP2 A.S0020-0 v1.0

3-55

d. Upon receipt of the RouteOpenRequest message with a registration failed cause value, eBS2 sends an 1

IAS-Session Information Request to the SRNC1 to retrieve session information of the AT and starts 2

timer Tsir-ias. 3

e. Upon receipt of the IAS-Session Information Request message, the SRNC1 responds by sending an 4

IAS-Session Information Response message to eBS2. This message contains the information record 5

of the current AGW, i.e. AGW1. Upon receipt of the IAS-Session Information Response message, 6

eBS2 stops timer Tsir-ias. 7

f. Upon receipt of the IAS-Session Information Response message, eBS2 sends a RouteOpenAccept 8

message to the AT to complete Route Setup procedure. 9

After step ‘f’ the AT enters Connected State. 10

g. Upon receipt of the RouteOpenRequest message with the registration failed cause value, eBS2 also 11

sends a RouteCreate message with the SRNC2 ANID to the AT. 12

h. Upon receipt of the RouteCreate message with the SRNC2 ANID, the AT sends a RouteOpenRequest 13

message to the SRNC2 through eBS2. The tunneling header of this message contains both the SSID 14

of the AT and the current UATI of the AT. 15

i. Upon receipt of the RouteOpenRequest message with UATI in the tunneling header, the SRNC2 16

sends an IAS-SRNC Transfer Request message to SRNC1 to request a session reference transfer and 17

starts timer Tstr-ias. 18

j. The SRNC1 responds to SRNC2 with an IAS-SRNC Transfer Response message. Once SRNC1 19

sends the IAS-SRNC Transfer Response message, it locks its session, i.e., it rejects any further 20

session modification but still accepts requests for a copy of the session and still accepts requests to 21

page the AT. Upon receipt of the IAS-SRNC Transfer Response message, SRNC2 stops timer Tstr-ias. 22

SRNC2 also locks its session. The source SRNC stores the new UATI and new UATI_SeqNo 23

received in the IAS-SRNC Transfer Request and the mapping between the new UATI (assigned by 24

the target SRNC) and the current (old) UATI, which is an index to the current session information for 25

the AT stored at the source SRNC. This information is needed to process messages from the target 26

SRNC that contain new UATI as the AT identifier. 27

k. Upon receipt of the IAS-SRNC Transfer Response message, SRNC2 sends a RouteOpenAccept 28

message to the AT. The message contains the new UATI of the AT. 29

Steps ‘l’ and ‘m’-‘t’ can occur in parallel. 30

l. Upon establishing the new route, the AT sends a new RouteMap message to each ANRI in the route 31

set, i.e. eBS2, SRNC1 and SRNC2. 32

m. Upon receiving the new UATI, the AT sends a UATIComplete message to SRNC2. SRNC2 ANRI 33

has become the Session Anchor ANRI for the AT. 34

Upon receipt of the UATIComplete message or signaling message addressed to the new UATI, SRNC2 35

unlocks its session, i.e., it allows session configuration, becomes the SRNC for the AT, and sends an IAS-36

UATI Update message to all ANRIs in the Route Set and the DAP of the AT. 37

n. SRNC2 sends an IAS-UATI Update message with the new UATI and the new UATI_SeqNo to 38

SRNC1 and starts timer Tuupd-ias. 39

o. Upon receipt of the IAS-UATI Update message, SRNC1 releases the old UATI and sends an IAS-40

UATI Update Ack message back to SRNC2. SRNC1 may terminate its route with the AT anytime 41

after this step. Upon receipt of the IAS-UATI Update Ack message, SRNC2 stops timer Tuupd-ias. 42

p. If SRNC1 does not receive a RouteClose message from the AT before step ‘o’, SRNC1 sends a 43

RouteClose message to the AT anytime after step ‘o’. Note that in response to the RouteClose 44

message, the AT will subsequently send a new RouteMap message to each ANRI in the route set. 45

3GPP2 A.S0020-0 v1.0

3-56

q. SRNC2 sends an IAS-UATI Update message with the new UATI and the new UATI_SeqNo to eBS2 1

and starts timer Tuupd-ias. 2

r. Upon receipt of the IAS-UATI Update message, eBS2 sends an IAS-UATI Update Ack message back 3

to SRNC2. Upon receipt of the IAS-UATI Update Ack message, SRNC2 stops timer Tuupd-ias. 4

s. SRNC2 sends an IAS-UATI Update message with the new UATI and the new UATI_SeqNo to the 5

DAP (eBS1) and starts timer Tuupd-ias. 6

t. Upon receipt of the IAS-UATI Update message, eBS1 sends an IAS-UATI Update Ack message back 7

to SRNC2. Upon receipt of the IAS-UATI Update Ack message, SRNC2 stops timer Tuupd-ias. 8

u. SRNC2 triggers EAP Access Authentication with the AT. 9

v. SRNC2 performs session configuration with the AT. After session configuration is completed, the AT 10

sends a SessionUpdated message to all ANRIs in the route set. The ANRIs in the route set send an 11

IAS-Session Information Request message to SRNC2 to retrieve a copy of the session and also the 12

information record of the new AGW, i.e., AGW2. 13

w. Upon receiving new session information with the new AGW information records, eBS2 assigns the 14

LinkID to the AT. 15

x. In the AT-assisted DAP Handoff mode, the AT sends a DAPMoveRequest message to eBS2. This 16

step can be omitted in AN-initiated DAP Handoff mode. 17

y. eBS2 performs PMIP binding at AGW2 by sending a PMIP-Registration Request message to AGW2. 18

If support for multiple bindings is enabled then the RL+Primary extension is included in the PMIP-19

Registration Request message. eBS2 starts timer Trrq-pmip. 20

z. Upon receipt of the PMIP-Registration Request message, AGW2 accepts binding request from eBS2 21

by sending a PMIP-Registration Reply message to eBS2. eBS2 stops timer Trrq-pmip. 22

aa. The eBS2 sends a DAPAssignment message to the AT after receiving the PMIP-Registration Reply 23

message. 24

Upon receipt of the successful PMIP-Registration Reply message from AGW2, eBS2 sends an IPT-25

Notification message to each ANRI in the route set and the DAP (eBS1) to indicate that it has become the 26

FLSE and the DAP for AGW2. 27

bb. eBS2 sends an IPT-Notification message to SRNC2 and starts timer Tnot-ipt. 28

cc. Upon receipt of the IPT-Notification message, SRNC2 responds with an IPT-Notification Ack 29


dd. eBS2 sends an IPT-Notification message to the eBS1 and starts timer Tnot-ipt. 31

ee. Upon receipt of the IPT-Notification message, eBS1 responds with an IPT-Notification Ack message. 32

Upon receipt of the IPT-Notification Ack message, eBS2 stops timer Tnot-ipt. eBS1 may tear down 33

the PMIP tunnel with AGW1 anytime after this step. 34

ff. Upon presenting a new IP interface to the AT in step ‘w’, the AT can now request a new IP address 35

assignment and new Mobile IP registration. 36

gg. AT gracefully closes the route with SRNC1, if it is still in the route set, and the connection with eBS2 37

and enters the Idle State. 38

39

3.7.2 Session Reference Transfer during Active Service Events 40

This section describes the call flows for session reference transfer during active service events. 41

3GPP2 A.S0020-0 v1.0

3-57

3.7.2.1 Session Reference Transfer during Active Services 1

This scenario describes the call flow for a session reference transfer. This call flow assumes that eBS1 2

and the source SRNC are already in the Route Set. 3

timeAT

d

Tstr-ias

IAS-SRNC Transfer Request (new UATI, SessionSig)

c

e

SourceSRNC

b

IAS-SRNC Transfer Response (new UATI_SeqNo)

UATIAssignment

TargetSRNC

UATIComplete

IAS-UATI Update (new UATI_SeqNo, new UATI, SessionSig) f

IAS-UATI Update Ack gTuupd-ias

eBS1

a*

IAS-UATI Update (new UATI_SeqNo, new UATI, SessionSig)


i

* conditional

eBS1 triggers Route Creation between AT and target SRNC. All ANRIs in Route Set receive the updated RouteMap

RouteClose

j

h*

4

Figure 3.7.2.1-1 Session Reference Transfer during Active Services 5

a. eBS1 triggers route creation between the AT and the target SRNC. Note: this step is not necessary if 6

the target SRNC is already in the route set. 7

b. The target SRNC sends an IAS-SRNC Transfer Request message to the source SRNC to request a 8

session reference transfer and starts timer Tstr-ias. 9

c. The source SRNC responds to the target SRNC with an IAS-SRNC Transfer Response message. This 10

message includes the new UATI_SeqNo (for the new UATI). If the SessionSignature received from 11

the target SRNC in step ‘b’ does not match with the SessionSignature in the source SRNC, the source 12

SRNC also includes the latest SessionSignature and Session in this message. Once the source SRNC 13

sends the IAS-SRNC Transfer Response message, it locks its session, i.e., it rejects any further 14

session modification but still accepts request for a copy of the session and still accepts request to page 15

the AT. Upon receipt of the IAS-SRNC Transfer Response message, the target SRNC stops timer 16

Tstr-ias. The target SRNC also locks its session. 17

d. The target SRNC sends UATIAssignment message containing the new UATI to the AT. 18

e. Upon receipt of the UATIAssignment message, the AT sends UATIComplete messages to the target 19

SRNC. 20


SRNC unlocks its session, i.e., it allows session configuration, and sends an IAS-UATI Update message 22

to all ANRIs in the Route Set and the DAP, if the DAP is outside the route set. Steps ‘f’ and ‘i’ may occur 23

in parallel. 24

f. The target SRNC sends an IAS-UATI Update message containing the new UATI_SeqNo, and the 25

new UATI to the source SRNC and starts timer Tuupd-ias. 26

g. Upon receipt of the IAS-UATI Update message with a new UATI_SeqNo, the source SRNC releases 27

the old UATI and sends an IAS-UATI Update Ack message back to the target SRNC. Upon receipt of 28

the IAS-UATI Update Ack message, the target SRNC stops timer Tuupd-ias. 29

3GPP2 A.S0020-0 v1.0

3-58

h. If the source SRNC does not receive a RouteClose message from the AT before step ‘f’, the source 1

SRNC sends a RouteClose message to the AT any time after step ‘f’. This RouteClose message 2

removes the source SRNC route from the AT’s route set. Note that in response to the RouteClose 3


i. The target SRNC sends an IAS-UATI Update message containing the new UATI_SeqNo, and the 5

new UATI to eBS1 and starts timer Tuupd-ias. 6

j. Upon receipt of the IAS-UATI Update message with a new UATI_SeqNo, eBS1 sends an IAS-UATI 7

Update Ack message back to the target SRNC. Upon receipt of the IAS-UATI Update Ack message, 8

the target SRNC stops timer Tuupd-ias. 9

10

3.7.2.2 Session Reference Transfer - Route Set Add during SRNC Transfer 11

This scenario describes the call flow when Route Set Add occurs during a session reference transfer. This 12

call flow assumes that the source SRNC and the target SRNC are already in the Route Set while eBS1 is 13

not yet in the Route Set. 14

tim eA T

c

T str-ias

IA S -S R N C T ransfer R equest (new U A TI, S essionS ig )

b

d

S ourceS R N C

a

IA S -S R N C T ransfer R esponse(new U A TI_S eqN o)

U A TIA ssignm ent

TargetS R N C

e

eB S 1

R outeO penR equest(o ld U A TI, S essionS ig ) IA S -S ession

In form ationR equest (o ld U A TI, Tunne led )

IA S -S ession In form ationR esponse (session )

R outeO penA ccept

f

g

h

i

* cond itiona l

IA S -U A TI U pdate A ck

T uupd -ias

T sir-ias

U A TIC om plete

k

R outeM ap l

mT uupd -ias

IA S -U A TI U pdate (new U A TI_S eqN o, new U A TI, S essionS ig )

IA S -U A TI U pdate A ck

IA S -U A TI U pdate (new U A TI_S eqN o, new U A TI, S essionS ig )

R outeC lose

n

j*

15 16

Figure 3.7.2.2-1 Session Reference Transfer - Route Set Add during SRNC Transfer 17

a. The target SRNC sends an IAS-SRNC Transfer Request message to the source SRNC to request a 18


b. The source SRNC locks its session and responds to the target SRNC with an IAS-SRNC Transfer 20

Response message. This message includes the new UATI_SeqNo (for the new UATI). Upon receipt 21

of the IAS-SRNC Transfer Response message, the target SRNC stops timer Tstr-ias. 22

3GPP2 A.S0020-0 v1.0

3-59

c. The target SRNC sends UATIAssignment message containing the new UATI to the AT. However, 1

before the message is received at the AT, the AT sends RouteOpenRequest message to eBS1 to add 2

eBS1 into the Route Set. 3

d. eBS1 sends an IAS-Session Information Request message containing the old UATI to the source 4

SRNC with a Tunneled flag and starts timer Tsir-ias. 5

e. The source SRNC accepts the request for session by sending IAS-Session Information Response with 6

the session information. Upon receipt of the IAS-Session Information Response message, eBS1 stops 7

timer Tsir-ias. 8

f. The AT receives UATIAssignment message from the target SRNC. 9

g. Upon receipt of the UATIAssignment message, the AT sends UATIComplete message to the target 10

SRNC. 11



to all ANRIs in the Route Set and the DAP, if the DAP is outside the route set. 14

h. The target SRNC sends an IAS-UATI Update message with the new UATI and the new 15

UATI_SeqNo to the source SRNC and starts timer Tuupd-ias. 16


an IAS-UATI Update Ack message back to the target SRNC. Upon receipt of the IAS-UATI Update 18

Ack message, the target SRNC stops timer Tuupd-ias. 19

j. If the source SRNC does not receive a RouteClose message from the AT before step ‘h’, the source 20

SRNC sends a RouteClose message to the AT any time after step ‘h’. This RouteClose message 21



k. The AT receives RouteOpenAccept from eBS1 in response to the RouteOpenRequest message in step 24

‘c’. This step may occur anytime after step ‘e’. 25

l. The AT sends RouteMap message to all ANRIs in the Route Set, including the target SRNC. 26

m. Upon receipt of the RouteMap message which contains the new ANRI in the Route Set, the target 27

SRNC sends an IAS-UATI Update message containing the new UATI and the new UATI_SeqNo to 28

eBS1 and starts timer Tuupd-ias. 29

n. Upon receipt of the IAS-UATI Update message, eBS1 sends an IAS-UATI Update Ack message to 30

the target SRNC. Upon receipt of the IAS-UATI Update Ack message, the target SRNC stops timer 31

Tuupd-ias. 32

33

3.7.2.3 Session Reference Transfer - Session Negotiation during SRNC Transfer 34

This scenario describes the call flow when session negotiation is attempted during a session reference 35

transfer. This call flow assumes that eBS1, the source SRNC and the target SRNC are already in the 36

Route Set. 37

3GPP2 A.S0020-0 v1.0

3-60

timeAT

c

Tstr-ias


b

d

SourceSRNC

a

IAS-SRNC Transfer Response(new UATI_SeqNo)

UATIAssignment

TargetSRNC

IAS-UATI Update (new UATI, new UATI_SeqNo, SessionSig)

e

eBS1

IAS-Session Information Update Response (new SessionSig)

f

g

h

i

* conditional


Tsur-ias

UATIComplete

k

IAS-UATI Update Ack (new UATI) lTuupd-ias

IAS-Session Information Update Request (new UATI, updated session)

n

m

IAS-Session Information Update Response (failed – Session Locked)

Session NegotiationInitiated


IAS-Session InformationUpdate Request (old UATI,updated session)

Tsur-ias

RouteClose

o

j*

ConfigComplete

SessionUpdated p

qSessionUpdated

1

Figure 3.7.2.3-1 Session Reference Transfer - Session Negotiation during SRNC Transfer 2





of the IAS-Session Information Request message, the target SRNC stops timer Tstr-ias. 7


before the message is received at the AT, the AT and eBS1 initiate session negotiation. 9

d. To complete session negotiation, eBS1 sends an IAS-Session Information Update Request message 10

with the old UATI to the source SRNC and starts timer Tsur-ias. 11

e. The source SRNC rejects the request by sending an IAS-Session Information Update Response 12

message to eBS1 with the error cause value indicating that the session is locked. Upon receipt of the 13

IAS-Session Information Update Response message, eBS1 stops timer Tsir-ias. eBS1 may retry updat-14

ing the session at the SRNC after it receives an IAS-UATI Update message or may terminate session 15

negotiation with the AT. 16

f. The AT receives UATIAssignment message from the target SRNC. 17

g. Upon receipt of the UATIAssignment message, the AT sends UATIComplete message to the target 18

SRNC. 19



to all ANRIs in the Route Set, including the source SRNC and eBS1 and the DAP, if the DAP is outside 22

the route set. Steps ‘h’ and ‘k’ may occur in parallel. 23

3GPP2 A.S0020-0 v1.0

3-61

h. The target SRNC sends an IAS-UATI Update message with the new UATI to the source SRNC and 1

starts timer Tuupd-ias. 2


an IAS-UATI Update Ack message back to the target SRNC. Upon receipt of the IAS-UATI Update 4

Ack message, the target SRNC stops timer Tuupd-ias. 5

j. If the source SRNC does not receive a RouteClose message from the AT before step ‘h’, the source 6

SRNC sends a RouteClose message to the AT any time after step ‘h’. This RouteClose message 7



k. The target SRNC sends an IAS-UATI Update message with the new UATI to eBS1 and starts timer 10

Tuupd-ias. 11

l. Upon receipt of the IAS-UATI Update message, eBS1 uses the new UATI and sends an IAS-UATI 12

Update Ack message back to the target SRNC. Upon receipt of the IAS-UATI Update Ack message, 13

the target SRNC stops timer Tuupd-ias. 14

m. Upon receipt of the IAS-UATI Update message, eBS1 sends an IAS-Session Information Update 15

Request message with the new UATI to the target SRNC and starts timer Tsur-ias. 16

n. The target SRNC accepts the request by sending an IAS-Session Information Update Response 17

message to eBS1 with the new session signature. Upon receipt of the IAS-Session Update Response 18

message, eBS1 stops timer Tsur-ias. 19

o. eBS1 sends a ConfigurationComplete message to AT. 20

p. The AT sends a SessionUpdated message to eBS1. 21

q. The AT sends a SessionUpdated message to the target SRNC. 22

23

3.7.2.4 Session Reference Transfer - Connection Lost before UATIAssignment is Received 24

This scenario describes an example scenario for a session reference transfer where the AT does not 25

receive the UATIAssignment message. This call flow assumes that the source SRNC and the target 26

SRNC are already in the Route Set while eBS1 is not yet in the Route Set. This scenario also illustrates 27

what happens if the AT accesses the system after the UATIAssignment was lost. For more information on 28

AT access, refer to section 3.1.3. 29

3GPP2 A.S0020-0 v1.0

3-62

timeAT

c

Tstr-ias


b

SourceSRNC

a

IAS-SRNC Transfer Response(new UATI_SeqNo)

UATIAssignment (new UATI)

TargetSRNC

RouteOpenRequest(old UATI)

IAS-Session InformationRequest (old UATI, Access)

eBS1

IAS-Session InformationResponse (session)

IAS-UATI Update (old UATI, old UATI_SeqNo, SessionSig)

RouteOpenAccept

d

e

f

g

i

jIAS-UATI Update Ack

Tsir-ias

Tuupd-ias

hRouteMap

AT is idle

1

Figure 3.7.2.4-1 Session Reference Transfer - UATIAssignment Lost 2



b. The source SRNC responds to the target SRNC with an IAS-SRNC Transfer Response message. This 5

message includes the new UATI_SeqNo (for the new UATI). Upon receipt of the IAS-SRNC 6

Transfer Response message, the target SRNC stops timer Tstr-ias. 7


the AT does not receive the message and has lost its connection. 9

While the AT is idle, if the source SRNC receives an IAS-Paging Request message, then the source 10

SRNC shall initiate paging procedure for the AT using the old PageID. Refer to section 3.8.7 and 11

3.8.9 for the paging procedure. 12

If the UATIComplete message is not received, then the source SRNC and the target SRNC can 13

release the new UATI once its session KeepAlive timer expires. 14

d. The AT accesses eBS1 by sending RouteOpenRequest with the old UATI to eBS1. 15

e. eBS1 sends an IAS-Session Information Request message to the source SRNC with a flag indicating 16

this is an access and starts timer Tsir-ias. 17

f. Upon receipt of the IAS-Session Information Request message with the old UATI and access flag, the 18

source SRNC unlocks the session and responds to eBS1 with an IAS-Session Information Response 19

message. This message contains the current session, the current DAP, and the current session 20

signature. Upon receipt of the IAS-Session Information Response message, eBS1 stops timer Tsir-ias. 21

g. eBS1 sends RouteOpenAccept message to the AT to complete route setup procedure with the AT. 22

h. The AT sends RouteMap to all ANRIs in the Route Set. 23

The following steps may occur any time after step ‘e’. 24

3GPP2 A.S0020-0 v1.0

3-63

i. Upon receipt of the IAS-Session Information Request with the old UATI and access flag, the source 1

SRNC also sends an IAS-UATI Update message to the target SRNC of the previous incomplete 2

session reference transfer to inform the target SRNC that it may release the new UATI. The AT 3

identity contains the UATI of the target SRNC and the SRNC Record is the SRNC Record of the 4

source SRNC. The source SRNC starts timer Tuupd-ias. 5

j. Upon receipt of the IAS-UATI Update message, the target SRNC releases the new UATI and sends 6

an IAS-UATI Update Ack message back to the source SRNC. Upon receipt of the IAS-UATI Update 7

Ack message, the source SRNC stops timer Tuupd-ias. 8

9

3.7.2.5 Session Reference Transfer - Connection Lost before UATIComplete is Received 10

This scenario describes a failure scenario for a session reference transfer where the UATIComplete 11

message is lost. This call flow assumes that the source SRNC and the target SRNC are already in the 12

Route Set while eBS1 is not yet in the Route Set. This scenario also illustrates what happens if the AT 13

accesses the system after the UATIComplete was lost. For more information on AT access, refer to 14

section 3.1.3. 15

timeAT

c

Tstr-ias


b

d

SourceSRNC

a

IAS-SRNC Transfer Response(current DAP, new UATI_SeqNo)

UATIAssignment (new UATI)

TargetSRNC

UATIComplete (new UATI)

eBS1

RouteOpenRequest(new UATI)

IAS-Session Information Request (new UATI, SessionSig, Access)

IAS-Session Information Response (session)

RouteOpenAccept


e

f

g

h

i

IAS-UATI Update Ack

Tsir-ias

Tuupd-ias

j

RouteMap

k

AT is idle

RouteClose

* conditional

l*

16

Figure 3.7.2.5-1 Session Reference Transfer - UATIComplete Lost 17



b. The source SRNC responds to the target SRNC with an IAS-SRNC Transfer Response message. This 20

message contains the new UATI_SeqNo (for the new UATI). Upon receipt of the IAS-SRNC 21

Transfer Response message, the target SRNC stops timer Tstr-ias. 22

c. The target SRNC sends UATIAssignment message containing the new UATI to the AT. 23

d. The AT sends UATIComplete message to the target SRNC. However, the AT loses its connection 24

before the message is delivered. 25

3GPP2 A.S0020-0 v1.0

3-64

While the AT is idle, if the source SRNC receives Paging Request message, then the source SRNC 1

shall initiate paging procedure for the AT using the old PageID. Refer to section 3.8.7 and 3.8.9 for 2

the paging procedure. 3

Note that the AT will monitor both the old PageID and the new PageID if the UATIComplete 4

message has not been sent successfully. 5

If the UATIComplete message is not received, then the source SRNC and the target SRNC may 6

release the new UATI once its session KeepAlive timer expires. 7

e. The AT accesses eBS1 by sending RouteOpenRequest message with the new UATI. 8

f. eBS1 sends an IAS-Session Information Request message with a flag indicating this is an access to 9

the target SRNC and starts timer Tsir-ias. 10

g. Upon receipt of the IAS-Session Information Request message with the new UATI, the target SRNC 11

unlocks the session and sends an IAS-Session Information Response message to eBS1. The message 12

contains the session of the AT. Upon receipt of the IAS-Session Information Response message, 13

eBS1 stops timer Tsir-ias. 14

h. eBS1 sends RouteOpenAccept message to the AT to complete route setup procedure. 15

i. The AT sends RouteMap message to all ANRIs in the Route Set, including eBS1 and the target 16

SRNC. 17

The following steps may happen any time after step ‘f’. 18

j. Upon receipt of the IAS-Session Information Request message with the new UATI, the target SRNC 19

sends an IAS-UATI Update message to the source SRNC and starts timer Tuupd-ias. 20

k. Upon receipt of the IAS-UATI Update message, the source SRNC sends an IAS-UATI Update Ack 21

message to the target SRNC and may release the old UATI. Upon receipt of the UATI Update Ack 22

message, the target SRNC stops timer Tuupd-ias. 23

l. If the source SRNC does not receive a RouteClose message from the AT before step ‘j’, the source 24

SRNC sends a RouteClose message to the AT any time after step ‘j’. This RouteClose message 25



3GPP2 A.S0020-0 v1.0

3-65

3.7.2.6 Session Reference Transfer - Route Add after UATI Assignment during SRNC Transfer 1

This scenario describes the call flow when Route Set Add occurs after UATI assignment during a session 2

reference transfer. This call flow assumes that the source SRNC and the target SRNC are already in the 3

Route Set while eBS2 is not yet in the Route Set. 4

5

Tsr-ias

time

c

Tstr-ias

b

d

a

e

f

g

h

i

j

Tuupd-ias

k

l

m

Tuupd-ias

Tuupd-ias

n

o

p

q

r

Tsr-ias

6

Figure 3.7.2.6-1 Session Reference Transfer - Route Set Add after UATI Assignment during 7

SRNC Transfer 8





of the IAS-SRNC Transfer Response message, the target SRNC stops timer Tstr-ias. 13

c. The target SRNC sends a UATIAssignment message containing the new UATI and new Session 14

Anchor Route ID to the AT. 15

3GPP2 A.S0020-0 v1.0

3-66

d. The AT sends a UATIComplete message to the target SRNC. 1

Before step ‘m’ happens, the AT opens route with eBS2. 2

e. The AT sends a RouteOpenRequest message including new Session Anchor Route ID towards eBS2 3

to open a route at eBS2. This message is first sent to eBS1 (RLSE). 4

f. eBS1 transfer the RouteOpenRequest message to eBS2 via LLT interface. The LLT header of the 5

RouteOpenRequest message includes old UATI because UATI stored in eBS1 is not updated. 6

g. eBS2 sends an IAS-Session Information Request message containing old UATI and new Session 7

Anchor Route ID to the source SRNC to request the session information for the AT, and starts timer 8

Tsir-ias. 9

h. The source SRNC sends an IAS-Session Information Response message indicating Session Anchor 10

Route ID mismatch which contains new UATI to the eBS1 because the received Session Anchor 11

Route ID is not for the source SRNC. eBS2 stops timer Tsir-ias. 12

i. eBS2 sends an IAS-Session Information Request message containing new UATI and new Session 13

Anchor Route ID to the target SRNC to request the session information for the AT, and starts timer 14

Tsir-ias. 15

j. The target SRNC sends an IAS-Session Information Response message including the session 16

information. eBS2 stops timer Tsir-ias. 17

k. eBS2 sends a RouteOpenAccept message to the AT. 18

l. The AT sends RouteMap messages to all ANRIs. 19

Step ‘m’, ‘o’ and ‘q’ can occur in parallel and those steps can occur anytime after step ‘d’. 20

m. The target SRNC sends an IAS-UATI Update message including new UATI to the source SRNC and 21

starts timer Tuupd-ias. 22

n. The source SRNC responds with an IAS-UATI Update Ack message to the target SRNC. The target 23

SRNC stops timer Tuupd-ias. 24

o. The target SRNC sends an IAS-UATI Update message including new UATI to eBS2 and starts timer 25

Tuupd-ias. 26

p. eBS2 responds with an IAS-UATI Update Ack message to eBS2. The target SRNC stops timer Tuupd-27

ias. 28

q. The target SRNC sends an IAS-UATI Update message including new UATI to eBS1 and starts timer 29

Tuupd-ias. 30

r. eBS1 responds with an IAS-UATI Update Ack message to the target SRNC. The target SRNC stops 31

timer Tuupd-ias. 32

33

3GPP2 A.S0020-0 v1.0

3-67

3.8 Idle State Mobility and Paging 1

2

3.8.1 AT Initiated Graceful Connection Close 3

This call flow describes the scenario when the AT sends a ConnectionClose message, with CloseReason 4

set to NormalClose, to the FLSE to notify it that the AT has gracefully closed the UMB connection. This 5

call flow assumes that eBS1 is the FLSE when the AT closes the connection and eBS1 (FLSE), eBS2, 6

SRNC and eBS3 (DAP) are all in the Route Set at the beginning of the call flow. The PMIP binding to the 7

DAP remains, and either the DAP or the AGW buffers data for Idle AT. 8

timeAT

eBS1(FLSE)

ConnectionClose(Normal Close, RouteCounter)

eBS2 SRNCeBS3(DAP)

b

d*

c

e**

Tnot-ipt


h

i

IPT-Notification (AT Iniated connectionclose, AccessCounter)

Tnot-ipt

IPT-Notification (AT Initiatedconnection close, AccessCounter)


Tnot-iptIPT-Notification Ack

IPT-Notification (AT Initiated connection close, AccessCounter)

a

AGW

l**

m**

Trrq-pmip

* = optional** = condtional

PMIP-RegistrationReply

PMIP-RegistrationRequest (Signaling Only)

AAA-Accounting-Request [Stop]


f**

g**

AAA-Accounting-Request[Stop, RouteDrop]


j

k



n

o

Tacct-aaa

Tacct-aaa

Tacct-aaa

9

Figure 3.8.1-1 AT Initiated Graceful Connection Close 10

a. The AT sends a ConnectionClose message to the eBS1 which is the FLSE with CloseReason set to 11

Normal Close. eBS1 can release any RF resources allocated to the AT upon receipt of the message. 12

Upon receipt of the ConnectionClose message from the AT, eBS1 sends an IPT-Notification message 13

with an AT Initiated connection close indication to all ANRIs in the Route Set and the DAP, if not in the 14

Route Set. Note: Steps ‘b’ through ‘k’ may occur in parallel. 15

b. eBS1 sends an IPT-Notification message to the eBS3 DAP with an AT Initiated connection close 16

indication and starts timer Tnot-ipt. 17

c. Upon receipt of the IPT-Notification message with an AT Initiated connection close indication, the 18

eBS3 DAP enters paging mode, i.e., it sends an IAS-Paging Request message to the SRNC whenever 19

it receives IP packets for the AT. Also, the eBS3 DAP responds to the FLSE with an IPT-Notification 20

Ack message to eBS1. eBS3 can then immediately release any RF resources allocated for the AT but 21

maintains information necessary to support PMIP binding and paging. Upon receipt of the IPT-22


3GPP2 A.S0020-0 v1.0

3-68

d. If the DAP cannot buffer data for idle AT’s, then the eBS3 DAP sends a PMIP-Registration Request 1

message with a Signaling-Only Binding type extension to the AGW. Upon sending the PMIP-2

Registration Request message, eBS3 starts timer Trrq-pmip. Note that the SRNC may decide to move 3

the PMIP signaling binding from the DAP to the SRNC any time after this step. Refer to section 3.8.5. 4

e. Upon receipt of the PMIP-Registration Request message, the AGW sends a PMIP-Registration Reply 5

message to eBS3. If the AGW accepts the Signaling-Only binding type registration, it removes any 6

existing Signaling-Only or Primary binding. Any existing RL+Primary binding becomes RL-Only 7

binding. At this point, if the AGW receives IP packets for the AT, it will buffer the packets and will 8

initiate paging of the AT. Upon receipt of the PMIP-Registration Reply message, eBS3 stops timer 9

Trrq-pmip. 10

f. If there is any Airlink Record created for the AT in eBS3, eBS3 sends an AAA-Accounting-Request 11


eBS3. 13

g. Upon receipt of the AAA-Accounting-Request (Stop)message from eBS3, the AGW sends an AAA-14


h. eBS1 sends an IPT-Notification message to the SRNC with an AT Initiated connection close 16

indication and starts timer Tnot-ipt. 17

i. Upon receipt of the IPT-Notification message with an AT Initiated connection close indication, the 18

SRNC enters idle mode. The SRNC also responds to eBS1 with an IPT-Notification Ack message. 19

Upon receipt of the IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 20

j. eBS1 sends an IPT-Notification message to eBS2 with an AT Initiated connection close indication 21

and starts timer Tnot-ipt. Note that step ‘b’ ,step ‘h’ and step ‘j’ may occur in parallel. 22

k. Upon receipt of the IPT-Notification message with an AT Initiated connection close indication, eBS2 23

responds with an IPT-Notification Ack message. It then can immediately release any RF resources 24

allocated for the AT. Upon receipt of the IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 25

l. If there is any Airlink Record created for the AT in eBS2, eBS2 sends an AAA-Accounting-Request 26


eBS2. 28

m. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS2, the AGW sends an AAA-29


n. The FLSE sends an AAA-Accounting-Request (Stop) message to the AGW including the Airlink 31

Record with the Connection Close indicator and starts timer Tacct-aaa. 32

o. Upon receipt of the AAA-Accounting-Request (Stop) message, the AGW sends an AAA-Accounting-33

Response message to the FLSE. The FLSE stops timer Tacct-aaa. 34

35

3.8.2 AN Initiated Graceful Connection Close - PMIP Signaling-Only Binding to SRNC 36

This call flow describes the Connection Close scenario when the PMIP Signaling-Only binding is 37

immediately established to the SRNC, instead of to the DAP. This call flow also describes the scenario of 38

AN initiated Connection Close. This call flow assumes that eBS1 is the FLSE when the AT closes the 39

connection and eBS1 (FLSE), eBS2, SRNC and eBS3 (DAP) are all in the Route Set at the beginning of 40

the call flow. 41

3GPP2 A.S0020-0 v1.0

3-69

1

Figure 3.8.2-1 AN Initiated Graceful Connection Close - PMIP Signaling-Only Binding to SRNC 2

a. The AN initiates the closing of the connection by sending a ConnectionClose message from eBS1 3

which is the FLSE to the AT, with a Close Reason of Normal Close. 4

b. Upon receipt of the ConnectionClose message from the AN, the AT sends a ConnectionClose 5

message to eBS1 which is the FLSE with a Close Reason of Close Reply. The message also includes 6

the last RouteCounter that the AT has assigned to a route. eBS1 can release any RF resources 7

allocated to the AT. 8

Upon receipt of the ConnectionClose message from the AT, eBS1 sends an IPT-Notification message 9

with the Notification Record IE indicating AN Initiated connection close to all ANRIs in the Route Set. 10

Note: Steps ‘c’ through ‘n’ may occur in parallel. 11

c. eBS1 sends an IPT-Notification message to the SRNC with the Notification Record IE indicating AN 12

Initiated connection close and starts timer Tnot-ipt. 13

d. Upon receipt of the IPT-Notification message with the AN Initiated connection close indication, the 14

SRNC determines that it will setup a PMIP Signaling-Only binding with the AGW, so that it can 15

3GPP2 A.S0020-0 v1.0

3-70

initiate paging procedures when the AGW notifies it that there is data for the AT. Also, the SRNC 1

responds to the FLSE with an IPT-Notification Ack message to eBS1. Upon receipt of the IPT-2


e. The SRNC sends a PMIP-Registration Request message with a Signaling-Only Binding type 4

extension to the AGW, informing the AGW to send a PMIP-Data Notification message to the SRNC 5

if the AGW receives data for the idle AT. When the SRNC receives a PMIP-Data Notification 6

message from the AGW, it will initiate paging of the AT by sending an IAS-Paging Request message 7

to each eBS in the paging area of the AT. Upon sending the PMIP-Registration Request message, 8

SRNC starts timer Trrq-pmip. 9

f. Upon receipt of the PMIP-Registration Request message, the AGW sends a PMIP-Registration Reply 10

message to SRNC. If the AGW accepts the Signaling-Only binding type registration, it removes any 11


binding. Upon receipt of the PMIP-Registration Reply message, the SRNC stops timer Trrq-pmip. 13

g. Upon receipt of the PMIP-Registration Reply message, the SRNC sends an IPT-Notification message 14

to the previous DAP of the AT, i.e., eBS3 in this call flow, to allow eBS3 to release resources 15

associated with its PMIP binding to the AGW. The SRNC starts timer Tnot-ipt. 16

h. Upon receipt of the IPT-Notification message, eBS3 responds with an IPT-Notification Ack message. 17

Upon receipt of the IPT-Notification Ack message, the SRNC stops timer Tnot-ipt. 18

i. eBS1 sends an IPT-Notification message to eBS3 with the Notification Record IE indicating AN 19

Initiated connection close and starts timer Tnot-ipt. 20

j. Upon receipt of the IPT-Notification message with the AN Initiated connection close indication, 21

eBS3 responds with an IPT-Notification Ack message. It then can immediately release any RF 22

resources allocated for the AT. Upon receipt of the IPT-Notification Ack message, eBS1 stops timer 23

Tnot-ipt. 24

k. If there is any Airlink Record created for the AT in eBS3, eBS3 sends an AAA-Accounting-Request 25


eBS3. 27

l. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS3, the AGW sends an AAA-28


m. eBS1 sends an IPT-Notification message to eBS2 with the Notification Record IE indicating AN 30

Initiated connection close and starts timer Tnot-ipt. Note that step ‘c’, step ‘i’ and step ‘m’ may occur 31

in parallel. 32

n. Upon receipt of the IPT-Notification message with the AN Initiated connection close indication, 33

eBS2 responds with an IPT-Notification Ack message. It then can immediately release any RF 34

resources allocated for the AT. Upon receipt of the IPT-Notification Ack message, eBS1 stops timer 35

Tnot-ipt. 36

o. If there is any Airlink Record created for the AT in eBS2, eBS2 sends an AAA-Accounting-Request 37


eBS2. 39

p. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS2, the AGW sends an AAA-40


q. The FLSE sends an AAA-Accounting-Request (Stop) message to the AGW and starts timer Tacct-aaa. 42

The message includes the Airlink Record with the Connection Close indicator. 43

r. Upon receipt of the AAA-Accounting-Request (Stop) message, the AGW sends an AAA-Accounting-44


3GPP2 A.S0020-0 v1.0

3-71

1

3.8.3 Non-Graceful Connection Close 2

This call flow describes the scenario when the AT lost connection with the FLSE, the PMIP binding to 3

the DAP remains, and either the DAP or the AGW buffers data for the idle AT. 4

timeAT

eBS1(FLSE)

eBS2 SRNCeBS3(DAP)

b

d*

c

e**

Tnot-ipt


i

IPT-Notification (Connection Lost, Access Counter)

IPT-Notification (Connection Lost, Access Counter)

a

AGW

Tnot-ipt

Tnot-ipt

h

Trrq-pmip

* = optional** = condtional

k

j

AT fails the supervision timer

with the FLSE



IPT-Notification (ConnectionLost, Access Counter)

PMIP-Registration Request (Signaling Only)




f**

g**

AAA-Accounting-Request (Stop)


l**AAA-Accounting-Request [Stop, RouteDrop]

AAA-Accounting-Response m**

n

o

Tacct-aaa

Tacct-aaa

Tacct-aaa

5

Figure 3.8.3-1 Non-Graceful Connection Close 6

a. The AT has failed the air-link supervision timer at eBS1 which is the FLSE. eBS1 also has not 7

received an IPT-Notification message with an indication that another eBS is now the FLSE. eBS1 8

starts an internal timer to release all resources it has allocated for the AT. 9

Upon detecting that the AT has failed the supervision timer, eBS1 sends an IPT-Notification message 10

with Connection Lost indication to all ANRIs in the Route Set and the DAP. Note: Steps ‘b’ through ‘h’ 11

and ‘j’ may occur in parallel. 12

b. eBS1 sends an IPT-Notification message to the eBS3 DAP with an indication of Connection Lost and 13


c. Upon receipt of the IPT-Notification message with the Connection Lost indication, the eBS3 DAP 15

enters paging mode, i.e., it sends an IAS-Paging Request message to the SRNC whenever it receives 16

IP packets for the AT. Also, the eBS3 DAP also responds to eBS1 with an IPT-Notification Ack 17

message. The eBS3 DAP releases any over-the-air resources it has provided to the AT. Upon receipt 18

of the IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 19

d. If the DAP cannot buffer data for idle AT’s, then the eBS3 DAP sends a PMIP-Registration Request 20

message with a Signaling-Only Binding type extension to the AGW. Upon sending the PMIP-21

Registration Request message, eBS3 starts timer Trrq-pmip. 22

3GPP2 A.S0020-0 v1.0

3-72

e. Upon receipt of the PMIP-Registration Request message, the AGW sends a PMIP-Registration Reply 1



binding. Upon receipt of the PMIP-Registration Reply message, eBS3 stops timer Trrq-pmip. 4

f. If there is any Airlink Record created for the AT in eBS3, eBS3 sends an AAA-Accounting-Request 5


eBS3. 7

g. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS3, the AGW sends an AAA-8



h. eBS1 sends an IPT-Notification message to the SRNC with an indication of Connection Lost and 11


i. Upon receipt of the IPT-Notification message with the Connection Lost indication, the SRNC enters 13

idle mode and uses the eBS1 identity and the current time to determine the paging behavior. The 14

SRNC also responds to eBS1 with an IPT-Notification Ack message. Upon receipt of the IPT-15


j. eBS1 sends an IPT-Notification message to eBS2 with an indication of Connection Lost and starts 17

timer Tnot-ipt. 18

k. Upon receipt of the IPT-Notification message with the Connection Lost indication, eBS2 responds 19

with an IPT-Notification Ack message. It also releases any resources allocated for the AT. Upon 20

receipt of the IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 21

l. If there is any Airlink Record created for the AT in eBS2, eBS2 sends an AAA-Accounting-Request 22


eBS2. 24

m. Upon receipt of the AAA-Accounting-Request (Stop) message from eBS2, the AGW sends an AAA-25



n. The FLSE sends an AAA-Accounting-Request (Stop) message to the AGW including the Airlink 28

Record with the Connection Close indicator. and starts timer Tacct-aaa. 29

o. Upon receipt of the AAA-Accounting-Request (Stop) message, the AGW sends an AAA-Accounting-30


32

3GPP2 A.S0020-0 v1.0

3-73

3.8.4 PMIP Binding Between SRNC and AGW in Idle State 1

This call flow describes the scenario when the AT is in idle state and the SRNC decides to move the 2

PMIP binding from the DAP to the SRNC. This call flow assumes that eBS1 is the DAP when the AT 3

closes the connection. 4

timeAT eBS1 SRNC

b

c

dTnot-ipt

f

a

AGW



IPT-Notification


AT in in idle state

eBS1 is the DAP of the AT

eBS1 releases

resources

e

Trrq-pmip

5

Figure 3.8.4-1 PMIP Binding Between SRNC and AGW in Idle State 6

a. The AT is in idle state and eBS1 is the DAP of the AT. 7

b. The SRNC decides to move the PMIP binding for the AT to the SRNC. The SRNC sends a PMIP-8

Registration Request message to the AGW with a Signaling-Only Binding type extension. The 9

message indicates that the AGW should buffer data for the AT when data arrives at the AGW. The 10

SRNC starts timer Trrq-pmip. 11

c. The AGW confirms the binding update by sending a PMIP-Registration Reply message to the SRNC 12

along with the lifetime of the binding. If the AGW accepts the Signaling-Only binding type 13

registration, it removes any existing Signaling-Only or Primary binding. Any existing RL+Primary 14

binding becomes RL-Only binding. The SRNC stops timer Trrq-pmip. 15

d. Upon receipt of the PMIP-Registration Reply message, the SRNC sends an IPT-Notification message 16

to the previous DAP of the AT, i.e., eBS1 in this call flow, to allow eBS1 to release resources related 17

to the AT. The SRNC starts timer Tnot-ipt. 18

e. Upon receipt of the IPT-Notification message, eBS1 responds with an IPT-Notification Ack message. 19

Upon receipt of the IPT-Notification Ack message, the SRNC stops timer Tnot-ipt. 20

f. eBS1 releases any session information necessary to support PMIP signaling binding, such as paging. 21

Note: radio resources were previously released during the Connection Close procedure when eBS1 22

received the Accounting-Response message from the AGW. 23

24

3GPP2 A.S0020-0 v1.0

3-74

3.8.5 DAP Requests AGW to Buffer Data in Idle State 1

This call flow describes the scenario when the AT is in idle state and the DAP decides to buffer data in 2

the AGW. This call flow assumes that eBS1 is the DAP for the AT when the AT becomes idle and the 3

PMIP binding for the AT remains at eBS1. 4

timeAT

eBS1(DAP)

b

a

AGW



Trrq-pmip

5

Figure 3.8.5-1 DAP Requests AGW to Buffer Data in Idle State 6

a. If the DAP decide that the AGW should buffer data for idle AT, then the eBS1 DAP sends a PMIP-7

Registration Request message with a Signaling-Only Binding type extension to the AGW. Upon 8

sending the PMIP-Registration Request message, eBS1 starts timer Trrq-pmip. 9

b. Upon receipt of the PMIP-Registration Request message, the AGW sends a PMIP-Registration Reply 10



binding. Upon receipt of the PMIP-Registration Reply message, eBS1 stops timer Trrq-pmip. 13

14

3.8.6 Idle AT Registration - Successful Scenario 15

This call flow describes the scenario where the AT performs registration with the SRNC through an eBS 16

that is supported by the SRNC. 17

tim eA T S R N C D A P A G W

R egis tra tion

a

b

c

C onnection c loses

R eg is tra tionR esponse

d

eB S 1

(optiona l)S R N C perfo rm s P M IP S igna ling -O n ly b ind ing

18

Figure 3.8.6-1 Idle AT Registration - Successful Scenario 19

a. The connection between the AT and the FLSE closes. Refer to sections 3.8.1 and 3.8.3. 20

b. Registration from the AT is triggered based on the Session Anchor Route configuration. The AT 21

sends a Registration message to the SRNC via the LLT tunnel from the local eBS which is assumed 22

to be eBS1 in this call flow. 23

c. Upon receipt of the tunneled Registration message, the SRNC updates its paging area for the AT and 24

accepts the registration request by sending RegistrationResponse message back to the AT. This 25

message is tunneled via the LLT tunnel to eBS1. 26

d. After step ‘c’, if the SRNC determines that the PMIP binding should be moved to the SRNC, then the 27

SRNC initiates the procedure in section 3.8.4. 28

29

3GPP2 A.S0020-0 v1.0

3-75

3.8.7 Paging with Data or Data Notification to eBS - Successful Scenario 1

This scenario describes the call flow for paging the AT when the AT is idle. This section assumes that the 2

PMIP binding is kept between the DAP and the AGW when the AT goes Idle. 3

timeAT

c

Tpgack-ias

b

eBS1

a

IAS-Paging Request (Priority)

eBS2 eBS3 SRNCeBS4(DAP)

AGW

Data or PMIP-Data Notification

IAS-Page (Local Fanout = 0)


DataData

xx

Tpgreq-ias

IAS-Paging Request Ack

d

Tpgreq-ias

Tsir-ias

Tnot-ipt



IAS-Session Information Request(Signature, Access Flag)

IAS-Session Information Response(Session, DAP)

PagePage

Page

RouteOpenRequest

RouteOpenAccept

RouteMap

Data

DataData

e

f

g

h

i

j

k

p

q**

r

o

l


s



m

n

Tnot-ipt

AT is in idle state

Key Exchange

eBS1 becomes DAP

** = conditional



Tacct-aaa

t

u

4

Figure 3.8.7-1 Paging - Successful Scenario 5

a. The connection between the AT and the FLSE is closed. The AT, SRNC and eBS4 DAP are all in idle 6

state. The eBS4 DAP may have performed flow control to trigger the AGW to buffer data. Refer to 7

the call flows in sections 3.8.1 and 3.8.3. 8

b. The eBS4 DAP is triggered to request paging of the idle AT either by receiving data for the AT from 9

the AGW (for the case where the DAP buffers data), or by receiving a PMIP-Data Notification 10

message from the AGW indicating that the AGW has received data for the AT (for the case where the 11

AGW buffers data). 12

3GPP2 A.S0020-0 v1.0

3-76

c. The eBS4 DAP sends an IAS-Paging Request message to the SRNC with the priority of the page, the 1

status of flow control at the AGW and a flag indicating that the paging area is unknown. The eBS4 2

DAP starts timer Tpgack-ias and waits for the IAS-Paging Request Ack message. 3

d. Upon receipt of the IAS-Paging Request message, the SRNC responds with an IAS-Paging Request 4

Ack message to the eBS4 DAP. Upon receipt of the IAS-Paging Request Ack message, the eBS4 5

DAP stops timer Tpgack-ias. The eBS4 DAP also starts timer Tpgreq-ias to await the arrival of an IPT-6

Notification message and does not attempt to send another IAS-Paging Request message to the SRNC 7

if subsequent data arrives, until after timer Tpgreq-ias expires. 8

e. The SRNC determines the paging area and sends an IAS-Page message to each eBS in the paging 9

area of the AT. This call flow assumes that eBS1, eBS2 and eBS3 are in the paging area. The IAS-10

Page message contains Local Fanout Required set to '0' for no local fanout, implying no IAS-Page 11

Ack message is required. The message also contains information on the time for initiating the paging 12

procedure over the air and priority of the page request. 13

f. eBS1, eBS2 and eBS3 page the AT at the specified channel and time. 14

g. This call flow assumes that the AT receives the page sent by eBS1 and responds to the page by 15

performing access procedure, i.e., the AT sends a RouteOpenRequest message to eBS1 to open a 16

route with eBS1. 17

h. Upon receipt of the RouteOpenRequest message, eBS1 sends an IAS-Session Information Request 18

message with a flag indicating access to the SRNC to requests a copy of the session and starts timer 19




i. The SRNC sends an IAS-Session Information Response message to eBS1 including the session 23

information and the ANID of eBS4 (DAP of the AT). Upon receipt of the IAS-Session Information 24

Response message, eBS1 stops timer Tsir-ias. 25

j. eBS1 sends RouteOpenAccept message to the AT to complete route establishment with the AT. 26

k. eBS1 completes Key Exchange procedure with the AT. This step can occur in parallel with step ‘j’. 27

l. The AT updates the RouteMap with both eBS1 and the SRNC. 28

m. eBS1 creates Air Link Record for the AT, sends an AAA-Accounting-Request (Start) message to the 29


n. Upon receipt of the AAA-Accounting-Request (Start) message, the AGW creates a UDR for this AT 31


After step ‘i’, eBS1 notifies all ANRIs in the route set and eBS4 (the previous DAP of the AT) that it has 33

become the FLSE for the AT. Steps ‘o’ and ‘q’ may occur in parallel. 34

o. eBS1 sends an IPT-Notification message to the SRNC indicating that eBS1 is the FLSE. eBS1 also 35


p. Upon receipt of the IPT-Notification message, the SRNC acknowledges with an IPT-Notification Ack 37


q. Based on the ANID of eBS4, eBS1 sends an IPT-Notification message to eBS4 indicating that eBS1 39

is the FLSE. eBS1 also starts timer Tnot-ipt. 40

r. Upon receipt of the IPT-Notification message, eBS4 acknowledges with an IPT-Notification Ack 41

message to eBS1. eBS4 also stops timer Tpgreq-ias and enters connected state. Upon receipt of the 42

IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 43

s. If the DAP had been set up to buffer data when the AT is idle, then any buffered data can be 44

forwarded to the AT through eBS1 once the DAP has been notified that eBS1 is the FLSE. If the 45

3GPP2 A.S0020-0 v1.0

3-77

AGW had been set up to buffer data when the AT is idle, and the DAP determines that it will 1

continue to be the DAP, then the DAP establishes a PMIP binding with the AGW in order to receive 2

data. 3

t. eBS1, which is the FLSE, becomes the DAP for the AT. Refer to section 3.6. This step can occur 4

anytime after step ‘j’. 5

u. Data from AGW is forwarded to eBS1 which is now the DAP. 6

7

3.8.8 Paging - Successful Scenario with Local Fanout 8

This scenario describes the call flow for paging the AT when the AT is idle. 9

tim eA T

c

T p g a c k-ia s

b

eB S1

a

IA S -P ag ing R equ est (P rio rity )

eB S2

e B S3

S R N Ce B S 4(D A P )

A G W

D a ta o r D a ta N o tifica tio n

IA S -P age (Lo ca l F ano u t=1 )

D a taD a ta

xx

IA S -P ag ing R e quest A ck

d

T p g re q-ia s

T s ir-ia s

T n o t-ip t


IP T -N o tifica tio n (eB S 1 is F LS E )

IA S -S ess ion In fo rm a tion R equ est(S igna tu re , A cce ss F lag )

IA S -S ess io n In fo rm atio n R e sponse(S ess ion , D A P )

P a geP a ge

P a ge

R ou teO pen R equ est

R ou teO pen A ccep t

R ou teM ap

D ata

D ataD a ta

e

h

i

j

k

l

m

r

s**

t

q

n

u

IP T -N o tifica tio n (eB S 1 is F LS E )


o

pT n o t-ip t

A T is in id le s ta te

K e y E xch ange

eB S 1 beco m es D A P

** = cond itiona l

IA S -P ag e (Loca l F anou t= 0 )

IA S -P a ge (Lo ca l F ano u t= 0 )

f

g

IA S -P a ge A ck

T p g a c k-ia s

10

Figure 3.8.8-1 Paging - Successful Scenario with Local Fanout 11

a. The connection between the AT and the FLSE is closed. The AT, SRNC and eBS4 DAP are all in idle 12

state. The eBS4 DAP may have performed flow control to trigger the AGW to buffer data. Refer to 13

the call flows in sections 3.8.1 and 3.8.4. 14

b. The eBS4 DAP is triggered to page the AT either by receiving data for the AT from the AGW or by 15

receiving a data notification that the AGW has data for the AT. 16

3GPP2 A.S0020-0 v1.0

3-78

c. The eBS4 DAP sends an IAS-Paging Request message to the SRNC with the priority of the page, the 1

status of flow control at the AGW and a flag indicating that the paging area is unknown. The eBS4 2

DAP starts timer Tpgack-ias and waits for the IAS-Paging Request Ack message. 3

d. Upon receipt of the IAS-Paging Request message, the SRNC responds with an IAS-Paging Request 4

Ack message to the eBS4 DAP. Upon receipt of the IAS-Paging Request Ack message, the eBS4 5

DAP stops timer Tpgack-ias and does not attempt to send another IAS-Paging Request message to the 6

SRNC if subsequent data arrives, until after timer Tpgreq-ias expires. 7

e. The SRNC sends an IAS-Page message to the LastRegistered-eBS for the AT. This call flow assumes 8

that the LastRegistered-eBS is eBS1. The IAS-Page message contains Local Fanout Required set to 9

'1' indicating local fanout is required. The message also contains information on the time for initiating 10

the paging procedure over the air and priority of the page request. The SRNC starts timer Tpgack-ias 11

and waits for the IAS-Page Ack message. 12

f. Upon receipt of the IAS-Page message with Local Fanout Required flag set, eBS1 sends an IAS-Page 13

Ack message to the SRNC. Upon receipt of the IAS-Page Ack message, the SRNC stops timer 14

Tpgack-ias. 15

g. Based on the Local Fanout flag and other information elements included in the IAS-Page message, 16

eBS1 determines the set of eBSs which should page the AT. This set is known as the eBSs in the 17

paging area. eBS1 forwards the message to the eBSs in the paging area. In the forwarded message, 18

eBS1 sets Local Fanout Required flag in the Paging Control IE to ‘0’ 19

h. eBS1, eBS2 and eBS3 page the AT at the specified channel and time. 20

i. This call flow assumes that the AT receives the page sent by eBS1 and responds to the page by 21

performing access procedure, i.e., the AT sends a RouteOpenRequest message to eBS1 to open a 22

route with eBS1. 23

j. Upon receipt of the RouteOpenRequest message, eBS1 sends an IAS-Session Information Request 24

message with a flag indicating access to the SRNC to requests a copy of the session and starts timer 25




k. The SRNC sends an IAS-Session Information Response message to eBS1 including the session 29

information and the ANID of eBS4 (DAP of the AT). Upon receipt of the IAS-Session Information 30

Response message, eBS1 stops timer Tsir-ias. 31

l. eBS1 sends RouteOpenAccept message to the AT to complete route establishment with the AT. 32

m. eBS1 completes Key Exchange procedure with the AT. This step can occur in parallel with step ‘j’. 33

n. The AT updates the RouteMap with both eBS1 and the SRNC. 34

After sending the RouteOpenAccept message to the AT in step ‘j’, eBS1 notifies all ANRIs in the route 35

set and eBS4 (the previous DAP of the AT) that it has become the FLSE for the AT. 36

o. eBS1 sends an IPT-Notification message to the SRNC indicating that eBS1 is the FLSE. eBS1 also 37


p. Upon receipt of the IPT-Notification message, the SRNC acknowledges with an IPT-Notification Ack 39


q. Based on the ANID of eBS4, eBS1 sends an IPT-Notification message to eBS4 indicating that eBS1 41

is the FLSE. eBS1 also starts timer Tnot-ipt. 42

r. Upon receipt of the IPT-Notification message, eBS4 acknowledges with an IPT-Notification Ack 43

message to eBS1. eBS4 also stops timer Tpgreq-ias and enters connected state. Upon receipt of the 44

IPT-Notification Ack message, eBS1 stops timer Tnot-ipt. 45

3GPP2 A.S0020-0 v1.0

3-79

s. If the AGW does not buffer the data or the eBS4 DAP has data for the AT, data in the eBS4 DAP is 1

forwarded to the AT through eBS1 which is the FLSE. 2

t. eBS1, which is the FLSE, becomes the DAP for the AT. Refer to section 3.6.1. This step can occur 3

anytime after step ‘j’. 4


6

3.8.9 Paging with Data Notification to the SRNC - Successful Scenario 7

This scenario describes the call flow for paging the AT when the AT is idle and the SRNC has the PMIP 8

binding for the idle AT as described in section 3.8.4. 9

timeAT eBS1

a

eBS2 eBS3 SRNC AGW

IAS-Page (local fanout = 0)


x

x Tpgreq-ias

Tsir-ias

IAS-Session Information Request (Signature, Access Flag)

IAS-Session Information Response (Session, AGW Address, GRE Key)

PagePage

Page

RouteOpenRequest

RouteOpenAccept

d

RouteMap

DataData




e

f

g

h

i

j

k

l

m

n

p

q

AT is in Idle State

Key Exchange

PMIP-Data Notification

PMIP-Registration Request (Timestamp)

PMIP-Registration Reply (Code 0 – registration accepted, Timestamp)Trrq-pmip


s

t

u

** = conditional* = optional

DAP Move Request

DAPAssignment

o*

r**

IPT-Notification (DAP identity, Timestamp)


AAA-Accounting-ResponseTacct-aaa

c

b

10

Figure 3.8.9-1 Paging with Data Notification to the SRNC - Successful Scenario 11

3GPP2 A.S0020-0 v1.0

3-80

a. The connection between the AT and the FLSE is closed. The AT and SRNC are in idle state. The 1

SRNC has established a PMIP signaling binding with the AGW so that the AGW will notify the 2

SRNC when data is received for the AT, and so the AGW will buffer data for the AT while paging 3

takes place. Refer to the call flows in section 3.8.3 and 3.8.2. 4

b. The SRNC is triggered to page the AT by receiving a PMIP-Data Notification message indicating that 5

the AGW has data for the AT. 6

c. The SRNC sends an IAS-Page message to each eBS in the paging area of the AT. This call flow 7

assumes that eBS1, eBS2 and eBS3 are in the paging area. The IAS-Page message contains a Cause 8

IE set to ‘Normal Operation, a Paging Control Record IE indicating the priority of the page and an 9

indication that an acknowledgment is not required, and a Session State Information Record IE 10

containing information on the time for initiating the paging procedure over the air. The SRNC starts 11

an instance of timer Tpgreq-ias for each paging request message sent. 12

d. eBS1, eBS2 and eBS3 page the AT at the specified channel and time. 13

e. This call flow assumes that the AT receives the page sent by eBS1 and responds to the page by 14

performing the access procedure, i.e., the AT sends a RouteOpenRequest message to eBS1 to open a 15

route with eBS1. 16

f. Upon receipt of the RouteOpenRequest message, eBS1 also sends an IAS-Session Information 17

Request message, with the Access/Tunneled field indicating ‘access’, to the SRNC to request a copy 18

of the session and starts timer Tsir-ias. Upon receipt of the IAS-Session Information Request message 19

with the Access/Tunneled field indicating ‘access’, the SRNC stops timer Tpgreq-ias. If the previous 20

session reference transfer was incomplete where the SRNC was the source or target SRNC of the 21

incomplete session reference transfer, the SRNC also notifies the target or source SRNC of the 22

previous session reference transfer (refer to sections 3.7.2.4 or 3.7.2.5, respectively). 23

g. The SRNC sends the IAS-Session Information Response message to eBS1 including the session 24

information and the address of the AGW and the GRE Key (refer to [13]). Upon receipt of the IAS-25


h. eBS1 sends RouteOpenAcceptmessage to the AT to complete route establishment with the AT. 27

i. eBS1 completes Key Exchange procedure with the AT. This step can occur in parallel with step ‘j’. 28

j. The AT updates the RouteMap with both eBS1 and the SRNC. 29

k. eBS1 creates Air Link Record for the AT, sends an AAA-Accounting-Request (Start) message to the 30


l. Upon receipt of the AAA-Accounting-Request (Start) message, the AGW creates a UDR for this AT 32


m. Based on the ANIDs of the other members of the Route Set (in this case the SRNC is the only other 34

member of the Route Set), eBS1 sends an IPT-Notification message to the SRNC indicating that 35

eBS1 is the FLSE. eBS1 also starts timer Tnot-ipt. 36

n. Upon receipt of the IPT-Notification message, the SRNC acknowledges with an IPT-Notification Ack 37


For AN-initiated DAP selection mode, eBS1/FLSE determines to assume the DAP role, and establishes a 39

PMIP binding with the AGW so that bearer data can be conveyed to the AT. This step can occur anytime 40

after step ‘g’ in AN-initiated DAP selection mode, or after step ‘h’ in AT-assisted DAP handoff mode. 41

o. If the AT is configured to use AT-assisted DAP handoff, the AT sends a DAPMoveRequest message 42

to eBS1 to trigger initial PMIP tunnel setup with the AGW. 43

p. For AN-initiated DAP selection mode, eBS1 determines to update the PMIP binding with the AGW 44

by sending a PMIP-Registration Request message to the AGW and starts timer Trrq-pmip. 45

3GPP2 A.S0020-0 v1.0

3-81

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

along with the lifetime of the tunnel. The target DAP stops timer Trrq-pmip. 2

r. If AT sends a DAPMoveRequest message in step ‘o’, eBS1 responds to the AT with a 3

DAPAssignment message to acknowledge completion of the PMIP tunnel setup. 4

s. The eBS1/DAP sends an IPT-Notification message to the SRNC and starts timer Tnot-ipt. The 5

message indicates that eBS1 is now the DAP. The message also contains the timestamp that eBS1 6

used in updating the PMIP tunnel with the AGW. Note that the IPT-Notification at step ‘o’ could 7

optionally simultaneously indicate that eBS1 is the DAP and the FLSE, i.e. instead of an IPT-8

Notification at step ‘k’ and step ‘q’, one IPT-Notification at step ‘o’ could be sent. 9

t. The SRNC responds with an IPT-Notification Ack message and eBS1/DAP stops timer Tnot-ipt. 10


12

3.9 Miscellaneous UMB Call Flows 13

3.9.1 Neighbor Discovery 14

Neighbor Discovery (ND) procedures include both AT and network initiated scenarios. The two cases 15

identified in this section allow the serving eBS to discover new neighbors, request updates of ND inform-16

ation from known eBSs and update its own ND information at neighboring eBSs. 17

3.9.1.1 Neighbor Discovery - AT (Pilot Report) Initiated 18

This call flow describes the scenario for AT initiated ND. In this case, an unknown PilotID in the AT’s 19

Pilot Report message causes the serving eBS to request the new eBS’s Sector ID, so it can start the ND 20

procedures. 21

timeAT

eBS1(serving)

PilotReport (pilotID2, other pilotIDs)

b

a

c

Tndrpt-ias

IAS-ND Report

f

g

IAS-ND Request

eBS2(new)

SectorIDRequest (pilotID2)

SectorIDResponse (pilotID2, SectorID2)

IAS-ND Request

IAS-ND Report

Tndrpt-ias

d

e

22

Figure 3.9.1.1-1 Neighbor Discovery - AT (Pilot Report) Initiated 23

a. The AT sees the pilot from eBS2 and reports this to eBS1 in a PilotReport message. 24

b. eBS1 does not recognize eBS2 based on pilotID2 and responds to the AT with a SectorIDRequest for 25

pilotID2. 26

c. The AT sends a SectorIDResponse message to eBS1 with the SectorID of pilotID2. eBS1 uses this in-27

formation to determine the ANID of eBS2 (Refer to [1] Part-000). 28

d. eBS1 sends an IAS-ND Request message, to eBS2 to initiate ND procedures and starts timer Tndrpt-ias. 29

e. eBS2 associates eBS1 with pilotID1, and responds with an IAS-ND Report message including its ND 30

information. eBS1 upon receipt of this message associates eBS2 with pilotID2, stores eBS2’s ND 31

information and stops timer Tndrpt-ias. 32

3GPP2 A.S0020-0 v1.0

3-82

f. eBS2 sends an IAS-ND Request message to eBS1 to initiate its own ND procedures and starts timer 1

Tndrpt-ias. 2

g. eBS1 responds with an IAS-ND Report message including its ND information. eBS2 upon receipt of 3

this message stores eBS1’s ND information and stops timer Tndrpt-ias. 4

5

3.9.1.2 Neighbor Discovery - eBS Initiated 6

This call flow describes the scenario where an eBS already knows the ANID of a neighboring eBS and 7

chooses to provide updated ND information to this eBS. 8

tim eAT eBS 1

IAS-N D R eport

b

eBS 2

aT ndrptack -ias

IAS-N D R eportAck

9

Figure 3.9.1.2-1 Neighbor Discovery - eBS Initiated 10

a. Based on internal changes (e.g., IOS protocol is revised), eBS1 may decide to indicate a change in it’s 11

own ND information to eBS2. eBS1 sends an unsolicited IAS-Neighbor Discovery Report message to 12

eBS1 and starts timer Tndrptack-ias. 13

b. eBS2 sends an IAS-Neighbor Discovery Report Ack message to eBS1. eBS1 upon receipt of IAS 14

Neighbor Discovery Report Ack message stops timer Tndrptack-ias. 15

16

3GPP2 A.S0020-0 v1.0

4-1

4 Messages, IEs and Timer Definitions 1

Refer to section 1.5 for Message Body, Coding, Ordering, and Interpretation of IEs. 2

4.1 Message Definitions 3

This section provides UMB IOS message definitions. 4

4.1.1 IAS Message Definitions 5

IAS messages are sent between ANRIs and between ANRIs and the DAP, if the DAP is outside the route 6

set, for session related functions (e.g., session request, session update and UATI update) as well as for AT 7

mobility and paging. IAS messages are sent between eBSs and between eBSs and the SRNC for neighbor 8

discovery related functions. 9

4.1.1.1 IAS-Session Information Request 10

This message is sent from an eBS to the SRNC to request session information for the AT. 11

Information Element Section Reference Type Notes

IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 C b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d RouteOpenRequest 4.2.1.6 C e Session Signature 4.2.1.7 R e Session Request Record 4.2.1.16 R f

12

a. The value of the Correlation ID in the IAS Message Type header shall be returned in the IAS 13

Message Type header in the corresponding IAS-Session Information Response message. 14

b. This IE contains the SSID of the AT for which the session information request is being made. This IE 15

is included if the information is available at the eBS. 16

c. This IE contains the UATI of the AT that was assigned by the SRNC. 17

d. This IE contains the identity information of the sending and receiving entities. 18

e. The RouteOpenRequest IE and the Session Signature IE are included if a RouteOpenRequest message 19

from the AT triggered the session information request. Otherwise the Session Signature IE is included. 20

f. This IE contains miscellaneous information related to session request. 21

22

4.1.1.2 IAS-Session Information Response 23

This message is sent from the SRNC to an eBS in response to a request for session information for an AT. 24


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R

3GPP2 A.S0020-0 v1.0

4-2


IAS DAP Record 4.2.1.18 C e SRNC Record 4.2.1.12 C f Session State Information Record 4.2.1.19 C g, i Network Session Record 4.2.1.20 C h

1

a. The value of the Correlation ID in the IAS Message Type header shall be set to the value of the 2

Correlation ID in the IAS Message Type header of the corresponding IAS-Session Information 3

Request message. 4

b. This IE contains the SSID of the AT for which the session information request was made. 5

c. This IE contains the UATI of the AT. 6


e. This IE contains the current DAP information and AGW records (per AGW) and is included if the 8

Cause IE indicates a successful event. 9

f. This IE is included to provide current SRNC information and is included if the Cause IE indicates a 10

successful event or Session Anchor RouteID mismatched. 11

g. This IE contains the Session State Information Records (SSIRs) for the AT and is included if the 12

Cause IE indicates a successful event. 13

h. This IE contains the network session information (e.g., QoS) and is included if the Cause IE indicates 14

a successful event. 15

i. Multiple instances of this IE may be present. 16

17

4.1.1.3 IAS-Session Information Update Request 18

This message is sent from an ANRI to the SRNC to request updated session information for an AT. 19


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Session Signature 4.2.1.7 R Session State Information Record 4.2.1.19 R e Network Session Record 4.2.1.20 R

20

a. The value of the Correlation ID in the IAS Message Type header shall be returned in the Correlation 21

ID in the IAS Message Type header in the corresponding IAS-Session Information Update Response 22

message. 23

b. This IE contains the SSID of the AT for which the session information update request is being made. 24



3GPP2 A.S0020-0 v1.0

4-3

e. Multiple instances of this IE may be present. 1

2

4.1.1.4 IAS-Session Information Update Response 3

This message is sent from the SRNC to an ANRI in response to a request to update session information 4

for an AT. 5


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R Session Signature 4.2.1.7 C e

6


Correlation ID in the IAS Message Type header of the corresponding IAS-Session Information 8

Update Request message. 9

b. This IE contains the SSID of the AT for which the session information update request was made. 10



e. This IE is included if the Cause IE indicates a successful event or an Invalid session signature. 13

14

4.1.1.5 IAS-SRNC Transfer Request 15

This message is sent from the target SRNC to the source SRNC to request that the session reference for 16

the AT be transferred to the target SRNC. 17


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 C b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d RouteOpenRequest 4.2.1.6 C e Session Signature 4.2.1.7 R e New UATI 128 4.2.1.11 R f Session Request Record 4.2.1.16 R g

18


ID in the IAS Message Type header in the corresponding IAS-SRNC Transfer Response message . 20

b. This IE contains the SSID of the AT for which the SRNC transfer request is being made. This IE is 21

included if the information is available at the target SRNC. 22


3GPP2 A.S0020-0 v1.0

4-4


e. The Session Signature IE is included and the RouteOpenRequest IE is omitted if the message is sent 2

by an ANRI in the Route Set. Otherwise, the RouteOpenRequest IE and the Session Signature IE are 3

included. 4

f. This is the new UATI provided by the target SRNC. 5

g. This IE contains miscellaneous information related to session request. 6

7

4.1.1.6 IAS-SRNC Transfer Response 8

This message is sent from the source SRNC to the target SRNC in response to a SRNC transfer request. 9


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R IAS DAP Record 4.2.1.18 C e SRNC Record 4.2.1.12 C f Session State Information Record 4.2.1.19 C e, h Network Session Record 4.2.1.20 C e PMIP Root Key 4.2.1.9 C g

10


Correlation ID in the IAS Message Type header of the corresponding IAS-SRNC Transfer Request 12

message. 13

b. This IE contains the SSID of the AT for which the SRNC transfer request was made. 14



e. This IE is included if the Cause IE indicates a successful event. 17

f. This IE is included for a successful SRNC transfer to provide current SRNC information and is 18

included if the Cause IE indicates a successful event or Session Anchor RouteID mismatched. 19

g. The IE is included for a successful SRNC transfer to provide the PMIP signaling message protection 20

key. 21

h. Multiple instances of this IE may be present. 22

23

4.1.1.7 IAS-Session Release 24

This message is sent by an ANRI (e.g., SRNC) to another ANRI or DAP to indicate that the UMB session 25

for an AT has been released. 26

3GPP2 A.S0020-0 v1.0

4-5



1


ID in the IAS Message Type header in the corresponding IAS-Session Release Ack message. 3

b. This IE contains the SSID of the AT for which the UMB session is being released. 4



7

4.1.1.8 IAS-Session Release Ack 8

This message is sent in response to the IAS-Session Release message. 9



10


Correlation ID in the IAS Message Type header of the corresponding IAS-Session Release message. 12

b. This IE contains the SSID of the AT for which the UMB session is being released. 13



16

4.1.1.9 IAS-UATI Update 17

This message is sent from the SRNC to an ANRI DAP or old SRNC to provide the SRNC Record. 18


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (RATI/UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R SRNC Record 4.2.1.12 R e

3GPP2 A.S0020-0 v1.0

4-6

1


ID in the IAS Message Type header in the corresponding IAS-Update Ack message. 3

b. This IE contains the SSID of the AT for which the UATI update is being made. 4

c. This IE contains the UATI of the AT or the RATI, if the update is being sent as a result of assigning a 5

UATI to an AT that previously had no UATI. 6


e. This IE is included to provide current SRNC information. 8

9

4.1.1.10 IAS-UATI Update Ack 10

This message is sent in response to an IAS-UATI Update message. 11



12


Correlation ID in the IAS Message Type header of the corresponding IAS-UATI Update message. 14

b. This IE contains the SSID of the AT for which the UATI update was made. 15



18

4.1.1.11 IAS-Paging Request 19

This message is sent from DAP to the SRNC to request paging for an AT. 20


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R Paging Control Record 4.2.1.13 C e


ID in the IAS Message Type header in the corresponding IAS-Paging Request Ack or IPT-22

Notification message. 23

b. This IE contains the SSID of the AT for which the paging request was made. 24


3GPP2 A.S0020-0 v1.0

4-7


e. These IEs are included if available at the sender. 2

3

4.1.1.12 IAS-Paging Request Ack 4

This message is sent in response to an IAS-Paging Request message. 5


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R Page Attempt Timer 4.2.1.17 R e


Correlation ID in the IAS Message Type header of the corresponding IAS-Paging Request message. 7




e. This IE contains the duration that the SRNC will attempt to page the AT without receiving another 11

IAS-Paging Request message from the DAP. 12

4.1.1.13 IAS-Page 13

This message is sent from the SRNC to an eBS, or from one eBS to another eBS to request paging for an 14

AT. 15


IAS Message Type 4.2.1.3 R a AT Identity (SSID) 4.2.1.4 R b AT Identity (UATI) 4.2.1.4 R c Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R Paging Control Record 4.2.1.13 C e AIS Paging Information Record 4.2.1.22 C e, f New UATI 128 4.2.1.11 C g


ID in the IAS Message Type header in the corresponding IAS-Page Request Ack. 17


c. This IE contains the UATI of the AT for which the SRNC sending this message assigned. 19


e. These IEs are included if available at the sender. 21

3GPP2 A.S0020-0 v1.0

4-8

f. This IE contains session state information records that are necessary for determining the current 1

paging cycle and the paging area of the AT. The receiver should assume the default values for any 2

SSIRs that are not sent. 3

g. This IE is included if the paging request is sent during SRNC transfer before the new UATI128 is 4

confirmed at the source SRNC. This information may be useful if the connection for the AT is 5

dropped during SRNC transfer. In this scenario, the AT may have the new UATI assignment but the 6

network has not received the confirmation. 7

8

4.1.1.14 IAS-Page Ack 9

This message is sent in response to an IAS-Page message if Local Fanout was requested. 10


IAS Message Type 4.2.1.3 R AT Identity (SSID) 4.2.1.4 R a AT Identity (UATI) 4.2.1.4 R b Network Identity (Endpoint ID) 4.2.1.5 R d Cause 4.2.1.8 R

a. This IE contains the SSID of the AT for which the paging request was made. 11

b. This IE contains the UATI of the AT for which the paging SRNC assigned. 12

c. The value of this IE shall be set to the value of the Correlation ID in the corresponding IAS-Page 13

message. 14


16

4.1.1.15 IAS-Neighbor Discovery Request 17

This message is sent from an eBS/SRNC to another eBS/SRNC either in response to that ANRI’s request 18

to initiate neighbor discovery procedures or in response to an AT reporting a pilotID that the sending 19

ANRI does not recognize. 20


IAS Message Type 4.2.1.3 R a Network Identity (Endpoint ID) 4.2.1.5 R b

21

a. The value of the Correlation ID in the IAS Message Type header of the IAS-Neighbor Discovery 22

Request message shall be returned in the Correlation ID in the IAS Message Type header in the 23

corresponding IAS-Neighbor Discovery Report message. 24

b. This IE contains the identity information of the sending and receiving entities. 25

26

4.1.1.16 IAS-Neighbor Discovery Report 27

This message may be sent in response to an IAS-Neighbor Discovery Request message or it may be sent 28

autonomously. 29

3GPP2 A.S0020-0 v1.0

4-9


IAS Message Type 4.2.1.3 R a Network Identity (Endpoint ID) 4.2.1.5 R b Neighbor Discovery Record 4.2.1.14 R Sector Parameters 4.2.1.15 R c Neighbor Connection Information 4.2.1.10 C d

1

a. If this message is being sent in response to an IAS-Neighbor Discovery Request message, the value of 2

the Correlation ID in the IAS Message Type header shall be set to the value of the Correlation ID in 3

the IAS Message Type header of that message. 4


c. This IE contains the sector parameters information of the sending eBS. 6

d. If the sending entity chooses to send this IE, it contains the addresses of the preferred SRNC and/or 7

the AGW used by the neighbor if the neighbor has been provisioned to use these specific entities. 8

4.1.1.17 IAS-Neighbor Discovery Report Ack 9

This message is sent in response to an IAS-Neighbor Discovery Report message. 10


IAS Message Type 4.2.1.3 R Network Identity (Endpoint ID) 4.2.1.5 R b


Correlation ID in the IAS Message Type header of the corresponding IAS-Neighbor Discovery 12

Report message. 13


15

4.1.1.18 IAS-Reject 16

This message is sent in response to an IAS message that can not be properly processed. 17


IAS Message Type 4.2.1.3 R a Network Identity (Endpoint ID) 4.2.1.5 R b Cause 4.2.1.8 R c IAS Reject Record 4.2.1.21 R d


Correlation ID in the IAS Message Type header of the rejected message, if known. Otherwise the 19

Correlation ID in the IAS Message Type header shall be set to zero and ignored by the receiving 20

entity. 21


c. This IE shall include the cause for the message being rejected. 23

d. This IE includes reject details and the message that caused the IAS-Reject message to be sent. 24

25

3GPP2 A.S0020-0 v1.0

4-10

4.1.2 IPT Message Definitions 1

IPT messages are sent between ANRIs and DAP for notification of a change in status and to provide 2

corresponding acknowledgements. 3

4.1.2.1 IPT-Notification 4

This message is sent between ANRIs and DAP to provide notification from the sending entity of a change 5

in its status or to indicate a change in the receiving entity’s status. 6


IPT Message Type 4.2.2.3 R a AT Identity (SSID) 4.2.2.4 R b AT Identity (UATI) 4.2.2.4 R c Network Identity (Endpoint ID) 4.2.2.5 R d Access Counter 4.2.2.9 R e Notification Record 4.2.2.6 C f, k IPT-DAP Record 4.2.2.7 C g, k LinkID 4.2.2.8 C h Message Timestamp 4.2.2.13 C i

7

a. The value of the Correlation ID in the IPT Message Type header shall be set to the value of the 8

Correlation ID in the IPT Message Type header of the corresponding IPT-Notification Ack message. 9

b. This IE contains the SSID of the AT for which the notification is being made. 10

c. This IE contains the UATI of the AT for which the serving SRNC assigned. 11


e. This IE contains the Access Counter value in the sender. Refer to section 2.2.3.1. 13

f. This IE may be included to provide indication(s) for why the message is being sent. 14

g. The IPT-DAP Record IE shall contain the AGW C-plane IP address to which the ANRI performed 15

PMIP registration, the AGW U-plane IP address, the GRE key used for the PMIP tunnel with the 16

AGW, the PMIP timestamp which the ANRI used in the successful PMIP registration request 17

message. 18

h. This IE is included if the notification message is sent to indicate that the sender is now the FLSE or 19

the DAP. The IE contains the LinkID of the sending eBS. 20

i. This IE is included if the notification message is sent to indicate that connection with the AT is closed 21

and the ConnectionClose message is received from the AT. The IE contains the RouteCounter in the 22

ConnectionClose message from the AT. 23

j. This optional IE may be included by the sender to provide the information of when the message is 24

generated. The receiver may use the information contain in this IE to determine the order that the 25

IPT-Notification messages were received. 26

k. Notification Record is not used to indicate that the sender is now DAP. The presence of the IPT-DAP 27

Record IE indicates that the sender is now DAP. 28

4.1.2.2 IPT-Notification Ack 29

This message is sent in response to an IPT-Notification message. 30


IPT Message Type 4.2.2.3 R a AT Identity (SSID) 4.2.2.4 R b

3GPP2 A.S0020-0 v1.0

4-11


AT Identity (UATI) 4.2.2.4 R c Network Identity (Endpoint ID) 4.2.2.5 R d Cause 4.2.2.10 R Notification Record 4.2.2.6 C e Flush Information 4.2.2.12 C f

1


Correlation ID in the IPT Message Type header in the corresponding IPT-Notification message. 3

b. This IE contains the SSID of the AT for which the notification was made. 4

c. This IE contains the UATI of the AT for which the serving SRNC assigned. 5


e. This IE contains the identity of the sender of the IPT-Notification Ack message that may be useful for 7

the receiver. This IE is included in the following scenarios: (i) the sender is the FLSE in response to 8

the notification from the DAP, (ii) the sender is the previous FLSE in response to the notification 9

from the current FLSE, and (iii) the sender is the previous RLSE in response to the notification from 10

the current RLSE. 11

f. This IE contains the information of the buffered data in the sender. This IE is included in the 12

following scenarios: (i) the sender is the previous FLSE in response to the notification from the 13

current FLSE, and (ii) the sender is the previous RLSE in response to the notification from the current 14

RLSE. 15

4.1.2.3 IPT-Reject 16

This message is sent in response to an IPT message that can not be properly processed. 17


IPT Message Type 4.2.2.3 R a Network Identity (Endpoint ID) 4.2.2.5 R b Cause 4.2.2.10 R c IPT Reject Record 4.2.2.14 R d


Correlation ID in the IPT Message Type header of the rejected message, if known. Otherwise the 19

Correlation ID in the IPT Message Type header shall be set to zero and ignored by the receiving 20

entity. 21


c. This IE shall include the cause for the message being rejected. 23

d. This IE includes reject details and the message that caused the IPT-Reject message to be sent. 24

25

4.1.2.4 IPT-Flush 26

This message is sent to indicate that the sender has finished tunneling data that requires in-order delivery. 27

3GPP2 A.S0020-0 v1.0

4-12


IPT Message Type 4.2.2.3 R AT Identity (SSID) 4.2.2.4 R a AT Identity (UATI) 4.2.2.4 R b Network Identity (Endpoint ID) 4.2.2.5 R c Notification Correlation ID 4.2.2.11 R d Flush Information 4.2.2.12 R

1

a. This IE contains the SSID and related information of the AT for which the notification was made. 2

b. This IE contains the UATI of the AT for which the serving SRNC assigned. 3

c. This IE contains the identity information of the sending and receiving entities. 4

d. The value of this IE shall be set to the value of the Correlation ID in the corresponding IPT-5

Notification message that triggers this message. 6

4.1.3 PMIP Message Definitions 7

PMIP messages are sent between eBS/SRNC and AGW to manage PMIP binding. For the definition of 8

messages, refer to [2]. 9

4.1.4 AAA Message Definitions 10

AAA messages are sent between eBS/SRNC and AGW to perform procedures related to authentication 11

authorization and accounting. For the definition of messages, refer to [2]. 12

13

4.2 IE Definitions 14

This section provides UMB IOS IE definitions. 15

4.2.1 IAS IE Definitions 16

This section provides IE definitions for the IAS messages defined in section 4.1.1. 17

4.2.1.1 IAS IE Identifiers 18

The following table lists all the IEs that make up the IAS messages defined in section 4.1.1. The table 19

includes the Information Element Identifier (IEI) coding which distinguishes one IE from another. The 20

table also includes a section reference indicating where the IE coding can be found. 21

22

Element Name IEI (Hex) Reference IAS Message Type none 4.2.1.3 AT Identity 01H 4.2.1.4 Network Identity (Endpoint ID) 02H 4.2.1.5 RouteOpenRequest 03H 4.2.1.6 Session Signature 04H 4.2.1.7 Cause 05H 4.2.1.8 PMIP Root Key 06H 4.2.1.9

3GPP2 A.S0020-0 v1.0

4-13

Element Name IEI (Hex) Reference Neighbor Connection Information 07H 4.2.1.10 New UATI 128 08H 4.2.1.11 SRNC Record 09H 4.2.1.12 Paging Control Record 0AH 4.2.1.13 Neighbor Discovery Record 0BH 4.2.1.14 Sector Parameters 0CH 4.2.1.15 Session Request Record 0DH 4.2.1.16 Page Attempt Timer 0EH 4.2.1.17 IAS DAP Record A0H 4.2.1.18 Session State Information Record A1H 4.2.1.19 Network Session Record A2H 4.2.1.20 IAS Reject Record A3H 4.2.1.21 AIS Paging Information Record A4H 4.2.1.22

Note: The IEI range for an IE determines the size of its IE length field and is defined in section 1.8. 1

2

4.2.1.2 Cross Reference of IEs with Messages 3

The following table provides a cross reference between the IEs and the messages defined in this specifi-4

cation. 5

Table 4.2.1.2-1 Cross Reference of IEs with Messages

Information Element Ref. IEI Used in These Messages Ref.

AIS Paging Information Record 4.2.1.22 A4H IAS-Page 4.1.1.13AT Identity 4.2.1.4 01H IAS-Session Information Request 4.1.1.1 IAS-Session Information Response 4.1.1.2 IAS-Session Information Update

Request 4.1.1.3

IAS-Session Information Update Response

4.1.1.4

IAS-SRNC Transfer Request 4.1.1.5 IAS-SRNC Transfer Response 4.1.1.6 IAS-Session Release 4.1.1.7 IAS-Session Release Ack 4.1.1.8 IAS-UATI Update 4.1.1.9 IAS-UATI Update Ack 4.1.1.10 IAS-Paging Request 4.1.1.11 IAS-Paging Request Ack 4.1.1.12 IAS-Page 4.1.1.13 IAS-Page Ack 4.1.1.14Cause 4.2.1.8 05H IAS-Session Information Response 4.1.1.2

3GPP2 A.S0020-0 v1.0

4-14




4.1.1.4

IAS-SRNC Transfer Response 4.1.1.6 IAS-Session Release Ack 4.1.1.8 IAS-Session Release 4.1.1.7 IAS-Paging Request 4.1.1.11 IAS-Paging Request Ack 4.1.1.12 IAS-Page 4.1.1.13 IAS-Page Ack 4.1.1.14 IAS-Reject 4.1.1.18IAS DAP Record 4.2.1.18 A0H IAS-Session Information Response 4.1.1.2 IAS-SRNC Transfer Response 4.1.1.6 IAS Message Type 4.2.1.3 none IAS-Session Information Request 4.1.1.1 IAS-Session Information Response 4.1.1.2 IAS-Session Information Update

Request 4.1.1.3


4.1.1.4

IAS-SRNC Transfer Request 4.1.1.5 IAS-SRNC Transfer Response 4.1.1.6 IAS-Session Release 4.1.1.7 IAS-Session Release Ack 4.1.1.8 IAS-UATI Update 4.1.1.9 IAS-UATI Update Ack 4.1.1.10 IAS-Paging Request 4.1.1.11 IAS-Paging Request Ack 4.1.1.12 IAS-Page 4.1.1.13 IAS-Page Ack 4.1.1.14 IAS-Neighbor Discovery Request 4.1.1.15 IAS-Neighbor Discovery Report 4.1.1.16 IAS-Neighbor Discovery Report Ack 4.1.1.17 IAS-Reject 4.1.1.18IAS Reject Record 4.2.1.21 A3H IAS-Reject 4.1.1.18Neighbor Connection Information 4.2.1.10 07H IAS-Neighbor Discovery Report 4.1.1.16Neighbor Discovery Record 4.2.1.14 0BH IAS-Neighbor Discovery Report 4.1.1.16Network Identity (Endpoint ID) 4.2.1.5 02H IAS-Session Information Request 4.1.1.1 IAS-Session Information Response 4.1.1.2

3GPP2 A.S0020-0 v1.0

4-15



IAS-Session Information Update Request

4.1.1.3


4.1.1.4

IAS-SRNC Transfer Request 4.1.1.5 IAS-SRNC Transfer Response 4.1.1.6 IAS-Session Release 4.1.1.7 IAS-Session Release Ack 4.1.1.8 IAS-UATI Update 4.1.1.9 IAS-UATI Update Ack 4.1.1.10 IAS-Paging Request 4.1.1.11 IAS-Paging Request Ack 4.1.1.12 IAS-Page 4.1.1.13 IAS-Page Ack 4.1.1.14 IAS-Neighbor Discovery Request 4.1.1.15 IAS-Neighbor Discovery Report 4.1.1.16 IAS-Neighbor Discovery Report Ack 4.1.1.17 IAS-Reject 4.1.1.18Network Session Record 4.2.1.20 A2H IAS-Session Information Response 4.1.1.2 IAS-Session Information Update

Request 4.1.1.3

IAS-SRNC Transfer Response 4.1.1.6 New UATI 128 4.2.1.11 08H IAS-Session Information Response 4.1.1.2 IAS-SRNC Transfer Request 4.1.1.5 IAS-UATI Update 4.1.1.9 IAS-Page 4.1.1.13Page Attempt Timer 4.2.1.17 0EH IAS-Paging Request Ack 4.1.1.12Paging Control Record 4.2.1.13 0AH IAS-Paging Request 4.1.1.11 IAS-Page 4.1.1.13PMIP Root Key 4.2.1.9 06H IAS-SRNC Transfer Response 4.1.1.6 RouteOpenRequest 4.2.1.6 03H IAS-Session Information Request 4.1.1.1 IAS-SRNC Transfer Request 4.1.1.5 Sector Parameters 4.2.1.15 0CH IAS-Neighbor Discovery Report 4.1.1.16Session Request Record 4.2.1.16 0DH IAS-Session Information Request 4.1.1.1 IAS-SRNC Transfer Request 4.1.1.5 Session Signature 4.2.1.7 04H IAS-Session Information Request 4.1.1.1 IAS-Session Information Update

Request 4.1.1.3

3GPP2 A.S0020-0 v1.0

4-16




4.1.1.4

IAS-SRNC Transfer Request 4.1.1.5 IAS-UATI Update 4.1.1.9 Session State Information Record 4.2.1.19 A1H IAS-Session Information Response 4.1.1.2 IAS-Session Information Update

Request 4.1.1.3

IAS-SRNC Transfer Response 4.1.1.6 IAS-Paging Request 4.1.1.11SRNC Record 4.2.1.12 09H IAS-Session Information Response 4.1.1.2 IAS-SRNC Transfer Response 4.1.1.6 IAS-UATI Update 4.1.1.9

1

4.2.1.3 IAS Message Type 2

The Message Type IE is used to indicate the version, type of message and provide for message correlation 3

on the IAS interface. 4

4.2.1.3 IAS Message Type

7 6 5 4 3 2 1 0 Octet

Version 1

Message Type 2

(MSB) Correlation ID = <any value> 3

4

5

(LSB) 6

Version This field shall be set to 01H in this specification for all messages except the 5

IAS-Reject message. The Version field in the IAS-Reject message shall be set to 6

00H by the sending entity and ignored by the receiving entity. Refer to section 7

1.6, for guidelines on when this field is to be incremented. 8

Message Type This field is coded as follows. 9

Table 4.2.1.3-1 Message Type 10

Message Name IAS Message Type Section Reference IAS-Reject 01H 4.1.1.18 IAS-Session Information Request 02H 4.1.1.1 IAS-Session Information Response 03H 4.1.1.2 IAS-Session Information Update Request 04H 4.1.1.3 IAS-Session Information Update Response 05H 4.1.1.4 IAS-SRNC Transfer Request 06H 4.1.1.5

3GPP2 A.S0020-0 v1.0

4-17

Message Name IAS Message Type Section Reference IAS-SRNC Transfer Response 07H 4.1.1.6 IAS-Session Release 08H 4.1.1.7 IAS-Session Release Ack 09H 4.1.1.8 IAS-UATI Update 0AH 4.1.1.9 IAS-UATI Update Ack 0BH 4.1.1.10 IAS-Paging Request 0CH 4.1.1.11 IAS-Paging Request Ack 0DH 4.1.1.12 IAS-Page 0EH 4.1.1.13 IAS-Page Ack 0FH 4.1.1.14 IAS-Neighbor Discovery Request 10H 4.1.1.15 IAS-Neighbor Discovery Report 11H 4.1.1.16 IAS-Neighbor Discovery Report Ack 12H 4.1.1.17

Correlation ID This field contains an ID that allows an entity to correlate a request-response pair 1

of messages. The value is a manufacturer concern. 2

3

4.2.1.4 AT Identity 4

This IE includes identity and related information of the AT. 5

4.2.1.4 AT Identity

7 6 5 4 3 2 1 0 Octet

IAS IEI = [01H] 1

Length = 15H, 11H 2

AT Identity Type = 01H, 02H 3

AT Identity variable

Length This field contains the number of octets in this IE following this field as a binary 6

number. 7

8

AT Identity Type This field contains the identity type for a specific AT. This field is coded as 9

follows. 10

Table 4.2.1.4-1 AT Identity - Type of Identity Coding 11

Values AT Identity Meaning

01H SSID (128+32 bits) 02H UATI (128 bits)

All other values are reserved.

12

When AT Identity Type is set to ‘01H(SSID)’, AT Identity field shall be coded as follows. 13

AT Identity When the AT Identity Type is set to ‘01H (SSID)’, the AT Identity field is set to 14

the terminal identifier associated with the AT and is coded as follows. Note that 15

3GPP2 A.S0020-0 v1.0

4-18

the SSID field is associated with the session and does not change throughout the 1

lifetime of session. 2

7 6 5 4 3 2 1 0 Octet

(MSB) UATI = <any value> 4

… …

(LSB) 19

(MSB) Time Stamp = <any value> 20

21

22

(LSB) 23

3

UATI This is set to the initial 128-bit terminal identifier associated with the AT. Refer to [1]. 4

Time Stamp This field contains the time stamp of when the session is created. The value is the 32 5

MSBs of the NTP timestamp format. 6

7

When the AT Identity Type is set to ‘02H (UATI)’, the AT Identity field shall be coded as follows. 8

7 6 5 4 3 2 1 0 Octet


… …

(LSB) 19

UATI This is set to the 128-bit terminal identifier that was assigned to the AT by the serving 9

SRNC. Refer to [1]. 10

11

4.2.1.5 Network Identity (Endpoint ID) 12

This IE contains the network identity of the sending and receiving ANRIs. 13

4.2.1.5 Network Identity (Endpoint ID)

7 6 5 4 3 2 1 0 Octet

IAS IEI = [02H] 1

Length = <variable> 2

Network Identity - Sender variable

Network Identity - Receiver variable


number. 15

Network Identity - n These fields contain the network address of the sending and receiving entities and 16

are coded as follows. 17

7 6 5 4 3 2 1 0 Octet

Network Identity Type = 01H 3

3GPP2 A.S0020-0 v1.0

4-19

7 6 5 4 3 2 1 0 Octet

Network Identity variable

Network Identity Type This field identifies the type of network identify provided in the following field 1

and is coded as follows. 2

Table 4.2.1.5-1 Network Identity Type - Type of Identity Coding 3

Values Network Identity Meaning

01H ANID All other values are reserved.

Network Identity When the Network Identity Type of the sender or receiver is set to ‘01H (ANID)’, 4

the Network Identity field is coded as follows. 5

7 6 5 4 3 2 1 0 Octet

(MSB) ANID = <any value> 4

… …

(LSB) 19

ANID This is the 128-bit Access Network Identifier for the ANRI. 6

7

4.2.1.6 RouteOpenRequest 8

This IE contains information for the air interface RouteOpenRequest message that triggered the session 9

information request or SRNC transfer request. 10

4.2.1.6 RouteOpenRequest

7 6 5 4 3 2 1 0 Octet

IAS IEI = [03H] 1


Access/ Tunneled

= [0,1]

RoR Reason = <any value>

Emergency Ind =

[0,1]

Auth Tag Incl = [0,1]

Reserved = [0]

3

Authentication Tag Blob Length = <any value> 4

(MSB) Authentication Tag Blob = <any value> 5

… …

(LSB) n

(MSB) Session Anchor Route ID = <any value> (LSB) Reserved = 0

n+1

Length This field contains the number of octets in this IE following this 11

field as a binary number. 12

Access/Tunneled This field is set to ‘0’ if the RouteOpenRequest message was 13

received during access procedure. Otherwise this field is set to 14

‘1’ if the RouteOpenRequest message was tunneled to the ANRI. 15

RoR Reason This field includes the reason for the route open request. Refer to 16

[1]. 17

3GPP2 A.S0020-0 v1.0

4-20

Emergency Ind This field contains the emergency status of the route open 1

request as indicated by the AT. Refer to [1]. 2

Auth Tag Incl This field shall be set to ‘1’ if Authentication Tag Length, 3

Authentication Tag Blob and Session Anchor Route ID are 4

included. Otherwise this field shall be set to ‘0’. Refer to [1]. 5

Authentication Tag Blob Length If the Auth Tag Incl bit is set to ‘1’ this field shall be included 6

and set to the AuthenticationTagBlobLength from the Route-7

OpenRequest message. Refer to [1]. Otherwise this field shall be 8

omitted. 9

Authentication Tag Blob If the Auth Tag Incl bit is set to ‘1’ this field shall be included 10

and set to the AuthenticationTagBlob from the RouteOpen-11

Request message. Refer to [1]. Otherwise this field shall be 12

omitted. 13

Session Anchor Route ID If the Auth Tag Incl bit is set to ‘1’ this field shall be included 14

and set to the Session Anchor Route ID from the RouteOpen-15

Request message. Refer to [1]. Otherwise this field and the 16

associated Reserved field in bit position ‘0’ shall be omitted. 17

18

4.2.1.7 Session Signature 19

This IE contains the session signature of the AT for which the session information is being requested. 20

4.2.1.7 Session Signature

7 6 5 4 3 2 1 0 Octet

IAS IEI = [04H] 1

Length = 02H 2

(MSB) Session Signature = <any value> 3

(LSB) 4


number. 22

Session Signature This field contains the session signature for the AT. Refer to [1]. 23

24

4.2.1.8 Cause 25

This IE contains the reason for which the message is being sent. 26

4.2.1.8 Cause

7 6 5 4 3 2 1 0 Octet

IAS IEI = [05H] 1

Length = 01H 2 Cause Value = <any value> 3


number. 28

Cause value This field indicates the reason for occurrence of a particular event and is coded as 29

follows. 30

3GPP2 A.S0020-0 v1.0

4-21

Table 4.2.1.8-1 Cause Value - Type of Identity Coding 1

Hex Value Cause Value Meaning

01H Successful event 02H Requested session not found 03H Authentication failure 04H Requested session locked 05H Session Anchor Route ID mismatch 07H Invalid session signature 08H UATI has changed 09H AT not recognized 0AH SRNC busy - Retry later 0BH Requesting ANRI not in Route Set 0DH Packet data session release 0EH Power down 0FH Normal operation 10H Session release 11H Stale message 12H SRNC did not page this UATI 13H Request rejected - reason unspecified E0H Reject - version not supported E1H Reject - message type not supported E2H Reject - required IE is missing E3H Reject - reason unspecified


Table 4.2.1.8-2 Allowable Cause Values by Message 2

Message Section Allowable Cause Values

IAS-Session Information Response 4.1.1.2 01H, 02H, 03H, 05H, 0BH, 11H, 12H, 13H IAS-Session Information Update Response 4.1.1.4 01H, 02H, 04H, 07H, 08H, 0BH, 13H IAS-SRNC Transfer Response 4.1.1.6 01H, 02H, 03H, 04H, 06H, 0AH, 0BH, 11H,

13H IAS-Session Release 4.1.1.7 03H, 0DH, 0EH IAS-Paging Request 4.1.1.11 0FH, 10H IAS-Paging Request Ack 4.1.1.12 01H, 09H, 13H IAS-Reject 4.1.1.18 E0H, E1H, E2H, E3H IAS-UATI Update Ack 4.1.1.10 01H, 09H

3

4.2.1.9 PMIP Root Key 4

This IE contains the link identifier of the sending entity. 5

3GPP2 A.S0020-0 v1.0

4-22

4.2.1.9 PMIP Root Key

7 6 5 4 3 2 1 0 Octet

IAS IEI = [06H] 1

Length = 20H 2

(MSB) PMN-AN-RK1 3

… …

(LSB) 34


number. 2

PMN-AN-RK1 This field contains the 256 bit PMIP signaling message protection key. Refer to 3

[1]. 4

4.2.1.10 Neighbor Connection Information 5

This IE contains the addresses of the possible network element connections used by the neighbor. 6

4.2.1.10 Neighbor Connection Information

7 6 5 4 3 2 1 0 Octet

IAS IEI = [07H] 1

Length 2

Connection Information-1 variable

… …

Connection Information-m variable

Length This field contains the number of octets in this IE following this field as 7

a binary number. 8

Connection Information These fields contain the network address information. 9

7 6 5 4 3 2 1 0 Octet

Address Type j

Address Length j+1

Address-1 Variable

… …

Address-n Variable

Address Type This field identifies the type of address provided in the following field 10


12

Table 4.2.1.10-1 SRNC Address - Type of Identity Coding 13

Values SRNC Address Meaning

01H SRNC IPv4

02H AGW IPv4 All other values are reserved.

3GPP2 A.S0020-0 v1.0

4-23

Address Length This field contains the number of octets in the this IE following this field 1

as a binary number. 2

Address-n When the Address Type is set to ‘01H (SRNC IPv4)’, the Address field 3

is coded as follows. 4

7 6 5 4 3 2 1 0 Octet

(MSB) SRNC IPv4 Address j+1

j+2

j+3

(LSB) j+4

SRNC IPv4 Address This is the 32 bit IPv4 address of the SRNC. 5

When the Address Type is set to ‘02H (AGW IPv4)’, the Address field is 6

coded as follows 7

7 6 5 4 3 2 1 0 Octet

(MSB) AGW IPv4 Address j+1

j+2

j+3

(LSB) j+4

AGW IPv4 Address This is the 32 bit IPv4 address of the AGW. 8

4.2.1.11 New UATI 128 9

This IE is set to the new terminal identifier associated with the AT. 10

4.2.1.11 New UATI 128

7 6 5 4 3 2 1 0 Octet

IAS IEI = [08H] 1

Length = 10H 2


… …

(LSB) 18


number. 12

UATI This is set to the new 128-bit terminal identifier associated with the AT. 13

14

4.2.1.12 SRNC Record 15

This IE contains all the information needed for another ANRI to become SRNC when an ANRI is added 16

into the route set. 17

4.2.1.12 SRNC Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [09H] 1

3GPP2 A.S0020-0 v1.0

4-24

4.2.1.12 SRNC Record

7 6 5 4 3 2 1 0 Octet

Length = 15H 2

SRNC Record Type 3

SRNC Record Length 4

SRNC Record variable

SRNC Record Type This field identifies the type of SRNC record provided in the following 1

fields and is coded as follows. 2

Table 4.2.1.12-1 SRNC Record - Type of Identity Coding 3

Values SRNC Record Meaning

01H SRNC Record Type 1 All other values are reserved.

4

SRNC Record Length This field contains the number of octets in the SRNC Record field as a 5

binary number. 6

SRNC Record When the SRNC Record Type is set to ‘01H (SRNC Record Type 1)’, 7

the SRNC Record field is coded as follows. 8

(MSB) Session Signature = <any value> n

(LSB) n+1

(MSB) UATI = <any value> n+2

… …

(LSB) n+17

UATI_SeqNo n+18

Data Capable = [0,1]

(MSB) Largest Route Counter n+19

(LSB) n+20

(MSB) Access Counter = <any value> n+21

(LSB) n+22


a binary number. 10

Session Signature This field contains the session signature for the AT. Refer to [1]. 11

UATI This is set to the new 128-bit terminal identifier associated with the AT. 12

UATI_SeqNo This field is initially set to zero and incremented by one for each new 13

UATI assignment. 14

Data Capable This filed is set to ‘0’ if the SRNC is not data capable. Otherwise this 15

field is set to ‘1’ to indicate that the SRNC is data capable. 16

Largest Route Counter The field contains the largest value of the 15 bit RouteCounter that the 17

SRNC has received. Refer to section 2.2.3.4. 18

3GPP2 A.S0020-0 v1.0

4-25

Access Counter The field contains the 16 bit Access Counter maintained by the SRNC 1

for the ATs session. 2

3

4.2.1.13 Paging Control Record 4

This IE is sent to convey control information for a page. 5

4.2.1.13 Paging Control Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [0AH] 1

Length = 02H, 03H 2

Reserved = 0

Reserved = 0

Reserved = 0

Reserved = 0

Reserved = 0

Local Fanout

Required = 0,1]

Message Priority Included = [0,1]

ReservationLabelIncluded =

[0,1]

3

Message Priority = <any value> m

ReservationLabel = <any value> n



Local Fanout Required If this IE is part of the IAS-Paging Request message, this field 8

shall be set to ‘0’. 9

If this IE is part of the IAS-Page message, this field indicates 10

whether the receiver is required to determine the paging area and 11

to forward the IAS-Page message to eBSs within the paging 12

area, where the receiver determines the paging area based on its 13

internal databases and the registration radius that is included in 14

this message. This field is set to ‘0’ if forwarding is not required 15

and is set to ‘1’ if forwarding is required. The receiver should set 16

the Local Fanout Required field to ‘0’ when forwarding this 17

message. 18

Message Priority Included This field indicates whether the Message Priority field is 19

included. This field is set to ‘1’ if the Message Priority field is 20

included, otherwise this field is set to ‘0’. 21

ReservationLabelIncluded This field indicates whether the ReservationLabel is included in 22

this IE. 23

Message Priority This field contains the Message Priority which the eBS is to use 24

to transmit the page message. This field is an 8 bit binary 25

number between 0 and 255 where the lower values indicate 26

higher priorities. This value is given as a guideline for the eBS. 27

ReservationLabel The sender may set this field to indicate the ReservationLabel of 28

the forward link packet that caused the access terminal to be 29

paged. The ReservationLabel is defined in [1]. 30

31

4.2.1.14 Neighbor Discovery Record 32

This IE contains the information that the receiving ANRI needs to communicate with and to configure its 33

air interface signaling information, such as neighbor fields SectorParameters, with the sending ANRI. 34

3GPP2 A.S0020-0 v1.0

4-26

4.2.1.14 Neighbor Discovery Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [0BH] 1


IOS Interface Identity Count = <any value> 3

IOS Interface Identity -1 variable

… …

IOS Interface Identity -n variable

Neighbor Network Identity Count = <any value> k

Neighbor Network Identity - 1 variable

… …

Neighbor Network Identity - p variable


a binary number. 2

IOS Interface Identity Count This field indicates the number of IOS Interface Identities in this IE. 3

IOS Interface Identity This field contains interface information and is coded as follows. 4

7 6 5 4 3 2 1 0 Octet

IOS Interface Number = 01H, 02H, 03H j

IOS Interface Version = <any value> j+1

5

IOS Interface Number This field is set to the interface for which the following protocol inform-6

ation is relevant and is coded as follows. 7

Table 4.2.1.14-1 IOS Interface Identity - Type of Identity Coding 8

Values IOS Interface Meaning Section Reference

01H IAS 2.1 02H IPT 2.2 03H LLT 2.3


9

IOS Interface Version This field contains an interface version supported by the sending entity. 10

The highest currently supported version for each IOS interface is defined 11

in the referenced section in Table 4.2.1.14-1. 12

Neighbor Network Identity 13

Count This field indicates the number of Neighbor Network Identities in this IE. 14

Neighbor Network Identity These fields contain the network address for neighbors of the sending 15

ANRI and are coded as follows. 16

3GPP2 A.S0020-0 v1.0

4-27

7 6 5 4 3 2 1 0 Octet

Network Identity Type = 01H k+1

Network Identity Length = 10H k+2

Network Identity = <any value> variable

Network Identity Type This field identifies the type of network identify provided in the 1

following field and is coded as follows. 2

Table 4.2.1.14-2 Network Identity - Type of Identity Coding 3



Network Identity Length This field contains the number of octets in the Network Identity field as a 4

binary number. 5

Network Identity When the Network Identity Type is set to ‘01H (ANID)’, the Network 6

Identity field is coded as follows. 7

7 6 5 4 3 2 1 0 Octet

(MSB) ANID = <any value> k+3

… …

(LSB) k+18

ANID This is the 128-bit Access Network Identifier for the Neighboring ANRI. 8

4.2.1.15 Sector Parameters 9

This IE contains the encapsulated air interface Sector Parameters message. 10

4.2.1.15 Sector Parameters

7 6 5 4 3 2 1 0 Octet

IAS IEI = [0CH] 1


Sector Parameters Count = <variable> 3

(MSB) Sector Parameters = <any value> 4

… …

(LSB) n


number. 12

Sector Parameters Count 13

This field indicates the number of Sector Parameters in this IE. 14

Sector Parameters This field contains the SectorParameters message. Refer to [1]. 15

16

4.2.1.16 Session Request Record 17

This IE contains miscellaneous information related to session request. 18

3GPP2 A.S0020-0 v1.0

4-28

4.2.1.16 Session Request Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [0DH] 1

Length = 02H 2

Derived MSK

Required

(MSB) Route Counter 3

(LSB) 4


a binary number. 2

Derived MSK Required This field when set to ‘1’ indicates that the sending entity requires a 3

derived master session key from the SRNC. Refer to [2]. Otherwise this 4

field is set to ‘0’. 5

Route Counter This field contains the Route Counter from the RouteOpenRequest 6

message. Refer to [1]. 7

8

4.2.1.17 Page Attempt Timer 9

This IE is used to indicate to the DAP the duration that the SRNC will attempt to page the AT without 10

receiving additional IAS-Paging Request message from the DAP. 11

4.2.1.17 Page Attempt Timer

7 6 5 4 3 2 1 0 Octet

IAS IEI = [0EH] 1

Length = [02H] 2

(MSB) Page Attempt Timer Value = [0000H - FFFFH] 3

(LSB) 4


a binary number. 13

Page Attempt Timer Value This field contains the duration that the SRNC will attempt to page the 14

AT without receiving additional IAS-Paging Request message from the 15

DAP. The value of this field is in unit of milliseconds. 16

17

4.2.1.18 IAS DAP Record 18

This IE contains AGW information for each AGW to which the AT connects. For each AGW, if the DAP 19

exists, this IE also contains information about the DAP. 20

4.2.1.18 IAS DAP Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [A0H] 1

(MSB) Length = <variable> 2

(LSB) 3

IAS AGW Record Count = <any value> 4

3GPP2 A.S0020-0 v1.0

4-29

4.2.1.18 IAS DAP Record

7 6 5 4 3 2 1 0 Octet

IAS AGW Record-1 variable

… …

IAS AGW Record-n variable


a binary number. 2

IAS AGW Record Count This field indicates the number IAS AGW Records in this IE. 3

IAS AGW Record-n These fields contain the information required to communicate with each 4

AGW to which a DAP is attached. The AGW Information-n for a given 5

AGW may be omitted after the DAP for an AGW has been removed 6

from the route set and no other ANRI sends an IPT-Notification message 7

indicating that it is the DAP for that AGW for an implementation-8

specific duration. This field is coded as follows. 9

7 6 5 4 3 2 1 0 Octet

IAS AGW Record Type = 01H h

IAS AGW Record Length = <any value> h+1

IAS AGW Record variable

IAS AGW Record Type This field identifies the type of IAS AGW Record provided and is coded 10

as follows. 11

Table 4.2.1.18-1 IAS AGW Record - Type of Identity Coding 12

Values IAS AGW Record Meaning

01H IAS AGW Record Type 1 All other values are reserved.

IAS AGW Record Length This field contains the number of octets in the IAS AGW Record field as 13

a binary number. 14

IAS AGW Record When the IAS AGW Record Type is set to ‘01H (IAS AGW Record 15

Type 1)’, the IAS AGW Record field is coded as follows. 16

17

7 6 5 4 3 2 1 0 Octet

IAS AGW Address Type = <any value> h

IAS AGW Address Length = <any value> h+3

IAS AGW Address = <any value> variable

EAP NAI Length i

(MSB) EAP NAI i+1

…

LSB j

AAA-Session-ID Length j+1

(MSB) AAA-Session-ID j+2

3GPP2 A.S0020-0 v1.0

4-30

7 6 5 4 3 2 1 0 Octet

…

LSB k

(MSB) LinkID = <any value> k+1

…

(LSB) k+8

DAP Information Type = <any value> m

DAP Information Length m+1

DAP Information = <any value> variable

PMN-AN-HA1 Key Length = <any value> n

(MSB) PMN-AN-HA1 Key = <any value> n+1

… …

(LSB) p

Reserved = 0000 (MSB) PMN-AN-HA1 Sequence Number

p+1

p+2

p+3

(LSB) p+4

1

IAS AGW Address Type This field identifies the type of IAS AGW address provided and is coded 2

as follows. 3

Table 4.2.1.18-2 IAS AGW Address - Type of Identity Coding 4

Values IAS AGW Address Meaning

01H IPv4 All other values are reserved.

IAS AGW Address Length This field contains the number of octets in the IAS AGW Address field 5


IAS AGW Address When the IAS AGW Address Type is set to ‘01H (IPv4)’, the IAS AGW 7

Address field is coded as follows. 8

7 6 5 4 3 2 1 0 Octet

(MSB) AGW IPv4 Address = <any value> h+4

h+5

h+6

(LSB) h+7

AGW IPv4 Address This is the 32 bit IPv4 address of the AGW. 9

EAP NAI Length This contains the number of octets in the EAP NAI field as a binary 10

number. 11

3GPP2 A.S0020-0 v1.0

4-31

EAP NAI This field contains the NAI received in EAP Identity Response message 1

at the SRNC. 2

AAA-Session-ID Length This contains the number of octets in the AAA-Session-ID field as a 3

binary number. 4

AAA-Session-ID This field contains the Session-ID of the AAA. 5

LinkID This field contains the 64-bit link identifier of the AGW for this record. 6

DAP Information Type This field identifies the type of DAP Information provided and is coded 7

as follows. 8

Table 4.2.1.18-3 DAP Information - Type of Identity Coding 9

Values DAP Information Meaning

01H Null 02H ANID


DAP Information Length This field contains the number of octets in the DAP Information field as 10

a binary number. 11

DAP Information When the DAP for the AGW does not exist, the DAP Information field is 12

set to ‘01H (Null)’ and the DAP Information field is not included. 13

When the DAP Information Type is set to ‘02H (ANID)’, the DAP 14

Information field is coded as follows. 15

7 6 5 4 3 2 1 0 Octet

(MSB) ANID = <any value> m+2

… …

(LSB) m+17

(MSB) GRE Key = <any value> m+18

m+19

m+20

(LSB) m+21

(MSB) DAP Time Stamp = <any value> m+22

… …

(LSB) m+29

Reserved = 000000 DAP Counter = <any value>

m+30

ANID This is the 128-bit Access Network Identifier for the DAP. 16

GRE Key This field contains the 32 bit GRE key used between the DAP 17

and the AGW. 18

DAP Time Stamp This field contains the 64 bit time stamp used between the DAP 19

and the AGW. 20

DAP Counter This field contains the two bit DAP Counter used for in-order 21

delivery. 22

3GPP2 A.S0020-0 v1.0

4-32

PMN-AN-HA1 Key Length This field contains the number of octets in the PMN-AN-HA1 1

Key field (only) as a binary number. If this field is set to zero, 2

then the PMN-AN-HA1 Key field as well as the PMN-AN-HA1 3

Sequence Number field and the associated four bit reserved field 4

are not included. 5

PMN-AN-HA1 Key If the PMN-AN-HA1 Key Length field is a non zero value, this 6

field contains the key to be used in the PMIP Registration 7

Request. Refer to [2]. Otherwise if the PMN-AN-HA1 Key 8

Length field is set to zero, this field is not included. 9

PMN-AN-HA1 Sequence Number If the PMN-AN-HA1 Key Length field is a non zero value, this 10

field contains the 28 bit sequence number associated with the 11

PMN-AN-HA1 key. Otherwise if the PMN-AN-HA1 Key 12

Length field is set to zero, this field is not included. 13

14

4.2.1.19 Session State Information Record 15

This IE is used to send all the parameter records associated with a (PersonalityID, ProtocolType) pair in 16

the UMB session as specified in [1]. 17

4.2.1.19 Session State Information Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [A1H] 1


(LSB) 3

(MSB) Session State Information Record = <any value> 4

… …

(LSB) n



Session State Information Record This field contains all the parameter records associated with a 20

(PersonalityID, ProtocolType) pair in the UMB session as 21

specified in [1]. Note that PersonalityID is contained within the 22

SSIR field. Air interface protocol attributes with default values 23

shall not be sent to the target node. The target node shall use the 24

default value specified in [1] for any attribute missing from the 25

SSIR. 26

When sending UMB session information in a message, multiple 27

instances of this IE are included. Static attributes with non-28

default values shall be included in the first SSIR IE for the 29

corresponding protocol type and shall be omitted from all 30

subsequent SSIR IEs in the message that are for the same 31

protocol type because the value of a static attribute is the same 32

across all personalities. 33

34

4.2.1.20 Network Session Record 35

This IE contains network specific session information for the AT. 36

3GPP2 A.S0020-0 v1.0

4-33

4.2.1.20 Network Session Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [A2H] 1


(LSB) 3

Network Session Info Type = 01H 4

Network Session Info variable


a binary number. 2

Network Session Info Type This field identifies the type of network session information provided in 3

the following field and is coded as follows. 4

Table 4.2.1.20-1 Network Session Info - Type of Identity Coding 5

Values Network Session Info Meaning

01H Subscriber QoS Profile All other values are reserved.

Network Session Info When the Network Session Info Type is set to ‘01H (Subscriber QoS 6

Profile)’, the Network Session Info field is coded as follows. 7

7 6 5 4 3 2 1 0 Octet

Subscriber QoS Profile Length j

j+1

(MSB) Subscriber QoS Profile = <any value> j+2

… …

(LSB) k

Subscriber QoS Profile This field contains the Subscriber QoS Profile. Refer to [2]-300. 8

4.2.1.21 IAS Reject Record 9

This IE contains information regarding the rejected message. The IE may also contain the versions 10

supported for communicating with the sending eBS/SRNC. 11

4.2.1.21 IAS Reject Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [A3H] 1


(LSB) 3

Version Length = <variable> 4

Version-1 5

… …

Version-n n

(MSB) Rejected Message = <variable> n+1

… …

3GPP2 A.S0020-0 v1.0

4-34

4.2.1.21 IAS Reject Record

7 6 5 4 3 2 1 0 Octet

(LSB) p


a binary number. 2

Version Length If the Cause IE of the IAS-Reject message is set to “Reject - version not 3

supported”, this field contains the number of octets included for Version 4

in this IE as a binary number. Otherwise this field is set to zero. 5

Version-n This field is included for non-zero Version lengths and contains one 6

version supported by the sending eBS/SRNC. 7

Message Rejected This field contains the rejected message. 8

9

4.2.1.22 AIS Paging Information Record 10

This IE is used to send UMB air interface information that enables the eBS to transmit the page over the 11

air in accordance with AT parameter. 12

4.2.1.22 AIS Paging Information Record

7 6 5 4 3 2 1 0 Octet

IAS IEI = [A4H] 1

(MSB) Length = [variable] 2

(LSB) 3

(MSB) AIS Paging Information Blob 4

… …

(LSB) n


a binary number. 14

AIS Paging Information Blob This field contains the air interface protocol attributes and associated 15

public data required by the receiving eBS to perform the paging 16

operation. The format is as specified in Annex A. 17

18

4.2.2 IPT IE Definitions 19

4.2.2.1 IPT IE Identifiers 20

The following table lists all the IEs that make up the IPT messages defined in section 4.1.2. The table 21

includes the Information Element Identifier (IEI) coding which distinguishes one IE from another. The 22

table also includes a section reference indicating where the IE coding can be found. 23

24

Element Name IEI (Hex) Reference IPT Message Type none 4.2.2.3 AT Identity 01H 4.2.2.4 Network Identity (Endpoint ID) 02H 4.2.2.5

3GPP2 A.S0020-0 v1.0

4-35

Element Name IEI (Hex) Reference Notification Record 03H 4.2.2.6 IPT-DAP Record 04H 4.2.2.7 LinkID 05H 4.2.2.8 Access Counter 06H 4.2.2.9 Cause 07H 4.2.2.10 Notification Correlation ID 08H 4.2.2.11 Flush Information 09H 4.2.2.12 Message Timestamp 0AH 4.2.2.13 IPT Reject Record A0H 4.2.2.14

1

4.2.2.2 Cross Reference of IEs with Messages 2

The following table provides a cross reference between the IEs and the messages defined in this specifi-3

cation. 4



Access Counter 4.2.2.9 06H IPT-Notification 4.1.2.1 AT Identity 4.2.2.4 01H IPT-Notification 4.1.2.1 IPT-Notification Ack 4.1.2.2 IPT-Flush 4.1.2.4 Cause 4.2.2.10 07H IPT-Reject 4.1.2.3 IPT-Notification Ack 4.1.2.2 Flush Information 4.2.2.12 09H IPT-Notification Ack 4.1.2.2 IPT-Flush 4.1.2.4 IPT-DAP Record 4.2.2.7 04H IPT-Notification 4.1.2.1 IPT Message Type 4.2.2.3 none IPT-Notification 4.1.2.1 IPT-Notification Ack 4.1.2.2 IPT-Flush 4.1.2.4 IPT-Reject 4.1.2.3 IPT Reject Record 4.2.2.14 A0H IPT-Reject 4.1.2.3 LinkID 4.2.2.8 05H IPT-Notification 4.1.2.1 Message Timestamp 4.2.2.13 0AH IPT-Notification 4.1.2.1 Network Identity (Endpoint ID) 4.2.2.5 02H IPT-Notification 4.1.2.1 IPT-Notification Ack 4.1.2.2 IPT-Reject 4.1.2.3 IPT-Flush 4.1.2.4 Notification Correlation ID 4.2.2.11 08H IPT-Flush 4.1.2.4 Notification Record 4.2.2.6 03H IPT-Notification 4.1.2.1

3GPP2 A.S0020-0 v1.0

4-36



IPT-Notification Ack 4.1.2.2

1

4.2.2.3 IPT Message Type 2

The Message Type IE is used to indicate the version, type of message and provide for message correlation 3

on the IPT interface. 4

4.2.2.3 IPT Message Type

7 6 5 4 3 2 1 0 Octet

Version 1

Message Type 2

(MSB) Correlation ID = <any value> 3

4

5

(LSB) 6

Version This field shall be set to 01H in this specification for all messages except the 5

IPT-Reject message. The Version field in the IPT-Reject message shall be set to 6

00H by the sending entity and ignored by the receiving entity. Refer to section 7

1.7, for guidelines on when this field is to be incremented. 8

Message Type This field is coded as follows. 9

Table 4.2.2.3-1 Message Type 10

Message Name IPT Message Type Section Reference IPT-Reject 01H 4.1.2.3 IPT-Notification 02H 4.1.2.1 IPT-Notification Ack 03H 4.1.2.2 IPT-Flush 04H 4.1.2.4

Correlation ID This field contains a value that allows an entity to correlate a request-response 11

pair of messages. The value is a manufacturer concern. 12

4.2.2.4 AT Identity 13

This IE includes identity and related information of the AT. 14

4.2.2.4 AT Identity

7 6 5 4 3 2 1 0 Octet

IPT IEI = [01H] 1

Length = 15H, 11H 2

AT Identity Type = 01H, 02H, 03H 3

AT Identity variable

3GPP2 A.S0020-0 v1.0

4-37


number. 2

AT Identity Type This field contains the identity type for a specific AT. This field is coded as 3

follows. 4

Table 4.2.2.4-1 AT Identity - Type of Identity Coding 5

Values AT Identity Meaning

01H SSID (128+32 bits) 02H UATI (128 bits) 03H RATI (128 bits)


6

When the AT Identity Type is set to ‘01H (SSID)’, the AT Identity field shall be coded as follows. 7

AT Identity When the AT Identity Type is set to ‘01H (SSID)’, the AT Identity field is set to 8

the terminal identifier associated with the AT and is coded as follows. Note that 9

the SSID field is associated with the session and does not change throughout the 10

lifetime of session. 11

7 6 5 4 3 2 1 0 Octet


… …

(LSB) 19

(MSB) Time Stamp = <any value> 20

21

22

(LSB) 23

12

UATI This is set to the 128-bit terminal identifier that was assigned to the AT when the session 13

was created. Refer to [1]. 14

Time Stamp This field contains the time stamp of when the session is created. The value is the 32 15

MSBs of the NTP timestamp format. 16

17

When the AT Identity Type is set to ‘02H (UATI)’, the AT Identity field shall be coded as follows. 18

AT Identity When the AT Identity Type is set to ‘02H (UATI)’, the AT Identity field is set to the 19

terminal identifier associated with the AT and is coded as follows. The UATI coded in 20

this field is the terminal identifier that the serving SRNC assigned. 21

7 6 5 4 3 2 1 0 Octet


… …

(LSB) 19

22

3GPP2 A.S0020-0 v1.0

4-38

UATI This is set to the 128-bit terminal identifier that was assigned to the AT by the serving 1

SRNC. Refer to [2]. 2

When the AT Identity Type is set to ‘03H (RATI)’, the AT Identity field shall be coded as follows. 3

AT Identity When the AT Identity Type is set to ‘03H (RATI)’, the AT Identity field is set to the 4

terminal identifier associated with the AT and is coded as follows. The RATI coded in 5

this field is the terminal identifier that the AT sent to open a route with the eBS. 6

7 6 5 4 3 2 1 0 Octet

(MSB) RATI 4

… …

(LSB) 19

7

RATI This field is set to the 128-bit terminal identifier that the AT uses before its session is 8

created at the SRNC. Refer to [2]. 9

10

4.2.2.5 Network Identity (Endpoint ID) 11

This IE contains the network identity of the sending and receiving ANRIs. 12

4.2.2.5 Network Identity (Endpoint ID)

7 6 5 4 3 2 1 0 Octet

IPT IEI = [02H] 1


Network Identity - Sender variable

Network Identity - Receiver variable


number. 14

Network Identity These fields contain the network address of the sending and receiving entities and 15

are coded as follows. 16

Network Identity Type 3

Network Identity variable

Network Identity Type This field identifies the type of network identify provided in the following field 17


Table 4.2.2.5-1 Network Identity - Type of Identity Coding 19



Network Identity When the Network Identity Type of the sender or receiver is set to ‘01H (ANID)’, 20

the Network Identity field is coded as follows. 21

3GPP2 A.S0020-0 v1.0

4-39

(MSB) ANID = <any value> 4

… …

(LSB) 19

ANID This is the 128-bit Access Network Identifier for the AN. 1

2

4.2.2.6 Notification Record 3

This IE contains sending entity’s notification to the receiving entity. 4

4.2.2.6 Notification Record

7 6 5 4 3 2 1 0 Octet

IPT IEI = [03H] 1

Length = 01H 2

Notification Info = 01H-0AH 3

5


number. 7

Notification Info This field indicates the notification being provided in the message and is coded 8

as follows. 9

Table 4.2.2.6-1 Notification Info 10

Values Notification Info Meaning

01H Sender is now the current FLSE 02H Sender is now the current RLSE 03H Sender is now the current FLSE/RLSE 04H Sending ANRI no longer considers receiving ANRI to be FLSE 05H AT Initiated connection close 06H AN Initiated connection close 07H Connection lost 08H Sender was the previous FLSE 09H Sender was the previous RLSE 0AH Sender was the previous FLSE/RLSE


11

Table 4.2.2.6-2 Notification Info 12

Message Section Allowable Notification Info

IPT-Notification 4.1.2.1 01H, 02H, 03H, 04H, 05H, 06H IPT-Notification Ack 4.1.2.2 01H, 07H, 08H, 09H, 0AH

13

3GPP2 A.S0020-0 v1.0

4-40

4.2.2.7 IPT-DAP Record 1

This IE contains information for the AGW to which the DAP performed PMIP registration. 2

4.2.2.7 IPT-DAP Record

7 6 5 4 3 2 1 0 Octet

IPT IEI = [04H] 1


IPT AGW Record Type = 01H 3

IPT AGW Record Length = <any value> 4

IPT AGW Record variable


a binary number. 4

IPT AGW Record Type This field identifies the type of IPT AGW Record provided and is coded 5

as follows. 6

Table 4.2.2.7-1 IPT AGW Record - Type of Identity Coding 7

Values IPT AGW Record Meaning

01H IPT AGW Record Type 1 All other values are reserved.

IPT AGW Record Length This field contains the number of octets in the IPT AGW Record field as 8

a binary number. 9

IPT AGW Record When the IPT AGW Record Type is set to ‘01H (IPT AGW Record 10

Type 1)’, the IPT AGW Record field is coded as follows. 11

12

IPT AGW Address Type = 01H 5

IPT AGW Address Length = <any value> 6

IPT AGW Address variable

(MSB) GRE Key = <any value> n+1

n+1

n+2

(LSB) n+3

(MSB) PMIP Time Stamp = <any value> n+4

… …

(LSB) n+11

Reserved = 000000 DAP Counter = <any value>

n+12

(MSB) PMIP Lifetime = <any value> n+13

(LSB) n+14

13

IPT AGW Address Type This field indicates the type of IPT AGW address provided and is coded 14

as follows. 15

3GPP2 A.S0020-0 v1.0

4-41

Table 4.2.2.7-2 AGW Address Type - Type of Identity Coding 1

Values AGW Address Type Meaning

01H IPv4 All other values are reserved.

IPT AGW Address Length This field contains the number of octets in the IPT AGW Address field 2


IPT AGW Address When the IPT AGW Address Type is set to ‘01H (IPv4)’, the IPT AGW 4

Address field is coded as follows. 5

(MSB) AGW C-plane IPv4 Address = <any value> 7

8

9

(LSB) 10

(MSB) AGW U-plane IPv4 Address = <any value> 11

12

13

(LSB) 14

6

AGW C-plane IPv4 Address This field contains the IP address of the AGW to which the DAP 7

performed PMIP registration. This field shall be set to the C-plane IP 8

address of the AGW. 9

AGW U-plane IPv4 Address This field shall be set to the U-plane IP address of the AGW. 10

GRE Key This field contains the GRE Key (refer to [13]) used for the PMIP tunnel 11

with the AGW. 12

PMIP Times Stamp This 64 bit field contains the time stamp which is used in the successful 13

PMIP registration request. 14

DAP Counter This field contains the two bit DAP Counter used for in-order delivery. 15

PMIP Lifetime This 16 bit field contains the lifetime of the tunnel which is used in the 16

successful PMIP registration request. 17

18

4.2.2.8 LinkID 19

This IE contains the link identifier of the sending entity. 20

4.2.2.8 LinkID

7 6 5 4 3 2 1 0 Octet

⇒ LinkID: IPT IEI = [05H] 1

Length = 08H 2

(MSB) LinkID = <any value> 3

… …

(LSB) 10

3GPP2 A.S0020-0 v1.0

4-42

1

Length This field contains the number of octets in this IE following this field as a binary number. 2

LinkID This field contains the link identifier of the sending entity. Refer to [1]. 3

4.2.2.9 Access Counter 4

This IE contains the access counter associated with connection close message and is used to determine 5

message freshness. 6

4.2.2.9 Access Counter

7 6 5 4 3 2 1 0 Octet

⇒ Access Counter: IPT IEI = [06H] 1

Length = 02H 2

Reserved = 0

Access Counter = <any value> 3

4

7

Length This field contains the number of octets in this IE following this field as a binary number. 8

Access Counter This field contains the value of the Access Counter at the sender. Refer to section 2.2.3.1. 9

10

4.2.2.10 Cause 11

This IE contains the reason for which the message is being sent. 12

4.2.2.10 Cause

7 6 5 4 3 2 1 0 Octet

IPT IEI = [07H] 1

Length = 01H 2 Cause Value = <any value> 3


number. 14

Cause value This field indicates the reason for occurrence of a particular event and is coded as 15

follows. 16

Table 4.2.2.10-1 Cause Value - Type of Identity Coding 17

Hex Value Cause Value Meaning

01H Successful event 02H Stale message E0H Reject - version not supported E1H Reject - message type not supported E2H Reject - required IE is missing E3H Reject - reason unspecified


18

3GPP2 A.S0020-0 v1.0

4-43

Table 4.2.2.10-2 Allowable Cause Values by Message 1

Message Section Allowable Cause Values

IPT-Notification Ack 4.1.2.2 01H, 02H IPT-Reject 4.1.2.3 E0H, E1H, E2H, E3H

2

4.2.2.11 Notification Correlation ID 3

This IE contains the value used to correlate the IPT-Flush message to the IPT-Notification message. 4

4.2.2.11 Notification Correlation ID

7 6 5 4 3 2 1 0 Octet

IAS IEI = [08H] 1

Length 2

(MSB) Correlation Value 3

4

5

(LSB) 6

5


number. 7

Correlation Value This field contains the Correlation Value in the Message Type header in the IPT-8

Notification message that triggers the IPT-Flush message. 9

4.2.2.12 Flush Information 10

This IE is sent to convey the buffer information at the sender. 11

4.2.2.12 Flush Information

7 6 5 4 3 2 1 0 Octet

IAS IEI = [09H] 1

Length = [01H] 2

Reserved = 000000 In-Order FL IP Data

Pending = [0,1]

In-Order RL L2 Data

Pending =[0,1]

3

12


a binary number. 14

In-Order FL IP Data Pending This field indicates whether the sender still has buffered forward-link IP 15

packets that required in-order delivery. This field is set to ‘0’ if no in-16

order IP packets remain at the sender and is set to ‘1’ if there still exists 17

some in-order IP packets at the sender. 18

In-Order RL L2 Data Pending This field indicates whether the sender still waits to service some 19

reverse-link L2 packets that required in-order delivery. This field is set to 20

3GPP2 A.S0020-0 v1.0

4-44

‘0’ if the sender no longer waits to service in-order L2 packets and is set 1

to ‘1’ otherwise. 2

4.2.2.13 Message Timestamp 3

This IE includes the timestamp of when the sender generates the message that contains this IE. 4

4.2.2.13 Message Timestamp

7 6 5 4 3 2 1 0 Octet

IPT IEI = [0AH] 1

Length = 09H 2

NTP Stratum 3

(MSB) Timestamp 4

… …

(LSB) 11

5


number. 7

NTP Stratum This field contains the NTP stratum level information of the clock that the 8

Timestamp field is based on. Refer to [3] for definition and meaning of NTP 9

stratum15. The value of this field is set to 0xFF if the Timestamp is not NTP 10

synchronized. 11

Timestamp This field contains the timestamp of when the sender generates the message that 12

contains this IE. The value contained in this field is represented in 64-bit NTP 13

format [3]. 14

15

4.2.2.14 IPT Reject Record 16

This IE contains information regarding the rejected message. The IE may also contain the versions 17

supported for communicating with the sending eBS/SRNC. 18

4.2.2.14 IPT Reject Record

7 6 5 4 3 2 1 0 Octet

IPT IEI = [A0H] 1


(LSB) 3

Version Length = <variable> 4

Version-1 5

… …

Version-n n

(MSB) Rejected Message = <variable> n+1

… …

15 Note that the sender is considered to be of NTP stratum 0 if its time is based on GPS clock as defined in [3].

3GPP2 A.S0020-0 v1.0

4-45

4.2.2.14 IPT Reject Record

7 6 5 4 3 2 1 0 Octet

(LSB) p


a binary number. 2

Version Length If the Cause IE of the IPT-Reject message is set to “Reject - version not 3

supported”, this field contains the number of octets included for Version 4

in this IE as a binary number. Otherwise this field is set to zero. 5

Version-n This field is included for non-zero Version lengths and contains one 6

version supported by the sending eBS/SRNC. 7

Message Rejected This field contains the rejected message. 8

9

4.3 Timer Definitions 10

This section describes the timers associated with the UMB IOS specification. 11

Timer Name Default Value

(seconds)

Range of Values

(seconds)

Granularity

(seconds)

Section Reference

Classification

Tacct-aaa 1.0 1.0 - 5.0 0.1 4.3.1.1 AAA Interface Tndrpt-ias 0.1 0.01-1.0 0.01 4.3.1.2 IAS Interface Tndrptack-ias 0.1 0.01-1.0 0.01 4.3.1.3 IAS Interface Tpgack-ias 0.1 0.01 - 1.0 0.01 4.3.1.4 IAS Interface Tpgreq-ias 0.5 0.1 – 60.0 0.1 4.3.1.5 IAS Interface Tsir-ias 0.1 0.01 - 1.0 0.01 4.3.1.6 IAS Interface Tsr-ias 0.1 0.01 - 1.0 0.01 4.3.1.7 IAS Interface Tstr-ias 0.1 0.01 - 1.0 0.01 4.3.1.8 IAS Interface Tsur-ias 0.1 0.01 - 1.0 0.01 4.3.1.9 IAS Interface Tuupd-ias 0.1 0.01 - 1.0 0.01 4.3.1.10 IAS Interface Tflflush-ipt 0.05 0.01-1.0 0.01 4.3.1.11 IPT Interface Tnot-ipt 0.1 0.01 - 1.0 0.01 4.3.1.12 IPT Interface Trlflush-ipt 0.1 0.01-1.0 0.01 4.3.1.13 IPT Interface Twaitdap-ipt 0.02 0.01-1.0 0.01 4.3.1.14 IPT Interface Trrq-pmip 1.0 1.0 - 5.0 0.1 4.3.1.15 PMIP Interface

12

4.3.1 Timer Descriptions 13

4.3.1.1 Timer Tacct-aaa 14

This eBS timer is started when an AAA-Accounting-Request message is sent to the AGW and is stopped 15

when an AAA-Accounting-Response message is received. 16

3GPP2 A.S0020-0 v1.0

4-46

4.3.1.2 Timer Tndrpt-ias 1

This eBS or SRNC timer is started when an IAS-Neighbor Discovery Request message is sent and 2

stopped when the corresponding IAS-Neighbor Discovery Report message is received. 3

4.3.1.3 Timer Tndrptack-ias 4

This eBS timer is started when an unsolicited IAS-Neighbor Discovery Report message is sent and 5

stopped when the corresponding IAS-Neighbor Report Ack message is received. 6

4.3.1.4 Timer Tpgack-ias 7

This DAP timer is started when an IAS-Paging Request message, or an IAS-Page message with Local 8

Fanout Required flag are sent and stopped when corresponding IAS-Paging Request Ack message or 9

IAS-Page Ack message are received. 10

4.3.1.5 Timer Tpgreq-ias 11

This DAP timer is started when an IAS-Paging Request Ack message is received and stopped when an 12

IPT-Notification (FLSE) message is received. This timer is set based on the value of Page Attempt Timer 13

IE in the IAS-Paging Request Ack message. 14

4.3.1.6 Timer Tsir-ias 15

This ANRI timer is started when an IAS-Session Information Request message is sent and stopped when 16

an IAS-Session Information Response message is received. 17

4.3.1.7 Timer Tsr-ias 18

This SRNC timer is started when an IAS-Session Release message is sent and stopped when an IAS-19

Session Release Ack message is received. 20

4.3.1.8 Timer Tstr-ias 21

This SRNC timer is started when an IAS-SRNC Transfer Request message is sent and stopped when an 22

IAS-SRNC Transfer Response message is received. 23

4.3.1.9 Timer Tsur-ias 24

This ANRI timer is started when an IAS-Session Information Update Request message is sent and 25

stopped when an IAS-Session Information Update Response message is received. 26

4.3.1.10 Timer Tuupd-ias 27

This SRNC timer is started when an IAS-UATI Update message is sent and stopped when an IAS-UATI 28

Update Ack message is received. 29

4.3.1.11 Timer Tflflush-ipt 30

This target FLSE timer is started when the target FLSE receives an IPT-Notification Ack message with an 31

indication that the source FLSE still has pending in-order data on the forward-link. This timer is reset on 32

every received IP packet tunneled from the source FLSE and is stopped when an IPT-Flush message with 33

an indication that the source FLSE no longer has pending in-order data on the forward-link is received or 34

when another FLSE handoff occurs. 35

4.3.1.12 Timer Tnot-ipt 36

This notification timer is started when an ANRI or DAP sends an IPT-Notification message to another 37

ANRI in the AT’s route set or DAP and is stopped when an IPT-Notification Ack message is received. 38

3GPP2 A.S0020-0 v1.0

4-47

4.3.1.13 Timer Trlflush-ipt 1

This target RLSE timer is started when the target RLSE receives an IPT-Notification Ack message with 2

an indication that the source RLSE still awaits pending in-order data on the reverse-link. This timer is 3

stopped when an IPT-Flush message with an indication that the source RLSE no longer awaits in-order 4

data on the reverse-link is received or when another FLSE handoff occurs. 5

4.3.1.14 Timer Twaitdap-ipt 6

This FLSE timer is started when the FLSE receives a tunneled IP packet from the target DAP or when an 7

IPT-Notification message with an indication that DAP has changed is received. The FLSE buffers new IP 8

packets received from the target DAP that require in-order delivery until expiration of timer Twaitdap-ipt. 9

4.3.1.15 Timer Trrq-pmip 10

This timer is started when an eBS or SRNC sends an PMIP-Registration Request message to the AGW 11

and is stopped when an PMIP-Registration Reply message is received. The FLSE buffers new IP packets 12

received from the target DAP that require in-order delivery until expiration of timer Twaitdap-ipt. 13

14

3GPP2 A.S0020-0 v1.0

4-48

1


3

3GPP2 A.S0020-0 v1.0

A-1

Annex A Format of the AIS Paging Information Blob 1

The format of the AIS Paging Information Blob in the AIS Paging Information Record IE on the IAS 2

interface is specified as follows. If the AIS Paging Information Blob is also specified in [1], the format 3

and information of the AIS Paging Information Blob in [1] shall take precedence over the format and 4

information defined in this specification. 5

Field Length (bits)

PageInformationVersion 8

NumSSIR 8

NumSSIR instances of the following record{

SessionInformationLength 16

SessionStateInformationRecord SessionInformationLength

}

CurrentPagePeriod 32

CurrentPageOffset 32

PageRegistrationRadius 16

DelayTolerantPageRequired 8

AccessPersistenceClass 8

6

PageInformationVersion This field shall be set to 0x00 for this version of the 7

PagingInformationBlob. The eBS shall return a failure message if it does 8

not support the PageInformationVersion. Refer to section 1.7. 9

NumSSIR This field shall be set to the number of session state information records 10

included in this message. 11

SessionInformationLength This field shall be set to the length, in bytes, of the 12

SessionStateInformationRecord included in this Blob. 13

SessionStateInformationRecord 14

This field shall be set to the Session State Information Record specified 15

in [1]. The list of attributes and non-attribute data to be included in this 16

record are provided at the end of this section. 17

CurrentPagePeriod This field shall be set to the paging period that is currently being used by 18

the access terminal, in units of superframes. 19

CurrentPageOffset This field shall be set to the paging offset parameter (denoted by R) that 20

is used by the access terminal. 21

PageRegistrationRadius This field shall be set to the radius from the last registered eBS that is to 22

be used to page the AT. This field shall be specified using the units used 23

to specify the RegistrationRadius attributes of the air interface. 24

DelayTolerantPageRequired This field shall be set to ‘0x01’ if delay tolerant paging is required to be 25

performed by the eBS, and shall be set to ‘0x00’ otherwise. All other 26

values of this field are reserved. As specified in [1], delay tolerant paging 27

requires the eBS to send a page without sending a quick page. 28

AccessPersistenceClass This field shall be set to 0xff if the AccessPersistence is not specified, 29

and shall be set to the AccessPersistenceClass otherwise. The 30

3GPP2 A.S0020-0 v1.0

A-2

AccessPersistenceClass is defined in the MAC Layer specified in [1]. 1

The sender shall set this field to 0xff if the AT does not support enhanced 2

page features (i.e. EnhancedPageFeaturesSupport attribute is equal to 0). 3

4

The SessionStateInformationRecord shall include the following parameters specified in [1]. The protocol 5

of [1] that defines the parameter is provided in parenthesis for reference. 6

• PageID (Route Control Protocol) 7

• SessionSeed (Route Control Protocol) 8

• ExpandedQPCHSupported (Superframe Preamble MAC Protocol) 9

• QuickPageOrderingEnabled (Superframe Preamble MAC Protocol) 10

• SupportedChannelBands (Idle State Protocol) 11

• AccessHashingClassMask (Idle State Protocol) 12

• ExpandedQPCHSupported (Superframe Preamble MAC Protocol) 13

14