Interoperability Specification (IOS) for Femtocell Access ... v1.0 Femto IOS-Pub_201104.pdfJanuary...
Transcript of 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
3.2.1.1.2.1 Successful Operation ............................................................................................... 3-2 35
3.2.1.1.2.2 Failure Operation ..................................................................................................... 3-3 36
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.3.3 Failure Operation ..................................................................................................... 3-4 4
3.2.1.1.4 MS OOB Indication ................................................................................................. 3-4 5
3.2.1.1.4.1 Successful Operation ............................................................................................... 3-4 6
3.2.1.1.4.2 Failure Operation ..................................................................................................... 3-4 7
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.1.1 Successful Operation ............................................................................................... 3-8 27
3.3.7.2.1.2 Failure Operation ..................................................................................................... 3-8 28
3.3.7.2.2 A25-FAP Registration Response ............................................................................. 3-8 29
3.3.7.2.2.1 Successful Operation ............................................................................................... 3-9 30
3.3.7.2.2.2 Failure Operation ..................................................................................................... 3-9 31
3.3.7.2.3 A25-FAP Deregistration .......................................................................................... 3-9 32
3.3.7.2.3.1 Successful Operation ............................................................................................... 3-9 33
3.3.7.2.3.2 Failure Operation ..................................................................................................... 3-9 34
3.3.7.2.4 A25-Measurement Request ..................................................................................... 3-9 35
3.3.7.2.4.1 Successful Operation ............................................................................................... 3-9 36
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.5.2 Failure Operation ................................................................................................... 3-11 4
3.3.7.2.6 A25-MS OOB Indication ....................................................................................... 3-11 5
3.3.7.2.6.1 Successful Operation ............................................................................................. 3-11 6
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.1.1 Successful Operation ............................................................................................. 3-13 16
3.3.8.2.1.2 Failure Operation ................................................................................................... 3-13 17
3.3.8.2.2 A26-FAP Registration Response ........................................................................... 3-13 18
3.3.8.2.2.1 Successful Operation ............................................................................................. 3-13 19
3.3.8.2.2.2 Failure Operation ................................................................................................... 3-13 20
3.3.8.2.3 A26-FAP Deregistration ........................................................................................ 3-13 21
3.3.8.2.3.1 Successful Operation ............................................................................................. 3-14 22
3.3.8.2.3.2 Failure Operation ................................................................................................... 3-14 23
3.3.8.2.4 A26-Measurement Request ................................................................................... 3-14 24
3.3.8.2.4.1 Successful Operation ............................................................................................. 3-14 25
3.3.8.2.4.2 Failure Operation ................................................................................................... 3-14 26
3.3.8.2.5 A26-Measurement Response ................................................................................. 3-14 27
3.3.8.2.5.1 Successful Operation ............................................................................................. 3-15 28
3.3.8.2.5.2 Failure Operation ................................................................................................... 3-15 29
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.14 Measurement Response Options ............................................................................ 5-35 20
5.2.2.15 Mobile Identity ...................................................................................................... 5-35 21
5.2.2.16 Measurement Report .............................................................................................. 5-35 22
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
5.2.3.8 Measurement Response Options ............................................................................ 5-39 36
3GPP2 A.S0024-A v1.0
viii
5.2.3.9 Measurement Report .............................................................................................. 5-40 1
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
[4] 3GPP2: A.S0013-D v3.0, Interoperability Specification (IOS) for cdma2000 Access Network 14
Interfaces - Part 3 Features, September 2010. 15
[5] 3GPP2: A.S0014-D v3.0, Interoperability Specification (IOS) for cdma2000 Access Network 16
Interfaces – Part 4 (A1, A1p, A2, and A5 Interfaces), September 2010. 17
[6] 3GPP2: A.S0017-D v3.0, Interoperability Specification (IOS) for cdma2000 Access Network 18
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
The entities identified in Figure 1.4.2-1 and Figure 1.4.2-2 are defined as follows. 7
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
FAP The Femtocell Access Point (FAP) is a wireless access point operating in licensed 14
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
The interfaces identified in Figure 1.4.2-1 and Figure 1.4.2-2 are defined as follows. 10
1x For details on the air interface, refer to C.S0005 [8]. 11
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
Fm The Fm interface enables auto-configuration of the FAP by the FMS. Refer to X.R0063 31
[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
The entities identified in Figure 1.4.3-1 and Figure 1.4.3-2 are defined as follows. 9
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
FAP The Femtocell Access Point (FAP) is a wireless access point operating in licensed 18
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
FMS The Femtocell Management System (FMS) is a network entity residing in an operator's 1
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
The interfaces identified in Figure 1.4.3-1 and Figure 1.4.3-2 are defined as follows. 13
1x For details on the air interface, refer to C.S0005 [8]. 14
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
Fm The Fm interface enables auto-configuration of the FAP by the FMS. Refer to X.R0063 31
[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
FMS The Femtocell Management System (FMS) is a network entity residing in an operator's 20
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
3.2.1.1.2.1 Successful Operation 39
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
3.2.1.1.2.2 Failure Operation 17
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
3.2.1.1.3.3 Failure Operation 2
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
3.2.1.1.4.1 Successful Operation 7
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
3.2.1.1.4.2 Failure Operation 22
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 A13 Interface 15
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 A16 Interface 26
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
3.3.7 A25 Interface 11
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
3.3.7.2.1.1 Successful Operation 19
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
3.3.7.2.1.2 Failure Operation 25
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
3.3.7.2.2.1 Successful Operation 1
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
3.3.7.2.2.2 Failure Operation 7
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
3.3.7.2.3.1 Successful Operation 11
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
3.3.7.2.3.2 Failure Operation 17
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
3.3.7.2.4.1 Successful Operation 24
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
3.3.7.2.4.2 Failure Operation 9
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
The measurement is successful and the result is above the operator‟s configurable threshold. 17
The measurement is successful, the result is below the operator‟s configurable threshold and the Low 18
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
Note: The definition of the operator‟s configurable threshold is outside the scope of this specification. 23
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
3.3.7.2.5.1 Successful Operation 27
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
detected‟ Cause value. 36
If the FAP determines there is not sufficient time to make a satisfactory measurement before 37
expiration of the measurement response timer, the FAP shall set the Cause value to „Measurement 38
procedure time-out‟ and may include a measurement report. 39
If the FAP is not capable of providing signal strength measurements, the FAP shall respond with the 40
Cause value, „BS not equipped‟. 41
If the FAP is unable to provide measurements at this time due to other on-going procedures, the FAP 42
shall respond with the Cause value „BS busy‟. 43
3GPP2 A.S0024-A v1.0
3-11
For equipment and/or interface failure, resource availability or OAM&P intervention, the FAP shall 1
include the appropriate Cause value. 2
Refer to section 5.1.2.5, A25-Measurement Response, for the format and content of this message. 3
3.3.7.2.5.2 Failure Operation 4
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
3.3.7.2.6.1 Successful Operation 9
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
3.3.7.2.6.2 Failure Operation 24
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
3.3.8 A26 Interface 17
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
3.3.8.2.1.1 Successful Operation 13
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
3.3.8.2.1.2 Failure Operation 20
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
3.3.8.2.2.1 Successful Operation 28
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
3.3.8.2.2.2 Failure Operation 35
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
3.3.8.2.3.1 Successful Operation 1
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
3.3.8.2.3.2 Failure Operation 10
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
3.3.8.2.4.1 Successful Operation 19
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
3.3.8.2.4.2 Failure Operation 33
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
The measurement is successful and the result is above the operator‟s configurable threshold. 3
The measurement is successful, the result is below the operator‟s configurable threshold and the Low 4
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
Note: The definition of the operator‟s configurable threshold is outside the scope of this specification. 9
3.3.8.2.5.1 Successful Operation 10
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
detected‟ Cause value. 17
If the FAP determines there is not sufficient time to make a satisfactory measurement before 18
expiration of the measurement response timer, the FAP shall set the Cause value to „Measurement 19
procedure time-out‟ and may include a measurement report. 20
If the FAP is not capable of providing signal strength measurements, the FAP shall respond with the 21
Cause value, „AN not equipped‟. 22
If the FAP is unable to provide measurements at this time due to other on-going procedures, the FAP 23
shall respond with the Cause value „AN busy‟. 24
For equipment and/or interface failure, resource availability or OAM&P intervention, the FAP shall 25
include the appropriate Cause value. 26
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
3.3.8.2.5.2 Failure Operation 29
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
1. A25-FAP Deregistration
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
2. A26-FAP Deregistration
1. A26-FAP Deregistration
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
1. A26-FAP Deregistration
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
7. A11-Registration Reply
6. A11-Registration Request
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
1. Packet data session dormant, PPP session is maintained
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
17. A11-Registration Reply
Target
FCS
Target
FAP
Tregreq
Source
PDSN
Source
BS/
PCF
16. A11-Registration Request
15. A11-Registration Acknowledge
14. A11-Registration UpdateTregup
13. Packet data session active, new PPP session established
10. A11-Registration Request
11. A11-Registration ReplyTregreq
7. A11-Registration Reply
6. A11-Registration RequestTregreq
2. Origination Message
3. BS Ack Order
1. Packet data session dormant, PPP session is maintained
4. CM Service Request
5. Assignment 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
signaling. Refer to X.S0059-200 [17] for the messaging format between the FAP and the FCS. 15
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
This scenario describes the call flow when an MS with a 1x active voice call hands off from a macro BS 2
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
19. Clear CompleteT315
14. Handoff Completion Msg
T306
Target
FCS
Source
MSC
Source
Macro
BS
13. Reverse Traffic Channel Frames or Traffic Channel Preamble
5. FACDIR2
18. Clear Command
T7
12. Handoff Commenced
4. Handoff Required
17. MSONCH
7. Null forward traffic channel frames
8. facdir2
T8
Twaitho
10. HO Direction Msg
11. MS Ack Order
3. PSMM
Target
FAP2
6a. Handoff Request
x
9. Handoff Command
6b. HO Request Ack
16. Handoff Complete
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
1. The MS is in a voice call via the source macro BS and the source MSC. 9
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
4. Based on the PSMM, the source macro BS decides to perform a hard handoff. The source macro BS 14
sends a Handoff Required message to the source MSC and starts timer T7. The message contains the 15
Cell ID value that maps to PN offset of the FAP and the MSC_ID of the target FCS. 16
5. The source MSC sends a FACDIR2 message to the target FCS via core network messaging, directing 17
the target FCS to initiate the handoff. Refer to X.S0004 [12]. 18
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
7. Target FAP 1 sends null forward traffic channel frames to the MS. 3
8. The target FCS, having completed the Handoff Request procedure, sends a facdir2 message to the 4
source MSC via core network messaging. Refer to X.S0004 [12]. 5
9. The source MSC prepares to switch the MS from the source macro BS to target FAP 1 and sends a 6
Handoff Command message to the source macro BS. The source MSC includes in the Handoff 7
Command message the service configuration records contained in the handoff request ack message 8
and received in the facdir2 message. Refer to X.S0059-200 [17]. The source macro BS stops timer T7. 9
10. The source macro BS sends a handoff direction message6 to the MS and starts timer T8. If the MS is 10
allowed to return to the source macro BS, timer Twaitho is also started by the source macro BS. 11
11. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source 12
macro BS. The source macro BS stops timer T8 upon receipt of this message. 13
12. The source macro BS sends a Handoff Commenced message to the source MSC to notify it that the 14
MS has been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306. If 15
timer Twaitho has been started, the source BS waits for that timer to expire before sending the Handoff 16
Commenced message. 17
13. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell. 18
14. The MS sends a Handoff Completion Message to target FAP 1. 19
15. Target FAP 1 sends a BS Ack Order to the MS over the air interface. 20
16. Target FAP 1 sends a Handoff Complete message to the target FCS via Fx2 signaling to notify it that 21
the MS has successfully completed the hard handoff. 22
17. The target FCS sends the MSONCH message to the source MSC via core network messaging to 23
notify it that the MS has successfully completed the hard handoff. 24
18. The source MSC sends a Clear Command message to the source macro BS and starts timer T315. The 25
source macro BS stops timer T306. 26
19. The source macro BS sends a Clear Complete message to the source MSC to notify it that clearing 27
has been accomplished. The source MSC stops timer T315. 28
20. The MS is in a voice call via target FAP 1 and the target FCS. 29
6 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-12
4.2.3.4.3 1x Macro BS to FAP Active Handoff with Late OOB Link Detection 1
This scenario describes the call flow when an MS with a 1x active voice call hands off from a macro BS 2
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
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
21. Voice
1. Voice
16. BS Ack Order
20. Clear CompleteT315
15. Handoff Completion Msg
T306
Target
FCS
Source
MSC
Source
Macro
BS
14. Reverse Traffic Channel Frames or Traffic Channel Preamble
4. FACDIR2
19. Clear Command
T7
13. Handoff Commenced
3. Handoff Required
18. MSONCH
8. Null forward traffic channel frames9. facdir2
T8
Twaitho
11. HO Direction Msg
12. MS Ack Order
2. PSMM
Target
FAP2
5a. Measure. Request
7a. Handoff Request
x
10. Handoff Command
7b. HO Request Ack
17. Handoff Complete
5b. Measure. Request
6. MS OOB Indication
7
Figure 4.2.3.4.3-1 1x Macro BS to FAP Active Handoff with Late OOB Link Detection 8
1. The MS is in a voice call via the source macro BS and the source MSC. 9
2. The MS sends a PSMM, refer to C.S0005 [8], to the source macro BS that includes the PN offset of 10
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‟). 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
8. Target FAP 1 sends null forward traffic channel frames to the MS. 11
9. The target FCS, having completed the Handoff Request procedure, sends a facdir2 message to the 12
source MSC via core network messaging. Refer to X.S0004 [12]. 13
10. The source MSC prepares to switch the MS from the source macro BS to target FAP 1 and sends a 14
Handoff Command message to the source macro BS. The source MSC includes in the Handoff 15
Command message the service configuration records contained in the handoff request ack message 16
and received in the facdir2 message. Refer to X.S0059-200 [17]. The source macro BS stops timer T7. 17
11. The source macro BS sends a handoff direction message7 to the MS and starts timer T8. If the MS is 18
allowed to return to the source macro BS, timer Twaitho is also started by the source macro BS. 19
12. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source 20
macro BS. The source macro BS stops timer T8 upon receipt of this message. 21
13. The source macro BS sends a Handoff Commenced message to the source MSC to notify it that the 22
MS has been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306. If 23
timer Twaitho has been started, the source BS waits for that timer to expire before sending the Handoff 24
Commenced message. 25
14. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell. 26
15. The MS sends a Handoff Completion Message to target FAP 1. 27
16. Target FAP 1 sends a BS Ack Order to the MS over the air interface. 28
17. Target FAP 1 sends a Handoff Complete message to the target FCS via Fx2 signaling to notify it that 29
the MS has successfully completed the hard handoff. 30
18. The target FCS sends the MSONCH message to the source MSC via core network messaging to 31
notify it that the MS has successfully completed the hard handoff. 32
19. The source MSC sends a Clear Command message to the source macro BS and starts timer T315. The 33
source macro BS stops timer T306. 34
20. The source macro BS sends a Clear Complete message to the source MSC to notify it that clearing 35
has been accomplished. The source MSC stops timer T315. 36
21. The MS is in a voice call via target FAP 1 and the target FCS. 37
7 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-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
1. MS OOB Indication
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
handoff via the MSC using the A1/A2 or A1p/A2p interfaces (refer to A.S0013 [4], Section 3.19.3.1). 11
MSTarget
BS
20. Voice
1. Voice
15. BS Ack Order
14. Handoff Completion Msg
Target
MSC
Source
FCS
Source
FAP
16. HO Complete
13. Reverse Traffic Channel Frames or Traffic Channel Preamble
5. HO Request
4. FACDIR2
T11
T9
7. HO Request Ack
17. MSONCH
6. Null forward traffic channel frames
8. facdir2
T8
Twaitho
10. HO Direction Msg
11. MS Ack Order
2. PSMM
x
3. Handoff Required
9. Handoff Command
12. Handoff Commenced
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
signaling. Refer to X.S0059-200 [17] for the messaging format between the FAP and the FCS. 18
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
11. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source 18
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
notify it that the MS has successfully completed the hard handoff. 29
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
8 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-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
1. Origination Message
5. Assignment Request
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
6. Assignment 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
This scenario describes the call flow when an MS with a 1x active voice call hands off from a macro BS 12
to a FAP. From the perspective of the source macro BS, these procedures are similar to those for a hard 13
handoff via the MSC using the A1/A2 or A1p/A2p interfaces (refer to A.S0013 [4], Section 3.19.3.1). 14
T315
MS FAP1
20. Voice
1. Voice
15. BS Ack Order
19. Clear Complete
14. Handoff Completion Msg
T306
FGWMSC
Source
Macro
BS
13. Reverse Traffic Channel Frames or Traffic Channel Preamble
4. Handoff Request
18. Clear Command
T7
12. Handoff Commenced
3. Handoff Required
7. Null forward traffic channel frames
8. Handoff Request Ack
T8
Twaitho
10. HO Direction Msg
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
16. Handoff Complete
17. Handoff Complete
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
2. The MS sends a PSMM, refer to C.S0005 [8], to the source macro BS that includes the PN offset of 18
the FAP as the strongest neighboring cell. 19
3GPP2 A.S0024-A v1.0
4-21
3. Based on the PSMM, the source macro BS decides to perform a hard handoff. The source macro BS 1
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
source macro BS stops timer T7. 22
10. The source macro BS sends a handoff direction message9 to the MS and starts timer T8. If the MS is 23
allowed to return to the source macro BS, timer Twaitho is also started by the source macro BS. 24
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
Commenced message. 31
13. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell. 32
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
successfully completed the hard handoff. 36
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
9 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-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
iating handoff procedures for the MS. From the perspective of the source macro BS, these procedures are 8
similar to those for a hard handoff via the MSC using the A1/A2 or A1p/A2p interfaces (refer to A.S0013 9
[4], Section 3.19.3.1). 10
T315
MS FAP1
20. Voice
1. Voice
15. BS Ack Order
19. Clear Complete
14. Handoff Completion Msg
T306
FGWMSC
Source
Macro
BS
13. Reverse Traffic Channel Frames or Traffic Channel Preamble
5. Handoff Request
18. Clear Command
T7
12. Handoff Commenced
4. Handoff Required
7. Null forward traffic channel frames
8. Handoff Request Ack
T8
Twaitho
10. HO Direction Msg
11. MS Ack Order
3. PSMM
FAP2
x
9. Handoff Command
6a. Handoff Request
6b. Handoff Request Ack
16. Handoff Complete
17. Handoff Complete
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
1. The MS is in a voice call via the source macro BS and the MSC. 13
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
3. The MS sends a PSMM, refer to C.S0005 [8], to the source macro BS that includes the PN offset of 16
the FAP as the strongest neighboring cell. 17
4. Based on the PSMM, the source macro BS decides to perform a hard handoff. The source macro BS 18
sends a Handoff Required message to the MSC and starts timer T7. The message contains the Cell ID 19
value, which may be derived using the PN offset received from step „2‟. 20
5. The MSC sends a Handoff Request message to the FGW based on the Cell ID. 21
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
7. The target FAP sends null forward traffic channel frames to the MS. 5
8. The FGW, having completed the Handoff Request procedure, sends a Handoff Request Acknowledge 6
message to the MSC. 7
9. The MSC prepares to switch the MS from the source macro BS to the target FAP and sends a Handoff 8
Command message to the source macro BS. The MSC includes in the Handoff Command message 9
the service configuration records contained in the Handoff Request Acknowledge message. The 10
source macro BS stops timer T7. 11
10. The source macro BS sends a handoff direction message10 to the MS and starts timer T8. If the MS is 12
allowed to return to the source macro BS, timer Twaitho is also started by the source macro BS. 13
11. The MS may acknowledge the handoff direction message by sending a Mobile Station 14
Acknowledgment Order to the source macro BS. The source macro BS stops timer T8 upon receipt of 15
this message. 16
12. The source macro BS sends a Handoff Commenced message to the MSC to notify it that the MS has 17
been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306. If timer 18
Twaitho has been started, the source BS waits for that timer to expire before sending the Handoff 19
Commenced message. 20
13. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell. 21
14. The MS sends a Handoff Completion Message to the target FAP. 22
15. The target FAP sends a Base Station Acknowledgment Order to the MS over the air interface. 23
16. The target FAP sends a Handoff Complete message to the FGW to notify it that the MS has 24
successfully completed the hard handoff. 25
17. The FGW sends the Handoff Complete message to the MSC. 26
18. The MSC sends a Clear Command message to the source macro BS and starts timer T315. The source 27
macro BS starts timer T306. 28
19. The source macro BS sends a Clear Complete message to the MSC to notify it that clearing has been 29
accomplished. The MSC stops timer T315. 30
20. The MS is in a voice call via the target FAP and the FGW. 31
10 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-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
15. Handoff Completion Msg
T306
FGWMSC
Source
Macro
BS
14. Reverse Traffic Channel Frames or Traffic Channel Preamble
4. Handoff Request
19. Clear Command
T7
13. Handoff Commenced
3. Handoff Required
8. Null forward traffic channel frames
9. Handoff Request Ack
T8
Twaitho
11. HO Direction Msg
12. MS Ack Order
2. PSMM
FAP2
5a. A25-Measurement Request
x
10. Handoff Command
7a. Handoff Request
7b. Handoff Request Ack
17. Handoff Complete
18. Handoff Complete
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
1. The MS is in a voice call via the source macro BS and the MSC. 9
2. The MS sends a PSMM, refer to C.S0005 [8], to the source macro BS that includes the PN offset of 10
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 MSC and starts timer T7. The message contains the Cell ID 13
value, which may be derived using the PN offset received from step „2‟. 14
4. The MSC sends a Handoff Request message to the FGW based on the Cell ID. 15
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
8. The target FAP sends null forward traffic channel frames to the MS. 10
9. The FGW, having completed the Handoff Request procedure, sends a Handoff Request Acknowledge 11
message to the MSC. 12
10. The MSC prepares to switch the MS from the source macro BS to the target FAP and sends a Handoff 13
Command message to the source macro BS. The MSC includes in the Handoff Command message 14
the service configuration records contained in the Handoff Request Acknowledge message. The 15
source macro BS stops timer T7. 16
11. The source macro BS sends a handoff direction message11 to the MS and starts timer T8. If the MS is 17
allowed to return to the source macro BS, timer Twaitho is also started by the source macro BS. 18
12. The MS may acknowledge the handoff direction message by sending a Mobile Station 19
Acknowledgment Order to the source macro BS. The source macro BS stops timer T8 upon receipt of 20
this message. 21
13. The source macro BS sends a Handoff Commenced message to the MSC to notify it that the MS has 22
been ordered to move to the target FAP 1 channel. The source macro BS starts timer T306.If timer 23
Twaitho has been started, the source BS waits for that timer to expire before sending the Handoff 24
Commenced message. 25
14. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell. 26
15. The MS sends a Handoff Completion Message to the target FAP. 27
16. The target FAP sends a Base Station Acknowledgment Order to the MS over the air interface. 28
17. The target FAP sends a Handoff Complete message to the FGW to notify it that the MS has 29
successfully completed the hard handoff. 30
18. The FGW sends the Handoff Complete message to the MSC. 31
19. The MSC sends a Clear Command message to the source macro BS and starts timer T315. The source 32
macro BS starts timer T306. 33
20. The source macro BS sends a Clear Complete message to the MSC to notify it that clearing has been 34
accomplished. The MSC stops timer T315. 35
21. The MS is in a voice call via the target FAP and the FGW. 36
37
11 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-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
9. Bearer Update Request
10. Bearer Update Response
11. Bearer Update Response
12. Handoff Command
14. MS Ack
Order15. Handoff Commenced
17. Handoff Completion
18. Handoff Complete
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
Acknowledge message. 16
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
14. The MS may acknowledge the handoff direction message by sending a Mobile Station 10
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
16. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell(s). 14
17. The MS sends a Handoff Completion Message to the target FAP. 15
18. The target FAP sends a Handoff Complete message to the FGW to notify it that the MS has 16
successfully completed the hard handoff. 17
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
12 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-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
7. Bearer Update Request
8. Bearer Update Response
9. Handoff Command
11. MS Ack
Order12. Handoff Commenced
14. Handoff Completion
15. Handoff Complete
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
1. The MS is in a voice call via the source macro BS and the source MSC. 7
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
Acknowledge message. 19
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
11. The MS may acknowledge the handoff direction message by sending a Mobile Station 4
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
13. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell(s). 8
14. The MS sends a Handoff Completion Message to the target FAP. 9
15. The target FAP sends a Handoff Complete message to the FGW to notify it that the MS has 10
successfully completed the hard handoff. 11
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
13 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-31
TA13req
Tregreq
Tregreq
Tregupd
Target
AN/PCFPDSNAT
10. A11-Registration Update
11. A11-Registration Ack
12. A11-Registration Request
(Lifetime=0)
13. A11-Registration Reply
(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
23. A11-Registration Reply
22. A11-Registration Request (Lifetime = 0)
21. A11-Registration Acknowledge
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
Length = <variable> 2
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
5.1.1.1 Measurement Request
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
(MSB) Cell = [001H-FFFH] j+3
Sector = [0H-FH] (0H =
Omni)
(LSB) j+4
} Cell Identification
Downlink Radio Environment: A1 Element Identifier = [29H] 1
Length = <variable> 2
Number of Cells = <variable> 3
Cell Identification Discriminator = [02H,07H] 4
Downlink Radio Environment entry {1+:
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
j+1
(LSB) j+2
(MSB) Cell = [001H-FFFH] j+3
Sector = [0H-FH] (0H =
Omni)
(LSB) j+4
} Cell Identification
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
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-4
5.1.1.1 Measurement Request
7 6 5 4 3 2 1 0 Octet
j+1
(LSB) j+2
(MSB) Cell = [001H-FFFH] j+3
(LSB) Sector = [0H-FH] (0H = Omni) j+4
} Cell Identification
(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
Length = <variable> 2
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
5.1.1.1 Measurement Request
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
Information Element Section
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
BSMAP Header: Message Discrimination = [00H] 1
Length Indicator (LI) = <variable> 2
Message Type = [72H] 1
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
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.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
Information Element Section
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
BSMAP Header: Message Discrimination = [00H] 1
Length Indicator (LI) = <variable> 2
Message Type = [73H] 1
Global RAND Key: A1 Element Identifier = [53H] 1
Length = <variable> 2
(MSB) Global RAND Key Value = <any value> 3
… …
(LSB) n
Called Party BCD Number: A1 Element Identifier = [5EH] 1
Length = <variable> 2
= [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
Length = <variable> 2
Cell Identification Discriminator = [07H] 3
} Cell Identification {1+:
(MSB) MSCID = <any value> j
j+1
(LSB) j+2
(MSB) Cell = [001H-FFFH] j+3
Sector = [0H-FH] (0H =
Omni)
(LSB) j+4
} Cell Identification
Pilot List: A1 Element Identifier = [54H] 1
Length = <variable> 2
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
Length = <variable> 2
(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
Information Element Section
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
BSMAP Header: Message Discrimination = [00H] 1
Length Indicator (LI) = <variable> 2
Message Type = [74H] 1
Mobile Identity (MN ID): A1 Element Identifier [0DH] 1
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 =
[001 (MEID – Hex Digits),
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
MEID Hex Digit 5 = [0H-FH] MEID Hex Digit 4 = [0H-FH] 5
MEID Hex Digit 7 = [0H-FH] MEID Hex Digit 6 = [0H-FH] 6
MEID Hex Digit 9 = [0H-FH] MEID Hex Digit 8 = [0H-FH] 7
MEID Hex Digit 11 = [0H-FH] MEID Hex Digit 10 = [0H-FH] 8
MEID Hex Digit 13 = [0H-FH] MEID Hex Digit 12 = [0H-FH] 9
Fill = [FH] MEID Hex Digit 14 = [0H-FH] 10
IF (Type of Identity = 110), Identity {1:
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
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
Message Type = [01H] 1
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
Length = [variable] 2
(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
Length = <variable> 2
3GPP2 A.S0024-A v1.0
5-12
5.1.2.1 A25-FAP Registration Request
7 6 5 4 3 2 1 0 Octet
Cell Identification Discriminator = [07H] 3
} Cell Identification {1+:
(MSB) MSCID = <any value> j
j+1
(LSB) j+2
(MSB) Cell = [001H-FFFH] j+3
Sector = [0H-FH] (0H = Omni) (LSB) j+4
} Cell Identification
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
Information Element Section Reference Element Direction Type
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
Message Type = [02H] 1
FAP Identifier: A25 Element Identifier = [74H] 1
Length = [variable] 2
(MSB) FAP-ID = <any value> 3
… …
(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
Information Element Section Reference Element Direction Type
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
Message Type = [03H] 1
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
Information Element Section
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
Message Type = [04H] 1
Global RAND Key: A25 Element Identifier = [53H] 1
Length = <variable> 2
(MSB) Global RAND Key Value = <any value> 3
… …
(LSB) n
Mobile Identity (MN ID): A25 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
= [110] (IMSI)
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+3 = [0H-9H] (BCD) (if
odd number of digits)
Identity Digit N+2 = [0H-9H] (BCD) n+1
Nonce: A25 Element Identifier = [55H] 1
Length = <variable> 2
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
Information Element Section Reference Element Direction Type
Message Type 5.2.3.3 FAP FGW M
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
5.1.3.1 A26-FAP Registration Request
7 6 5 4 3 2 1 0 Octet
Message Type = [01H] 1
FAP Identifier: A26 Element Identifier = [01H] 1
Length = [variable] 2
(MSB) FAP-ID = <any value> 3
… …
(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
5.1.3.1 A26-FAP Registration Request
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
Information Element Section Reference Element Direction Type
Message Type 5.2.3.3 FGW FAP M
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
Message Type = [02H] 1
FAP Identifier: A26 Element Identifier = [01H] 1
Length = [variable] 2
(MSB) FAP-ID = <any value> 3
… …
(LSB) n
Cause: A26 Element Identifier = [03H] 1
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
Information Element Section Reference Element Direction Type
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
Message Type = [03H] 1
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.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
Information Element Section Reference Element Direction Type
Message Type 5.2.3.3 FGW FAP M
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
5.1.3.4 A26-Measurement Request
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
FAP Identifier: A26 Element Identifier = [01H] 1
Length = [variable] 2
(MSB) FAP-ID = <any value> 3
… …
(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
5.1.3.4 A26-Measurement Request
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
Information Element Section
Reference
Element
Direction
Type
Message Type 5.2.3.3 FAP FGW M
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
FAP Identifier: A26 Element Identifier = [01H] 1
Length = [variable] 2
(MSB) FAP-ID = <any value> 3
… …
(LSB) n
Cause: A26 Element Identifier = [03H] 1
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
A1 Element Identifier 1
Length 2
0/1 Cause value 3
Length This field is defined as the number of octets following the Length field. 18
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
5.2.1.5 Measurement Response Options
7 6 5 4 3 2 1 0 Octet
A1 Element Identifier 1
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
A1 Element Identifier 1
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
Length This field indicates the number of octets in this IE following the Length 17
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
stamp is in units of 80 ms. 19
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
A1 Element Identifier 1
Length 2
(MSB) Global RAND Key Value 3
… …
(LSB) n
Length This field indicates the number of octets in this IE following the Length 24
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
A1 Element Identifier 1
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
Length This field indicates the number of octets in this IE following the Length 1
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
A1 Element Identifier 1
Length 2
(MSB) Nonce Value 3
… …
(LSB) n
Length This field indicates the number of octets in this IE following the Length 14
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
A1 Element Identifier 1
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
MEID Hex Digit 5 MEID Hex Digit 4 5
MEID Hex Digit 7 MEID Hex Digit 6 6
MEID Hex Digit 9 MEID Hex Digit 8 7
MEID Hex Digit 11 MEID Hex Digit 10 8
MEID Hex Digit 13 MEID Hex Digit 12 9
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
5.2.1.10 Mobile Identity - 2
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
5.2.1.10 Mobile Identity - 2
7 6 5 4 3 2 1 0 Octet
(MSB) ESN 4
5
6
(LSB) 7
Odd/Even Indicator (octet 3; bit 3): This field is set to „0‟. 1
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
5.2.1.10 Mobile Identity - 3
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
5.2.1.10 Mobile Identity - 4
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
Odd/Even Indicator (octet 3; bit 3): This field is set to „0‟. 17
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
A1 Element Identifier 1
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
stamp is in units of 80 ms. 22
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
Element Name IEI (Hex) Reference
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
Measurement Response Options 51H 5.2.2.14
Measurement Report 52H 5.2.2.16
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
A25-Measurement Request 5.1.2.4
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
A25-FAP Registration Response 5.1.2.2
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
A25-Measurement Response 5.1.2.5
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
A25-Measurement Response 5.1.2.5
MS Measured Channel
Identity
5.2.2.11 64H A25-Measurement Request 5.1.2.4
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
A25-FAP Deregistration 5.1.2.3
1
5.2.2.3 A25 Message Type 2
The A25 Message Type IE is used to indicate the type of message on the A25 interface. 3
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 Message Name A25 Message Type Section Reference
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
A25 Element Identifier = [02H] 1
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
This IE is used to indicate the reason for occurrence of a particular event and is coded as follows. 29
5.2.2.6 Reg/Dereg Cause
7 6 5 4 3 2 1 0 Octet
A25 Element Identifier = [03H] 1
Length 2
(MSB) Cause Value (LSB) 3
Length This field contains the number of octets in this IE following this field as a binary 30
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
5.2.2.14 Measurement Response Options 15
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
5.2.2.16 Measurement Report 19
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
Element Name IEI (Hex) Reference
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
Measurement Response Options 06H 5.2.3.8
Measurement Report 07H 5.2.3.9
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
Information Element Ref. IEI Used in These Messages Ref.
A26 Message Type 5.2.3.3 none A26-FAP Registration Request 5.1.3.1
A26-FAP Registration Response 5.1.3.2
A26-FAP Deregistration 5.1.3.3
A26-Measurement Request 5.1.3.4
A26-Measurement Response 5.1.3.5
FAP Identifier 5.2.3.4 01H A26-FAP Registration Request 5.1.3.1
A26-FAP Registration Response 5.1.3.2
A26-Measurement Request 5.1.3.4
A26-Measurement Response 5.1.3.5
Sector Info 5.2.3.5 02H A26-FAP Registration Request 5.1.3.1
A26-Measurement Request 5.1.3.4
Cause 5.2.3.10 03H A26-FAP Registration Response 5.1.3.2
A26-FAP Deregistration 5.1.3.3
A26-Measurement Response 5.1.3.5
3GPP2 A.S0024-A v1.0
5-37
Table 5.2.3.2-1 Cross Reference of IEs with Messages
Information Element Ref. IEI Used in These Messages Ref.
AT-ID 5.2.3.6 04H A26-Measurement Request 5.1.3.4
A26-Measurement Response 5.1.3.5
Long Code Mask 5.2.3.7 05H A26-Measurement Request 5.1.3.4
Measurement Response
Options
5.2.3.8 06H A26-Measurement Request 5.1.3.4
Measurement Report 5.2.3.9 07H A26-Measurement Response 5.1.3.5
5.2.3.3 A26 Message Type 1
The A26 Message Type IE is used to indicate the type of message on the A26 interface. 2
A26 Message Name A25 Message Type Section Reference
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
A26 Element Identifier = [01H] 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 5
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
A26 Element Identifier = [02H] 1
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
Length This field contains the number of octets in this IE following this field as a binary 1
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
A26 Element Identifier = [04H] 1
Length 2
Reserved ATI Type 3
AT identifier variable
Length This field contains the number of octets in this IE following this field as a binary 8
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
A26 Element Identifier = [05H] 1
Length 2
Reserved (MSB) 3
LCM_MI 4
5
6
7
(LSB) 8
Reserved (MSB) 9
LCM_MQ 10
11
12
13
(LSB) 14
Length This field is defined as the number of octets following the Length field. 5
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
5.2.3.8 Measurement Response Options 10
This IE is used to provide options related to the Measurement Response message. 11
5.2.3.8 Measurement Response Options
7 6 5 4 3 2 1 0 Octet
A26 Element Identifier = [06H] 1
3GPP2 A.S0024-A v1.0
5-40
5.2.3.8 Measurement Response Options
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 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
5.2.3.9 Measurement Report 14
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
A26 Element Identifier = [07H] 1
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
Length This field indicates the number of octets in this IE following the Length 17
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
This IE is used to indicate the reason for occurrence of a particular event and is coded as follows. 18
5.2.3.10 Cause
7 6 5 4 3 2 1 0 Octet
A26 Element Identifier = [03H] 1
Length 2
(MSB) Cause Value (LSB) 3
Length This field contains the number of octets in this IE following this field as a binary 19
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