interoperability specification (ios) for femtocell access ... v1.0 femto ios-pub_201104.pdfjanuary...

© 2011, 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.S0024-A v1.0

April 2011

Interoperability Specification (IOS) for Femtocell Access Points

Revision History

Date Revision Description

January 2010 A.S0024-0 v1.0 Initial revision. For features supported, refer to section 1.1

April 2011 A.S0024-A v1.0 Includes support for IOS-based 1x architecture, 1x Femtocell

Access Control, out-of-band indication enhancements for 1x active

handoff from a macro BS to a FAP and dormant handoff from a

macro AN to a FAP. LIPA requirements and call flows (now

addressed in X.S0059) are removed.

3GPP2 A.S0024-A v1.0

i

Table of Contents 1

2

Foreword ..................................................................................................................................................... xii 3

1 Introduction ................................................................................................................................... 1-1 4

1.1 Overview ....................................................................................................................................... 1-1 5

1.1.1 Purpose .......................................................................................................................................... 1-1 6

1.1.2 Scope ............................................................................................................................................. 1-1 7

1.1.3 Document Convention .................................................................................................................. 1-1 8

1.2 References ..................................................................................................................................... 1-1 9

1.2.1 Normative References ................................................................................................................... 1-2 10

1.2.2 Informative References ................................................................................................................. 1-3 11

1.3 Terminology .................................................................................................................................. 1-3 12

1.3.1 Acronyms ...................................................................................................................................... 1-3 13

1.3.2 Definitions .................................................................................................................................... 1-4 14

1.4 Architecture .................................................................................................................................. 1-5 15

1.4.1 Femtocell SIP-Based 1x Voice Architecture ................................................................................ 1-5 16

1.4.1.1 Femtocell SIP-based 1x RAN Network Entities ...................................................... 1-5 17

1.4.1.2 Femtocell SIP-based 1x RAN Interfaces ................................................................. 1-6 18

1.4.2 Femtocell IOS-based 1x Voice Architecture ................................................................................ 1-6 19

1.4.2.1 Femtocell 1x IOS-based RAN Network Entities ..................................................... 1-7 20

1.4.2.2 Femtocell 1x IOS-based RAN Interfaces ................................................................ 1-8 21

1.4.2.3 Protocol Stack .......................................................................................................... 1-9 22

1.4.3 Femtocell 1x and HRPD Packet Data ......................................................................................... 1-10 23

1.4.3.1 Femtocell 1x and HRPD RAN Packet Data Network Entities .............................. 1-10 24

1.4.3.2 Femtocell 1x and HRPD RAN Packet Data Interfaces .......................................... 1-11 25

1.4.4 Femtocell eHRPD Packet Data ................................................................................................... 1-12 26

1.4.4.1 Femtocell eHRPD RAN Packet Data Network Entities ........................................ 1-12 27

1.4.4.2 Femtocell eHRPD RAN Packet Data Interfaces .................................................... 1-12 28

1.4.5 HRPD LIPA ................................................................................................................................ 1-13 29

1.5 IOS Femtocell Assumptions ....................................................................................................... 1-13 30

1.6 Feature Descriptions ................................................................................................................... 1-14 31

1.6.1 Explicitly Supported Features ..................................................................................................... 1-14 32

1.6.1.1 FAP Power-up ....................................................................................................... 1-14 33

1.6.1.2 1x Dormant Handoff Between the Macro BS and the FAP ................................... 1-14 34

1.6.1.3 1x Active Handoff Between the Macro BS and the FAP ...................................... 1-14 35

1.6.1.4 HRPD Dormant Handoff Between the Macro AN/PCF and the FAP ................... 1-14 36

3GPP2 A.S0024-A v1.0

ii

1.6.1.5 Connected State Session Transfer Between the FAP and the Macro AN .............. 1-14 1

1.6.1.6 Femtocell Access Control ...................................................................................... 1-14 2

1.6.1.7 1x OOB Indication of MS Detection ..................................................................... 1-14 3

2 Requirements and Procedures ..................................................................................................... 2-15 4

2.1 Femtocell Requirements ............................................................................................................. 2-15 5

2.1.1 SIP-based 1x RAN Femtocell Requirements .............................................................................. 2-15 6

2.1.2 IOS-based 1x RAN Femtocell Requirements ............................................................................. 2-15 7

2.1.2.1 IOS Signaling Routing ........................................................................................... 2-15 8

2.1.2.2 Cell ID Aggregation .............................................................................................. 2-15 9

2.1.2.3 UZID Aggregation ................................................................................................. 2-16 10

2.1.2.4 Transport Layer Requirements .............................................................................. 2-16 11

2.1.2.4.1 Use of SUA for A1p .............................................................................................. 2-16 12

2.1.2.4.2 Use of SCCP for A1 .............................................................................................. 2-17 13

2.1.3 1x Packet Data and HRPD Femtocell Requirements .................................................................. 2-17 14

2.1.3.1 Security Association for 1x and HRPD Packet Data Femtocells .......................... 2-17 15

2.2 1x Packet Data Support ............................................................................................................... 2-17 16

2.3 eHRPD Femtocell Operation ...................................................................................................... 2-18 17

2.4 Femtocell Access Control ........................................................................................................... 2-18 18

2.4.1 Femtocell Access Control Authorization and Enforcement Points ............................................. 2-18 19

2.4.2 Access Control List ..................................................................................................................... 2-18 20

2.4.3 1x Femtocell Access Control ...................................................................................................... 2-18 21

2.4.3.1 AN-AAA as 1x Authorization Point ...................................................................... 2-18 22

2.4.4 HRPD Femtocell Access Control ............................................................................................... 2-19 23

2.4.4.1 AN-AAA as HRPD FAC Authorization Point ...................................................... 2-19 24

2.5 LIPA Requirements and Procedures ........................................................................................... 2-19 25

3 Femtocell Interfaces ...................................................................................................................... 3-1 26

3.1 FGW and RAN Interfaces ............................................................................................................. 3-1 27

3.2 SIP-based FAP to Core Network Interface ................................................................................... 3-1 28

3.2.1 A1 Formatted Messages Used on Fx2 .......................................................................................... 3-1 29

3.2.1.1 Measurement Procedures ......................................................................................... 3-1 30

3.2.1.1.1 Measurement Request .............................................................................................. 3-1 31

3.2.1.1.1.1 Successful Operation ............................................................................................... 3-1 32

3.2.1.1.1.2 Failure Operation ..................................................................................................... 3-2 33

3.2.1.1.2 Measurement Response ........................................................................................... 3-2 34



3GPP2 A.S0024-A v1.0

iii

3.2.1.1.3 Femtocell Supplementary Info ................................................................................ 3-3 1

3.2.1.1.3.1 Successful FCS Operation ....................................................................................... 3-3 2

3.2.1.1.3.2 Successful FAP Operation ....................................................................................... 3-3 3


3.2.1.1.4 MS OOB Indication ................................................................................................. 3-4 5



3.3 FAP RAN Interfaces ..................................................................................................................... 3-4 8

3.3.1 A1/A1p and A2/A2p Interfaces .................................................................................................... 3-4 9

3.3.2 A10/A11 Interface ........................................................................................................................ 3-4 10

3.3.3 A12 Interface ................................................................................................................................ 3-4 11

3.3.3.1 A12 RADIUS Attribute Definition .......................................................................... 3-5 12

3.3.3.1.1 Femtocell-Access-Control-Authorization ................................................................ 3-5 13

3.3.3.1.2 HRPD Access Authentication and 1x Access Authorization .................................. 3-6 14

3.3.4 A13 Interface ................................................................................................................................ 3-6 15

3.3.4.1 HRPD Dormant Handoff from FAP to Macro AN/PCF .......................................... 3-6 16

3.3.5 A16 Interface ................................................................................................................................ 3-6 17

3.3.5.1 Connected-State Handoff from FAP to a Macro AN............................................... 3-6 18

3.3.5.2 Connected-State Handoff from Macro AN to a FAP............................................... 3-7 19

3.3.6 A24 (IP Tunneling) Interface ........................................................................................................ 3-7 20

3.3.7 A25 Interface ................................................................................................................................ 3-7 21

3.3.7.1 A25 Interface Network/Transport Protocol Specification ....................................... 3-7 22

3.3.7.1.1 Use of the SUA for A25 .......................................................................................... 3-7 23

3.3.7.1.2 Use of SCTP ............................................................................................................ 3-8 24

3.3.7.2 A25 Interface Message Procedures.......................................................................... 3-8 25

3.3.7.2.1 A25-FAP Registration Request ............................................................................... 3-8 26



3.3.7.2.2 A25-FAP Registration Response ............................................................................. 3-8 29



3.3.7.2.3 A25-FAP Deregistration .......................................................................................... 3-9 32



3.3.7.2.4 A25-Measurement Request ..................................................................................... 3-9 35


3GPP2 A.S0024-A v1.0

iv

3.3.7.2.4.2 Failure Operation ................................................................................................... 3-10 1

3.3.7.2.5 A25-Measurement Response ................................................................................. 3-10 2

3.3.7.2.5.1 Successful Operation ............................................................................................. 3-10 3


3.3.7.2.6 A25-MS OOB Indication ....................................................................................... 3-11 5


3.3.7.2.7 A25-Femtocell Supplementary Info ...................................................................... 3-11 7

3.3.7.2.7.1 Successful FAP Operation ..................................................................................... 3-11 8

3.3.7.2.7.2 Failure FAP Operation ........................................................................................... 3-11 9

3.3.7.2.7.3 None.Successful FGW Operation .......................................................................... 3-11 10

3.3.7.2.7.4 Failure FGW Operation ......................................................................................... 3-12 11

3.3.8 A26 Interface .............................................................................................................................. 3-12 12

3.3.8.1 A26 Interface Network/Transport Protocol Specification ..................................... 3-12 13

3.3.8.2 A26 Interface Message Procedures........................................................................ 3-13 14

3.3.8.2.1 A26-FAP Registration Request ............................................................................. 3-13 15



3.3.8.2.2 A26-FAP Registration Response ........................................................................... 3-13 18



3.3.8.2.3 A26-FAP Deregistration ........................................................................................ 3-13 21



3.3.8.2.4 A26-Measurement Request ................................................................................... 3-14 24



3.3.8.2.5 A26-Measurement Response ................................................................................. 3-14 27



4 FAP Call Flows ............................................................................................................................. 4-1 30

4.1 FAP Operation .............................................................................................................................. 4-1 31

4.1.1 FAP Power-up ............................................................................................................................... 4-1 32

4.1.2 IOS-based 1x FAP Registration/Deregistration ............................................................................ 4-1 33

4.1.2.1 1x FAP Registration ................................................................................................ 4-2 34

4.1.2.2 1x FAP Deregistration ............................................................................................. 4-2 35

4.1.2.2.1 FAP-initiated FAP Deregistration ........................................................................... 4-2 36

3GPP2 A.S0024-A v1.0

v

4.1.2.2.2 FGW-initiated FAP Deregistration .......................................................................... 4-2 1

4.1.3 HRPD FAP Registration/Deregistration ....................................................................................... 4-2 2

4.1.3.1 HRPD FAP Registration .......................................................................................... 4-2 3

4.1.3.2 HRPD FAP Deregistration ...................................................................................... 4-3 4

4.1.3.2.1 FAP-initiated HRPD FAP Deregistration ................................................................ 4-3 5

4.1.3.2.2 FGW-initiated HRPD FAP Deregistration .............................................................. 4-3 6

4.2 SIP-based 1x RAN Call Flows ..................................................................................................... 4-4 7

4.2.1 MS/AT Power-up at the FAP ........................................................................................................ 4-4 8

4.2.2 MS Registration and Paging at the FAP ....................................................................................... 4-4 9

4.2.3 SIP-based 1x Handoff ................................................................................................................... 4-4 10

4.2.3.1 SIP-based 1x Macro BS to FAP Dormant Handoff (Intra-PDSN) .......................... 4-4 11

4.2.3.2 SIP-based 1x Macro BS to FAP Dormant Handoff (Inter-PDSN) .......................... 4-6 12

4.2.3.3 SIP-based 1x FAP to Macro BS Dormant Handoff ................................................. 4-7 13

4.2.3.4 SIP-based 1x Macro BS to FAP Active Handoff .................................................... 4-8 14

4.2.3.4.1 SIP-based 1x Macro BS to FAP Active Handoff Measurements ............................ 4-8 15

4.2.3.4.2 1x Macro BS to FAP Active Handoff with Early OOB Link Detection ............... 4-10 16

4.2.3.4.3 1x Macro BS to FAP Active Handoff with Late OOB Link Detection ................. 4-12 17

4.2.3.4.4 MS OOB Indication ............................................................................................... 4-14 18

4.2.3.5 SIP-based 1x FAP to Macro BS Active Handoff .................................................. 4-14 19

4.3 IOS-based 1x RAN Call Flows ................................................................................................... 4-16 20

4.3.1 MS Registration .......................................................................................................................... 4-16 21

4.3.2 Mobile Origination...................................................................................................................... 4-17 22

4.3.3 Mobile Termination .................................................................................................................... 4-18 23

4.3.4 IOS-based 1x Handoff ................................................................................................................ 4-19 24

4.3.4.1 Macro BS to FAP Dormant Handoff (Intra-PDSN) .............................................. 4-19 25

4.3.4.2 Macro BS to FAP Dormant Handoff (Inter-PDSN) .............................................. 4-20 26

4.3.4.3 FAP to Macro BS Dormant Handoff ..................................................................... 4-20 27

4.3.4.4 Macro BS to FAP Active Handoff ......................................................................... 4-20 28

4.3.4.4.1 Macro BS to FAP Active Handoff Measurements ................................................ 4-20 29

4.3.4.4.2 Macro BS to FAP Active Handoff with Early OOB Link Detection .................... 4-22 30

4.3.4.4.3 Macro BS to FAP Active Handoff with Late OOB Link Detection ...................... 4-24 31

4.3.4.4.4 A25-MS OOB Indication ....................................................................................... 4-26 32

4.3.4.5 FAP to Macro BS Active Handoff ......................................................................... 4-26 33

4.3.4.6 Inter-FAP Active Handoff ..................................................................................... 4-26 34

4.3.4.6.1 Active Optimized Inter-FAP Handoff with A1p ................................................... 4-26 35

4.3.4.6.2 Active Optimized Inter-FAP Handoff with A1 ..................................................... 4-29 36

3GPP2 A.S0024-A v1.0

vi

4.4 HRPD Call Flows ....................................................................................................................... 4-30 1

4.4.1 HRPD Handoff ........................................................................................................................... 4-30 2

4.4.1.1 HRPD Macro AN/PCF to FAP Dormant Handoff ................................................ 4-30 3

4.4.1.2 HRPD FAP to Macro AN/PCF Dormant Handoff ................................................ 4-30 4

4.4.1.3 HRPD Macro AN/PCF to FAP Connected State Session Transfer ....................... 4-33 5

4.4.1.4 HRPD FAP to Macro AN/PCF Connected State Session Transfer ....................... 4-36 6

4.5 LIPA Session Establishment between FAP and AT ................................................................... 4-36 7

5 Messages, Information Elements and Timer Definitions .............................................................. 5-1 8

5.1 Message Definitions...................................................................................................................... 5-1 9

5.1.1 A1 and A1p Message Definitions ................................................................................................. 5-1 10

5.1.1.1 Measurement Request .............................................................................................. 5-1 11

5.1.1.2 Measurement Response ........................................................................................... 5-5 12

5.1.1.3 Femtocell Supplementary Info ................................................................................ 5-7 13

5.1.1.4 MS OOB Indication ................................................................................................. 5-9 14

5.1.2 A25 Message Definition ............................................................................................................. 5-11 15

5.1.2.1 A25-FAP Registration Request ............................................................................. 5-11 16

5.1.2.2 A25-FAP Registration Response ........................................................................... 5-12 17

5.1.2.3 A25-FAP Deregistration ........................................................................................ 5-13 18

5.1.2.4 A25-Measurement Request ................................................................................... 5-13 19

5.1.2.5 A25-Measurement Response ................................................................................. 5-13 20

5.1.2.6 A25-MS OOB Indication ....................................................................................... 5-13 21

5.1.2.7 A25-Femtocell Supplementary Info ...................................................................... 5-14 22

5.1.3 A26 Message Definitions ............................................................................................................ 5-15 23

5.1.3.1 A26-FAP Registration Request ............................................................................. 5-15 24

5.1.3.2 A26-FAP Registration Response ........................................................................... 5-16 25

5.1.3.3 A26-FAP Deregistration ........................................................................................ 5-17 26

5.1.3.4 A26-Measurement Request ................................................................................... 5-17 27

5.1.3.5 A26-Measurement Response ................................................................................. 5-19 28

5.2 Information Element Definitions ................................................................................................ 5-21 29

5.2.1 A1 and A1p Information Element Definitions ............................................................................ 5-21 30

5.2.1.1 A1 and A1p Information Element Identifiers ........................................................ 5-21 31

5.2.1.2 Message Type ........................................................................................................ 5-21 32

5.2.1.3 Long Code ............................................................................................................. 5-22 33

5.2.1.4 Cause ..................................................................................................................... 5-22 34

5.2.1.5 Measurement Response Options ............................................................................ 5-24 35

5.2.1.6 Measurement Report .............................................................................................. 5-25 36

3GPP2 A.S0024-A v1.0

vii

5.2.1.7 Global RAND Key ................................................................................................ 5-26 1

5.2.1.8 Pilot List ................................................................................................................ 5-26 2

5.2.1.9 Nonce ..................................................................................................................... 5-27 3

5.2.1.10 Mobile Identity ...................................................................................................... 5-27 4

5.2.1.11 OOB Indication ...................................................................................................... 5-30 5

5.2.2 A25 Information Element Definitions ........................................................................................ 5-31 6

5.2.2.1 A25 Information Element Identifiers ..................................................................... 5-31 7

5.2.2.2 A25 Cross Reference of IEs with Messages .......................................................... 5-31 8

5.2.2.3 A25 Message Type ................................................................................................ 5-32 9

5.2.2.4 FAP Identifier ........................................................................................................ 5-33 10

5.2.2.5 1x Cell Info ............................................................................................................ 5-33 11

5.2.2.6 Reg/Dereg Cause ................................................................................................... 5-34 12

5.2.2.7 Cell Identifier List .................................................................................................. 5-35 13

5.2.2.8 Classmark Information Type 2 .............................................................................. 5-35 14

5.2.2.9 Downlink Radio Environment ............................................................................... 5-35 15

5.2.2.10 CDMA Serving One Way Delay ........................................................................... 5-35 16

5.2.2.11 MS Measured Channel Identity ............................................................................. 5-35 17

5.2.2.12 IS-2000 Channel Identity ....................................................................................... 5-35 18

5.2.2.13 Long Code ............................................................................................................. 5-35 19


5.2.2.15 Mobile Identity ...................................................................................................... 5-35 21


5.2.2.17 Cause ..................................................................................................................... 5-35 23

5.2.2.18 OOB Indication ...................................................................................................... 5-35 24

5.2.2.19 Global RAND Key ................................................................................................ 5-35 25

5.2.2.20 Authentication Response Parameter ...................................................................... 5-36 26

5.2.2.21 Nonce ..................................................................................................................... 5-36 27

5.2.3 A26 Information Element Definitions ........................................................................................ 5-36 28

5.2.3.1 A26 Information Element Identifiers ..................................................................... 5-36 29

5.2.3.2 A26 Cross Reference of IEs with Messages .......................................................... 5-36 30

5.2.3.3 A26 Message Type ................................................................................................ 5-37 31

5.2.3.4 FAP Identifier ........................................................................................................ 5-37 32

5.2.3.5 Sector Info ............................................................................................................. 5-37 33

5.2.3.6 AT-ID .................................................................................................................... 5-38 34

5.2.3.7 Long Code Mask.................................................................................................... 5-39 35


3GPP2 A.S0024-A v1.0

viii


5.2.3.10 Cause ..................................................................................................................... 5-41 2

5.3 Timer Definitions ........................................................................................................................ 5-42 3

5.3.1 Timer Descriptions...................................................................................................................... 5-42 4

5.3.1.1 Tmr-1 ........................................................................................................................ 5-42 5

5.3.1.2 Tmr-26 ....................................................................................................................... 5-42 6

5.3.1.3 Tregreq-26 ................................................................................................................... 5-42 7

8

9

3GPP2 A.S0024-A v1.0

ix

Table of Figures 1

2

Figure 1.4.1-1 Femtocell SIP-based 1xVoice Architecture with MSC ............................................. 1-5 3

Figure 1.4.1-2 Femtocell SIP-based 1x Voice Architecture with MSCe .......................................... 1-5 4

Figure 1.4.2-1 Femtocell IOS-based 1x Voice Architecture with A1p/A2p Interfaces .................... 1-7 5

Figure 1.4.2-2 Femtocell IOS-based 1x Voice Architecture with A1/A2 Interfaces ........................ 1-7 6

Figure 1.4.2.3-1 Femtocell 1x IOS-Based Protocol Reference Model-Control Plane ......................... 1-9 7

Figure 1.4.2.3-2 Femtocell 1x IOS-Based Protocol Reference Model- User Plane ............................. 1-9 8

Figure 1.4.2.3-3 Femtocell 1x IOS-Based Protocol Reference Model-Control Plane ......................... 1-9 9

Figure 1.4.2.3-4 Femtocell 1x IOS-Based Protocol Reference Model- User Plane ............................. 1-9 10

Figure 1.4.3-1 Femtocell 1x Packet Data Architecture ................................................................... 1-10 11

Figure 1.4.3-2 Femtocell HRPD Packet Data Architecture ............................................................ 1-10 12

Figure 1.4.4-1 Femtocell eHRPD Packet Data Architecture .......................................................... 1-12 13

Figure 2.1.2.4.1-1 DRN/SRN and Source/Destination Address Usage Between FAP and FGW ........ 2-16 14

Figure 2.1.2.4.1-2 DRN/SRN and Source/Destination Address Usage Between FGW and MSCe ..... 2-17 15

Figure 2.1.2.4.2-1 SLR/DLR and SPC/DPC Usage Between FGW and MSC ..................................... 2-17 16

Figure 3.3.3.1-1 3GPP2 RADIUS Attribute Format ............................................................................ 3-5 17

Figure 4.1.1-1 FAP Power-up ........................................................................................................... 4-1 18

Figure 4.1.2.1-1 FAP Registration ....................................................................................................... 4-2 19

Figure 4.1.2.2.1-1 FAP-initiated FAP Deregistration ............................................................................. 4-2 20

Figure 4.1.2.2.2-1 FGW-initiated FAP Deregistration ........................................................................... 4-2 21

Figure 4.1.3.1-1 FAP Registration ....................................................................................................... 4-3 22

Figure 4.1.3.2.1-1 FAP-initiated HRPD FAP Deregistration ................................................................. 4-3 23

Figure 4.1.3.2.2-1 FGW-initiated HRPD FAP Deregistration ................................................................ 4-3 24

Figure 4.2.3.1-1 1x Macro BS to FAP Dormant Handoff (Intra-PDSN) ............................................. 4-4 25

Figure 4.2.3.2-1 1x Macro BS to FAP Dormant Handoff (Inter-PDSN) ............................................. 4-6 26

Figure 4.2.3.4.1-1 1x Macro BS to FAP Active Handoff ....................................................................... 4-8 27

Figure 4.2.3.4.2-1 1x Macro BS to FAP Active Handoff with Early OOB Link Detection ................. 4-10 28

Figure 4.2.3.4.3-1 1x Macro BS to FAP Active Handoff with Late OOB Link Detection ................... 4-12 29

Figure 4.2.3.4.4-1 MS OOB Indication ................................................................................................ 4-14 30

Figure 4.2.3.5-1 1x FAP to Macro BS Active Handoff ..................................................................... 4-14 31

Figure 4.3.1-1 Mobile Registration via a Circuit Switched MSC/MSCe ........................................ 4-16 32

Figure 4.3.2-1 Mobile Origination via a Circuit Switched MSC .................................................... 4-17 33

Figure 4.3.3-1 Mobile Termination via a Circuit Switched MSC ................................................... 4-18 34

Figure 4.3.4.4.1-1 1x Macro BS to FAP Active Handoff ..................................................................... 4-20 35

Figure 4.3.4.4.2-1 1x Macro BS to FAP Active Handoff with Early OOB Link Detection ................. 4-22 36

3GPP2 A.S0024-A v1.0

x

Figure 4.3.4.4.3-1 1x Macro BS to FAP Active Handoff with Late OOB Link Detection ................... 4-24 1

Figure 4.3.4.4.4-1 A25-MS OOB Indication ........................................................................................ 4-26 2

Figure 4.3.4.7.1-1 Active Optimized Inter-FAP Handoff, FGW with A1p .......................................... 4-27 3

Figure 4.3.4.7.2-1 Active Optimized Inter-FAP Handoff, FGW with A1 ............................................ 4-29 4

Figure 4.4.1.2-1 HRPD FAP to Macro AN/PCF Dormant Handoff .................................................. 4-31 5

Figure 4.4.1.3-1 HRPD Macro AN/PCF to FAP Active Handoff ...................................................... 4-33 6

7

8

3GPP2 A.S0024-A v1.0

xi

Table of Tables 1

2

Table 3.3.7.1.1-1 Use of SUA for FCP Messages ................................................................................. 3-7 3

Table 5.2.1.2-1 BSMAP Messages ................................................................................................... 5-21 4

Table 5.2.1.4-1 Cause Class Values ................................................................................................. 5-23 5

Table 5.2.1.4-2 Cause Values ........................................................................................................... 5-23 6

Table 5.2.1.10-1 Mobile Identity - Type of Identity Coding .............................................................. 5-28 7

Table 5.2.1.10-2 Mobile Identity - Type of OOB Identity Coding ..................................................... 5-30 8

Table 5.2.2.2-1 A25 Cross Reference of IEs with Messages ............................................................ 5-31 9

Table 5.2.3.2-1 Cross Reference of IEs with Messages ................................................................... 5-36 10

Table 5.3.1-1 Timer Values and Ranges Sorted by Name ............................................................. 5-42 11

12

13

14

3GPP2 A.S0024-A v1.0

xii

Foreword 1

The foreword is not part of this standard. 2

This document describes the protocols and procedures to support Femtocell Access Points (FAPs) in the 3

Radio Access Network (RAN). 4

5

6

7

3GPP2 A.S0024-A v1.0

1-1

1 Introduction 1

This document contains the procedures, call flows and message descriptions associated with Femtocell 2

Access Point (FAP) support in the access network. 3

1.1 Overview 4

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

features and functions. 6

Features and functions explicitly supported in this specification: 7

Femtocell power-up 8

1x dormant handoff between the macro BS and the FAP 9

1x active handoff between the macro BS and the FAP 10

High Rate Packet Data (HRPD) dormant handoff between the macro AN and the FAP 11

HRPD connected state session transfer between the FAP and the macro AN 12

1x and HRPD Femtocell Access Control (FAC) including 1x authorization at the AN-AAA 13

1x out-of-band (OOB) indication that an MS is or is not detected in the proximity of a Femtocell. 14

15

Note: Local IP Access (LIPA) is specified in X.S0059-100 [16]. 16

The features and functions that are explicitly not supported in this specification are: 17

Soft handoff between Femtocells 18

Concurrent packet and circuit voice service 19

1.1.1 Purpose 20

The purpose of this document is to provide a standard and call flows for the Femtocell interfaces within 21

the Radio Access Network (RAN). 22

1.1.2 Scope 23

This document provides an interoperability specification for a RAN that supports Femtocell operation. 24

This document contains message procedures and formats necessary to obtain this interoperability. 25

1.1.3 Document Convention 26

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

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

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

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

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

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

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

1.2 References 34

References are either normative or informative. A normative reference is used to include another 35

document as a mandatory part of a 3GPP2 specification. Documents that provide additional non-essential 36

information are included in the informative references section. 37

3GPP2 A.S0024-A v1.0

1-2

1.2.1 Normative References 1

The following standards contain provisions which, through reference in this text, constitute provisions of 2

this standard. At the time of publication, the editions indicated were valid. All standards are subject to 3

revision, and parties to agreements based upon this document are encouraged to investigate the possibility 4

of applying the most recent editions published by them. 5

[1] 3GPP2: A.S0008-C v3.0, Interoperability Specification (IOS) for High Rate Packet Data 6

(HRPD) Radio Access Network Interfaces with Session Control in the Access Network, June, 7

2010. 8

[2] 3GPP2: A.S0009-C v3.0, Interoperability Specification (IOS) for High Rate Packet Data 9

(HRPD) Radio Access Network Interfaces with Session Control in the Packet Control Function, 10

June 2010. 11

[3] 3GPP2: A.S0012-D v3.0, Interoperability Specification (IOS) for cdma2000 Access Network 12

Interfaces - Part 2 Transport, September 2010. 13


Interfaces - Part 3 Features, September 2010. 15


Interfaces – Part 4 (A1, A1p, A2, and A5 Interfaces), September 2010. 17


Interfaces – Part 7 (A10 and A11 Interfaces), September 2010. 19

[7] 3GPP2: A.S0022-A v1.0, Interoperability Specification (IOS) for Evolved High Rate Packet 20

Data (eHRPD) Radio Access Network Interfaces and Interworking with Enhanced Universal 21

Terrestrial Radio Access Network (E-UTRAN), February 2011. 22

[8] 3GPP2: C.S0005-E v2.0, Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread 23

Spectrum Systems, June 2010. 24

[9] 3GPP2: C.S0024-B v3.0, cdma2000 High Rate Packet Data Air Interface Specification, 25

September 2009. 26

[10] 3GPP2: C.S0087-0 v2.0, E-UTRAN - cdma2000 Connectivity and Interworking: Air Interface 27

Specification, January, 2010. 28

[11] 3GPP2: S.S0132-0 v1.0, Femtocell Security Framework, December 2009. 29

[12] 3GPP2: X.S0004-E v7.0, Mobile Application Part (MAP), April 2008. 30

[13] 3GPP2: X.S0011-D v2.0, Wireless IP Network Standard, November 2008. 31

[14] 3GPP2: X.S0057-0 v3.0, E-UTRAN - eHRPD Connectivity and Interworking: Core Network 32

Aspects, September 2010. 33

[15] 3GPP2: X.S0059-000-A v1.0, cdma2000 Femtocell Network Overview. 34

[16] 3GPP2: X.S0059-100-A v1.0, cdma2000 Femtocell Network Packet Data Network Aspects. 35

[17] 3GPP2: X.S0059-200-A v1.0, cdma2000 Femtocell Network: 1x and IMS Network Aspects. 36

Editor‟s Note: The above documents ([15], [16] and [17]) are works in progress and should not be 37

referenced unless and until they are approved and published. Until such time as this Editor‟s Note is 38

removed, the inclusion of the above documents is for informational purposes only. 39

[18] IETF: RFC 768, User Datagram Protocol, August 1980. 40

[19] IETF: RFC 2865, Remote Authentication Dial In User Service (RADIUS), June 2000. 41

3GPP2 A.S0024-A v1.0

1-3

[20] IETF: RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User 1

Service (RADIUS), July 2003. 2

1.2.2 Informative References 3

[I-1] 3GPP2: X.R0063-0 v1.0, 3GPP2 Femtocell Configuration Parameters. 4

[I-2] 3GPP2: S.R0005-B v2.0, Network Reference Model for CDMA2000 Spread Spectrum Systems, 5

May 2007. 6

[I-3] 3GPP2: S.R0037-B v2.0 IP Network Architecture Model for cdma2000 Spread Spectrum 7

Systems, June 2009. 8

[I-4] http://standards.ieee.org/regauth/oui/tutorials/EUI48.html. 9

[I-5] http://standards.ieee.org/regauth/oui/tutorials/EUI64.html. 10

11

1.3 Terminology 12

13

1.3.1 Acronyms 14

3GPP2 3rd Generation Partnership Project 2

ACL Access Control List

AN Access Network

AAA Authentication, Authorization and Accounting

AN-AAA Access Network Authentication, Authorization and Accounting

AT Access Terminal

BS Base Station

BSMAP Base Station Mobile Application Part

CDMA Code Division Multiple Access

CHAP Challenge Handshake Authentication Protocol

CVSE Critical Vendor Specific Extension

DNS Domain Name System

ESN Electronic Serial Number

FAC Femtocell Access Control

FACDIR2 Facilities Directive 2

FAP Femtocell Access Point

FCP Femtocell Control Protocol

FCS Femtocell Convergence Server

FEID Femtocell Equipment Identifier

FGW Femtocell Gateway

FIAP Femtocell IOS Application Protocol

FMS Femtocell Management System

HRPD High Rate Packet Data

IE Information Element

3GPP2 A.S0024-A v1.0

1-4

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IOS Interoperability Specification

IP Internet Protocol

kbps kilobit per second

LIPA Local IP Access

MEID Mobile Equipment Identity

MGW Media Gateway

MS Mobile Station

MSC Mobile Switching Center

MSCe Mobile Switching Center Emulation

NVSE Normal Vendor Specific Extension

OOB out-of-band

PCF Packet Control Function

PCM Pulse Code Modulation

PDSN Packet Data Serving Node

PLCM Public Long Code Mask

PPP Point to Point Protocol

PSMM Pilot Strength Measurement Message

RADIUS Remote Authentication Dial-In User Service

RAN Radio Access Network

RFC Request for Comments

RTP Real-time Transport Protocol

SC/MM Session Control / Mobility Management

SCTP Stream Control Transmission Protocol

SeGW Security Gateway

SIP Session Initiation Protocol

SUA Signaling Connection Control Part User Adaptation Layer

UATI Unicast Access Terminal Identifier

UDP User Datagram Protocol

VSA Vendor Specific Attribute

VoIP Voice over IP

1.3.2 Definitions 1

out-of-band A communication means other than a cdma2000® 1 1x or HRPD air 2

interface. 3

A1 Formatted Message An A1 message defined in this document that is transported on the Fx2 4

interface or an A1/A1p message that is transported on the A25 interface. 5

1 cdma2000®

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

Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000®

is a registered trademark of the

Telecommunications Industry Association (TIA-USA) in the United States.

3GPP2 A.S0024-A v1.0

1-5

1.4 Architecture 1

1x and HRPD Femtocell IOS messaging and call flows are based on the architecture reference models 2

shown in this section. In the figures, solid lines indicate signaling and bearer and dashed lines indicate 3

only signaling. 4

1.4.1 Femtocell SIP-Based 1x Voice Architecture 5

Figure 1.4.1-1 and Figure 1.4.1-2 show the RAN reference architecture for SIP-based 1x voice access 6

from a FAP. For voice, the 1x signaling and user plane packets are converted at the FAP to Session 7

Initiation Protocol (SIP) and Voice over IP (VoIP) traffic respectively. 8

A2

1x FAP

Core NetworkIPsec tunnel

(Fx3)

Macro

BSMSC

MS

SeGW

MGCF/MGW

FCS

FMS

Fx2

Fx1

A1

A12

1x

Fm

AN-AAA

MAP

IMS

9

Figure 1.4.1-1 Femtocell SIP-based 1xVoice Architecture with MSC 10

11

1x FAP

Core NetworkIPsec tunnel (Fx3)

MSCe

MS

SeGW

MGCF/

MGWFCS

FMS

Fx2

Fx1

A1p

A12

1x

Fm

A2p

AN-AAA

Macro

BS

IMS

MAP

12

Figure 1.4.1-2 Femtocell SIP-based 1x Voice Architecture with MSCe 13

1.4.1.1 Femtocell SIP-based 1x RAN Network Entities 14

The entities identified in Figure 1.4.1-1 and Figure 1.4.1-2 are defined as follows. 15

BS The macro base station (BS) is an entity in the public radio telecommunications system 16

used for radio telecommunications with MSs. 17

3GPP2 A.S0024-A v1.0

1-6

FAP The Femtocell Access Point (FAP) is a wireless access point operating in licensed 1

spectrum to connect a mobile station (MS) to the operator‟s network through the public 2

Internet infrastructure. In 1x, this entity enables access to 1x voice users by providing a 3

conversion function between 1x voice and IP Multimedia Subsystem (IMS)-based VoIP 4

traffic and signaling. 5

MS The mobile station (MS) is an entity in the public cellular radio telecommunications 6

service intended to be used while in motion or during halts at unspecified points. 7

MSC/MSCe The Mobile Switching Center (MSC) may be either a circuit-switched MSC or an IP 8

based MSCe (emulation) and provides processing and control for calls and services. 9

Refer to S.R0005 [I-2] for MSC and S.R0037 [I-3] for MSCe. 10

SeGW The Security Gateway (SeGW) is an entity residing in an operator‟s network that 11

provides for secure access for the FAP to network operator services. Refer to X.S0059-12

000 [15]. 13

AN-AAA The AN Authentication, Authorization and Accounting server may perform access 14

control authorization for the 1x FAP. 15

Core network entities are specified in X.S0059-000 [15]. 16

1.4.1.2 Femtocell SIP-based 1x RAN Interfaces 17

The interfaces identified in Figure 1.4.1-1 and Figure 1.4.1-2 are defined as follows. 18

1x For details on the air interface, refer to C.S0005 [8]. 19

A1 This interface carries signaling information between the mobility management functions 20

of the circuit-switched MSC and the call control component of the macro BS. 21

A1p This interface carries signaling information between the mobility management functions 22

of the MSCe and the call control component of the macro BS. 23

A2 This interface is used to provide a path for user traffic. The A2 interface carries 64/56 24

kbps PCM information (for circuit-oriented voice) or 64 kbps Unrestricted Digital 25

Information (UDI, for ISDN) between the circuit-switched MSC and the BS. 26

A2p This interface provides a path for packet-based user traffic sessions. The A2p interface 27

carries bearer information via IP packets between the Media Gateway (MGW) and the 28

BS. 29

A12 The A12 interface carries signaling information related to access authentication and 30

Femtocell Access Control authorization between the FAP and the AN Authentication, 31

Authorization and Accounting (AN-AAA) entity. 32

Fx1 For details on the bearer interface between the FAP and the MGW, refer to X.S0059-000 33

[15]. 34

Fx2 For details on the signaling interface between the FAP and the IMS, refer to X.S0059-000 35

[15]. 36

Fx3 For details on the IPsec tunnel between the FAP and the SeGW refer to X.S0059-000 37

[15]. 38

Fm The Fm interface enables auto-configuration of the FAP by the FMS. Refer to X.R0063 39

[I-1] and X.S0059-000 [15]. 40

1.4.2 Femtocell IOS-based 1x Voice Architecture 41

Figure 1.4.2-1 and Figure 1.4.2-2 show the RAN reference architecture for IOS-based 1x access from a 42

FAP with the support of the A1p/A2p and the A1/A2 interfaces, respectively. 43

3GPP2 A.S0024-A v1.0

1-7

A1p

1x FAP1x

IPsec tunnel (Fx3)

Macro

BS

MSCe

MS

SeGW

FGW

A1p

FMS

Fm

A1pA2p

A2pMGWA2p

A25

AN-AAA

A12

1

Figure 1.4.2-1 Femtocell IOS-based 1x Voice Architecture with A1p/A2p Interfaces 2

3

A2

1x FAP1x

IPsec tunnel (Fx3)

Macro

BSMSC

MS

SeGW

FGW

A1

FMS

Fm

A1p

A2p

A1

A25

AN-AAA

A12

MGWA2

4

Figure 1.4.2-2 Femtocell IOS-based 1x Voice Architecture with A1/A2 Interfaces 5

1.4.2.1 Femtocell 1x IOS-based RAN Network Entities 6


AN-AAA The AN Authentication, Authorization and Accounting server may perform access 8

control authorization for the 1x FAP. 9

BS The macro base station (BS) is an entity in the public radio telecommunications system 10

used for radio telecommunications with an MS. The macro BS connects to an MSC via 11

the A1 and A2 interfaces. The macro BS connects to an MSCe and MGW via the A1p 12

and A2p interfaces. 13


spectrum to connect a mobile station (MS) to the operator‟s network through the public 15

Internet infrastructure. 16

FGW The Femtocell Gateway (FGW) provides aggregation, proxy, conversion and routing 17

functions for a FAP to access services within an operator‟s network 18

FMS The Femtocell Management System (FMS) is a network entity residing in an operator's 19

network that aids in FAP auto-configuration before the FAP can provide services. 20

MGW The Media GateWay (MGW) provides an interface between the packet environment of 21

the Core Network and the circuit switched environment of the PSTN for bearer traffic, 22

when equipped with circuit capabilities. The MGW provides vocoding and/or transcoding 23

functions to the bearer traffic if the FGW connects to an MSC. The signaling interface 24

3GPP2 A.S0024-A v1.0

1-8

between the FGW and the MGW is to be specified in a future revision of this 1

specification. 2

MS The mobile station (MS) is an entity in the public cellular radio telecommunications 3

service intended to be used while in motion or during halts at unspecified points. 4

MSC/MSCe The Mobile Switching Center (MSC) may be either a circuit-switched MSC or an IP 5

based MSCe (emulation) and provides processing and control for calls and services. 6

SeGW The Femtocell Security Gateway (SeGW) provides for secure access for the FAP to 7

network operator services. Refer to X.S0059-000 [15]. 8

1.4.2.2 Femtocell 1x IOS-based RAN Interfaces 9



A1 This interface carries signaling information between the mobility management functions 12

of the circuit-switched MSC and the call control component of the FGW/macro BSC. 13

Refer to A.S0014 [5]. 14

A1p This interface carries signaling information between the mobility management functions 15

of the MSCe and the call control component of the macro BS. It also carries signaling 16

information between the mobility management functions of the MSCe and call control 17

component of the FGW, and between the FGW and the FAP. Refer to A.S0014 [5]. 18

A2 This interface is used to provide a path for user traffic. The A2 interface carries 64/56 19

kbps PCM information (for circuit-oriented voice) or 64 kbps Unrestricted Digital 20

Information (UDI, for ISDN) between the circuit-switched MSC and the FGW/macro BS. 21

A2p This interface provides a path for packet-based user traffic sessions. The A2p interface 22

carries voice information via IP packets between the Media Gateway (MGW) and the 23

FAP/macro BS. 24

A12 The A12 interface carries signaling information related to access authentication and 25

Femtocell Access Control authorization between the FAP and the AN-AAA entity. 26

A25 This interface carries signaling information between the FAP and the FGW for FAP 27

registration with the FGW and macro 1x BS active handoff to the FAP. 28

Fx3 For the details on the IPsec tunnel between the FAP and the SeGW refer to X.S0059-000 29

[15]. 30


[I-1] and X.S0059-000 [15]. 32

3GPP2 A.S0024-A v1.0

1-9

1.4.2.3 Protocol Stack 1

The Femtocell 1x IOS-based protocol stack for the A1p/A2p interface is depicted as follows. 2

MS FAP

IOS

(A1p+A25)

SUA

SCTP

L3

Signaling

IP/IPSec

LAC

MAC

L2

Phy L1

L3

Signaling

LAC

MAC

Phy

FGW

IOS

(A1p+A25)

SUA

SCTP

IP

L2

L1

SUA

SCTP

IP

L2

L1

IOS

(A1p)

SUA

SCTP

IP

L2

L1

MSCe

IP/IPsec

L2

IP

L2

SeGW

L1 L1

IOS

(A1p)

3

Figure 1.4.2.3-1 Femtocell 1x IOS-Based Protocol Reference Model-Control Plane 4

RTP

UDP

IP/IPsec

L1/L2

Voice

CDMA2000

air

FAP SeGW

Voice

CDMA2000

air

MS FGW MGW

IP/IPsec

L1/L2

IP

L1/L2

RTP

UDP

IP

L1/L2

IP

L1/L2

5

Figure 1.4.2.3-2 Femtocell 1x IOS-Based Protocol Reference Model- User Plane 6

The Femtocell 1x IOS-based protocol stack for the A1/A2 interface is depicted as follows. 7

MS FAP

IOS

(A1p+A25)

SUA

SCTP

L3

Signaling

IP/IPSec

LAC

MAC

L2

Phy L1

L3

Signaling

LAC

MAC

Phy

FGW

IOS

(A1p+A25)

SUA

SCTP

IP

L2

L1

SCCP

MTP

L1

IOS

(A1)

SCCP

MTP

L1

MSC

IP/IPsec

L2

IP

L2

SeGW

L1 L1

IOS

(A1)

8

Figure 1.4.2.3-3 Femtocell 1x IOS-Based Protocol Reference Model-Control Plane 9

RTP

UDP

IP/IPsec

L1/L2

Voice

CDMA2000

air

FAP SeGW

Voice

CDMA2000

air

MS FGW MSC

IP/IPsec

L1/L2

IP

L1/L2

RTP

UDP

IP

L1/L2

PCM

L1

PCM

L1

10

Figure 1.4.2.3-4 Femtocell 1x IOS-Based Protocol Reference Model- User Plane 11

3GPP2 A.S0024-A v1.0

1-10

1.4.3 Femtocell 1x and HRPD Packet Data 1

Figure 1.4.3-1 shows the reference architecture for 1x packet data access from a FAP. Figure 1.4.3-2 2

shows the reference architecture for HRPD packet data access from a FAP. 3

FGW

IPsec tunnel

MS

Macro 1x BS/

PCF

A11A10

SeGW

1xA11

PDSN

FMS

Fm

A101x FAP

A12

AN-AAA

4

Figure 1.4.3-1 Femtocell 1x Packet Data Architecture 5

FGWIPsec tunnel

PDSN

Macro

HRPD

AN/PCF

A12A11

A10

SeGW

HRPD

FAP

A12

Fm

HRPD

AN-AAAFMS

AT A13

A16

A24

A10

A11

A26

6

Figure 1.4.3-2 Femtocell HRPD Packet Data Architecture 7

1.4.3.1 Femtocell 1x and HRPD RAN Packet Data Network Entities 8


AN The Access Network is a logical entity in the HRPD RAN used for radio communications 10

with the AT. 11

AN-AAA The AN Authentication, Authorization and Accounting server performs access 12

authentication, Femtocell Access Control (FAC) authorization and Local IP Access 13

(LIPA) authorization functions for the RAN. 14

AT The Access Terminal (AT) is a device providing data connectivity to a user. 15

BS The macro base station is an entity in the public radio telecommunications system used 16

for radio telecommunications with MSs. 17


spectrum to connect an AT to the operator‟s network through the public Internet 19

infrastructure. 20

FGW The Femtocell Gateway (FGW) is an entity residing in an operator‟s network that 21

provides aggregation, proxy and registration functions for the FAP to access network 22

operator services. A10, A11, A13, A16, A12 and A24 interfaces may pass transparently 23

through the FGW. 24

3GPP2 A.S0024-A v1.0

1-11


network that aids in FAP auto-configuration before the FAP can provide services. 2

MS The mobile station is an entity in the public cellular radio telecommunications service 3

intended to be used while in motion or during halts at unspecified points. 4

PCF The Packet Control Function (PCF) is an entity in the RAN that manages the relay of 5

packets between the BS or AN and the PDSN. 6

PDSN The Packet Data Serving Node (PDSN) is an entity that routes MS/AT originated or 7

MS/AT terminated packet data traffic. A PDSN establishes, maintains and terminates link 8

layer sessions to MS/ATs. 9

SeGW The Security Gateway (SeGW) is a network entity residing in an operator's network that 10

provides secure access for the FAP to the operator‟s network. Refer to X.S0059-000 [15]. 11

1.4.3.2 Femtocell 1x and HRPD RAN Packet Data Interfaces 12



A10 This interface carries user traffic between the FAP and the PDSN or between the PCF 15

and the PDSN. 16

A11 This interface carries signaling information between the FAP and the PDSN or between 17

the PCF and the PDSN. 18

A12 This interface carries signaling information related to access authentication between the 19

FAP or the AN/PCF and the AN-AAA. This interface may also be used for FAC 20

authorization (refer to section 1.6.1.6). 21

A13 This interface carries signaling information between the Session Control / Mobility 22

Management (SC/MM) function in the macro AN/PCF and the SC/MM function in the 23

FAP for idle state session transfer and inter-AN paging when the AT is in idle state. 24

A16 This interface carries signaling information between the macro AN and the FAP for 25

HRPD inter-AN connected state session transfer (hard handoff). 26

A24 This interface carries buffered user data between the macro AN/PCF and the FAP for an 27

AT, during A13 session transfer. 28

A26 This interface carries signaling information between the FAP and the FGW for FAP 29

registration with the FGW and macro AN active handoff to the FAP. 30


[I-1] and X.S0059-000 [15]. 32

HRPD For details on the air interface, refer to C.S0024 [9]. 33

34

3GPP2 A.S0024-A v1.0

1-12

1.4.4 Femtocell eHRPD Packet Data 1

Figure 1.4.4-1 shows the reference architecture for eHRPD packet data access from an eFAP. 2

FGWIPsec tunnel

HSGW

Macro

eAN/

ePCF

A12A11

A10

SeGW

eHRPD

eFAP

A12

Fm

eHRPD

AN-AAAFMS

eAT A13

A16

A24

A10

A11

A26

3

Figure 1.4.4-1 Femtocell eHRPD Packet Data Architecture 4

1.4.4.1 Femtocell eHRPD RAN Packet Data Network Entities 5

The entities identified in Figure 1.4.4-1 are defined as follows. 6

AN-AAA The AN Authentication, Authorization and Accounting server performs access 7

authentication, FAC authorization and LIPA authorization functions for the RAN. 8

eAN The Evolved Access Network (eAN) is a logical entity in the eHRPD RAN used for radio 9

communications with the eAT. 10

eAT The Evolved Access Terminal (eAT) is a device providing data connectivity to a user. 11

eFAP The Evolved Femtocell Access Point (eFAP) is a wireless access point operating in 12

licensed spectrum to connect an eAT to the operator‟s network through the public 13

Internet infrastructure. 14

ePCF The Evolved Packet Control Function (ePCF) is an entity in the RAN that manages the 15

relay of packets between the eAN and the HSGW. 16

FGW The Femtocell Gateway (FGW) is an entity residing in an operator‟s network that 17

provides aggregation, proxy and registration functions for the eFAP to access network 18

operator services. 19


network that aids in eFAP auto-configuration before the eFAP can provide services. 21

HSGW The HRPD Serving Gateway (HSGW) is an entity that routes eAT originated or eAT 22

terminated packet data traffic. An HSGW establishes, maintains and terminates link layer 23

sessions to eATs. 24

SeGW The Security Gateway (SeGW) is a network entity residing in an operator's network that 25

provides secure access for the eFAP to the operator‟s network. Refer to X.S0059-000 26

[15]. 27

1.4.4.2 Femtocell eHRPD RAN Packet Data Interfaces 28

The interfaces identified in Figure 1.4.4-1 are defined as follows. 29

A10 This interface carries user traffic between the eFAP and the HSGW or between the ePCF 30

and the HSGW. 31

3GPP2 A.S0024-A v1.0

1-13

A11 This interface carries signaling information between the eFAP and the HSGW or between 1

the ePCF and the HSGW. 2

A12 This interface carries signaling information related to access authentication between the 3

eFAP or the eAN/ePCF and the AN-AAA. This interface may also be used for FAC 4

authorization (refer to section 1.6.1.6). 5

A13 This interface carries signaling information between the Session Control/Mobility 6

Management (SC/MM) function in the macro eAN/ePCF and the SC/MM function in the 7

eFAP for idle state session transfer and inter-eAN paging when the eAT is in idle state. 8

A16 This interface carries signaling information between the macro eAN and the eFAP for 9

eHRPD inter-eAN connected state session transfer (hard handoff). 10

A24 This interface carries buffered user data between the macro eAN/ePCF and the eFAP for 11

an eAT, during A13 session transfer. 12

A26 This interface carries signaling information between the eFAP and the FGW for eFAP 13

registration with the FGW and macro eAN active handoff to the eFAP. 14

Fm The Fm interface enables auto-configuration of the eFAP by the FMS. Refer to X.R0063 15

[I-1] and X.S0059-000 [15]. 16

eHRPD For details on the air interface, refer to C.S0087 [10]. 17

1.4.5 HRPD LIPA 18

HRPD Local IP Access is specified in X.S0059-100 [16] 19

1.5 IOS Femtocell Assumptions 20

The following assumptions apply to this document. 21

1. The SIP-based 1x voice FAP contains a SIP client that converts 1x signaling and user plane packets 22

to/from SIP signaling and RTP traffic, respectively. 23

2. The IOS-based 1x voice FAP functions as a 1x base station subsystem and provides A1p-based 24

Femtocell IOS Application Protocol (FIAP), A2p, and A25 interfaces to the FGW. Refer to X.S0059-25

000 [15] for a description of FIAP. 26

3. The IOS-based 1x FGW functions as a BSC and provides the A1/A2 or A1p/A2p interface to the 27

MSC/MSCe or MGW. 28

4. Each FAP connects to one and only one SeGW at a time. 29

5. Each FAP connects to one and only one FMS at a time. 30

6. Each SIP-based 1x voice FAP is assigned a Cell_ID of type 07H (refer to A.S0014 [5]). The MSC_ID 31

of the Cell_ID corresponds to the Femtocell Convergence Server (FCS) with which the FAP 32

communicates. Refer to X.S0059-200 [17]. 33

7. The 1x packet data/HRPD FAP contains PCF functionality. 34

8. Each FAP communicates with the core network entities in the operator‟s network through the SeGW. 35

9. The PN offset broadcast by the 1x or HRPD FAP may not be unique; it is possible for multiple FAPs 36

within the coverage area of a single macro BS/AN to have the same PN offset. 37

10. An AN-AAA acting as an enforcement point requires FEID support in the FAP. 38

3GPP2 A.S0024-A v1.0

1-14

1.6 Feature Descriptions 1

This section describes the features identified in the overview in section 1.1. 2

1.6.1 Explicitly Supported Features 3

1.6.1.1 FAP Power-up 4

This feature supports FAP power-up and initialization, including neighborhood discovery, network 5

discovery and configuration. 6

1.6.1.2 1x Dormant Handoff Between the Macro BS and the FAP 7

This feature supports handoff of an idle MS between the macro BS and the FAP. 8

1.6.1.3 1x Active Handoff Between the Macro BS and the FAP 9

This feature supports handoff of an active MS between the macro BS and the FAP. 10

1.6.1.4 HRPD Dormant Handoff Between the Macro AN/PCF and the FAP 11

This feature supports handoff of an idle AT between the macro AN/PCF and the FAP. 12

1.6.1.5 Connected State Session Transfer Between the FAP and the Macro AN 13

This feature supports handoff of an active AT between the FAP and the macro AN. 14

1.6.1.6 Femtocell Access Control 15

This feature allows a FAP to be able to control which MS/AT can register or receive services from the 16

FAP. A FAP can be configured to have one of the following types of access association. 17

Open Access2: any MS/AT can access and receive services from the FAP. However, LIPA service 18

may be further controlled by the AN-AAA. Refer to X.S0059-100 [16]. 19

Signaling Access: any MS/AT can access and register with the FAP, i.e., the MS/AT is 20

reachable/pageable. However, the MS/AT that is not on the access control list (ACL) may be 21

redirected to a macro BS or AN when it attempts to establish a traffic connection. 22

Restricted Access: only an MS/AT that is on the ACL is allowed to access or register. The FAP does 23

not complete the registration process of any MS/AT that is not on the access control list. 24

This specification explicitly supports the FAP being an enforcement point for a 1x MS or HRPD AT 25

where the ACL is provided by the FMS. This specification also explicitly supports the AN-AAA being an 26

enforcement point for the HRPD FAP. 27

This specification transparently supports other core network entities being enforcement points for both 1x 28

and HRPD. 29

Note that emergency services (e.g., global emergency call) may be exempt from Femtocell access control, 30

based on operator policy. 31

1.6.1.7 1x OOB Indication of MS Detection 32

This feature allows a FAP that can detect, via out-of-band (OOB) mechanism, an authorized MS in its 33

proximity to indicate this detection to the FGW or FCS, to disambiguate the target FAP during active 34

hand-in. 35

2 Open, Signaling and Restricted Access may also be referred to as Open, Signaling and Restricted Association.

3GPP2 A.S0024-A v1.0

2-15

1

2 Requirements and Procedures 2

This section describes the requirements and procedures associated with this specification. 3

2.1 Femtocell Requirements 4

This section describes the requirements associated with this specification. 5

2.1.1 SIP-based 1x RAN Femtocell Requirements 6

The requirements for a SIP-based 1x RAN Femtocell are specified in X.S0059-200 [17]. 7

2.1.2 IOS-based 1x RAN Femtocell Requirements 8

2.1.2.1 IOS Signaling Routing 9

The number of cells that the MSC/MSCe supports may be limited. In this case, multiple FAPs can share 10

the same cell ID under the MSC/MSCe. The FGW shall maintain a mobility context for each MS attached 11

to a FAP, and uses the mobility context to route downlink IOS signaling from the MSC/MSCe to the 12

appropriate FAP. 13

When the FGW receives the first Complete Layer 3 Information message from an MS via the FAP, the 14

FGW shall send the Complete Layer 3 Information message to the MSC/MSCe and set up the mobility 15

context including the MS‟s identity and the FAP‟s identity, if the MS registers with the MSC/MSCe 16

successfully. Otherwise, the FGW shall clear the mobility context entry for the MS. The FGW shall 17

maintain the mobility context when a mobility event occurs. When a connectionless downlink IOS 18

signaling message (e.g., a Paging Request or ADDS Page message) is received by the FGW, the FGW 19

determines the target FAP based on the mobility context. 20

Connection oriented IOS signaling messages are routed over the SUA/SCCP signaling connection 21

identified by the Source/Destination Reference Number or the Local Reference Number. 22

If the FGW detects an underlying transport layer failure between the FAP and the FGW, the FGW shall 23

send a Clear Request message for each active MS associated with the corresponding FAP to the 24

MSC/MSCe and start an instance of timer T300 to wait for each corresponding Clear Command message 25

from the MSC/MSCe. Upon receiving each Clear Command message from the MSC/MSCe the FGW 26

shall stop timer T300 and send a Clear Complete message to the MSC/MSCe. The FGW also clears the 27

mobility context of the MS. The FAP should release the call for the MS when the FAP detects the 28

transport layer failure to the FGW. 29

When the FGW receives a Handoff Request message from the MSC/MSCe, the FGW may determine the 30

target FAP based on the A25 measurement procedure (refer to section 3.3.7.2.4), and route the Handoff 31

Request message to the target FAP. When the handoff procedure successfully occurs, the FGW 32

establishes the mobility context for the MS. When the FGW can not identify the target FAP, the FGW 33

shall send a Handoff Failure message to the MSC/MSCe. 34

When the FGW receives a Handoff Required message from the FAP and the FGW determines that the 35

target cell is a FAP under control of the same FGW then the FGW sends a Handoff Request message to 36

the target FAP. If the FGW determines that the target cell is not a FAP under control of the same FGW, 37

then the FGW sends a Handoff Required message to the MSC/MSCe. 38

2.1.2.2 Cell ID Aggregation 39

The FGW is identified to the MSC/MSCe using one or more unique Cell IDs. The number of FAPs 40

supported by an FGW may exceed the number of available Cell ID values, and in this case the Cell ID 41

3GPP2 A.S0024-A v1.0

2-16

value used in A1p messages sent between the FGW and the supported FAPs are not unique. The FGW is 1

responsible for correlating the unique Cell ID used by the MSC/MSCe to the potentially non-unique Cell 2

ID used by the FAPs, together with internal knowledge of FAP registration information, signaling tunnel 3

endpoints, etc. Also refer to section 2.1.2.4. 4

2.1.2.3 UZID Aggregation 5

The FGW may map the UZID coming from the FAP to a user zone sent to the MSC/MSCe on the 6

A1/A1p interface. This mapping is not specified in this document. 7

2.1.2.4 Transport Layer Requirements 8

For SUA and SCCP protocol descriptions, refer to A.S0012 [3]. 9

For the first signaling connection initiated by the FAP, FAP shall set the DRN value to zero. For the first 10

signaling connection initiated by the FGW, FGW shall set the DRN value to zero. Both the FAP and the 11

FGW shall maintain the mapping info between DRN and SRN to identify the signaling connection 12

between the FAP and the FGW. 13

For the first signaling connection initiated by the FGW, FGW shall set the DLR value to zero. For the 14

first signaling connection initiated by the MSC, MSC shall set the DLR value to zero. Both the FGW and 15

the MSC shall maintain the mapping info between DLR and SLR to identify the signaling connection 16

between the FGW and the MSC. 17

2.1.2.4.1 Use of SUA for A1p 18

The SUA protocol is used between FAP and FGW, and between FGW and MSCe. The SUA 19

Source/Destination Reference Number (SRN/DRN) is a four-byte element internally chosen by the 20

MSCe, FGW or FAP to uniquely identify a signaling connection between the FAP and the FGW, or 21

between the FGW and the MSCe. 22

Referring to Figure 2.1.2.4.1-1, in the FAP to FGW direction, the SRN is chosen by the FAP. The Source 23

Address is set to the FAP‟s IP address assigned by the SeGW and the Destination Address is set to the 24

FGW‟s IP address. In the FGW to FAP direction, the SRN is chosen by the FGW. The Source Address is 25

set to the FGW‟s IP address and the Destination Address is set to the FAP‟s IP address. In the FGW to 26

FAP direction, the FGW echoes the FAP SRN in the DRN field. In the FAP to FGW direction, the FAP 27

echoes the FGW SRN in the DRN field. Note that it is the responsibility of the FAP and the FGW to 28

ensure that no two calls have identical SUA local reference numbers. 29

DRN (FGW), SRN (FAP)

Src addr (FAP), Dst addr (FGW)

DRN (FAP), SRN (FGW)

Src addr (FGW), Dst addr (FAP)

SRN: Source Reference Number

DRN: Destination Reference Number

FGWFAP

30

Figure 2.1.2.4.1-1 DRN/SRN and Source/Destination Address Usage Between FAP and FGW 31

Referring to Figure 2.1.2.4.1-2, in the FGW to MSCe direction, the SRN is chosen by the FGW. The 32

Source Address is set to the FGW‟s IP address and the Destination address is set to the MSCe‟s IP 33

address. In the MSCe to FGW direction, the SRN is chosen by the MSCe. The Source Address is set to 34

the MSCe‟s IP address and the Destination address is set to the FGW‟s IP address. In the MSCe to FGW 35

direction, the MSCe echoes the FGW SRN in the DRN field. In the FGW to MSCe direction, the FGW 36

echoes the MSCe SRN in the DRN field. Note that it is the responsibility of the FGW and the MSCe to 37

ensure that no two calls have identical SUA local reference numbers. 38

3GPP2 A.S0024-A v1.0

2-17

DRN (MSCe), SRN (FGW)

Src addr (FGW), Dst addr (MSCe)

DRN (FGW), SRN (MSCe)

Src addr (MSCe), Dst addr (FGW)

SRN: Source Reference Number

DRN: Destination Reference Number

MSCeFGW

1

Figure 2.1.2.4.1-2 DRN/SRN and Source/Destination Address Usage Between FGW and MSCe 2

2.1.2.4.2 Use of SCCP for A1 3

The SCCP protocol is used between the FGW and the MSC. The SCCP Source/Destination Local 4

Reference (SLR/DLR) number is a three-byte element internally chosen by the MSC or the FGW to 5

uniquely identify a signaling connection. 6

Referring to Figure 2.1.2.4.2-1, in the FGW to MSC direction, the SLR is chosen by the FGW. The 7

Source Point Code (SPC) is set to the FGW‟s signaling point code and the Destination Point Code (DPC) 8

is set to the MSC‟s signaling point code. In the MSC to FGW direction, the SLR is chosen by the MSC. 9

The SPC is set to the MSC‟s point code and the DPC is set to the FGW‟s point code. In the MSC to FGW 10

direction, the MSC echoes the FGW SLR in the DLR field. In the FGW to MSC direction, the FGW 11

echoes the MSC SLR in the DLR field. Note that it is the responsibility of the FGW and the MSC to 12

ensure that no two calls have identical SCCP local reference numbers. 13

DLR (MSC), SLR (FGW)

SPC (FGW), DPC (MSC)

DLR(FGW), SLR(MSC)

SPC(MSC), DPC(FGW)

SLR/DLR: Source/Destination Local Reference

SPC/DPC: Source/Destination Point Code

MSCFGW

14

Figure 2.1.2.4.2-1 SLR/DLR and SPC/DPC Usage Between FGW and MSC 15

2.1.3 1x Packet Data and HRPD Femtocell Requirements 16

2.1.3.1 Security Association for 1x and HRPD Packet Data Femtocells 17

The 1x or HRPD packet data FAP shall maintain a security context for the PDSN to which it is attached. 18

This context consists of an authentication algorithm and mode, a secret (shared key or appropriate 19

public/private key pair), and a style of replay protection in use. This context is used to populate the 20

Mobile-Home Authentication Extension and Registration Update Authentication Extension Information 21

Elements (IEs). Refer to A.S0017 [6] for more information. 22

23

2.2 1x Packet Data Support 24

Upon receiving a 1x Origination or 1x Enhanced Origination Message from the MS with the service 25

option set to 0x21H (i.e., SO 33), the FAP may acknowledge the message from the MS as described in 26

C.S0005 [8]. If the FAP acknowledges the 1x origination and the MS is already 1x registered via the FAP, 27

the FAP shall establish or perform service option negotiation procedures over the traffic channel (to 28

support SO 33) with the MS directly and follow the BS procedures specified in A.S0017 [6] for setup of 29

the A10 with the PDSN. Otherwise, if the MS is not registered via the FAP, the FAP shall perform the 30

MS registration procedures as specified in X.S0059-200 [17] or section 4.3.1 and after successful 31

registration, establish the traffic channel (to support SO 33) with the MS directly and follow the BS 32

procedures in A.S0017 [6] for setup of the A10 with the PDSN. 33

3GPP2 A.S0024-A v1.0

2-18

2.3 eHRPD Femtocell Operation 1

The eFAP shall follow the FAP procedures and assumptions in this specification and in X.S0059 [15], 2

[16], [17] with the exception of the following operations. 3

The eFAP shall follow the eAN procedures specified in A.S0022 [7] and X.S0057 [14] for eHRPD 4

systems that interwork with the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 5

and Evolved Packet Core (EPC). 6

The eFAP shall follow the eAN procedures as specified in C.S0087 [10] to interface with the eAT. 7

Active handoff between the eFAP and the E-UTRAN is not specified. 8

2.4 Femtocell Access Control 9

This section describes the requirements and procedures to support Femtocell Access Control (FAC). 10

2.4.1 Femtocell Access Control Authorization and Enforcement Points 11

The Femtocell access control authorization point performs a comparison between the identity of the 12

MS/AT and the authorized identities on the ACL. The Femtocell access control enforcement point, based 13

on the authorization results, may subsequently deny services to MS/ATs not present on the ACL. 14

This specification explicitly supports the FAP being the enforcement and authorization point for the 1x 15

MS and the HRPD AT where the ACL is provided by the FMS. This specification also explicitly supports 16

the AN-AAA being an authorization point for the HRPD FAP and 1x FAP. For the 1x FAP, the actual 17

authorization entity (e.g., Femtocell AAA, AN-AAA) is left as an implementation issue. 18

2.4.2 Access Control List 19

An ACL consists of the list of MSs or ATs that are allowed access on the FAP. Each entry in the ACL 20

contains an identity of either an MS or an AT. For example, the identity can be one of the following: 21

IMSI, MEID, ESN, or NAI used in the CHAP response on the access stream. The FAP requirements and 22

procedures when an MS or AT outside of the ACL tries to access the FAP are based on its access 23

association type described in section 1.6.1.6 and is outside the scope of this specification. 24

A FAP may be configured with the ACL and its access association type by the FMS (refer to X.R0063 [I-25

1]). 26

2.4.3 1x Femtocell Access Control 27

For 1x, the FAP, the AN-AAA, or both may be the FAC authorization point and the FAP is the enforce-28

ment point. 29

2.4.3.1 AN-AAA as 1x Authorization Point 30

When the AN-AAA is to perform the FAC authorization point function, it associates the ACL with the 31

FAP through its Femtocell Equipment Identifier (FEID). If an FEID is supported in the FAP, then the 32

FAP shall also include the FEID in the Access-Request message sent on the A12 interface to the AN-33

AAA, for FAC. The Access-Request, Access-Accept and Access-Reject shall include the Message-34

Authenticator attribute for protecting the integrity of the RADIUS message. Refer to X.S0011 [13]. In 35

addition, for an AN-AAA to recognize that the transaction is for 1x access authorization, the Access-36

Request message shall contain the “HRPD Access Authentication and 1x Access Authorization” attribute 37

set to 1x Access Authorization (refer to section 3.3.3.1.2). 38

When the MS attempts to access the FAP (e.g., to register or originate a call), the FAP sends an Access-39

Request to the AN-AAA on the A12 interface. Refer to section 3.3.3.1.2 and RFC 3576 [20] for A12 40

interface procedures. The AN-AAA, does not perform access authentication, however it verifies through 41

the 1x ACL that the MS is authorized to receive services through the FAP. If the MS is allowed to receive 42

services through the FAP, the AN-AAA returns an Access-Accept message on the A12 interface in 43

3GPP2 A.S0024-A v1.0

2-19

accordance with RFC 2865 [19]. If the MS is not allowed to receive services through the FAP (e.g., the 1

MS is not on the FAP ACL), the AN-AAA returns an Access-Accept message on the A12 interface (in 2

accordance with RFC 2865 [19]) including the Femtocell-Access-Control-Authorization attribute. Refer 3

also to section 3.3.3.1.1. 4

2.4.4 HRPD Femtocell Access Control 5

For HRPD, the FAP, the AN-AAA, or both may be the FAC authorization point and the FAP is the 6

enforcement point. 7

2.4.4.1 AN-AAA as HRPD FAC Authorization Point 8

When the AN-AAA is to perform the FAC authorization point function, it associates the ACL with the 9

FAP through its FEID. If an FEID is supported in the FAP, then the FAP shall also include the FEID in 10

the Access-Request message sent on the A12 interface. 11

When the AT returns a CHAP response message (refer to Section 3.1.1 in A.S0008 [1], or A.S0009 [2]), 12

the FAP forwards the response along with its FEID in an Access-Request message to the AN-AAA on the 13

A12 interface. Refer to section 3.3.3 for A12 interface procedures. The AN-AAA, in addition to 14

performing access or terminal authentication, verifies through the HRPD ACL that the AT is authorized 15

to receive services through the FAP. If the AT passes authentication and is allowed to receive services 16

through the FAP, the AN-AAA returns an Access-Accept message on the A12 interface in accordance 17

with RFC 2865 [19]. However if the AT passes authentication and is not allowed to receive services 18

through the FAP (e.g., the AT is not in the FAP ACL), the AN-AAA returns an Access-Accept message 19

on the A12 interface (in accordance with RFC 2865 [19]) including the Femtocell-Access-Control-20

Authorization attribute. Refer also to section 3.3.3.1.1. Otherwise, if the AT fails authentication, the AN-21

AAA sends an Access-Reject message on the A12 interface in accordance with RFC 2865 [19]. 22

2.5 LIPA Requirements and Procedures 23

Local IP Access requirements and procedures are specified in X.S0059-100 [16]. 24

25

3GPP2 A.S0024-A v1.0

2-20

1

(This page intentionally left blank) 2

3

3GPP2 A.S0024-A v1.0

3-1

3 Femtocell Interfaces 1

This section describes the interface requirements for the FAP. 2

3.1 FGW and RAN Interfaces 3

Messages from all interfaces in section 1.4.3 that pass through the FGW (i.e., A10, A11, A12, A13, A16, 4

A24, A26) may: 5

1. be intercepted and regenerated, 6

2. be passed through without modification, or 7

3. bypass the FGW. 8

Whether this occurs is implementation-specific except where it is explicitly indicated. 9

3.2 SIP-based FAP to Core Network Interface 10

The SIP-based FAP communicates with the core network using the Fm, Fx1 and Fx2 interfaces. Refer to 11

X.S0059-200 [17]. The Fx2 signaling interface is based on IEs defined for the A1 interface. New 12

messages are defined in A1 format in this specification to support the Fx2 interface. The new messages 13

defined in this specification are not sent or received by the macro BS. Instead, the Fx2 interface uses the 14

Message Type and IEs defined in these messages (refer to section 5.2.1) according to the procedures in 15

X.S0059-200 [17] to support. Femtocell-specific capabilities (e.g., 1x active hand-in). 16

3.2.1 A1 Formatted Messages Used on Fx2 17

This section describes the message procedures used between the SIP-based FAP and the FCS for the 18

following messages: 19

Measurement Request 20

Measurement Response 21

Femtocell Supplementary Info 22

MS OOB Indication 23

24

3.2.1.1 Measurement Procedures 25

3.2.1.1.1 Measurement Request 26

This Base Station Mobile Application Part (BSMAP) message allows the FCS to request candidate FAPs 27

(e.g., FAPs with the same PN offset reported by an MS) to provide signal strength measurements for 28

determining the target FAP for handoff of the existing MS connection. 29

Note: FAP measurement requests are not supported for IS-95 or 3x IS-2000 channels. 30

3.2.1.1.1.1 Successful Operation 31

If a handoff is required and the FCS can not uniquely identify the target FAP, the FCS may send a 32

Measurement Request message to candidate FAPs for handoff measurement requests. The FCS 33

determines the candidate FAPs based on information in the FacilitiesDirective2 (FACDIR2) message. 34

Refer to X.S0059-200 [17]. 35

The FCS shall include the Downlink Radio Environment, CDMA Serving One Way Delay and MS 36

Measured Channel Identity IEs if received in the FACDIR2 message. 37

The IS-2000 Channel Identity IE shall be included to provide MS physical channel information. 38

3GPP2 A.S0024-A v1.0

3-2

The Long Code IE shall be included in the Measurement Request message and based on the FACDIR2 1

message, set to the received Public Long Code Mask (PLCM), the Electronic Serial Number (ESN) 2

derived PLCM or the received Private Longcode value. 3

The Mobile Identity IE should be included if the FAP is the access control enforcement point. 4

Upon sending this message to one or multiple FAPs, the FCS starts one instance of timer Tmr-1 to await 5

the arrival of the corresponding Measurement Response message(s). Note that if Measurement Request 6

messages are sent to multiple FAPs, the FCS should consider the responses from multiple FAPs before 7

selecting the target FAP for handoff. The duration that the FCS should wait for responses from FAPs 8

should be large enough to account for the round-trip delay between the FCS and any of the candidate 9

FAPs plus the value of the Measurement Response Timer field in the Measurement Response Options IE. 10

The FCS may receive an MS OOB Indication message from a FAP instead of a Measurement Response 11

message. Refer to section 3.2.1.1.4. If an MS OOB Indication message is received by the FCS from a 12

FAP indicating the presence of the MS before it receives measurement responses from each FAP, the FCS 13

may select the indicated FAP for handoff and proceed without waiting for other Measurement Response 14

messages. 15

Refer also to section 5.1.1.1, Measurement Request, for the format and content of this message. 16

3.2.1.1.1.2 Failure Operation 17

If timer Tmr-1 expires and the FCS did not set either the Low Signal Report Suppression bit or the Error 18

Report Suppression bit in the Measurement Response Options IE for a non responsive FAP, the FCS may 19

re-determine the candidate FAPs and repeat the measurement request procedure. If the Measurement 20

Response or MS OOB Indication message is not received, the FCS shall terminate the measurement 21

request procedure with the FAP. Note that Tmr-1 should be larger than the Measurement Response Timer 22

field in the Measurement Response Options IE. 23

Refer also to X.S0059-200 [17]. 24

3.2.1.1.2 Measurement Response 25

This BSMAP message allows the candidate FAP to respond to a Measurement Request message from the 26

FCS. Upon receipt of a Measurement Request message, the candidate FAP shall verify whether or not the 27

MS identifier is on the ACL, perform the requested measurement procedures if possible, and shall 28

respond to the FCS with a Measurement Response message if any of the following conditions are true: 29

The measurement is successful and the result is above the operator‟s configurable threshold. 30

The measurement is successful, the result is below the operator‟s configurable threshold and the Low 31

Signal Report Suppression bit in the Measurement Request message is set to „0‟. 32

The measurement is not successful (i.e., Cause value of the Measurement Response message is not 33

„Measurement successful‟) and the Error Report Suppression bit in the Measurement Request 34

message is set to „0‟. 35

Note: The definition of the operator‟s configurable threshold is outside the scope of this specification. 36

If the FAP detects the out-of-band presence of the specified MS, the FAP may send an MS OOB 37

Indication message to the FCS instead of a Measurement Response message. Refer to section 3.2.1.1.4. 38


This message is sent by the FAP to the FCS in response to a Measurement Request message, and shall 40

include the Long Code IE set to the value received in the corresponding Measurement Request message, 41

the Cause value and a measurement report, if available. 42

If the MS is allowed to utilize FAP resources and a measurement is successfully made, the FAP shall 43

respond with a „Measurement successful‟ Cause value and the measurement report. 44

3GPP2 A.S0024-A v1.0

3-3

If the MS is not allowed to utilize FAP resources, the FAP shall make and include the requested 1

measurement if possible and respond with the Cause value set to „MS not allowed‟. 2

If a measurement is attempted and the MS is not detected, the FAP shall respond with an „MS not 3

detected‟ Cause value. 4

If the FAP determines there is not sufficient time to make a satisfactory measurement before 5

expiration of the measurement response timer, the FAP shall set the Cause value to „Measurement 6

procedure time-out‟ and may include a measurement report. 7

If the FAP is not capable of providing signal strength measurements, the FAP shall respond with the 8

Cause value, „BS not equipped‟. 9

If the FAP is unable to provide measurements at this time due to other on-going procedures, the FAP 10

shall respond with the Cause value „BS busy‟. 11

For equipment and/or interface failure, resource availability or OAM&P intervention, the FAP shall 12

include the appropriate Cause value. 13

Upon receipt of this message for all corresponding Measurement Request messages sent, the FCS stops 14

timer Tmr-1. Refer also to section 5.1.1.2, Measurement Response, for the format and content of this 15

message. 16


None. 18

3.2.1.1.3 Femtocell Supplementary Info 19

This BSMAP message allows the FCS and FAP to exchange Femtocell related information in support of 20

IOS messaging. 21

3.2.1.1.3.1 Successful FCS Operation 22

When the FCS chooses to update the GLOBAL_RAND_KEY at the FAP, it shall send this message with 23

the new key contained in the Global RAND Key IE. The IE contains the GLOBAL_RAND_KEY that the 24

FAP shall use to generate and broadcast the Global RAND. Refer to S.S0132 [11]. 25

When the FCS sends a Location Updating Accept message to the FAP (i.e., the MS successfully registers 26

via the FAP), the FCS may also send a Femtocell Supplementary Info message with the Called Party 27

BCD Number IE included and set to the Mobile Directory Number (MDN) of the MS, with the Type of 28

Number field set to “Unknown”. 29

Refer also to 5.1.1.3, Femtocell Supplementary Info, for the format and content of this message. 30

3.2.1.1.3.2 Successful FAP Operation 31

When the FAP successfully completes IMS registration, it shall send this message with the following IEs: 32

Cell Identifier List IE containing a list of IS-41 Cell Global Identifiers (ICGI) for neighboring cells in 33

the Cell Identifier List IE. 34

Pilot List IE containing the FAP‟s Pilot PN information. 35

This message should be sent any time the FAP determines that the neighboring cell information has 36

changed. This message shall also be sent any time the FAP‟s PN information is changed. 37

When the FAP generates a Global RAND and returns the MS response in the Authentication Response 38

Parameter IE of an IOS message (refer to A.S0014 [5]), the FAP shall also encapsulate in the same SIP 39

MESSAGE body a Femtocell Supplementary Info message with the Nonce IE set to the NONCE used by 40

the FAP to generate the Global RAND (refer to S.S0132 [11]) and the Authentication Response 41

Parameter IE. Refer also to X.S0059-200 [17]. 42

3GPP2 A.S0024-A v1.0

3-4

Refer also to 5.1.1.3, Femtocell Supplementary Info, for the format and content of this message. 1


None. 3

3.2.1.1.4 MS OOB Indication 4

This BSMAP message allows the FAP to provide an indication to the FCS that a particular MS has either 5

been detected out-of-band (OOB) or is no longer being detected OOB in the proximity of the Femtocell. 6


When a FAP detects the OOB presence (e.g., using another radio technology) of an MS on an active call 8

near the Femtocell, the FAP may invoke the MS OOB Indication procedure. When this procedure is 9

invoked, the FAP shall send an MS OOB Indication message to the FCS if the FAP is able to determine 10

the mapping of the OOB identification to either the MS IMSI, MEID or both. The FAP shall include one 11

of the MS‟s identifiers, may send both of these identifiers, and in addition may include the OOB identifier. 12

The FAP Identifier shall be set to the FAP‟s FEID and the OOB Indication Detected field shall be set to 13

„1‟ to indicate that the MS is detected OOB at the FAP. Upon receiving this message the FCS stops timer 14

Tmr-1, if it is running as a result of a Measurement Request message having been sent to this FAP. 15

When a FAP detects the lack of OOB presence of an MS that has been previously indicated as present to 16

the FCS in an MS OOB Indication message, the FAP should send an MS OOB Indication message. The 17

message shall include the same identifier(s) that were used in the corresponding previous MS OOB 18

Indication message sent to the FCS. The FAP ID shall be set to the FAP‟s FEID and the OOB Indication 19

Detected field shall be set to „0‟ to indicate that the MS is no longer detected OOB at the FAP. 20

Refer also to section 5.1.1.4, MS OOB Indication, for the format and content of this message. 21


None. 23

3.3 FAP RAN Interfaces 24

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

3.3.1 A1/A1p and A2/A2p Interfaces 26

Refer to A.S0014 [5]. 27

3.3.2 A10/A11 Interface 28

The number of PZIDs that the PDSN supports can be limited. In this case, multiple FAPs can share the 29

same PZID. The FGW may consolidate the A10/A11 connection to the PDSN onto the A10/A11 30

connections to the FAP. 31

Refer also to A.S0008 [1], A.S0009 [2] and A.S0017 [6]. 32

3.3.3 A12 Interface 33

If supported by the FAP and by operator policy (policy configured via FMS, refer to X.R0063 [I-1]), the 34

FAP shall include the FEID parameter in the Additional Accounting Parameter Attribute RADIUS 35

attribute (refer to X.S0059-100 [16]) in the Access Request message sent on the A12 interface. 36

For the 1x FAP, when the MS attempts to access the FAP, the FAP may send an Access-Request message 37

to the AN-AAA on the A12 interface (refer to RFC 2865 [19] and RFC 3576 [20]), containing: 38

3GPP2 A.S0024-A v1.0

3-5

User-Name (1)3 = MSID 1

NAS-IP-Address (4) = IP address assigned by the SeGW of FAP 2

Service-Type (6) = “Authorize Only” 3

If the attribute values received in the Access-Request are acceptable, the visited AN-AAA shall return an 4

Access-Accept message to the FAP on the A12 interface. 5

The general Vendor Specific Format for all 3GPP2 RADIUS attributes is defined in Figure 3.3.3.1-1. 6

Refer also to A.S0008 [1] and A.S0009 [2]. 7

3.3.3.1 A12 RADIUS Attribute Definition 8

This section defines the 3GPP2 vendor specific attribute for FAP support in this specification. The 9

general Vendor Specific Format is shown in Figure 3.3.3.1-1. The type and vendor ID are the same for 10

every attribute. The vendor-ID of 5535 (159FH) is used to indicate 3GPP2. Note that all integers are in 11

network byte order. 12

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 1

Type Length Vendor-ID

Vendor-ID (cont) Vendor-Type Vendor-Length

Vendor-Value

Figure 3.3.3.1-1 3GPP2 RADIUS Attribute Format 13

Values for the corresponding fields are specified in the following attribute sections. 14

3.3.3.1.1 Femtocell-Access-Control-Authorization 15

The Femtocell-Access-Control-Authorization Vendor Specific Attribute (VSA) contains information 16

related to Femtocell access control authorization. This attribute, shown in Figure 3.3.3.1-1, may be 17

included in the RADIUS Access-Accept message, sent from the AN-AAA in HRPD or 1x system to the 18

FAP on the A12 interface. 19

Type: 26 20

Length: 12 21

Vendor ID: 5535 22

Vendor-Length: 6 23

Vendor-Type: 217 24

Vendor-Value: 25

0: MS/AT is in the access control list of the Femtocell. 26

1: MS/AT is not in the access control list of the Femtocell. 27

All other values are reserved. 28

3 The numbers in this list correspond to the RADIUS attribute type defined in RFC 2865.

3GPP2 A.S0024-A v1.0

3-6

3.3.3.1.2 HRPD Access Authentication and 1x Access Authorization 1

The HRPD Access Authentication and 1x Access Authorization4: VSA indicates whether the Access 2

Request is in the context of HRPD access authentication or 1x access authorization. This optionally 3

appears in an Access-Request message, on the A12 interface. 4

Type = 26 (1AH) 5

Length = 12 (0CH) 6

Vendor-ID = 5535 (0000 159FH) 7

Vendor-Type = 60 (3CH) 8

Vendor-Length = 6 (06H) 9

Vendor-Value = 10

1 (0000 0001H) - HRPD Access Authentication. 11

2 (0000 0002H) - 1x Access Authorization. 12

All other values are reserved. 13

Refer also to A.S0008 [1] and A.S0009 [2], Annex E. 14


3.3.4.1 HRPD Dormant Handoff from FAP to Macro AN/PCF 16

When an HRPD AT performs a dormant handoff from a FAP to a macro AN/PCF, the macro AN/PCF 17

sends an A13-Session Information Request message to retrieve the HRPD session from the source FAP. 18

The destination IP address of the A13-Session Information Request message may be the source FAP or 19

the FGW. The macro AN/PCF may receive the A13-Session Information Response message either from 20

the source FAP or the FGW. This specification assumes that the FGW can be supported without any 21

additional interface or modification to A13 interface at both FAP and macro AN/PCF. 22

Upon receipt of the session information, the macro AN/PCF completes session establishment with the AT 23

and selects the PDSN to set up an A10 connection for each service connection. Refer to A.S0008 [1] and 24

A.S0009 [2], Section 4.4.1.2. 25


3.3.5.1 Connected-State Handoff from FAP to a Macro AN 27

When an AT with an active HRPD connection hands off from a FAP to a macro AN, the FAP uses the 28

A16 interface to request transfer of the HRPD session to the target AN/PCF. In the A16-Session Transfer 29

Request message, the destination IP address of the A16-Session Information Request message may be 30

provisioned to deliver the message to either the FGW or the target AN/PCF. The FAP shall include the 31

Target Sector ID IE to assist the target AN in determining the sector to which the resource should be 32

allocated. 33

Refer also to A.S0008 [1] and A.S0009 [2], Section 3.12. 34

4 In the HRPD IOS, this attribute is entitled “HRPD Access Authentication”. This specification adds the Vendor-Value “1x

Access Authorization”.

3GPP2 A.S0024-A v1.0

3-7

3.3.5.2 Connected-State Handoff from Macro AN to a FAP 1

When an AT with an active HRPD connection hands off from a macro AN to a FAP, the macro AN uses 2

the A16 interface to request transfer of the HRPD session to the target FAP. In the A16-Session Transfer 3

Request message, the destination IP address of the A16-Session Information Request message may be the 4

FGW or the FAP according to operator‟s policy. The macro AN may omit the Target Sector ID IE in the 5

A16-Session Transfer Request message. The FGW may use the A26-Measurement Request message to 6

determine the target FAP. 7

Refer also to A.S0008 [1] and A.S0009 [2], Section 3.12. 8

3.3.6 A24 (IP Tunneling) Interface 9

Refer to A.S0008 [1] and A.S0009 [2]. 10


The A25 interface supports 1x FAP registration with the FGW and macro BS active handoff to the FAP. 12

3.3.7.1 A25 Interface Network/Transport Protocol Specification 13

The Femtocell Control Protocol (FCP) is independent of the underlying physical transport medium, which 14

is left to the discretion of operators and manufacturers. The protocol stack for the A25 interface is: 15

Femtocell Control Application

SUA

SCTP

IP/IPsec

Link Layer

Physical Layer

The protocol requirements for SUA/SCTP on the A25 interface, except when specified in this document, 16

are specified in A.S0012 [3]. 17

3.3.7.1.1 Use of the SUA for A25 18

The SUA is used to support signaling messages between the 1x FAP and the FGW. One SUA signaling 19

connection is used for the transfer of A25 interface messages per FAP. 20

For Connectionless (protocol class 0) transactions, where there is no SUA connection, A25 interface 21

messages are transported in the SUA Connectionless Data Transfer (CLDT) message. Table 3.3.7.1.1-1 22

indicates which SUA messages shall be used to transport each of the application messages on the A25 23

interface. 24

Table 3.3.7.1.1-1 Use of SUA for FCP Messages

Application Message

Message

Discriminator

SUA

Message

Femtocell Control Messages

A25-FAP Registration Request BSMAP CLDT

A25-FAP Registration Response BSMAP CLDT

A25-FAP Deregistration BSMAP CLDT

A25-Measurement Request BSMAP CLDT

3GPP2 A.S0024-A v1.0

3-8

Table 3.3.7.1.1-1 Use of SUA for FCP Messages

Application Message

Message

Discriminator

SUA

Message

A25-Measurement Response BSMAP CLDT

A25-MS OOB Indication BSMAP CLDT

A25-Femtocell Supplementary Info BSMAP CLDT

3.3.7.1.2 Use of SCTP 1

The A25 interface shall share the same SCTP connection with the A1p Interface. For the use of SCTP 2

over the A1p interface, refer to A.S0012 [3]. 3

If the SCTP connection for the A25 interface is terminated, then the registration information in the FGW 4

should be discarded. 5

3.3.7.2 A25 Interface Message Procedures 6

This section describes the message procedures used between the FAP and the FGW on the A25 interface. 7

The interface consists of the following messages: 8

A25-FAP Registration Request 9

A25-FAP Registration Response 10

A25-FAP Deregistration 11

A25-Measurement Request 12

A25-Measurement Response 13

A25-MS OOB Indication 14

A25-Femtocell Supplementary Info 15

3.3.7.2.1 A25-FAP Registration Request 16

An A25-FAP Registration Request message is sent by the FAP to the FGW to register itself with the 17

FGW. 18


When the FAP powers on, obtains the FAP configuration info from the FMS (i.e., 1x cell info of the FAP) 20

and discovers the FGW IP address, it sends an A25-FAP Registration Request message to the FGW to 21

register itself with the FGW. The A25-FAP Registration Request message shall contain FAP ID and 1x 22

cell info of the FAP and may contain the cell identifier list for the macro cell neighbors of the FAP. 23

Refer to section 5.1.2.1, A25-FAP Registration Request, for the format and content of this message. 24


None. 26

3.3.7.2.2 A25-FAP Registration Response 27

An A25-FAP Registration Response message is sent by the FGW to the FAP in response to the FAP 28

registration. 29

3GPP2 A.S0024-A v1.0

3-9


When the FGW receives an A25-FAP Registration Request message from the FAP, the FGW sends an 2

A25-FAP Registration Response message to the FAP. The A25-FAP Registration Response message shall 3

contain the FAP Identifier IE, copied from the received A25-FAP Registration Request message, and the 4

Cause value indicating the result of the registration attempt. 5

Refer to section 5.1.2.2, A25-FAP Registration Response, for the format and content of this message. 6


None. 8

3.3.7.2.3 A25-FAP Deregistration 9

The A25-FAP Deregistration message is sent by either the FGW or the FAP to deregister the FAP. 10


If either the FGW or the FAP decides to terminate the operation of the FAP, the FGW or the FAP sends 12

an A25-FAP Deregistration message to notify the peer of the deregistration. The A25-FAP Deregistration 13

message shall contain the Cause IE indicating the reason for deregistration. The FGW and the FAP shall 14

clear the related resource associated with the FAP when it sends or receives this message. 15

Refer to section 5.1.2.3, A25-FAP Deregistration, for the format and content of this message. 16


None. 18

3.3.7.2.4 A25-Measurement Request 19

The A25-Measurement Request message is sent by the FGW to request candidate FAPs (e.g., a set of 20

FAPs sharing the same PN offset reported by an MS) to provide signal strength measurements for 21

determining the target FAP for handoff of the existing MS connection. 22

Note: FAP measurement requests are not supported for IS-95 or 3x IS-2000 channels. 23


If a handoff is required and the FGW can not uniquely identify the target FAP, the FGW may send an 25

A25-Measurement Request message to candidate FAPs for handoff measurement requests. The FGW 26

determines the candidate FAPs based on information in the Handoff Request message. Refer to A.S0014 27

[17]. 28

The FGW shall include the Downlink Radio Environment, CDMA Serving One Way Delay and MS 29

Measured Channel Identity IEs if received in the Handoff Request message. 30

The IS-2000 Channel Identity IE shall be included to provide MS physical channel information. 31

The Long Code IE shall be included in the Measurement Request message and based on the Handoff 32

Request message, set to the received Public Long Code Mask (PLCM), the Electronic Serial Number 33

(ESN) derived PLCM or the received Private Longcode value. 34

The Mobile Identity IE should be included if the FAP is the access control enforcement point. 35

Upon sending this message to one or multiple FAPs, the FGW waits for the arrival of the corresponding 36

Measurement Response message(s). Note that if A25-Measurement Request messages are sent to multiple 37

FAPs, the FGW should consider the responses from multiple FAPs before selecting the target FAP for 38

handoff. The duration that the FGW should wait for responses from FAPs should be large enough to 39

3GPP2 A.S0024-A v1.0

3-10

account for the round-trip delay between the FGW and any of the candidate FAPs plus the value of the 1

Measurement Response Timer field in the Measurement Response Options IE. 2

The FGW may receive an A25-MS OOB Indication message from a FAP instead of an A25-Measurement 3

Response message. Refer to section 3.3.7.2.6. If an A25-MS OOB Indication message is received by the 4

FGW from a FAP indicating the presence of the MS before it receives measurement responses from each 5

FAP, the FGW may select the indicated FAP for handoff and proceed without waiting for other A25-6

Measurement Response messages. 7

Refer to section 5.1.2.4, A25-Measurement Request, for the format and content of this message. 8


None. 10

3.3.7.2.5 A25-Measurement Response 11

This message allows the candidate FAP to respond to the FGW for an A25-Measurement Request 12

message. Upon receipt of an A25-Measurement Request message, the candidate FAP shall verify whether 13

or not the MS identifier in on the ACL, perform the requested measurement procedures if possible, and 14

shall respond to the FGW with an A25-Measurement Response message if any of the following 15

conditions are true: 16



Signal Report Suppression bit in the A25-Measurement Request message is set to „0‟. 19

The measurement is not successful (i.e., Cause value of the A25-Measurement Response message is 20

not „Measurement successful‟) and the Error Report Suppression bit in the A25-Measurement 21

Request message is set to „0‟. 22


If the FAP detects the out-of-band presence of the specified MS, the FAP may send an A25-MS OOB 24

Indication message to the FGW instead of an A25-Measurement Response message. Refer to section 25

3.3.7.2.6. 26


This message is sent by the FAP to the FGW in response to an A25-Measurement Request message, and 28

shall include the Long Code IE set to the value received in the corresponding A25-Measurement Request 29

message, the Cause value and a measurement report, if available. 30

If the MS is allowed to utilize FAP resources and a measurement is successfully made, the FAP shall 31

respond with a „Measurement successful‟ Cause value and the measurement report. 32

If the MS is not allowed to utilize FAP resources, the FAP shall make and include the requested 33

measurement if possible and respond with the Cause value set to „MS not allowed‟. 34

If a measurement is attempted and the MS is not detected, the FAP shall respond with an „MS not 35






Cause value, „BS not equipped‟. 41


shall respond with the Cause value „BS busy‟. 43

3GPP2 A.S0024-A v1.0

3-11



Refer to section 5.1.2.5, A25-Measurement Response, for the format and content of this message. 3


None. 5

3.3.7.2.6 A25-MS OOB Indication 6

This message allows the FAP to provide an indication to the FGW that a particular MS has either been 7

detected out-of-band (OOB) or is no longer being detected OOB in the proximity of the Femtocell. 8


When a FAP detects the OOB presence (e.g., using another radio technology) of an MS on an active call 10

near the Femtocell, the FAP may invoke the MS OOB Indication procedure. When this procedure is 11

invoked, the FAP shall send an A25-MS OOB Indication message to the FGW if the FAP is able to 12

determine the mapping of the OOB identification to either the MS IMSI, MEID or both. The FAP shall 13

include one of the MS‟s identifiers, may send both of these identifiers, and in addition may include the 14

OOB identifier. The FAP ID shall be set to the FAP‟s FEID and the OOB Indication Detected field shall 15

be set to „1‟ to indicate that the MS is detected OOB at the FAP. 16

When a FAP detects the lack of OOB presence of an MS that has been previously indicated as present to 17

the FGW in an A25-MS OOB Indication message, the FAP should send an A25-MS OOB Indication 18

message. The message shall include the same identifier(s) that were used in the corresponding previous 19

A25-MS OOB Indication message sent to the FGW. The FAP ID shall be set to the FAP‟s FEID and the 20

OOB Indication Detected field shall be set to „0‟ to indicate that the MS is no longer detected OOB at the 21

FAP. 22

Refer to section 5.1.2.6, A25-MS OOB Indication, for the format and content of this message. 23


None. 25

3.3.7.2.7 A25-Femtocell Supplementary Info 26

This A25 message allows the FGW and FAP to exchange femtocell related information in support of IOS 27

messaging. 28

3.3.7.2.7.1 Successful FAP Operation 29

When the FAP returns the MS response in the Authentication Response Parameter IE of an IOS message 30

(refer to A.S0014 [5]), the FAP shall also send an A25-Femtocell Supplementary Info message with the 31

Nonce IE set to the NONCE used by the FAP to generate the Global Challenge Broadcast (refer to 32

S.S0132 [11]) and the Authentication Response Parameter IE. 33

Refer to section 5.1.2.7, A25-Femtocell Supplementary Info, for the format and content of this message. 34

3.3.7.2.7.2 Failure FAP Operation 35

None. 36

3GPP2 A.S0024-A v1.0

3-12

3.3.7.2.7.3 Successful FGW Operation 1

The FGW shall use this message to update the GLOBAL_RAND_KEY at the FAP with the new key 2

contained in the Global RAND Key IE. The IE contains the GLOBAL_RAND_KEY that the FAP shall 3

use to generate and broadcast the Global Challenge. Refer to S.S0132 [11]. 4

When the Authentication Response Parameter (AUTHR) IE is included, the FGW shall correlate the 5

associated IOS message using the Mobile Identity and the AUTHR. The FGW shall verify the RAND 6

value. If the FGW successfully verifies that the RAND value is correct, the FGW shall forward the IOS 7

message to the MSC or MSCe. 8

Refer also to 5.2.1.7, A25-Femtocell Supplementary Info, for the format and content of this message. 9

3.3.7.2.7.4 Failure FGW Operation 10

If the corresponding IOS message is not available to be correlated with the A25-Femtocell Supplementary 11

Info message based on the Mobile Identity and the AUTHR, the FGW shall deem the mobile 12

authentication to have failed. 13

If the verification of the RAND is unsuccessful the FGW shall not forward the IOS message to the MSC 14

or MSCe and shall terminate the requested transaction. 15

Refer also to 5.2.1.7, A25-Femtocell Supplementary Info, for the format and content of this message. 16


The A26 interface supports HRPD FAP registration with the FGW and macro AN active handoff to the 18

FAP. 19

3.3.8.1 A26 Interface Network/Transport Protocol Specification 20

The IOS application is independent of the underlying physical transport medium, which is left to the 21

discretion of operators and manufacturers. The signaling protocol stack available to operators and 22

manufacturers for the A26 interface is: 23

IOS Application

UDP

IP/IPsec

Link Layer

Physical Layer

The following UDP [18] port value is reserved for signaling on the A26 interface: 24

A26 (FAP-to-FGW) 4726/UDP - This is the registered UDP port number to be used for FAP 25

registration. 26

The destination port number in the UDP packet that carries an A26-FAP Registration Request, A26-FAP-27

Deregistration and A26-FAP Measurement Request message shall be set to 4726. 28

The receiver of the A26-FAP Registration Request message shall set the <source port, source IP address> 29

and <destination port, destination IP address> of the UDP packet that carries the corresponding A26-FAP 30

Registration Response message to the <destination port, destination IP address> and <source port, source 31

IP address> of the UDP packet that carried the A26-FAP Registration Request message, respectively. 32

The receiver of the A26-Measurement Request message shall set the <source port, source IP address> and 33

<destination port, destination IP address> of the UDP packet that carries the corresponding A26-34

Measurement Response message to the <destination port, destination IP address> and <source port, 35

source IP address> of the UDP packet that carried the A26-Measurement Request message, respectively. 36

3GPP2 A.S0024-A v1.0

3-13

The standard UDP protocol, as described in [18], shall be used. 1

3.3.8.2 A26 Interface Message Procedures 2

This section describes the message procedures used between FAP and FGW on the A26 interface. The 3

interface consists of the following messages: 4

A26-FAP Registration Request 5

A26-FAP Registration Response 6

A26-FAP Deregistration 7

A26-Measurement Request 8

A26-Measurement Response 9

3.3.8.2.1 A26-FAP Registration Request 10

An A26-FAP Registration Request message is sent by the FAP to the FGW to register itself with the 11

FGW. 12


When the FAP powers on, obtains the FAP configuration information from the FMS and discovers the 14

FGW IP address, it sends an A26-FAP Registration Request message to the FGW to register itself with 15

the FGW. The FAP then starts timer Tregreq-26 and awaits the arrival of the corresponding A26-FAP 16

Registration Response message. The A26-FAP Registration Request message shall contain the FAP ID 17

and Sector Info of the FAP neighbors. 18

Refer to section 5.1.3.1, A26-FAP Registration Request, for the format and content of this message. 19


If timer Tregreq-26 expires, the FAP may resend the A26-FAP Registration Request message to the FGW 21

and restart timer Tregreq-26 a configurable number of times. If the A26-FAP Registration Response 22

message is not received from the FGW, the FAP may terminate the registration procedure with the FGW 23

for an implementation specific period of time. 24

3.3.8.2.2 A26-FAP Registration Response 25

An A26-FAP Registration Response message is sent by the FGW to the FAP in response to the FAP 26

registration. 27


When the FGW receives an A26-FAP Registration Request message from the FAP, the FGW sends an 29

A26-FAP Registration Response message to the FAP. The A26-FAP Registration Response message shall 30

contain the FAP Identifier IE, copied from the received A26-FAP Registration Request message, and the 31

Cause value indicating the result of the registration attempt. Upon receipt of this message, the FAP stops 32

timer Tregreq-26. 33

Refer to section 5.1.3.2, A26-FAP Registration Response, for the format and content of this message. 34


None. 36

3.3.8.2.3 A26-FAP Deregistration 37

The A26-FAP Deregistration message is sent by either the FGW or the FAP to deregister the FAP. 38

3GPP2 A.S0024-A v1.0

3-14


If either the FGW or the FAP decides to terminate the operation of the FAP, the FGW or the FAP sends 2

an A26-FAP Deregistration message to notify the peer of the deregistration and starts timer Tregreq-26 to 3

await the arrival of an acknowledging A26-FAP Deregistration message. The A26-FAP Deregistration 4

message shall contain the Cause IE indicating the reason for deregistration. The FGW and the FAP shall 5

clear the related resource associated with the FAP when it sends or receives the acknowledging A26-FAP 6

Deregistration message. The acknowledging A26-FAP Deregistration message shall include the same 7

cause value received in the original A26-FAP Deregistration message. 8

Refer to section 5.1.3.3, A26-FAP Deregistration, for the format and content of this message. 9


If timer Tregreq-26 expires, the FGW or FAP may resend the A26-FAP Deregistration message and restart 11

timer Tregreq-26 a configurable number of times. If an acknowledging A26-FAP Deregistration message is 12

not received, the FGW or FAP clears the related resource and may address OAM&P procedures per 13

operator policy. 14

3.3.8.2.4 A26-Measurement Request 15

The A26-Measurement Request message is sent by the FGW to request candidate FAPs (e.g., a set of 16

FAPs sharing the same PN offset reported by an AT) to provide signal strength measurements for 17

determining the target FAP for handoff of the existing AT connection. 18


If a handoff is required and the FGW can not uniquely identify the FAP, the FGW may send an A26-20

Measurement Request message to candidate FAPs for handoff measurement requests. Using the pilot 21

information from the RouteUpdate message reported by the AT, the FGW determines the candidate FAPs 22

based on the Pilot PN information of each FAP registered with the FGW. 23

The Sector Info IE and Long Code Mask IE shall be included to assist the FAP using the LongCodeMask 24

parameter (C.S0024 [9]) to detect the AT identified by the AT-ID. 25

Upon sending this message, the FGW starts timer Tmr-26 to await the arrival of the corresponding A26-26

Measurement Response message. Note that if A26-Measurement Request messages are sent to multiple 27

FAPs, the FGW should consider the responses from multiple FAPs before selecting the target FAP for 28

handoff. The duration that the FGW should wait for responses from FAPs should be large enough to 29

account for the round-trip delay between the FGW and any of the candidate FAPs plus the value of 30

Measurement Response Timer field in the Measurement Response Options IE. 31

Refer to section 5.1.3.4, A26-Measurement Request, for the format and content of this message. 32


If timer Tmr-26 expires and the FGW did not set either the Low Signal Report Suppression bit or the Error 34

Report Suppression bit in the Measurement Response Options IE, the FGW may restart the timer and 35

resend this message a configurable number of times. If the A26-Measurement Response message is not 36

received, the FGW shall terminate the measurement request procedure with the FAP. Note that Tmr-26 37

should be larger than the Measurement Response Timer field in the Measurement Response Options IE. 38

3.3.8.2.5 A26-Measurement Response 39

This message allows the candidate FAP to respond to the FGW for an A26-Measurement Request 40

message. Upon receipt of an A26-Measurement Request message, the candidate FAP shall perform the 41

3GPP2 A.S0024-A v1.0

3-15

requested measurement procedures if possible, and shall respond to the FGW with an A26-Measurement 1

Response message if any of the following conditions are true: 2



Signal Report Suppression bit in the A26-Measurement Request message is set to „0‟. 5

The measurement is not successful (i.e., Cause value of the A26-Measurement Response message is 6

not „Measurement successful‟) and the Error Report Suppression bit in the A26-Measurement 7

Request message is set to „0‟. 8



This message is sent by the FAP to the FGW in response to an A26-Measurement Request message, and 11

shall include the AT-ID IE set to the value received in the corresponding A26-Measurement Request 12

message, the Cause value and a measurement report, if available. 13

If a measurement is successfully made, the FAP shall respond with a „Measurement successful‟ Cause 14

value and the measurement report. 15

If a measurement is attempted and the AT is not detected, the FAP shall respond with an „AT not 16






Cause value, „AN not equipped‟. 22


shall respond with the Cause value „AN busy‟. 24



Upon receipt of this message, the FGW stops timer Tmr-26. 27

Refer to section 5.1.3.5, A26-Measurement Response, for the format and content of this message. 28


None. 30

31

32

33

3GPP2 A.S0024-A v1.0

3-16

1

(This page intentionally left blank) 2

3

3GPP2 A.S0024-A v1.0

4-1

4 FAP Call Flows 1

This section describes the call flows associated with FAP and AT operation. 2

4.1 FAP Operation 3

This section describes the call flows associated with Femtocell operation. 4

4.1.1 FAP Power-up 5

This scenario describes the call flow associated with FAP power-up and initialization, including 6

neighborhood discovery, network discovery and configuration. 7

FMS

1. FAP power-up and neighborhood discovery

Core

NetworkSeGWFAP

5. FAP is configured and registered with

network; FAP turns on transmitter

2. FAP discovers SeGW and establishes secure IP tunnel with the SeGW

3. FAP discovers FMS, uploads neighboorhood info, downloads configuration parameters

4. 1x FAP connects with the core network for registration

8

Figure 4.1.1-1 FAP Power-up 9

1. The FAP powers-up and initiates neighborhood discovery (refer to X.R0063-0 [I-1]). The FAP scans 10

its neighboring cells and obtains its radio neighborhood information. Note this step should complete 11

prior to step „3‟. 12

2. The FAP discovers the IP address of the SeGW by DNS lookup or by other means and establishes a 13

secure IP tunnel with the SeGW. Refer to X.S0059-100 [16]. 14

3. The FAP discovers the FMS through the secure IP tunnel and uploads the information it obtained 15

during neighborhood discovery to the FMS. The FMS configures the FAP with air-interface and 16

network parameters (including those required for 1x FAP operation). Refer to X.R0063-0 [I-1]. 17

4. If the FAP is to provide 1x services, it also connects to and registers with the core network (refer to 18

X.S0059-200 [17]) or the FGW (refer to section 4.1.2.1). 19

5. The FAP, once authorized and configured by the serving FMS, may start transmitting on the assigned 20

frequency. 21

4.1.2 IOS-based 1x FAP Registration/Deregistration 22

This section describes the call flows associated with IOS-based femtocell registration and deregistration. 23

For SIP-based femtocell registration and deregistration call flows, refer to X.S0059-200 [17]. 24

3GPP2 A.S0024-A v1.0

4-2

4.1.2.1 1x FAP Registration 1

This scenario describes the call flow associated with FAP registration with the FGW to enable the FGW 2

to provide service and core network connectivity for the FAP. Note: When the FAP powers on, it obtains 3

the FAP configuration information from the FMS and discovers the FGW IP address. 4

FGWFAP

1. A25-FAP Registration Request

2. A25-FAP Registration Response 5

Figure 4.1.2.1-1 FAP Registration 6

1. The FAP sends an A25-FAP Registration Request message to the FGW to register itself with the 7

FGW. 8

2. The FGW receives the FAP registration attempt and responds with an A25-FAP Registration 9

Response message with a Cause value indicating success or failure. 10

4.1.2.2 1x FAP Deregistration 11

These scenarios describe the call flows associated with FAP deregistration with the FGW. 12

4.1.2.2.1 FAP-initiated FAP Deregistration 13

FGWFAP

1. A25-FAP Deregistration

14

Figure 4.1.2.2.1-1 FAP-initiated FAP Deregistration 15

1. The FAP sends an A25-FAP Deregistration message to the FGW to deregister itself with the FGW. 16

The FAP and the FGW clear the related resource. 17

4.1.2.2.2 FGW-initiated FAP Deregistration 18

FGWFAP


19

Figure 4.1.2.2.2-1 FGW-initiated FAP Deregistration 20

1. The FGW sends an A25-FAP Deregistration message to the FAP to deregister the FAP. 21

4.1.3 HRPD FAP Registration/Deregistration 22

4.1.3.1 HRPD FAP Registration 23

This scenario describes the call flow associated with FAP registration with the FGW to enable the FGW 24

to provide service and core network connectivity for the FAP. When the FAP powers on, it obtains the 25

FAP configuration information from the FMS and discovers the FGW IP address. 26

3GPP2 A.S0024-A v1.0

4-3

FGWFAP

Tregreq-26

1. A26-FAP Registration Request

2. A26-FAP Registration Response 1

Figure 4.1.3.1-1 FAP Registration 2

1. The FAP sends an A26-FAP Registration Request message to the FGW to register itself with the 3

FGW. The FAP starts timer Tregreq-26. 4

2. The FGW receives the FAP registration attempt and responds with an A26-FAP Registration 5

Response message with a Cause value indicating success or failure. When the FAP receives the A26-6

FAP Registration Response message, it stops timer Tregreq-26. 7

4.1.3.2 HRPD FAP Deregistration 8

These scenarios describe the call flows associated with FAP deregistration with the FGW. 9

4.1.3.2.1 FAP-initiated HRPD FAP Deregistration 10

FGWFAP

Tregreq-26



11

Figure 4.1.3.2.1-1 FAP-initiated HRPD FAP Deregistration 12

1. The FAP sends an A26-FAP Deregistration message to the FGW to deregister itself with the FGW 13

and starts timer Tregreq-26. 14

2. The FGW receives the deregistration and responds with an A26-FAP Deregistration message with the 15

same cause value received. When the FAP receives the acknowledging A26-FAP Deregistration 16

message, it stops timer Tregreq-26. The FAP and the FGW clear the related resource. 17

4.1.3.2.2 FGW-initiated HRPD FAP Deregistration 18

FGWFAP


2. A26-FAP DeregistrationTregreq-26

19

Figure 4.1.3.2.2-1 FGW-initiated HRPD FAP Deregistration 20

1. The FGW sends an A26-FAP Deregistration message to the FAP to deregister the FAP and starts 21

timer Tregreq-26. 22

2. The FAP receives the deregistration and responds with an A26-FAP Deregistration message with the 23

same cause value received. When the FGW receives the acknowledging A26-FAP Deregistration 24

message, it stops timer Tregreq-26. The FAP and the FGW clear the related resource. 25

3GPP2 A.S0024-A v1.0

4-4

4.2 SIP-based 1x RAN Call Flows 1

This section describes the SIP-based 1x Femtocell call flows associated with MS operation. 2

4.2.1 MS/AT Power-up at the FAP 3

Refer to the registration call flow in X.S0059-200 [17]. 4

4.2.2 MS Registration and Paging at the FAP 5

For registration and paging call flows, refer to X.S0059-200 [17]. 6

4.2.3 SIP-based 1x Handoff 7

This section describes the call flows associated with handoff between 1x macro and Femtocell systems. 8

4.2.3.1 SIP-based 1x Macro BS to FAP Dormant Handoff (Intra-PDSN) 9

This scenario describes the call flow when an MS with a dormant packet data session hands off from a 10

macro BS to a FAP under the same PDSN. From the perspective of the source macro BS, these 11

procedures are identical to those for a dormant handoff of a packet data service instance. Refer to 12

A.S0013 [4], Section 3.17.4.13.1. 13

MS PDSN

15. A11-Registration Reply

Target

FCS

Target

FAP

Tregreq

Source

BS/

PCF

14. A11-Registration Request

13. A11-Registration Acknowledge

12. A11-Registration UpdateTregup



Tregreq

2. Origination Message

3. BS Ack Order

16. Packet data session dormant, PPP session is maintained

4. CM Service Request

5. Assignment Request

8. Assignment Failure

9. Clear Command

11. Clear Complete

10. Release Order


14

Figure 4.2.3.1-1 1x Macro BS to FAP Dormant Handoff (Intra-PDSN) 15

1. It is assumed that the MS has performed a MIP registration (if required) and established a PPP 16

connection with the PDSN however the packet data session is now dormant. The MS does not have 17

an active voice call in progress. 18

2. On detection of a new PZID, SID or NID, the MS sends an Origination Message with DRS set to „0‟ 19

to the target FAP. 20

3GPP2 A.S0024-A v1.0

4-5

3. The target FAP acknowledges the receipt of the Origination Message with a BS Ack Order to the MS. 1

4. The target FAP encapsulates a CM Service Request message and sends it to the target FCS via Fx2 2

signaling. Refer to X.S0059-200 [17] for the messaging format between the FAP and the FCS. 3

Note: Step „4‟ is optional. If step „4‟ is not performed, steps „5‟, „8‟, „9‟ and „11‟ are omitted. 4

5. The target FCS sends an Assignment Request message to the target FAP via Fx2 signaling to request 5

assignment of radio resources. 6

6. The target FAP sends an A11-Registration Request message to the PDSN. This message includes the 7

Mobility Event Indicator within the Critical Vendor Specific Extension (CVSE) and a non-zero Life-8

time. This message also includes Accounting Data (A10 Connection Setup Airlink Record) and 9

ANID information (CANID/PANID). The target FAP starts timer Tregreq. 10

7. The A11-Registration Request message is validated and the PDSN accepts the connection by 11

returning an A11-Registration Reply message with an accept indication. If the PDSN has data to send, 12

it includes the Data Available Indicator within the CVSE. The A10 connection binding information at 13

the PDSN is updated to point to the target FAP. The target FAP stops timer Tregreq. 14

If the PDSN responds to the target FAP with the Data Available Indicator, the target FAP establishes 15

traffic channels. In this case, steps „8‟-„11‟ and „16‟ are omitted. 16

8. The target FAP sends the Assignment Failure message to the target FCS via Fx2 signaling, with the 17

Cause value indicating Packet Call Going Dormant. 18

9. After the target FCS has successfully authenticated the MS, it sends a Clear Command message to the 19

target FAP via Fx2 signaling with the Cause value „Do not notify mobile‟. 20

10. The target FAP may send a Release Order to the MS. This allows the MS to send Origination 21

Messages for any remaining PDSIs sooner. 22

11. The target FAP sends a Clear Complete message to the target FCS via Fx2 signaling. 23

12. The PDSN initiates release of the A10 connection with the source BS/PCF by sending an A11-24

Registration Update message. The PDSN starts timer Tregupd. 25

13. The source BS/PCF responds with an A11-Registration Acknowledge message. The PDSN stops 26

timer Tregupd. 27

14. The source BS/PCF sends an A11-Registration Request message with Lifetime set to zero to the 28

PDSN. The source BS/PCF starts timer Tregreq. 29

15. The PDSN sends the A11-Registration Reply message with an accept indication to the source 30

BS/PCF. The source BS/PCF releases the A10 connection for the MS. The source PCF stops timer 31

Tregreq. 32

If the MS sends an Origination Message with DRS = 0 for additional dormant service instances (this 33

may occur any time after step „10‟ or when timer T42m expires for the last dormant service instance 34

handed off), this procedure is repeated for each such service instance. 35

16. The packet data session remains dormant. 36

3GPP2 A.S0024-A v1.0

4-6

4.2.3.2 SIP-based 1x Macro BS to FAP Dormant Handoff (Inter-PDSN) 1

This scenario describes the call flow when an MS with a dormant packet data session hands off from a 2

macro BS to a FAP under a different PDSN. From the perspective of the source macro BS, these 3

procedures are identical to those for a dormant handoff of a packet data service instance. Refer to 4

A.S0013 [4], Section 3.17.4.14. 5

MSTarget

PDSN


Target

FCS

Target

FAP

Tregreq

Source

PDSN

Source

BS/

PCF



14. A11-Registration UpdateTregup

13. Packet data session active, new PPP session established


11. A11-Registration ReplyTregreq


6. A11-Registration RequestTregreq


3. BS Ack Order


4. CM Service Request


9. Assignment Complete

8. TCH setup

12. Establish PPP connection, MIP registration

6

Figure 4.2.3.2-1 1x Macro BS to FAP Dormant Handoff (Inter-PDSN) 7

1. It is assumed that the MS has performed a MIP registration (if required) and established a PPP 8

connection with the PDSN however the packet data session is now dormant. The MS does not have 9

an active voice call in progress. 10

2. On detection of a new PZID, SID or NID, the MS sends an Origination Message with DRS set to „0‟ 11

to the target FAP. 12

3. The target FAP acknowledges the receipt of the Origination Message with a BS Ack Order to the MS. 13

4. The target FAP encapsulates a CM Service Request message and sends it to the target FCS via Fx2 14


Note: Step „4‟ is optional. If step „4‟ is not performed, steps „5‟ and „9‟ are omitted. 16

5. The target FCS sends an Assignment Request message to the target FAP via Fx2 signaling to request 17

assignment of radio resources. 18

6. The target FAP initiates establishment of the A10 connection by sending an A11-Registration 19

Request message with non-zero Lifetime value to the target PDSN. The message includes the 20

Mobility Event Indicator within a CVSE and a non-zero Lifetime. This message also includes 21

3GPP2 A.S0024-A v1.0

4-7

Accounting Data (A10 Connection Setup Airlink Record) and ANID information (CANID/PANID). 1

The target FAP starts timer Tregreq. 2

7. The A11-Registration Request message is validated and the target PDSN accepts the connection by 3

returning an A11-Registration Reply message with an accept indication and Data Available Indicator 4

within a CVSE. If the PDSN supports fast handoff the Anchor P-P Address is included. If the target 5

FAP does not support fast handoff it ignores the Anchor P-P Address. The target FAP stops timer 6

Tregreq. 7

8. The target FAP initiates setup of the traffic channel with the MS. 8

9. The target FAP sends the Assignment Complete message to the target FCS. 9

10. The target FAP sends an A11-Registration Request message to the target PDSN containing an Airlink 10

Start accounting record. The target FAP starts timer Tregreq. 11

11. The target PDSN updates the accounting data and returns an A11-Registration Reply message with an 12

accept indication back to the target FAP. The target FAP stops timer Tregreq. 13

12. The MS and the target PDSN establish the link layer (PPP) connection and perform MIP registration 14

procedures (if required) over the link layer (PPP) connection, thereby creating a mobility binding for 15

the MS. 16

13. The packet data session is active and a new PPP session has been established. 17

14. On expiration of the PPP timer or other events internal to the source PDSN, the source PDSN initiates 18

release of the A10 connection with the source BS/PCF by sending an A11-Registration Update 19

message. The source PDSN starts timer Tregupd. 20

15. The source BS/PCF responds with an A11-Registration Acknowledge message. The source PDSN 21

stops timer Tregupd. 22

16. The source BS/PCF sends an A11-Registration Request message with Lifetime set to zero. The source 23

PCF starts timer Tregreq. 24

17. The source PDSN stores the accounting related information for further processing before returning an 25

A11-Registration Reply message with an accept indication. The source BS/PCF releases the A10 26

connection. The source BS/PCF stops timer Tregreq. 27

4.2.3.3 SIP-based 1x FAP to Macro BS Dormant Handoff 28

For the scenario when a MS with a dormant packet data session hands off from FAP to a macro BS, from 29

the perspective of the target BS and the source FAP, these procedures are identical to those for a dormant 30

handoff of a packet data service instance. Refer to A.S0013 [4], Section 3.17.4.13.1 for details. 31

3GPP2 A.S0024-A v1.0

4-8

4.2.3.4 SIP-based 1x Macro BS to FAP Active Handoff 1

This section describes the call flows associated with active handoff from a macro BS to a FAP. 2

4.2.3.4.1 SIP-based 1x Macro BS to FAP Active Handoff Measurements 3

This scenario describes the call flow when an MS with a 1x active voice call hands off from a macro BS 4

to a FAP. From the perspective of the source macro BS, these procedures are similar to those for a hard 5

handoff via the MSC using the A1/A2 or A1p/A2p interfaces (refer to A.S0013 [4], Section 3.19.3.1). 6

MSTarget

FAP1

20. Voice

1. Voice

15. BS Ack Order

19. Clear CompleteT315

14. Handoff Completion Msg

T306

Target

FCS

Source

MSC

Source

Macro

BS

13. Reverse Traffic Channel Frames or Traffic Channel Preamble

4. FACDIR2

18. Clear Command

T7

12. Handoff Commenced

3. Handoff Required

17. MSONCH

7. Null forward traffic channel frames

8. facdir2

T8

Twaitho

10. HO Direction Msg

11. MS Ack Order

2. PSMM

Target

FAP2

5a. Measure. Request

5b. Measurement Request

6a. Handoff Request

x

9. Handoff Command

6b. HO Request Ack

16. Handoff Complete

7

Figure 4.2.3.4.1-1 1x Macro BS to FAP Active Handoff 8

1. The MS is in a voice call via the source macro BS and the source MSC. 9

2. The MS sends a Pilot Strength Measurement Message (PSMM), refer to C.S0005 [8], to the source 10

macro BS that includes the PN offset of the FAP as the strongest neighboring cell. 11

3. Based on the PSMM, the source macro BS decides to perform a hard handoff. The source macro BS 12

sends a Handoff Required message to the source MSC and starts timer T7. The message contains the 13

Cell ID value that maps to PN offset of the FAP and the MSC_ID of the target FCS. 14

4. The source MSC sends a FACDIR2 message to the target FCS via core network messaging, directing 15

the target FCS to initiate the handoff. Refer to X.S0004 [12]. 16

5. If the target FCS can not determine the FAP corresponding to the Cell ID reported in step „4‟ (i.e., 17

there are multiple FAPs that have the same PN offset), the target FCS sends a measurement request 18

message via Fx2 signaling to the candidate FAPs that have the same PN offset (steps „5a‟ and „5b‟). 19

All FAPs that receive this message verify that the MS is allowed 1x cdma2000 circuit switched 20

services through the FAP, and attempt to detect the MS and measure the signal strength of the reverse 21

3GPP2 A.S0024-A v1.0

4-9

link of the MS (refer to C.S0005 [8]). Each FAP responds to the FCS providing the signal strength 1

measured on the reverse link of the MS and the transmit power of the FAP. 2

6. Based on the results of the measurement request or other means, the target FCS uniquely determines 3

the target FAP, allocates bearer resources and sends a handoff request to target FAP 1. Target FAP 1 4

allocates the appropriate radio resources and responds with a handoff request acknowledge via Fx2 5

signaling. Refer to X.S0059-200 [17]. 6

7. Target FAP 1 sends null forward traffic channel frames to the MS. 7

8. The target FCS, having completed the Handoff Request procedure, sends a facdir2 message to the 8

source MSC via core network messaging. Refer to X.S0004 [12]. 9

9. The source MSC prepares to switch the MS from the source macro BS to target FAP 1 and sends a 10

Handoff Command message to the source macro BS. The source MSC includes in the Handoff 11

Command message the service configuration records contained in the handoff request ack message 12

and received in the facdir2 message. Refer to X.S0059-200 [17]. The source macro BS stops timer T7. 13

10. The source macro BS sends a handoff direction message5 to the MS and starts timer T8. If the MS is 14

allowed to return to the source macro BS, timer Twaitho is also started by the source macro BS. 15

11. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source 16

macro BS. The source macro BS stops timer T8 upon receipt of this message. 17

12. The source macro BS sends a Handoff Commenced message to the source MSC to notify it that the 18

MS has been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306. If 19

timer Twaitho has been started, the source BS waits for that timer to expire before sending the Handoff 20

Commenced message. 21

13. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell. 22

14. The MS sends a Handoff Completion Message to target FAP 1. 23

15. Target FAP 1 sends a BS Ack Order to the MS over the air interface. 24

16. Target FAP 1 sends a Handoff Complete message to the target FCS via Fx2 signaling to notify it that 25

the MS has successfully completed the hard handoff. 26

17. The target FCS sends the MSONCH message to the source MSC via core network messaging to 27

notify it that the MS has successfully completed the hard handoff. 28

18. The source MSC sends a Clear Command message to the source macro BS and starts timer T315. The 29

source macro BS stops timer T306. 30

19. The source macro BS sends a Clear Complete message to the source MSC to notify it that clearing 31

has been accomplished. The source MSC stops timer T315. 32

20. The MS is in a voice call via target FAP 1 and the target FCS. 33

5 This may be a Handoff Direction Message, a General Handoff Direction Message, an Extended Handoff Direction Message,

or a Universal Handoff Direction Message as appropriate.

3GPP2 A.S0024-A v1.0

4-10

4.2.3.4.2 1x Macro BS to FAP Active Handoff with Early OOB Link Detection 1


to a FAP and the FCS is provided an indication that the MS is in the proximity of the FAP prior to it init-3

iating handoff procedures for the MS. From the perspective of the source macro BS, these procedures are 4

similar to those for a hard handoff via the MSC using the A1/A2 or A1p/A2p interfaces (refer to A.S0013 5

[4], Section 3.19.3.1). 6

MSTarget

FAP1

20. Voice

1. Voice

15. BS Ack Order



T306

Target

FCS

Source

MSC

Source

Macro

BS


5. FACDIR2

18. Clear Command

T7


4. Handoff Required

17. MSONCH


8. facdir2

T8

Twaitho


11. MS Ack Order

3. PSMM

Target

FAP2

6a. Handoff Request

x

9. Handoff Command

6b. HO Request Ack


2. MS OOB Indication

7

Figure 4.2.3.4.2-1 1x Macro BS to FAP Active Handoff with Early OOB Link Detection 8


2. FAP 1 detects the MS‟s presence over the OOB link and sends an MS OOB Indication message via 10

Fx2 signaling to the FCS. 11

3. The MS sends a PSMM, refer to C.S0005 [8], to the source macro BS that includes the PN offset of 12

the FAP as the strongest neighboring cell. 13






6. The target FCS uniquely determines the FAP corresponding to the Cell ID reported in step „4‟ based 19

on the MS OOB Indication message sent by FAP 1 in step „2‟, allocates bearer resources and sends a 20

3GPP2 A.S0024-A v1.0

4-11

handoff request to target FAP 1. Target FAP 1 allocates the appropriate radio resources and responds 1

with a handoff request acknowledge via Fx2 signaling. Refer to X.S0059-200 [17]. 2






























3GPP2 A.S0024-A v1.0

4-12

4.2.3.4.3 1x Macro BS to FAP Active Handoff with Late OOB Link Detection 1


to a FAP and the FCS is provided an indication that the MS is in the proximity of the FAP while it is init-3



[4], Section 3.19.3.1). 6

MSTarget

FAP1

21. Voice

1. Voice

16. BS Ack Order



T306

Target

FCS

Source

MSC

Source

Macro

BS


4. FACDIR2

19. Clear Command

T7


3. Handoff Required

18. MSONCH

8. Null forward traffic channel frames9. facdir2

T8

Twaitho


12. MS Ack Order

2. PSMM

Target

FAP2

5a. Measure. Request

7a. Handoff Request

x

10. Handoff Command

7b. HO Request Ack


5b. Measure. Request


7

Figure 4.2.3.4.3-1 1x Macro BS to FAP Active Handoff with Late OOB Link Detection 8









5. If the target FCS can not determine the FAP corresponding to the Cell ID reported in step „4‟ (i.e., 17

there are multiple FAPs that have the same PN offset), the target FCS sends a measurement request 18

message via Fx2 signaling to the candidate FAPs that have the same PN offset (steps „5a and 5b‟). All 19

FAPs that receive this message verify that the MS is allowed 1x cdma2000 circuit switched services 20

through the FAP, and attempt to detect the MS and measure the signal strength of the reverse link of 21

3GPP2 A.S0024-A v1.0

4-13

the MS (refer to C.S0005 [8]). Each FAP responds to the FCS providing the signal strength measured 1

on the reverse link of the MS and the transmit power of the FAP. 2

6. When FAP 1 detects the MS‟s presence over the OOB link it sends an MS OOB Indication message 3

via Fx2 signaling instead of a Measurement Response message to the FCS. If the MS OOB Indication 4

message is received by the FCS before it receives measurement responses from each FAP in step „5‟, 5

the FCS selects FAP 1 as the target FAP for handoff and proceeds without waiting for other Measure-6

ment Response messages. 7

7. The FSC allocates bearer resources and sends a handoff request to FAP 1.Target FAP 1 allocates the 8

appropriate radio resources and responds with a handoff request acknowledge via Fx2 signaling. 9

Refer to X.S0059-200 [17]. 10






























3GPP2 A.S0024-A v1.0

4-14

4.2.3.4.4 MS OOB Indication 1

This scenario describes the call flow when FAP 1 determines that a previously detected MS is no longer 2

in its proximity over the OOB link. 3

FAP1FCS


4

Figure 4.2.3.4.4-1 MS OOB Indication 5

1. FAP 1 no longer detects the previously detected MS. FAP 1 sends MS OOB Indication message via 6

Fx2 signaling to the FCS to cancel the previous MS OOB Indication provided by FAP 1 to the FCS. 7

4.2.3.5 SIP-based 1x FAP to Macro BS Active Handoff 8

This scenario describes the call flow when an MS with a 1x active voice call hands off from a FAP to a 9

macro BS. From the perspective of the target macro BS, these procedures are similar to those for a hard 10


MSTarget

BS

20. Voice

1. Voice

15. BS Ack Order


Target

MSC

Source

FCS

Source

FAP

16. HO Complete


5. HO Request

4. FACDIR2

T11

T9

7. HO Request Ack

17. MSONCH


8. facdir2

T8

Twaitho


11. MS Ack Order

2. PSMM

x

3. Handoff Required

9. Handoff Command


18. Clear Command

19. Clear Complete

12

Figure 4.2.3.5-1 1x FAP to Macro BS Active Handoff 13

1. The MS is in a voice call via the source FAP and the source FCS. 14

2. The MS sends a PSMM message C.S0005 [8] to the source FAP. 15

3. Based on the PSMM, the source FAP decides to perform a hard handoff to the target BS. The source 16

FAP sends a Handoff Required message with the list of target cells to the source FCS via Fx2 17


3GPP2 A.S0024-A v1.0

4-15

4. The source FCS sends a FACDIR2 message to the target MSC via core network messaging. Refer to 1

X.S0004 [12]. 2

5. The target MSC sends a Handoff Request message to the target BS and starts timer T11. 3

6. Upon receipt of the Handoff Request message from the target MSC, the target BS allocates the 4

appropriate radio resources as specified in the message and connects the call. The target BS sends null 5

forward traffic channel frames to the MS. 6

7. The target BS sends a Handoff Request Acknowledge message to the target MSC and starts timer T9 7

to wait for arrival of the MS on its radio channel. The target MSC stops timer T11 upon the receipt of 8

this message. The cell identifier list contains the BS Cell ID. 9

8. The target MSC sends the facdir2 message to the source FCS via core network messaging. Refer to 10

X.S0004 [12]. 11

9. The source FCS prepares to switch the MS from the source FAP to the target BS and sends a Handoff 12

Command message to the source FAP via Fx2 signaling. The source FCS includes in the Handoff 13

Command message the service configuration records it received in the Handoff Request Ack message. 14

Refer to X.S0059-200 [17]. 15

10. The source FAP sends a handoff direction message8 to the MS and starts timer T8. If the MS is 16

allowed to return to the source FAP, timer Twaitho is also started by the source FAP. 17


FAP. The source FAP stops timer T8 upon receipt of this message. 19

12. The source FAP sends a Handoff Commenced message to the source FCS via Fx2 signaling to notify 20

it that the MS has been ordered to move to the target BS channel. If timer Twaitho has been started, the 21

source FAP waits for that timer to expire before sending the Handoff Commenced message. 22

13. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell(s). 23

14. The MS sends a Handoff Completion Message to the target BS. The target BS stops timer T9. 24

15. The target BS sends the BS Ack Order to the MS over the air interface. 25

16. The target BS sends a Handoff Complete message to the target MSC to notify it that the MS has 26

successfully completed the hard handoff. 27

17. The target MSC sends the MSONCH message to the source FCS via core network messaging to 28


18. The source FCS sends a Clear Command message to the source FAP via Fx2 signaling. 30

19. The source FAP sends a Clear Complete message to the source FCS via Fx2 signaling to notify it that 31

clearing has been accomplished. 32

20. The MS is in a voice call via the target BS and the target MSC. 33



3GPP2 A.S0024-A v1.0

4-16

4.3 IOS-based 1x RAN Call Flows 1

This section describes the IOS-based 1x Femtocell call flows associated with MS/AT operation. 2

4.3.1 MS Registration 3

This scenario describes the call flow when an MS registers with the MSC/MSCe and the FGW replaces 4

the cell ID of the FAP in the BSMAP with the virtual cell ID of the FGW. 5

MS FAPMSC/

MSCe

1. Registration Message

4. Location Updating Accept

FGW

2. Complete L3 Info: Location

Updating Request (FAP Cell ID)3. Complete L3 Info: Location

Updating Request (FGW Cell ID)

6. Location Updating Accept

7.Registration Accept

Order

5.Maintain MS’s

mobility context

6

Figure 4.3.1-1 Mobile Registration via a Circuit Switched MSC/MSCe 7

1. The MS initiates a registration procedure by sending a Registration Message to the FAP. 8

2. The FAP constructs the Location Updating Request message with the cell ID of FAP in the BSMAP 9

header, places it in the Complete Layer 3 Information message and sends it to the FGW. 10

3. The FGW replaces the cell ID of the FAP in the BSMAP with the virtual cell ID of the FGW, and 11

forwards the Complete Layer 3 Information message to the MSC/MSCe. 12

4. The MSC/MSCe sends a Location Updating Accept message to the FGW to indicate that the Location 13

Updating Request message has been processed. 14

5. The FGW maintains the MS‟s mobility context. 15

6. The FGW forwards the Location Updating Accept message to the FAP. 16

7. The FAP responds to the MS with a Registration Accept Order. 17

3GPP2 A.S0024-A v1.0

4-17

4.3.2 Mobile Origination 1

This scenario describes the call flow associated with an MS call origination via a circuit switched MSC in 2

the Femtocell system. Messaging between the FAP, FGW and MSC is also applicable to an MS call 3

origination via an MSCe. 4

MS



T312

3. Complete L3 Info:

CM Service Request

7. Channel Assignment

2. BS Ack Order

FAP FGW MSC

4. Complete L3 Info:

CM Service Request


8. Orig. Continuation Msg9. CM Service Request

Continuation10. CM Service Request

Continuation11. Assignment Complete

12. Assignment Complete

13. Call progress indication

T10

T303

5

Figure 4.3.2-1 Mobile Origination via a Circuit Switched MSC 6

1. The MS transmits an Origination Message, with Layer 2 Ack required, over the Access Channel of 7

the air interface to the FAP to request service. 8

2. The FAP acknowledges the receipt of the Origination Message with a Base Station Acknowledgment 9

Order to the MS. 10

3. The FAP constructs the CM Service Request message, places it in the Complete Layer 3 Information 11

message, sends the message to the FGW. If the Origination Message sent in step „1‟ indicated that it 12

is to be followed by an Origination Continuation Message, the CM Service Request message includes 13

the Origination Continuation Indicator element. 14

4. The FGW receives the CM Service Request message from the FAP, replaces the cell identifier info 15

with a virtual cell ID info, and then forwards the message to the MSC, and starts timer T303. If the 16

CM Service Request message includes the Origination Continuation Indicator element, the MSC 17

starts timer T312 to await the CM Service Request Continuation message. The FGW maintains the 18

cell identifier and virtual cell ID association as well as the mobility context including the identity of 19

the MS and the FAP. 20

5. The MSC sends an Assignment Request message to the FGW to request assignment of radio 21

resources. This message includes information on the terrestrial circuit, if one is to be used between 22

the circuit-switched MSC and the FGW. The MSC then starts timer T10. The FGW stops the timer 23

T303 upon receipt of the Assignment Request message. 24

6. Based on the maintained mobility context information, the FGW forwards the Assignment Request 25

message to the FAP serving the MS. 26

7. The FAP and the MS establish a radio traffic channel per step e-j in A.S0013-D v2.0 Section 3.1.1.1.1. 27

8. If the MS indicated in the Origination Message in step „1‟ that an Origination Continuation Message 28

would follow, the MS sends this message. 29

3GPP2 A.S0024-A v1.0

4-18

9. If the FAP received an Origination Continuation Message in step „8‟, it sends a CM Service Request 1

Continuation message to the FGW. 2

10. If the FGW received a CM Service Request Continuation message from the FAP, it forwards the 3

message to the MSC. Upon receipt of the CM Service Request Continuation message the MSC stops 4

timer T312. 5

11. After the radio traffic channel and circuit have both been established and fully interconnected, the 6

FAP sends the Assignment Complete message to the FGW and considers the call to be in 7

Conversation State. 8

12. The FGW forwards the Assignment Complete message to the MSC. The MSC stops timer T10 upon 9

receipt of the Assignment Complete message. 10

13. As call progress tone is applied in-band in this case, ringback tone is available on the audio circuit 11

path towards the MS. 12

4.3.3 Mobile Termination 13

This scenario describes the call flow associated with an MS call termination via a circuit switched MSC 14

in the Femtocell system. Messaging between the FAP, FGW and MSC is also applicable to an MS call 15

termination via an MSCe. 16

17

18

Figure 4.3.3-1 Mobile Termination via a Circuit Switched MSC 19

1. The circuit-switched MSC determines that an incoming call terminates to an MS within its serving 20

region and sends the Paging Request message to the FGW to initiate a mobile terminated call setup 21

scenario. The circuit-switched MSC then starts timer T3113. 22

2. The FGW receives the Paging Request message from the MSC and determines the target FAP based 23

on the maintained mobility context of this MS. If the MS‟s mobility context does not exist in the 24

FGW, no action is taken by the FGW and the MT call flow terminates. 25

3GPP2 A.S0024-A v1.0

4-19

The FGW should replace the cell identifier information (virtual cell ID) in the Paging Request 1

message from the MSC with the cell ID of the target FAP, and then forward the Paging Request 2

message to the FAP. Note that the virtual cell ID values for different FGWs under the same MSC are 3

different. 4

3. The FAP issues a Page Message containing the MS address over the Paging Channel. 5

4. The MS acknowledges the page by transmitting a Page Response Message over the Access Channel. 6

5. The FAP constructs the Paging Response message, places it in the Complete Layer 3 Information 7

message, sends the message to the FGW. 8

6. The FGW receives the Paging Response message from the FAP, replaces the cell identifier 9

information with the virtual cell ID, and then forwards the message to the MSC. The FGW starts time 10

T303. The MSC stops timer T3113 upon receipt of the Paging Response message from the FGW. 11

7. The FAP acknowledges the receipt of the Page Response Message with a Base Station 12

Acknowledgment Order to the MS. 13

8. The MSC sends an Assignment Request message to the FGW to request assignment of radio 14

resources. This message includes information on the terrestrial circuit, if one is to be used between 15

the circuit-switched MSC and the FGW. The MSC then starts timer T10. The FGW stops the timer 16

T303 upon receipt of the Assignment Request message. 17

9. Based on the maintained mobility context information, the FGW forwards the Assignment Request 18

message to the FAP. 19

10. The FAP and the MS establish a radio traffic channel per steps „g‟-„l‟ in A.S0013-D [4] Section 20

3.1.2.1.1. 21

11. After the radio traffic channel and circuit have both been established and fully interconnected, the 22

FAP sends the Assignment Complete message to the FGW. 23

12. The FGW forwards the Assignment Complete message to the MSC. The MSC stops timer T10 upon 24

receipt of the Assignment Complete message and starts timer T301. 25

13. The FAP sends the Alert With Information Message to the MS to cause ringing at the MS. 26

14. The MS acknowledges the reception of the Alert With Information Message by transmitting the 27

Mobile Station Acknowledgment Order. 28

15. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted 29

to the FAP. 30

16. The FAP acknowledges the Connect Order with the Base Station Acknowledgment Order over the 31

forward traffic channel. 32

17. The FAP sends a Connect message to the FGW. 33

18. The FGW forwards the Connect message to the MSC. The MSC stops timer T301 upon receipt of the 34

Connect message from the FGW. At this point, the call is considered stable and in the Conversation 35

State. 36

4.3.4 IOS-based 1x Handoff 37

4.3.4.1 Macro BS to FAP Dormant Handoff (Intra-PDSN) 38

For the scenario when an MS with a dormant packet data session hands off from a macro BS to a FAP 39

under the same PDSN, from the perspective of the source macro BS, these procedures are identical to 40

those for a dormant handoff of a packet data service instance. Refer to A.S0013 [4], Section 3.17.4.13.1. 41

3GPP2 A.S0024-A v1.0

4-20

4.3.4.2 Macro BS to FAP Dormant Handoff (Inter-PDSN) 1

For the scenario when an MS with a dormant packet data session hands off from a macro BS to a FAP 2

under a different PDSN, from the perspective of the source macro BS, these procedures are identical to 3

those for a dormant handoff of a packet data service instance. Refer to A.S0013 [4], Section 3.17.4.14. 4

4.3.4.3 FAP to Macro BS Dormant Handoff 5

For the scenario when a MS with a dormant packet data session hands off from FAP to a macro BS, from 6

the perspective of the target BS and the source FAP, these procedures are identical to those for a dormant 7

handoff of a packet data service instance. Refer to A.S0013 [4], Section 3.17.4.13.1. 8

4.3.4.4 Macro BS to FAP Active Handoff 9

This section describes the call flows associated with active handoffs from the macro BS to the FAP. 10

4.3.4.4.1 Macro BS to FAP Active Handoff Measurements 11


to a FAP. From the perspective of the source macro BS, these procedures are similar to those for a hard 13


T315

MS FAP1

20. Voice

1. Voice

15. BS Ack Order

19. Clear Complete


T306

FGWMSC

Source

Macro

BS


4. Handoff Request

18. Clear Command

T7


3. Handoff Required


8. Handoff Request Ack

T8

Twaitho


11. MS Ack Order

2. PSMM

FAP2

5a. A25-Measure Rqst

5b. A25-Measurement Request

x

9. Handoff Command

6a. Handoff Request

6b. Handoff Request Ack



15

Figure 4.3.4.4.1-1 1x Macro BS to FAP Active Handoff 16

1. The MS is in a voice call via the source macro BS and the MSC. 17



3GPP2 A.S0024-A v1.0

4-21


sends a Handoff Required message to the MSC and starts timer T7. The message contains the Cell ID 2

value, which may be derived using the PN offset received from step „2‟. 3

4. The MSC sends a Handoff Request message to the FGW based on the Cell ID. 4

5. If the FGW can not determine the FAP (i.e., there are multiple FAPs that have the same PN offset 5

corresponding to the Cell ID received in step „4‟), the FGW sends an A25-Measurement Request 6

message to the candidate FAPs that have the same PN offset (steps „5a‟ and „5b‟). All FAPs that 7

receive this message verify that the MS is allowed 1x cdma2000 circuit switched services through the 8

FAP, and attempt to detect the MS and measure the signal strength of the reverse link of the MS. 9

Each FAP responds to the FGW providing the signal strength measured on the reverse link of the MS 10

and the transmit power of the FAP. 11

6. Based on the results of the measurement request or other means, the FGW uniquely determines the 12

target FAP, allocates bearer resources and sends a Handoff Request message to the target FAP. The 13

target FAP allocates the appropriate radio resources and responds with a Handoff Request 14

Acknowledge message. 15

7. The target FAP sends null forward traffic channel frames to the MS. 16

8. The FGW, having completed the Handoff Request procedure, sends a Handoff Request Acknowledge 17

message to the MSC. 18

9. The MSC prepares to switch the MS from the source macro BS to the target FAP and sends a Handoff 19

Command message to the source macro BS. The MSC includes in the Handoff Command message 20

the service configuration records contained in the Handoff Request Acknowledge message. The 21




11. The MS may acknowledge the handoff direction message by sending a Mobile Station 25

Acknowledgment Order to the source macro BS. The source macro BS stops timer T8 upon receipt of 26

this message. 27

12. The source macro BS sends a Handoff Commenced message to the MSC to notify it that the MS has 28

been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306. If timer 29

Twaitho has been started, the source BS waits for that timer to expire before sending the Handoff 30



14. The MS sends a Handoff Completion Message to the target FAP. 33

15. The target FAP sends a Base Station Acknowledgment Order to the MS over the air interface. 34

16. The target FAP sends a Handoff Complete message to the FGW to notify it that the MS has 35


17. The FGW sends the Handoff Complete message to the MSC. 37

18. The MSC sends a Clear Command message to the source macro BS and starts timer T315. The source 38

macro BS starts timer T306. 39



3GPP2 A.S0024-A v1.0

4-22

19. The source macro BS sends a Clear Complete message to the MSC to notify it that clearing has been 1

accomplished. The MSC stops timer T315. 2

20. The MS is in a voice call via the target FAP and the FGW. 3

4

4.3.4.4.2 Macro BS to FAP Active Handoff with Early OOB Link Detection 5

This call flow describes the scenario when an MS with a 1x active voice call hands off from a macro BS 6

to a FAP and the FGW is provided an indication that the MS is in the proximity of the FAP prior to it init-7



[4], Section 3.19.3.1). 10

T315

MS FAP1

20. Voice

1. Voice

15. BS Ack Order

19. Clear Complete


T306

FGWMSC

Source

Macro

BS


5. Handoff Request

18. Clear Command

T7


4. Handoff Required



T8

Twaitho


11. MS Ack Order

3. PSMM

FAP2

x

9. Handoff Command

6a. Handoff Request




2. A25-MS OOB Ind.

11

Figure 4.3.4.4.2-1 1x Macro BS to FAP Active Handoff with Early OOB Link Detection 12


2. FAP 1 detects the presence of the MS on an active call over the OOB link and sends an A25-MS 14

OOB Indication message to the FGW. 15







3GPP2 A.S0024-A v1.0

4-23

6. The FGW uniquely determines the FAP corresponding to the Cell ID reported in step „4‟ based on the 1

A25-MS OOB Indication message sent by FAP1 in step „2‟, allocates bearer resources and sends a 2

Handoff Request message to target FAP 1. Target FAP 1 allocates the appropriate radio resources and 3

responds with a Handoff Request Acknowledge message. 4












this message. 16


been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306. If timer 18
















3GPP2 A.S0024-A v1.0

4-24

4.3.4.4.3 Macro BS to FAP Active Handoff with Late OOB Link Detection 1

This call flow describes the scenario when an MS with a 1x active voice call hands off from a macro BS 2

to a FAP and the FGW is provided an indication that the MS is in the proximity of the FAP while it is 3

initiating handoff procedures for the MS. From the perspective of the source macro BS, these procedures 4

are similar to those for a hard handoff via the MSC using the A1/A2 or A1p/A2p interfaces (refer to 5

A.S0013 [4], Section 3.19.3.1). 6

T315

MS FAP1

21. Voice

1. Voice

16. BS Ack Order

20. Clear Complete


T306

FGWMSC

Source

Macro

BS


4. Handoff Request

19. Clear Command

T7


3. Handoff Required



T8

Twaitho


12. MS Ack Order

2. PSMM

FAP2

5a. A25-Measurement Request

x

10. Handoff Command

7a. Handoff Request




6. A25-MS OOB Ind.

5b. A25-Measure Rqst

7

Figure 4.3.4.4.3-1 1x Macro BS to FAP Active Handoff with Late OOB Link Detection 8








5. If the FGW can not determine the FAP (i.e., there are multiple FAPs that have the same PN offset 16

corresponding to the Cell ID received in step „4‟), the FGW sends an A25-Measurement Request 17

message to the candidate FAPs that have the same PN offset (steps „5a‟ and „5b‟). All FAPs that 18

receive this message verify that the MS is allowed 1x cdma2000 circuit switched services through the 19

FAP, and attempt to detect the MS and measure the signal strength of the reverse link of the MS. 20

3GPP2 A.S0024-A v1.0

4-25

Each FAP responds to the FGW providing the signal strength measured on the reverse link of the MS 1

and the transmit power of the FAP. 2

6. When FAP 1 detects the presence of the MS on an active call over the OOB link it sends an A25-MS 3

OOB Indication message instead of an A25-Measurement Response message to the FGW. If the A25-4

MS OOB Indication message is received by the FGW before it receives measurement responses from 5

each FAP in step „5‟, the FGW selects the target FAP 1 as the target FAP for handoff and proceeds 6

without waiting for other A25-Measurement Response messages. 7

7. The FGW allocates bearer resources and sends a Handoff Request message to FAP 1. The target FAP 8

allocates the appropriate radio resources and responds with a Handoff Request Acknowledge message. 9












this message. 21


been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306.If timer 23














37



3GPP2 A.S0024-A v1.0

4-26

4.3.4.4.4 A25-MS OOB Indication 1

This scenario describes the call flow when FAP 1 determines that a previously detected MS is no longer 2

in its proximity over the OOB link. 3

FAP 1FGW

1. A25-MS OOB Ind.

4

Figure 4.3.4.4.4-1 A25-MS OOB Indication 5

1. FAP 1 no longer detects the previously detected MS. FAP 1 sends an A25-MS OOB Indication 6

message to the FGW to cancel the previous MS OOB Indication provided by FAP1 to the FGW. 7

4.3.4.5 FAP to Macro BS Active Handoff 8

For the scenario when an MS with a 1x active voice call hands off from a FAP to a macro BS, from the 9

perspective of the target macro BS, these procedures are identical to those for a hard handoff via the MSC 10

using the A1/A2 or A1p/A2p interfaces. Refer to A.S0013 [4], Section 3.19.3.1. 11

4.3.4.6 Inter-FAP Active Handoff 12

This section describes the call flows associated with inter-FAP active handoff. 13

4.3.4.6.1 Active Optimized Inter-FAP Handoff with A1p 14

This scenario describes the call flow associated with an active optimized inter-FAP handoff when the 15

FGW connects to the MSCe via the A1p interface. 16

Note: The Femtocell IOS Application Protocol (FIAP) signaling messages shown in Figure 4.3.4.6.1-1 17

are applicable between the source FAP and the target FAP and FCS when SIP is the FCP (Femtocell 18

Control Protocol), with the exceptions noted in the text. Refer to X.S0059-000 [15] for an FCP 19

description. 20

3GPP2 A.S0024-A v1.0

4-27

MS

2. PSMM

5. Handoff Request

3. Handoff Required

1. 1x voice

13. HO Dir Msg

Source

FAP

Target

FAPFGW

7. Bearer Update Required

8. Bearer Update Request

6. Handoff Requ Ack

16. Reverse TCH frames or preamble

4. FGW detects target cell belonging to the same FGW

based on the cell ID configuration info.

MSCe


10. Bearer Update Response


12. Handoff Command

14. MS Ack

Order15. Handoff Commenced

17. Handoff Completion


19. Handoff Performed

20. 1x voice

21. Clear procedure

1

Figure 4.3.4.6.1-1 Active Optimized Inter-FAP Handoff, FGW with A1p 2

1. The MS is in a voice call via the source macro BS and the source MSCe. 3

2. The MS sends a PSMM, refer to C.S0005 [8], to the source FAP that includes the PN offset of the 4

target FAP as the strongest neighboring cell. 5

3. Based on the PSMM, the source FAP decides to perform a hard handoff. The source FAP sends a 6

Handoff Required message to the FGW. The message contains the Cell ID value, which may be 7

derived using the PN offset received from step „2‟. 8

4. The FGW detects that the target cell is located under itself and performs an optimized inter-FAP 9

handoff procedure. 10

Note: The FGW determines the target FAP based on measurement procedures, out-of-band indications 11

provided by the FAP or other means (refer to section 4.3.4.4). When SIP is the FCP, for FCS call flows 12

refer to 4.2.3.4. 13

5. The FGW sends a Handoff Request message to the target FAP. 14

6. The target FAP allocates the appropriate radio resources and responds with a Handoff Request 15


Note: Steps „7‟-„12‟ are performed by the FGW only when SUA is the FCP. 17

7. The FGW initiates Bearer Update procedures by sending a Bearer Update Required message to the 18

MSCe. The target FAP A2p bearer related parameters are included in the Bearer Update Required 19

message if they are contained in Handoff Request message from the target FAP. 20

3GPP2 A.S0024-A v1.0

4-28

8. The MSCe returns a Bearer Update Request message including the MGW A2p bearer related 1

parameters. 2

9. The FGW forwards the Bearer Update Request message to the target FAP. 3

10. The target FAP acknowledges the A2p bearer modification with a Bearer Update Response message. 4

11. The FGW returns a Bearer Update Response message to the MSCe. 5

Note: The MSCe uses the H.248 modification procedure to update A2p bearer info with the MGW. 6

12. The FGW prepares to switch the MS from the source FAP to the target FAP and sends a Handoff 7

Command message to the source FAP. 8

13. The source FAP sends a handoff direction message12 to the MS. 9


Acknowledgment Order to the source FAP. 11

15. The source FAP sends a Handoff Commenced message to the FGW to notify it that the MS has been 12

ordered to move to the target FAP channel. 13





Note: Step „19‟ is performed by the FGW only when SUA is the FCP. 18

19. The FGW may send a Handoff Performed message to the MSCe to inform the MSCe of handoff 19

operations. 20

20. The MS is in a voice call via the target FAP. 21

21. The FGW initiates call clearing procedures with the source FAP. 22

23



3GPP2 A.S0024-A v1.0

4-29

4.3.4.6.2 Active Optimized Inter-FAP Handoff with A1 1

This scenario describes the call flow associated with an active optimized inter-FAP handoff when the 2

FGW connects to the MSC via the A1 interface. 3

Note: Figure 4.3.4.6.2-1 is not applicable when SIP is the FCP. 4

MS

2. PSMM

5. Handoff Request

3. Handoff Required

1. 1x voice

10. HO Dir Msg

Source

FAP

Target

FAPFGW

6. Handoff Requ Ack

4. FGW detects target cell belonging to the same FGW

based on the cell ID configuration info.

MSC



9. Handoff Command

11. MS Ack

Order12. Handoff Commenced

14. Handoff Completion


16. Handoff Performed

17. 1x voice

18. Clear procedure

13. Reverse TCH frames or preamble

5

Figure 4.3.4.6.2-1 Active Optimized Inter-FAP Handoff, FGW with A1 6


2. The MS sends a PSMM, refer to C.S0005 [8], to the source FAP that includes the PN offset of the 8

target FAP as the strongest neighboring cell. 9

3. Based on the PSMM, the source FAP decides to perform a hard handoff. The source FAP sends a 10

Handoff Required message to the FGW. The message contains the Cell ID value which may be 11

derived using the PN offset received from step „2‟. 12

4. The FGW detects that the target cell is located under itself and performs an optimized inter-FAP 13

handoff procedure. 14

Note: The FGW determines the target FAP based on measurement procedures, out-of-band indications 15

provided by the FAP or other means (refer to section 4.3.4.4). 16

5. The FGW sends a Handoff Request message to the target FAP. 17

6. The target FAP allocates the appropriate radio resources and responds with a Handoff Request 18


7. The FGW initiates Bearer Update procedures by sending a Bearer Update Request message to the 20

target FAP. 21

8. The target FAP acknowledges the A2p bearer modification with a Bearer Update Response message. 22

3GPP2 A.S0024-A v1.0

4-30

9. The FGW prepares to switch the MS from the source FAP to the target FAP and sends a Handoff 1

Command message to the source FAP. 2

10. The source FAP sends a handoff direction13 message to the MS. 3


Acknowledgment Order to the source FAP. 5

12. The source FAP sends a Handoff Commenced message to the FGW to notify it that the MS has been 6

ordered to move to the target FAP channel. 7





16. The FGW may send a Handoff Performed message to the MSC to inform the MSC of handoff 12

operations. 13

17. The MS is in a voice call via the target FAP. 14

18. The FGW initiates call clearing procedures with the source FAP. 15

4.4 HRPD Call Flows 16

This section describes the HRPD femtocell call flows associated with AT operation. 17

4.4.1 HRPD Handoff 18

This section describes the call flows associated with handoff between HRPD macro and Femtocell 19

systems. 20

4.4.1.1 HRPD Macro AN/PCF to FAP Dormant Handoff 21

For the scenario when an HRPD AT performs a dormant handoff from a macro AN/PCF to a FAP, from 22

the perspective of the source AN/PCF these procedures are identical to those for a dormant handoff using 23

the A13 interface to retrieve session information. From the perspective of the target FAP, the 24

configuration of the handoff source appears as an AN/PCF and the handoff procedure occurs after 25

performing Femtocell access control procedures. Refer to A.S0008 [1] and A.S0009 [2], Section 3.7 for 26

details and section 2.4 for Femtocell access control procedures. 27

4.4.1.2 HRPD FAP to Macro AN/PCF Dormant Handoff 28

This scenario describes the call flow when an HRPD AT performs a dormant handoff from a FAP to a 29

macro AN/PCF. It is assumed that the AT has crossed a mobility boundary and that, based on the UATI, 30

the AN/PCF sends the A13-Session Information Request message to the FGW instead of the FAP. This 31

call flow also assumes that the A13-Session Information Response and the A13-Session Information 32

Confirm messages are exchanged directly between the source FAP and the target AN/PCF. 33

Otherwise, if the AN/PCF is able to send the A13-Session Request message directly to the FAP, then 34

from the perspective of the target AN/PCF these procedures are identical to those for a dormant handoff 35

using the A13 interface to retrieve session information. Refer to A.S0008 [1] and A.S0009 [2], Section 36

3.7 for details. 37



3GPP2 A.S0024-A v1.0

4-31

TA13req

Tregreq

Tregreq

Tregupd

Target

AN/PCFPDSNAT

10. A11-Registration Update

11. A11-Registration Ack


(Lifetime=0)


(Lifetime=0, accept)

TA13res

1. Initiate Session

Establishment

5. Complete Session

Establishment

6. Location Update

Procedures

FGWSource

FAP

2. A13-Session Info

Request

3. A13-Session Info

Request

7. A13-Session Info Confirm

8. A11-Registration Request (Lifetime, MEI)

9. A11-Registration Reply (Lifetime, accept)

4. A13-Session Information Response

1

Figure 4.4.1.2-1 HRPD FAP to Macro AN/PCF Dormant Handoff 2

1. After the AT crosses a mobility boundary (e.g., the macro AN pilot is the strongest pilot), the AT 3

requests an HRPD connection. Subsequently, the AT and the macro target AN/PCF initiate HRPD 4

session establishment. During this procedure, the target AN/PCF receives the UATI of an existing 5

HRPD session (if available). The UATI can be used as an identifier for the existing HRPD session 6

and, based on the UATI, the target AN/PCF attempts to retrieve the existing HRPD session state 7

information from the source FAP, via the FGW. 8

2. The target AN/PCF sends an A13-Session Information Request message to the FGW. The A13-9

Session Information Request message includes the received UATI, the Security Layer Packet and 10

(target) Sector ID. The target AN/PCF starts timer TA13req. 11

3. The FGW determines the address of the source FAP, through means outside the scope of this 12

specification, and forwards the A13-Session Information Request message to the source FAP, to 13

request the HRPD session information for the AT. 14

4. The source FAP validates the A13-Session Information Request and sends the requested HRPD 15

session information of the AT to the target AN/PCF in an A13-Session Information Response 16

message. The message may be sent directly to the target AN/PCF or through the FGW. The source 17

FAP starts timer TA13res. The target AN/PCF stops timer TA13req. 18

5. The AT and the target AN/PCF complete the establishment of the HRPD session. Depending on the 19

state of the AT and the target AN/PCF, either an existing HRPD session may be re-established, or a 20

new HRPD session may be initiated if required. This step may be omitted if no further over-the-air 21

signaling is required. 22

6. If the target AN/PCF supports the Location Update procedure, the target AN/PCF updates the ANID 23

in the AT using the Location Update procedure. The target AN/PCF may also retrieve the PANID 24

from the AT if necessary (e.g., the Session Configuration retrieved in step „4‟ indicates that the source 25

FAP does not support the Location Update procedure). 26

3GPP2 A.S0024-A v1.0

4-32

7. The target AN/PCF sends an A13-Session Information Confirm message to the source FAP to 1

indicate that the target AN/PCF has received the HRPD session information. The message may be 2

sent directly to the source AN/PCF or through the FGW. Upon receipt of the A13-Session 3

Information Confirm message, the source FAP deletes the associated AT HRPD session information 4

and stops timer TA13res. 5

8. The target AN/PCF selects the PDSN (refer to A.S0013 [4]), and sends an A11-Registration Request 6

message to the PDSN to set up an A10 connection for each service connection. The A11-Registration 7

Request message includes the MEI within the CVSE and a non-zero Lifetime. This message also 8

includes a CVSE containing Accounting Data (A10 Connection Setup Airlink Record), if new A10 9

connections are being established, and a Normal Vendor Specific Extension (NVSE) including ANID 10

information (CANID/PANID). The target AN/PCF starts timer Tregreq. 11

9. The A11-Registration Request message is validated and the PDSN accepts the A10 connections by 12

returning an A11-Registration Reply message with an accept indication and the Lifetime set to the 13

configured Trp value. If the PDSN has data to send, it includes the Data Available Indicator within the 14

CVSE. If the subscriber has a Subscriber QoS Profile, the PDSN includes it in an NVSE. The A10 15

connection binding information at the PDSN is updated to point to the target AN/PCF. The target 16

AN/PCF stops timer Tregreq. 17

10. If the PDSN has A10 connections to another AN/PCF (e.g., the source FAP), it initiates closure of the 18

A10 connections with that AN/PCF by sending an A11-Registration Update message. The PDSN 19

starts timer Tregupd. 20

11. The source FAP responds with an A11-Registration Acknowledge message. The PDSN stops timer 21

Tregupd. 22

12. The source FAP sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. 23

The source FAP starts timer Tregreq. 24

13. The PDSN sends an A11-Registration Reply message to the source FAP. The source FAP closes the 25

A10 connections for the AT and stops timer Tregreq. 26

3GPP2 A.S0024-A v1.0

4-33

4.4.1.3 HRPD Macro AN/PCF to FAP Connected State Session Transfer 1

This scenario describes the call flow when an active AT hands off from a macro AN/PCF to a FAP and 2

the A16 interface from the macro AN terminates on an FGW. From the perspective of the source macro 3

AN/PCF, these procedures are similar to those for a hard handoff using the A16 interface (refer to 4

A.S0008 [1] and A.S0009 [2]). 5

AT FAP2

1. Packet data flow

TA13rel

TSClose-13

Target

FAP1FGW

Source

AN/PCF

4. A10: Xoff

PDSN

2. Source AN decides to transfer

session to target FAP

6a. A26-Measure Rqst

5. A16-Session

Transfer Request

6b. A26-Measurement Request

TKeepAlive-13


22. A11-Registration Request (Lifetime = 0)


20. A11-Registration UpdateTregupd

Tregreq

29a/b. A13-Resource Release Response

28a/b. A13-Resource Release Request

26a/b. A13-Keep Alive Response

25a/b. A13-Keep Alive Request

18a/b. A16-Session Release Indication Ack

17a/b. A16-Session Release Indication

15. A11-Reg. Reply

Tstrel-16

Tregreq

12a/b. A16-Session Transfer Complete

11. Source AN may close

connection or may initiate

application layer route reset. At

the same time, source AN may

assign new connection to AT

10. A11-Reg. Reply

8a/b. A16-Session Transfer Response

7. A16-Session

Transfer Request

Tregreq

9. A11-Reg. Request

14. A11-Reg. Request

(ActiveStart)

Tstcomp-16

Tstreq-16

TSClose-13

Tstreq-16

3. Source AN locks session

configuration in the AT

27. Connection between AT and target FAP closes

13. Target FAP acquires the AT and may complete an application layer route reset

16. Target FAP may assign new UATI to the AT and receives confirmation

19. Target FAP unlocks session configuration in the AT

24. Packet data

6

Figure 4.4.1.3-1 HRPD Macro AN/PCF to FAP Active Handoff 7

1. The AT has already established a packet data call via the source macro AN/PCF. 8

3GPP2 A.S0024-A v1.0

4-34

2. The source AN decides that the HRPD session should be transferred via hard handoff to the target 1

FAP. This decision is triggered according to a session transfer trigger algorithm which is imple-2

mentation specific. From the perspective of the source AN, the FGW is another AN. All FAP‟s 3

sectors are configured as belonging to the FGW. 4

3. The source AN locks the AT session, e.g., by sending a LockConfiguration message to the AT as 5

specified in [9]. New session configuration or attribute update cannot take place while the session is 6

locked. If the AT cannot support locking the session, then the source AN begins to ignore all session 7

reconfiguration requests from the AT. The source AN will only resume processing session 8

reconfiguration requests from the AT if the session transfer is aborted. 9

4. The source PCF may send an in-band flow control Xoff signal to the PDSN to stop data transmission 10

from the PDSN if the flow control feature is activated. 11

5. The source AN sends an A16-Session Transfer Request message to the FGW. The A16-Session 12

Transfer Request message includes the Session State Information Records of the current HRPD 13

session and all supported personalities. The latest traffic channel report message is also encapsulated 14

in the A16-Session Transfer Request message indicating that this is a hard handoff request. The 15

source AN starts timer Tstreq-16. 16

After receipt of the A16-Session Transfer Request message, the FGW chooses the target FAP based on 17

the RouteUpdate message (Encapsulated Message IE) in the A16-Session Transfer Request message. Step 18

„6‟ only occurs when the FGW identifies multiple FAPs which have the same target PN offset. In this 19

case the FGW requests each FAP to measure the AT‟s reverse link strength as follows: 20

6. The FGW sends an A26-Measurement Request message to the candidate FAPs that have the same PN 21

offset (steps „6a‟ and „6b‟). All FAPs that receive this message attempt to detect the AT and measure 22

the signal strength of the reverse link of the AT and transmit power of the FAP. Each FAP responds 23

to the FGW providing the signal strength measured on the reverse link of the AT and the transmit 24

power of the FAP. 25

7. Based on the results of the measurement request, the FGW uniquely determines the target FAP. In 26

this call flow, it‟s assumed that FAP 1 is selected. The FGW forwards the A16-Session Transfer 27

Request message to FAP 1. 28

8. FAP 1 determines from the latest traffic channel report message the list of new sectors that the AT 29

should switch to in order to connect to FAP 1 and then allocates resources required for these sectors. 30

FAP 1 accepts the hard handoff request by sending an A16-Session Transfer Response message to the 31

FGW (step „8a‟). The message also includes Proposed Session State Information Records containing 32

necessary traffic channel parameters of the new sectors. FAP 1 starts timer Tstcomp-16. The FGW 33

forwards the A16-Session Transfer Response message to the source AN (step „8b‟). Upon receipt of 34

the A16-Session Transfer Response message, the source AN stops timer Tstreq-16. 35

Note: Steps „9‟ and „10‟ can occur any time after step „7‟ and before step „20‟ 36

9. FAP 1 recognizes that no A10 connection associated with the AT is available. It then establishes A10 37

connection(s) with the source PDSN. FAP 1 sends an A11-Registration Request message to the 38

PDSN with the „S‟ bit set to „0‟ indicating that simultaneous binding is not needed. The source PDSN 39

is able to receive data simultaneously from both the source PCF and FAP 1 while both A10 40

connections are still alive. FAP 1 starts timer Tregreq. The A11-Registration Request message includes 41

A10 Connection Setup airlink record and may include Active Start airlink record. 42

10. The A11-Registration Request message is validated and the PDSN accepts the connection by 43

returning an A11-Registration Reply message with an accept indication and Lifetime set to the 44

configured Trp value. The A10 connection binding information at the PDSN is updated to point to 45

FAP 1. FAP 1 stops timer Tregreq. 46

3GPP2 A.S0024-A v1.0

4-35

11. If the source AN cannot transfer Signaling Link Protocol (SLP) states to FAP 1 or the source AN 1

needs to instruct the AT to switch to a new personality before FAP 1 can acquire the AT, then the 2

source AN also closes the connection, e.g., by sending a ConnectionClose message [9], and at the 3

same time assign a new connection between the AT and FAP 1 e.g., by sending a 4

TrafficChannelAssignment message [9] (refer to Sections 3.13.1 and 3.13.2). If the source AN can 5

transfer SLP states to FAP 1 and does not need to switch to a new personality, then the source AN 6

also sends an application-layer route reset command, e.g., RLP Reset for Default Packet Application 7

or ResetTxIndication and ResetRxIndication for Multi-flow Packet Application [9], at the same time. 8

This step can occur anytime after step „8‟. The source AN may repeat this step to enhance reliability. 9

12. The source AN sends an A16-Session Transfer Complete message to the FGW (step „12a‟). Since 10

some Session State Information records (e.g., state information) may be changed after A16-Session 11

Transfer Request has been sent, this message includes Session State Information Records that have 12

been changed from the values indicated by the A16-Session Transfer Request message as modified by 13

the session changes in the A16-Session Transfer Response message. The source AN also starts timer 14

Tstack-16. The FGW forwards the A16-Session Transfer Complete message to the FAP 1 (step „12b‟), 15

Upon receipt of the A16-Session Transfer Complete message, FAP 1 stops timer Tstcomp-16. 16

13. After FAP 1 has acquired the AT, if FAP 1 has received SLP states in the A16-Session Transfer 17

Complete message and does not receive an application-layer route reset acknowledgement, e.g., RLP 18

ResetAck for Default Packet Application or RLP ResetTxIndicationAck and ResetRxComplete for 19

Multi-flow Packet Application [9], then FAP 1 instructs the AT to reset the application-layer route. If 20

FAP 1 receives an application-layer route reset acknowledgement, then FAP 1 completes the 21

application-layer route reset procedure. If SLP states are not included in the A16-Session Transfer 22

Complete message, then FAP 1 should not instruct the AT to reset the application-layer route. The 23

FAP 1 may begin transmitting data to the AT upon completion of this step. 24

14. FAP 1 sends an A11-Registration Request message including Active Start airlink record(s) to the 25

PDSN and starts timer Tregreq. 26

15. Upon receipt of the A11-Registration Request message, the PDSN sends an A11-Registration Reply 27

message to FAP 1. FAP 1 stops timer Tregreq. 28

16. If the source AN and FAP 1 are in different subnets, then FAP 1 assigns a new UATI to the AT and 29

receives confirmation from the AT that the new UATI is now in use. 30

17. After FAP 1 has acquired the AT and is assured that access to the system by the AT would be directed 31

to FAP 1, it sends an A16-Session Release Indication message to the FGW (step „17a‟). This message 32

indicates that the session is now under control of FAP 1 hence the source AN/PCF can terminate its 33

connection with the PDSN and can purge the session associated with the AT. FAP 1 starts timer 34

Tstrel-16. The FGW forwards the A16-Session Release Indication message to the source AN (step 35

„17b‟). Upon receipt of the A16-Session Release Indication message, the source AN stops timer 36

Tstack-16. 37

18. The source AN sends an A16-Session Release Indication Ack message to the FGW (step „18a‟). The 38

FGW forwards the A16-Session Release Indication Ack message to FAP 1 (step „18b‟). Upon receipt 39

of the A16-Session Release Indication Ack message, FAP 1 stops timer Tstrel-16. 40

Note: This call flow assumes the source AN is the AN that assigned LCM_UATI and timer TSClose-13 41

is started at this time. 42

19. If the connection was not closed in step „11‟, then FAP 1 unlocks the AT session, e.g., by sending a 43

UnlockConfiguration message as specified in [9]. New session configuration and attribute update can 44

now be initiated. 45

Step „20‟ can occur any time after step „10‟. 46

3GPP2 A.S0024-A v1.0

4-36

20. The PDSN initiates closure of the A10 connection with the source AN/PCF by sending an A11-1

Registration Update message. The PDSN starts timer Tregupd. 2

21. The source AN/PCF responds with an A11-Registration Acknowledge message. The PDSN stops 3

timer Tregupd. 4

22. Upon receipt of A16-Session Release Indication message and A11-Registration Update message, the 5

source AN/PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value 6

of zero to close the A10 connection and starts timer Tregreq. 7

23. The PDSN responds with an A11-Registration Reply message to complete the release of the A10 8

connection. The source PCF stops timer Tregreq. 9

24. Packet data is forwarded by FAP 1 between the PDSN and the AT. 10

25. FAP 1 may send an A13-Keep Alive Request message (step „25a‟) to the FGW (assuming that the 11

source AN is the AN that assigned LCM_UATI) before TSClose-13 running at the source AN expires 12

(refer to step „5‟) and starts timer TKeepAlive-13. The FGW forwards the A13-Keep Alive Request 13

message to the Source AN (step „25b‟). 14

26. Upon receipt of the A13-Keep Alive Request message, the source AN restarts timer TSClose-13 and 15

sends an A13-Keep Alive Response message to the FGW (step „26a‟). The FGW forwards A13-Keep 16

Alive Response message to FAP 1 (step „26b‟). FAP 1 stops timer TKeepAlive-13. 17

27. The connection between the AT and FAP 1 closes. 18

28. After the connection between the AT and FAP 1 closes, FAP 1 sends an A13-Resource Release 19

Request message (step „28a‟) to the FGW identified by AT-ID in the A16-Session Transfer Complete 20

message. FAP 1 starts timer TA13rel. The FGW forwards A13-Resource Release Request message to 21

the Source AN (step „28b‟). The source PCF stops the timer TSClose-13 upon receipt of this message. 22

29. Upon receipt of the A13-Resource Release Request message, the source AN sends an A13-Resource 23

Release Response message back to the FGW (step „29a‟). The source AN may now re-assign the 24

UATI to another AT. The FGW forwards A13-Resource Release Response message to FAP 1 (step 25

„29b'). Upon receipt of the A13-Resource Release Response message, FAP 1 stops timer TA13rel. 26

4.4.1.4 HRPD FAP to Macro AN/PCF Connected State Session Transfer 27

For the scenario when an AT with an active HRPD connection hands off from a FAP to a macro AN, 28

from the perspective of the target AN/PCF these procedures are identical to those for a connected state 29

handoff using the A16 interface to request a session transfer. From the perspective of the source FAP, the 30

configuration of the handoff target appears as an AN/PCF. For requirements, refer to section 3.3.5.1 for 31

details. For call flows, refer to A.S0008 [1] and A.S0009 [2], Section 3.12.1. 32

4.5 LIPA Session Establishment between FAP and AT 33

Local IP Access call flows are provided in X.S0059-100 [16]. 34

35

3GPP2 A.S0024-A v1.0

5-1

5 Messages, Information Elements and Timer Definitions 1

5.1 Message Definitions 2

5.1.1 A1 and A1p Message Definitions 3

When A1 messages defined in this section are transported on the Fx2 interface, they are formatted as 4

specified as in X.S0059-200 [17]. When A1/A1p messages defined in this section are transported on the 5

A25 interface, they are formatted as specified in this document. 6

5.1.1.1 Measurement Request 7

The BSMAP Measurement Request message is sent from the FCS to a candidate FAP to request that the 8

FAP provide measurement information for an MS to be potentially handed off to that FAP. 9

Information Element Section

Reference

Element

Direction

Type

Message Type 5.2.1.2 FCS FAP M

Classmark Information Type 2 [5] FCS FAP Ma

Cell Identifier List (Target) [5] FCS FAP Mb

Downlink Radio Environment [5] FCS FAP Oc,d C

CDMA Serving One Way Delay [5] FCS FAP Od C

MS Measured Channel Identity [5] FCS FAP Od C

IS-2000 Channel Identity [5] FCS FAP Oe R

Long Code 5.2.1.3 FCS FAP Of R

Measurement Response Options 5.2.1.5 FCS FAP O R

Mobile Identity 5.2.1.10 FCS FAP Og C

a. This IE provides the signaling types and band classes that the MS is permitted to use. More than 10

one is permitted. If an MS is capable of supporting multiple band classes, and this information was 11

included in the Handoff Required message, it shall be indicated in the band class entry field as 12

shown in [5], Section 4.2.12. 13

b. If more than one cell is specified, then they shall be in order of selection preference. Only 14

discriminator types „0000 0010‟ and „0000 0111‟ are used. 15

c. This IE provides information for each cell in the Cell Identifier List (target) IE. 16

d. This IE shall be included if received by the FCS. 17

e. This IE specifies the IS-2000 physical channels intended for the Code Division Multiple Access 18

(CDMA) to CDMA hard handoff request and shall be included. 19

f. This IE shall be included and set to the Public or Private Long Code in use by the MS. 20

g. This IE is included if the FAP is the access control enforcement point. 21

3GPP2 A.S0024-A v1.0

5-2

The following table shows the bitmap layout for the Measurement Request message. 1

5.1.1.1 Measurement Request

7 6 5 4 3 2 1 0 Octet

BSMAP Header: Message Discrimination = [00H] 1

Length Indicator (LI) = <variable> 2

Message Type = [71H] 1

Classmark Information Type 2: A1 Element Identifier = [12H] 1

Length = <variable> 2

MOB_P_REV

= [000 – 111]

Reserved

= [0]

See List

of

Entries

= [0, 1]

RF Power Capability = [000-

010]

3

Reserved = [00H] 4

NAR_

AN_

CAP

= [0,1]

IS-95

= [1]

Slotted

= [0,1]

Reserved = [00] DTX

= [0,1]

Mobile

Term

= [0,1]

TIA/

EIA-553

= [0,1]

5

Reserved = [00H] 6

Reserved = [0000 00] Mobile

Term

= [0,1]

PSI

= [0,1]

7

SCM Length = [01H] 8

Station Class Mark = [00H – FFH] 9

Count of Band Class Entries = [01H-20H] 10

Band Class Entry Length = [03H] 11

Mobile Band Class Capability Entry {1+:

Reserved = [000] Band Class n = [00000-11111] k

Band Class n Air Interfaces Supported = [00H-FFH] k+1

Band Class n MOB_P_REV = [00H-FFH] k+2

} Mobile Band Class Capability Entry

Cell Identifier List (Target): A1 Element Identifier = [1AH] 1


Cell Identification Discriminator = [02H,07H] 3

IF (Discriminator = 02H), Cell Identification {1+:

(MSB) Cell = [001H-FFFH] j

Sector = [0H-FH] (0H =

Omni)

(LSB) j+1

} OR IF (Discriminator = 07H), Cell Identification {1+:

(MSB) MSCID = <any value> j

3GPP2 A.S0024-A v1.0

5-3


7 6 5 4 3 2 1 0 Octet

j+1

(LSB) j+2

(MSB) Cell = [001H-FFFH] j+3


Omni)

(LSB) j+4

} Cell Identification

Downlink Radio Environment: A1 Element Identifier = [29H] 1


Number of Cells = <variable> 3


Downlink Radio Environment entry {1+:

IF (Discriminator = 02H), Cell Identification {1



Omni)

(LSB) j+1

} OR IF (Discriminator = 07H), Cell Identification {1:


j+1

(LSB) j+2



Omni)

(LSB) j+4


Reserved = [00] Downlink Signal Strength Raw = [000000-111111] k

(MSB) CDMA Target One Way Delay = [0000H-FFFFH] (x100ns) k+1

(LSB) k+2

} Downlink Radio Environment entry

CDMA Serving One Way Delay: A1 Element Identifier = [0CH] 1

Length = [08H, 0BH] 2


IF (Discriminator = 02H), Cell Identification {1:



Omni)

(LSB) j+1

} OR IF (Discriminator = 07H), Cell Identification {1:


3GPP2 A.S0024-A v1.0

5-4


7 6 5 4 3 2 1 0 Octet

j+1

(LSB) j+2


(LSB) Sector = [0H-FH] (0H = Omni) j+4


(MSB) CDMA Serving One Way Delay = [0000H-FFFFH] k

(LSB) k+1

Reserved = [0000 00] Resolution = [00,

01, 10]

k+2

(MSB) CDMA Serving One Way Delay Time Stamp = [00 00H – FF FFH] k+3

(LSB) k+4

MS Measured Channel Identity: A1 Element Identifier = [64H] 1

Length = [02H] 2

Band Class = [00000 – 11111] ARFCN (high part)

= [000-111]

3

ARFCN (low part) = [00H – FFH] 4

IS-2000 Channel Identity: A1 Element Identifier = [09H] 1


OTD= [0]

(Ignored)

Physical Channel Count =

[001, 010]

Frame Offset = [0H-FH] 3

The following 6 octets are repeated once for each physical channel {1…2:

Physical Channel Type =

[01H (Fundamental Channel – FCH – IS-2000),

02H (Dedicated Control Channel – DCCH – IS-2000)]

n

Rev_

FCH_

Gating

Reverse Pilot Gating

Rate

= [00, 01, 10]

QOF Mask

= <any value>

(ignored)

Walsh Code Channel Index

(high part) = <any value>

(Ignored)

n+1

Walsh Code Channel Index (low part) = <any value> (Ignored) n+2

Pilot PN Code (low part) = <any value> (Ignored) n+3

Pilot

PN

Code

(high

part)

= <any

value>

(Ignored)

Reserved = [00] Power

Combined

= [0]

Freq.

included

= [1]

ARFCN (high part)

= [000-111]

n+4

ARFCN (low part) = [00H-FFH] n+5

3GPP2 A.S0024-A v1.0

5-5


7 6 5 4 3 2 1 0 Octet

} Channel Information

Long Code: A1 Element Identifier = [50H] 1

Length = [06H] 2

Reserved = [00 0000] (MSB) 3

Long Code = <any value> 4

5

6

7

(LSB) 8

Measurement Response Options: A1 Element Identifier [51H] 1

Length = 02H 2

Reserved = [0000 00] Error

Report

Suppressi

on = [0,1]

Low Signal

Report

Suppression

= [0,1]

3

(MSB) Measurement Response Timer = <any value> (LSB) 4

Mobile Identity (MN ID): A1 Element Identifier [0DH] 1

Length = [06H - 08H] (10 - 15 digits) 2

Identity Digit 1 = [0H-9H] (BCD) Odd/even

Indicator

= [1,0]

Type of Identity =

[001 (MEID – Hex Digits),

110 (IMSI – BCD Digits)]

3

Identity Digit 3 = [0H-9H] (BCD) Identity Digit 2 = [0H-9H] (BCD) 4

… … …

Identity Digit N+1 = [0H-9H] (BCD) Identity Digit N = [0H-9H] (BCD) n

= [1111] (if even number of digits) Identity Digit N+2 = [0H-9H] (BCD) n+1

5.1.1.2 Measurement Response 1

This BSMAP message is sent from the target FAP to the FCS to indicate whether or not the MS has been 2

located and to provide link signal strength measurement information if available. This message is sent in 3

response to a Measurement Request message. 4


Reference

Element

Direction

Type

Message Type 5.2.1.2 FAP FCS M

Long Code 5.2.1.3 FAP FCS Oa R

Cause 5.2.1.4 FAP FCS Ob R

Measurement Report 5.2.1.6 FAP FCS Oc C

Mobile Identity 5.2.1.10 FAP FCS Od C

3GPP2 A.S0024-A v1.0

5-6

a. This IE shall be included and set to the Long Code received in the corresponding Measurement 1

Request message. 2

b. This IE shall be included and indicates a successful measurement, the reason why measurement 3

information could not be provided or a condition related to the included measurement information. 4

c. This IE is included to provide the requested signal strength information, when available. 5

d. This IE is included if it was received in the Measurement Request message. 6

The following table shows the bitmap layout for the Measurement Response message. 7

5.1.1.2 Measurement Response

7 6 5 4 3 2 1 0 Octet




Long Code: A1 Element Identifier = [50H] 1

Length = [06H] 2

Reserved = [00 0000] (MSB) 3

Long Code = <any value> 4

5

6

7

(LSB) 8

Cause: A1 Element Identifier = [04H] 1

Length = [01H] 2

ext =

[0]

Cause value =

[01H (Radio interface failure),

07H (OAM&P intervention),

20H (Equipment failure),

21H (No radio resource available),

25H (BS not equipped),

60H (Protocol error between BS and MSC),

70H (Measurement successful),

72H (MS not detected),

73H (MS not allowed),

74H (BS busy),

75H (Terrestrial resources are not available),

76H (Measurement procedure time-out)]

3

Measurement Report: A1 Element Identifier = [52H] 1

Length = [12H] 2

(MSB) BS Tx Pilot Power = <any value> (LSB) 3

(MSB) MS Rx Pilot Strength = <any value> (LSB) 4

3GPP2 A.S0024-A v1.0

5-7

5.1.1.2 Measurement Response

7 6 5 4 3 2 1 0 Octet

(MSB) Measurement Start Timestamp = <any value> 5

… …

(LSB) 12

(MSB) Measurement End Timestamp = <any value> 13

… …

(LSB) 20


Length = [06H - 08H] (10 - 15 digits) 2


Indicator

= [1,0]

Type of Identity =


110 (IMSI – BCD Digits)]

3


… … …



5.1.1.3 Femtocell Supplementary Info 1

The BSMAP Femtocell Supplementary Info message is sent between the FCS and the FAP to provide 2

additional Femtocell related information. 3


Reference

Element

Direction

Type

Message Type 5.2.1.2 FCS FAP M

Global RAND Key 5.2.1.7 FCS FAP Oa C

Called Party BCD Number [5] FCS FAP Ob C

Cell Identifier List [5] FCS FAP Oc C

Pilot List 5.2.1.8 FCS FAP Od C

Nonce 5.2.1.9 FCS FAP Oe C

Authentication Response Parameter [5] FCS FAP Oe C

a. This IE is sent to the FAP when the FCS chooses to update the GLOBAL_RAND_KEY at the FAP. 4

Refer to S.S0132 [11]. 5

b. This IE is sent to the FAP when the MS successfully registers via the FAP. The IE shall contain the 6

MDN of the MS registered via the FAP, sent in Called Party BCD format with the Type of Number 7

field set to “Unknown”. 8

c. This IE is sent to the FCS after the FAP successfully performs IMS registration (or its neighboring 9

cell information changes) to provide the list of IS-41 Cell Global Identifier for neighboring cells. 10

d. This IE is sent to the FCS after the FAP successfully completes IMS registration (or its PN 11

information changes). 12

3GPP2 A.S0024-A v1.0

5-8

e. This IE is sent to the FCS when the FAP performs a Global Challenge Broadcast and sends the 1

response from the MS to the FCS (in an Authentication Response Parameter IE in an associated 2

IOS message), refer to A.S0014 [5]. 3

The following table shows the bitmap layout for the Femtocell Supplementary Info message. 4

5.1.1.3 Femtocell Supplementary Info

7 6 5 4 3 2 1 0 Octet




Global RAND Key: A1 Element Identifier = [53H] 1


(MSB) Global RAND Key Value = <any value> 3

… …

(LSB) n

Called Party BCD Number: A1 Element Identifier = [5EH] 1


= [1] Type of Number

= [000]

Number Plan Identification

= [0000-1111]

3

Number Digit/End Mark 2 = [0000-1111] Number Digit/End Mark 1 = [0000-1111] 4

Number Digit/End Mark 4 = [0000-1111] Number Digit/End Mark 3 = [0000-1111] 5

… …

Number Digit/End Mark m+1 = [0000-

1111]

Number Digit/End Mark m = [0000-

1111]

n

Cell Identifier List: A1 Element Identifier = [1AH] 1


Cell Identification Discriminator = [07H] 3

} Cell Identification {1+:


j+1

(LSB) j+2



Omni)

(LSB) j+4


Pilot List: A1 Element Identifier = [54H] 1


Number of Pilots = [01H-10H] 3

3GPP2 A.S0024-A v1.0

5-9

5.1.1.3 Femtocell Supplementary Info

7 6 5 4 3 2 1 0 Octet

} Pilot Entry { Number of Pilots: {1+:

Channel Record Length = <variable> j

(MSB) Channel Record = <any value> j+1

… …

(LSB) k

Reserved (MSB) Pilot PN Information = <any value> k+1

(LSB) k+2

} Pilot Entry

Nonce: A1 Element Identifier = [55H] 1


(MSB) Nonce Value = <any value> 3

… …

(LSB) n

Authentication Response Parameter: A1 Element Identifier = [42H] 1

Length = 04H 2

Reserved = [0000] Auth Signature Type = [0001] (AUTHR)

[0010] (AUTHU)

3

[0] [0] [0] [0] [0] [0] (MSB) 4

Auth Signature = <any value> 5

(LSB) 6

5.1.1.4 MS OOB Indication 1

This BSMAP message is sent from the target FAP to the FCS to indicate the presence or absence of an 2

MS in the proximity of the FAP, for enhanced active macro BS to FAP handoff. 3


Reference

Element

Direction

Type

Message Type 5.2.1.2 FAP FCS M

Mobile Identity 5.2.1.10 FAP FCS Oa R

OOB Indication 5.2.1.11 FAP FCS Ob R

a. This IE shall be set to the IMSI or the MEID. One or more instances of this IE may be included for 4

the MS, including IMSI, MEID or the OOB Identity. 5

b. This IE identifies the MS OOB indication type. 6

3GPP2 A.S0024-A v1.0

5-10

The following table shows the bitmap layout for the MS OOB Indication message. 1

5.1.1.4 MS OOB Indication

7 6 5 4 3 2 1 0 Octet





Length = [06H - 08H] (10 - 15 digits) 2

Identity Digit 1 = [0H-9H] (BCD), if Type

of Identity = 110 (IMSI),

= [0H-FH] if Type of Identity = 001)

= 0H if Type of Identity = 000 (OOB)

Odd/even

Indicator

= [1,0]

Type of Identity =


110 (IMSI – BCD Digits),

000 (OOB-ID)]

3

IF (Type of Identity = 001), Identity {1:

MEID Hex Digit 3 = [0H-FH] MEID Hex Digit 2 = [0H-FH] 4






Fill = [FH] MEID Hex Digit 14 = [0H-FH] 10

IF (Type of Identity = 110), Identity {1:


… … …



OR IF (Type of Identity = 000), Identity {1:

OOB Type = <any value> 4

(MSB) OOB Identity = <any value> 5

… …

(LSB) n

OOB Indication: A1 Element Identifier = [57H] 1

Length = [09H] 2

Detected

= [0,1]

Reserved = 000 0000

3

(MSB) Time Stamp = <any value> 4

… …

(LSB) 11

3GPP2 A.S0024-A v1.0

5-11

5.1.2 A25 Message Definition 1

5.1.2.1 A25-FAP Registration Request 2

This message is sent from the FAP to the FGW for 1x FAP registration. 3

Information Element Section Reference Element Direction Type

Message Type 5.2.2.3 FAP FGW M

FAP Identifier 5.2.2.4 FAP FGW Oa R

1x Cell Info 5.2.2.5 FAP FGW Ob R

Cell Identifier List 5.2.2.7 FAP FGW Oc C

a. This IE shall take form of NAI <FAPID@realm>, where FAPID is the FAP Equipment Identifier 4

(FEID), refer to S.S0132 [11], and realm is the name of Femtocell network that owns the FAP. 5

b. Multiple instances of this IE may be included, where one instance of this IE contains one 1x Cell info. 6

c. This IE is sent to the FGW after the FAP successfully discovers the IS-41 Cell Global Identifier for 7

neighboring cells. 8

The following table shows the bitmap layout for the A25-FAP Registration Request message. 9

5.1.2.1 A25-FAP Registration Request

7 6 5 4 3 2 1 0 Octet


FAP Identifier: A25 Element Identifier = [74H] 1

Length = [variable] 2

(MSB) FAP-ID = <any value> 3

… …

(LSB) n

1x Cell Info: A25 Element Identifier = [02H] 1


(MSB) MSCID = <any value> 3

4

(LSB) 5

(MSB) Cell = <any value> 6

Sector = <any value> (LSB) 7

Pilot PN Code(low part) = <any value> 8

Pilot PN

Code (high

part) = <any

value>

Frequen

cy

Included

= [0,1]

Reserved = [000] ARFCN (high part) = <any

value>

9

ARFCN (low part) = <any value> 10

Cell Identifier List: A25 Element Identifier = [1AH] 1


3GPP2 A.S0024-A v1.0

5-12


7 6 5 4 3 2 1 0 Octet

Cell Identification Discriminator = [07H] 3

} Cell Identification {1+:


j+1

(LSB) j+2


Sector = [0H-FH] (0H = Omni) (LSB) j+4


1

5.1.2.2 A25-FAP Registration Response 2

This message is sent from the FGW in response to a 1x FAP registration. 3


Message Type 5.2.2.3 FGW FAP M

FAP Identifier 5.2.2.4 FGW FAP Oa R

Reg/Dereg Cause 5.2.2.6 FGW FAP O R

a. The FGW shall set the value of this IE to the value of the FAP Identifier IE of the A25-FAP 4

Registration Request message to which it is responding. 5

The following table shows the bitmap layout for the A25-FAP Registration Response message. 6

5.1.2.2 A25-FAP Registration Response

7 6 5 4 3 2 1 0 Octet





… …

(LSB) n

Reg/Dereg Cause: A25 Element Identifier = [03H] 1

Length = [01H] 2

Cause value = [01H (Success),

[02H (Rejected),

03H (Overload),

04H (Unauthorized FAP),

05H (OAM&P intervention),

06H (Transport resource unavailable),

08H (Unspecified)]

3

3GPP2 A.S0024-A v1.0

5-13

1

5.1.2.3 A25-FAP Deregistration 2

This message is sent from either the FAP or the FGW for deregistration of the FAP. 3


Message Type 5.2.2.3 FAP ↔ FGW M

Reg/Dereg Cause 5.2.2.6 FAP ↔ FGW O R

4

The following table shows the bitmap layout for the A25-FAP Deregistration message. 5

5.1.2.3 A25-FAP Deregistration

7 6 5 4 3 2 1 0 Octet


Reg/Dereg Cause: A26 Element Identifier = [03H] 1

Length = [01H] 2

Cause value = [04H (Unauthorized FAP),

05H (OAM&P),

07H (Power off),

08H (Unspecified)]

3

5.1.2.4 A25-Measurement Request 6

This message is sent from the FGW to a target FAP to request that the FAP provide measurement 7

information for an MS to be potentially handed off to that FAP. 8

The A25-Measurement Request message format is identical to the A1 Measurement Request message 9

format. Refer to 5.1.1.1. 10

5.1.2.5 A25-Measurement Response 11

This message is sent from the target FAP to the FGW to indicate whether or not the MS has been located 12

and to provide link signal strength measurement information if available. This message is sent in response 13

to an A25-Measurement Request message. 14

The A25 Measurement Response message format is identical to the A1 Measurement Response message 15

format. Refer to 5.1.1.2. 16

5.1.2.6 A25-MS OOB Indication 17

This message is sent from the target FAP to the FGW to indicate the presence or absence of an MS in the 18

proximity of the FAP, for enhanced active macro BS to FAP handoff. 19

The A25-MS OOB Indication message format is identical to the A1 MS OOB Indication message format. 20

Refer to 5.1.1.4. 21

3GPP2 A.S0024-A v1.0

5-14

5.1.2.7 A25-Femtocell Supplementary Info 1

The A25-Femtocell Supplementary Info message is sent between the FGW and the FAP to provide 2

additional Femtocell related information. 3


Reference

Element Direction Type

Message Type 5.2.2.3 FGW ↔ FAP M C

Global RAND Key 5.2.2.19 FGW FAP Oa C

Mobile Identity (IMSI) 5.2.2.15 FGW FAP Ob C

Nonce 5.2.2.21 FGW FAP Ob C

Authentication Response Parameter

(AUTHR)

5.2.2.20 FGW FAP Oc C

a. This IE shall be included when the FGW updates the GLOBAL_RAND_KEY at the FAP. Refer to 4

S.S0132 [11]. 5

b. This IE shall be included when the Authentication Response Parameter (AUTHR) IE is included in 6

this message. 7

c. This IE contains the authentication response signature (AUTHR) received from an authentication 8

capable MS when broadcast authentication is active. 9

The following table shows the bitmap layout for the A25-Femtocell Supplementary Info message. 10

5.1.2.7A25-Femtocell Supplementary Info

7 6 5 4 3 2 1 0 Octet


Global RAND Key: A25 Element Identifier = [53H] 1


(MSB) Global RAND Key Value = <any value> 3

… …

(LSB) n


Length = [06H - 08H] (10 - 15 digits) 2


Indicator

= [1,0]

Type of Identity

= [110] (IMSI)

3


… …


= [1111] (if even number of digits),

Identity Digit N+3 = [0H-9H] (BCD) (if

odd number of digits)

Identity Digit N+2 = [0H-9H] (BCD) n+1

Nonce: A25 Element Identifier = [55H] 1


3GPP2 A.S0024-A v1.0

5-15

5.1.2.7A25-Femtocell Supplementary Info

7 6 5 4 3 2 1 0 Octet

(MSB) Nonce Value = <variable> 3

… …

(LSB) n

Authentication Response Parameter (AUTHR): A25 Element

Identifier = [54H]

1

Length = [04H] 2

Reserved = [0000] Auth Signature Type = [0001] (AUTHR) 3

[0] [0] [0] [0] [0] [0] (MSB) 4

Auth Signature = <any value> 5

(LSB) 6

1

5.1.3 A26 Message Definitions 2

5.1.3.1 A26-FAP Registration Request 3

This message is sent from the FAP to the FGW for registration. 4



FAP Identifier 5.2.3.4 FAP FGW O R

Sector Info 5.2.3.5 FAP FGW Oa R

a. Multiple instances of this IE may be included, where one instance of this IE contains one Sector info. 5

The following table shows the bitmap layout for the A26-FAP Registration Request message. 6


7 6 5 4 3 2 1 0 Octet





… …

(LSB) n

Sector Info {1+:

Sector Info: A26 Element Identifier = [02H] 1

Length = [05H] 2

Pilot PN (low part) = <any value> 3

3GPP2 A.S0024-A v1.0

5-16


7 6 5 4 3 2 1 0 Octet

Pilot PN

(high part)

= <any

value>

Reserved = [000 0000] 4

(MSB) Channel = <any value> 5

6

(LSB) 7

} Sector Info

5.1.3.2 A26-FAP Registration Response 1

This message is sent from the FGW in response the FAP‟s registration. 2



FAP Identifier 5.2.3.4 FGW FAP Oa R

Cause 5.2.3.10 FGW FAP O R

a. The FGW shall set the value of this IE to the value of the FAP Identifier IE of the A26-FAP 3

Registration Request message to which it is responding. 4

The following table shows the bitmap layout for the A26-FAP Registration Response message. 5

5.1.3.2 A26-FAP Registration Response

7 6 5 4 3 2 1 0 Octet





… …

(LSB) n


Length = [01H] 2

Cause value = [01H (Success)

02H (Rejected)

03H (Overload)

04H (Unauthorized FAP)

05H (OM&P intervention)

06H (Transport resource unavailable),

08H (Unspecified)]

3

3GPP2 A.S0024-A v1.0

5-17

5.1.3.3 A26-FAP Deregistration 1

This message is sent from either the FAP or the FGW for deregistration of the FAP. 2


Message Type 5.2.3.3 FAP ↔ FGW M

Cause 5.2.3.10 FAP ↔ FGW Oa R

a. When this message is sent in acknowledgement to an originating A26-FAP Deregistration message, 3

the Cause IE shall be set to the Cause IE received in that originating message. 4

The following table shows the bitmap layout for the A26-FAP Deregistration message. 5

5.1.3.3 A26-FAP Deregistration

7 6 5 4 3 2 1 0 Octet



Length = [01H] 2

Cause value = [04H (Unauthorized FAP),

05H (OAM&P),

07H (Power off),

08H (Unspecified)]

3

5.1.3.4 A26-Measurement Request 6

This message is sent from the FGW to a target FAP to request that the FAP provide measurement 7

information for an AT to be potentially handed off to that FAP. 8



AT-ID 5.2.3.6 FGW FAP Oa R

FAP Identifier 5.2.3.4 FGW FAP O R

Sector Info 5.2.3.5 FGW FAP Ob R

Long Code Mask 5.2.3.7 FGW FAP Oc R

Measurement Response Options 5.2.3.8 FGW FAP O R

a. This IE identifies the session of the AT and shall be set to the last UATI that the AT has confirmed 9

before this message is sent. 10

b. This IE carries the candidate target sector information for handoff. 11

c. This IE shall be included and set to the Reverse Traffic Channel Long Code Mask in use by the AT. 12

The following table shows the bitmap layout for the A26-Measurement Request message. 13

5.1.3.4 A26-Measurement Request

7 6 5 4 3 2 1 0 Octet

A26 Message Type = [04H] 1

AT-ID: A26 Element Identifier = [04H] 1

3GPP2 A.S0024-A v1.0

5-18


7 6 5 4 3 2 1 0 Octet

Length = [05H] 2

Reserved = [0000] ATI Type = [0010 (UATI 32)] 3

(MSB) AT-ID = <any value> 4

5

6

(LSB) 7




… …

(LSB) n

Sector Info: A26 Element Identifier = [02H] 1

Length = [05H] 2

Pilot PN (low part) = <any value> 3

Pilot PN

(high

part) =

<any

value>

Reserved = [000 0000] 4

(MSB) Channel = <any value> 5

6

(LSB) 7

Long Code Mask: A26 Element Identifier = [05H] 1

Length = [0CH] 2

Reserved = [00 0000] (MSB) 3

LCM_MI = <any value> 4

5

6

7

(LSB) 8

Reserved = [00 0000] (MSB) 9

LCM_MQ = <any value> 10

11

12

13

(LSB) 14

3GPP2 A.S0024-A v1.0

5-19


7 6 5 4 3 2 1 0 Octet

Measurement Response Options: A26 Element Identifier [06H] 1

Length = [02H] 2

Reserved = [0000 00] Error

Report

Suppressi

on = [0,1]

Low

Signal

Report

Suppressi

on = [0,1]

3

(MSB) Measurement Response Timer = <any value> (LSB) 4

5.1.3.5 A26-Measurement Response 1

This message is sent from the target FAP to the FGW to indicate whether or not the AT has been located 2

and to provide link signal strength measurement information if available. This message is sent in response 3

to an A26-Measurement Request message. 4


Reference

Element

Direction

Type


AT-ID 5.2.3.6 FAP FGW Oa R

FAP Identifier 5.2.3.4 FAP FGW Ob R

Cause 5.2.3.10 FAP FGW Oc R

Measurement Report 5.2.3.9 FAP FGW Od C

a. The FAP shall set the value of this IE to the value of the AT-ID IE of the A26-Measurement Request 5

message to which it is responding. 6

b. The FGW shall set the value of this IE to the value of the FAP Identifier IE of the A26-Measurement 7

Request message to which it is responding. 8

c. This IE shall be included and indicates a successful measurement, the reason why measurement 9

information could not be provided or a condition related to the included measurement information. 10

d. This IE is included to provide the requested signal strength information, when available. 11

The following table shows the bitmap layout for the A26-Measurement Response message. 12

5.1.3.5 A26-Measurement Response

7 6 5 4 3 2 1 0 Octet

A26 Message Type = [05H] 1

AT-ID: A26 Element Identifier = [04H] 1

Length = [05H] 2

Reserved = [0000] ATI Type = [0010 (UATI32)] 3

(MSB) AT-ID = <any value> 4

5

6

3GPP2 A.S0024-A v1.0

5-20

5.1.3.5 A26-Measurement Response

7 6 5 4 3 2 1 0 Octet

(LSB) 7




… …

(LSB) n


Length = [01H] 2

ext = [0] Cause value =

[05H (OAM&P intervention),

21H (Radio interface failure),

22H (Equipment failure),

23H (No radio resource available),

24H (AN not equipped),

25H (Protocol error between AN and FGW),

26H (Measurement successful),

27H (AT not detected),

28H (AT not allowed),

29H (AN busy),

2AH (Terrestrial resources are not available),

2BH (Measurement procedure time-out)]

3

Measurement Report: A26 Element Identifier = [07H] 1

Length = [12H] 2

(MSB) AN Tx Pilot Power = <any value> (LSB) 3

(MSB) AT Rx Pilot Strength = <any value> (LSB) 4

(MSB) Measurement Start Timestamp = <any value> 5

… …

(LSB) 12

(MSB) Measurement End Timestamp = <any value> 13

… …

(LSB) 20

1

3GPP2 A.S0024-A v1.0

5-21

5.2 Information Element Definitions 1

5.2.1 A1 and A1p Information Element Definitions 2

5.2.1.1 A1 and A1p Information Element Identifiers 3

The following table lists all Femtocell specific IEs included in the messages defined in section 5.1.1. The 4

table includes the Information Element Identifier (IEI) coding which distinguishes one IE from another. 5

The table also includes a section reference indicating where the IE coding can be found. 6

Element Name IEI (Hex) Reference

Cause 04H 5.2.1.4

IS-2000 Channel Identity 09H [5]

CDMA Serving One Way Delay 0CH [5]

Mobile Identity 0DH 5.2.1.10

Classmark Information Type 2 12H [5]

Cell Identifier List 1AH [5]

Downlink Radio Environment 29H [5]

Authentication Response Parameter 42H [5]

Long Code 50H 5.2.1.3

Measurement Response Options 51H 5.2.1.5

Measurement Report 52H 5.2.1.6

Global RAND Key 53H 5.2.1.7

Pilot List 54H 5.2.1.8

Nonce 55H 5.2.1.9

Called Party BCD Number 5EH [5]

Refer to [5] for additional IEIs used on the A1 interface. 7

5.2.1.2 Message Type 8

The A1 Message Type IE is used to indicate the type of message on the A1 interface. 9

5.2.1.2 Message Type

7 6 5 4 3 2 1 0 Octet

Message Type 1

Message Type This octet is coded as shown in Table 5.2.1.2-1. 10

Table 5.2.1.2-1 BSMAP Messages

BSMAP Message Name

Message

Type

Value

Message Category

Section

Reference

Measurement Request 71H Radio Resource Mgmt. 5.1.1.1

Measurement Response 72H Radio Resource Mgmt. 5.1.1.2

Femtocell Supplementary Info 73H Radio Resource Mgmt. 5.1.1.3

3GPP2 A.S0024-A v1.0

5-22

Table 5.2.1.2-1 BSMAP Messages

BSMAP Message Name

Message

Type

Value

Message Category

Section

Reference

MS OOB Indication 74H Radio Resource Mgmt. 5.1.1.4

BSMAP messages are used to perform functions at the MSC or BS. Refer to [5] for additional Message 1

Types used on the A1 interface. 2

5.2.1.3 Long Code 3

This IE is used to provide either the Public Long Code Mask or the Private Long Code in use by the MS, 4

to the FAP. 5

5.2.1.3 Long Code

7 6 5 4 3 2 1 0 Octet

A1 Element Identifier 1

Length 2

Reserved (MSB) 3

Long Code 4

5

6

7

(LSB) 8

Length This field is defined as the number of octets following the Length field. 6

Long Code This 42-bit field shall be set to the Public Long Code if any of the following 7

conditions are true: 8

Public Long Code is received by the FCS in the FACDIR2 message, or 9

if the Public Long Code Mask is not included and the received Encryption 10

Information does not include the Encryption Parameter Identifier field with 11

the value set to „00100‟ (Private Longcode) and the corresponding Status bit 12

set to „1‟ (active), i.e., then the Public Long Code is derived from the Mobile 13

Identity (ESN) IE. 14

Otherwise this field shall be set to the received Private Long Code value. 15

5.2.1.4 Cause 16

This IE is used to indicate the reason for occurrence of a particular event and is coded as follows. 17

5.2.1.4 Cause

7 6 5 4 3 2 1 0 Octet


Length 2

0/1 Cause value 3


3GPP2 A.S0024-A v1.0

5-23

Cause value The Cause value field is a single octet field if the extension bit (bit 7) is set to „0‟. 1

If bit 7 of octet 3 is set to „1‟ then the Cause value is a two octet field. If the value 2

of the first octet of the cause field is „1XXX 0000‟ then the second octet is 3

reserved for national applications, where „XXX‟ indicates the Cause Class as 4

indicated in Table 5.2.1.4-1. Otherwise, the Cause values are defined in Table 5

5.2.1.4-2. 6

Table 5.2.1.4-1 Cause Class Values 7

Binary Values Meaning

000 Normal event

001 Normal event

010 Resource unavailable

011 Service or option not available

100 Service or option not implemented

101 Invalid message (e.g., parameter out of range)

110 Protocol error

111 Interworking

8

Table 5.2.1.4-2 Cause Values

6 5 4 3 2 1 0 Hex Value Cause

Normal Event Class (000 xxxx and 001 xxxx)

0 0 0 0 0 0 0 00 Radio interface message failure

0 0 0 0 0 0 1 01 Radio interface failure

0 0 0 0 0 1 0 02 Uplink quality

0 0 0 0 0 1 1 03 Uplink strength

0 0 0 0 1 0 0 04 Downlink quality

0 0 0 0 1 0 1 05 Downlink strength

0 0 0 0 1 1 0 06 Distance

0 0 0 0 1 1 1 07 OAM&P intervention

0 0 0 1 0 0 0 08 MS busy

0 0 0 1 0 0 1 09 Call processing

0 0 0 1 0 1 0 0A Reversion to old channel

0 0 0 1 0 1 1 0B Handoff successful

0 0 0 1 1 0 0 0C No response from MS

0 0 0 1 1 0 1 0D Timer expired

0 0 0 1 1 1 0 0E Better cell (power budget)

0 0 0 1 1 1 1 0F Interference

0 0 1 0 0 0 0 10 Packet call going dormant

0 0 1 0 0 0 1 11 Service option not available

0 0 1 0 1 0 1 15 Short data burst authentication failure

0 0 1 0 1 1 1 17 Time critical relocation/handoff

0 0 1 1 0 0 0 18 Network optimization

0 0 1 1 0 0 1 19 Power down from dormant state

0 0 1 1 0 1 0 1A Authentication failure

0 0 1 1 0 1 1 1B Inter-BS soft handoff drop target

0 0 1 1 1 0 1 1D Intra-BS soft handoff drop target

0 0 1 1 1 1 0 1E Autonomous Registration by the Network

Resource Unavailable Class (010 xxxx)

0 1 0 0 0 0 0 20 Equipment failure

3GPP2 A.S0024-A v1.0

5-24

Table 5.2.1.4-2 Cause Values

6 5 4 3 2 1 0 Hex Value Cause

0 1 0 0 0 0 1 21 No radio resource available

0 1 0 0 0 1 0 22 Requested terrestrial resource unavailable

0 1 0 0 0 1 1 23 A2p RTP Payload Type not available

0 1 0 0 1 0 0 24 A2p Bearer Format Address Type not available

0 1 0 0 1 0 1 25 BS not equipped

0 1 0 0 1 1 0 26 MS not equipped (or incapable)

0 1 0 0 1 1 1 27 2G only sector

0 1 0 1 0 0 0 28 2G only carrier

0 1 0 1 0 0 1 29 PACA call queued

0 1 0 1 0 1 0 2A Handoff blocked

0 1 0 1 0 1 1 2B Alternate signaling type reject

0 1 0 1 1 0 0 2C A2p Resource not available

0 1 0 1 1 0 1 2D PACA queue overflow

0 1 0 1 1 1 0 2E PACA cancel request rejected

Service or Option Not Available Class (011 xxxx)

0 1 1 0 0 0 0 30 Requested transcoding/rate adaptation unavailable

0 1 1 0 0 0 1 31 Lower priority radio resources not available

0 1 1 0 0 1 0 32 PCF resources are not available

0 1 1 0 0 1 1 33 TFO control request failed

0 1 1 0 1 0 0 34 MS rejected order

Service or Option Not Implemented Class (100 xxxx)

1 0 0 0 1 0 1 45 PDS-related capability not available or not

supported)

Invalid Message Class (101 xxxx)

1 0 1 0 0 0 0 50 Terrestrial circuit already allocated

Protocol Error (110 xxxx)

1 1 0 0 0 0 0 60 Protocol error between BS and MSC

Interworking (111 xxxx)

1 1 1 0 0 0 0 70 Measurement successful

1 1 1 0 0 0 1 71 ADDS message too long for delivery on the paging

channel

1 1 1 0 0 1 0 72 MS not detected

1 1 1 0 0 1 1 73 MS not allowed

1 1 1 0 1 0 0 74 BS busy

1 1 1 0 1 0 1 75 Terrestrial resources are not available

1 1 1 0 1 1 0 76 Measurement procedure time-out

1 1 1 0 1 1 1 77 PPP session closed by the MS

1 1 1 1 0 0 0 78 Do not notify MS

1 1 1 1 0 0 1 79 PDSN resources are not available

1 1 1 1 0 1 1 7B Concurrent authentication

1 1 1 1 1 0 0 7C MS incorrect integrity info

1 1 1 1 1 1 1 7F Handoff procedure time-out

All other values Reserved for future use.

5.2.1.5 Measurement Response Options 1

This IE is used to provide options related to the Measurement Response message. 2

5.2.1.5 Measurement Response Options

7 6 5 4 3 2 1 0 Octet

3GPP2 A.S0024-A v1.0

5-25


7 6 5 4 3 2 1 0 Octet


Length 2

Reserved Error

Report

Suppress

-ion

Low

Signal

Report

Suppress-

ion

3

(MSB) Measurement Response Timer (LSB) 4

Length This field indicates the number of octets in this IE following the Length 1

field. 2

Error Report Suppression This bit shall be set to „1‟ if the FAP may omit responding with a 3

Measurement Response message when the Cause value is not 4

Measurement successful. Otherwise, this bit shall be set to „0‟. 5

Low Signal Report Suppression This bit shall be set to „1‟ if the FAP may omit responding with a 6

Measurement Response message when the MS measurement result is 7

below the operator‟s configurable threshold. Otherwise, this bit shall be 8

set to „0‟. 9

Measurement Response Timer This field is an 8-bit binary number, in units of 80 ms., which indicates 10

the duration of the timer, starting at the receipt of the Measurement 11

Request message, in which the FAP should respond with a Measurement 12

Response message. 13

5.2.1.6 Measurement Report 14

This IE is used to provide FAP transmit pilot power and receive pilot signal strength for the requested 15

MS. 16

5.2.1.6 Measurement Report

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) BS Tx Pilot Power (LSB) 3

(MSB) MS Rx Pilot Strength (LSB) 4

(MSB) Measurement Start Timestamp 5

… …

(LSB) 12

(MSB) Measurement End Timestamp 13

… …

(LSB) 20


field. 18

3GPP2 A.S0024-A v1.0

5-26

BS Tx Pilot Power This field indicates the FAP‟s pilot power. If the FAP‟s pilot power is 1

within the range of -128 to 127 dBm, the FAP shall set this field to the 2

two‟s complement representation of its Pilot Channel Power (in dBm). 3

Otherwise, if the pilot power is below -128 or above 127 dBm, the FAP 4

shall set this field to the two‟s complement representation of -128 or 127, 5

respectively. 6

MS Rx Pilot Strength This field indicates the received power of the MS pilot channel measured 7

at the FAP RF input ports. If the received power is in the range of -127.5 8

to 0 dBm, the FAP shall set this field to the nearest integer value of -2 x 9

the received power (in dBm). For example, if the received power is -10

20.25 dBm this field is set to 41. Otherwise if the received power is 11

below -127.5 or above 0 dBm, the FAP shall set this field to 255 or 0, 12

respectively. 13

Measurement Start Timestamp This field is a 64-bit binary number set to the CDMA System Time at the 14

time that the MS Rx Pilot measurement in this IE is started. The time 15

stamp is in units of 80 ms. 16

Measurement End Timestamp This field is a 64-bit binary number set to the CDMA System Time at the 17

time that the MS Rx Pilot measurement in this IE is finished. The time 18


20

5.2.1.7 Global RAND Key 21

This IE is used to update the FAP with the GLOBAL_RAND_KEY used to generate and broadcast the 22

Global Challenge. 23

5.2.1.7 Global RAND Key

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) Global RAND Key Value 3

… …

(LSB) n


field. 25

Global RAND Key Value This field contains the GLOBAL_RAND_KEY to be used by the FAP to 26

generate and broadcast the Global Challenge. Refer to S.S0132 [11]. 27

5.2.1.8 Pilot List 28

This IE is used to update the FCS with the FAP‟s Pilot List information, after successful IMS registration 29

or when the FAPs PN information changes. 30

5.2.1.8 Pilot List

7 6 5 4 3 2 1 0 Octet


Length 2

Number of Pilots 3

3GPP2 A.S0024-A v1.0

5-27

5.2.1.8 Pilot List

7 6 5 4 3 2 1 0 Octet

Channel Record Length j

(MSB) Channel Record j+1

… …

(LSB) k

Reserved (MSB) Pilot PN Information k+1

(LSB) k+2


field. 2

Number of Pilots This field indicates the number of pilots represented by this IE. The 3

Channel Record and Pilot PN Phase are indicated for each pilot. 4

Channel Record Length This field contains the numbers of octets in the Channel Record field as a 5

binary number. 6

Channel Record This field contains a channel record as defined in C.S0024 [9]. The 7

information contained in a channel record include the system type, band 8

class, and channel number. 9

Pilot PN Information This field contains the Pilot PN Phase of the pilot. Refer to C.S0024 [9]. 10

5.2.1.9 Nonce 11

This IE is used to update the FCS with the NONCE used by the FAP to generate the Global Challenge 12

Broadcast. 13

5.2.1.9 Nonce

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) Nonce Value 3

… …

(LSB) n


field. 15

Nonce Value This field contains the NONCE used by the FAP to generate the Global 16

Challenge Broadcast. Refer to S.S0132 [11]. 17

18

5.2.1.10 Mobile Identity 19

This IE is used to provide the mobile‟s IMSI or OOB Identity. 20

5.2.1.10 Mobile Identity

7 6 5 4 3 2 1 0 Octet


3GPP2 A.S0024-A v1.0

5-28

5.2.1.10 Mobile Identity

7 6 5 4 3 2 1 0 Octet

Length 2

MSID Value variable

Length: This field contains the number of octets in this IE following this 1

field as a binary number. 2

MSID Value: The MSID value is determined by the Type of Identity field, 3

included within the value, as follows. 4

Type of Identity: This field is defined as follows. 5

Table 5.2.1.10-1 Mobile Identity - Type of Identity Coding 6

Binary

Values

Mobile Identity Meaning

„000‟ OOB

„001‟ MEID

„110‟ IMSI

„101‟ ESN

All other values are reserved.

For Mobile Identity Type „001‟ (MEID), the Mobile Identity fields are set as follows. 7

5.2.1.10 Mobile Identity - 1

7 6 5 4 3 2 1 0 Octet

MEID Hex Digit 1 Odd/even

Indicator

Type of Identity 3

MEID Hex Digit 3 MEID Hex Digit 2 4






Fill MEID Hex Digit 14 10

Odd/Even Indicator (octet 3; bit 3): This field is set to „0‟. 8

MEID Hex Digits: The MEID Identity Digit fields are coded using 14 hexadecimal 9

digits and bits 4 to 7 of the last octet shall be filled with „1111‟. 10

For Mobile Identity Type „110‟ (ESN), the MSID Value is coded as follows. 11


7 6 5 4 3 2 1 0 Octet

Identity Digit 1 Odd/even

Indicator

Type of Identity 3

3GPP2 A.S0024-A v1.0

5-29


7 6 5 4 3 2 1 0 Octet

(MSB) ESN 4

5

6

(LSB) 7


Identity Digit 1: Identity Digit 1 in octet 3 is unused and coded as „0000‟. 2

ESN: The ESN is not separated into digits, and occupies octets 4-7 3

with the most significant bit in octet 4 bit 7. 4

Note: ESN may be the true ESN, UIM_ID or the pseudo ESN 5

(derived from the MEID or received in a Status Response 6

Message from the MS). 7

For Mobile Identity Type „110‟ (IMSI), the Mobile Identity fields are set as follows. 8


7 6 5 4 3 2 1 0 Octet

Identity Digit 1 Odd/Even

Indicator

Type of Identity 3

Identity Digit 3 Identity Digit 2 4

… …

Identity Digit N+1 Identity Digit N n

Odd/Even Indicator (octet 3; bit 3): This field is set to „0‟ for an even number of digits and to „1‟ for 9

an odd number of identity digits. 10

Identity Digits (octet 3 etc.) The IMSI Identity Digit fields are coded using BCD coding 11

format in octet 3 with the leftmost digit of IMSI in the Identity 12

Digit 1 field. If the number of identity digits is even then bits 4 13

to 7 of the last octet shall be filled with „1111‟. For Mobile 14

Identity Type „000‟ (OOB), the Mobile Identity fields are set as 15

follows. 16


7 6 5 4 3 2 1 0 Octet

Identity Digit 1 Odd/Even

Indicator

Type of Identity 3

OOB Type 4

(MSB) OOB Identity 5

… …

(LSB) n


3GPP2 A.S0024-A v1.0

5-30

Identity Digit 1 (octet 3) This field is set to 0H. 1

Identity This field is set as follows. 2

OOB Type This field indicates the type of out-of-band identifier and is 3

coded as follows. 4

Table 5.2.1.10-2 Mobile Identity - Type of OOB Identity Coding 5

Binary

Values

OOB Identity Meaning

„0000 0001‟ EUI-48

„0000 0010‟ EUI-64

All other values are reserved.

If the OOB Type is set to 01H (EUI-48), the OOB Identity is set as follows. 6

OOB Identity This field contains the 48-bit Extended Unique Identifier (EUI-7

48™). Refer to [I-4]. 8

If the OOB Type is set to 02H (EUI-64), the OOB Identity is set as follows. 9

OOB Identity This field contains the 64-bit EUI-64™. Refer to [I-5]. 10

11

5.2.1.11 OOB Indication 12

This IE is used to identify the type of MS indication to the FCS. 13

5.2.1.11 OOB Indication

7 6 5 4 3 2 1 0 Octet


Length 2

Detected Reserved 3

(MSB) Time Stamp 4

… …

(LSB) 11

Length: This field contains the number of octets in this IE following this 14

field as a binary number. 15

Detected This field is set to „1‟ when the FAP is indicating the MS is 16

detected OOB under the FAP. Otherwise this field is set to „0‟ 17

when the FAP is indicating that the MS is no longer detected 18

OOB under the FAP. 19

Time Stamp This field is a 64-bit binary number set to the CDMA System 20

time for when the MS OOB detection event occurred. The time 21


23

3GPP2 A.S0024-A v1.0

5-31

5.2.2 A25 Information Element Definitions 1

5.2.2.1 A25 Information Element Identifiers 2

The following table lists all the IEs that make up the messages defined in section 5.1.2. The table includes 3

the IEI coding which distinguishes one IE from another. The table also includes a section reference 4

indicating where the IE coding can be found. 5

The IEIs used in A25-Measurement Request message are identical to the IEIs of A1 Measurement 6

Request message. 7

The IEIs used in A25-Measurement Response message are identical to the IEIs of A1 Measurement 8

Response message. 9

10


1x Cell Info 02H 5.2.2.5

Reg/Dereg Cause 03H 5.2.2.6

Cause 04H 5.2.2.17

IS-2000 Channel Identity 09H 5.2.2.12

CDMA Serving One Way Delay 0CH 5.2.2.10

Mobile Identity 0DH 5.2.2.15

Classmark Information Type 2 12H 5.2.2.8

Cell Identifier List 1AH 5.2.2.7

Downlink Radio Environment 29H 5.2.2.9

Long Code 50H 5.2.2.13



Global RAND Key 53H 5.2.2.19

Authentication Response Parameter (AUTHR) 54H 5.2.2.20

Nonce 55H 5.2.2.21

MS Measured Channel Identity 64H 5.2.2.11

FAP Identifier 74H 5.2.2.4

OOB Indication 75H 5.2.2.18

11

5.2.2.2 A25 Cross Reference of IEs with Messages 12

The following table provides a cross reference between the IEs and the messages defined in this 13

specification. 14

Table 5.2.2.2-1 A25 Cross Reference of IEs with Messages

Information Element Ref. IEI Used in These Messages Ref.

1x Cell Info 5.2.2.5 02H A25-FAP Registration Request 5.1.2.1

A25 Message Type 5.2.2.3 None A25-FAP Registration Request 5.1.2.1

A25-FAP Registration Response 5.1.2.2

A25-FAP Deregistration 5.1.2.3

3GPP2 A.S0024-A v1.0

5-32

A25-Measurement Request 5.1.2.4

A25-Measurement Response 5.1.2.5

A25-Femtocell Supplementary Info 5.1.2.7

Authentication Response

Parameter (AUTHR)

5.2.2.20 54H A25-Femtocell Supplementary Info 5.1.2.7

Cause 5.2.2.17 04H A25-Measurement Response 5.1.2.5

CDMA Serving One Way

Delay

5.2.2.10 0CH A25-Measurement Request 5.1.2.4

Cell Identifier List 5.2.2.7 1AH A25-FAP Registration Request 5.1.2.1


Classmark Information Type 2 5.2.2.8 12H A25-Measurement Request 5.1.2.4

Downlink Radio Environment 5.2.2.9 29H A25-Measurement Request 5.1.2.4

FAP Identifier 5.2.2.4 74H A25-FAP Registration Request 5.1.2.1


Global RAND Key 5.2.2.19 53H A25-Femtocell Supplementary Info 5.1.2.7

IS-2000 Channel Identity 5.2.2.12 09H A25-Measurement Request 5.1.2.4

Long Code 5.2.2.13 50H A25-Measurement Request 5.1.2.4


Measurement Report 5.2.2.16 52H A25-Measurement Response 5.1.2.5

Measurement Response

Options

5.2.2.14 51H A25-Measurement Request 5.1.2.4

Mobile Identity 5.2.2.15 0DH A25-Measurement Request 5.1.2.4

A25-MS OOB Indication 5.1.2.6

A25-Femtocell Supplementary Info 5.1.2.7


MS Measured Channel

Identity


Nonce 5.2.2.21 55H A25-Femtocell Supplementary Info 5.1.2.7

OOB Indication 5.2.2.18 75H A25-MS OOB Indication 5.1.2.6

Reg/Dereg Cause 5.2.2.6 03H A25-FAP Registration Response 5.1.2.2


1

5.2.2.3 A25 Message Type 2


A25 Message Name A25 Message Type Section Reference

A25-FAP Registration Request 01H 5.1.2.1

A25-FAP Registration Response 02H 5.1.2.2

A25-FAP Deregistration 03H 5.1.2.3

A25-Femtocell Supplementary Info 04H 5.1.2.7

3GPP2 A.S0024-A v1.0

5-33


A25-Measurement Request 71H 5.1.2.4

A25-Measurement Response 72H 5.1.2.5

A25-MS OOB Indication 74H 5.1.2.6

1

5.2.2.4 FAP Identifier 2

This IE is used to identify the FAP. 3

5.2.2.4 FAP Identifier

7 6 5 4 3 2 1 0 Octet

A25 Element Identifier = [074H] 1

Length 2

(MSB) FAP ID 3

… …

(LSB) n

Length This field contains the number of octets in this IE following this field as a binary 4

number. 5

FAP ID FAP ID shall take form of NAI <FAPID@realm>, where FAPID is the FAP 6

Equipment Identifier (FEID), refer to S.S0132 [11], and realm is the name of 7

Femtocell network that owns the FAP. 8

9

5.2.2.5 1x Cell Info 10

The FAP shall set this field to the sector info configured through auto-configuration phase. 11

5.2.2.5 1x Cell Info

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) MSCID 3

4

(LSB) 5

(MSB) Cell 6

Sector (LSB) 7

Pilot PN (low part) 8

Pilot PN

(high part)

Frequency

Included

Reserved ARFCN (high part) 9

ARFCN (low part) 10

Length This field indicates the number of octets in this element following the 12

Length field. 13

3GPP2 A.S0024-A v1.0

5-34

MSCID The MSCID is coded as defined in [12]. MSCID is 3 octets long where 1

the first two octets (octets 4 and 5) represent Market ID and the last octet 2

represents the Switch Number. In the MSCID field, bit 7 of octet 4 is the 3

most significant bit and bit 0 of octet 5 is the least significant bit of the 4

Market ID field. In the MSCID field bit 7 of octet 6 is the most 5

significant bit of the Switch Number field. 6

Cell/Sector In the Cell/Sector value field bit 7 of octet 3 is the most significant bit 7

and bit 0 of octet 4 is the least significant bit. Bits 3 to 0 of octet 4 8

contain the sector number (0H = omni). The coding of the cell identity is 9

the responsibility of each administrator. Coding using full hexadecimal 10

representation may be used. The cell identity consists of 2 octets 11

maximum. If an administrator has chosen N bits for the cell identity 12

where N <16 then the additional bits up to 16 are coded with a „0‟ in 13

each in the following way: 14

If 8 <N<16 the bits N-8 through 7 of octet 4 are coded with a „0‟ in each. 15

If N=8 then octet 4 is coded with a „0‟ in each bit. 16

If N<8 then octet 4 is coded with a „0‟ in each bit and bits N through 7 in 17

octet 3 are coded with a „0‟ in each. 18

Pilot PN The Pilot PN Code is one of 511 unique values for the Pilot Channel 19

offset. The offsets are in increments of 64 PN chips. 20

Frequency Included This is a flag indicating whether the frequency assignment is included. A 21

„0‟ indicates no frequency assignment is present, a „1‟ indicates a 22

frequency assignment is present and is specified in the ARFCN field of 23

this element. 24

ARFCN This field identifies the Absolute Radio Frequency Channel Number 25

relative to the band class for the call association. This channel number 26

refers to the center frequency channel. 27

5.2.2.6 Reg/Dereg Cause 28


5.2.2.6 Reg/Dereg Cause

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) Cause Value (LSB) 3


number. 31

Cause Value This field is set to the range of values as follows: 32

Hex Values Meaning

01 Success

02 Rejected

03 Overload

04 Unauthorized FAP

3GPP2 A.S0024-A v1.0

5-35

Hex Values Meaning

05 OM&P intervention

06 Transport resource unavailable

07 Power off

08 Unspecified

09-FF Reserved

5.2.2.7 Cell Identifier List 1

This IE is identical to IE „Cell Identifier List‟ on A1 interface. Refer to A.S0014 [5]. 2

5.2.2.8 Classmark Information Type 2 3

This IE is identical to IE „Classmark Information Type 2‟ on A1 interface. Refer to A.S0014 [5]. 4

5.2.2.9 Downlink Radio Environment 5

This IE is identical to IE „Downlink Radio Environment‟ on A1 interface. Refer to A.S0014 [5]. 6

5.2.2.10 CDMA Serving One Way Delay 7

This IE is identical to IE „CDMA Serving One Way Delay‟ on A1 interface. Refer to A.S0014 [5]. 8

5.2.2.11 MS Measured Channel Identity 9

This IE is identical to IE „MS Measured Channel Identity‟ on A1 interface. Refer to A.S0014 [5]. 10

5.2.2.12 IS-2000 Channel Identity 11

This IE is identical to IE „IS-2000 Channel Identity‟ on A1 interface. Refer to A.S0014 [5]. 12

5.2.2.13 Long Code 13

This IE is identical to IE „Long Code‟ on A1 interface. Refer to section 5.2.1.3. 14


This IE is identical to IE „Measurement Response Options‟ on A1 interface. Refer to section 5.2.1.5. 16

5.2.2.15 Mobile Identity 17

This IE is identical to IE „Mobile Identity‟ on A1 interface. Refer to section 5.2.1.10. 18


This IE is identical to IE „Measurement Report‟ on A1 interface. Refer to section 5.2.1.6. 20

5.2.2.17 Cause 21

This IE is identical to IE „Cause‟ on A1 interface. Refer to section 5.2.1.4. 22

5.2.2.18 OOB Indication 23

This IE is identical to IE „OOB Indication‟ on the A1 interface. Refer to 5.2.1.11. 24

5.2.2.19 Global RAND Key 25

This IE is used to update the FAP with the GLOBAL_RAND_KEY used to generate and broadcast the 26

Global Challenge. This IE is identical to IE „Global RAND Key‟ on the A1 interface. Refer to 5.2.1.7. 27

3GPP2 A.S0024-A v1.0

5-36

5.2.2.20 Authentication Response Parameter 1

This IE is identical to IE „Authentication Response Parameter‟ on the A1 interface. Refer to A.S0014 [5]. 2

5.2.2.21 Nonce 3

This IE is used to update the FGW with the Nonce used by the FAP to generate the Global Challenge 4

Broadcast. This IE is identical to IE "Nonce" on the A1 interface. Refer to 5.2.1.9. 5

5.2.3 A26 Information Element Definitions 6

5.2.3.1 A26 Information Element Identifiers 7

The following table lists all the IEs that make up the messages defined in section 5.1.3. The table includes 8

the IEI coding which distinguishes one IE from another. The table also includes a section reference 9

indicating where the IE coding can be found. 10


FAP Identifier 01H 5.2.3.4

Sector Info 02H 5.2.3.5

Cause 03H 5.2.3.10

AT-ID 04H 5.2.3.6

Long Code Mask 05H 5.2.3.7



5.2.3.2 A26 Cross Reference of IEs with Messages 11

The following table provides a cross reference between the IEs and the messages defined in this 12

specification. 13

Table 5.2.3.2-1 Cross Reference of IEs with Messages


A26 Message Type 5.2.3.3 none A26-FAP Registration Request 5.1.3.1





FAP Identifier 5.2.3.4 01H A26-FAP Registration Request 5.1.3.1




Sector Info 5.2.3.5 02H A26-FAP Registration Request 5.1.3.1


Cause 5.2.3.10 03H A26-FAP Registration Response 5.1.3.2



3GPP2 A.S0024-A v1.0

5-37

Table 5.2.3.2-1 Cross Reference of IEs with Messages


AT-ID 5.2.3.6 04H A26-Measurement Request 5.1.3.4


Long Code Mask 5.2.3.7 05H A26-Measurement Request 5.1.3.4

Measurement Response

Options


Measurement Report 5.2.3.9 07H A26-Measurement Response 5.1.3.5

5.2.3.3 A26 Message Type 1



A26-FAP Registration Request 01H 5.1.3.1

A26-FAP Registration Response 02H 5.1.3.2

A26-FAP Deregistration 03H 5.1.3.3

A26-Measurement Request 04H 5.1.3.4

A26-Measurement Response 05H 5.1.3.5

5.2.3.4 FAP Identifier 3

This IE is used to identify the FAP. 4

5.2.3.4 FAP Identifier

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) FAP ID 3

… …

(LSB) n


number. 6

FAP ID FAP ID shall take form of NAI <FAPID@realm>, FAPID is the FAP Equipment 7

Identifier (FEID), refer to S.S0132 [11], realm is the name of Femtocell network 8

that owns the FAP. 9

5.2.3.5 Sector Info 10

The FAP shall set this field to the sector info configured through auto-configuration phase. 11

5.2.3.5 Sector Info

7 6 5 4 3 2 1 0 Octet


Length 2

3GPP2 A.S0024-A v1.0

5-38

5.2.3.5 Sector Info

7 6 5 4 3 2 1 0 Octet

Pilot PN (low part) 3

Pilot PN

(high part)

Reserved 4

(MSB) Channel 5

6

(LSB) 7


number. 2

Pilot PN This field contains the Pilot PN of a sector as specified in [9] as 9 bit binary 3

number. 4

Channel This field contains the channel info of a sector. 5

5.2.3.6 AT-ID 6

This IE is used to identify the AT session in the A26 interface. 7

5.2.3.6 AT-ID

7 6 5 4 3 2 1 0 Octet


Length 2

Reserved ATI Type 3

AT identifier variable


number. 9

ATI Type Access Terminal identifier types associated with the AT are as follows. 10

Binary Values ATI Type Meaning AT identifier Length (bits)

0000 Reserved (for Broadcast ATI (BATI)) N/A

0001 Reserved (for Multicast ATI (MATI)) N/A

0010 Unicast ATI 32 (UATI 32) 32

0011 Reserved (for Random ATI (RATI)) N/A

0100 Reserved (for Unicast ATI 128 (UATI128)) N/A

(all others) (reserved)

11

For UATI32 (Type 0010), the AT identifier field is encoded as follows. 12

7 6 5 4 3 2 1 0 Octet

(MSB) UATIColorCode (LSB) 4

3GPP2 A.S0024-A v1.0

5-39

7 6 5 4 3 2 1 0 Octet

(MSB) UATI024 5

6

(LSB) 7

UATIColorCode This field contains the UATIColorCode for the AT. Refer to [9]. 1

UATI024 This field contains the UATI024 for the AT. Refer to [9]. 2

5.2.3.7 Long Code Mask 3

This IE is used to provide Long Code Mask in use by the AT, to the FAP. 4

5.2.3.7 Long Code Mask

7 6 5 4 3 2 1 0 Octet


Length 2

Reserved (MSB) 3

LCM_MI 4

5

6

7

(LSB) 8

Reserved (MSB) 9

LCM_MQ 10

11

12

13

(LSB) 14


LCM_MI This field shall be set to the value of the reverse traffic channel in-phase long 6

code mask associated with the access terminal‟s session. 7

LCM_MQ This field shall be set to the value of the reverse traffic channel quadrature-phase 8

long code mask associated with the access terminal‟s session. 9


This IE is used to provide options related to the Measurement Response message. 11


7 6 5 4 3 2 1 0 Octet


3GPP2 A.S0024-A v1.0

5-40


7 6 5 4 3 2 1 0 Octet

Length 2

Reserved Error

Report

Suppress

-ion

Low

Signal

Report

Suppress-

ion

3

(MSB) Measurement Response Timer (LSB) 4


field. 2

Error Report Suppression This bit shall be set to „1‟ if the FAP may omit responding with a 3

Measurement Response message when the Cause value is not Measure-4

ment successful. Otherwise, this bit shall be set to „0‟. 5

Low Signal Report Suppression This bit shall be set to „1‟ if the FAP may omit responding with a 6

Measurement Response message when the AT measurement result is 7

below the operator‟s configurable threshold. Otherwise, this bit shall be 8

set to „0‟. 9

Measurement Response Timer This field is an 8-bit binary number, in units of 80 ms., which indicates 10

the duration of the timer, starting at the receipt of the Measurement 11

Request message, in which the FAP should respond with a Measurement 12

Response message. 13


This IE is used to provide FAP transmit pilot power and receive pilot signal strength for the requested 15

AT. 16

5.2.3.9 Measurement Report

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) AN Tx Pilot Power (LSB) 3

(MSB) AT Rx Pilot Strength (LSB) 4

(MSB) Measurement Start Timestamp 5

… …

(LSB) 12

(MSB) Measurement End Timestamp 13

… …

(LSB) 20


field. 18

AN Tx Pilot Power This field indicates the FAP‟s pilot power. If the FAP‟s pilot power is 19

within the range of -128 to 127 dBm, the FAP shall set this field to the 20

3GPP2 A.S0024-A v1.0

5-41

two‟s complement representation of its Pilot Channel Power (in dBm). 1

Otherwise, if the pilot power is below -128 or above 127 dBm, the FAP 2

shall set this field to the two‟s complement representation of -128 or 127, 3

respectively. 4

AT Rx Pilot Strength This field indicates the received power of the AT pilot channel measured 5

at the FAP RF input ports. If the received power is in the range of -127.5 6

to 0 dBm, the FAP shall set this field to the nearest integer value of -2 x 7

the received power (in dBm). E.g., if the received power is -20.25 dBm 8

this field is set to 41. Otherwise if the received power is below -127.5 or 9

above 0 dBm, the FAP shall set this field to 255 or 0, respectively. 10

Measurement Start Timestamp This field is a 64-bit binary number derived from the CDMA System 11

Time at the time that the AT Rx Pilot measurement in this IE is started. 12

The time stamp is in units of 80 ms. 13

Measurement End Timestamp This field is a 64-bit binary number derived from the CDMA System 14

Time at the time that the AT Rx Pilot measurement in this IE is finished. 15

The time stamp is in units of 80 ms. 16

5.2.3.10 Cause 17


5.2.3.10 Cause

7 6 5 4 3 2 1 0 Octet


Length 2

(MSB) Cause Value (LSB) 3


number. 20

Cause Value This field is set to the range of values as follows: 21

Hex Values Meaning

01 Success

02 Rejected

03 Overload

04 Unauthorized FAP

05 OM&P intervention

06 Transport resource unavailable

07 Power off

08 Unspecified

09-20 Reserved

21 Radio interface failure

22 Equipment failure

23 No radio resource available

24 AN not equipped

3GPP2 A.S0024-A v1.0

5-42

Hex Values Meaning

25 Protocol error between AN and FGW

26 Measurement successful

27 AT not detected

28 AT not allowed

29 AN busy

2A Terrestrial resources are not available

2B Measurement procedure time-out

2C-FF Reserved

5.3 Timer Definitions 1

5.3.1 Timer Descriptions 2

This section describes the timers associated with the Femtocell IOS. All A11 timers (i.e., Tregreq, Tregupd) 3

are defined in A.S0017 [6]. 4

Table 5.3.1-1 Timer Values and Ranges Sorted by Name 5

Timer

Name

Default

Value

(seconds)

Range of

Values

(seconds)

Granularity

(seconds)

Section

Reference

Classification

Tmr-1 5 0-10 0.1 5.3.1.1 Handoff

Tmr-26 5 0-10 0.1 5.3.1.2 A26 interface

Tregreq-26 5 0-10 0.1 5.3.1.3 A26 interface

5.3.1.1 Tmr-1 6

This FCS timer is started when one or more Measurement Request messages are sent, and stopped when 7

all the corresponding Measurement Response messages are received or an MS OOB Indication message is 8

received. 9

Note: All other A1 handoff and call processing timers are defined in A.S0014 [5]. 10

5.3.1.2 Tmr-26 11

This FGW timer is started when the A26-Measurement Request message is sent, and stopped when the 12

A25-Measurement Response message is received. 13

5.3.1.3 Tregreq-26 14

This is a FAP timer which is started when FAP sends the A26-FAP Registration Request message, and 15

stopped when the A26-FAP Registration Response message is received. This is also a FAP or FGW timer 16

which is started when the A26-FAP Deregistration message is sent, and stopped when the acknowledging 17

A26-FAP Deregistration message is received. 18

19