Embed Size (px)
Citation preview
3GPP2 A.S0013-0 v2.0
1
3GPP2 A.S0013-0
Version 2.0
Date: May 2002
2
3
4
5
6
7
8
9
10
Interoperability Specification (IOS) for cdma2000 11
Access Network Interfaces — Part 3 Features 12
13
(3G-IOSv4.2) 14
15
(Post SDO Ballot, Pre SDO Publication Version) 16
17
18
19
20
21
COPYRIGHT 22
3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may 23
copyright and issue documents or standards publications in individual Organizational Partner's name based on this 24
document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at 25
[email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that 26
Organizational Partner. See www.3gpp2.org for more information. 27
28
29
30
31
3GPP2 A.S0013-0 v2.0
i
Table of Contents 1
2
3
1.0 Introduction .................................................................................................................................. 1 4
1.1 Overview .................................................................................................................................. 1 5
1.1.1 Purpose ............................................................................................................................. 5 6
1.1.2 Scope ................................................................................................................................ 5 7
1.2 References ................................................................................................................................ 5 8
1.2.1 TIA / EIA.......................................................................................................................... 5 9
1.2.2 3GPP2............................................................................................................................... 6 10
1.2.3 International Telecommunications Union - Telecommunications Sector (ITU-T) ................ 7 11
1.2.4 Other ................................................................................................................................. 7 12
1.3 Terminology ............................................................................................................................. 7 13
1.3.1 Acronyms.......................................................................................................................... 7 14
1.3.2 Definitions....................................................................................................................... 10 15
1.4 Call Processing and Supplementary Services Assumptions....................................................... 10 16
1.4.1 Call Control..................................................................................................................... 10 17
1.4.1.1 A2/A5 Terrestrial Circuit Allocation ............................................................................ 10 18
1.4.1.2 Radio Channel Allocation ............................................................................................ 10 19
1.4.1.3 Traffic Channel Release ............................................................................................... 11 20
1.4.1.4 A3 User Traffic Subchannel Allocation ........................................................................ 11 21
1.5 Radio Resource Management Assumptions.............................................................................. 11 22
1.5.1 Radio Channel Supervision .............................................................................................. 11 23
1.5.1.1 Traffic Channel Radio Link Supervision....................................................................... 11 24
1.5.1.2 Idle Channel Observation............................................................................................. 11 25
1.5.2 Radio Channel Management ............................................................................................ 11 26
1.5.2.1 Radio Channel Configuration Management .................................................................. 11 27
1.5.2.2 Radio Traffic Channel Management ............................................................................. 11 28
1.5.2.2.1 Radio Channel Allocation...................................................................................... 11 29
1.5.2.2.2 Radio Traffic Channel Release .............................................................................. 11 30
1.5.2.2.3 Radio Traffic Channel Power Control .................................................................... 11 31
1.5.2.2.4 Channel Encoding and Decoding ........................................................................... 12 32
2.0 Feature Descriptions ................................................................................................................... 13 33
2.1 Call Setup of Voice and Circuit Data Calls .............................................................................. 13 34
2.2 Call Clearing of Voice and Circuit Data Calls.......................................................................... 13 35
2.2.1 Call Clearing Initiated by the MS or BS ........................................................................... 13 36
2.2.2 Call Clearing Initiated by the MSC................................................................................... 14 37
2.3 TFO Support ........................................................................................................................... 14 38
2.4 Test Calls................................................................................................................................ 15 39
2.5 Support of DTMF.................................................................................................................... 15 40
2.6 Support of Supplementary Services ......................................................................................... 16 41
2.6.1 Feature Activation and Deactivation................................................................................. 16 42
2.6.2 Call Waiting .................................................................................................................... 16 43
2.6.3 Three Way Calling........................................................................................................... 17 44
2.6.4 Message Waiting Notification .......................................................................................... 17 45
2.6.5 Call Barring..................................................................................................................... 18 46
2.6.6 Calling Number ID Presentation / Restriction................................................................... 18 47
2.6.6.1 CNIR for Mobile Originated Calls................................................................................ 18 48
2.6.6.2 CNIP/CNIR for Mobile Terminated Calls..................................................................... 18 49
2.6.7 Distinctive Ringing.......................................................................................................... 19 50
2.6.8 Answer Holding .............................................................................................................. 19 51
2.6.9 User Selective Call Forwarding........................................................................................ 19 52
2.7 Mobile Registration (Mobile Originated) ................................................................................. 20 53
2.8 Global Emergency Call Origination......................................................................................... 20 54
2.9 E911 Phase I and Phase 2 ........................................................................................................ 20 55
3GPP2 A.S0013-0 v2.0
ii
2.10 Short Message Service ............................................................................................................ 21 1
2.11 Priority Access and Channel Assignment (PACA) ................................................................... 21 2
2.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration 3
(OTAPA)................................................................................................................................ 22 4
2.12.1 OTASP Support............................................................................................................... 22 5
2.12.2 OTAPA Support .............................................................................................................. 23 6
2.13 Mobile Position Determination ................................................................................................ 23 7
2.13.1 Support of Position Location Service (MS – PDE Approach)............................................ 23 8
2.13.2 Software Calculation Position Determination (BS-MSC Approach) .................................. 23 9
2.14 User Zone ............................................................................................................................... 24 10
2.15 ISDN Interworking.................................................................................................................. 24 11
2.16 Circuit Data Calls.................................................................................................................... 24 12
2.17 3G Packet Data Calls............................................................................................................... 25 13
2.17.1 Packet Data Assumptions................................................................................................. 26 14
2.17.2 Previous and Current Access Network Identifiers (PANID/CANID) ................................. 27 15
2.17.3 PDSN Selection Algorithm .............................................................................................. 27 16
2.17.4 Packet Data Security Considerations ................................................................................ 27 17
2.17.5 Version Interoperability Control....................................................................................... 28 18
2.17.6 Short Data Bursts............................................................................................................. 28 19
2.17.7 Common Channel Packet Data (CCPD) ........................................................................... 28 20
2.18 Voice and Packet Data Concurrent Services............................................................................. 29 21
2.19 Handoff .................................................................................................................................. 30 22
2.19.1 Handoff via MSC ............................................................................................................ 30 23
2.19.2 Handoff via Direct BS-to-BS Signaling............................................................................ 30 24
2.19.3 Fast Handoff.................................................................................................................... 30 25
2.19.4 Hard Handoff into Soft Handoff....................................................................................... 33 26
2.19.5 Intergeneration Packet Data Handoff................................................................................ 33 27
2.20 Security Features..................................................................................................................... 33 28
2.20.1 Terminal Authentication .................................................................................................. 34 29
2.20.2 Signaling Message Encryption ......................................................................................... 34 30
2.20.3 Voice/Data Privacy.......................................................................................................... 35 31
2.21 Flex Rate ................................................................................................................................ 35 32
2.22 Status Inquiry.......................................................................................................................... 36 33
2.23 3X Multi-Carrier Operation ..................................................................................................... 36 34
2.24 5 ms Messaging ...................................................................................................................... 36 35
2.25 Enhanced Rate Adaptation Mode (ERAM) .............................................................................. 36 36
2.26 Code Combining Soft Handoff (CCSH) ................................................................................... 36 37
2.27 Rescue Channel....................................................................................................................... 37 38
2.28 Terrestrial Circuit Management ............................................................................................... 37 39
2.28.1 Terrestrial Circuit Management for the A2/A5 Interface ................................................... 37 40
2.28.2 Terrestrial Circuit Management for the A3 Interface......................................................... 38 41
2.29 Vocoder Support ..................................................................................................................... 38 42
2.30 Features Supported Transparently in this Standard ................................................................... 38 43
2.30.1 Emergency Service (Basic) via Specific Dialed Number................................................... 38 44
2.30.2 Carrier Access ................................................................................................................. 39 45
2.30.3 Call Forwarding............................................................................................................... 39 46
2.30.3.1 Call Forwarding Unconditional (CFU) ......................................................................... 39 47
2.30.3.2 Call Forwarding When Busy (CFB).............................................................................. 39 48
2.30.3.3 Call Forwarding - No Answer ...................................................................................... 39 49
2.30.3.4 Call Forward Default ................................................................................................... 40 50
2.30.4 Call Delivery ................................................................................................................... 40 51
2.30.5 Advice of Charge (AOC) ................................................................................................. 40 52
2.30.6 Call Transfer.................................................................................................................... 40 53
2.30.7 Lawfully Authorized Wiretap........................................................................................... 41 54
3.0 Feature Call Flows ...................................................................................................................... 43 55
3.1 Call Setup of Voice and Circuit Data Calls .............................................................................. 43 56
3GPP2 A.S0013-0 v2.0
iii
3.1.1 Mobile Origination Examples .......................................................................................... 43 1
3.1.1.1 Mobile Origination ...................................................................................................... 43 2
3.1.1.2 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 3
Assignment into Soft/Softer Handoff............................................................................ 45 4
3.1.2 Mobile Termination Examples ......................................................................................... 51 5
3.1.2.1 Mobile Termination ..................................................................................................... 51 6
3.1.2.2 Mobile Termination, Assignment Retry........................................................................ 53 7
3.2 Call Clearing of Voice and Circuit Data Calls.......................................................................... 55 8
3.2.1 Call Clearing Initiated by the MS or BS ........................................................................... 55 9
3.2.2 Call Clearing Initiated by the MSC................................................................................... 56 10
3.2.2.1 Scenario 1 - Clear from the Network ............................................................................ 56 11
3.2.2.2 Call clearing via Clear Command................................................................................. 56 12
3.2.2.3 Call Clearing when Tones/Announcements are Provided .............................................. 56 13
3.2.3 Call Clearing Collision..................................................................................................... 56 14
3.2.4 Call Flow Diagrams for Call Clear Operation ................................................................... 57 15
3.2.4.1 Call Clear via Clear Request (MS Initiated) ........................................................... 57 16
3.2.4.2 Call Clear via Clear Request (BS Initiated) ............................................................ 58 17
3.2.4.3 Call Clear via Clear Command .............................................................................. 59 18
3.3 TFO Support ........................................................................................................................... 59 19
3.3.1 Scenario Diagram ............................................................................................................ 59 20
3.4 Test Calls................................................................................................................................ 60 21
3.5 Support of DTMF.................................................................................................................... 60 22
3.6 Support of Supplementary Services ......................................................................................... 60 23
3.6.1 Feature Activation and Deactivation................................................................................. 61 24
3.6.1.1 Feature Activation/Deactivation in Idle Mode............................................................... 61 25
3.6.1.2 Feature Activation/Deactivation While in a Call ........................................................... 61 26
3.6.2 Call Waiting .................................................................................................................... 61 27
3.6.3 Three Way Calling........................................................................................................... 62 28
3.6.3.1 Three-Way Calling – (Method 1).................................................................................. 62 29
3.6.3.2 Three-Way Calling - (Method 2) .................................................................................. 63 30
3.6.4 Message Waiting Notification .......................................................................................... 64 31
3.6.4.1 Message Waiting Notification on the Paging Channel................................................... 64 32
3.6.4.2 Message Waiting Notification on the Traffic Channel................................................... 65 33
3.6.5 Call Barring..................................................................................................................... 66 34
3.6.5.1 Call Barring Incoming.................................................................................................. 66 35
3.6.5.2 Call Barring Outgoing.................................................................................................. 66 36
3.6.6 Calling Number ID Presentation/Restriction..................................................................... 67 37
3.6.7 Distinctive Ringing.......................................................................................................... 68 38
3.6.8 Answer Holding .............................................................................................................. 68 39
3.6.9 User Selective Call Forwarding........................................................................................ 68 40
3.7 Mobile Registration (Mobile Originated) ................................................................................. 68 41
3.7.1 Location Registration - Successful Case........................................................................... 69 42
3.7.2 Power Down Registration at the End of a Call .................................................................. 69 43
3.8 Global Emergency Call Origination......................................................................................... 69 44
3.9 E911 Phase I and Phase 2 ........................................................................................................ 70 45
3.10 Short Message Service ............................................................................................................ 70 46
3.10.1 SMS Feature Description ................................................................................................. 70 47
3.10.1.1 SMS - Mobile Originated Point-to-Point....................................................................... 70 48
3.10.1.2 SMS - Mobile Terminated Point-to-Point ..................................................................... 70 49
3.10.1.3 SMS - Broadcast.......................................................................................................... 71 50
3.10.2 SMS Delivery on the Control Channel ............................................................................. 71 51
3.10.2.1 SMS Broadcast Delivery over the Paging Channel........................................................ 71 52
3.10.2.2 SMS Delivery to an MS on the Paging Channel - Example 1 ........................................ 72 53
3.10.2.3 SMS Receipt from an MS on the Access Channel......................................................... 72 54
3.10.2.4 SMS Delivery to an MS on the Paging Channel - Example 2 without Early Traffic 55
Channel Assignment .................................................................................................... 73 56
3GPP2 A.S0013-0 v2.0
iv
3.10.2.5 SMS Delivery to an MS on the Paging Channel - Example 3 with Early Traffic Channel 1
Assignment.................................................................................................................. 75 2
3.10.3 SMS Delivery on the Traffic Channel............................................................................... 76 3
3.10.3.1 SMS Delivery to an MS on a Traffic Channel ........................................................ 76 4
3.10.3.2 SMS Receipt from an MS on a Traffic Channel...................................................... 77 5
3.11 Priority Access and Channel Assignment (PACA) ................................................................... 77 6
3.11.1 Mobile Origination with PACA Service ........................................................................... 77 7
3.11.1.1 Mobile Origination with PACA Service – Radio Resources not Available..................... 78 8
3.11.1.2 Mobile Origination, Idle Handoff with PACA Active ................................................... 79 9
3.11.1.3 Mobile Origination with PACA Active, Consecutive PACA Calls ................................ 80 10
3.11.2 PACA Call Cancellation Initiated by the MS.................................................................... 80 11
3.11.3 PACA Call Cancellation Initiated by Either MSC or BS ................................................... 81 12
3.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration 13
(OTAPA)................................................................................................................................ 82 14
3.12.1 OTASP Support............................................................................................................... 82 15
3.12.1.1 OTASP Call Setup....................................................................................................... 83 16
3.12.1.2 OTASP Data Exchanges .............................................................................................. 83 17
3.12.1.3 SSD Update Procedure................................................................................................. 83 18
3.12.1.4 Privacy Mode Procedure .............................................................................................. 83 19
3.12.1.5 Rejection ..................................................................................................................... 83 20
3.12.1.6 OTASP Call Clear ....................................................................................................... 83 21
3.12.1.7 OTASP Call Flow........................................................................................................ 83 22
3.12.2 OTAPA Support .............................................................................................................. 85 23
3.13 Mobile Position Determination ................................................................................................ 85 24
3.13.1 Call flows for Position Location Service (MS-PDE) ......................................................... 86 25
3.13.1.1 Mobile Originated Position Location Service on the Traffic Channel ............................ 86 26
3.13.1.2 Mobile Terminated Position Location Service on the Traffic Channel ........................... 89 27
3.13.1.3 Position Location Service over Common Channels – Mobile Terminated...................... 91 28
3.13.1.4 Position Location Service over Common Channels – Mobile Originated ....................... 92 29
3.13.2 Call Flows for Software Calculation Position Determination (BS-MSC) ........................... 93 30
3.14 User Zone ............................................................................................................................... 94 31
3.14.1 Invoking User Zone at Registration .................................................................................. 94 32
3.14.2 Use of User Zones During Call Setup............................................................................... 95 33
3.14.3 Changing User Zone During a Call................................................................................... 96 34
3.15 ISDN Interworking Service ..................................................................................................... 96 35
3.16 Circuit Data Calls.................................................................................................................... 97 36
3.17 3G Packet Data Calls............................................................................................................... 98 37
3.17.1 Data Ready to Send (DRS) Indicator ................................................................................ 98 38
3.17.2 Previous and Current Access Network Identifiers (PANID/CANID) ................................. 98 39
3.17.3 PDSN Selection Algorithm .............................................................................................. 99 40
3.17.4 A8/A9 Interface Call Flows ............................................................................................100 41
3.17.4.1 Mobile Initiated Initial Call Setup – Successful Operation ...........................................100 42
3.17.4.2 BS Initiated Call Release to Dormant State..................................................................102 43
3.17.4.3 MS Initiated Call Release to Dormant State.................................................................103 44
3.17.4.4 MS Power Down.........................................................................................................105 45
3.17.4.5 PDSN Initiated Service Release...................................................................................106 46
3.17.4.6 MS Initiated Call Re-Activation from Dormant State...................................................107 47
3.17.4.7 Network Initiated Call Re-Activation from Dormant State ...........................................107 48
3.17.4.8 Mobile Terminated Packet Data Rejection During a Voice Call ...................................109 49
3.17.4.9 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN.....................110 50
3.17.4.10 Dormant Handoff (Inter-BSC/Inter-PCF) - Mobile Served by a Different PDSN ..........112 51
3.17.4.11 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 52
Authentication in MSC Following Assignment Failure. (TCH is Established) ..............114 53
3.17.4.12 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 54
Authentication in MSC Following Assignment Failure. (No TCH Established) ............117 55
3.17.4.13 Soft / Softer Handoff Packet Data................................................................................118 56
3GPP2 A.S0013-0 v2.0
v
3.17.4.14 Inter-BS Hard Handoff (Within the Same PCF) ...........................................................118 1
3.17.4.15 Inter-PCF Hard Handoff (Within Same PDSN)............................................................121 2
3.17.4.16 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure.......................124 3
3.17.4.17 MS Initiated Call Release to Null State........................................................................127 4
3.17.4.18 Dormant MS Power Down, A10 Release Initiated by the MSC/BSC............................128 5
3.17.4.19 Mobile Initiated Initial Call Setup – Successful Operation with Delayed Accounting 6
Information.................................................................................................................130 7
3.17.4.20 Accounting Parameters Update Event Procedure .........................................................131 8
3.17.5 A10/A11 Interface Call Flows.........................................................................................132 9
3.17.5.1 Mobile Originated Packet Call Setup – Successful Operation.......................................133 10
3.17.5.2 Mobile Originated Packet Call Setup – Failure Operation ............................................135 11
3.17.5.3 Mobile Originated Packet Call Setup – With Registration to Alternate PDSN ..............137 12
3.17.5.4 Packet Data Service Session Clearing-PDSN Initiated .................................................139 13
3.17.5.5 Packet Data Service Session Clearing – MSC Initiated ................................................141 14
3.17.5.6 Packet Data Service Session Clearing – MS Initiated...................................................141 15
3.17.5.7 Packet Data Service Session Clearing – PDSN Initiated (Crossing A11-Registration 16
Request and A11-Registration Update)........................................................................142 17
3.17.5.8 Inter-PCF Dormant Handoff – Mobile Continues to be Served by the Serving PDSN...144 18
3.17.5.9 Inter-PCF Dormant Handoff – Mobile Served by a New Target PDSN.........................146 19
3.17.5.10 Inter-PCF Hard Handoff – Mobile Continues to be Served by the Serving PDSN.........148 20
3.17.5.11 Inter-BS Hard Handoff – Mobile Served by a New Target PDSN.................................152 21
3.17.5.12 Accounting update due to parameter changes...............................................................156 22
3.17.6 Version Interoperability Control......................................................................................156 23
3.17.6.1 A8/A9 Version Control ...............................................................................................156 24
3.17.6.1.1 Example of a Successful BS initiated A9-Version Control Procedure ....................156 25
3.17.6.1.2 Example of a Successful PCF Initiated A9-Version Control Procedure ..................157 26
3.17.6.2 A10/A11 Version Control ...........................................................................................157 27
3.17.7 Support of Short Data Bursts...........................................................................................158 28
3.17.7.1 A8/A9 Call Flows .......................................................................................................158 29
3.17.7.1.1 Mobile Originated Short Data Burst Call Flows ....................................................158 30
3.17.7.1.2 Mobile Terminated Short Data Burst Call Flows ...................................................160 31
3.17.7.1.2.1 Short Data Delivery from the PCF to the MS................................................160 32
3.17.7.1.2.2 Short Data Delivery from the PCF – BS Refuses SDB Request .....................162 33
3.17.7.2 A10/A11 Call Flows ...................................................................................................164 34
3.17.7.2.1 Short Data Burst Delivery to the PDSN.................................................................164 35
3.17.7.2.2 Short Data Burst Delivery from the PDSN to the MS ............................................165 36
3.17.8 Support for Common Channel Packet Data (CCPD) ........................................................166 37
3.17.8.1 A8/A9 Call Flows .......................................................................................................166 38
3.17.8.1.1 Mobile Originated CCPD Mode Request ..............................................................166 39
3.17.8.1.2 Mobile Terminated Packet Data for a CCPD Device .............................................169 40
3.17.8.1.3 CCPD Dormant Mode Packet Data Handoffs ........................................................171 41
3.17.8.1.3.1 Call Flow: CCPD MS Dormant Handoff - Mobile Served by 42
the Same PDSN ...........................................................................................171 43
3.17.8.1.3.2 Call Flow: Dormant Handoff of a CCPD Mobile: Mobile Served by a New 44
PDSN ..........................................................................................................173 45
3.17.8.2 A10/A11 Call Flows ...................................................................................................175 46
3.17.8.2.1 Call Flow: CCPD Mobile Originated Packet Data Call Setup – Successful 47
Operation .............................................................................................................175 48
3.17.8.2.2 Call Flow: CCPD MS Inter-PCF Dormant Handoff – Mobile Served by the Same 49
PDSN...................................................................................................................177 50
3.17.8.2.3 CCPD Mobile Inter-PCF Dormant Handoff – Mobile Served by a New PDSN ......179 51
3.17.9 Packet Data Security Considerations ...............................................................................181 52
3.17.9.1 PCF-PDSN Security Association.................................................................................182 53
3.18 Voice and Packet Concurrent Service .....................................................................................182 54
3.18.1 Concurrent Service Examples - Mobile Origination.........................................................182 55
3.18.1.1 Mobile Initiated Packet Data Service Connection, Voice Service is Already Active......183 56
3GPP2 A.S0013-0 v2.0
vi
3.18.1.2 Mobile Initiated Voice Service Connection, Packet Data Service is Already Active......184 1
3.18.2 Concurrent Service Examples - Mobile Termination........................................................186 2
3.18.2.1 Mobile Termination for Voice Service, Packet Data is Already Active.........................186 3
3.18.3 Concurrent Service Examples - BS Initiated Call Setup ...................................................188 4
3.18.3.1 Network Initiated Call Re-Activation from Dormant State, MS is Already Active with 5
Voice Service .............................................................................................................189 6
3.18.3.2 Network Initiated Call Re-Activation from Dormant State, MS is Active with a 7
Concurrent Voice Service and Has Performed an Inter-BS/Intra-PCF Voice 8
Call Handoff ...............................................................................................................190 9
3.18.4 Concurrent Services: Call Clearing Examples..................................................................192 10
3.18.4.1 Call Clear via Service Release – MS Initiated..............................................................192 11
3.18.4.2 Call Clear via Service Release - MSC Initiated ............................................................193 12
3.18.5 Concurrent Service - Handoff..........................................................................................194 13
3.18.5.1 Concurrent Service (Active Voice and Packet Data Services) - Hard Handoff ..............194 14
3.18.5.1.1 Successful Inter-BS Hard Handoff Call Flows (Within the Same PCF)..................194 15
3.18.5.1.2 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by 16
the Same PDSN) ..................................................................................................195 17
3.18.5.1.3 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by New PDSN) ...195 18
3.18.5.2 Concurrent Service (Active Voice and Dormant Packet Data Services) - Handoff ........195 19
3.18.5.2.1 Successful Inter-PCF Handoff Call Flows (Mobile Served by the Same PDSN).....195 20
3.18.5.2.2 Successful Inter-PCF Handoff Call Flow (Mobile Served by New PDSN) .............199 21
3.18.5.3 Concurrent Service - Soft / Softer Handoff ..................................................................202 22
3.19 Handoff .................................................................................................................................203 23
3.19.1 Handoff via MSC ...........................................................................................................203 24
3.19.1.1 Introduction ................................................................................................................203 25
3.19.1.1.1 Recognition That a Handoff is Required by a BS ..................................................203 26
3.19.1.1.2 Recognition That a Handoff is Required by the MSC............................................203 27
3.19.1.1.3 Concept of “Designated Cell”...............................................................................203 28
3.19.1.2 Inter-BS Hard Handoff................................................................................................204 29
3.19.1.2.1 Triggering Phase ..................................................................................................204 30
3.19.1.2.2 Target Determination Phase..................................................................................204 31
3.19.1.2.3 Resource Establishment........................................................................................204 32
3.19.1.2.4 Execution Phase ...................................................................................................204 33
3.19.1.3 Call Clearing...............................................................................................................204 34
3.19.1.4 Handoff Failure Handling ...........................................................................................205 35
3.19.1.5 Intra-BS Handoff ........................................................................................................205 36
3.19.2 Handoff via Direct BS-to-BS Signaling...........................................................................205 37
3.19.2.1 A3 Interface Messages ................................................................................................205 38
3.19.2.1.1 A3 Interface Setup Messages ................................................................................206 39
3.19.2.1.2 A3 Interface Operational Messages.......................................................................206 40
3.19.2.1.3 A3 Interface Clearing Messages............................................................................206 41
3.19.2.2 A7 Interface Messages ................................................................................................206 42
3.19.2.3 Soft/Softer Handoff Addition ......................................................................................207 43
3.19.2.4 Soft/softer Handoff Removal.......................................................................................208 44
3.19.2.5 Cell Removal by a Target BS ......................................................................................208 45
3.19.2.6 Call Clearing...............................................................................................................208 46
3.19.2.7 Handoff Performed .....................................................................................................208 47
3.19.2.8 Access Handoff and Channel Assignment into Soft Handoff........................................208 48
3.19.2.9 Soft/Softer Handoff of High Speed Packet Data...........................................................209 49
3.19.2.9.1 Soft/Softer Handoff of Forward Link Bursts of Data .............................................210 50
3.19.2.9.2 Soft/Softer Handoff of Reverse Link Bursts of SCH Data......................................210 51
3.19.3 Handoff Call Flows.........................................................................................................211 52
3.19.3.1 Hard Handoff via MSC Call Flows..............................................................................211 53
3.19.3.1.1 Successful Hard Handoff ......................................................................................211 54
3.19.3.1.2 Successful Hard Handoff to ANSI/TIA/EIA-553-A Systems .................................213 55
3GPP2 A.S0013-0 v2.0
vii
3.19.3.1.3 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 1
Alternative Rejected .............................................................................................214 2
3.19.3.1.4 Hard Handoff With Return On Failure ..................................................................216 3
3.19.3.1.5 Hard Handoff Failure – Connection Refused.........................................................217 4
3.19.3.2 Soft/softer Handoff via Direct BS-to-BS Signaling Call Flows.....................................218 5
3.19.3.2.1 Soft/softer Handoff Addition ................................................................................218 6
3.19.3.2.2 Soft/softer Handoff Removal ................................................................................220 7
3.19.3.2.3 Cell Removal by a Target BS................................................................................222 8
3.19.3.2.4 Initial Traffic Burst Example – A3 Connection Not Yet Established......................223 9
3.19.3.2.5 Subsequent Traffic Burst Example........................................................................225 10
3.19.3.2.6 Source BS Releases Reserved Resources ..............................................................227 11
3.19.3.2.7 Early Burst Termination Initiated by Source BS....................................................228 12
3.19.3.2.8 Early Burst Termination Initiated by Target BS.....................................................228 13
3.19.4 Fast Handoff Call Flows .................................................................................................228 14
3.19.4.1 Anchor PDSN Reachable from Target PCF .................................................................229 15
3.19.4.2 Anchor PDSN Not Reachable from Target PCF...........................................................232 16
3.19.5 Intergeneration Packet Data Handoff...............................................................................238 17
3.19.5.1 Hard Handoff from 2G System to 3G System ..............................................................238 18
3.19.5.2 Hard Handoff from 3G System to 2G System ..............................................................241 19
3.19.5.3 Intra-PCF Hard Handoff from 3G System to 2G System ..............................................244 20
3.19.5.4 Dormant Handoff from 2G System to 3G System ........................................................246 21
3.19.5.5 Dormant Handoff from 3G System to 2G System ........................................................246 22
3.20 Security Features....................................................................................................................246 23
3.20.1 Authentication and Privacy .............................................................................................246 24
3.20.1.1 SSD Update Procedure - Successful Case ....................................................................247 25
3.20.1.2 Terminal Authentication .............................................................................................249 26
3.20.1.3 Parameter Update........................................................................................................249 27
3.20.1.4 Privacy Mode Procedure .............................................................................................250 28
3.21 Flex Rate ...............................................................................................................................251 29
3.22 Status Inquiry.........................................................................................................................251 30
3.22.1 Status Inquiry Example...................................................................................................251 31
3.23 3X Multi-Carrier Operation ....................................................................................................252 32
3.23.1 Hard Handoff Support.....................................................................................................252 33
3.23.2 Soft Handoff Support......................................................................................................252 34
3.24 5 ms Messaging .....................................................................................................................253 35
3.24.1 Forward Link..................................................................................................................253 36
3.24.2 Reverse Link ..................................................................................................................253 37
3.25 Enhanced Rate Adaptation Mode (ERAM) .............................................................................253 38
3.26 Code Combining Soft Handoff (CCSH) ..................................................................................253 39
3.27 Rescue Channel......................................................................................................................253 40
3.27.1 Rescue Channel – Network and MS Select the Same Rescue Cell(s) ................................254 41
3.27.2 Rescue Channel – Network and MS Selected Different Rescue Cell(s).............................257 42
3.28 Terrestrial Circuit Management ..............................................................................................259 43
3.28.1 Terrestrial Circuit Management for the A2/A5 Interfaces.................................................259 44
3.28.1.1 A2/A5 Terrestrial Circuit Allocation ...........................................................................259 45
3.28.1.2 A2/A5 Terrestrial Circuit Blocking/Unblocking...........................................................260 46
3.28.1.2.1 Block Procedure Scenario Diagram.......................................................................260 47
3.28.1.2.2 Unblock Procedure Scenario Diagram...................................................................260 48
3.28.1.3 Reset Circuit Procedure...............................................................................................261 49
3.28.1.3.1 Reset Procedure at the BS Scenario Diagram ........................................................261 50
3.28.1.3.2 A1 Reset Circuit Procedure at the MSC ................................................................261 51
3.28.1.3.3 A1 Reset Circuit Procedure at the MSC with BS Block Response..........................262 52
3.28.1.4 Global System Reset ...................................................................................................263 53
3.28.1.4.1 Successful Reset at the MSC.................................................................................263 54
3.28.1.4.2 Successful Reset at the BS....................................................................................263 55
3.28.1.4.3 Reset Glare Noted at the MSC..............................................................................264 56
3GPP2 A.S0013-0 v2.0
viii
3.28.1.4.4 Reset Glare Noted at the BS .................................................................................265 1
3.28.1.4.5 Reset Glare Noted at Both the MSC and the BS ....................................................266 2
3.28.2 Terrestrial Circuit Management for the A3 Interface........................................................267 3
3.28.2.1 Successful Reset at a BS .............................................................................................267 4
3.28.2.2 A7-Reset Glare Noted at the First BS ..........................................................................268 5
3.28.2.3 A7-Reset Glare Noted at Both BSs..............................................................................269 6
3.29 Vocoder Support ....................................................................................................................270 7
3.29.1 Mobile Originated Calls..............................................................................................270 8
3.29.2 Mobile Terminated Calls.............................................................................................272 9
3.29.3 Service Option Change During Handoff ......................................................................273 10
11
12
3GPP2 A.S0013-0 v2.0
ix
List of Figures 1
2
Figure 2.11-1 Packet Data Service State Transitions................................................................................ 25 3
Figure 2.19.3-1 General Configuration Prior to a Fast Handoff. ............................................................... 31 4
Figure 2.19.3-2 General Configuration During a Fast Handoff, Step 1 ..................................................... 32 5
Figure 2.19.3-3 General Configuration During a Fast Handoff, Step 2 ..................................................... 32 6
Figure 3.1.1.1-1 Mobile Origination........................................................................................................ 44 7
Figure 3.1.1.2-1 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 8
Assignment into Soft/Softer Handoff............................................................................................... 47 9
Figure 3.1.2.1-1 Mobile Termination ...................................................................................................... 51 10
Figure 3.1.2.2-1 Mobile Termination: Assignment Retry......................................................................... 53 11
Figure 3.2.4.1-1 Call Clear Initiated by MS............................................................................................. 58 12
Figure 3.2.4.2-1 Call Clear Initiated by BS (via Clear Request) ............................................................... 58 13
Figure 3.2.4.3-1 Call Clear Initiated by MSC (via Clear Command) ........................................................ 59 14
Figure 3.3.1-1 Transcoder Control Call Flow .......................................................................................... 60 15
Figure 3.6.12-1 Feature Activation/Deactivation While in a Call ............................................................. 61 16
Figure 3.6.2-1 Call Waiting .................................................................................................................... 62 17
Figure 3.6.3.1-1 Three-Way Calling - (Method 1) ................................................................................... 63 18
Figure 3.6.3.2-1 Three-Way Calling - (Method 2) ................................................................................... 64 19
Figure 3.6.4.1-1 Message Waiting Notification on the Paging Channel .................................................... 65 20
Figure 3.6.4.2-1 Message Waiting Notification on the Traffic Channel .................................................... 65 21
Figure 3.6.5.2-1 Call Barring Outgoing................................................................................................... 66 22
Figure 3.7.1-1 Location Registration - Successful Case ........................................................................... 69 23
Figure 3.10.2.1-1 SMS-Broadcast Delivery to Mobile Stations over the Paging Channel.......................... 71 24
Figure 3.10.2.2-1 SMS-MT Delivery to an MS on the Paging Channel - Example 1................................. 72 25
Figure 3.10.2.3-1 SMS-MO Delivery on the Access Channel .................................................................. 73 26
Figure 3.10.2.4-1 SMS-MT Delivery to an MS on the Paging Channel - Example 2................................. 74 27
Figure 3.10.2.5-1 SMS-MT Delivery to an MS on the Paging Channel - Example 3................................. 75 28
Figure 3.10.3.1-1 SMS Message Delivery to an MS on a Traffic Channel................................................ 76 29
Figure 3.10.3.2-1 SMS Receipt from an MS on a Traffic Channel ........................................................... 77 30
Figure 3.11.1.1-1 Mobile Origination with PACA Service....................................................................... 78 31
Figure 3.11.1.2-1 Mobile Origination, Idle Handoff with PACA Active................................................... 79 32
Figure 3.11.1.3-1 Mobile Origination with Consecutive PACA Call Requests ......................................... 80 33
Figure 3.11.2-1 PACA Call Cancellation Initiated by the MS .................................................................. 81 34
Figure 3.11.3-1 PACA Call Cancellation Initiated by the MSC................................................................ 82 35
Figure 3.12.1.7-1 OTASP Message Flow: CDMA................................................................................... 84 36
Figure 3.13.1.1-1 Mobile Originated Position Location Service on a Traffic Channel............................... 87 37
Figure 3.13.1.2-1 Mobile Terminated Position Location Service on a Traffic Channel ............................. 89 38
Figure 3.13.1.3-1 PLD over Common Channels ...................................................................................... 91 39
Figure 3.13.1.5-1 PLD over Common Channels ...................................................................................... 92 40
Figure 3.13.2-1 Software Calculation for Position Determination ............................................................ 93 41
Figure 3.14.1-1 Location Registration using User Zones ......................................................................... 94 42
Figure 3.14.2-1 Mobile Call Setup Using User Zone ............................................................................... 95 43
Figure 3.14.3-1 Updating the User Zone During a Call............................................................................ 96 44
Figure 3.17.4.1-1 Mobile Initiated Initial Call Setup – Successful Operation...........................................101 45
Figure 3.17.4.2-1 BS Initiated Call Release to Dormant State .................................................................102 46
Figure 3.17.4.3-1 MS Initiated Call Release to Dormant State ................................................................104 47
Figure 3.17.4.4-1 MS Power Down........................................................................................................105 48
Figure 3.17.4.5-1 PDSN Initiated Service Release..................................................................................106 49
Figure 3.17.4.7-1 Network Initiated Call Re-Activation from Dormant State ..........................................108 50
Figure 3.17.4.8-1 Mobile Terminated Packet Data Rejection During a Voice Call...................................110 51
Figure 3.17.4.9-1 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN....................111 52
Figure 3.17.4.10-1 Dormant Handoff (Inter-BSC/Inter-PCF) - Mobile Served by a Different PDSN .......113 53
Figure 3.17.4.11-1 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 54
Authentication in MSC Following Assignment Failure. (TCH is Established) .................................115 55
3GPP2 A.S0013-0 v2.0
x
Figure 3.17.4.12-1 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 1
Authentication in MSC Following Assignment Failure (No TCH Established) ................................117 2
Figure 3.17.4.14-1 Inter-BS Hard Handoff (Within the Same PCF) ........................................................119 3
Figure 3.17.4.15-1 Inter-PCF Hard Handoff (Within Same PDSN).........................................................122 4
Figure 3.17.4.16-1 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure....................125 5
Figure 3.17.4.17-1 MS Initiated Call Release to Null State .....................................................................127 6
Figure 3.17.4.18-1 Dormant MS Power Down, A10 Release Initiated by the MSC/BSC .........................129 7
Figure 3.17.4.19-1 Mobile Initiated Initial Call Setup– Successful Operation with Delayed Accounting 8
Information....................................................................................................................................130 9
Figure 3.17.4.20-1 Accounting Parameters Update Event Procedure.......................................................132 10
Figure 3.17.5.1-1 Mobile Originated Packet Call Setup – Successful Operation ......................................134 11
Figure 3.17.5.2-1 Mobile Originated Packet Call Setup – Failure Operation ...........................................136 12
Figure 3.17.5.3-1 Mobile Originated Packet Call Setup – With Registration to Alternate PDSN..............138 13
Figure 3.17.5.4-1 Packet Data Service Session Clearing - PDSN Initiated...............................................140 14
Figure 3.17.5.5-1 Packet Data Service Session Clearing – MSC Initiated................................................141 15
Figure 3.11.5.5.6-1 Packet Data Service Session Clearing – MS Initiated ...............................................142 16
Figure 3.17.5.7-1 Packet Data Service Session Clearing– PDSN Initiated (Crossing A11-Registration 17
Request and A11-Registration Update)...........................................................................................143 18
Figure 3.17.5.8-1 Inter-PCF Dormant Handoff – Mobile Continues to be Served by the Serving PDSN ..145 19
Figure 3.17.5.9-1 Inter-PCF Dormant Handoff – Mobile Served by a New Target PDSN........................147 20
Figure 3.17.5.10-1 Inter-PCF Hard Handoff – Mobile Continues to be Served by the Serving PDSN ......150 21
Figure 3.17.5.11-1 Inter-BS Hard Handoff – Mobile Served by New Target PDSN.................................153 22
Figure 3.17.5.12-1 Accounting Update Due to Parameter Change...........................................................156 23
Figure 3.17.6.1.1-1 Successful BS Initiated A9-Version Control Procedure ............................................157 24
Figure 3.17.6.1.2-1 Successful PCF Initiated A9-Version Control Procedure ..........................................157 25
Figure 3.17.7.1.1-1 cdma2000 Short Data Burst from an MS to the PCF.................................................159 26
Figure 3.17.7.1.2.1-1 cdma2000 Short Data Burst from the PCF to the MS.............................................161 27
Figure 3.17.7.1.2.2-1 cdma2000 Short Data Burst from the PCF to the MS.............................................163 28
Figure 3.17.7.2.1-1 cdma2000 Short Data Burst from the MS to the PDSN.............................................164 29
Figure 3.17.7.2.2-1 cdma2000 Short Data Burst from the PDSN to the MS.............................................165 30
Figure 3.17.8.1.1-1 CCPD MS Initiated Packet Data Call Setup and Data Transfer .................................168 31
Figure 3.17.8.1.2-1 Mobile Terminated Packet Data for a CCPD Device ................................................170 32
Figure 3.17.8.1.3.1-1 CCPD MS Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served 33
by Same PDSN..............................................................................................................................172 34
Figure 3.17.8.1.3.2-1 CCPD MS Dormant Handoff (Inter-BSC/Inter-PCF) - Mobile Served 35
by Different PDSN ........................................................................................................................174 36
Figure 3.17.8.2.1-1 Mobile Originated CCPD Call Setup – Successful Operation ...................................176 37
Figure 3.17.8.2.2-1 Inter-PCF Dormant Handoff – Mobile Continues to be Served by the Same PDSN...178 38
Figure 3.17.8.2.3-1 Inter-PCF Dormant Handoff – Mobile Served by a New Target PDSN.....................180 39
Figure 3.18.1.1-1 Mobile Initiated Packet Data Service Connection, Voice Service is Already Active.....183 40
Figure 3.18.1.2-1 Mobile Initiated Voice Service Connection, One Service is Already Active.................185 41
Figure 3.18.2.1-1 Mobile Termination for Voice Service, Packet Data is Already Active ........................187 42
Figure 3.18.3.1 PCF Initiated Call Re-Activation from Dormant State, Voice is Already Active .............189 43
Figure 3.18.3.2-1 PCF Initiated Call Re-Activation from Dormant State, Voice is Already Active ..........191 44
Figure 3.18.4.1-1 Releasing a Service That Is Not the Only One Connected (MS Initiated).....................193 45
Figure 3.18.4.2-1 Releasing a Service That Is Not the Only One Connected (MSC Initiated) ..................194 46
Figure 3.18.5.2.1-1 Successful Inter-PCF Handoff (Mobile Served by the Same PDSN) .........................196 47
Figure 3.18.5.2.2-1 Successful Inter-PCF Handoff (Mobile Served by New PDSN) ................................200 48
Figure 3.19.3.1.1-1 Successful Hard Handoff .........................................................................................211 49
Figure 3.19.3.1.2-1 Successful Hard Handoff to an ANSI/TIA/EIA-553-A System .................................213 50
Figure 3.19.3.1.3-1 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 51
Alternative Rejected ......................................................................................................................215 52
Figure 3.19.3.1.4-1 Hard Handoff with Return On Failure......................................................................216 53
Figure 3.19.3.1.5-1 Hard Handoff Failure ..............................................................................................217 54
Figure 3.19.3.2.1-1 Soft/Softer Handoff Addition...................................................................................219 55
Figure 3.19.3.2.2-1 Soft/Softer Handoff Removal ..................................................................................221 56
3GPP2 A.S0013-0 v2.0
xi
Figure 3.19.3.2.3-1 Cell Removal Initiated by the Target BS..................................................................222 1
Figure 3.19.3.2.4-1 Initial Traffic Burst Example ...................................................................................224 2
Figure 3.19.3.2.5-1 Subsequent Traffic Burst Example...........................................................................226 3
Figure 3.19.3.2.6-1 Source BS Releases Reserved Resources .................................................................227 4
Figure 3.19.3.2.7-1 Early Burst Termination Initiated by Source BS.......................................................228 5
Figure 3.19.3.2.8-1 Early Burst Termination Initiated by Target BS .......................................................228 6
Figure 3.19.4.1-1 Anchor PDSN Reachable From Target PCF................................................................229 7
Figure 2.19.4.2-1 Anchor PDSN Not Reachable From Target PCF.........................................................233 8
Figure 3.19.5.1-1 Hard Handoff from 2G System to 3G System .............................................................239 9
Figure 3.19.5.2-1 Hard Handoff from 3G System to 2G System .............................................................242 10
Figure 3.19.5.3-1 Intra-PCF Hard Handoff from 3G System to 2G System .............................................244 11
Figure 3.20.1.1-1 SSD Update - Successful Case....................................................................................248 12
Figure 3.20.1.2-1 Terminal Authentication.............................................................................................249 13
Figure 3.20.1.3-1 Parameter Update.......................................................................................................250 14
Figure 3.20.1.4-1 Privacy Mode Procedure ............................................................................................250 15
Figure 3.22.1-1 Status Inquiry................................................................................................................251 16
Figure 3.27.1-1 Rescue Channel – Network and MS Select the Same Rescue Cell(s) ..............................255 17
Figure 3.27.2-1 Rescue Channel – Network and MS Selected Different Rescue Cells .............................258 18
Figure 3.29.1.2.1-1 Block Procedure......................................................................................................260 19
Figure 3.28.1.2.2-1 Unblock Procedure..................................................................................................260 20
Figure 3.28.1.3.1-1 A1 Reset Circuit Procedure at the BS.......................................................................261 21
Figure 3.28.1.3.2-1 A1 Reset Circuit Procedure at the MSC ...................................................................262 22
Figure 3.28.1.3.3-1 Reset Circuit Procedure at the MSC with BS Block Response ..................................262 23
Figure 3.28.1.4.1-1 Successful Reset at the MSC ...................................................................................263 24
Figure 3.28.1.4.2-1 Successful Reset at the BS.......................................................................................264 25
Figure 3.28.1.4.3-1 Reset Glare Noted at the MSC.................................................................................265 26
Figure 3.28.1.4.4-1 Reset Glare Noted at the BS ....................................................................................266 27
Figure 3.28.1.4.5-1 Reset Glare Noted at Both the MSC and the BS .......................................................267 28
Figure 3.28.2.1-1 Successful A7-Reset at a BS.......................................................................................268 29
Figure 3.28.2.2-1 A7-Reset Glare Noted at the First BS .........................................................................268 30
Figure 3.28.2.3-1 A7-Reset Glare Noted at Both BSs .............................................................................269 31
Figure 3.29.1-1 Vocoder Selection – Mobile Originated Case.................................................................271 32
Figure 3.29.2-1 Vocoder Selection – Mobile Terminated Case ...............................................................272 33
Figure 3.29.3-1 Vocoder Selection – Handoff Case ................................................................................273 34
35
36
3GPP2 A.S0013-0 v2.0
xii
Table of Tables 1
2
Table 3.20.1-1 Authentication and Voice Privacy Requirements.............................................................246 3
4
5
3GPP2 A.S0013-0 v2.0
xiii
Foreword 1
2
(This foreword is not part of this standard.) 3
4
This document was produced by Working Groups TR45.4 of the Telecommunications Industry 5
Association and TSG-A of the Third Generation Partnership Project 2. This document was 6
developed in accordance with TIA/EIA and 3GPP2 procedural guidelines, and represents the 7
consensus position of the Working Groups. 8
9
The Working Groups acknowledge the contributions made by the following individuals in the 10
development of this standard: 11
12
Name Representing Position Dale Baldwin Sprint PCS TIA TR45.4 Chair George Turnipseed Sprint PCS 3GPP2 TSG-A Chair Roger Edwards 3GPP2 Secretariat Professional Editor Srini Rao Winphoria Part 1 (Overview) Technical Editor Scott Marin Motorola Part 2 (Transport) Technical Editor Bill Semper Samsung Part 3 (Features) Technical Editor and
Chair for Comment Resolution Yasaman Abtahi and Mini Vasudevan
Nortel Networks Part 4 (A1/A2/A5) Technical Editors
Janice Wunsch Lucent Technologies Part 5 (A3/A7) Technical Editor Shahab Sayeedi Motorola Part 6 (A8/A9) Technical Editor Roger Gustavsson and Erik Colban
Ericsson Part 7 (A10/A11) Technical Editors
13
14
Suggestions for improvement of this standard are welcome. They should be sent to: 15
Telecommunications Industry Association 16
Engineering Department 17
Suite 300 18
250 Wilson Boulevard 19
Arlington, VA 22201 USA 20
21
22
3GPP2 A.S0013-0 v2.0
xiv
1
(This page intentionally left blank.) 2
3
4
5
6
7
8
3GPP2 A.S0013-0 v2.0
Section 1 1
1.0 Introduction 1
This document contains the procedures and call flows associated with the features that 2
are supported by this release of the IOS specification. 3
1.1 Overview 4
This document includes a description of the protocol and some generic procedures to 5
support the following features and functions. Conformance to this standard may be 6
claimed on a feature by feature and/or interface by interface basis. If conformance on a 7
given interface is claimed for a feature, it shall be supported as defined in this standard. 8
The following Features have been added in this revision of the standard: 9
3G Packet Data Calls 10
· Fast Handoff 11
· Common Channel Packet Data (CCPD) 12
Code Combining Soft Handoff 13
Enhanced Rate Adaptation Mode 14
Flex Rate 15
Rescue Channel 16
Status Inquiry 17
In addition, the following enhancements were made to IOS functions: 18
ESN was added as an Accounting Parameter 19
Bi-directional GRE Key Assignment over the A9 and A11 Interfaces 20
A8/A9 Version Control 21
A10/A11 Version Control 22
Position Determination Location (service options 35 and 36) 23
Features and Functions Explicitly Supported in this Standard: 24
3G Packet Data Calls 25
· Call Setup (Mobile Originated) 26
· Reactivation (Mobile Initiated and Network Initiated) 27
· Handoffs (Dormant , Hard, Fast) 28
· Call Clearing (Mobile Initiated and Network Initiated) 29
· Transition to Dormancy 30
· Accounting 31
· Common Channel Packet Data (CCPD) 32
· Short Data Bursts 33
3X Multi-Carrier 34
5ms Messaging 35
Call Clearing of Voice and Circuit Data Calls (Mobile Initiated and Network Initiated) 36
Call Setup for Voice and Circuit Data Calls (Mobile Originated and Mobile 37
Terminated) 38
Circuit Data Calls (Asynchronous Data and Group-3 Fax) 39
Code Combining Soft Handoff (CCSH) 40
E911 Phase 1 and Phase 2 41
Enhanced Rate Adaptation Mode (ERAM) 42
Flex Rate 43
Global Emergency Call Origination 44
Handoff 45
· Handoff via MSC 46
· Handoff via direct BS-to-BS signaling 47
3GPP2 A.S0013-0 v2.0
Section 1 2
· Fast Handoff 1
· Hard Handoff into Soft Handoff 2
· Intergenerational Packet Data Handoff 3
ISDN Interworking 4
Mobile Position Determination 5
Mobile Registration (Mobile Originated) 6
Over the Air Service Provisioning (OTASP) 7
Over the Air Parameter Administration (OTAPA) 8
Priority Access and Channel Assignment (PACA) 9
Rescue Channel 10
Security Features 11
· Terminal Authentication 12
· Signaling Message Encryption 13
· Voice/Data Privacy 14
Short Message Service (Mobile Originated, Mobile Terminated, and Broadcast) (SMS) 15
Status Inquiry 16
Support of DTMF 17
Support for DS-41 base stations 18
Support of Supplementary Services 19
· Feature Activation/Deactivation: Idle and In-Call 20
· Call Waiting 21
· Three-Way Calling 22
· Message Waiting Notification 23
· Call Barring 24
· Calling Number ID Presentation (CNIP)/ Calling Number ID Restriction 25
(CNIR) 26
· Distinctive Ringing 27
· Answer Holding 28
· User Selective Call Forwarding 29
Terrestrial Circuit Management 30
Test Calls 31
TFO Support 32
User Zone 33
Vocoder Support 34
Voice and Packet Data Concurrent Services 35
Features and Functions Transparently Supported in this Standard: 36
Advice of Charge (AOC) 37
Call Delivery 38
Call Forwarding 39
· Call Forwarding Unconditional (CFU) 40
· Call Forwarding When Busy (CFB) 41
· Call Forwarding - No Answer (CFNA) 42
· Call Forwarding Default 43
Call Transfer 44
Carrier Access 45
Emergency Service (Basic) via specific dialed number (e.g., “911”) 46
Lawfully Authorized Wiretap 47
48
49
3GPP2 A.S0013-0 v2.0
Section 1 3
1
Active Handoff (MC-41 to MC-41 and DS-41 to DS-41): the following types of handoffs 2
are supported: 3
Type of Handoff
Voice calls
Async Data and G3 Fax
Packet Data Calls (up to
2 Mbps)
ISDN Interworking
Calls
Intra-BS, Intra-MSC Soft Handoff Yes Yes Yes Yese
* Intra-BS, Intra-MSC Hard Handoff Yes Yes Yes Yese
Inter-BS, Intra-MSC Soft Handoff Yes Yes Yes Yese
* Inter-BS, Intra-MSC Hard Handoff Yes Yes Yesa Yese
Inter-BS, Inter-MSC Soft Handoff Yes Yes Yes Yese
* Inter-BS, Inter-MSC Hard Handoff Yes No Yesb Yese
Intergenerational Handoff c Yes Yes Yesd Noe
Active Handoff (DS-41 hard handoff to/from MC-41): the following types of handoffs 4
are supported: 5
Type of Handoff
Voice calls
Async Data and G3 Fax
Packet Data Calls (up to
2 Mbps)
* Inter-BS, Intra-MSC Hard Handoff Yes Yes Yesa
* Inter-BS, Inter-MSC Hard Handoff Yes No Yesb
* Hard handoff does not apply to supplemental channels 6
a. Inter-BS, Intra-MSC Hard Handoff may result in handoff across PDSN 7
boundaries. 8
b. Inter-BS, Inter-MSC Hard Handoff may result in handoff across PDSN 9
boundaries. In addition, this requires extensions to ANSI-41 for packet data 10
services. 11
c. Intergenerational handoff describes handoff of a mobile between a system that 12
supports packet data service as specified in [11] to [17] and a system that 13
supports a packet data service as specified in [10]. 14
d. The Service Option changes in this scenario. 15
e. Not applicable for DS-41 to DS-41 handoffs. 16
Soft Handoff enhancements, as specified in [10] are supported by this specification. 17
Access Handoff, Access Probe Handoff and CDMA Channel Assignment into Soft 18
Handoff and Access Entry Handoff as specified in [10] are supported in this 19
specification. 20
Access Entry Handoff is transparent to this standard. 21
Mobile-Assisted CDMA-to-CDMA Inter-Frequency Handoff Enhancement is supported 22
as specified in [10]. 23
Circuit mode voice service assumptions: 24
The following assumptions are made: 25
3GPP2 A.S0013-0 v2.0
Section 1 4
• All mobiles are capable of executing a service option change and a hard handoff 1
simultaneously. That is, the Action Time for both of these activities may be the 2
same. 3
• For inter-vendor hard handoff, the source BS knows the service option capabilities of 4
the target BS. 5
• For inter-vendor soft handoff, all target BS channel elements are capable of 6
supporting both the 13K and EVRC service options (i.e., rate set 1 and rate set 2). 7
• The source BS may assume that sufficient resources are available at the target BS for 8
the requested service option. 9
• A default service configuration shall be used at all target BSs for hard handoff. 10
• The MSC is aware of the service options supported by each of the BSs attached to it. 11
• Hard handoff from 13K to EVRC is disallowed for TIA/EIA/IS-95B mobiles. For 12
cdma2000 mobiles, if the target BS does not have 13K available, the target BS may 13
send a new service option to the source BS. 14
• Currently, only 13K (8000H and 0011H) and EVRC voice service options are 15
supported. 16
• The default service option for IOS networks is 13K voice (SO=8000H). 17
• All mobile stations capable of supporting EVRC can also support 13K (8000H) 18
service options. 19
• Service negotiation is between the Base Station (BS) and the Mobile Station (MS). 20
• Service negotiation only depends on the capabilities of the BS and of the MS. 21
Based on these assumptions, a source BS will always know what vocoder types (EVRC / 22
13K) are supported at the target BS, and what service configuration is to be used at the 23
target BS. If a change of vocoder type is necessary, the source BS can accomplish it by 24
commanding the MS to execute a service option change and a hard handoff 25
simultaneously. Thus, service negotiation messaging is not needed on either the A1 or A3 26
interfaces. 27
The following procedures are to be followed: 28
• If the BS receives a Paging Request from the MSC specifying a service option valid 29
for this version of the IOS but not supported by the BS, the BS pages the mobile with 30
the service option in the Paging Request message. 31
• If the BS receives an Origination Message / Paging Response Message from a MS 32
specifying a service option not valid for this standard, the BS may deny the request. 33
In the case of an originating call, the BS may order the MS to generate a local 34
Reorder signal. 35
• Otherwise, if the BS receives an Origination Message / Paging Response Message 36
from a MS specifying a supported service option (i.e., rate set 1 or rate set 2), that is 37
not supported on the particular BS, the BS shall send a CM Service Request message 38
/ Paging Response message to the MSC containing the service option received from 39
the MS. 40
• The MSC sends the service option that was received in the CM Service Request / 41
Paging Response message in the Assignment Request message. 42
• Otherwise, the call is handled using the call setup procedures of this specification. 43
In all cases, if a call is successfully set up, the BS shall inform the MSC of the agreed 44
service option in the Assignment Complete message. 45
3GPP2 A.S0013-0 v2.0
Section 1 5
In the intra-MSC hard handoff scenario, if the source BS asks for a service option not 1
supported by the target BS, then the MSC may reject the handoff request. 2
1.1.1 Purpose 3
The purpose of this document is to provide IOS Feature Description (Stage 1) and IOS 4
Feature Call Flows (Stage 2) for the Access Network Features. 5
1.1.2 Scope 6
This document provides user level descriptions and access network call flows designed to 7
assist in the development of the interfaces that coincide with the Reference Points: “A”, 8
“Ater”, “Aquater”, and “Aquinter”, as defined in the Network Reference Model. Refer to [28]. 9
Refer to [11] to [17] for definitions of messages and timers used in this document. 10
1.2 References 11
12
1.2.1 TIA / EIA 13
For ease of cross referencing, the Telecommunications Industry Association (TIA) / 14
Electronics Industry Association (EIA) references provided in this section are aligned 15
with the 3GPP2 references, provided in section 1.2.2. For consistency within IOS parts, 16
the most commonly referenced documents [1~17] shall be the same as they appear here 17
in this part, or left as “Reserved” if not used in a particular IOS part. 18
[1] TIA/EIA/IS-2000.1-A, Introduction for cdma2000 Standards for Spread 19
Spectrum Systems, November 2000. 20
[2] TIA/EIA/IS-2000.2-A, Physical Layer Standard for cdma2000 Spread Spectrum 21
Systems, November 2000. 22
[3] TIA/EIA/IS-2000.3-A, Medium Access Control (MAC) Standard for cdma2000 23
Spread Spectrum Systems, November 2000. 24
[4] TIA/EIA/IS-2000.4-A, Signaling Link Access Control (LAC) Standard for 25
cdma2000 Spread Spectrum Systems, November 2000. 26
[5] TIA/EIA/IS-2000.5-A, Upper Layer (Layer 3) Signaling Standard for cdma2000 27
Spread Spectrum Systems, November 2000. 28
[6] TIA/EIA/IS-2000.6-A, Analog Signaling Standard for cdma2000 Spread 29
Spectrum Systems, November 2000. 30
[7-8] Reserved. 31
[9] TIA/EIA-41-D, Cellular Radio-Telecommunications Intersystem Operations; 32
December, 1997. 33
[10] TIA/EIA-95-B; Mobile Station - Base Station Compatibility Standard for Dual-34
Mode Wideband Spread Spectrum Cellular Systems; March, 1999. 35
[11] TIA/EIA-2001.1-B, Interoperability Specification (IOS) for cdma2000 Access 36
Network Interfaces – Part 1 Overview, May, 2002. 37
[12] TIA/EIA-2001.2-B, Interoperability Specification (IOS) for cdma2000 Access 38
Network Interfaces – Part 2 Transport, May, 2002. 39
[13] TIA/EIA-2001.3-B, Interoperability Specification (IOS) for cdma2000 Access 40
Network Interfaces – Part 3 Features, May, 2002. 41
[14] TIA/EIA-2001.4-B, Interoperability Specification (IOS) for cdma2000 Access 42
Network Interfaces – Part 4 (A1, A2, and A5 Interfaces), May, 2002. 43
[15] TIA/EIA-2001.5-B, Interoperability Specification (IOS) for cdma2000 Access 44
Network Interfaces – Part 5 (A3 and A7 Interfaces), May, 2002. 45
3GPP2 A.S0013-0 v2.0
Section 1 6
[16] TIA/EIA-2001.6-B, Interoperability Specification (IOS) for cdma2000 Access 1
Network Interfaces – Part 6 (A8 and A9 Interfaces), May, 2002. 2
[17] TIA/EIA-2001.7-B, Interoperability Specification (IOS) for cdma2000 Access 3
Network Interfaces – Part 7 (A10 and A11 Interfaces), May, 2002. 4
[18] TIA/EIA-553-A, Mobile Station - Base Station Compatibility Specification; 5
November, 1999. 6
[19] TIA/EIA-602-A, Data Transmission Systems and Equipment, Serial 7
Asynchronous Automatic Dialing and Control; August, 2000. 8
[20] TIA/EIA/IS-637-A, Short Message Service for Spread Spectrum Systems, 9
September, 1999. 10
[21] TIA/EIA-664-A, Wireless Features Description; December 2000. 11
[22] TIA/EIA/IS-683-B, Over the Air Service Provisioning of Mobile Stations in 12
Spread Spectrum Systems, December, 2001. 13
[23] TIA/EIA/IS-707-A-2, Data Services Option Standard for Spread Spectrum 14
Systems - Addendum 2, June 2000. 15
[24] TIA/EIA/IS-725-A, TIA/EIA-41-D Enhancements for Over-The-Air Service 16
Provisioning (OTASP) & Parameter Administration (OTAPA), March, 1999. 17
[25] TIA/EIA/IS-728, InterSystem Link Protocol, April, 1998. 18
[26] TIA/EIA/IS-801-1, Position Determination Service Standard for Dual Mode 19
Spread Spectrum Systems, March, 2001. 20
[27] TIA/EIA-895, CDMA Tandem Free Operation, January, 2002.. 21
[28] TIA/EIA/TSB100-A, Wireless Network Reference Model, March, 2001.. 22
[29] Common Cryptographic Algorithms, Revision D.1, September, 2000. An EAR 23
controlled document subject to restricted distribution. Contact the 24
Telecommunications Industry Association, Arlington, VA. 25
[30] Interface Specification for Common Cryptographic Algorithms, Revision D.1, 26
September, 2000. Contact the Telecommunications Industry Association, 27
Arlington, VA. 28
1.2.2 3GPP2 29
The 3GPP2 references are aligned with the TIA/EIA references of Section 1.2.1 and are 30
provided here for information and cross reference purposes. 31
[1] 3GPP2 C.S0001-A, Introduction to cdma2000 Standards for Spread Spectrum 32
Systems, June 2000.. 33
[2] 3GPP2 C.S0002-A-1, Physical Layer Standard for cdma2000 Spread Spectrum 34
Systems, October 2000. 35
[3] 3GPP2 C.S0003-A-1, Medium Access Control (MAC) Standard for cdma2000 36
Spread Spectrum Systems, October 2000. 37
[4] 3GPP2 C.S0004-A-1, Signaling Link Access Control (LAC) Standard for 38
cdma2000 Spread Spectrum Systems, October 2000. 39
[5] 3GPP2 C.S0005-A-1, Upper Layer (Layer 3) Signaling Standard for cdma2000 40
Spread Spectrum Systems, October 2000. 41
[6] 3GPP2 C.S0006-A-1, Analog Signaling Standard for cdma2000 Spread 42
Spectrum Systems, October 2000. 43
[7-8] Reserved. 44
[9-10] Reserved. 45
[11] 3GPP2 A.S0011-0, Interoperability Specification (IOS) for cdma2000 Access 46
Network Interfaces – Part 1 Overview, May, 2002. 47
[12] 3GPP2 A.S0012-0, Interoperability Specification (IOS) for cdma2000 Access 48
Network Interfaces – Part 2 Transport, May, 2002. 49
[13] 3GPP2 A.S0013-0, Interoperability Specification (IOS) for cdma2000 Access 50
Network Interfaces – Part 3 Features, May, 2002. 51
[14] 3GPP2 A.S0014-0, Interoperability Specification (IOS) for cdma2000 Access 52
Network Interfaces – Part 4 (A1, A2, and A5 Interfaces), May, 2002. 53
3GPP2 A.S0013-0 v2.0
Section 1 7
[15] 3GPP2 A.S0015-0, Interoperability Specification (IOS) for cdma2000 Access 1
Network Interfaces – Part 5 (A3 and A7 Interfaces), May, 2002. 2
[16] 3GPP2 A.S0016-0, Interoperability Specification (IOS) for cdma2000 Access 3
Network Interfaces – Part 6 (A8 and A9 Interfaces), May, 2002. 4
[17] 3GPP2 A.S0017-0, Interoperability Specification (IOS) for cdma2000 Access 5
Network Interfaces – Part 7 (A10 and A11 Interfaces), May, 2002. 6
[18-19] Reserved. 7
[20] 3GPP2 C.S0015-0, Short Message Service, December, 1999. 8
[21] 3GPP2 S.R0006-0, Wireless Features Description, December, 1999. 9
[22] 3GPP2 C.S0016-0, Over the Air Service Provisioning of Mobile Stations in 10
Spread Spectrum Systems, June, 1998. 11
[23] 3GPP2 C.S0017-0-2, Data Service Options for Spread Spectrum Systems 12
Addendum 2, January 14, 2000. Refer also to TIA/EIA/IS-707-A-2. 13
[24] 3GPP2 N.S0011-1, OTASP and OTAPA, January, 1999. 14
[25] 3GPP2 N.S0019-0, Intersystem Link Protocol, April, 1998. 15
[26] 3GPP2 C.S0022-0, Location Services (Position Determination Service), 16
December, 1999. 17
[27] 3GPP2 A.S0004, 3GPP2 Tandem Free Operation Specification, June, 2000. 18
[28] 3GPP2 S.R0005-B, Network Reference Model for cdma2000 Spread Spectrum 19
Systems, April, 2001. 20
[29] 3GPP2, S.P0053, Common Cryptographic Algorithms, (include if completed by 21
end of TIA-2001-B ballot]. 22
[30] S.P0054, Interface Specification for Common Cryptographic Algorithms, 23
(include if completed by end of TIA-2001-B ballot]. 24
1.2.3 International Telecommunications Union - 25
Telecommunications Sector (ITU-T) 26
[31] ITU-T Recommendation V.32bis, A duplex modem operating at signalling rates 27
of up to 14,400 bit/s for use on the general switched telephone network and on 28
leased point-to-point 2-wire telephone-type circuits, February, 1991. 29
[32] ITU-T Recommendation V.42, Error-correcting procedures for DCEs using 30
asynchronous-to-synchronous conversion, January, 1996. 31
1.2.4 Other 32
[33] Internet Engineering Task Force, RFC 1321 – The MD5 Message-Digest 33
Algorithm, April 1992. 34
[34] Internet Engineering Task Force, RFC 2002 – IP Mobility Support, October 35
1996. 36
[35] Internet Engineering Task Force, RFC 3115 – Mobile IP Vendor/Organization-37
Specific Extensions, April 2001. 38
1.3 Terminology 39
40
1.3.1 Acronyms 41
42
Acronym Meaning 2G Second Generation
3GPP2 Third Generation Partnership Project 2
3GPP2 A.S0013-0 v2.0
Section 1 8
Acronym Meaning AC Authentication Center
ADDS Application Data Delivery Service
AMPS Advanced Mobile Phone System
AUTHBS Authentication
AUTHR Authentication Response
AUTHU Unique Challenge Authentication Response
BCD Binary Code Decimal
BS Base Station
BSC Base Station Controller
BTS Base Transceiver System
CANID Current Access Network Identifiers
CC Call Control
CCPD Common Channel Packet Data
CCSH Code Combining Soft Handoff
CDMA Code Division Multiple Access
CM Connection Management
CNIP Calling Number Identification Presentation
CNIR Calling Number Identification Restriction
COUNT Call History Count
CW Call Waiting
DCCH Dedicated Control Channel
DRS Data Ready to Send
DS0 Digital Signal Level 0
DTMF Dual Tone Multi-Frequency
EIA Electronics Industry Association
EPSMM Extended Pilot Strength Measurement Message
ERAM Enhanced Rate Adaption Mode
EVRC Enhanced Variable Rate Codec
FCH Fundamental Channel
FER Frame Error Rate
GRE Generic Routing Encapsulation
HLR Home Location Register
IE Information Element
IMSI International Mobile Subscriber Identity
IOS Interoperability Specification
IP Internet Protocol
IS Interim Standard
ISDN Integrated Services Digital Network
ISLP Intersystem Link Protocol
IWF Interworking Function
3GPP2 A.S0013-0 v2.0
Section 1 9
Acronym Meaning LAC Link Access Control
MAC Medium Access Control
MC Message Center (alternatively: Mobile Client)
MIP Mobile IP
MS Mobile Station
MSC Mobile Switching Center
MSIN Mobile Station Identifier Number
MWI Message Waiting Indication
NID Network Identification
NVSE Normal Vendor Specific Extension
OS Operations System
OTAF Over The Air Function
OTAPA Over The Air Parameter Administration
OTASP Over The Air Service Provisioning
PACA Priority Access and Channel Assignment
PANID Previous Access Network Identifiers
PCF Packet Control Function
PCM Pulse Coded Modulation
PDE Position Determination Entity
PDSN Packet Data Serving Node
PIN Personal Identification Number
PLD Position Location Data
PPP Point to Point Protocol
PZID Packet Zone Identifier
RAN Radio Access Network
RAND Random Variable
RANDC Random Confirmation
RANDSSD Random SSD
RANDU Random Variable – Unique Challenge
RLP Radio Link Protocol
SAT Supervisory Audio Tone
SCCP Signaling Connection Control Part
SCH Supplemental Channel
SDB Short Data Burst
SDU Selection/Distribution Unit
SID System Identification
SME Signaling Message Encryption
SMS Short Message Service
SMS-MO SMS Mobile Originated
SMS-MT SMS Mobile Terminated
3GPP2 A.S0013-0 v2.0
Section 1 10
Acronym Meaning SOCI Service Option Connection Identifier
SPI Security Parameter Index
SSD Shard Secret Data
TCH Traffic Channel
TDSO Test Data Service Option
TFO Tandem Free Operation
TIA Telecommunications Industry Association
UDI Unrestricted Digital Information
VLR Visitor Location Register
1.3.2 Definitions 1
Reserved. 2
1.4 Call Processing and Supplementary Services Assumptions 3
This section contains assumptions for call processing and supplementary services. 4
In some of the call processing and services functions, it is possible that an inter-BS hard 5
handoff may occur during the process. In such an event, the target BS (i.e., the BS to 6
which the MS has been handed off) shall assume responsibility for functionality ascribed 7
to the BS as defined herein.. 8
1.4.1 Call Control 9
Call control shall be primarily the responsibility of the MSC. The BS provides message 10
transmission and interworking between the particular air interface and the MSC. 11
1.4.1.1 A2/A5 Terrestrial Circuit Allocation 12
Terrestrial Circuit allocation is handled in the following manner: 13
The MSC considers the interface to the BS as a route of “n” circuits. The MSC shall 14
therefore ensure that the terrestrial circuit chosen is able to support the type of call 15
involved. 16
The BS may suggest a preferred terrestrial circuit to the MSC, in which case, the MSC 17
shall use the suggested terrestrial circuit if available. Refer to section 2.28 for the 18
definition of “available.” 19
1.4.1.2 Radio Channel Allocation 20
The BS allocates the radio channel to be used. This may be based on information 21
received from the MSC. 22
3GPP2 A.S0013-0 v2.0
Section 1 11
1.4.1.3 Traffic Channel Release 1
The release of a dedicated resource is primarily controlled by the MSC. However, for 2
radio propagation reasons, the BS may request that the MSC release a call. 3
1.4.1.4 A3 User Traffic Subchannel Allocation 4
The target BS considers the interface to the SDU as a route of multiple A3 User Traffic 5
Subchannels. The target BS chooses an A3 User Traffic Subchannel from the idle A3 6
User Traffic Subchannels connected to the SDU where the call being processed is 7
anchored. 8
1.5 Radio Resource Management Assumptions 9
This section contains assumptions about radio resource management. 10
1.5.1 Radio Channel Supervision 11
1.5.1.1 Traffic Channel Radio Link Supervision 12
Radio link supervision of dedicated radio resources shall be the responsibility of the BS. 13
If communication with the mobile is lost then the BS can request that the call be cleared. 14
1.5.1.2 Idle Channel Observation 15
The quality of idle radio channels may be measured by the BS. 16
1.5.2 Radio Channel Management 17
1.5.2.1 Radio Channel Configuration Management 18
The channel configuration management shall be controlled between the BS and the 19
Operations System (OS) over the “O” Interface. The BS shall be able to support one cell 20
or multiple cells. The “O” Interface is beyond the scope of this specification. 21
1.5.2.2 Radio Traffic Channel Management 22
1.5.2.2.1 Radio Channel Allocation 23
The BS shall always choose the radio channel to be used. 24
1.5.2.2.2 Radio Traffic Channel Release 25
The release of a dedicated radio resource is primarily controlled by the MSC. However, 26
for radio propagation reasons the BS can request of the MSC that a call be released. 27
1.5.2.2.3 Radio Traffic Channel Power Control 28
All power control functions shall be performed between the MS and the BS. 29
3GPP2 A.S0013-0 v2.0
Section 1 12
1.5.2.2.4 Channel Encoding and Decoding 1
The radio channel encoding and decoding, and interleaving shall be performed by the BS. 2
The type of radio channel coding and interleaving is derived from the information in the 3
Assignment Request message from the MSC. 4
5
.6
3GPP2 A.S0013-0 v2.0
Section 2 13
2.0 Feature Descriptions 1
2
2.1 Call Setup of Voice and Circuit Data Calls 3
Call setup is a process where a sequence of messages is used to advance the call to a 4
stable condition where the parties involved may communicate. 5
The call setup may be a normal call setup, emergency call setup, SMS, OTAPA, PACA 6
call setup, or other supplementary service invocation. 7
Call Setup messages are defined in [14]. 8
Refer to section 3.1.1 for mobile originated call flows and section 3.1.2 for mobile 9
terminated call flows associated with this feature. A mobile-to-mobile call is handled as a 10
combination of a mobile originated and a mobile terminated call. Tandem Free Operation 11
(TFO) may be applied for mobile-to-mobile calls to enhance speech quality, refer to 12
section 2.3. 13
2.2 Call Clearing of Voice and Circuit Data Calls 14
Call clearing is a process where a sequence of messages is used to free in a controlled 15
manner all resources in the network associated with one or all service instances of a 16
mobile. 17
There are two types of call clearing over the A1 interface: 18
1. Call clearing of a single service, when other services are connected. 19
2. Call clearing of all services connected (including the case where only one 20
service is connected). 21
Call clearing may be initiated by either the BS, the MS, or the MSC. 22
Call clearing collision occurs when two entities independently initiate the call clearing 23
procedures; refer to section 3.2.3 for description of cases of call clearing collisions. 24
Refer to section 3.2 for call flows related to this feature. 25
2.2.1 Call Clearing Initiated by the MS or BS 26
When the MS initiates a normal clearing of all services including the only service 27
connected, the MS sends a Release Order to the BS. The BS shall send a Clear Request 28
message to the MSC and wait for the Clear Command message from the MSC. 29
The MSC is responsible for clearing A1, A2, and/or A5 connections associated with the 30
call. To release all allocated resources associated with all services, the MSC shall send a 31
Clear Command message to the BS. The call flow scenarios are illustrated in section 32
3.2.4.3. 33
The MS may also initiate a release of a service that is not the only service connected to 34
the MS. The scenario is illustrated in section 3.18.4.1. 35
3GPP2 A.S0013-0 v2.0
Section 2 14
If the MS is not active (powered off) or if for any reason the radio channel failed between 1
the MS and the BS or if some internal BS failure occurs, then the BS initiates call 2
clearing. The BS sends a Clear Request message to the MSC. The scenario is illustrated 3
in section 3.2.4.2. 4
2.2.2 Call Clearing Initiated by the MSC 5
When the MSC chooses to deny call set up initiated by the reception of a CM Service 6
Request or Paging Response message contained in a SCCP Connection Request, the 7
MSC may send a SCCP Connection Refused containing no user data. 8
When the MSC initiates a normal clearing of a single service that is not the only service 9
connected, the MSC sends a Service Release message to the BS. This normal call 10
clearing scenario is illustrated in section 3.18.4.2. 11
In case the MSC initiates a normal clearing of all services, the MSC shall send a Clear 12
Command message to the BS. This normal call clearing scenario is illustrated in section 13
3.2.4.3. 14
Call clearing messages are not affected if the network provides either tones or 15
announcements immediately before clearing a call. 16
2.3 TFO Support 17
Mobile to mobile calls are handled as a combination of mobile originated and mobile 18
terminated calls. For information on Tandem Free Operation, refer to [27]. 19
It is generally known that tandeming of vocoders results in noticeable audio degradation. 20
Although some vocoders handle tandeming better than others, all suffer from this effect. 21
Such tandeming occurs in a mobile-to-mobile digital call. 22
For a mobile to mobile digital call, vocoding currently takes place at both the originating 23
and terminating SDUs. Encoded audio received at the SDU is decoded and subsequently 24
routed to the mate SDU via the MSC(s). At the mate SDU, the decoded voice is encoded 25
again prior to transmission over the air. This “tandem” vocoding results in an audio 26
quality degradation and increased throughput delay compared to a mobile-to-land or 27
land-to-mobile call. 28
The TFO feature enhances current operation by bypassing the vocoding process at the 29
SDU(s) for mobile to mobile calls. If both mobile parties are using the same voice service 30
option, the encoded voice received from the BTS is not decoded at the SDU. Instead the 31
encoded voice is converted to the appropriate MSC/BS signaling format (e.g., rate 32
adapted to a 64K DS0 timeslot, but not decoded) for transmission through the MSC 33
network. The mate MSC in turn routes the encoded speech to the appropriate SDU where 34
it is converted back to the appropriate signaling format for routing to the BTS. 35
TFO setup operation relies on inband signaling exchange between the SDUs. The SDUs 36
use inband signaling to determine when it is appropriate to establish TFO operation. 37
Refer to [27] for complete details regarding the inband signaling protocol. 38
The TFO feature also provides the capability of controlling TFO operation via “out-of-39
band” signaling. Specifically, the Transcoder Control Request and Transcoder Control 40
Acknowledge messages could be used over the A1 interface to disable/enable the inband 41
signaling mechanism at the SDUs. Disabling the inband signaling mechanism, forces the 42
3GPP2 A.S0013-0 v2.0
Section 2 15
call to revert to tandem vocoding mode. These same messages can also be used to re-1
start/enable the inband signaling protocol at the SDUs. This capability is beneficial for 2
supplementary feature interaction scenarios (such as, Answer Hold and Three Party 3
Conferencing). 4
Refer to section 3.3 for call flows associated with this feature. 5
2.4 Test Calls 6
The purpose of test calls is to generate test data (e.g., frame error rate (FER), forward and 7
reverse link capacity estimates, etc.) for performance analysis. These calls need not 8
require any trunks (DS0 circuits) on the A2 or A5 interfaces. The MS or the MSC may 9
initiate a test call. 10
The test data service option (TDSO) provides for the generation of an arbitrary 11
(preselected or random) data source for transport over forward and reverse traffic 12
channels while following an arbitrary (preselected or random) transmission frame 13
activity. The test is performed at a fixed data rate. The MS and the BS generate test data 14
frames for the configured and allocated traffic channels. The frame generation processes 15
are synchronized between the MS and the BS. This permits the receiving station to 16
reproduce the transmitted frames and compare them to the received frames. 17
The Markov service option provides pseudo-random data for testing the Fundamental 18
Channel between the MS and the BS. The test can be performed at a fixed data rate or at 19
a variable data rate. A pseudo-random process governs the selection of the data rate for 20
each data block in a variable rate test. A pseudo- random process also generates the 21
content of each data block. The pseudo-random processes are synchronized between the 22
MS and the BS. This permits the receiving station to reproduce the transmitted data 23
blocks and compare them to the received data blocks. 24
The loopback service options provide a loopback of primary traffic information bits 25
through the MS. These service options provide the means for a BS to supply a known 26
data stream on both the Forward and Reverse Traffic Channels so that a MS’s receiving 27
and transmitting performance can be measured. In addition, these service options provide 28
a convenient means of setting up calls and generating traffic for system testing. 29
When the test call uses a TDSO, Markov, or loopback operation, reception of any 30
supplementary service messages or inter-BS hard handoff requests may be considered 31
unexpected and may be ignored. 32
Hard handoff is not supported for any test calls. 33
Refer to section 3.4 for call flows associated with this feature. 34
2.5 Support of DTMF 35
DTMF digit transmission can be sent using in-band tones between the MS and MSC once 36
a call is in Conversation State. No action is required by the BS for transmission of in-37
band DTMF signals. 38
Alternatively, DTMF digits may be sent in a Send Burst DTMF Message over the air 39
interface, refer to [5]. In the MS to network direction, the BSC is required to generate the 40
DTMF tones and inject them into the 64 kbit/s PCM stream towards the MSC. In the 41
network to MS direction the BS may extract the DTMF signal from the 64 kbit/s PCM 42
3GPP2 A.S0013-0 v2.0
Section 2 16
stream received from the MSC and generate the Send Burst DTMF Message to be 1
delivered over the air interface. 2
There are no call flows associated with this feature. 3
2.6 Support of Supplementary Services 4
Overview descriptions of these features are given in the following subsections. 5
2.6.1 Feature Activation and Deactivation 6
When the network receives a Flash with Info Message, Origination Message or Enhanced 7
Origination Message from the MS during a particular call state it interprets it as an 8
invocation of a supplementary service. The mobile subscriber activates, deactivates, 9
registers, and erases a supplementary service by entering a digit string at the MS, which 10
is sent to the MSC. The MSC performs digit analysis on the dialed digits to determine 11
that the subscriber requires a supplementary service operation, and processes the request. 12
Feature activation/deactivation in idle mode is accomplished by the sending of a string of 13
digits and end marks (*, #) that identify the feature to be activated/deactivated, along with 14
any additional PIN information, called party number, etc. in a mobile origination. The 15
MSC, after doing digit analysis, determines that the request is for feature 16
activation/deactivation, processes the request, and gives the MS an indication of the 17
acceptance or rejection of the request using normal call setup or call clearing procedures. 18
After taking appropriate action (e.g., setting up a call and playing a tone or 19
announcement), the MSC or MS may initiate call clearing. No special action is required 20
at the BS to process supplementary service requests using this method. Refer to the 21
message flow diagrams for the mobile originated call setup (section 3.1.1) for an 22
illustration of this message handling. 23
Feature activation/deactivation while in a call is accomplished by sending a string of 24
digits and end marks (*, #) that identify the feature to be activated/deactivated, along with 25
any additional PIN information, called party number, etc. in an air interface Flash with 26
Information message or Enhanced Origination message from the MS to the BS and in an 27
Flash with Information message or Additional Notification message from the BS to the 28
MSC. Any response by the MSC to the BS is via in-band signals provided by the MSC. 29
Such actions are treated as activities that are independent of the Flash with Information 30
messages going in the other direction. 31
Refer to section 3.6.1 for the call flow associated with this feature. 32
2.6.2 Call Waiting 33
Call Waiting provides notification to a controlling subscriber of an incoming call while 34
the subscriber is in the Conversation State. Subsequently, the controlling subscriber can 35
either answer or ignore the incoming call. If the controlling subscriber answers the 36
second call, it may alternate between the two calls. For additional description, refer to 37
[21]. 38
The Call Waiting notification of the incoming call is sent as Flash with Information 39
messages to the MS from the MSC via the BS, or, alternatively, the Call Waiting 40
notification is sent as an in-band tone between the MS and the MSC. 41
3GPP2 A.S0013-0 v2.0
Section 2 17
The second call (Call Waiting call) is answered by the MS by sending a Flash with 1
Information messages to the MSC via the BS. The MS may alternate between the two 2
calls by sending Flash with Information messages to the MSC via the BS. 3
Thus feature is activated according to Feature Activation described in section 2.6.1. 4
Call flows associated with this feature can be found in section 3.6.2. 5
2.6.3 Three Way Calling 6
Three Way Calling provides the controlling subscriber the capability of adding a third 7
party to an established two-party call, so that all three parties may communicate in a call. 8
If either of the two non-controlling parties to an established three-party call disconnects, 9
the remaining party is reconnected to the controlling subscriber as a normal two-party 10
call. If the controlling subscriber of a three-party call disconnects, all other parties are 11
released. 12
An MS requests a three-way calling by sending a Flash with Information message to the 13
BS, which forwards this request to the MSC. This message puts the remote party on hold. 14
This request may include the address of the third party that is to be included in the three-15
party call. If the initial Flash with Information message does not included the address of 16
the third party, the MS sends a subsequent Flash with Information containing the third 17
party address. 18
A call is established to the third party address. When the call is answered, the MS 19
establishes the three-way call by sending a Flash with Information to the BS, which 20
forwards it to the MSC, which places all three parties in a conference call. 21
For further description, refer to [21]. 22
Call flows associated with this feature can be found in section 3.6.3. 23
2.6.4 Message Waiting Notification 24
Message Waiting Notification (MWN) informs a subscriber when a voice message is 25
available for retrieval. The MWN may use different types of indications to inform a 26
subscriber of an unretrieved voice message. 27
The Feature Notification message is used to deliver a Message Waiting Indication (MWI) 28
to the MS while it is idle. There is a possible race condition when the Feature 29
Notification message is sent while an MS is originating a call. If this occurs, the message 30
waiting indication may not be successfully delivered. It is recommended that the MSC 31
request an acknowledgment with the Feature Notification, and resend the MWI 32
information on the traffic channel, if necessary. 33
The Flash with Information message is used to deliver a Message Waiting Indication 34
while the MS is on a traffic channel, i.e., after an Assignment Complete message has 35
been received at the MSC. 36
For further description, refer to [21]. 37
Refer to section 3.6.4 for the call flows associated with this feature. 38
3GPP2 A.S0013-0 v2.0
Section 2 18
2.6.5 Call Barring 1
Call Barring provides the possibility to bar a subscriber from originating calls and 2
receiving calls. The reason a subscriber is barred from originating or receiving calls is 3
defined as an implementation issue. Call Barring can be of the following types: 4
• Origination Denied 5
• Termination Denied 6
• Local calls only 7
• Selected leading digits of directory number 8
• Selected leading digits of directory number and local calls only 9
• National long distance (including local calls and may include neighboring counties) 10
• International calls (includes national long distance and local calls) 11
• Single Directory Number (only number allowed except for 9-1-1) 12
Call Barring Incoming is transparent to the IOS interfaces. 13
Call Barring Outgoing requires the MSC to assign a channel to the originating mobile, 14
apply call treatment (e.g. announcement to mobile subscriber on the traffic channel) and 15
then clear the call after treatment has been applied. Note that the subscriber may also 16
initiate call clearing upon hearing the announcement or other appropriate treatment (e.g., 17
tones). 18
Refer to section 3.6.5 for the call flow associated with this feature. 19
2.6.6 Calling Number ID Presentation / Restriction 20
Calling Number ID Presentation provides the number identification of the calling party to 21
the called subscriber. 22
Calling Number ID Restriction restricts presentation of the subscriber’s Calling Number 23
Identification to the called party. The Calling Number ID Restriction may be made 24
permanently or temporary on the subscriber’s request. 25
The following subsections describe the support for: 26
• Calling Number Identification Presentation (CNIP) 27
• Calling Number Identification Restriction (CNIR) 28
2.6.6.1 CNIR for Mobile Originated Calls 29
For CNIR, the calling party can request CNIR on a per call basis by including the feature 30
code before the Called Party Number digits in the Called Party BCD Number in the CM 31
Service Request message. 32
2.6.6.2 CNIP/CNIR for Mobile Terminated Calls 33
There are two types of CNIP/CNIR supported: 34
1. If the MS is idle, for mobile terminated calls, the CNIP/CNIR information is 35
sent in the Assignment Request message. The call flows for this feature are 36
identical to the call flows for a mobile terminated call, refer to section 3.1.2. 37
3GPP2 A.S0013-0 v2.0
Section 2 19
2. If the MS user subscribes to the Call Waiting (CW) feature and is engaged in 1
a call, the CNIP/CNIR information is sent in the Flash with Information 2
message. The call flow for this feature is identical to the call flow for Call 3
Waiting, refer to section 3.6.2. 4
The MSC codes the presentation restriction information as “presentation allowed” when 5
providing text, e.g., “Unknown Number” or “Private Number,” corresponding to the 6
cases when the number is not available or is presentation restricted. When the “screening 7
indicator” is not provided or can not be determined, a default value of “network 8
provided” is recommended. 9
2.6.7 Distinctive Ringing 10
Distinctive Ringing provides the MS with the possibility to receive information from the 11
MSC to create a distinctive ring signal. 12
The A1 interface uses the Signal element or the MS Information Records element to carry 13
information to the MS concerning the specific ringing pattern to be used. Refer to [14]. 14
The call flows for this feature are identical to the call flows for a mobile terminated call, 15
refer to section 3.1.2. 16
2.6.8 Answer Holding 17
Answer Hold (AH) provides a called subscriber the capability to answer the call, but 18
selectively delay the conversation (e.g., calls in the alerting or Call Waiting state). The 19
incoming call is provided an appropriate network announcement to notify the calling 20
party to please hold. 21
AH is also applicable to incoming calls being delivered to called AH authorized 22
subscribers as Call Waiting (CW) calls. 23
This feature is activated according to Feature Activation described in section 2.6.1. 24
The MS uses the Flash with Information message to invoke Answer Holding in the 25
Alerting and Call Waiting state. The Flash with Information message is also used to 26
toggle between two calls, one of which in Answer Holding state, while in Call Waiting 27
state. 28
Call flows for Answer Holding are shown in section 3.6.8. 29
2.6.9 User Selective Call Forwarding 30
User Selective Call Forwarding provides a called subscriber the capability to selectively 31
redirect unanswered, incoming calls to an alternate destination (e.g., to a voice mail 32
system, to a network registered Directory Number, or to a Directory Number stored in the 33
MS). User Selective Call Forwarding is applicable both to calls being offered to a 34
subscriber via alerting and to calls being offered to a subscriber via Call Waiting 35
Notification. 36
This feature is activated according to the Feature Activation described in section 2.6.1: 37
• The Forward-To-Number registration is handled by the regular Feature Activation 38
feature. 39
3GPP2 A.S0013-0 v2.0
Section 2 20
• When an MS is in the alerting state, or in the Conversation state and receiving a Call 1
Waiting Notification, the MS sends a Flash with Information to invoke this feature. 2
Call flows for User Selective Call Forwarding are shown in section 3.6.9. 3
2.7 Mobile Registration (Mobile Originated) 4
Mobile registration is a process where mobile characteristics such as location or status are 5
provided to the network. Registration may be initiated by the MS, by the network (not 6
supported in this version of this standard), or implied during a MS access. 7
The following functions are not supported in this version of the specification: 8
• The ability to allow the MSC to order an idle MS to perform a registration; 9
• Traffic channel registration - where the MSC may notify an MS that it is registered 10
while the MS occupies a traffic channel. 11
The MSC may infer registration information based on a mobile’s system access. This 12
form of registration is transparent to the BS and the MS, and requires no additional 13
message passing over the MSC-BS interface. 14
The MS may initiate registration for a number of reasons. The types of registration 15
performed are enabled and controlled through parameters transmitted by the BS on the 16
forward (downlink) control channels. Selection of control channel parameters and 17
enabling of specific registration types are beyond the scope of this document, and will not 18
be discussed further. 19
Refer to section 3.7 for call flows associated with this feature. 20
2.8 Global Emergency Call Origination 21
The phone number required to access a Public Safety Answering Point (emergency 22
assistance) in a given geographic area may not be known to the user. In fact, there may 23
be different access numbers for difference agencies (e.g., police, fire, medical). 24
Global Emergency Call Origination is a mechanism whereby the user initiates an 25
emergency service call via some vendor specific means. The MS origination message 26
includes an indication that this is an emergency service request and the network handles 27
the call accordingly. 28
The MS origination may include user dialed digits. The network may use the dialed 29
digits, if present, to determine more specific information regarding the type of emergency 30
support requested. 31
Normal mobile originated call setup call flows apply to this feature; refer to section 3.1.1. 32
2.9 E911 Phase I and Phase 2 33
For E911 phase 1, the CM service request provides the location of the E911 MS and also 34
provides the MSID (IMSI) of the MS to be used for the callback number. 35
For E911 phase 2, this standard supports delivery of the mobile location data from the 36
network to a Position Determining Entity (PDE). Procedures and protocols used on the 37
interface between the PDE and other Network Entities are outside the scope of this 38
3GPP2 A.S0013-0 v2.0
Section 2 21
standard. Further this standard assumes that all involved elements (i.e. MS, BS, MSC and 1
PDE) conform to [26]. The PDE can either be supported at the BS or centrally at the 2
MSC. If the PDE is located at the BS the mobile location is sent to the MSC; otherwise, if 3
the PDE is located in the core network, mobile location data is sent to the MSC. 4
Call back feature is transparently supported by the normal call establishment procedures. 5
2.10 Short Message Service 6
The Short Message Service (SMS) provides for the transfer of short messages between an 7
application residing on a MS and an application within the network, e.g., at a Message 8
Center (MC). The MSC and BS provide a conduit for short messages between the 9
application in the network, e.g., at the MC, and the application in the MS. Other network 10
procedures carried out by entities providing a Short Message Service (SMS), are beyond 11
the scope of this standard (refer to [9]). 12
Three types of basic short messaging are supported: mobile originated point-to-point, 13
mobile terminated point-to-point, and broadcast. Both mobile originated and mobile 14
terminated point-to-point short messaging may require that messages be exchanged in 15
both directions on the air interface. 16
Short messages can be exchanged between the MS and BS on both the control and traffic 17
channels. Thus, an active MS is able to send and receive short messages at any time. The 18
maximum number of short message characters that can be handled varies with the air 19
interface and teleservice type employed. Each short message shall be carried within a 20
single message on the MSC-BS Interface: no provision is made for segmentation and 21
reassembly of short messages. 22
The Short Message Service is divided into a number of protocol layers: the SMS 23
teleservice layer, the SMS transport layer, and the SMS relay layer (refer to [20]). The 24
relay layer may sit on top of other air interface layers. Not all air interfaces may support 25
the full range of SMS capabilities and layers. All of these layers are transparent to the 26
MSC-BS Interface, and are carried as part of the SMS user part element in the MSC-BS 27
Interface messages. 28
For point to point delivery, the MSC can request that the BS report that a Layer 2 29
acknowledgment was received from the MS. This indicates that the MS received the short 30
message. In addition, both the transport and teleservice layers may generate 31
acknowledgments (refer to [20]) but these acknowledgments are transparent to the MSC-32
BS Interface. 33
The scope of the requirements and specifications outlined in this document are limited to 34
the MSC-BS Interface, as defined in the Network Reference Model ([28]). Descriptions 35
of operations at other interfaces are included for information only. 36
Refer to section 3.10 for call flows associated with this feature. 37
2.11 Priority Access and Channel Assignment (PACA) 38
PACA (Priority Access Channel Assignment) allows a user to have priority access to 39
traffic channels on call origination. When the traffic channel is not available, the BS can 40
queue the mobile and update the queue position subsequently. When a traffic channel 41
becomes available, the BS serves the MS based on first come first served within a 42
priority. 43
3GPP2 A.S0013-0 v2.0
Section 2 22
The subscriber has two options for invocation of PACA: Permanent or Demand (refer to 1
[21]). In the permanent option, the feature is always available and is used automatically 2
whenever the user attempts to originate a call. In the demand option, the feature is 3
available only on request via dialing the feature code before the telephone number at the 4
time of origination for that specific call. 5
By sending the PACA Message over the air-interface, the BS can notify the user that the 6
call is queued, the queue position is updated, or the PACA call should be re-originated. 7
When the PACA call is enabled, the MS shall operate in non-slotted mode. If the MS is 8
directed by the user to cancel the queued PACA call, the MS shall send the PACA Cancel 9
Message. 10
Two conditions may occur on a call origination with PACA service. In the first condition, 11
the BS can not determine the availability of radio resources before sending the CM 12
Service Request to the MSC. Thus, the BS sends the Radio and Environment Resources 13
Information element (without indicating the availability of its radio resources) in the CM 14
Service Request message to the MSC. Refer to [14] for further explanations of this 15
message and information element. In this case, the origination call flow shown in section 16
3.1.1.1 is followed. 17
In the second case, the BS determines that radio resources are not available before 18
sending the CM Service Request. The BS sends an indication in the CM Service Request 19
message to notify the MSC that the radio resources are unavailable. In this case, the 20
origination call flow shown in section 3.11.1.1 is followed. 21
The PACA Service call flows are defined based on the following principles: 22
• The PACA queue is maintained and managed at the BS. 23
• The timestamp is managed at the MSC. 24
• The MSC assigns the priority level and time of a PACA eligible call and informs the 25
BS in the Assignment Request or PACA Command message. 26
• The MSC maintains the timestamp information for the PACA call and assists in 27
maintaining the priority while the MS is roaming within the system by passing the 28
timestamp information to the new BS in the Assignment Request or PACA Update 29
message. 30
• The BS may keep the MS informed of updated queue position. 31
• The BS informs the MSC in case of re-origination of PACA call in the CM Service 32
Request message. 33
• The PACA call can be canceled implicitly or explicitly by the MS, the BS or the 34
MSC. 35
Refer to section 3.11 for call flows associated with this feature. 36
2.12 Over-The-Air Service Provisioning (OTASP) and Over The Air 37
Parameter Administration (OTAPA) 38
These features are fully specified in [22]. 39
2.12.1 OTASP Support 40
Normal call setup procedures for voice calls are used to establish an OTASP call. The 41
mechanism for transporting OTASP data messages over the air interface is defined in 42
3GPP2 A.S0013-0 v2.0
Section 2 23
[22]. The processing of OTASP data messages at the MSC or BS is the responsibility of 1
the vendors. OTASP data messages are transported on the A1 interface via the ADDS 2
Deliver/Ack messages. The MSC interface to the network is addressed in [24]. 3
Refer to section 3.12.1 for the call flow associated with this feature. 4
2.12.2 OTAPA Support 5
OTAPA is supported in this specification by the ADDS Deliver/Ack set of messages. A 6
specific Service Option (18 or 19) is required to set up the call. No specific messages or 7
information areas are required beyond the messages necessary to set up a Mobile 8
Terminated call and to transfer ADDS messages. The only requirement for the BS is to 9
provide interworking between the air interface and the A1 interface for these messages. 10
The use of these messages by the MS and the MSC is beyond the scope of this 11
specification. 12
2.13 Mobile Position Determination 13
This section includes descriptions of how to support determination of the MS’s position. 14
Various approaches are possible. The supported approaches are discussed in the 15
subsections below. 16
2.13.1 Support of Position Location Service (MS – PDE Approach) 17
The Position Location Service provides for the transfer of Position Location Data 18
between an application residing on a MS and an application within the network (i.e. 19
Position Determining Entity (PDE)). Support of the TIA/EIA/IS-801 messages using the 20
ADDS message across the "A" interface is mandatory. Other network procedures carried 21
out by entities providing Position Location Data (PLD) are beyond the scope of this 22
standard. 23
Position Location Data is transferred between MSC and BS using ADDS procedures on 24
both the control and traffic channels. Normally the ADDS messages are used to carry 25
application data between the MS and the MSC which is transparent to the BS, however, 26
for PLD applications a BS may trigger the position determination process. Thus, an 27
active MS is able to send and receive Position Location Data messages at any time. The 28
Position Location Data and associated messaging is defined in [26]. This is transparent to 29
the MSC-BS Interface, and is carried as part of the ADDS User Part element in the MSC-30
BS A1 Interface messages. 31
2.13.2 Software Calculation Position Determination (BS-MSC 32
Approach) 33
Through the use of software calculation techniques, a network based Position 34
Determination based process can take advantage of the radio interface parameters and 35
measurements to determine the location of a MS that is on a traffic channel. These 36
messages support both network based and mobile-assisted position determination. The 37
MSC requests certain measurements and parameters from the BS, and the BS provides 38
those measurements in a response message. Calculations then take place to determine the 39
location of the MS. 40
3GPP2 A.S0013-0 v2.0
Section 2 24
For PLD applications that have a base station based position determination process, the 1
BS may return the Geographic Location IE in the Radio Measurements for Position 2
Response message. 3
If the PSMM Count is 0, and if either the BS does not support PLD; or if it does, but the 4
LPDE is not able to compute a geographical estimate based on the available 5
measurements, then the BS shall return the CDMAOneWayDelay information in the 6
response. 7
2.14 User Zone 8
The concept of User Zones is important to the operation of CDMA Tiered Services. It is 9
via User Zones by which the network offers custom services based upon the MS location. 10
User Zones are associated with a set of features and services, plus a geographic area in 11
which the User Zone features/services are made available to the customers that have 12
subscribed to that User Zone. The boundary of the User Zone Geographic area may be 13
established based on the coverage area of a BS, or it may be established independent of 14
RF topology. Refer to [5] for further details on User Zones. 15
The MS User Zone may be indicated at registration time in the Location Updating 16
Request, or at call setup in the CM Service Request or Paging Response messages sent by 17
the BS to the MSC. The User Zone may also be changed during the call by using the User 18
Zone Update Request message. User Zone Reject and User Zone Update messages are 19
sent by the MSC to the BS to reject or change the MS's active User Zone. 20
Refer to section 3.14 for call flows associated with this feature. 21
2.15 ISDN Interworking 22
ISDN interworking service provides interoperable communications between an MS and 23
an existing ISDN subscriber terminal operating in the public ISDN as well as between 24
mobile stations. The procedures and interfaces are specified in [23]. 25
For all calls supporting ISDN interworking services, the MSC shall provide a function of 26
protocol conversion between upper layer signaling over the A1 interface and ISDN 27
signaling, and the SDU shall construct Unrestricted Digital Information (UDI) data/RLP 28
frames from RLP frames/UDI data respectively. 29
Refer to section 3.15 for more details on this feature. 30
2.16 Circuit Data Calls 31
Circuit Data calls include Asynchronous Data and Group-3 Fax services. These services 32
allow the MS to send and receive asynchronous data and facsimiles. Refer to [14] for 33
information on valid service options. The procedures and interfaces are specified by [23], 34
which specifies compliance with other TIA data standards and ITU recommendations 35
(e.g. [19], [31], and [32]). 36
For all calls supporting circuit-oriented data services, an Interworking Function (IWF) 37
exists that interfaces between the transmission of the data in the fixed network and the 38
transmission of the data over the air interface. For this standard, the IWF for circuit-39
oriented data calls is considered to be located at the MSC. The A5 interface connects the 40
3GPP2 A.S0013-0 v2.0
Section 2 25
SDU to the IWF. The A5 interface carries a duplex stream of user traffic between the 1
MSC and SDU. Once an IWF has been allocated for a circuit-oriented data call, it shall 2
remain anchored for the duration of the call. 3
According to [23], the RLP is terminated in the SDU. The A5 interface in this case 4
carries the output of the RLP function specified in [23] from the SDU function to the 5
IWF. The protocol currently defined in this standard for the A5 interface is ISLP. Refer 6
to [25]. 7
Both mobile origination and mobile termination applications of this service shall be 8
“Data Only”. 9
Normal call origination, call termination, and call clearing procedures apply. 10
Call flows associated with this feature are described in sections 3.1.1, 3.1.2, and 3.2. 11
This standard supports Handoffs for Asynchronous Data and Group 3 fax calls as 12
indicated in section 1.1. 13
2.17 3G Packet Data Calls 14
Packet data calls allow users to exchange data between the MS and an IP data network. 15
This section describes IOS support for 3G packet data services. These services are 16
primarily identified with service option 33, as defined in [23]. Other service options also 17
may be used (refer to [14]) for Intergeneration Handoff (handoff between systems 18
supporting packet data services based on ANSI/TIA/EIA/IS-95-B and systems supporting 19
packet data service based on cdma2000). Intergeneration Handoffs are described in 20
section 2.19.5. 21
For all calls supporting packet data services, a Packet Data Serving Node (PDSN) exists 22
that interfaces between the transmission of the data in the fixed network and the 23
transmission of the data over the air interface. The PDSN interfaces to the BS through a 24
Packet Control Function (PCF), which may or may not be co-located with the BS. 25
For purposes of the protocol of this standard, there are three packet data service states: 26
Active/Connected, Dormant, and Null/Inactive. In the Active/Connected State, a physical 27
traffic channel exists between the MS and the BS, and either side may send data. In the 28
Dormant State, no physical traffic channel exists between the MS and the BS, but the 29
PPP link between the MS and the PDSN is maintained. In the Null/Inactive State, there is 30
no traffic channel between the MS and the BS and no PPP link between the MS and the 31
PDSN. 32
Active / Connected
State
Dormant State
Null/Inactive State
33
Figure 2.11-1 Packet Data Service State Transitions 34
3GPP2 A.S0013-0 v2.0
Section 2 26
The mobile may cross Packet Zone boundaries while in the Dormant State. This is 1
referred to as Dormant Handoff. The Dormant handoff procedures specified in this 2
standard allow the A10 connections between the PCF and PDSN to be moved (or 3
established) for the mobile when it enters a new packet zone. 4
The mobile may re-enter Active state (e.g., if the user has data to send) at any time. This 5
transition is referred to as Re-Activation from Dormant, and is not related to Dormant 6
Handoff (i.e., Re-Activation from Dormant is not related to a mobility event). 7
Packet data is typically transmitted over the air on dedicated traffic channels. 8
Mechanisms also exist for transmitting data over the common channels. Short Data Burst 9
is a part of the 3G Packet Data feature that enables small amounts of data to be 10
transmitted over the common channels. Common Channel Packet Data is a mode of 3G 11
Packet Data where all data is transmitted using Short Data Bursts. 12
A1 and A8 connections are maintained during the Active / Connected State and released 13
during transition to Dormant or Null/Inactive State. The A10 connection is maintained 14
during the Active/Connected and the Dormant State. 15
Refer to section 3.17 and accompanying subsections for call flows associated with packet 16
data. 17
2.17.1 Packet Data Assumptions 18
The following assumptions are made regarding packet data. 19
1. Each PCF corresponds to a packet zone, each PCF is uniquely identified by the 20
Current Access Network Identifiers (CANID) and every PCF knows its CANID 21
value. Location update is performed when the mobile roams into a new PCF area. 22
No dormancy knowledge is required by the PDSN. 23
2. The set of PDSNs that a PCF may connect to is known at the PCF. 24
3. A PDSN selection algorithm as specified in Section 3.17.3 is used for initial PDSN 25
assignment and PDSN reselection. 26
4. When connecting to a PDSN during an active session handoff or during dormant 27
handoff, if the target PDSN recognizes the session, it does not require a restart of 28
PPP. 29
5. Links between PCFs and PDSNs support both the signaling and traffic channels. 30
6. The signaling channels support call connects, disconnects, as well as signaling for 31
QoS, accounting information etc. 32
7. The traffic channels support in-sequence delivery of data payload. 33
8. A PCF initiates an A10 connection, but either the PCF or the PDSN may drop it. 34
9. The A10/A11 interfaces are assumed to be supported on a private IP network for 35
security considerations. 36
10. When IP is used as the network layer for the A10 bearer, standard IP QoS 37
mechanisms may be employed. 38
3GPP2 A.S0013-0 v2.0
Section 2 27
2.17.2 Previous and Current Access Network Identifiers 1
(PANID/CANID) 2
The selected PDSN needs to know whether a mobile is being handed off by a PCF that 3
was not previously using this PDSN for the connection, in order to determine if PPP 4
reconfiguration and Mobile IP registration are required. The information used to make 5
this determination consists of the Packet Zone Identifier (PZID), System Identification 6
(SID) and Network Identification (NID) values, which are also referred to as the Access 7
Network Identifiers. The PCF is uniquely identified by the Current Access Network 8
Identifiers (CANID) and every PCF knows its CANID value. Anytime a mobile crosses 9
into a new region, where the region is defined by the Access Network Identifiers, it shall 10
re-register with that Access Network. 11
Refer to section 3.17.2 for more details. 12
2.17.3 PDSN Selection Algorithm 13
The PDSN selection algorithm specified in this standard shall be used for initial PDSN 14
selection of the first service instance and PDSN re-selection initiated by Dormant 15
handoff. This algorithm increases the likelihood that the MS will be re-connected to the 16
same PDSN upon Dormant handoff, thereby avoiding possible PPP and MIP re-17
establishment on a new PDSN. The algorithm is based upon the mobile’s IMSI, which is 18
assumed to be known at the PCF at the time of A10 establishment. 19
Refer to section 3.17.3 for details of this algorithm. 20
2.17.4 Packet Data Security Considerations 21
The PCF-PDSN interface is designed for use over a protected, private network between 22
the PCFs and the PDSNs. Pre-arranged security associations, in the style of “IP Mobility 23
Support” ([34]) exist among every PCF and PDSN pair that forms an A10 connection. 24
Several potential vulnerabilities exist in the absence of such security associations. If an 25
A10 connection is accessible to an attacker, the GRE encapsulated user traffic may be 26
intercepted and/or spoofed if end-to-end security mechanisms are not in place. Such end-27
to-end security issues are outside the scope of this standard. However, all A11 signaling 28
messages are authenticated to prevent an A10 connection setup and tear down by an 29
unauthorized node. “Mobile-Home Authentication Extension” and “Registration Update 30
Authentication Extension” provide a means of protecting the A11 signaling messages. If 31
registration messages are not authenticated, a denial-of-service attack is possible. If a 32
PCF sends a Registration Request to the PDSN with a spoofed Session Specific 33
Extension, the PDSN would then send an explicit tunnel tear down to the previous PCF, 34
causing user traffic to be misdirected to the new PCF. This would cause a loss of service 35
and possibly interception of traffic, depending on what other security measures are in 36
place. 37
The A8/A9 interfaces are assumed to be supported on a private IP network for security 38
considerations. 39
For details on packet data security, refer to section 3.19.9. 40
3GPP2 A.S0013-0 v2.0
Section 2 28
2.17.5 Version Interoperability Control 1
The architectural assumptions for the A10-A11 interface version control scheme for a 2
communicating PDSN-PCF pair are: 3
• The architectural principle, in [34] on which the A10-A11 interface is based, shall 4
not be violated. 5
• The latest IOS version shall be backward compatible with older supported IOS 6
versions. 7
The structure of the mandatory elements shall not change in revisions of the IOS 8
standard. Refer to section 3.17.6.2 for details of how version control is implemented on 9
the A10/A11 interface. 10
Refer to section 3.17.6.1 for a description of the call flow demonstrating how version 11
control is implemented on the A8/A9 interface. 12
2.17.6 Short Data Bursts 13
cdma2000 defines short data bursts as messages or data associated with a data service 14
that consist of a small number of frames that are transmitted to a mobile with a dormant 15
packet data service instance. Short Data Bursts are not supported across packet zone 16
boundaries. Data may be lost if an MS moves to a new packet zone shortly after 17
transmitting a Short Data Burst (SDB). Mobile terminated data may also be lost if a 18
mobile moves to a new packet zone after a short data burst is sent to the BS/PCF from the 19
PDSN, but before it has been transmitted to the mobile. The BS shall ensure that multiple 20
mobile originated short data bursts from the same mobile shall be sent to the PCF in the 21
order in which they were received from the mobile. 22
Refer to section 3.17.7 for call flows describing this feature. 23
2.17.7 Common Channel Packet Data (CCPD) 24
The Common Channel Packet Data (CCPD) feature supports packet data call setup, 25
dormant mode handoffs, and data transmission using Short Data Bursts over Common 26
Channels. Short Data Bursts are specified in [23]. 27
A CCPD Device is a data-only mobile that doesn’t support traffic channels. Any 28
signaling or data to be exchanged between a CCPD device and the network shall occur 29
over cdma2000 Common Channels. A CCPD capable mobile is a cdma2000 mobile that 30
supports CCPD Mode. A CCPD capable mobile may request CCPD Mode from the 31
network when the amount of data to be transmitted is expected to be small and 32
infrequent. The BS may deny CCPD Mode to a CCPD capable mobile. 33
A CCPD Device or a CCPD Capable mobile operating in CCPD Mode may be referred to 34
as a CCPD mobile. Messages and data exchanged between a CCPD mobile and the 35
network are sent over Common Channels encapsulated within Short Data Bursts. This 36
includes PPP Connection, Mobile IP Registration (if required), and Packet data. For 37
CCPD applications that do not require mobility (telemetry applications for example) 38
Mobile IP Registration is not required and Simple IP may be used. Messages and data 39
exchanged between the PCF and the BS shall be sent over the A9 signaling channel, 40
therefore an A8 bearer connection is not required. CCPD mobiles are authenticated via 41
the ADDS Transfer/ADDS Transfer Ack messages, therefore an SCCP connection is not 42
required to support a CCPD call. 43
3GPP2 A.S0013-0 v2.0
Section 2 29
A CCPD Device requests CCPD Mode from the network by sending an Origination 1
Message to the BS with the SDB_DESIRED_ONLY bit set to 1 and the 2
FCH_SUPPORTED and DCCH_SUPPORTED bits set to 0. Upon successful completion 3
of PPP connection setup and Mobile IP Registration (if required), the mobile’s packet 4
data service instance transitions from the Null/Inactive to Dormant state. A CCPD 5
Device’s packet data service state shall never transition to the Active/Connected state. 6
Upon successful establishment of the packet data session, the CCPD device and network 7
may exchange small amounts of data over common channels. 8
A CCPD capable mobile may request Common Channel Packet Data (CCPD) Service 9
from the network by setting the SDB_DESIRED_ONLY and TCH-SUPPORTED bits in 10
the Origination Message to 1. If the BS agrees to support the mobile’s request for CCPD 11
Mode, PPP connection setup and MIP registration (if required) are performed over 12
common channels using Short Data Bursts. An A8 bearer connection is not required. 13
Upon successful completion of these procedures, the mobile’s packet data service state 14
transitions from the Null to the Dormant State. 15
A CCPD mobile originating a CCPD call setup or CCPD dormant mode handoff shall be 16
authenticated once by the network at the start of the procedure. A CCPD mobile shall not 17
be authenticated again upon subsequent Short Data Burst transmissions in support of the 18
CCPD call setup or CCPD dormant mode handoff procedure. 19
The BS may initiate CCPD Mode for a CCPD capable mobile, even though a CCPD 20
mobile may not have explicitly requested CCPD Mode from the network by setting the 21
SDB_DESIRED_ONLY bit to 1 in the Origination Message. The BS may use this 22
procedure for dormant mode handoffs for example. The BS responds to the Mobile’s 23
Origination Message with a Short Data Burst rather than assigning a traffic channel for 24
the call. Subsequent communication between the MS and the network occurs using Short 25
Data Bursts over Common Channels. 26
For call flows associated with this feature, refer to section 3.17.8. 27
2.18 Voice and Packet Data Concurrent Services 28
Concurrent service means that multiple services (or multiple service option connections) 29
are provided for a user simultaneously. Each instance is established independently. In this 30
version of the standard, this capability provides support for one voice and one 3G packet 31
data service option simultaneously. Other service combinations may be supported by a 32
future release. 33
Upon request from the PDSN (through the PCF) to send data packets to the MS that 34
already has an active voice call, the BS may initiate a packet data call by sending the 35
Additional Service Request message to the MSC. The MSC acknowledges the request by 36
sending the Assignment Request message to the BS. 37
Refer to section 3.18 for call flows associated with this feature. 38
In addition, refer to section 3.2 when clearing all service instances. 39
40
3GPP2 A.S0013-0 v2.0
Section 2 30
2.19 Handoff 1
2
2.19.1 Handoff via MSC 3
Handoffs (both Intra-BS and Inter-BS) can occur for one of several reasons including 4
radio propagation, traffic distribution, OAM&P activity, and equipment failure. Refer to 5
sections 3.17.4, and 3.17.5 for packet data scenarios. 6
Inter-BS Handoff: An Inter-BS handoff is attempted whenever a potential target may be 7
outside of the domain of the source BS. The MSC may optionally use inter-BS hard 8
handoff procedures to perform handoffs where the source BS and target BS are the same. 9
Hard handoff includes inter-MSC hard handoff in which the source BS and the target BS 10
are controlled by different MSCs. 11
Intra-BS Handoff: An intra-BS handoff is a handoff performed under the domain of one 12
BS. As such, the MSC is not involved in the execution of the handoff. Once an intra-BS 13
hard handoff is successfully completed, the BS shall inform the MSC if the old cell is no 14
longer involved in the call. Once an intra-BS soft/softer handoff is successfully 15
completed, the BS shall inform the MSC unless the designated cell concept is used, refer 16
to section 3.19.1.1.3 (Concept of “Designated Cell"). 17
Refer to section 3.19.1 for more information on this type of handoff. 18
2.19.2 Handoff via Direct BS-to-BS Signaling 19
Efficient inter-BS soft handoff is supported via direct BS to BS signaling and traffic 20
connections between base stations. 21
The A3 interface, composed of signaling and user traffic subchannels, provides the ability 22
to establish and remove A3 traffic connections. The A3 interface also provides support 23
for operational procedures, such as turning on/off voice privacy or changing the service 24
configuration of a call. 25
The A7 interface provides direct BS to BS signaling for the support of efficient soft 26
handoff. Only a call release procedure should interrupt any Handoff procedure. Multiple 27
concurrent A7 Handoff Add procedures are prohibited for the same physical channel on 28
the same call. Multiple concurrent A7 Handoff Drop procedures for the same physical 29
channel on the same call are prohibited. 30
Refer to section 3.19.2 for more information on BS-to-BS handoff. 31
2.19.3 Fast Handoff 32
Fast Handoff provides a low interruption packet data service hard handoff mechanism by: 33
1. Maintaining an MS’s PPP session as long as the MS has an active packet data 34
session, and 35
2. Transmitting the forward data stream to the source and target PCFs during the 36
handoff procedures (bicasting). 37
3GPP2 A.S0013-0 v2.0
Section 2 31
The general configuration and nomenclature for Fast Handoff are shown in Figure 2.14.3-1
1. 2
The source BS initiates hard handoff of active packet data service instance(s) by sending 3
a Handoff Required / Handoff Request message to the target BS. Inclusion of the Anchor 4
P-P Address indicates to the target BS that Fast Handoff is requested. The Anchor PDSN 5
is defined to be the PDSN that terminates the PPP connection, and the Anchor P-P 6
Address is the Anchor PDSN’s P-P (PDSN to PDSN) interface IP address. The Handoff 7
Required / Handoff Request messages also include the source PDSN Address and the 8
Anchor PDSN Address. 9
When selecting the target PDSN, the target BS/PCF should use the Anchor PDSN or the 10
source PDSN address provided in the Handoff Request message if possible. Otherwise, 11
the PDSN selection algorithm applies. 12
The target PDSN uses the Anchor P-P Address to establish a P-P connection to the 13
Anchor PDSN for each active packet data service instance. The source (target) PDSN is 14
defined to be the PDSN connected to the source (target) BS/PCF. During Fast Handoff, 15
the Anchor PDSN remains fixed. 16
Source PDSN
A10/A11
Anchor PDSN
MS
A10/A11 A10/A11
Target PDSN
A10/A11
Target BS/PCF
A10/A11 Anchor PDSN Address
Source PDSN Address
Anchor P-P Address
Source BS/PCF
P-P Connection
17
Figure 2.19.3-1 General Configuration Prior to a Fast Handoff. 18
Depending on the handoff situation, any pair of PDSNs among the Anchor, source and 19
target PDSN, or all three of them, may be identical. The target BS recognizes these cases 20
based on comparing the addresses included in the Handoff Request message with each 21
other and with the target PDSN address. For instance: 22
• If no Fast Handoff has taken place previously during the current active phase of the 23
MS, then the Anchor and the source PDSN are identical, and no P-P connection(s) 24
exist prior to the handoff. 25
• If the target BS/PCF can reach the Anchor PDSN, then the target BS/PCF should 26
select the target PDSN to be identical to the Anchor PDSN. 27
• If the target BS/PCF cannot reach the Anchor PDSN, but can reach the source 28
PDSN, then the target BS/PCF should select the target PDSN to be identical to the 29
source PDSN. 30
• If a prior Fast Handoff resulted in P-P connection(s) between the Anchor and the 31
source PDSN, and the target PCF can reach neither the Anchor PDSN nor the source 32
PDSN, then all three PDSNs are distinct. 33
Prior to handing off the MS, the target BS/PCF selects a target PDSN and initiates pre-34
setup of a transmission path between the target BS/PCF and the Anchor PDSN. The 35
3GPP2 A.S0013-0 v2.0
Section 2 32
transmission path between the source BS/PCF and the Anchor PDSN is maintained. Data 1
from the Anchor PDSN is bicasted to the source and the target BS/PCFs. This is shown 2
in Figure 2.19.3-2. 3
Source BS/PCF
Source PDSN
A10/A11
Anchor PDSN
MS
A10/A11 A10/A11
Target PDSN
A10/A11
Target BS/PCF
A10/A11
P-P connection
P-P connection
4
Figure 2.19.3-2 General Configuration During a Fast Handoff, Step 1 5
If the target and source PDSN are identical, but distinct from the Anchor PDSN, then the 6
P-P connection(s) existing prior to the handoff are reused and the data stream(s) are 7
forked at the source PDSN. When the target PDSN is distinct from the source and the 8
Anchor PDSN, new P-P connection(s) are setup between the Anchor and the target 9
PDSN. When the target PDSN is identical to the Anchor PDSN, no new P-P 10
connection(s) are set up. 11
After the MS connects to the target BS, the transmission path between the Anchor PDSN 12
and the source BS/PCF is torn down (except for the P-P connection(s) in the case that the 13
existing P-P connection(s) are reused for the target PDSN). This is shown in Figure 14
2.19.3-3. 15
Source BS/PCF
Source PDSN
Anchor PDSN
MS
Target PDSN
Target BS/PCF
A10/A11
P-P connection
16
Figure 2.19.3-3 General Configuration During a Fast Handoff, Step 2 17
If the target PDSN is the same as the Anchor PDSN, then the Fast Handoff is completed; 18
i.e., the P-P connection(s) are released and no new ones are created. 19
Otherwise, the Fast Handoff stays up until one of the following events occurs: 20
• It is superseded by another Fast Handoff (i.e., the target BS/PCF and target PDSN in 21
Figure 2.14.3-3 becomes the source BS/PCF and source PDSN in Figure 2.14.3-1. 22
• All packet data service instances on the mobile are dormant. Completion of the Fast 23
Handoff entails the target PDSN releasing all P-P connections to the Anchor PDSN, 24
3GPP2 A.S0013-0 v2.0
Section 2 33
which triggers PPP session renegotiation between the target PDSN and the MS. To 1
minimize impact, this is done when the mobile has no active packet data service 2
instances. 3
If a target BS/PCF that does not support Fast Handoff receives a Handoff Request 4
message that requests Fast Handoff, then the basic hard handoff procedures specified in 5
sections 3.17.4 and 3.17.5 apply. 6
Call flows for this feature are provided in section 3.19.4. 7
2.19.4 Hard Handoff into Soft Handoff 8
Hard handoff into (i.e. coincident with) soft handoff can increase the probability of 9
successful handoff of a call. This feature allows the source BS to specify a list of target 10
cells for the handoff, by including these cells in the Cell Identifier List in the Handoff 11
Required message. The cell list is forwarded to the target BS in the Handoff Request 12
message. The target BS decides which cells are included in the handoff, and allocates 13
resources on these cells. The target BS then indicates these cells in the Cell Identifier List 14
of the Handoff Request Ack message, and this cell list is forwarded to the source BS in 15
the Handoff Command message. The source BS directs the mobile to these cells using a 16
handoff direction message. Refer to section 3.1.1.2 for a call flow related to this feature. 17
2.19.5 Intergeneration Packet Data Handoff 18
Intergenerational handoff is defined to be the handoff of a mobile between a system that 19
supports packet data service as specified in [11] to [17] (referred to as “3G” in this 20
section) and a system that supports a packet data service as specified in [10] (referred to 21
as “2G” in this section). Note that packet data service based on the [10] air interface 22
standard is not explicitly supported in this version of the standard. A packet data service 23
session needs to be re-established following an intergeneration packet data handoff. 24
Refer to section 3.19.5 for details on this feature. 25
2.20 Security Features 26
The security features supported by this version of the IOS comprise: 27
• Terminal Authentication, 28
• Signaling Message Encryption, and 29
• Voice/Data Privacy 30
These features are supported using Shared Secret Data (SSD). Shared Secret Data is a 31
128-bit pattern stored in the MS and readily available to the network. This Shared Secret 32
Data is not passed across the air interface between the MS and the network or across the 33
MSC-BS interface. The first 64 bits of the SSD is defined as SSD-A and is used to 34
support the authentication procedures. The last 64 bits of the SSD is defined as SSD-B 35
and is used to support voice/data privacy and signaling message encryption. Air interface 36
procedures are defined to update SSD at the MS. New Shared Secret Data is generated at 37
the HLR/AC, which initiates the SSD update procedure. Invocation of the SSD update 38
procedure is an HLR/AC or OAM&P concern. The SSD update procedure can take place 39
on traffic channels for mobiles capable of authentication and the related security 40
procedures. 41
3GPP2 A.S0013-0 v2.0
Section 2 34
Usually, the entity controlling the authentication in the network initiates the Unique 1
Challenge procedure as specified in the section 3.20.1.2 after an SSD update procedure is 2
completed. 3
2.20.1 Terminal Authentication 4
Terminal Authentication is the process by which information is exchanged between an 5
MS and network for the purpose of confirming the identity of the MS. A successful 6
outcome of the authentication process occurs only when it can be demonstrated that the 7
MS and network possess identical sets of secret provisioning information called Shared 8
Secret Data (SSD). In the case of authentication failure, service providers may deny 9
network access to invalid mobiles and thereby deter fraud. The method involves a 10
common algorithm in the network and MS, and a parameter unique to each MS, and 11
known only to the MS and the network, called the A-key. The common cryptographic 12
authentication algorithms are described in [16] and the interface (input and output 13
parameters) for the algorithms is described in [17]. 14
Furthermore, a second level of security is established called the Shared Secret Data 15
(SSD). The SSD is derived from the A-key and a random challenge (RANDSSD) as 16
described in section 3.20.1.1. The A-key and the SSD are never broadcast across the air 17
interface. Instead, a publicly available random number (RAND) is sent to the MS. The 18
RAND and SSD are used as input to the authentication algorithm at both the MS and the 19
network. The authentication response result (referred to as AUTHR) is computed by the 20
MS and returned to the network. It is compared to the network’s computed result 21
AUTHR. If the results match, the authentication procedure was successful. If 22
authentication procedures fail, the MSC may initiate call clearing per section 3.2.2. 23
Two forms of authentication are available for use with mobiles capable of authentication 24
and the related security procedures. In the first form, the RAND value is broadcast on the 25
forward control/paging channel and common to all mobiles accessing the cell. The 26
mobile computes AUTHR using this RAND, and provides it in its initial access message, 27
which may be a location registration, origination, or page response. Refer to Section 3.1.1 28
for details on the use of this form of authentication for mobile origination and page 29
responses. Also refer to section 3.7. 30
In the second form of authentication, the MSC initiates an explicit authentication 31
procedure, with messaging separate from those used for call setup and registration. The 32
MSC issues a challenge to the MS containing a specific (unique) RANDU value, and the 33
MS responds with its computed AUTHU value. This is referred to as the unique 34
challenge/response procedure, and is described in this section. This procedure is always 35
initiated and controlled by the MSC. The MSC may initiate this procedure at any time on 36
either control or traffic channels. 37
2.20.2 Signaling Message Encryption 38
If provided by the air interface, Signaling Message Encryption (SME) protects certain 39
fields within selected air interface signaling messages. SME enhances the authentication 40
process and protects sensitive subscriber information (e.g. PINs). 41
In order to provide this protection, the relevant device used for the signaling message 42
needs to be loaded with the appropriate key. This is supplied by the MSC over the MSC-43
BS Interface. Refer to the definition of the information element “Encryption Information” 44
in [14]. Signaling Message Encryption cannot be invoked unless broadcast authentication 45
is activated in the system. 46
3GPP2 A.S0013-0 v2.0
Section 2 35
There are no call flows associated with this feature. 1
2.20.3 Voice/Data Privacy 2
If provided by the air interface, voice/data privacy is between the BS and the MS1. In 3
order to provide this protection, the relevant device used for the voice privacy needs to be 4
loaded with the appropriate key. This is supplied by the MSC over the MSC-BS interface. 5
Refer to the definition of the information element “Encryption Information” in [14]. 6
Voice/Data Privacy cannot be invoked unless broadcast authentication is activated in the 7
system. 8
There are no call flows associated with this feature. 9
2.21 Flex Rate 10
Flex Rate provides the user the ability to assign data rates to the MS with greater 11
granularity than previously allowed in cdma2000. In order to use Flex Rate, the MS is 12
required to download a table (or series of tables) from the BS as part of the Non-13
Negotiable Service Configuration Record (NNSCR). The NNSCR contains a mapping of 14
physical channels to tables; the tables contain a 4-bit index to each row and an associated 15
bits-per-frame value. There is a default table that is standardized. In addition, the NNSCR 16
contains a one-bit USE_FLEX_NUM_BITS indicator. To assign a data rate for a data 17
burst, the BS sends a 4-bit index into the table for each Supplemental Channel (SCH) in 18
use (REV_SCH_NUM_BITS_IDX and FOR_SCH_NUM_BITS_IDX). If the Flex Rate 19
indicator (USE_FLEX_NUM_BITS) is ‘0’, the index refers to the standardized table, and 20
this is used to determine the number bits per frame. If USE_FLEX_NUM_BITS is set to 21
‘1’ and the channel is mapped to a table other than the default table, the index and this 22
Flex Rate table are used to determine the bits per frame for this channel and this burst. 23
Since the NNSCR is passed to the target base stations, there is no need to explicitly pass 24
the Flex rate tables or the USE_FLEX_NUM_BITS indicator to the target base stations. 25
If the MS is in soft handoff, and a burst is being assigned using Flex Rate, the index into 26
the Flex Rate table (either REV_SCH_NUM_BITS_IDX or 27
FOR_SCH_NUM_BITS_IDX) shall be passed to the target. For forward bursts, the 28
assigned Flex Rate is transmitted to the target base stations by sending the 29
FOR_SCH_NUM_BITS_IDX in the Forward Supplemental Channel Rate field of the 30
Forward Burst Radio Info element in the A7-Burst Request and A7-Burst Commit 31
messages. For reverse bursts, the assigned Flex Rate is transmitted to the target base 32
stations by sending the REV_SCH_NUM_BITS_IDX in the Reverse Supplemental 33
Channel Rate field of the Reverse Burst Radio Info element in the A7-Burst Request and 34
A7-Burst Commit messages. 35
User data traffic frames sent on the A3 link use the Frame Content field to indicate either 36
the data rate that the frame is to be transmitted at (Forward Link) or the data rate that the 37
frame was received at (Reverse Link). For Flex Rate, the four least significant bits of this 38
field are used to indicate either REV_SCH_NUM_BITS_IDX or 39
FOR_SCH_NUM_BITS_IDX. 40
1 In CDMA systems, all calls are initiated using the public long code mask for PN
spreading. The mobile station user may request voice privacy during call setup using the Origination Message or Page Response Message, and during Traffic Channel operation using the Long Code Transition Request Order. Voice privacy is then provided by transitioning to the private long code mask used for PN spreading
3GPP2 A.S0013-0 v2.0
Section 2 36
2.22 Status Inquiry 1
This procedure is performed on a CDMA Traffic Channel or the CDMA Control Channel 2
to query certain capabilities of the MS. The MSC sends the Status Request message to the 3
BS to instruct the mobile to report certain parameters such as call mode, terminal 4
information, roaming information, security status, etc. For details on the various 5
information records that the MSC may request from MS, refer to [5]. 6
When the MSC sends the Status Request message to the BS, it shall indicate the type of 7
information requested from the mobile. The MSC may include the qualification 8
information of the requested capabilities in the message. Also, the MSC may start timer 9
T3272. The action taken upon the expiration of timer T3272 is implementation dependent. 10
The mobile responds by sending the requested information to the BS. Consequently, the 11
BS responds by sending the Status Response message to the MSC. 12
This operation shall not be applied to DS-41. 13
Refer to section 3.22 for call flows associated with this feature. 14
2.23 3X Multi-Carrier Operation 15
In this standard, 3X Multi-Carrier implementation affects handoff procedures. 3X 16
parameters are required to be properly passed in the handoff messages for the feature to 17
be successfully used. Section 3.23 describes how this feature can be implemented using 18
existing messages and information elements. 19
2.24 5 ms Messaging 20
5 ms messaging allows for faster signaling between the BS and the MS. The only IOS 21
impact is on the A3 traffic frames, which are used to carry the 5 ms messages during soft 22
handoff. Section 3.24 outlines how this feature is implemented. 23
2.25 Enhanced Rate Adaptation Mode (ERAM) 24
Enhanced Rate Adaptation Mode (ERAM) enhances the flexible and variable rate 25
features by using low rate turbo coding schemes. When flexible or variable data rate 26
transmission is used for the Supplemental Channel with turbo codes, low rate turbo codes 27
are used instead of pure code symbol repetition to match the length of the encoder output 28
with the interleaver size of the maximum assigned data rate. By doing this, a performance 29
gain can be achieved due to the inherent low rate coding gain. 30
The source BS indicates the use of ERAM to the target BS (in either a hard handoff or 31
soft handoff scenarios) in the Non-Negotiable Service Configuration IE. To indicate 32
mobile support for this feature, the sender sets the ERAM Supported bit in the IS-2000 33
Mobile Capabilities information element. 34
There are no call flows associated with this feature. 35
2.26 Code Combining Soft Handoff (CCSH) 36
This feature only applies to packet data service. Code Combining Soft Handoff (CCSH) 37
utilizes iterative turbo decoding, which can achieve coding diversity gain in addition to 38
3GPP2 A.S0013-0 v2.0
Section 2 37
the conventional diversity gain during the soft-handoff process. CCSH is a soft handoff 1
method where certain cells encode and transmit the data with the default turbo encoder, 2
whereas other cells use the complementary turbo encoder. The MS combines the code 3
symbols transmitted by each BS for turbo decoding. This is only used for forward link 4
data bursts. 5
The target BS indicates support for this feature to the source BS by setting the CCSH bit 6
in the A3 Connect Information IE of the A3 Connect message. When a supplemental 7
channel is assigned for a data burst, the source BS informs the target BS of the turbo 8
encoder type to be used on the supplemental channel for each cell in the active set by 9
setting the CCSH Encoder Type bit in the Forward Burst Radio Info IE in the Burst 10
Commit message. 11
There are no call flows associated with this feature. 12
2.27 Rescue Channel 13
The Rescue Channel feature supports the use of pre-allocated radio resources at 14
neighboring base stations in order to attempt to recover a voice call in danger of being 15
dropped. An MS disables its transmitter upon detection of a loss of forward frames from 16
the network. Once the source BS detects a loss of transmission from the mobile, it may 17
attempt to re-establish communication with the mobile by performing soft handoff 18
additions to rescue cells at neighboring base stations. These base stations are selected 19
based on the mobile’s neighbor list, last reported EPSMM, and possibly other factors. 20
IOS Rescue Channel procedures require reserved A3 connections be provisioned between 21
the source and target base stations. When the source BS adds a BS to the neighbor list of 22
the mobile, it indicates to the mobile if that neighbor supports a rescue channel. Later, if a 23
call rescue is required, the mobile may autonomously promote the neighbor cell into its 24
active set, and begin to use the pre-allocated rescue channel. 25
Refer to section 3.27 for call flows describing this feature. 26
2.28 Terrestrial Circuit Management 27
This section describes management of terrestrial circuits between MSC and BS and 28
between BS and BS. 29
2.28.1 Terrestrial Circuit Management for the A2/A5 Interface 30
Terrestrial circuits in the context of this section are those DS0 facilities that are used to 31
carry traffic (voice or data) (A2/A5) between the MSC and the BS. 32
The terrestrial circuit management message structures and the information elements in 33
these messages are described in [14]. 34
The following definitions are to be used when considering the condition of a terrestrial 35
circuit: 36
Available The condition of a terrestrial circuit (A2/A5) that is available for 37
selection by the MSC. 38
3GPP2 A.S0013-0 v2.0
Section 2 38
Blocked The condition of a terrestrial circuit (A2/A5) which the BS has 1
identified as out of service, and is therefore not available for selection 2
by the MSC. 3
Idle The condition of a terrestrial circuit (A2/A5) that is not carrying traffic. 4
The idle condition does not imply availability. 5
Refer to section 3.28.1 for more details on this feature. 6
2.28.2 Terrestrial Circuit Management for the A3 Interface 7
This section describes those procedures involved with the management of terrestrial 8
circuits on the A3 interface. Terrestrial circuits in the context of this section are ATM 9
virtual circuits (A3) that are used to carry traffic (voice or data) and signaling information 10
between the SDU and the BTS. 11
The following definitions are to be used when considering the condition of a terrestrial 12
circuit: 13
Available The condition of a virtual circuit connection (A3) that is available for 14
selection by the BTS. 15
Blocked The condition of a virtual circuit connection (A3) which the SDU has 16
identified as out of service, and is therefore not available for selection 17
by the BTS. 18
Idle The condition of a virtual circuit connection (A3) that is not carrying 19
traffic. The idle condition does not imply availability. 20
For call flows associated with this feature, refer to section 3.28.2. 21
2.29 Vocoder Support 22
This version of the IOS supports two vocoder types: 23
• 13K (SO=8000H, 0011H) 24
• EVRC (SO=0003H) 25
Section 3.29 describes the IOS messaging required to support vocoder assignment by the 26
BS. 27
2.30 Features Supported Transparently in this Standard 28
The features included in this section are supported transparently (i.e., can be implemented 29
using existing messages and call flows) by this version of the standard. 30
2.30.1 Emergency Service (Basic) via Specific Dialed Number 31
For E911 Phase 1 and Phase 2, refer to section 2.9. 32
Emergency calls are handled as regular calls by the BS. There is no impact to the Radio 33
Access Network. For basic emergency calls, as specific digit string (e.g. 911) constitutes 34
the dialed digits. Alternatively, the mobile may signal that the call is an emergency call, 35
in which case the Global Emergency Call Indication is used (refer to section 2.8). 36
3GPP2 A.S0013-0 v2.0
Section 2 39
The call flows for this feature are identical to the call flows for a mobile originated call, 1
refer to section 3.1.1. 2
2.30.2 Carrier Access 3
This feature uses carrier access codes as prefixes to the called party number to set up an 4
MS originated call. It is supported transparently by the IOS interfaces (IOS allows up to a 5
total of 32 digits in the Origination Messages). 6
2.30.3 Call Forwarding 7
Call forwarding permits a called subscriber to send incoming calls addressed to the called 8
subscriber’s Directory Number to another Directory Number (forward-to number) or to 9
the called subscriber’s designated voice mailbox. The call forwarding may be done under 10
following conditions: 11
• Unconditional 12
• When Busy 13
• No Answer 14
• Default 15
1. Feature activation: Feature codes are sent in the Called Party BCD Number 16
parameter of the CM Service Request message (refer to [14]) when subscriber 17
initiates actions (e.g. to activate or deactivate Call Forwarding.). 18
2. Feature operation - Incoming calls are forwarded by the MSC; this is transparent to 19
the IOS interfaces. 20
2.30.3.1 Call Forwarding Unconditional (CFU) 21
Call Forwarding Unconditional provides the capability to a subscriber to forward calls 22
regardless of the condition of the termination. 23
For further description, refer to [21]. 24
This feature is transparent to IOS interfaces 25
2.30.3.2 Call Forwarding When Busy (CFB) 26
Call Forwarding When Busy provides the capability to a subscriber to forward calls when 27
the subscriber is busy. 28
For further description, refer to [21]. 29
This feature is transparent to IOS interfaces. 30
2.30.3.3 Call Forwarding - No Answer 31
Call Forwarding When No Answer provides the capability to a subscriber to forward 32
calls when the subscriber fails to answer a call or is otherwise inaccessible (excluding 33
busy). 34
For further description, refer to [21]. 35
3GPP2 A.S0013-0 v2.0
Section 2 40
This feature is transparent to IOS interfaces. 1
2.30.3.4 Call Forward Default 2
Call Forwarding Default provides the capability to a subscriber to forward calls when the 3
subscriber fails to answer a call, is busy or is otherwise inaccessible. 4
For further description, refer to [21]. 5
This feature is transparent to IOS interfaces. 6
2.30.4 Call Delivery 7
Call Delivery allows a subscriber to receive a call to his or her directory number while 8
roaming. 9
For further description, refer to [21]. 10
This feature is transparent to the IOS interfaces. 11
2.30.5 Advice of Charge (AOC) 12
Advice of Charge (AOC) permits a wireless subscriber to receive charging information 13
for telecommunication services. 14
AOC information is presented at the start of a call, during a call, or at the end of a call. 15
AOC information is conveyed to the subscriber within five (5) seconds of the appropriate 16
event (start of call, mid-call charging event, and end of call). 17
AOC information may be presented using visual display, distinctive alerting, audible tone 18
or announcement, or a combination of visual display, distinctive alerting, and audible 19
tone or announcement. 20
This feature is activated according to Feature Activation described in section 2.6.1. 21
AOC information is sent from the MSC to the MS via the BS using Flash with 22
Information messages. 23
There are no call flows are associated with this feature. 24
2.30.6 Call Transfer 25
Call Transfer enables a subscriber to transfer an in-progress established call to a third 26
party. The call to be transferred may be an incoming or outgoing call. 27
Call Transfer allows a controlling subscriber to put a call on hold, dial a third party, then 28
connect the held party and the third party into a call 29
Call Transfer also allows a controlling subscriber, that also has Three-Way Calling 30
(3WC) active, to set up a three-way call and drop out of the call leaving the other two 31
parties of call connected to each other. 32
For further description se [21]. 33
3GPP2 A.S0013-0 v2.0
Section 2 41
This feature is activated according to Feature Activation described in section 2.6.1. 1
The feature is invoked using the Flash with Information messages. 2
There are no call flow is associated with this feature. 3
2.30.7 Lawfully Authorized Wiretap 4
Lawfully Authorized Wiretap means to access communications as an intercept access 5
service. The service fall into four categories: 6
• Non-call associated service to provide information about a subject that is not 7
necessary related to a call. 8
• Call associated service to provide call-identification information about calls 9
involving the intercept subject. 10
• Call associated and non-call associated service to provide subject and network 11
signaling call-identifying information. 12
• Content surveillance services to provide access to an intercept subject’s 13
communication 14
Location support for wiretap is not required, however, location of the wiretap subject 15
may be provided using the most recent Cell ID parameter provided to the MSC. 16
There are no call flows associated with this feature. 17
18
3GPP2 A.S0013-0 v2.0
Section 2 42
1
(This page intentionally left blank.) 2
3
4
5
6
7
3GPP2 A.S0013-0 v2.0
Section 3 43
3.0 Feature Call Flows 1
Refer to [14] to [17] for definitions of messages and timers used in this document. 2
3.1 Call Setup of Voice and Circuit Data Calls 3
Call flows for setup of mobile originated and terminated voice and circuit data calls are 4
described in this section. 5
For details on call clearing call flows, refer to section 3.2. For definitions of timers listed 6
in this section, refer to specific interface documents. 7
3.1.1 Mobile Origination Examples 8
Mobile originated call setup involves exchange of the following MSC-BS messages: 9
• Complete Layer 3 Information with Connection Management (CM) Service Request 10
• Assignment Request 11
• Assignment Failure 12
• Assignment Complete 13
• Progress. 14
3.1.1.1 Mobile Origination 15
This section describes the call flow associated with an MS call origination in the system. 16
3GPP2 A.S0013-0 v2.0
Section 3 44
MS BS MSCtime comment
Origination Message
Base Station Ack Order
a
b
c
d
e
f
Complete L3 Info: CM Service Request
Assignment Request
Channel Assignment Message
Tch Preamble
g
h
BS Ack Order
MS Ack Order
Service Connect Message
Assignment Complete
Ringback Tone
i
k
l
T10
Transparent tosignaling
Service Connect Completionj
T303
1
Figure 3.1.1.1-1 Mobile Origination 2
a. The MS transmits an Origination Message, with Layer 2 Ack required, over 3
the access channel of the air interface to the BS to request service. 4
b. The BS acknowledges the receipt of the Origination Message with a Base 5
Station Acknowledgment Order to the MS. 6
If the BS can determine that resources, e.g., a traffic channel, are not 7
available, the BS may perform the “PACA” call flow described in section 8
3.11. Otherwise, the call is allowed to proceed. 9
c. The BS constructs the CM Service Request message, places it in the Complete 10
Layer 3 Information message, sends the message to the MSC, and starts timer 11
T303. For circuit switched calls, the BS may request the MSC to allocate a 12
preferred terrestrial circuit. 13
If the global challenge is used, the MSC continues the call setup process while 14
waiting for an authentication confirmation. If an authentication failure 15
indication is received at the MSC, it may clear the call. Some in-band 16
treatment may be provided on discretion of the MSC manufacturer, e.g., tone 17
or announcement, assuming the BSC has already done channel assignment. 18
d. The MSC sends an Assignment Request message to the BS to request 19
assignment of radio resources. This message includes information on the 20
terrestrial circuit, if one is to be used between the MSC and the BS. The MSC 21
then starts timer T10. 22
If the BS requested a preferred terrestrial circuit in the CM Service Request 23
message and the MSC can support that terrestrial circuit, the MSC shall use 24
the same terrestrial circuit in the Assignment Request message. Otherwise, the 25
MSC may assign a different terrestrial circuit. 26
3GPP2 A.S0013-0 v2.0
Section 3 45
If the ‘Include Priority’ bit of the Radio Environment and Resources element 1
was set to ‘1’ in the CM Service Request message to indicate that no lower 2
priority channels are available (e.g., when a PACA channel reservation 3
scheme is used) the MSC shall include the actual call priority. 4
Upon receipt of the Assignment Request message from the MSC, the BS stops 5
timer T303. 6
e. If a traffic channel is available for the call, the BS sends a Channel 7
Assignment Message over the paging channel of the radio interface (with the 8
MS address) to initiate the establishment of a radio traffic channel, if the MS 9
is not already on a traffic channel. 10
If for any reason the BS is unable to assign resources (e.g., a traffic channel) 11
for this call and the call is given PACA service, the BS queues the request and 12
notifies the MS of the reason and the current queue position (refer to section 13
3.11). The BS then sends an Assignment Failure message to the MSC with the 14
Cause field set to ‘PACA Call Queued’. The MSC initiates normal call 15
clearing call flow as described in section 3.2.2 to release the underlying 16
transport connection. 17
When a traffic channel becomes available, the BS instructs the MS to re-18
originate the call by sending a PACA Message. 19
f. The MS begins sending the traffic channel preamble (TCH Preamble) over the 20
designated reverse traffic channel. 21
g. Once the BS acquires the reverse traffic channel, it sends the Base Station 22
Acknowledgment Order, with Layer 2 Ack required, to the MS over the 23
forward traffic channel. 24
h. The MS acknowledges the reception of the BS Ack Order by transmitting the 25
Mobile Station Acknowledgment Order and by sending null traffic channel 26
data (Null TCH Data) over the reverse traffic channel. 27
i. The BS then sends the Service Connect Message / Service Option Response 28
Order to the MS specifying the service configuration for the call. The MS 29
begins processing traffic in accordance with the specified service 30
configuration. 31
j. On receipt of the Service Connect Message, the MS responds with a Service 32
Connect Completion Message. 33
k. After the radio traffic channel and circuit have both been established and fully 34
interconnected, the BS sends the Assignment Complete message to the MSC 35
and considers the call to be in conversation state. 36
The MSC stops timer T10 upon receipt of the Assignment Complete message. 37
l. As call progress tone is applied in-band in this case, ringback tone is available 38
on the audio circuit path towards the MS. 39
3.1.1.2 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 40
Assignment into Soft/Softer Handoff 41
This section describes the call flow associated with the mobile origination with the 42
Access Probe Handoff, Access Handoff and Channel Assignment into Soft Handoff using 43
the source BS (the BS on which the first probe was sent). The same technique applies to 44
the mobile termination case. 45
3GPP2 A.S0013-0 v2.0
Section 3 46
The access handoff, access probe handoff, and channel assignment into soft handoff 1
functions shown in the following diagram are not all necessarily required for each call 2
setup. The diagram gives an example of a call where all three are used, but that is not the 3
case for all calls. In this section, “A3-CEData Forward/Reverse” messages represent 4
“A3-IS-95 FCH Forward/Reverse”, “A3-IS-2000 FCH Forward/Reverse”, or “A3-IS-5
2000 DCCH Forward/Reverse” messages. 6
3GPP2 A.S0013-0 v2.0
Section 3 47
Origination Message (II)
x
MSSource
BSMSC
time comment
a
c
e
f
g
h
T303
Base Station Ack Order
b
d
TargetBS-1
TargetBS-2
TargetBS-3
xOrigination Message (I)
A7-Access Channel Message Transfer
A7-Access Channel Message Transfer Ack
Tacm
A7-Handoff Request
Complete L3 Info: CM Service Request
A3-Connect
l
j
i
Tconn3
A3-CEData Forward
k
A3-CEData Reverse
A3-Traffic Channel Status
Tchanstat
mA7-Handoff Request Ack
A3-Connect Ack
Thoreq
nOrigination Message (III)
oBase Station Ack Order
q
pA7-Access Channel Message Transfer
A7-Access Channel Message Transfer Ack
Tacm
Assignment Request
s
A7-Paging Channel Message Transfer
r
xx
x
Extended Channel Assignment Message
t
u
Pilot Preamble T10
Source BS wasattempted first
Access probe handoffto target BS-1
Access probe handoffto target BS-2
Access probehandoff ends
Access handoff totarget BS-3
SCENARIO CONTINUESNEXT PAGE
These messages areused to set up softhandoff legs forchannel assignmentinto soft handoff.
1
Figure 3.1.1.2-1 Mobile Origination with Access Probe Handoff, Access Handoff and Channel 2
Assignment into Soft/Softer Handoff 3
3GPP2 A.S0013-0 v2.0
Section 3 48
MS Source
BS MSC
time comment
v
x
z
Base Station Ack Order
w
y
Target BS-1
Target BS-2
Target BS-3
Assignment Complete
T10
SCENARIO CONTINUED FROM PREVIOUS PAGE
MS Ack Order
Service Connect Message
Service Connect Completion Message
aa Handoff Performed
1
Figure 3.1.1.2-1 (Cont.) Mobile Origination with Access Probe Handoff, Access Handoff and Channel 2
Assignment into Soft/Softer Handoff 3
a. The MS transmits an Origination Message (Origination (I)), with Layer 2 Ack 4
required, over the access channel of the air interface to the source BS to 5
request service. Because this BS is the first to which the MS sends an access 6
probe, it becomes by definition the source BS for this call setup attempt. In 7
this message the MS reports the pilot strength of all the pilots in the MS’s 8
Paging Channel Active Set. It also reports other pilots using the 9
ACCESS_HO_LIST and the OTHER_REPORTED_LIST (refer to [1] to [6]). 10
This message is not received by the source BS. 11
b. The MS performs an access probe handoff and sends a second Origination 12
Message (Origination (II)), with Layer 2 Ack required, over the access 13
channel of the air interface to the target BS-1 to request service. Note that the 14
target BS-1 may not have been in the ACCESS_HO_LIST in step a. 15
c. The target BS-1 acknowledges the receipt of the Origination Message with a 16
Base Station Acknowledge Order to the MS. The BS Ack Order is not 17
received by the MS. 18
d. The target BS-1 recognizes that it is not the first accessed BS and encapsulates 19
the Origination Message received from the MS in the A7-Access Channel 20
Message Transfer message and forwards it to the source BS instead of sending 21
the CM Service Request message to the MSC. The target BS-1 starts timer 22
Tacm. 23
e. The source BS acknowledges the A7-Access Channel Message Transfer 24
message by sending an A7-Access Channel Message Transfer Ack message to 25
the target BS-1. The target BS-1 stops timer Tacm. 26
f. The source BS constructs the CM Service Request message, places it in the 27
Complete Layer 3 Information message, sends the message to the MSC, and 28
starts timer T303. The BS may request the MSC to allocate a preferred 29
terrestrial circuit. 30
g. Since the Origination Message to the source BS carries the pilot report of 31
other strong pilots, the source BS initiates the inter-BS soft handoff setup 32
procedure by sending the A7-Handoff Request message to one or more target 33
BSs. (In this example scenario, the source BS chooses target BS-1 target BS-2 34
and target BS-3). The source BS starts an instance of timer Thoreq for each A7 35
Handoff Request message sent. Alternatively, the initiation of soft handoff 36
3GPP2 A.S0013-0 v2.0
Section 3 49
may be performed after receiving the Assignment Request message from the 1
MSC. 2
h. The target BSs initiate A3 connections by sending A3-Connect messages to 3
the specified address. Each target BS starts an instance of timer Tconn3. 4
i. The source BS replies with A3-Connect Ack messages to complete the A3 5
connections. Target BSs stop timer Tconn3. The source BS starts an instance of 6
timer Tchanstat for each A3 Connect Ack message sent if the source BS 7
requests to receive A3-Traffic Channel Status messages from the target BSs. 8
j. The source BS begins to send idle forward frames to the target BSs. 9
k. The target BSs begin to send reverse idle frames as soon as the first forward 10
frame is received from the source BS. The reverse frames contain the timing 11
adjustment information necessary to achieve synchronization. 12
l. If the source BS has chosen to be notified of the start of transmission and 13
reception at the target BSs, when its SDU function and the target BSs have 14
synchronized the A3 traffic subchannel, the target BS replies with an A3-15
Traffic Channel Status message. Note that this step can occur any time after 16
step (i). The source BS stops Tchanstat timers. 17
m. Target BS-1, target BS-2 and target BS-3 send A7-Handoff Request Ack 18
messages to the source BS to complete the soft handoff setup procedure. Note 19
that this message can be sent at any time following the receipt of the A3-20
Connect Ack messages at each target BS. The source BS stops Thoreq timers. 21
n. The MS did not receive the Layer 2 Ack in response to the Origination 22
Message at step c; therefore, it performs an access probe handoff to target BS-23
2, and sends a third Origination Message (Origination (III)) with the first 24
accessed BS identified and with Layer 2 Ack required. 25
Note that the ACCESS_HO_LIST identifies the source BS as the first 26
attempted, and that target BS-1 and target BS-2, which may not have been 27
included in the ACCESS_HO_LIST in step a, are included in the 28
ACCESS_HO_LIST in this step. 29
o. Target BS-2 responds with a Base Station Ack Order to the MS. The MS 30
receives the Base Station Ack Order, which successfully completes the access 31
attempt. 32
p. The target BS-2 recognizes that it is not the first accessed BS (i.e., the source 33
BS) and encapsulates the Origination Message received from the MS in the 34
A7-Access Channel Message Transfer message and forwards it to the source 35
BS instead of sending the CM Service Request message to the MSC. The 36
target BS-2 starts timer Tacm. 37
q. The source BS acknowledges the A7-Access Channel Message Transfer 38
message by sending an A7-Access Channel Message Transfer Ack message to 39
the target BS-2. 40
The source BS upon receiving the Origination Message from the target- BS-2 41
for the same MS and the same call may send a second CM Service Request to 42
the MSC, though this option is not shown in this example. Upon receipt of the 43
A7-Access Channel Message Transfer Ack message the target BS-2 stops 44
timer Tacm. 45
r. The MSC sends an Assignment Request message to the source BS to request 46
assignment of radio resources. This message includes information on the 47
terrestrial circuit, if one is to be used between the MSC and the BS. The MSC 48
3GPP2 A.S0013-0 v2.0
Section 3 50
then starts timer T10. Upon receipt of the Assignment Request message from 1
the MSC, the BS stops timer T303. This step may occur any time after step f. 2
s. After receiving the Assignment Request message from the MSC and 3
optionally receiving A3-Connect messages from the potential target BSs, the 4
source BS constructs an air-interface Extended Channel Assignment message 5
and forwards it in the A7-Paging Channel Message Transfer message to one 6
or more base stations, usually chosen from those that are in the 7
ACCESS_HO_LIST and OTHER_REPORTED_LIST (which may not be the 8
same BSs set up in soft handoff). The A7-Paging Channel Message Transfer 9
message may be sent any time after the A3 Connections are completed. 10
t. The source BS and target BSs send the appropriate channel assignment 11
message over the air to the MS. The probability of the MS receiving this 12
message is substantially increased by sending this message from multiple base 13
stations. In the meantime, the MS has performed an access handoff to target 14
BS-3. Since the MS is listening to the paging channel of only one BS, it does 15
not receive the Extended Channel Assignment Message from any other BSs 16
than target BS-3. At any time after sending/receiving the A7-Paging Channel 17
Message Transfer message, all soft handoff legs on the source BS and target 18
BS begin sending null forward traffic frames to the MS. 19
u. After receiving the Extended Channel Assignment Message from the target 20
BS-3 and the forward traffic frames from one or more base stations, the MS 21
starts sending the traffic frames or preambles. 22
In steps v through y, the full activity of the messaging between the source BS 23
and the MS via the target BSs using A3-CEData Forward and A3-CEData 24
Reverse messages and transmission and reception of messages to and from the 25
MS by the target BSs is not shown for simplicity in the diagram. 26
v. If a target BS detects reverse preamble, it sends it to the source BS in an A3-27
CEData Reverse message. Once the source BS acquires the reverse traffic 28
channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack 29
required, to the MS over the forward traffic channel. The source BS also 30
informs the target BSs that the reverse traffic channel was acquired by starting 31
to send non-idle frame content type in the A3-CEData Forward messages. 32
Upon receiving non-idle frame content in the A3-CEData Forward messages, 33
the target BS terminates any attempts to send the channel assignment message 34
to the MS. 35
w. The MS acknowledges the reception of the BS Ack Order by transmitting the 36
Mobile Station Acknowledgment Order and by sending null traffic channel 37
data (Null TCH Data) over the reverse traffic channel. 38
x. The source BS then sends the Service Connect Message / Service Option 39
Response Order to the MS specifying the service configuration for the call. 40
The MS begins processing traffic in accordance with the specified service 41
configuration. 42
y. On receipt of the Service Connect Message, the MS responds with a Service 43
Connect Completion Message. 44
z. The source BS sends the Assignment Complete message to the MSC. At this 45
time, the MS is on the traffic channel and the call setup into soft/softer 46
handoff is completed successfully. MSC stops timer T10. At this time, the MS 47
is setup directly in soft/softer handoff with one or more base stations. 48
aa. The source BS may send a Handoff Performed message to the MSC as 49
explained in section 3.19.1.1.3 “Concept of A "Designated Cell.” 50
3GPP2 A.S0013-0 v2.0
Section 3 51
3.1.2 Mobile Termination Examples 1
Mobile terminated call setup involves exchange of the following MSC-BS messages: 2
• Paging Request 3
• Complete Layer 3 Information with Paging Response 4
• Assignment Request 5
• Assignment Complete 6
• Assignment Failure 7
• Alert with Information 8
• Connect. 9
3.1.2.1 Mobile Termination 10
This section describes the call flow associated with an MS call termination in the system. 11
Base Station Ack Order
MS BS MSCtime comment
Page Response Message c
d
e
f
g
h
i
j
Complete L3 Info: Paging Response
Assignment Request
Channel Assignment Message
Tch Preamble
k
m
BS Ack Order
MS Ack Order
Service Connect Message
Assignment Complete
T10
Connect
p
r
Page Messageb
aPaging Request
n
o
Alert with Info
MS Ack Order
Connect Order
qBS Ack Order
T301
T3113
T303
Service Connect Completionl
12
Figure 3.1.2.1-1 Mobile Termination 13
a. The MSC determines that an incoming call terminates to a mobile within its 14
serving region and sends the Paging Request message to the BS to initiate a 15
mobile terminated call setup scenario. The MSC then starts timer T3113. 16
3GPP2 A.S0013-0 v2.0
Section 3 52
b. The BS issues a Page Message containing the MS address over the paging 1
channel. 2
c. The MS acknowledges the page by transmitting a page response message over 3
the access channel. 4
d. The BS constructs the Paging Response message, places it in the Complete 5
Layer 3 Information message, sends the message to the MSC, and starts timer 6
T303. The BS may request the MSC to allocate a preferred terrestrial circuit. 7
The MSC stops timer T3113 upon receipt of the Paging Response message 8
from the BS. 9
e. The BS acknowledges the receipt of the Page Response Message from the MS 10
with a Base Station Acknowledgment Order to the MS. 11
f. The MSC sends an Assignment Request message to the BS to request 12
assignment of radio resources. This message also includes terrestrial circuit if 13
one is to be used between the MSC and the BS. The MSC then starts timer 14
T10. 15
If the BS requested a preferred terrestrial circuit in the Paging Response 16
message and the MSC can support that terrestrial circuit, the MSC shall use 17
the same terrestrial circuit in the Assignment Request message. Otherwise, the 18
MSC may assign a different terrestrial circuit. 19
Upon receipt of the Assignment Request message from the MSC, the BS stops 20
timer T303. 21
g. The BS sends a Channel Assignment Message over the control channel of the 22
radio interface (with the MS address) to initiate the establishment of a radio 23
traffic channel, if the MS is not already on a traffic channel. 24
h. The MS begins sending the traffic channel preamble (TCH Preamble) over the 25
designated reverse traffic channel. 26
i. Once the BS acquires the reverse traffic channel, it sends the Base Station 27
Acknowledgment Order, with Layer 2 Ack required, to the MS over the 28
forward traffic channel. 29
j. The MS acknowledges the reception of the BS order by transmitting the 30
Mobile Station Acknowledgment Order. 31
k. The BS then sends the Service Connect Message / Service Option Response 32
Order to the MS specifying the service configuration for the call. The MS 33
begins processing traffic in accordance with the specified service 34
configuration. 35
l. On receipt of the Service Connect Message, the MS responds with a Service 36
Connect Completion Message. 37
m. After the radio traffic channel and circuit have both been established, the BS 38
sends the Assignment Complete message to the MSC. 39
The MSC stops timer T10 upon receipt of the Assignment Complete message 40
from the BS, and starts timer T301. 41
n. The BS sends the Alert with Information Message to the MS to cause ringing 42
at the MS. 43
o. The MS acknowledges the reception of the Alert with Information Message 44
by transmitting the Mobile Station Acknowledgment Order. 45
3GPP2 A.S0013-0 v2.0
Section 3 53
p. When the call is answered at the MS, a Connect Order, with acknowledgment 1
required, is transmitted to the BS. 2
q. The BS acknowledges the Connect Order with the Base Station 3
Acknowledgment Order over the forward traffic channel. 4
r. The BS sends a Connect message to the MSC to indicate that the call has been 5
answered at the MS. At this point, the call is considered stable and in the 6
conversation state. 7
The MSC stops timer T301 upon receipt of the Connect message from the BS. 8
3.1.2.2 Mobile Termination, Assignment Retry 9
This section describes the call flow diagram when channel assignment is retried between 10
the BS and MSC interface for a mobile terminated call. 11
MS BS MSCtime comment
Page Response Message
Base Station Ack Order
c
d
e
Complete L3 Info: Paging Response
Page Messageb
aPaging Request
T3113
h
i
j
k
l
Assignment Request
Channel Assignment Message
Tch Preamble
m
o
BS Ack Order
MS Ack Order
Service Connect Message
Assignment Complete
T10
Connect
r
t
p
q
Alert with Info
MS Ack Order
Connect Order
sBS Ack Order
T301
fAssignment Request
gAssignment Failure T10
T20
Service Connect Completionn
T303
12
Figure 3.1.2.2-1 Mobile Termination: Assignment Retry 13
3GPP2 A.S0013-0 v2.0
Section 3 54
a The MSC determines that an incoming call terminates to a mobile within its 1
serving region and sends the Paging Request message to the BS to initiate a 2
mobile terminated call setup scenario. The MSC starts timer T3113. 3
b. The BS issues a Page Message containing the MS address over the paging 4
channel. 5
c. The MS acknowledges the page by transmitting a Page Response Message 6
over the access channel. 7
d. The BS constructs the Paging Response message, places it in the Complete 8
Layer 3 Information message, sends the message to the MSC, and starts timer 9
T303. The BS may request the MSC to allocate a preferred terrestrial circuit. 10
The MSC stops timer T3113 upon receipt of the Paging Response message 11
from the BS. 12
e. The BS acknowledges the receipt of the Page Response Message from the MS 13
with a Base Station Acknowledgment Order over the air interface. 14
f. The MSC sends an Assignment Request message to the BS to request 15
assignment of radio resources. This message also includes terrestrial circuit, if 16
one is to be used, between the MSC and the BS. The MSC then starts timer 17
T10. 18
If the BS requested a preferred terrestrial circuit in the Paging Response 19
message and the MSC can support that terrestrial circuit, the MSC shall use 20
the same terrestrial circuit in the Assignment Request message. Otherwise, the 21
MSC may assign a different terrestrial circuit. 22
The BS stops timer T303 upon receipt of the Assignment Request message. 23
g. In this example, the BS recognizes that the assignment cannot be completed, 24
(e.g., the requested terrestrial circuit is not available) and sends the 25
Assignment Failure message to the MSC. The BS then starts timer T20. 26
The MSC stops timer T10 upon receipt of the Assignment Failure message 27
from the BS. 28
h. The MSC retries by sending an Assignment Request message to the BS to 29
request assignment of radio resources. This message also includes a different 30
terrestrial circuit to be used between the MSC and the BS, if one is needed for 31
the call. The MSC restarts timer T10. 32
Upon receipt of the retry of the Assignment Request message, the BS stops 33
timer T20. In this example, it is assumed that this second Assignment Request 34
message is acceptable to the BS. The BS connects the traffic channel to the 35
designated terrestrial circuit. 36
i. The BS sends a Channel Assignment Message over the paging channel of the 37
radio interface (with the MS address) to initiate the establishment of a radio 38
traffic channel, if the MS is not already on a traffic channel. 39
j. The MS begins sending the traffic channel preamble (TCH Preamble) over the 40
designated reverse traffic channel. 41
k. Once the BS acquires the reverse traffic channel, it sends the Base Station 42
Acknowledgment Order, with Layer 2 Ack required, to the MS over the 43
forward traffic channel. 44
l. The MS acknowledges the reception of the Base Station Acknowledgment 45
Order by transmitting the Mobile Station Acknowledgment Order. 46
3GPP2 A.S0013-0 v2.0
Section 3 55
m. The BS then sends the Service Connect Message / Service Option Response 1
Order to the MS specifying the service configuration for the call. The MS 2
begins processing traffic in accordance with the specified service 3
configuration. 4
n. On receipt of the Service Connect Message, the MS responds with a Service 5
Connect Completion Message. 6
o. After the radio traffic channel and circuit have both been established, the BS 7
sends the Assignment Complete message to the MSC 8
Upon receipt of the Assignment Complete message, the MSC stops timer T10, 9
and starts timer T301. 10
p. The BS sends the Alert with Information Message to the MS to cause ringing 11
at the MS. 12
q. The MS acknowledges the reception of the Alert with Information Message 13
by transmitting the Mobile Station Acknowledgment Order. 14
r. When the call is answered at the MS, a Connect Order, with acknowledgment 15
required, is transmitted to the BS. 16
s. The BS acknowledges the Connect Order with the Base Station 17
Acknowledgment Order over the forward traffic channel. 18
t. The BS sends a Connect message to the MSC to indicate that the call has been 19
answered at the MS. 20
Upon receipt of the Connect message from the BS, the MSC stops timer T301. 21
3.2 Call Clearing of Voice and Circuit Data Calls 22
There are two types of clearing call flows over the A1 interface: 23
1. Call clearing for a single service that is not the only one connected. 24
2. Call clearing of all services connected (including the case where only one 25
service is connected). 26
Call clearing may be initiated by either the Base Station, the MS, the PDSN/PCF, or the 27
MSC. 28
3.2.1 Call Clearing Initiated by the MS or BS 29
Call clearing may be initiated by packet data call flows; refer to section 3.17. 30
When the MS initiates a normal clearing of a single service that is not the only service 31
connected, the MS sends one of the Service Request Message (SRQM), Resource Release 32
Request Message (RRRM) or Resource Release Request Mini Message (RRRMM). The 33
BS shall send a Service Release message to the MSC and starts timer T308 to wait for the 34
Service Release Complete message from the MSC. This scenario is illustrated in section 35
3.18.4.1. 36
When the MS initiates a normal clearing of all services including the only service 37
connected, the MS sends a Release Order to the BS. The BS shall send a Clear Request 38
message to the MSC and start timer T300 to wait for the Clear Command message from 39
the MSC. For packet data calls, call clearing does not normally clear the service session. 40
3GPP2 A.S0013-0 v2.0
Section 3 56
The service session is cleared using call flows in this section for conditions such as MS 1
power down, termination of the PPP session by the mobile or the network, etc. 2
The MSC is responsible for clearing A1, A2, and/or A5 connections associated with the 3
call. To release all allocated resources associated with all services, the MSC shall send a 4
Clear Command message to the BS. The BS responds with a Clear Complete message 5
and stop timer T300. The call flow scenarios are illustrated in section 3.2.4.3. 6
If the MS is not active (powered off) or if for any reason the radio channel failed between 7
the MS and the BS or if some internal BS failure occurs, then the BS initiates call 8
clearing. The BS sends a Clear Request message to the MSC. The MSC responds with a 9
Clear Command message to the BS and waits for a Clear Complete message from the BS. 10
The scenario is illustrated in section 3.2.4.2. 11
Refer to [14] for unsuccessful call clearing procedures related to the Service Release, 12
Clear Request and Clear Command messages. 13
3.2.2 Call Clearing Initiated by the MSC 14
When the MSC chooses to deny call set up initiated by the reception of a CM Service 15
Request or Paging Response message contained in a SCCP Connection Request, the 16
MSC may send a SCCP Connection Refused containing no user data. 17
3.2.2.1 Scenario 1 - Clear from the Network 18
When the MSC initiates a normal clearing of a single service that is not the only service 19
connected, the MSC sends a Service Release message to the BS and starts timer T308 to 20
wait for a Service Release Complete message from the BS. This normal call clearing 21
scenario is illustrated in section 3.13.18.4.2. 22
In case the MSC initiates a normal clearing of all services including the only one 23
connected, the MSC shall send a Clear Command message to the BS and wait for a Clear 24
Complete message from the BS. This normal call clearing scenario is illustrated in 25
section 3.2.4.3. 26
3.2.2.2 Call clearing via Clear Command 27
If call clearing is initiated by the MSC, the MSC shall send a Clear Command message to 28
the BS, start timer T315, and wait for a Clear Complete message from the BS. Timer T315 29
is stopped when the Clear Complete message is received. This normal call clearing 30
scenario is illustrated in section 3.2.4.3. 31
3.2.2.3 Call Clearing when Tones/Announcements are Provided 32
Call clearing messages are not affected if the network provides either tones or 33
announcements immediately before clearing a call. 34
3.2.3 Call Clearing Collision 35
Call clearing collision occurs in the following cases: 36
1. The BS sends a Clear Request message and the MSC simultaneously sends a 37
Clear Command message. 38
3GPP2 A.S0013-0 v2.0
Section 3 57
When the MSC receives the Clear Request message, it shall note it and continue to wait 1
for the Clear Complete message. When the BS receives the Clear Command message, it 2
shall complete the call clearing. 3
2. The BS and MSC simultaneously send Service Release messages and each 4
Service Release message contains the same Service Option Connection 5
Identifier (SOCI). 6
When the MSC receives the Service Release message, it shall note it and continue to wait 7
for a Service Release Complete message. When the BS receives the Service Release 8
message, stop timer T308 and send a Service Release Complete message to the MSC. 9
3. The BS and MSC simultaneously send Service Release messages and each 10
Service Release message contains different SOCI. 11
When the MSC receives the Service Release message and the MSC realizes that all 12
services are being released, ,the MSC sends the Clear Command message to the BS and 13
start timer T315. When the BS receives the Clear Command message it stops timer T308 14
and shall proceed with the normal call clearing call flows as in 3.2.4.3.1. 15
4. The BS sends a Service Release message and the MSC simultaneously sends a 16
Clear Command message. 17
When the BS receives the Clear Command message, it shall complete the clearing of all 18
services including the only one connected and send a Clear Complete message to the 19
MSC. The BS then stops timer T308. When the MSC receives the Service Release 20
message, it shall note it and continue to wait for a Clear Complete message. 21
5. The BS sends a Clear Request message and the MSC simultaneously sends a 22
Service Release message 23
When the MSC receives the Clear Request message, it shall send a Clear Command 24
message and stop timer T308. The MSC starts timer T315 to wait for a Clear Complete 25
message. When the BS receives the Service Release message, it shall note it and continue 26
to wait for a Clear Command message. 27
3.2.4 Call Flow Diagrams for Call Clear Operation 28
The following subsections provide the call flow diagrams for call clearing operations. 29
3.2.4.1 Call Clear via Clear Request (MS Initiated) 30
In this example, when the MS initiates call clearing by sending a Release Order to the 31
BS, the BS sends a Clear Request message to the MSC and waits to receive a Clear 32
Command message. 33
3GPP2 A.S0013-0 v2.0
Section 3 58
MS MSCtime comment
Release Ordera
b
c
d
Clear Request
Clear Command
Clear Complete
Release Order
T300
T315
e
BS
1
Figure 3.2.4.1-1 Call Clear Initiated by MS 2
a. The MS initiates call clearing by transmitting a Release Order over the reverse 3
traffic channel. 4
b. The BS then sends the Clear Request message to the MSC to initiate the call 5
clear transaction. Timer T300 is started by the BS. 6
c. The MSC sends a Clear Command message to the BS to instruct the BS to 7
release the associated dedicated resource (such as terrestrial circuit) and starts 8
timer T315. The BS stops timer T300. 9
d. In response to the Clear Command message, the BS releases the terrestrial 10
circuit, if allocated. The BS then acknowledges the MS by sending it a 11
Release Order over the forward traffic channel and releases the radio resource. 12
e. The BS then returns a Clear Complete message to the MSC. The MSC stops 13
timer T315 upon receipt of the Clear Complete message. The MSC releases the 14
underlying transport connection. 15
3.2.4.2 Call Clear via Clear Request (BS Initiated) 16
In this example, when there is a radio channel failure or the MS is not active, the BS 17
initiates call clearing by sending a Clear Request message to the MSC. 18
MS BS MSCtime comment
a
b
c
Clear Request
Clear Command
Clear Complete
T300
T315
19
Figure 3.2.4.2-1 Call Clear Initiated by BS (via Clear Request) 20
a. In this case of a radio channel failure between the MS and the BS, or if the 21
MS is not active, the BS sends a Clear Request message to the MSC. The BS 22
starts timer T300 and waits for the Clear Command from the MSC 23
3GPP2 A.S0013-0 v2.0
Section 3 59
b. The MSC sends a Clear Command message to instruct the BS to release the 1
associated dedicated resource (such as terrestrial circuit) and starts timer T315. 2
The BS stops timer T300. 3
c. The BS then returns a Clear Complete message. 4
The MSC stops timer T315 upon receipt of the Clear Complete message and 5
releases the underlying transport connection. 6
3.2.4.3 Call Clear via Clear Command 7
In this example, the MSC initiates call clearing by using the Clear procedure (Clear 8
Command and Clear Complete messages). 9
MS MSCtime comment
b
c
Clear Command
Clear Complete
Release Order
Release Order
a
d
T315
BS
10
Figure 3.2.4.3-1 Call Clear Initiated by MSC (via Clear Command) 11
a. The MSC sends a Clear Command message to the BS to instruct the BS to 12
release the associated dedicated resource and starts timer T315. 13
b. The BS initiates call clearing over the air interface by transmitting a Release 14
Order over the forward traffic channel. 15
c. The MS acknowledges the Release Order by returning a Release Order over 16
the reverse traffic channel. 17
d. The BS then returns a Clear Complete message. The MSC stops timer T315 18
upon receipt of the Clear Complete message and releases the underlying 19
transport connection. 20
3.3 TFO Support 21
This section describes call flows associated with Tandem Free Operation. Refer to 22
section 2.3 for more description of this feature. 23
3.3.1 Scenario Diagram 24
Figure 3.3.1-1 shows the Transcoder Control call flow. 25
3GPP2 A.S0013-0 v2.0
Section 3 60
Time
a
b
BS MSC
Transcoder Control Acknowledge
Transcoder Control Request
T309
Comment
1
Figure 3.3.1-1 Transcoder Control Call Flow 2
a. The MSC sends a Transcoder Control Request message to enable or disable 3
the inband signaling mechanism at the BS. If the inband signaling mechanism 4
is already enabled and the call is not in the TFO Operation state, an enable 5
directive simply resets the inband signaling state machine logic. Timer T309 is 6
started by the MSC. 7
b. Upon receipt of the Transcoder Control Request message, the BS sets the 8
inband signaling mechanism to the appropriate state and returns a “success” 9
Transcoder Control Acknowledge message if TFO operation was successfully 10
enabled/disabled. A failure acknowledgement is sent if the BS is unable to 11
accomplish the Transcoder Control Request. The MSC stops timer T309. 12
3.4 Test Calls 13
Test calls initiated by the MS use the call flows described in section 3.1.1. Test calls 14
initiated by the MSC use the call flows described in section 3.1.2. 15
3.5 Support of DTMF 16
This feature is supported using existing call flows. 17
3.6 Support of Supplementary Services 18
The following subsections contain call flows demonstrating the procedures for supporting 19
Supplementary Services. Refer to section 2.6 for overview descriptions of these features. 20
The features defined in [21] generally involve transactions between the MSC and the MS. 21
The required information is passed through the BS using the following messages: 22
• Flash with Information 23
• Flash with Information Ack 24
• Feature Notification 25
• Feature Notification Ack 26
• CM Service Request 27
• Assignment Request 28
• Assignment Complete 29
• Clear Command 30
• Clear Complete. 31
3GPP2 A.S0013-0 v2.0
Section 3 61
3.6.1 Feature Activation and Deactivation 1
The sections below indicate the call flows used to handle feature activation and 2
deactivation both when the MS is idle and is in a call. 3
3.6.1.1 Feature Activation/Deactivation in Idle Mode 4
Refer to section 3.1.1 for call flows associated with this feature. 5
3.6.1.2 Feature Activation/Deactivation While in a Call 6
7
MS BS MSCtime comment
aFlash with Information
c
b
In-Band information
Flash with Information
8
Figure 3.6.12-1 Feature Activation/Deactivation While in a Call 9
a. The MS sends a Flash with Information message to the BS to pass a string of 10
digits and end marks to request feature activation/deactivation. 11
b. The BS places the string of digits and end marks in a Flash with Information 12
message and sends it to the MSC. 13
c. The MSC generates in-band tones or announcements. 14
3.6.2 Call Waiting 15
This section provides the call flow description for the call waiting feature. 16
3GPP2 A.S0013-0 v2.0
Section 3 62
MS BS MSCtime comment
b
c
e
f
Flash with Information
aFlash with Information
d
Flash with Information
Flash with Information
Flash with Information
Flash with Information
1
Figure 3.6.2-1 Call Waiting 2
a. The MSC sends a Flash with Information message to the BS to alert the MS 3
that there is a call waiting. 4
b. The BS takes the information from the MSC and sends a Flash with 5
Information message to the MS. 6
c. The MS sends the Flash with Information message to the BS to indicate the 7
acceptance of the second call. 8
d. The BS sends a Flash with Information message to the MSC. The MSC then 9
places the original call on hold and connects the second call to the MS. 10
e. To toggle between the two callers, the MS sends the Flash with Information 11
message to the BS. 12
f. The BS sends a Flash with Information message to the MSC. The MSC then 13
places the second call on hold and reconnects the original call to the MS. 14
The MSC may optionally apply an inband tone to alert the user of a waiting call. Such an 15
action would take the place of or supplement steps (a) and (b) above. 16
If an MS releases an active call after receiving call waiting notification, and while a call 17
is waiting, the active call is cleared using normal call release call flows as described in 18
Section 3.2.4.3, and the waiting call is offered using normal mobile termination call 19
flows, as described in Section 3.1.2. 20
If an MS releases the active call while another call is held (by the Call Waiting feature), 21
the active call is cleared using normal call release call flows as described in Section 22
3.2.4.2, and the held call is offered using normal mobile termination call flows, as 23
described in Section 3.1.2. 24
3.6.3 Three Way Calling 25
3.6.3.1 Three-Way Calling – (Method 1) 26
This section provides the call flow description for the Three-Way Calling feature 27
(Method 1). 28
3GPP2 A.S0013-0 v2.0
Section 3 63
MS BS MSCtime comment
a
bFlash with Information
Flash with Information
c
dFlash with Information
Flash with Information (2nd party called address)
e
fFlash with Information
Flash with Information
g
hFlash with Information
Flash with Information
1
Figure 3.6.3.1-1 Three-Way Calling - (Method 1) 2
a. To initiate Three-Way Calling while a call is in progress, the MS sends a 3
Flash with Information to the BS to request the original call to be placed on 4
hold. 5
b. The BS sends the Flash with Information message from the MS to the MSC. 6
The MSC places the original call on hold. 7
c. The MS sends a Flash with Information message to the BS containing the 8
dialed digits of the second party. 9
d. The BS sends the Flash with Information message to the MSC with the dialed 10
digits of the second party. Once the second party answers, it is connected to 11
the MS. 12
e. The MS sends a Flash with Information Message to the BS to request 13
connection of all three parties. 14
f. The BS sends the Flash with Information to the MSC. The MSC places all 15
three parties in a conference call. 16
g. To disconnect the second party, the MS sends a Flash with Information to the 17
BS. 18
h. The BS sends a Flash with Information message to the MSC, which 19
disconnects the second call. 20
3.6.3.2 Three-Way Calling - (Method 2) 21
This section provides the call flow description for the Three-Way Calling feature 22
(Method 2). In Method 2, the called address information of the second call is sent during 23
the first hook flash indication from the MS. 24
3GPP2 A.S0013-0 v2.0
Section 3 64
MS BS MSCtime comment
a
bFlash with Information
Flash with Information (2nd party called address)
c
dFlash with Information
Flash with Information
e
fFlash with Information
Flash with Information
1
Figure 3.6.3.2-1 Three-Way Calling - (Method 2) 2
a. To initiate Three-Way Calling while a call is in progress, the MS sends a 3
Flash with Information containing the dialed digits of the second call to the 4
BS. 5
b. The BS sends a Flash with Information message to the MSC along with the 6
dialed digits of the second party. The MSC places the original call on hold and 7
starts call setup procedures for the second party. Once the second party 8
answers, it is connected to the MS. 9
c. The MS sends a Flash with Information message to the BS to request 10
connection of all three parties. 11
d. The BS sends the Flash with Information message to the MSC. The MSC 12
places all three parties in a conference call. 13
e. To disconnect the second party, the MS sends a Flash with Information 14
message to the BS. 15
f. The BS sends a Flash with Information message to the MSC, which 16
disconnects the second call. 17
3.6.4 Message Waiting Notification 18
3.6.4.1 Message Waiting Notification on the Paging Channel 19
The following example demonstrates the delivery of a Message Waiting Indication via 20
the Feature Notification message over the control channel. 21
3GPP2 A.S0013-0 v2.0
Section 3 65
MS BS MSCtime comment
b
c
dFeature Notification Ack
Layer 2 Ack
aFeature Notification
MWI Order / FeatureNotification
T63
1
Figure 3.6.4.1-1 Message Waiting Notification on the Paging Channel 2
a. MSC sends a Feature Notification message containing message waiting 3
information and starts timer T63. 4
b. The BS sends an appropriate message to the mobile depending upon the air 5
interface protocol. 6
c. The MS acknowledges the receipt of the message by a Layer 2 Ack. 7
d. BS sends the Feature Notification Ack message to the MSC. The MSC stops 8
timer T63. 9
3.6.4.2 Message Waiting Notification on the Traffic Channel 10
The following example shows the delivery of a Message Waiting Indication to the MS 11
while on a traffic channel via the Flash with Information message. 12
MS BS MSCtime comment
b
c
dFlash with Information Ack
Layer 2 Ack
aFlash with Information
Flash with Information
T62
13
Figure 3.6.4.2-1 Message Waiting Notification on the Traffic Channel 14
a. When the MS is on traffic channel, the MSC may include message waiting 15
information in the Flash with Information message to inform the MS that there 16
are zero or more messages waiting. In this scenario, it is assumed that the 17
MSC also includes the Tag element in the Flash with Information message to 18
request that the BS notify the MSC when a Layer 2 Ack is received from the 19
MS. The MSC starts timer T62. 20
b. The BS sends the information in the Flash with Information air interface 21
message. 22
c. Once the MS has received the Flash with Information message, it responds 23
with a Layer 2 Ack message. 24
3GPP2 A.S0013-0 v2.0
Section 3 66
d. The BS sends the Flash with Information Ack message to the MSC including 1
the Tag element included by the MSC in the Flash with Information message. 2
The MSC stops timer T62. 3
3.6.5 Call Barring 4
This section contains call flows associated with the Call Barring Feature. 5
3.6.5.1 Call Barring Incoming 6
Call Barring Incoming is transparent to the IOS. 7
3.6.5.2 Call Barring Outgoing 8
9
MS Ack Order
a
b
c
MS BS MSC
Time
e
f
g
h
i
j
k
l
m
Origination Message
T10
d
T303
BS Ack Order
Complete L3 Info: CM Service Request
Assignment Request
Channel Assignment Message
Tch Preamble
BSAck Order
Service Connect Message
Assignment Complete
Clear Command
Clear Complete T315
Service Connect Completion
10
Figure 3.6.5.2-1 Call Barring Outgoing 11
a. The MS transmits an Origination Message, with layer 2 acknowledgment 12
required, over the access channel of the air interface to the BS to request 13
service. 14
3GPP2 A.S0013-0 v2.0
Section 3 67
b. The BS acknowledges the receipt of the Origination Message with a Base 1
Station Acknowledgment Order to the MS. 2
c. The BS constructs the CM Service Request message, places it in the Complete 3
Layer 3 Information message, sends the message to the MSC, and starts timer 4
T303. For circuit switched calls, the BS may request the MSC to allocate a 5
preferred terrestrial circuit. 6
d. The MSC sends an Assignment Request message to the BS to request 7
assignment of radio resources. This message includes information on the 8
terrestrial circuit, if one is to be used between the MSC and the BS. The MSC 9
then starts timer T10. Upon receipt of the Assignment Request message from 10
the MSC, the BS stops timer T303. 11
e. If a traffic channel is available for the call, the BS sends a Channel 12
Assignment Message over the paging channel of the radio interface (with the 13
MS address) to initiate the establishment of a radio traffic channel, if the MS 14
is not already on a traffic channel. 15
f. The MS begins sending the traffic channel preamble (TCH Preamble) over the 16
designated reverse traffic channel. 17
g. Once the BS acquires the reverse traffic channel, it sends the Base Station 18
Acknowledgment Order, with layer 2 acknowledgment required, to the MS 19
over the forward traffic channel. 20
h. The MS acknowledges the reception of the BS Ack Order by transmitting the 21
Mobile Station Acknowledgment Order and by sending null traffic channel 22
data (Null TCH Data) over the reverse traffic channel. 23
i. The BS then sends the Service Connect Message / Service Option Response 24
Order to the MS specifying the service configuration for the call. The MS 25
begins processing traffic in accordance with the specified service 26
configuration. 27
j. On receipt of the Service Connect Message, the MS responds with a Service 28
Connect Completion Message. 29
k. After the radio traffic channel and circuit have both been established and fully 30
interconnected, the BS sends the Assignment Complete message to the MSC 31
and considers the call to be in conversation state. The MSC stops timer T10 32
upon receipt of the Assignment Complete message. 33
l. If the MSC determines that the call should be blocked, it applies treatment 34
(announcement), sends a Clear Command to instruct the BS to release the 35
associated dedicated resources and starts timer T315. 36
m. The BS returns the Clear complete message and the MSC stops timer T315. 37
3.6.6 Calling Number ID Presentation/Restriction 38
For mobile originated CNIR, refer to the call flows in section 3.1.1. 39
For mobile terminated CNIP/CNIR, if the MS is idle, the CNIP/CNIR information is sent 40
in the Assignment Request message. The call flows for this feature are identical to the 41
call flows for a mobile terminated calls, refer to section 3.1.2. 42
3GPP2 A.S0013-0 v2.0
Section 3 68
If the MS user subscribes to the Call Waiting (CW) feature and is engaged in a call, the 1
CNIP/CNIR information is sent in the Flash with Information message. The call flow for 2
this feature is identical to the call flow for Call Waiting; refer to section 3.6.2. 3
3.6.7 Distinctive Ringing 4
The call flows for this feature are identical to the call flows for a mobile terminated call; 5
refer to section 3.1.2. 6
3.6.8 Answer Holding 7
This feature is activated using Feature Activation; refer to section 3.6.1. 8
3.6.9 User Selective Call Forwarding 9
This feature is activated using Feature Activation; refer to section 3.6.1. 10
3.7 Mobile Registration (Mobile Originated) 11
This section describes procedures related to Registration and Deregistration. 12
Mobile registration is a process where mobile characteristics such as location or status are 13
provided to the network. Registration may be initiated by the MS, by the network, or 14
implied during an MS access. Deregistration processes for are initiated by the MS. 15
The following functions are not supported in this version of the specification: 16
• The ability to allow the MSC to order an idle MS to perform a registration; 17
• Traffic channel registration - where the MSC may notify an MS that it is registered 18
while the MS occupies a traffic channel. 19
The MSC may infer registration information based on a mobile’s system access. This 20
form of registration is transparent to the BS and the MS, and requires no additional 21
message passing over the MSC-BS interface. 22
The MS may initiate registration for a number of reasons. The types of registration 23
performed are enabled and controlled through parameters transmitted by the BS on the 24
forward (downlink) control channels. Selection of control channel parameters and 25
enabling of specific registration types are beyond the scope of this document. 26
Successful location registration requests involve the exchange of the following MSC-BS 27
messages: 28
• Complete Layer 3 Information with Location Updating Request 29
• Authentication Request / Authentication Response (optional) 30
• Location Updating Accept 31
The message diagrams for the location update request procedure are illustrated in Figure 32
3.15.1.2.3-1. 33
When authentication is supported by the BS/MSC, a challenge RAND is broadcast on the 34
control channel. RAND is specified in [14] and utilized for the process of registration, 35
3GPP2 A.S0013-0 v2.0
Section 3 69
call origination and call termination. The MS utilizes the broadcast RAND to compute 1
the Authentication Response AUTHR specified in [14]. 2
The Location Updating Request message is sent by the BS to notify the MSC of a 3
registration attempt by the MS. 4
3.7.1 Location Registration - Successful Case 5
The call flow diagram in Figure 3.7.1-1 provides an illustration of a successful Location 6
Registration procedure initiated by the MS. 7
MS BS MSC time comment
Registration Message
Registration Accepted Order
a
b
c
d
Location Updating Request
Location Updating Accept T3210
8
Figure 3.7.1-1 Location Registration - Successful Case 9
a. The MS initiates registration operation by sending the Registration Message to 10
the BS. 11
b. On reception of the Registration Message the BS constructs the Location 12
Updating Request message, places it in the Complete Layer 3 Information 13
message, and sends it to the MSC. The BS then starts timer T3210. 14
c. The MSC sends the Location Updating Accept message to the BS to indicate 15
that the Location Updating Request message has been processed. 16
Upon receipt of the Location Updating Accept message, the BS stops timer 17
T3210. 18
d. The BS may transmit a Registration Accepted Order to the MS to indicate 19
successful location registration operation. 20
3.7.2 Power Down Registration at the End of a Call 21
The MS may send a power down indication in a Release Order when clearing a call. The 22
BS shall forward a power down indication to the MSC by including the Power Down 23
Indicator element in the Clear Complete message. Refer to [14] “Clear Complete” for 24
more information. 25
3.8 Global Emergency Call Origination 26
Normal mobile originated call setup call flows apply to this feature; refer to section 3.1.1. 27
3GPP2 A.S0013-0 v2.0
Section 3 70
3.9 E911 Phase I and Phase 2 1
Normal mobile originated call setup call flows apply to this feature; refer to section 3.1.1. 2
This feature also uses Mobile Position Determination; refer to section 3.13. 3
3.10 Short Message Service 4
This section contains descriptions and call flows for the Short Message Service feature. 5
Refer to section 2.10 for more details on this feature. 6
3.10.1 SMS Feature Description 7
The subsections below contain descriptions of the following SMS cases: 8
• SMS Mobile Originated Point-to-Point 9
• SMS Mobile Terminated Point-to-Point 10
• SMS Broadcast 11
3.10.1.1 SMS - Mobile Originated Point-to-Point 12
This section describes the call flow for sending an SMS message which is mobile 13
originated. 14
A mobile originated SMS (SMS-MO) message may be sent from the MS to the BS on 15
either a control (access) or traffic channel. 16
An MS already on a traffic channel uses that traffic channel to send an SMS-MO 17
message. An idle MS may use either an access channel, or in some air interfaces, may 18
request a traffic channel for delivery of an SMS-MO message. If an idle CDMA MS 19
wants to use a traffic channel to send an SMS-MO message, it sends an Origination 20
Message with the short message service option number in the service option field. The 21
call origination call flows described in section 3.1.1 are then used. If the access channel is 22
used for SMS-MO message transmission from the MS to the BS, then no call 23
establishment is performed. When the SMS-MO message is transmitted from the MS to 24
the BS on an access channel, the transport of the SMS-MO message on the MSC-BS 25
Interface is accomplished by sending an Application Data Delivery Service (ADDS) 26
Transfer message from the BS to the MSC. 27
When the SMS-MO message is transmitted from the MS to the BS on a traffic channel, 28
the transport of SMS-MO message on the MSC-BS Interface is accomplished by sending 29
the ADDS Deliver message from the BS to the MSC. 30
3.10.1.2 SMS - Mobile Terminated Point-to-Point 31
This section describes the call flow for sending an SMS message which is mobile 32
terminated. 33
An SMS Mobile Terminated (SMS-MT) message can be transmitted from the BS to the 34
MS on either a control (paging) or traffic channel. An SMS-MT message to an MS 35
already on a traffic channel is sent on the traffic channel. 36
3GPP2 A.S0013-0 v2.0
Section 3 71
When the SMS-MT message is sent to the MS on a traffic channel, the transport of the 1
SMS-MT message on the MSC-BS Interface is accomplished by sending the ADDS 2
Deliver message from the MSC to the BS. 3
When the SMS-MT message is sent to the MS on a control channel, the transport of the 4
SMS-MT message on the MSC-BS Interface is accomplished by sending the ADDS Page 5
message from the MSC to the BS. 6
3.10.1.3 SMS - Broadcast 7
SMS Broadcast is a mobile terminated short message that is sent to all mobile stations 8
operating within the BS serving region. The broadcast address determines which mobiles 9
receive the message. 10
When the MSC sends an SMS Broadcast message to idle mobile stations, the MSC uses 11
the ADDS Page message. 12
3.10.2 SMS Delivery on the Control Channel 13
The delivery of SMS-MT, SMS-MO, and SMS-Broadcast messages on the control 14
channel is accomplished by the exchange of ADDS Page, ADDS Page Ack, and ADDS 15
Transfer messages. 16
The ADDS Page is sent from the MSC to the BS and is used for SMS-MT and SMS-17
Broadcast messages. It may be acknowledged with the ADDS Page Ack message. 18
The ADDS Transfer message is sent from the BS to the MSC when the BS receives a 19
Data Burst message on the access channel. 20
This section contains examples of SMS delivery on the control channel. 21
3.10.2.1 SMS Broadcast Delivery over the Paging Channel 22
This section provides the call flow description for SMS Broadcast delivery over the 23
Paging channel. 24
MS BS MSCtime comment
b
c
ADDS Page Ack
aADDS Page
Paging Channel SMS BroadcastDelivery
T3113
25
Figure 3.10.2.1-1 SMS-Broadcast Delivery to Mobile Stations over the Paging Channel. 26
a. The MSC receives SMS Broadcast information for delivery to idle mobile 27
stations. 28
The MSC sends an ADDS Page message to the BS. The ADDS Page contains 29
the SMS Broadcast message in its ADDS User Part information element. 30
3GPP2 A.S0013-0 v2.0
Section 3 72
If the MSC requires an acknowledgment to the ADDS Page message, the Tag 1
element shall be included in the ADDS Page message. The MSC starts timer 2
T3113. 3
b. If the MSC requested an acknowledgment from the BS by including the Tag 4
element in the ADDS Page message, the BS replies with an ADDS Page Ack 5
message including the Tag element set to the same value as received from the 6
MSC. The MSC stops timer T3113. 7
c. The BS sends the SMS Broadcast information to the appropriate mobile 8
stations over the Paging channel. Layer 2 Acks are not requested by the BS 9
from the mobile stations receiving the SMS broadcast message. 10
3.10.2.2 SMS Delivery to an MS on the Paging Channel - Example 1 11
This section provides the call flow description for the delivery of an SMS-MT message 12
on the paging channel. 13
MS BS MSCtime comment
b
c
dADDS Page Ack
Layer 2 Ack
aADDS Page
Paging Channel SMS Delivery T3113
Conditional
Conditional
14
Figure 3.10.2.2-1 SMS-MT Delivery to an MS on the Paging Channel - Example 1 15
a. The MSC determines that a point-to-point short message is to be sent to an 16
idle MS. 17
The MSC sends an ADDS Page message to the BS. The ADDS Page contains 18
the short message in its ADDS User Part information element. 19
If the MSC requires an acknowledgment, it includes the Tag information 20
element in the ADDS Page message and starts timer T3113. 21
b. The BS sends the short message to the MS on the paging channel. Before 22
sending the short message, the BS may perform vendor specific procedures 23
such as paging the MS to determine the cell in which the MS is located. 24
c. If a Layer 2 Ack was solicited, the MS acknowledges the receipt of the 25
message by a Layer 2 Ack. 26
d. If the MSC requested an acknowledgment by including the Tag information 27
element in the ADDS Page message, the BS replies with an ADDS Page Ack 28
message including the Tag information element set identical to the value sent 29
by the MSC. If timer T3113 was previously started, it is now stopped. 30
3.10.2.3 SMS Receipt from an MS on the Access Channel 31
This section provides the call flow description for the receipt of an SMS-MO message on 32
the access channel. 33
3GPP2 A.S0013-0 v2.0
Section 3 73
Time
a
b
c
MS BS MSC
ADDS Transfer
Access Channel SMS Delivery
Layer 2 Ack
1
Figure 3.10.2.3-1 SMS-MO Delivery on the Access Channel 2
a. The MS sends a point-to-point SMS message to the network on the access 3
channel. 4
b. If the MS had requested a Layer 2 Ack, the BS acknowledges the short 5
message received on the access channel by sending a Layer 2 Ack on the 6
paging channel. 7
c. The BS sends an ADDS Transfer message to the MSC containing the SMS 8
message received from the MS in the ADDS User Part element. 9
3.10.2.4 SMS Delivery to an MS on the Paging Channel - Example 2 without Early Traffic 10
Channel Assignment 11
This section provides an example call flow description for the delivery of an SMS-MT 12
message on the Paging Channel without early traffic channel assignment by the BS. In 13
this example, the MS is held on the control channel until the SMS messages are 14
delivered. After delivery, the MS is released. 15
3GPP2 A.S0013-0 v2.0
Section 3 74
MS BS MSCtime comment
g
h
iADDS Page Ack
Layer 2 Ack
fADDS Page
Paging Channel SMS DeliveryT3113
b
aPaging Request
Base Station Ack Order
T3113
c
dComplete L3 Info: Paging Response
Page Response Message
Page Message
MSC releases underlying transport connection
k
lRelease Order
Release Order
e
j
Optional
Optional
T303
1
Figure 3.10.2.4-1 SMS-MT Delivery to an MS on the Paging Channel - Example 2 2
a. The MSC sends a Paging Request message to the BS and starts timer T3113. 3
b. The BS sends a Page Message on the paging channel. 4
c. The MS responds with a Page Response Message. 5
d. The BS sends a Complete Layer 3 Information message containing a Paging 6
Response message to the MSC. The MSC stops timer T3113. 7
e. The BS sends a Base Station Ack Order to acknowledge the Page Response 8
Message from the MS. 9
f. If the Radio Environment and Resources element in the Page Response 10
message indicates no early traffic channel assignment by the BS, the MSC 11
sends an ADDS Page message to the BS. The ADDS Page contains the short 12
message in its ADDS User Part information element. 13
If the MSC requires an acknowledgment, it includes the Tag information 14
element in the ADDS Page message and starts timer T3113. 15
g. The BS sends the short message to the MS. 16
h. The MS acknowledges the receipt of the message by a Layer 2 Ack. 17
i. If the MSC requested an acknowledgment by including the Tag information 18
element in the ADDS Page message, the BS replies with an ADDS Page Ack 19
message including the Tag information element set identical to the value sent 20
by the MSC. If timer T3113 was previously started, it is now stopped. 21
j. The MSC releases the underlying transport connection to clear the pending 22
page response. 23
3GPP2 A.S0013-0 v2.0
Section 3 75
k. The BS, upon the release of the underlying transport connection, sends a 1
Release Order to the MS. 2
l. The MS sends a Release Order to the BS to acknowledge the release. 3
3.10.2.5 SMS Delivery to an MS on the Paging Channel - Example 3 with Early Traffic 4
Channel Assignment 5
This section provides an example call flow description for the delivery of an SMS-MT 6
message on the Paging Channel with early traffic channel assignment by the BS. 7
MS BS MSCtime comment
g
h
i
ADDS Page Ack
Layer 2 Ack
f
ADDS Page
Paging Channel SMS DeliveryT3113
b
aPaging Request
Base Station Ack Order
T3113
c
dComplete L3 Info: Paging Response
Page Response Message
Page Message
(MSC releases underlying transport connection)
k
l
Release Order
Release Order
e
j
Optional
Optional
T303
8
Figure 3.10.2.5-1 SMS-MT Delivery to an MS on the Paging Channel - Example 3 9
a. The MSC sends a Paging Request message to the BS and starts timer T3113. 10
b. The BS sends a Page Message on the paging channel. 11
c. The MS responds with a Page Response Message. 12
d. The BS sends a Complete Layer 3 Information message containing a Paging 13
Response message to the MSC. The MSC stops timer T3113. 14
e. The BS sends a Base Station Ack Order to acknowledge the Page Response 15
Message from the MS. 16
f. The Radio Environment and Resources element in the Page Response 17
message indicates early traffic channel assignment by the BS, the MSC shall 18
release the underlying transport connection to clear the pending page response 19
g. The BS, upon the release of the underlying transport connection, sends a 20
Release Order to the MS. 21
h. The MS sends a Release Order to the BS to acknowledge the release. 22
3GPP2 A.S0013-0 v2.0
Section 3 76
i. The MSC sends an ADDS Page message to the BS. The ADDS Page contains 1
the short message in its ADDS User Part information element. 2
If the MSC requires an acknowledgment, it includes the Tag information 3
element in the ADDS Page message and starts timer T3113. 4
j. The BS sends the short message to the MS. 5
k. The MS acknowledges the receipt of the message by a Layer 2 Ack. 6
l. If the MSC requested an acknowledgment by including the Tag information 7
element in the ADDS Page message, the BS replies with an ADDS Page Ack 8
message including the Tag information element set identical to the value sent 9
by the MSC. If timer T3113 was previously started, it is now stopped. 10
3.10.3 SMS Delivery on the Traffic Channel 11
This section describes the delivery of SMS messages on the traffic channel. 12
The delivery of Short Messages on the traffic channel is accomplished with the ADDS 13
Deliver and ADDS Deliver Ack messages on the MSC-BS Interface. 14
This section contains examples of SMS Delivery Services on the traffic channel. 15
3.10.3.1 SMS Delivery to an MS on a Traffic Channel 16
This section provides the call flow description for delivery of an SMS-MT short message 17
on a traffic channel. 18
a
b
c
d
MS BS MSC
ADDS Deliver
Traffic Channel SMS Delivery
ADDS Deliver Ack
Layer 2 Ack
CommentTime
19
Figure 3.10.3.1-1 SMS Message Delivery to an MS on a Traffic Channel 20
a. The MSC determines that a short message is to be sent to the MS while it is 21
on the traffic channel. 22
b. The MSC sends an ADDS Deliver message to the BS. The ADDS Deliver 23
message contains the short message in the ADDS User Part element. The BS 24
transmits the short message over the forward traffic channel. If the BS does 25
not receive an acknowledgment after transmitting the CDMA Data Burst 26
message, it shall retransmit the message. The BS shall not exceed a maximum 27
number of retransmissions, to be selected by the BS manufacturer. When the 28
BS reaches the maximum number of retransmissions, it shall declare a Layer 2 29
Ack failure and initiate call clearing. 30
c. The MS acknowledges delivery of the short message on the traffic channel 31
with a Layer 2 Ack. 32
3GPP2 A.S0013-0 v2.0
Section 3 77
d. If the MSC has requested a response by including the tag element in the 1
ADDS Deliver message, the BS replies with an ADDS Deliver Ack message 2
when it has received acknowledgment from the MS that the message was 3
delivered. If a Tag element was included in the ADDS Deliver message, the 4
BS shall include the Tag element in the ADDS Deliver Ack message, and set 5
it to the same value as that received in the ADDS Deliver message. 6
3.10.3.2 SMS Receipt from an MS on a Traffic Channel 7
This section provides the call flow description for the receipt of an SMS-MO message on 8
a traffic channel. 9
Time
a
b
c
MS BS MSC
ADDS Deliver
Traffic Channel SMS Delivery
Layer 2 Ack
10
Figure 3.10.3.2-1 SMS Receipt from an MS on a Traffic Channel 11
a. The BS receives a Traffic Channel SMS Delivery message from an MS on the 12
traffic channel with a burst type indicating SMS. 13
b. If a Layer 2 Ack was requested by the MS, the BS sends a Layer 2 Ack to the 14
MS on the traffic channel. 15
c. The BS sends an ADDS Deliver message to the MSC. The ADDS User Part 16
element contains the short message which was received from the MS. 17
3.11 Priority Access and Channel Assignment (PACA) 18
The following subsections describe call flows associated with the PACA feature. Refer to 19
section 2.11 for more information on this feature. PACA service involves exchange of the 20
following MSC-BS messages: 21
• PACA Command 22
• PACA Command Ack 23
• PACA Update 24
• PACA Update Ack 25
• CM Service Request 26
• Assignment Request 27
• Assignment Failure. 28
3.11.1 Mobile Origination with PACA Service 29
Two conditions may occur on a call origination with PACA service. In the first condition, 30
the BS can not determine that radio resources are not available for a call before sending 31
the CM Service Request message to the MSC. In this case the origination call flow shown 32
3GPP2 A.S0013-0 v2.0
Section 3 78
in section 3.1.1.1 is followed. In the second case, the BS determines that radio resources 1
are not available for a call before sending the CM Service Request message. In this 2
second case, the origination call flow shown in section 3.11.1.1 below is followed. 3
3.11.1.1 Mobile Origination with PACA Service – Radio Resources not Available 4
This section describes the call flow associated with an MS call origination with PACA 5
service in the system. 6
MS BS MSCtime comment
Origination Message a
c
e
f
g
h
Complete L3 Info: CM Service Request
PACA Command Ack
T303
PACA Message
Base Station Ack Orderb
dPACA Command
Tpaca1
PACA Message
PACA Message
7
Figure 3.11.1.1-1 Mobile Origination with PACA Service 8
a. The MS transmits an Origination, with Layer 2 Ack required, over the access 9
channel of the air interface to the BS to request service. The MS sets the 10
PACA_REORIG field to ‘0’ to indicate a user-directed origination. 11
b. The BS acknowledges the receipt of the Origination Message with a Base 12
Station Acknowledgment Order to the MS. 13
c. The BS constructs the CM Service Request message, places it in the Complete 14
Layer 3 Information message, sends the message to the MSC, and starts timer 15
T303. The BS includes the Radio Environment and Resources elements in the 16
CM Service Request message. The ‘Avail’ bit of the Radio Environment and 17
Resources element is set to ‘0’ to indicate that resources at the BS are not 18
available. The PSI field in the Classmark Information Type 2 IE should be set 19
to ‘1’. 20
The MSC receives the call origination and dialed digits in the CM Service 21
Request message and determines that the call is eligible for PACA service. 22
d. The MSC sends a PACA Command message to inform the BS that PACA 23
service shall be applied to this call. The PACA Command message includes 24
the Priority and the PACA Time Stamp information elements to provide 25
information to the BS for PACA queuing. The MSC starts timer Tpaca1. Upon 26
receipt of the PACA Command message the BS stops timer T303. 27
e. Based on the information received in the PACA Command message the BS 28
queues the call. The BS sends a PACA Command Ack message to the MSC. 29
3GPP2 A.S0013-0 v2.0
Section 3 79
The MSC stops timer Tpaca1 after receiving the acknowledgment. The MSC 1
releases the underlying transport connection. 2
f. The BS sends a PACA Message to the MS to indicate that the service request 3
has been queued and includes the queue position. 4
g. The BS may optionally send additional PACA messages over the paging 5
channel to update the MS on its PACA queue position. The BS may resend 6
this message as needed until radio resources become available. 7
h. When radio resources become available, the BS sends a PACA Message to 8
instruct the MS to re-originate the call. In this case, the PURPOSE field is set 9
to ‘0010’ to request PACA re-origination. The normal Origination call flow 10
(refer to section 3.1.1.1) processes the re-origination request. 11
3.11.1.2 Mobile Origination, Idle Handoff with PACA Active 12
This section describes the call flow associated with MS call origination with PACA 13
active in the system while idle handoff occurs. 14
MS New BS MSCtime comment
b
c
dPACA Update Ack
a
PACA Update
Tpaca2
Old BS
Origination Procedure with PACAService Involving the Old BS
Origination Procedure with PACAService Involving the New BS
15
Figure 3.11.1.2-1 Mobile Origination, Idle Handoff with PACA Active 16
a. The MS previously attempted a call origination and the call has been queued 17
as in steps a through f of Figure 3.6.1.1-1. 18
b. While approaching the boundary of the cell, the MS detects an adequately 19
strong pilot signal transmitted by one of the neighboring cells (new BS). The 20
MS performs an idle handoff and starts monitoring the new paging channel. 21
The MS then transmits an Origination Message, with Layer 2 Ack required, 22
over the access channel of the air interface to the new BS to request service. In 23
this case, the PACA_REORIG field received in the Origination Message is set 24
to ‘1’. The normal Origination call flow (refer to section 3.1.1.1) processes the 25
re-origination request. 26
c. The MSC sends a PACA Update message to instruct the old BS to remove the 27
service request from its PACA queue. The MSC can send the PACA Update 28
message anytime after receiving the CM Service Request message from the 29
new BS. The MSC starts timer Tpaca2. 30
3GPP2 A.S0013-0 v2.0
Section 3 80
d. The BS sends a PACA Update Ack message to the MSC to confirm that 1
appropriate action has been taken by the BS and that its PACA information 2
has been updated. Upon receipt of the PACA Update Ack message the MSC 3
stops timer Tpaca2. 4
3.11.1.3 Mobile Origination with PACA Active, Consecutive PACA Calls 5
This section describes the call flow associated with a successful MS call origination with 6
consecutive service requests in the system. In this scenario the MS originates a call to 7
another number while the first call request is in a PACA queue. 8
MS BS MSCtime comment
b
c
dPACA Update Ack
a
PACA Update
Tpaca2
Origination Procedurewith PACA Service
Origination Procedurewith PACA Service
9
Figure 3.11.1.3-1 Mobile Origination with Consecutive PACA Call Requests 10
a. The MS previously attempted a call origination and the call has been queued 11
as in steps a through f of Figure 3.6.1.1-1. 12
b. While the first call request is pending, the MS sends an Origination Message, 13
with Layer 2 Ack required, over the access channel of the air interface to the 14
BS to request service using a different called party number. In this case, the 15
PACA_REORIG field received in the Origination Message is set to ‘0’. The 16
normal Origination call flow (refer to section 3.1.1.1) processes the re-17
origination request. 18
c. The MSC sends a PACA Update message to the BS with the PACA Order 19
indicating “Remove MS from the queue.” The MSC can send the PACA 20
Update message anytime after receiving the second CM Service Request 21
message. The MSC starts timer Tpaca2. 22
d. The BS sends a PACA Update Ack message to the MSC to confirm that 23
appropriate action has been taken by the BS and that its PACA information 24
has been updated. Upon receipt of the PACA Update Ack message the MSC 25
stops timer Tpaca2. 26
3.11.2 PACA Call Cancellation Initiated by the MS 27
This section describes the call flow associated with cancellation of a PACA queued call 28
in the system. In this scenario the cancellation is initiated by the MS. 29
3GPP2 A.S0013-0 v2.0
Section 3 81
MS BS MSCtime comment
b
c
ePACA Update Ack
a
PACA Update
Tpaca2
Origination Procedurewith PACA Service
PACA Cancel
d
BS Ack Order
1
Figure 3.11.2-1 PACA Call Cancellation Initiated by the MS 2
a. The MS previously attempted a call origination and the call has been queued 3
as in steps a through f of Figure 3.6.1.1-1. 4
b. The MS sends a PACA Cancel Message, with layer 2 Ack required, over the 5
access channel of the air interface to the BS to request the call be canceled. 6
c. The BS acknowledges the receipt of the PACA Cancel Message with a Base 7
Station Acknowledgment Order to the MS. 8
d. The BS cancels the call and removes the request from its PACA queue. The 9
BS then sends a PACA Update message to the MSC to indicate that the call 10
has been canceled. The BS starts timer Tpaca2. 11
e. The MSC sends a PACA Update Ack message to the BS to confirm the 12
receipt of the PACA Update message. Upon receipt of the PACA Update Ack 13
message the BS stops timer Tpaca2. 14
3.11.3 PACA Call Cancellation Initiated by Either MSC or BS 15
This section describes the call flow associated with cancellation of a PACA call in the 16
system. In this example scenario the cancellation is initiated by the MSC. The BS-17
initiated PACA call cancellation is identical except the BS sends the PACA Update 18
message to the MSC. 19
3GPP2 A.S0013-0 v2.0
Section 3 82
MS BS MSCtime comment
b
c
ePACA Update Ack
a
PACA Update
Tpaca2
Origination Procedurewith PACA Service
PACA Message
dMS Ack Order
MSC decides tocancel thequeued PACAcall.
1
Figure 3.11.3-1 PACA Call Cancellation Initiated by the MSC 2
a. The MS previously attempted a call origination and the call has been queued 3
as in steps a through f of Figure 3.6.1.1-1. 4
b. The MSC sends a PACA Update message to the BS with the PACA Order 5
indicating “Remove MS from the queue and release MS.” The MSC starts 6
timer Tpaca2. 7
c. The BS cancels the call and removes the request from its PACA queue. The 8
BS then sends a PACA Message (PURPOSE=‘0011’) to the MS to indicate 9
that the PACA call has been canceled. 10
d. The MS sends an MS Ack order to the BS to acknowledge PACA 11
cancellation. 12
e. The BS sends a PACA Update Ack message to the MSC to confirm that 13
appropriate action has been taken by the BS and that its PACA information 14
has been updated. Upon receipt of the PACA Update Ack message the MSC 15
stops timer Tpaca2. 16
3.12 Over-The-Air Service Provisioning (OTASP) and Over The Air 17
Parameter Administration (OTAPA) 18
This section describes the messages and call flows to support the OTASP and OTAPA 19
features over the A-Interface. These features are fully specified in [22]. 20
3.12.1 OTASP Support 21
This section describes the messages and call flows to support OTASP calls. This includes 22
a mechanism for transporting OTASP data messages, as defined in [22]. The processing 23
of OTASP forward and reverse data messages at the MSC or BS is the responsibility of 24
the vendors. The air interface between the BS and MS is described in [22] and the MSC 25
interface to the network is addressed in [24]. 26
Successful OTASP processing involves the following procedures and exchange of some 27
MSC-BS interface messages: 28
3GPP2 A.S0013-0 v2.0
Section 3 83
1. OTASP Call Setup procedure 1
2. OTASP Data Exchange procedure which includes exchange of following 2
messages: 3
• ADDS Deliver 4
• ADDS Deliver Ack 5
Some existing procedures may also be applied as sub-procedures: 6
• SSD update procedure 7
• Privacy Mode request procedure 8
3. OTASP Call Clearing procedure 9
3.12.1.1 OTASP Call Setup 10
Normal call setup procedures for mobile origination (refer to section 3.1.1) are used to 11
establish the OTASP call. 12
3.12.1.2 OTASP Data Exchanges 13
After a voice path is set up, the ADDS Deliver message is used in both directions to 14
support exchange of OTASP data. In addition, the SSD update procedure and the Privacy 15
Mode procedure over the traffic channel may also be utilized. Refer to section 3.20.1 for 16
the call flows. 17
3.12.1.3 SSD Update Procedure 18
After the A-key has been derived at the MS as a result of receiving appropriate 19
information via an ADDS Deliver message, an SSD Update procedure over the traffic 20
channel may also be used. 21
3.12.1.4 Privacy Mode Procedure 22
The Privacy Mode procedure includes the processes to: pre-load the BS with parameters 23
for signaling message encryption (SME) or privacy, enable and disable SME or privacy. 24
A Privacy Mode procedure may be applied after an SSD Update procedure has been 25
successfully completed. 26
3.12.1.5 Rejection 27
When the BS receives a rejection indication (e.g., a Mobile Station Reject Order), it sends 28
the Rejection message to the MSC. No response is expected from the MSC. Refer to [14] 29
for Rejection message procedures and format. 30
3.12.1.6 OTASP Call Clear 31
Normal call clearing procedures (refer to section 3.2) are utilized to clear OTASP calls. 32
3.12.1.7 OTASP Call Flow 33
This section describes the message transactions between an MSC and BS to support 34
OTASP message transfer for the mobile. 35
3GPP2 A.S0013-0 v2.0
Section 3 84
MS BS MSCtime comment
Origination Messagea
b
c
d
e
f
i
j
k
l
n
o
ADDS Deliver
ADDS Deliver Ack
Data Burst (OTA)
L2 Ack/Reject Order with L2 Ack
Data Burst (OTA)
ADDS Deliver
L2 Ack
p
Reject Order
Rejection
g
h
Normal Call Setup
SSD Update
Privacy Mode Request
Repeat Steps c through k
Normal Call Clearing
mTerminal Re-Authentication
If a Rejectionmessage isreceived, theremainder of thisscenario may beomitted.
Optional
Optional
Optional
Optional
1
Figure 3.12.1.7-1 OTASP Message Flow: CDMA 2
a. The MS transmits an Origination Message over the access channel of the air 3
interface to the BS to initiate the OTASP process. 4
b. The MSC and the BS utilize normal call setup procedures (refer to section 5
3.1.1) to establish the OTASP call. 6
c. Upon request from the Over the Air Function (OTAF), the MSC encapsulates 7
an OTASP data message within an ADDS Deliver message and sends it to the 8
BS. 9
d. The BS extracts the OTASP data message and places it in the CDMA Data 10
Burst Message and transmits it over the traffic channel to the MS. 11
3GPP2 A.S0013-0 v2.0
Section 3 85
e. The MS may respond with a Layer 2 Ack or a Reject Order containing a 1
Layer 2 Ack acknowledging the Data Burst Message. 2
f. When the BS receives a Layer 2 Ack or a Reject Order containing a Layer 2 3
Ack acknowledging the Data Burst Message from the MS response to an 4
ADDS Deliver message that contained a Tag information element, it sends an 5
ADDS Deliver Ack message to the MSC with the corresponding Tag value. 6
g. The MS may return a Reject Order. 7
h. If the MS sends a Reject Order, he BS sends a Rejection message to the MSC 8
to convey the information contained in the Reject Order. If a Rejection 9
message is received, the remainder of this scenario may be omitted. 10
i. The OTASP application in the MS responds by sending an OTASP data 11
message. The MS places the OTASP data message in the CDMA Data Burst 12
Message and transmits it over the traffic channel to the BS. 13
j. Upon reception of the CDMA Data Burst Message, the BS responds with a 14
Layer 2 Ack. 15
k. The BS extracts the OTASP data message and places it in the ADDS Deliver 16
message to the MSC. 17
Steps (l) through (o) are optional. 18
l. After the A-key has been derived from information transferred via ADDS 19
Deliver messages, an SSD Update procedure over the traffic channel may also 20
be utilized to exchange authentication information (RANDSSD, RANDBS, 21
AUTHBS). 22
m. After an SSD Update procedure, Terminal Re-Authentication (refer to [22]) 23
needs to be performed to generate the cipher key that is used for Privacy. 24
n. After Terminal Re-Authentication, Privacy Mode procedures over the traffic 25
channel may also be applied to specify the use of either Signaling Message 26
Encryption (SME) or Privacy for the call. 27
o. Multiple forward and reverse OTASP messages can be sent between the 28
OTASP endpoint in the network and the MS. The MSC and the BS transfer 29
these messages whenever they are received. 30
p. Once the OTASP service programming has been successful, the call can be 31
cleared using a regular Call Clearing call flow (refer to section 3.2). 32
3.12.2 OTAPA Support 33
There are no call flows associated with this feature. Refer to section 2.12.2 for more 34
information. 35
3.13 Mobile Position Determination 36
This section presents several call flows which provide examples for Mobile Position 37
Determination. The approaches that are supported in this version of the standard are the 38
Position Location Service (MS-PDE) approach and the Software Calculation Position 39
Determination (BS-MSC) approach. Examples of both of these approaches are given in 40
this section. 41
The following messages (defined in [14]) are used to support this feature: 42
3GPP2 A.S0013-0 v2.0
Section 3 86
• Radio Measurements for Position Request 1
• Radio Measurements for Position Response 2
• ADDS Page 3
• ADDS Page Ack 4
• ADDS Transfer 5
• ADDS Deliver 6
• ADDS Deliver Ack 7
For PLD applications that have a BS based position termination process, the BS may 8
return the Geographic Location IE in the Radio Measurements for Position Response 9
message. 10
3.13.1 Call flows for Position Location Service (MS-PDE) 11
This section provides call flows for MS-PDE approach to position location. Position 12
Location Service may be done on either the common channels (Access and Paging) or 13
traffic channel (FCH). Position Location Service over common channels is very similar 14
to SMS delivery on the common channels. Position Location Service on the traffic 15
channel may by accomplished over an existing traffic link by sending Position Service 16
Location data bursts over the existing channel. Alternatively, the mobile or the network 17
may initiate a Position Location Services call on a traffic channel if no other services are 18
active, and these are the scenarios demonstrated below. 19
3.13.1.1 Mobile Originated Position Location Service on the Traffic Channel 20
This section describes how a mobile may initiate Position Location Service on a traffic 21
channel. 22
3GPP2 A.S0013-0 v2.0
Section 3 87
MS BS MSC
Origination Message
BS Ack Order
CM Service Request
Assignment Request
Channel assignment andservice connection Assignment Complete
Unique Challenge-Response
Data Burst
ADDS Deliver
ADDS Deliver
Data Burst
Layer 2 Ack
ADDS Deliver Ack
Clear CommandRelease Order
Release Order
Clear Complete
Time
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
pq
optional
T303
T10
T315
Layer 2 Ack
r
Clear Request
s
T300
1
Figure 3.13.1.1-1 Mobile Originated Position Location Service on a Traffic Channel 2
a. The MS transmits an Origination Message, with Layer 2 Ack required, over 3
the Access Channel of the air interface to the BS to request service. The 4
message contains SO=35 or SO=36, and does not contain dialed digits. 5
b. The BS acknowledges the receipt of the Origination Message with a Base 6
Station Acknowledgement Order to the MS. 7
3GPP2 A.S0013-0 v2.0
Section 3 88
c. The BS constructs the CM Service Request message, places it in the Complete 1
Layer 3 Information message, sends the message to the MSC, and starts timer 2
T303. The CM Service Request contains the Special Service Call Indicator 3
information element with MOPD set to ‘1’. The CM Service Request contains 4
service option SO=35 or SO=36, and does not contain dialed digits. 5
d. The MSC sends an Assignment Request message to the BS to request 6
assignment of radio resources. This message does not contain a terrestrial 7
circuit (CIC). The MSC starts timer T10. Upon receipt of the Assignment 8
Request message from the MSC, the BS stops timer T303. 9
e. The BS assigns a traffic channel to the mobile and completes the service 10
connection. See steps e-j in Figure 3.1.2.1-1. 11
f. After the radio traffic channel has been established and fully interconnected, 12
the BS sends the Assignment Complete message to the MSC and considers the 13
call in conversation state. 14
g. Optionally, the MSC may initiate unique challenge request-response. This 15
step may also be performed after step c, in which case common channels are 16
used. Refer to section 3.20.1. 17
h. The MS sends position location data to the BS on the traffic channel in a Data 18
Burst Message, and indicates that a Layer 2 Ack is required. 19
i. The BS sends a Layer 2 Ack to the MS. 20
j. The BS encapsulates the Position Location Service data in an ADDS Deliver 21
message and sends it to the MSC. 22
k. If the PDE has information for the MS, the MSC sends it an ADDS Deliver 23
message to the MSC. This message includes the Tag information element. 24
l. The BS sends a Data Burst Message to the MS over the traffic channel and 25
indicates that a Layer 2 Ack is required. 26
m. Upon receipt of the Data Burst, the MS sends a Layer 2 Ack to the BS. 27
n. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Deliver Ack to the 28
MSC including the Tag information element it received in the ADDS Deliver 29
message. 30
o. At some later time, the BS decides to terminate the Position Location Service. 31
The BS sends a Clear Request to the MSC and starts timer T300. (This 32
message will also be sent if the MS sends a Release Order to clear the call.) 33
This step assumes the PDE is located at the BS. 34
p. The MSC sends a Clear Command message to the BS to instruct the BS to 35
release the traffic channel and starts timer T315. This message initiates 36
clearing of traffic channel resources in the event that the PDE is external to 37
the BS. Upon receipt of this message, the BS stops timer T300, if it was 38
started. 39
q. The BS initiates call clearing over the air interface by transmitting a Release 40
Order over the forward traffic channel. 41
r. The MS responds by sending a Release Order to the BS and releasing the 42
traffic channel. 43
s. The BS sends a Clear Complete message to the MSC. Upon receipt of this 44
message, the MSC stops timer T315. 45
3GPP2 A.S0013-0 v2.0
Section 3 89
3.13.1.2 Mobile Terminated Position Location Service on the Traffic Channel 1
This section describes how the network may initiate Position Location Service on a 2
traffic channel. 3
MS BS MSC
Page Message
Page ResponsePaging Response
Assignment Request
Channel assignment andservice connection Assignment Complete
Data Burst
ADDS Deliver Ack
ADDS Deliver
Data Burst
Layer 2 Ack
Clear Command
Release Order
Release Order
Clear Complete
Time
a
b
c
d
e
f
g
h
i
j
k
l
m
no
p
q
r
T303
T10
T315
Paging Request
BS Ack Order
ADDS Deliver
T3113
Layer 2 Ack
s
Clear Request
t
T300
4
Figure 3.13.1.2-1 Mobile Terminated Position Location Service on a Traffic Channel 5
3GPP2 A.S0013-0 v2.0
Section 3 90
a. The MSC determines that a Position Location Service data request needs to be 1
sent to the mobile within its serving region and sends the Paging Request 2
message to the BS to initiate a mobile terminated call setup scenario. The 3
Paging Request message contains either SO=35 or SO=36. The MSC then 4
starts timer T3113. 5
b. The BS issues a Page Message containing the MS address over the Paging 6
channel. 7
c. The MS acknowledges the page by transmitting a page response message over 8
the Access channel. The response indicates the mobile supports SO 35 or 36. 9
d. The BS constructs the Paging Response message, places it in the Complete 10
Layer 3 Information message, sends the message to the MSC, and starts timer 11
T303. The BS shall not request a preferred terrestrial circuit for this service. 12
The MSC stops timer T3113 upon receipt of the Paging Response message 13
from the BS. 14
e. The BS acknowledges the receipt of the Page Response message from the MS 15
with a Base Station Acknowledgement Order to the MS. 16
f. The MSC sends an Assignment Request message to the BS to request 17
assignment of radio resources. The message does not contain a terrestrial 18
circuit (CIC). The MSC then starts timer T10. Upon receipt of the Assignment 19
Request message from the MSC, the BS stops timer T303. 20
g. The BS assigns a traffic channel and connects the service. See steps g-l in 21
figure 3.1.4.1-1. 22
h. After the radio traffic channel has been established, the BS sends the 23
Assignment Complete message to the MSC. The MSC stops timer T10 upon 24
receipt of the Assignment Complete message from the BS. 25
i. The MSC sends a Position Location Service data request encapsulated in an 26
ADDS Deliver message to the BS. The MSC includes the Tag information 27
element with this message. 28
j. The BS delivers the Position Location Service request in a Data Burst 29
Message to the MS over the traffic channel, and indicates that a Layer 2 Ack 30
is required. 31
k. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the 32
BS. 33
l. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Deliver Ack 34
message to the MSC with the same Tag value it received from the MSC in the 35
ADDS Deliver message in step i. 36
m. The MS sends Position Location Service data response to the BS in a Data 37
Burst Message over the traffic channel and indicates that a Layer 2 Ack is 38
required. 39
n. Upon receipt of the Data Burst Message, the BS sends a Layer 2 Ack to the 40
MS. 41
o. The BS encapsulates the Position Location Information in an ADDS Deliver 42
message and sends it to the MSC. 43
p. At some later time, the BS decides to terminate the Position Location Service. 44
The BS sends a Clear Request to the MSC and starts timer T300. (This 45
message will also be sent if the MS sends a Release Order to clear the call.) 46
This step assumes the PDE is located at the BS. 47
3GPP2 A.S0013-0 v2.0
Section 3 91
q. The MSC sends a Clear Command message to the BS to instruct the BS to 1
release the traffic channel and starts timer T315. This message initiates 2
clearing of traffic channel resources in the event that the PDE is external to 3
the BS. Upon receipt of this message, the BS stops timer T300, if it was 4
started. 5
r. The BS initiates call clearing over the air interface by transmitting a Release 6
Order over the forward traffic channel. 7
s. The MS acknowledges the Release Order by returning a Release Order over 8
the reverse traffic channel. 9
t. The BS sends a Clear Complete message to the MSC. The MSC stops timer 10
T315 upon receipt of the Clear Complete message and releases the underlying 11
transport connection. 12
3.13.1.3 Position Location Service over Common Channels – Mobile Terminated 13
This section describes how mobile terminated Position Location Service may be 14
supported using common channels. 15
MS BS MSC
Data Burst
Layer 2 Ack T3113
ADDS Transfer
Time
a
b
c
d
e
f
ADDS Page
Data Burst
Layer 2 Ack
g
ADDS Page Ack
16
Figure 3.13.1.3-1 PLD over Common Channels 17
a. The MSC determines that Position Location Service data request needs to be 18
sent to the mobile within its serving region and sends the ADDS Page 19
message to the BS. The Data Burst Type field in the ADDS User Part is set to 20
‘05H (PLD)’. The MSC includes the Tag information element in this message. 21
The MSC then starts timer T3113. 22
b. The BS sends the Position Location Information to the MS using a Data Burst 23
Message over the Paging Channel. The BS indicates that a Layer 2 Ack is 24
required. 25
3GPP2 A.S0013-0 v2.0
Section 3 92
c. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the 1
BS. 2
d. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Page Ack message 3
to the MSC including the Tag information element with the same value it 4
received in the ADDS Page message in step a. 5
e. The MS sends the Position Location Service data response to the BS in a Data 6
Burst Message on the Access Channel. The MS indicates that a BS Ack is 7
required. 8
f. Upon receipt of the Data Burst Message, the BS sends a Layer 2 Ack to the 9
MS to acknowledge receipt of the Data Burst Message on the Access Channel. 10
g. The BS encapsulates the Position Location Information in an ADDS Transfer 11
message and sends it to the MSC. 12
3.13.1.4 Position Location Service over Common Channels – Mobile Originated 13
This section describes how mobile originated Position Location Service may be 14
supported using common channels. 15
MS BS MSC
Data Burst
Layer 2 Ack
ADDS Transfer
Time
a
b
c
d
e
f
Data Burst
BS Ack
ADDS Page
ADDS Page Ackg
T3113
16
Figure 3.13.1.5-1 PLD over Common Channels 17
a. The MS sends the Position Location Service data request to the BS in a Data 18
Burst on the Access Channel. The MS indicates that a BS Ack is required. 19
b. The sends a BS Ack Order to the MS to acknowledge receipt of the Data 20
Burst Message on the Access Channel. 21
c. The BS encapsulates the Position Location Information in an ADDS Transfer 22
message and sends it to the MSC. 23
d. The MSC determines that Position Location Service data response needs to be 24
sent to the mobile and sends the ADDS Page message to the BS. The Data 25
3GPP2 A.S0013-0 v2.0
Section 3 93
Burst Type field in the ADDS User Part is set to ‘05H (PLD)’. The MSC 1
includes the Tag information element in this message. The MSC then starts 2
timer T3113. 3
e. The BS sends the Position Location Information to the MS using a Data Burst 4
Message over the Paging Channel. The BS indicates that a Layer 2 Ack is 5
required. 6
f. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the 7
BS. 8
g. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Page Ack message 9
to the MSC including the Tag information element with the same value it 10
received in the ADDS Page message in step a. 11
3.13.2 Call Flows for Software Calculation Position Determination 12
(BS-MSC) 13
This section describes a call flow Software Calculation Position Determination approach. 14
This approach is network initiated. 15
BS MSC
Tsoftpos
Time
a
b
Radio Measurements ForPosition Request
Radio Measurements ForPosition Response
16
Figure 3.13.2-1 Software Calculation for Position Determination 17
a. The PDE determines that position determination by means of software 18
calculation is to take place for a given mobile station that is on a traffic 19
channel, and sends a Radio Measurements for Position Request message to the 20
BS. The MSC starts timer Tsoftpos. 21
b. Upon receipt of the Radio Measurements for Position Request message, the 22
BS gathers the requested measurements and returns them in a Radio 23
Measurements for Position Response message. Upon receipt of the Radio 24
Measurements for Position Response message, the MSC stops time Tsoftpos. 25
Optionally, if the BS is capable of doing the position location calculation, the 26
3GPP2 A.S0013-0 v2.0
Section 3 94
BS will send the geographic location instead of the requested measurements to 1
the MSC. 2
3.14 User Zone 3
This section contains call flows describing the procedures for User Zones. Refer to 4
section 2.14 for more information on this feature. 5
3.14.1 Invoking User Zone at Registration 6
e
User Zone Reject
Location Updating Accept
Location Updating Request
MS BS MSC time comment
Registration Message a
b
c
d Steps d and e are used by the MSC for User Zone rejection.
T3210
User Zone Reject
7
Figure 3.14.1-1 Location Registration using User Zones 8
a. The MS initiates registration operation by sending the Registration Message to 9
the BS. 10
b. On reception of the Registration Message, the BS constructs the Location 11
Updating Request message, including the MS's User Zone, places it in a 12
Complete Layer 3 Information message, and sends it to the MSC. The BS 13
starts timer T3210. 14
c. The MSC sends the Location Updating Accept message to the BS to indicate 15
that the Location Updating Request message has been processed. Upon 16
receiving the Location Updating Accept message the BS stops timer T3210. 17
The following two steps are only used when the MSC rejects the User Zone requested by 18
the MS. 19
d. The MSC sends a User Zone Reject message to reject the User Zone. The 20
MSC may include an alternate User Zone for the mobile to use. 21
e. The BS sends the User Zone Reject message to the MS with the information it 22
received from the MSC. 23
3GPP2 A.S0013-0 v2.0
Section 3 95
3.14.2 Use of User Zones During Call Setup 1
MS BS MSC time comment
a
b
d
Complete L3 Info: CM Service Request/Paging Response
User Zone Reject
Assignment Complete
Assignment Request
User Zone Reject
e
Steps d and e are used by the MSC for User Zone rejection.
T10
c
T303
2
Figure 3.14.2-1 Mobile Call Setup Using User Zone 3
a. The BS constructs the CM Service Request message or Paging Response 4
message, including the User Zone the MS transmitted and send it to the MSC. 5
The BS starts timer T303. 6
b. The MSC sends an Assignment Request message to the BS to request 7
assignment of radio resources and starts timer T10. Upon receipt of this 8
message, the BS stops timer T303. 9
c. The BS sends an Assignment Complete message to the MSC. After receiving 10
the Assignment Complete message, the MSC stops timer T10. 11
The following two steps are only used when the MSC rejects the User Zone requested by 12
the MS. 13
d. The MSC sends a User Zone Reject message to reject the MS's preferred User 14
Zone. The MSC may send an alternate User Zone for the mobile to use. 15
e. The BS sends the User Zone Reject message to the MS with the information it 16
received from the MSC. 17
3GPP2 A.S0013-0 v2.0
Section 3 96
3.14.3 Changing User Zone During a Call 1
User Zone Reject
User Zone Update Request
MS BS MSC time comment
a
b
c
d
User Zone Update Request
User Zone Reject
User Zone Update
User Zone Update e
f
Steps c and d used by the MSC only for User Zone Rejection.
Steps e and f is used by the MSC only to change the User Zone used by the MS.
2
Figure 3.14.3-1 Updating the User Zone During a Call 3
a. The MS transmits a User Zone Update Request over the reverse traffic 4
channel of the air interface to the BS to request service. Included in this 5
message is the User Zone the MS prefers. 6
b. The BS sends a User Zone Update Request message to the MSC. Included is 7
the preferred User Zone the MS transmitted. 8
c. If the MSC rejects the MS preferred User Zone the MSC sends a User Zone 9
Reject message optionally with an alternate User Zone for the mobile to use. 10
Note, this message is sent only if the MSC rejects the MS preferred User 11
Zone. 12
d. The BS sends a User Zone Reject message to the MS. Included is the User 13
Zone information the MSC transmitted. 14
e. If the MSC wants to change the User Zone being used by the MSC, it sends 15
the User Zone Update message to the BS, including the new User Zone to be 16
used by the mobile. 17
f. The BS sends a User Zone Update message to the MS. Included is the User 18
Zone information the MSC transmitted. 19
3.15 ISDN Interworking Service 20
For ISDN interworking calls, normal call origination, call termination, handoff and call 21
clearing call flows are applied. These call flows are described in section 3.1.1, 3.1.2, 22
3.19.3, and 3.2. Refer to [14] for information on valid service options. 23
For ISDN interworking calls, the A2 interface carries unrestricted digital information of 24
user traffic between the MSC and the SDU. The SDU shall construct 64 kbps 25
Unrestricted Digital Information (UDI) data from RLP frames transmitted over the air-26
interface and shall construct RLP frames from 64 kbps unrestricted digital data received 27
from the MSC. 28
3GPP2 A.S0013-0 v2.0
Section 3 97
3.16 Circuit Data Calls 1
Normal call origination, call termination, and call clearing procedures apply. 2
Call flows associated with this feature are described in sections 3.1.1, 3.1.2, and 3.2. 3
4
5
3GPP2 A.S0013-0 v2.0
Section 3 98
3.17 3G Packet Data Calls 1
This section describes the procedures and call flows for packet support in the IOS. 2
3.17.1 Data Ready to Send (DRS) Indicator 3
As part of the support for the Dormant State, the TIA/EIA/IS-2000 air interface supports 4
a Data Ready to Send indicator that is used on Origination. When a mobile station sends 5
an origination request with a packet data service option specified, it includes the Data 6
Ready to Send (DRS) bit. This indicator is set to 1 on initial call setup and when the 7
terminal transitions from Dormant to Active because it has data to send and is requesting 8
the establishment of a traffic channel. The DRS bit is set to 0 to indicate that the terminal 9
has crossed a Packet Zone boundary while dormant, and is sending the origination 10
request to update the network as to its current location. On receipt of an origination with 11
the DRS bit set to 1, the BS initiates the call setup procedure as described in section 12
3.17.4.1, which normally results in the establishment of a traffic channel and in the A8 13
and A10 bearer connections being established. Note, traffic channels are not established 14
for Common Channel Packet Data (CCPD) Service. Refer to section 3.17.8.1.1 for the 15
call flow. 16
When the BS receives an origination with the DRS bit set to 0, the BS delays the 17
establishment of a traffic channel until after the A8 and A10 bearer connection 18
establishment procedures are complete. During the A8 bearer connection establishment 19
procedure, the BS indicates to the PCF that a DRS=0 has been received through the use 20
of the Data Ready Indicator element in the A9-Setup-A8 message. If the PCF has data 21
from the network to deliver to the terminal, it indicates this by setting the Cause element 22
in the A9-Connect-A8 message to the Data Ready to Send value. The BS then establishes 23
a traffic channel to the terminal and completes a normal call setup procedure as in 24
Section 3.17.4.1. 25
If the PCF does not have data, it indicates that the A8 is not to be established by sending 26
the A9-Release-A8 Complete message to the BS. The BS returns an Assignment Failure 27
message to the MSC with the Cause value set to Packet Call Going Dormant. Upon 28
receipt of the Assignment Failure message, the MSC returns a Clear Command to the BS 29
with the Cause value set to Do Not Notify Mobile. The BS sends a Clear Complete 30
message to the MSC upon receipt of the Clear Command message. 31
3.17.2 Previous and Current Access Network Identifiers 32
(PANID/CANID) 33
On detection of a new PZID, SID or NID, the MS sends an Origination Message or 34
Enhanced Origination Message to the target BS. The target BS forwards the received 35
PZID, SID and NID information to the PCF as the Previous Access Network Identifiers 36
(PANID). In the case of hard handoff, the source BS includes the Previous Access 37
Network Identifiers (PANID) in the Handoff Required message to the MSC. The MSC 38
forwards this information to the target BS in the Handoff Request message, which in turn 39
sends the received PANID to the PCF. The PCF includes the PANID received from the 40
target BS, along with the its own Current Access Node Identifiers (CANID) to the PDSN 41
as part of the A11-Registration Request message. The PDSN maintains the CANID 42
which is serving each connection and compares this against the PANID, received in the 43
A11-Registration Request message, to determine if it currently owns the call. If the 44
PDSN owns the call, it does not need to initiate or send agent advertisements. If the 45
PDSN does not own the call, then the PDSN needs to trigger PPP re-negotiation followed 46
3GPP2 A.S0013-0 v2.0
Section 3 99
by the sending of agent advertisement messages so that a new Foreign Agent / Home 1
Agent tunnel to the mobile can be setup properly. Upon a successful A11 registration, the 2
PDSN updates its stored CANID with the input CANID value received in the A11-3
Registration Request message (so it is up-to-date with the currently active PCF). 4
For an MS originated packet data call, the MS does not send the PANID and the PCF 5
sends only its CANID. The PDSN performs an agent advertisement and forces the mobile 6
to register with the Home Agent. For a dormant re-activation, the MS also does not send 7
the PANID; however, in this case registration is not required since the mobile has 8
previously registered. 9
3.17.3 PDSN Selection Algorithm 10
The following algorithm shall be used for initial PDSN assignment and PDSN reselection 11
in this standard. Each PCF maintains a configuration table with the address of all PDSNs 12
that are accessible from it as follows: 13
PDSN Number PDSN IP Address 14
0 a b c d 15
1 k l m n 16
... 17
N-1 w x y z 18
In the configuration table, the PDSNs are locally numbered from 0 to N-1 in ascending 19
order of PDSN IP addresses, N being the total number of entries in the table. In 20
configurations that support partial connectivity of PCFs and PDSNs, one or more 21
“dummy” entries for PDSNs are allowed in the table for those PDSNs that exist in the 22
network but are not accessible from the PCF. These dummy entries allow different PCFs 23
to resolve the same IMSI to the same PDSN. The PDSN IP address for such “dummy” 24
PDSN entries is set to 0 0 0 0. 25
For initial PDSN assignment and for PDSN reselection, the PCF shall determine which 26
PDSN to use for a particular mobile by the following PDSN Selection algorithm: 27
PDSN No. = (truncated Mobile IMSI) modulo N, 28
where (truncated Mobile IMSI) is defined to be the least significant 4 digits of the IMSI 29
(or MSIN) taken as a decimal value. 30
The IP address of the selected PDSN is obtained by indexing at the PDSN Number entry 31
in the configuration table. If the selected PDSN is not accessible by the PCF (PDSN IP 32
Address is all zeros, for example), the PCF shall select another PDSN by performing the 33
following algorithm, up to N-1 times, till a valid PDSN IP Address entry is found in the 34
configuration table. 35
PDSN No. = (PDSN No. +1 ) modulo N. 36
The PCF shall initiate establishment of the A10 connection with the selected PDSN. If 37
the selected PDSN responds with code ‘88H’ in the A11-Registration Reply, thereby 38
3GPP2 A.S0013-0 v2.0
Section 3 100
proposing another PDSN, the PCF may initiate establishment of the A10 connection with 1
the proposed PDSN. 2
3.17.4 A8/A9 Interface Call Flows 3
This section describes call flows for the A8/A9 interface. The following messages are 4
required to support the 3G packet data feature on the A8/A9 interface: 5
• A9-Setup-A8 6
• A9-Connect-A8 7
• A9-AL Connected 8
• A9-AL Connected Ack 9
• A9-Release-A8 10
• A9-Release-A8 Complete 11
• A9-Update-A8 12
• A9-Update-A8 Ack 13
• A9-Disconnect-A8 14
• A9-BS Service Request 15
• A9-BS Service Response 16
For procedures for A8 interface Setup, Release, Handoff, and Accounting, refer to [16]. 17
3.17.4.1 Mobile Initiated Initial Call Setup – Successful Operation 18
When an MS initiates a packet data call and PPP negotiation has not been initiated yet, 19
PPP negotiation is performed before transmitting packet data. 20
3GPP2 A.S0013-0 v2.0
Section 3 101
T10
BS MS
Origination
BS ACK Order
MSC
CM Service Request
A9-Setup-A8
Assignment Request
PCF PDSN
Assignment Complete
a
b
c
d
e
f
g
h
i
j
A10/A11
Connection
T303
TA8-Setup
Active Packet Data Session
Establishing PPP connection
IS-2000
TCH
A9-Connect-A8 (Anchor P-P Address)
1
Figure 3.17.4.1-1 Mobile Initiated Initial Call Setup – Successful Operation 2
a. The MS transmits an Origination Message (DRS=1), with layer 2 3
acknowledgment required, over the access channel of the air interface to the 4
BS to request packet data service. 5
b. The BS acknowledges the receipt of the Origination Message with a Base 6
Station Acknowledgment Order to the MS. 7
c. The BS constructs the CM Service Request message, places it in the Complete 8
Layer 3 Information message, sends the message to the MSC, and starts timer 9
T303. 10
d. The MSC sends an Assignment Request message to the BS to request 11
assignment of radio resources and starts timer T10. For packet data services a 12
terrestrial circuit between the MSC and the BSC is not required. The BS stops 13
timer T303. 14
e. The BS and the MS initiate the establishment of a radio traffic channel. 15
f. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator 16
set to 1 to establish an A8 connection and starts timer TA8-setup. 17
g. Procedure for establishing A10/A11 connection is performed. If the PDSN 18
supports Fast Handoff, the PDSN recognizes that it is the Anchor PDSN (PPP 19
3GPP2 A.S0013-0 v2.0
Section 3 102
terminates on this PDSN) and includes its Anchor P-P Address in the A11-1
Registration Reply message. 2
h. Upon establishment of the A10/A11 connection, the PCF establishes an A8 3
connection and transmits an A9-Connect-A8 Message with Cause Value set to 4
‘Successful Operation’. If PCF supports Fast Handoff, the PDSN provides the 5
Anchor PDSN Address and the Anchor P-P Address. The PCF supporting fast 6
handoff passes this information to BS as part of this message. 7
i. Upon receiving an A9-Connect-A8 message, the BS stops the timer TA8-setup 8
and transmits Assignment Complete message. The MSC stops timer T10. This 9
step may occur any time after radio link establishment. 10
j. PPP connection establishment procedure and Mobile IP Registration (if 11
required) on the PPP connection are performed between the MS and PDSN. 12
3.17.4.2 BS Initiated Call Release to Dormant State 13
This section describes the call flow associated with a BSC initiated packet service 14
deactivation (active-to-dormant state transition). In order to simplify the diagram, it is 15
assumed that for purposes of this example, the packet call is not in inter-BSC soft/softer 16
handoff prior to the deactivation and that the mobile does not have an active voice call in 17
progress. 18
Clear Request
Clear Complete
A9-Release-A8
Clear Command
A9-Release-A8 Complete
MS BS MSC/VLR PCF PDSN Time Comment
Active/PPP connected
Dormant/PPP connected
a
b
c
d
e
f
g
h
T300
T315
Trel9
TCH
Release
19
Figure 3.17.4.2-1 BS Initiated Call Release to Dormant State 20
a. While the packet data service option is connected, the BS should maintain a 21
packet data inactivity timer. The timer should be reset whenever non-idle RLP 22
data frames are sent or received. 23
3GPP2 A.S0013-0 v2.0
Section 3 103
b. If the packet data inactivity timer expires, the BS should release the Traffic 1
Channel. The BS sends a Clear Request message to the MSC to initiate the 2
call clear transaction, and starts timer T300. 3
c. The MSC starts timer T315 and sends a Clear Command message to the BS to 4
instruct the BSC to release the associated dedicated resources. The BS stops 5
timer T300. 6
d. BS initiates traffic channel release using existing procedures. 7
e. The BS then sends an A9-Release-A8 message, with a Cause value set to 8
“Packet call going Dormant”, to the PCF to instruct the PCF to release the 9
associated dedicated resources, and starts timer Trel9. Note that in this scenario 10
the A10/A11 connection is not released. 11
f. The PCF acknowledges the A9-Release-A8 message by returning an A9-12
Release-A8 Complete message. The BS stops timer Trel9. 13
g. The BS then returns a Clear Complete message to the MSC. The MSC stops 14
timer T315 and releases the underlying transport connection. Clear Complete 15
may occur any time after the traffic channel is released. 16
h. At this point, the MS is considered to be in the dormant state. 17
3.17.4.3 MS Initiated Call Release to Dormant State 18
This section describes the call flow associated with an MS deactivation (active-to-19
dormant state transition) initiated by MS. In order to simplify the diagram, it is assumed 20
that for purposes of this example, the packet call is not in inter-BS soft/softer handoff 21
prior to the deactivation and the mobile does not have an active voice call in progress. 22
3GPP2 A.S0013-0 v2.0
Section 3 104
Release Order
MS BS MSC/VLR PCF PDSN Time Comment
Clear Request
Clear Command
Clear Complete
A9-Release-A8 Complete
Active / PPP connected
Dormant / PPP connected
a
b
c
d
e
f
g
h
i
A9-Release-A8
T300
Trel9
TCH
Release
1
Figure 3.17.4.3-1 MS Initiated Call Release to Dormant State 2
a. The mobile maintains a packet data inactivity timer. The timer is reset 3
whenever a non-idle RLP data frame is sent or received. 4
b. If the packet data inactivity timer expires, the mobile requests the BS to 5
disconnect the traffic channel. The MS sends a Release Order with “ORDQ = 6
00000000”, to the BS to request a transition to the dormant state. 7
c. The BS then sends a Clear Request message to the MSC to initiate the call 8
clear transaction, and starts timer T300. 9
d. The MSC sends a Clear Command message to the BS to instruct the BS to 10
release the associated dedicated resources and starts timer T315. The BS stops 11
timer T300. 12
e. BS initiates traffic channel release using existing procedures. 13
f. The BS then sends an A9-Release-A8 message, with a Cause value set to 14
“Packet call going Dormant”, to the PCF to instruct the PCF to release the 15
associated dedicated resources, and starts timer Trel9. Note that in this scenario 16
the A10/A11 connection is not released. 17
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-18
Release-A8 Complete. The BS stops timer Trel9. 19
3GPP2 A.S0013-0 v2.0
Section 3 105
h. The BS then returns a Clear Complete message to the MSC. The MSC 1
releases the underlying transport connection and stops timer T315. Clear 2
Complete may occur any time after the traffic channel is released. 3
i. At this point, the MS is considered to be in the dormant state. 4
3.17.4.4 MS Power Down 5
This section describes the call flow associated with a packet call release initiated by an 6
MS power down. 7
MS BS MSC/VLR PCF PDSNTime Comment
Clear Request
Clear Command
Release Order
Release Order
Clear Complete
A9-Release-A8 Complete
a
b
c
d
e
f
g
h
A9-Release-A8
A10/A11 ConnectionRelease Procedure
T300
T315
Trel9
8
Figure 3.17.4.4-1 MS Power Down 9
a. The MS powers down causing a packet data session to terminate. It sends a 10
Release Order to the BS with a power down indication. 11
b. The BS then sends a Clear Request message to the MSC to initiate the call 12
clear transaction, and starts timer T300. 13
c. The MSC sends a Clear Command message to the BS to instruct the BS to 14
release the associated dedicated resources and starts timer T315. The BS stops 15
timer T300. 16
d. In response to the Clear Command message, the BS acknowledges the MS by 17
sending it a Release Order and releases the radio resource. 18
e. The BS then sends an A9-Release-A8 message with a Cause value set to 19
“Normal Call Release” to the PCF to instruct the PCF to release the associated 20
dedicated resource, and to release the associated A10 connection. The BS 21
starts timer Trel9. 22
f. The PCF initiates the procedure for releasing the A10/A11 connection. Refer 23
to Section 3.17.5.6 for details. 24
3GPP2 A.S0013-0 v2.0
Section 3 106
g. The PCF then sends an A9-Release-A8 Complete message to the BS. The BS 1
stops timer Trel9. 2
h. The BS returns a Clear Complete message to the MSC. The MSC releases the 3
underlying transport connection and stops timer T315. Clear Complete may 4
occur any time after the traffic channel is released. 5
3.17.4.5 PDSN Initiated Service Release 6
This section describes the call flow associated with a packet service release initiated by 7
PDSN. It is assumed that the mobile does not have an active voice call in progress. 8
= MS BS MSC/VLR PCF PDSN Time Comment
Clear Request
Clear Command
Clear Complete
A9-Disconnect-A8
a
b
c
d
e
f
g
A9-Release-A8
A10/A11 Connection Release Procedure
A9-Release-A8 Complete
h
Tdiscon9
Trel9
T300
T315 TCH
Release
9
Figure 3.17.4.5-1 PDSN Initiated Service Release 10
a. When the packet service is released by the PDSN (e.g., because of PPP 11
termination), the A10/A11 connection is released. 12
b. When the PCF recognizes that the A10/A11 connection is released, the PCF 13
sends an A9-Disconnect-A8 message to the BS and starts timer Tdiscon9. 14
c. The BS initiates release of the A8 connection by transmitting an A9-Release-15
A8 message and starts timer Trel9. The PCF stops timer Tdiscon9. 16
d. The PCF acknowledges the A9-Release-A8 message by returning an A9-17
Release-A8 Complete. The BS stops timer Trel9. 18
e. The BS the sends a Clear Request message to the MSC to initiate call clearing 19
transaction, and starts timer T300. 20
f. The MSC sends a Clear Command message to the BS to instruct the BS to 21
release the associated dedicated resources and starts timer T315. The BS stops 22
timer T300. 23
3GPP2 A.S0013-0 v2.0
Section 3 107
g. In response to the Clear Command message, the BS initiates call clearing over 1
the air interface by transmitting a Release Order. 2
h. The BS then returns a Clear Complete message to the MSC. The MSC stops 3
timer T315 and releases the underlying transport connection. Clear Complete 4
may occur any time after the traffic channel is released. 5
3.17.4.6 MS Initiated Call Re-Activation from Dormant State 6
Once in the dormant state, a packet data call is reconnected by the MS by including a 7
packet data call specific service option in an Origination Message with DRS bit set to ‘1’. 8
The PPP and MIP sessions need not be re-established. That is, the A10/A11 connection 9
need not be re-established. In all other respects, this call is no different than a normal A8 10
connection setup procedure. 11
3.17.4.7 Network Initiated Call Re-Activation from Dormant State 12
Once in the dormant state, a packet data call is reconnected by the PCF by sending an 13
A9-BS Service Request message containing a packet data call specific service option to 14
the BS. The BS acknowledges the request by sending the A9-BS Service Response 15
message to the PCF and initiates a normal BS initiated call setup. 16
This section describes the call flow example associated with the establishment of an A8 17
connection upon dormant state to active state transition. In this scenario: 18
1. The MS has already performed MIP registration (if required) and established a 19
PPP connection with the PDSN. 20
2. The A8 (User Traffic) connection between the PCF and the BSC does not 21
exist. 22
3. The mobile does not have an active voice call in progress. 23
Note, if the MS performed an Intra-PCF dormant mode handoff, the target BS that 24
initiates the A8 connection setup may be different than the source BS that was initially 25
contacted by the PCF. 26
The PDSN sends data packets to the PCF on an existing A10 connection. The following 27
call flow diagram provides an illustration for a successful packet termination procedure. 28
3GPP2 A.S0013-0 v2.0
Section 3 108
Assignment Complete
CommentMS Time
a
b
c
d
e
f
g
h
iComplete L3 info:Paging Response
Page Response Message
Assignment Request
A9-Setup-A8
A9-Connect-A8
BS Ack Order
IS-2000 TchSetup
Active Packet Data Session
j
TA8-Setup
T303
T10
Packet Data
A9-BS Service Request
BS Service Request
BS Service Response
A9-BS Service Response
Paging Request
Page Message
BS MSC / VLR PDSNPCF
Tbsreq9T311
T3113
K
l
m
n
o
Dormant, PPP connection is maintained
1
Figure 3.17.4.7-1 Network Initiated Call Re-Activation from Dormant State 2
a. The PDSN sends data packets to the BS on an existing PPP connection and 3
A10 connection associated with a specific mobile for packet service. 4
b. The PCF sends an A9-BS Service Request message to the BS in order to 5
request packet service, and starts timer Tbsreq9. 6
c. The BS sends a BS Service Request message to the MSC, and starts timer 7
T311, in order to reconnect the call. 8
d. The MSC acknowledges the call setup request by sending a BS Service 9
Response message to the BS. Upon receipt of the BS Service Response 10
message from the MSC, the BS stops timer T311. 11
e. The BS responds with A9-BS Service Response. The PCF stops timer Tbsreq9 12
upon receipt of the A9-BS Service Response message. 13
3GPP2 A.S0013-0 v2.0
Section 3 109
f. The MSC sends a Paging Request message to establish a mobile terminated 1
packet data call, and starts timer T3113. 2
g. The BS issues a Page message containing the MS address over the paging 3
channel. 4
h. The MS acknowledges the page by transmitting a Page Response message 5
over the access channel. 6
i. The BS constructs the Paging Response message, places it in Complete Layer 7
3 Information message, sends the message to the MSC, and starts timer T303. 8
The MSC stops timer T3113 upon receipt of the Paging Response message 9
from the BS. 10
j. The BS acknowledges the receipt of the Page Response message with a BS 11
Ack order to the MS. 12
k. The MSC sends an Assignment Request message to the BS to request 13
assignment of radio resources and the A8 (User Traffic) connection between 14
the BS and the PCF. The MSC then starts timer T10. 15
Upon receipt of the Assignment Request message from the MSC, the BS stops 16
timer T303. 17
l. The BS and the MS perform radio resources setup procedure. 18
m. The BS sends A9-Setup-A8 message to the PCF to establish A8 (User Traffic) 19
connection between the BS and the PCF, over the A9 (Signaling) connection. 20
The BS then starts timer TA8-Setup. Note: if the MS performed an intra-PCF 21
dormant mode handoff, the BS sending this message may not be the same BS 22
that was initially contacted by the PCF. 23
n. The PCF responds with A9-Connect-A8 message to complete the setup of A8 24
(User Traffic) connection for this packet service request. If Fast Handoff is 25
supported, the PCF passes the Anchor P-P Address to the BSC as part of this 26
message. Upon receipt of the A9-Connect-A8 message from the PCF, the BS 27
stops timer TA8-Setup. 28
o. After the radio link and the A8 connection have been established, the BS 29
sends an Assignment Complete message to the MSC. The MSC stops timer 30
T10. 31
3.17.4.8 Mobile Terminated Packet Data Rejection During a Voice Call 32
This procedure is only applicable to the cases that the MS is operating with protocol 33
revision less than 7 or the BS and/or the MSC does not support concurrent services. The 34
following call flow diagram provides an illustration for rejection of packet data 35
termination during a voice call. 36
3GPP2 A.S0013-0 v2.0
Section 3 110
A9-BS Service Response (Cause: “MS Busy”)
Time Comment
a
b
c
d
e
Dormant, PPP connection is maintained
Packet Data
A9-BS Service Request
BS Service Request
BS Service Response
MS BS MSC / VLR PDSN PCF
Tbsreq9 T311
voice call
voice call
Dormant
1
Figure 3.17.4.8-1 Mobile Terminated Packet Data Rejection During a Voice Call 2
a. It is assumed that the MS has performed MIP registration (if required) and 3
established a PPP connection. Packet data arrives at the PDSN and is sent on 4
the A10 connection to the PCF. 5
b. The PCF sends A9-BS Service Request message to the BS in order to request 6
packet service, and starts timer Tbsreq9. 7
c. The BS sends a BS Service Request message to the MSC, and starts timer 8
T311. 9
d. The MSC sends a BS Service Response message with cause value ‘MS Busy’ 10
to the BS. The BS stops timer T311 upon receipt of the BS Service Response 11
message. 12
e. The BS sends an A9-BS Service Response message to the PCF containing a 13
the cause value “MS Busy.” The PCF stops timer Tbsreq9 upon receipt of the 14
A9-BS Service Response message and should wait to resend A9-BS Service 15
Request message. The amount of time to wait to resend is an implementation 16
issue. 17
3.17.4.9 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN 18
The following call flow diagram provides an illustration for a successful handoff during 19
Dormant state from source PCF to target PCF. It is assumed that the PCF is uniquely 20
identified by the CANID. On detection of a new PZID, NID or SID, the MS sends an 21
Origination Message to the target BS that includes the packet data service option. The 22
Origination Message includes the previous PZID, NID and SID when any of these 23
parameters change during the dormant handoff. Based on the IDs (PZID, NID and/or 24
SID) in the Origination Message, the target PCF sends the PANID of the source PCF and 25
3GPP2 A.S0013-0 v2.0
Section 3 111
the CANID of the target PCF to the serving PDSN. The serving PDSN uses this 1
information to determine whether or not PPP re-negotiation is required. 2
The BS does not establish a traffic channel when it receives an origination with DRS set 3
to ‘0’; a traffic channel may be established after the completion of setup of the A8 and 4
A10 bearer connections. 5
Assignment Req
Source BS MSC Source PCF
Time Comment
a
b
c
d
e
f
g
h
i
PDSN Target PCF MS
CM Service Req
Origination Message
A9-Setup-A8
A9-Release-A8 Complete
Assignment Failure
BS Ack Order
Dormant, PPP connection is maintained
TA8-setup
Target BS
T303
T10 PDSN Dormant HO
j
k
Clear Command
Clear Complete
T20
T315
l Dormant Packet Data Session
6
Figure 3.17.4.9-1 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN 7
a. It is assumed that the MS has performed a MIP registration (if required) and 8
established a PPP connection with the PDSN but is now dormant. The mobile 9
does not have an active voice call in progress. 10
b. The dormant mobile detects a change of PZID, SID or NID while monitoring 11
the broadcast channel and initiates an origination with the DRS bit set to ‘0’. 12
c. Target BS acknowledges the receipt of the Origination Message with a Base 13
Station Ack Order to the MS. 14
d. Target BS constructs the CM Service Request message, places it in the 15
Complete Layer 3 Information message, sends message to the MSC and starts 16
timer T303. 17
e. The MSC sends an Assignment Request message to the target BS to request 18
assignment of radio resources and starts timer T10. On receipt of the 19
Assignment Request message, the BS stops timer T303. 20
3GPP2 A.S0013-0 v2.0
Section 3 112
f. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set 1
to ‘0’, to the target PCF and starts timer TA8-setup. The handoff indicator of the 2
A9 Indicators IE shall be set to ‘0’. 3
g. The target PCF establishes the A10/A11 link and the PDSN disconnects the 4
old A10/A11 link (refer to procedure in section 3.17.5.8). (If the PDSN has 5
data for the mobile, it responds to the PCF with a Registration Reply message 6
with the Data Available Indicator in the Vendor/Organization Specific 7
Extension.) 8
h. The PCF responds to the BS with an A9-Release-A8 Complete message. The 9
BS stops timer TA8-setup. 10
If the PDSN responds to the PCF with a Data Available Indicator, the PCF 11
responds to the BS with an A9-Connect-A8 message with Cause element set 12
to Data Ready to Send. In this case, the BS establishes a traffic channel and 13
continues as in steps g-j in Figure 3.11.4.2.1-1. In this case, the remaining 14
steps in this procedure are omitted. 15
i. The BS sends the Assignment Failure message to the MSC with Cause value 16
indicating Packet Call Going Dormant and starts timer T20. The MSC stops 17
timer T10. 18
j. The MSC sends a Clear Command to BS with Cause value ‘Do Not Notify 19
Mobile’ and starts timer T315. Upon receipt of the Clear Command, the BS 20
stops timer T20. The BS sends a Clear Complete message to the MSC. 21
k. The MSC stops timer T315 upon receipt of the Clear Complete message. 22
l. The packet data session remains dormant 23
3.17.4.10 Dormant Handoff (Inter-BSC/Inter-PCF) - Mobile Served by a Different PDSN 24
When an MS in dormant state moves into a different packet zone and ends up being 25
connected to a different PDSN, the target PCF is required to forward the ANID of the 26
source PCF (PANID) and the ANID of the target PCF (CANID) to the serving PDSN. 27
PPP negotiation is performed. 28
3GPP2 A.S0013-0 v2.0
Section 3 113
BS MS
Origination
BS ACK Order
MSC
CM Service
A9-Setup-A8
Assignment Request
Target PCF
Target
PDSN
A9-Connect-A8
Assignment Complete
Establishing PPP connection
a
b
c
d
e
f
g
h
i
j
T303
T10
TA8-Setup A10/A11
Connection
Establishment
A9-Update-A8
A9-Update-A8 Ack Tupd9
k
l
TCH
Establishment
Time
A10/A11
Accounting
1
Figure 3.17.4.10-1 Dormant Handoff (Inter-BSC/Inter-PCF) - Mobile Served by a Different PDSN 2
a. The dormant mobile detects a change of PZID, SID or NID while monitoring 3
the broadcast channel and initiates an origination with the DRS bit set to ‘0’. 4
b. The BS acknowledges the receipt of the Origination Message with a Base 5
Station Acknowledgment Order to the MS. 6
c. The BS constructs the CM Service Request message, places it in the Complete 7
Layer 3 Information message, sends the message to the MSC, and starts timer 8
T303. 9
d. The MSC sends an Assignment Request message to the BS to request 10
assignment of radio resources and starts timer T10. For packet data services, a 11
terrestrial circuit between the MSC and the BS is not required. The BS stops 12
timer T303. 13
e. The BS transmits an A9-Setup-A8 message to the PCF, with DRS=‘0’, to 14
establish an A8 connection and starts timer TA8-setup. The Handoff Indicator 15
of the A9 Indicators IE shall be set to ‘0’. 16
3GPP2 A.S0013-0 v2.0
Section 3 114
f. Procedure for establishing A10/A11 connection is performed. 1
g. Upon establishment of the A10 connection, the PCF establishes an A8 2
connection and transmits an A9-Connect-A8 Message with Cause set to Data 3
Ready to Send. If Fast Handoff is supported, the PCF passes the Anchor P-P 4
Address to the BS as part of this message. Upon reception of the A9-Connect-5
A8 message, the BS stops the timer TA8-setup. 6
h. The BS initiates the establishment of a radio traffic channel. 7
i. After the radio link is established, the BS sends an Assignment Complete 8
message to the MSC. The MSC stops timer T10. This step may occur any time 9
after radio link establishment. 10
j. The BS sends an A9-Update-A8 message to the PCF to pass Accounting 11
Parameters. The BS starts timer Tupd9. The A10/A11 Accounting Procedure is 12
performed. 13
k. The PCF, upon receipt of the A9-Update-A8 message, responds with an A9-14
Update-A8 Ack message. Upon receipt of this message, the BS stops timer 15
Tupd9. 16
l. PPP connection establishment procedure and Mobile IP Registration (if 17
required) on the PPP connection are performed between the MS and PDSN. 18
3.17.4.11 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 19
Authentication in MSC Following Assignment Failure. (TCH is Established) 20
The following call flow diagram provides an illustration for a handoff during Dormant 21
state from source PCF to target PCF. It is assumed that the PCF has only one PZID, SID 22
or NID. The BS does not immediately establish a traffic channel when it receives an 23
origination with DRS set to ‘0’. 24
The MSC may start its authentication procedure using the authentication data received in 25
the CM Service Request and in parallel instructs the BSC to assign necessary resources 26
via the Assignment Request message. 27
The BS communicates with the PCF to setup an A10 connection. The PCF establishes the 28
A10 connection and notifies the BSC that a traffic channel and an A8 connection are 29
necessary. This is a result of the PDSN indicating that it has data to send in the A11-30
Registration Reply. The BSC then sends an Assignment complete to the MSC after 31
successful establishment of the traffic channel. Meanwhile, the MSC is still waiting for 32
the authentication results to come back from the authentication center. The results are 33
received indicating that the authentication has failed. The MSC initiates a clear request 34
and the release indicator indicating “authentication failed”. The BSC triggers an A9-35
release-A8 message to the PCF containing a cause value set to “authentication failed”. 36
The PCF starts releasing the A10 connection by sending an A11-Registration Request 37
containing the failure indication within the air-link record information. NOTE: The same 38
procedure is applicable to the initial origination and reactivation from dormant state. 39
The above scenario is illustrated in the following diagram. 40
3GPP2 A.S0013-0 v2.0
Section 3 115
1
A9-Release-A8
Assignment Req
Source BS MSC
Source PCF
Time Comment
a
b
c
d
e
f
g
h
i
PDSN Target PCF MS
CM Service Req
Origination Message
A9-Setup-A8
A9-Connect-A8
Assignment Complete
BS Ack Order
Dormant, PPP connection is maintained
TA8-Setup
Target BS
T303
T10
PDSN Dormant HO
Active Packet Data Session
j
k
Authentication results received
indicating failure
A10 Release
Clear Command. (Auth. Failed )
A9-Release-A8 Complete
Clear Complete
l
m
n
p
TCH establishment
TCH release
A9-Update-A8
A9-Update-A8 Ack
A10/A11 Accounting
q
r
s
o
2
Figure 3.17.4.11-1 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 3
Authentication in MSC Following Assignment Failure. (TCH is Established) 4
a. It is assumed that the MS has performed a MIP registration (if required) and 5
established a PPP connection with PDSN but is now dormant. 6
b. The dormant mobile detects a change of PZID, SID or NID while monitoring 7
the broadcast channel and initiates an origination with the DRS bit set to 0. 8
3GPP2 A.S0013-0 v2.0
Section 3 116
c. Target BS acknowledges the receipt of the Origination Message with a Base 1
Station Ack Order to the MS. 2
d. Target BS constructs the CM Service Request message, places it in the 3
Complete Layer 3 Information message, sends message to the MSC and starts 4
timer T303. The CM request includes authentication data. 5
e. The MSC sends an Assignment Request message to the target BS to request 6
assignment of radio resources and starts timer T10. On receipt of the 7
Assignment Request message, the BS stops timer T303. The MSC starts an 8
authentication procedure and waits for the results. 9
f. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set 10
to 0, to the target PCF and starts timer TA8-setup. 11
g. The target PCF establishes the A10/A11 link and the PDSN disconnects the 12
old A10/A11 link (refer to procedure in 3.11.5.5.8). (In this scenario, the 13
PDSN has data for the mobile and it responds to the PCF with a Registration 14
Reply message with Data Available Indicator in the Vendor/Organization 15
Specific Extension.) 16
h. The PCF responds to the BS with an A9-Connect-A8 message and indicates 17
that a traffic channel is required. If Fast Handoff is supported, the PCF passes 18
the Anchor P-P Address to the BS as part of this message. The BS stops timer 19
TA8-setup. 20
i. The BS sends the Assignment Complete message to the MSC after 21
successfully establishing the traffic channel. The MSC stops timer T10. 22
j. The target BS sends an A9-Update-A8 message to the target PCF to pass 23
Accounting Parameters. The BS starts timer Tupd9. 24
k. A10/A11 Accounting Procedure is performed. 25
l. The PCF, upon receipt of the A9-Update-A8 message, responds with an A9-26
Update-A8 Ack message. Upon receipt of this message, the BS stops timer 27
Tupd9. 28
m. The packet data session is active. 29
n. The MSC receives the authentication result from the authentication center 30
indicating that the authentication has failed. It thus sends a Clear Command 31
message to the BS indicating that authentication has failed. 32
o. The BS releases the traffic channel by sending a Release Order to the MS 33
indicating “Service Option Rejected”. 34
p. The BS informs the PCF via an A9-Release-A8 message containing an update 35
reason parameter indicating “authentication failed”. 36
q. The PCF starts the A10 release procedure using “authentication failed for 37
dormant packet call” as a release indicator in the air-link record within the 38
A11-Registration Request with lifetime=0. 39
r. At response from the PDSN, the PCF sends an A9-Release-A8 complete 40
message back to the BS. 41
s. The BS sends a Clear Complete message back to the MSC indicating that 42
resources for the packet data call have been released. 43
3GPP2 A.S0013-0 v2.0
Section 3 117
3.17.4.12 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 1
Authentication in MSC Following Assignment Failure. (No TCH Established) 2
This scenario is similar to the 3.11.4.11 except that a TCH is not established during the 3
dormant handoff procedure. Furthermore, if the authentication results are available before 4
the MSC sends the clear command to the BS, the MSC issues a clear command with 5
“authentication failure” cause value. The BS then uses the A9-Update-A8 message to 6
alert the PCF that it should tear down the A10 connection for that mobile. 7
8
A9-Update-A8
Assignment Req
Source BS MSC Source PCF
Time Comment
a
b
c
d
e
f
g
h
i
PDSN Target PCF MS
CM Service Req
Origination Message
A9-Setup-A8
A9-Release-A8-Complete
Assignment Failure
BS Ack Order
Dormant, PPP connection is maintained
TA8-Setup
Target BS
T303
T10
PDSN Dormant HO
j
k Authentication
Results Received
A10 Release
Clear Command. (Auth. Failed)
Clear Complete
m
n
o
p
A9-Update-A8 Ack
Release Order l
9
Figure 3.17.4.12-1 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Failed 10
Authentication in MSC Following Assignment Failure (No TCH Established) 11
a. It is assumed that the MS has performed a MIP registration (if required) and 12
established a PPP connection with the PDSN but is now dormant. 13
3GPP2 A.S0013-0 v2.0
Section 3 118
b. The dormant mobile detects a change of PZID, SID or NID while monitoring 1
the broadcast channel and initiates an origination with the DRS bit set to ‘0’. 2
c. Target BS acknowledges the receipt of the Origination Message with a Base 3
Station Ack Order to the MS. 4
d. Target BS constructs the CM Service Request message, places it in the 5
Complete Layer 3 Information message, sends message to the MSC and starts 6
timer T303. The CM Service Request includes authentication data. 7
e. The MSC sends an Assignment Request message to the target BS to request 8
assignment of radio resources and starts timer T10. On receipt of the 9
Assignment Request message, the BS stops timer T303. The MSC starts an 10
authentication procedure and waits for the results. 11
f. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set 12
to 0, to the target PCF and starts timer TA8-setup. 13
g. The target PCF establishes the A10/A11 link and the PDSN disconnects the 14
old A10/A11 link (refer to procedure in 3.11.5.5.8). (The PDSN does not have 15
data for the mobile.) 16
h. The PCF responds to the BS with an A9-Release-A8-Complete message since 17
there is no need for a TCH. The BS stops timer TA8-setup. 18
i. The BS sends the Assignment Failure message to the MSC indicating “packet 19
call going dormant”. The MSC stops timer T10. 20
j. The packet data session is dormant. 21
k. The MSC receives the authentication result from the authentication center 22
indicating that the authentication has failed prior to sending the clear 23
command message. It thus sends a Clear Command message to the BS 24
indicating that authentication has failed. 25
l. The BS sends a Release Order to the MS indicating “Service Option 26
Rejected”. 27
m. The BS informs the PCF via an A9-Update-A8 message containing an update 28
reason parameter indicating “authentication failed”. 29
n. The PCF starts the A10 release procedure using “authentication failed for 30
dormant packet call” as a release indicator in the air-link record within the 31
A11-Registration Request with lifetime=’0’. 32
o. At response from the PDSN, the PCF sends an A9-Update-A8 Ack message 33
back to the BS. 34
p. The BS sends a Clear Complete message back to the MSC indicating that 35
resources for the packet data call have been released. 36
3.17.4.13 Soft / Softer Handoff Packet Data 37
Call flows for soft/softer handoff of the FCH, DCCH, and SCH are explained in Section 38
3.19.2. 39
3.17.4.14 Inter-BS Hard Handoff (Within the Same PCF) 40
The following call flow diagram provides an illustration for a successful hard handoff 41
event during packet data services. In order to simplify the diagram, it is assumed that for 42
3GPP2 A.S0013-0 v2.0
Section 3 119
purposes of this example, the packet call is not in inter-BS soft/softer handoff prior to the 1
handoff, and no other service options are connected. 2
MS Source BS MSC Time Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Target BS
T9
h
j
i
k
l
m
n
T306
T315
Twaitho
x
PCF PDSN
A9-Setup-A8
A9-Connect-A8
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
T7
Handoff Completion
A9-AL Connected
A9-AL Connected Ack
Handoff Complete
Clear Command
A9-Release-A8
A9-Release Complete-A8
Clear Complete
MS Ack Order
BS Ack Order
o
p
q
r
Talc9
Twaitho9
A9-AL Disconnected
s
A9-AL Disconnected Ack
t
Tald9
TA8-Setup
Tre19
3
Figure 3.17.4.14-1 Inter-BS Hard Handoff (Within the Same PCF) 4
a. Based on an MS report that it crossed a network specified threshold for signal 5
strength or for other reasons, the source BS recommends cdma2000 to 6
cdma2000 hard handoff to one or more cells in the domain of the target BS. 7
The source BS sends a Handoff Required message with the list of cells to the 8
MSC and starts timer T7. 9
b. The MSC sends a Handoff Request message to the target BS with a hard 10
handoff indicator. 11
c. The target BS sends an A9-Setup-A8 message to the PCF and starts timer 12
TA8-Setup, in order to establish the A8-Connection. In this case, the handoff 13
indicator field of the A9-Setup-A8 message is set to ‘1’ (during handoff). 14
d. Upon receipt of the A9-Setup-A8 message from the target BS, the PCF 15
establishes the A8 connection. At this point of time, the PCF continues to 16
forward packet data received from PDSN to the source BS (i.e., the target BS 17
doesn’t receive packet data from the PCF). Then the PCF sends the A9-18
3GPP2 A.S0013-0 v2.0
Section 3 120
Connect-A8 message and starts timer Twaitho9. When the target BS receives 1
the A9-Connect-A8 message it stops timer TA8-Setup. 2
The establishment of the A10/A11 connection is not performed because the 3
handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during 4
handoff). 5
e. The target BS sends a Handoff Request Acknowledgment message to the 6
MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio 7
channel. 8
f. The MSC prepares to switch from the source BS to the target BS and sends a 9
Handoff Command to the source BS. The source BS stops timer T7. 10
g. The PCF stops packet transmission to the source BS upon receipt of A9-AL 11
(Air Link) Disconnected from source BS. At this point in time, the source BS 12
starts timer Tald9. 13
h. The PCF sends an A9-AL (Air Link) Disconnected Ack message in response 14
to the A9-AL Disconnected message. The BS stops timer Tald9. 15
i. The source BS sends the General Handoff Direction Message or Universal 16
Handoff Direction Message to the MS across the air interface. If the MS is 17
allowed to return to the source BS, then timer Twaitho is started by the source 18
BS. 19
j. The MS may acknowledge the General Handoff Direction Message or 20
Universal Handoff Direction Message by sending an MS Ack Order to the 21
source BS. 22
If the General Handoff Direction Message or Universal Handoff Direction 23
Message is sent using quick repeats, the source BS might not request an 24
acknowledgment from the MS. 25
k. The source BS sends a Handoff Commenced message to the MSC to notify it 26
that the MS has been ordered to move to the target BS channel. The source BS 27
starts timer T306 to await the Clear Command message from the MSC. If timer 28
Twaitho has been started, the source BS shall wait for that timer to expire 29
before sending the Handoff Commenced message. 30
l. The MS sends a Handoff Completion message to the target BS. The target BS 31
detects that the MS has successfully accessed the target BS and stops timer 32
T9. 33
m. The target BS sends the BS Ack Order to the MS over the air interface. 34
n. Upon the receipt of the Handoff Completion message from MS, the target BS 35
sends a Handoff Complete message to the MSC to notify it that handoff has 36
been successfully completed. However, if timer T9 expires before the target 37
BS detects that the MS has successfully accessed the target BS, the target BS 38
shall send a Handoff Failure message to the MSC. Refer to [16] for detailed 39
procedures. 40
o. The target BS sends an A9-AL (Air Link) Connected message to the PCF and 41
starts timer Talc9. In the case of packet data handoff only this message can be 42
sent any time after step (l). Then the PCF stops timer Twaitho9, updates its 43
routing table to route packet data sent from PDSN to the target BS and restarts 44
packet data transmission to the target BS. In this case, PCF does not perform 45
the A10/A11 connection establishment procedure because the A10/A11 46
connection has already been established. 47
3GPP2 A.S0013-0 v2.0
Section 3 121
p. The PCF sends the A9-AL (Air Link) Connected Ack as the response of the 1
A9-AL (Air Link) Connected message and stops timer Talc9. If timer Talc9 is 2
expired, the target BS may resend the A9-AL Connect message. 3
q. The MSC sends a Clear Command to the source BS and starts timer T315. The 4
source BS stops timer T306. 5
r. The source BS sends an A9-Release-A8 message to the PCF in order to 6
release the A8-Connection and starts timer Tre19. 7
s. Upon the receipt of the A9-Release-A8 message from the source BS, the PCF 8
releases the A8-Connection and responds with an A9-Release-A8 Complete 9
message. Upon receiving A9-Release-A8 message the source BS stops timer 10
Tre19. 11
t. The source BS sends a Clear Complete message to the MSC to notify it that 12
clearing has been accomplished. The MSC stops timer T315. Clear Complete 13
may occur any time after the traffic channel is released. 14
3.17.4.15 Inter-PCF Hard Handoff (Within Same PDSN) 15
The following call flow diagram provides an illustration for a successful hard handoff 16
event from a cdma2000 system to another cdma2000 system during packet data services. 17
In order to simplify the diagram, it is assumed that for purposes of this example, the 18
packet call is not in inter-BS soft/softer handoff prior to the handoff, and no other service 19
options are connected. This call flow shows the case of hard handoff without Fast 20
Handoff. For Fast Handoff, see the call flow in section 3.19.4. 21
The PANID is communicated to the target BS via the Handoff Required/Requested 22
messages and is subsequently sent to target PCF via the A9-AL-Connected message. The 23
source BS had originally been informed of the triplets associated with the source PCF via 24
the A9-Connect-A8 message. The target PCF inserts its own triplet (CANID) and 25
communicates both sets of access parameter identifiers to the PDSN. 26
3GPP2 A.S0013-0 v2.0
Section 3 122
MS Source BS MSC Time Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
T9
h
j
i
k
l
m
n
T306
T315
Twaitho
x
Source PCF
PDSN
A9-Setup-A8
A9-Connect-A8
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
T7
Handoff Completion
A9-AL Connected
A9-AL Connected Ack
Handoff Complete
Clear Command
A9-Release-A8
A9-Release-A8 Complete
Clear Complete
S Ack Order
BS Ack Order
o
p
q
r
Target PCF
Target BS
s
t
Talc9
Twaitho9
A9-AL Disconnected
u
A9-AL Disconnected Ack Tald9
TA8-Setup
Tre19
PDSN HO Procedures
1
Figure 3.17.4.15-1 Inter-PCF Hard Handoff (Within Same PDSN) 2
a. Based on an MS report that it crossed a network specified threshold for signal 3
strength, changes to a different ANID or for other reasons, the source BS 4
recommends cdma2000 to cdma2000 hard handoff to one or more cells in the 5
domain of the target BS. The source BS sends a Handoff Required message 6
with the list of cells to the MSC and starts timer T7. The source BS includes 7
the PANID information in the handoff required message. 8
b. The MSC sends a Handoff Request message (which includes the PANID 9
information previously communicated to the MSC via the Handoff Required 10
message) to the target BS with a hard handoff indicator (e.g., Handoff Type 11
element in the message indicating hard handoff). 12
c. The target BS sends an A9-Setup-A8 message to the target PCF in order to 13
establish the A8 connection and starts timer TA8-Setup. In this case, the 14
handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during 15
handoff). 16
3GPP2 A.S0013-0 v2.0
Section 3 123
d. Upon receipt of the A9-Setup-A8 message from the target BS, the target PCF 1
establishes the A8 connection. At this point of time, the PDSN continues to 2
forward packet data to the source BS via source PCF. (I.e., The target BS and 3
target PCF don’t receive packet data from the PDSN.). Then the target PCF 4
sends the A9-Connect-A8 message and starts timer Twaitho9. When the target 5
BS receives the A9-Connect-A8 message it stops timer TA8-Setup. 6
The establishment of the A10/A11 connection is not performed because the 7
handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during 8
handoff). 9
e. The target BS sends a Handoff Request Acknowledgment message to the 10
MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio 11
channel. 12
f. The MSC prepares to switch from the source BS to the target BS and sends a 13
Handoff Command to the source BS. The source BS stops timer T7. 14
g. The PCF stops packet transmission to the source BS upon receipt of A9-AL 15
(Air Link) Disconnected from the source BS. At this point of time, the source 16
BS starts timer Tald9. 17
h. The PCF sends A9-AL Disconnected Ack message as a response to the A9-18
AL (Air Link) Disconnected message. The BS stops timer Tald9. 19
i. The source BS sends the General Handoff Direction Message or Universal 20
Handoff Direction Message to the MS across the air interface. If the MS is 21
allowed to return to the source BS, then timer Twaitho is started by the source 22
BS. 23
j. The MS may acknowledge the General Handoff Direction Message or 24
Universal Handoff Direction Message by sending an MS Ack Order to the 25
source BS. If the General Handoff Direction Message or Universal Handoff 26
Direction Message is sent using quick repeats, the source BS might not 27
request an acknowledgment from the MS. 28
k. The source BS sends a Handoff Commenced message to the MSC to notify it 29
that the MS has been ordered to move to the target BS channel. The source BS 30
starts timer T306 to await the Clear Command message from the MSC. If timer 31
Twaitho has been started, the source BS shall wait for that timer to expire 32
before sending the Handoff Commenced message. 33
l. The MS sends a Handoff Completion Message to the target BS. The target BS 34
detects that the mobile has successfully accessed the target BS and stops timer 35
T9. 36
m. The target BS sends the BS Ack Order to the MS over the air interface. 37
n. Upon the receipt of the Handoff Completion message from the MS, the target 38
BS sends a Handoff Complete message to the MSC to notify it that 39
successfully completed the handoff. If timer T9 had expired the BS shall send 40
Handoff Failure message to the MSC. Refer to [16] for detail procedures.. 41
o. The target BS sends A9-AL (Air Link) Connected message, including the 42
PANID received previously in the Handoff Requested message, to the target 43
PCF and starts timer Talc9. . In the case of packet data handoff only this 44
message can be sent any time after step (l). In that message it will include the 45
PANID received previously in the Handoff Requested message. The target 46
PCF stops timer Twaitho9. 47
3GPP2 A.S0013-0 v2.0
Section 3 124
p. The target PCF establishes the A10/A11 link and the PDSN disconnects the 1
old A10/A11 link (see procedure in 3.11.5.5.10). 2
q. The target PCF sends the A9-AL (Air Link) Connected Ack as the response of 3
the A9-AL (Air Link) Connected message and stops timer Talc9. If timer 4
Talc9 is expired, the target BS may resend the A9-AL Connect message. 5
r. The MSC sends a Clear Command to the source BS and starts timer T315. The 6
source BS stops timer T306. 7
s. The source BS sends an A9-Release-A8 message to the source PCF in order to 8
release the A8-Connection and starts timer Tre19. 9
t. Upon the receipt of the A9-Release-A8 message from the source BS, the 10
source PCF releases the A8-connection and responds with an A9-Release-A8 11
Complete message. When the source BS receives the A9-Release-A8 12
Complete message it stops timer Tre19. 13
u. The source BS sends a Clear Complete message to the MSC to notify it that 14
clearing has been accomplished. The MSC stops timer T315. Clear Complete 15
may occur any time after the traffic channel is released. 16
3.17.4.16 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure 17
The following call flow diagram provides an illustration for a hard handoff event from a 18
cdma2000 system to another cdma2000 system. In this scenario, the MS successfully 19
returns to the source BS after hard handoff fails. It is assumed that the call is not in inter-20
BS soft/softer handoff prior to the hard handoff, and thus no inter-BS connections need to 21
be removed. 22
3GPP2 A.S0013-0 v2.0
Section 3 125
MS Source BS MSC Time Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
T9
h
j
i
k
l
m
n
T315
Twaitho
SourcePCF
PDSN
A9-Setup-A8
A9-Connect-A8
Handoff Request Ack
Handoff Command
GHDM / UHDM
CF Search ReportMessage
T7
Clear Command
A9-Release-A8
A9-Release-A8 Complete
Clear Complete
Ack Order
TargetPCFTarget BS
Handoff Failure
Twaitho9
A9-AL Disconnected
A9-AL Connected
A9-AL Connected Ack
o
p
q
A9-AL Disconnected Ack
r
Tald9
Talc9
TA8-Setup
Tre19
1
Figure 3.17.4.16-1 Inter-PCF Hard Handoff (Within Same PDSN) With Return On Failure 2
a. Based on an MS report that it crossed a network specified threshold for signal 3
strength or for other reasons, the source BS recommends cdma2000 to 4
cdma2000 hard handoff to one or more cells in the domain of the target BS. 5
The source BS sends a Handoff Required message with the list of cells to the 6
MSC and starts timer T7. 7
b. The MSC sends a Handoff Request message to the target BS with hard 8
handoff indicator (e.g., Handoff Type element in the message indicating hard 9
handoff). 10
c. The target BS sends an A9-Setup-A8 message to the target PCF in order to 11
establish the A8-Connection and starts timer TA8-Setup. In this case, the 12
handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during 13
handoff). 14
d. Upon receipt of the A9-Setup-A8 message from the target BS, the target PCF 15
establishes the A8-Connection. At this point in time, the PDSN continues to 16
forward packet data to the source BS via source PCF (i.e. the target BS and 17
target PCF don’t receive packet data from the PDSN). Then the target PCF 18
sends the A9-Connect-A8 message and starts timer Twaitho9. When the target 19
BS receives the A9-Connect-A8 message it stops timer TA8-Setup. 20
3GPP2 A.S0013-0 v2.0
Section 3 126
The establishment of the A10/A11 connection is not performed because the 1
handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during 2
handoff). 3
e. The target BS sends a Handoff Request Acknowledgment message to the 4
MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio 5
channel. 6
f. The MSC prepares to switch from the source BS to the target BS and sends a 7
Handoff Command to the source BS. The source BS stops timer T7. 8
g. Upon receipt of the Handoff Command message, the source BS sends an A9-9
AL (Air Link) Disconnected message to the source PCF and starts timer Tald9. 10
The source PCF stops packet data transmission to the source BS upon receipt 11
of the A9-AL (Air Link) Disconnected from the source BS. 12
h. The PCF sends the A9-AL (Air Link) Disconnected Ack message as response 13
of the A9-AL (Air Link) Disconnected message. Upon receipt of this 14
message, the source BS stops timer Tald9. 15
i. The source BS sends the General Handoff Direction Message or Universal 16
Handoff Direction Message to the MS across the air interface. Because the 17
MS is allowed to return to the source BS, then timer Twaitho is started by the 18
source BS. 19
j. The MS may acknowledge the General Handoff Direction Message or 20
Universal Handoff Direction Message by sending an MS Ack Order to the 21
source BS. 22
If the General Handoff Direction Message or Universal Handoff Direction 23
Message is sent using quick repeats, the source BS might not request an 24
acknowledgment from the MS. 25
k. The MS sends a Candidate Frequency (CF) Search Report Message to the 26
source BS after handoff to the target has failed. 27
l. If the handoff fails (i.e., when the BSC receives the CF Search Report 28
Message), the source BS sends the A9-AL (Air Link) Connected message to 29
the source PCF and starts timer Talc9. 30
m. The source PCF restarts packet data transmission upon receipt of the A9-31
AL(Air Link) Connected message from the source BS. The source BS stops 32
timer Talc9. 33
n. Upon receipt of the CF Search Report Message from the MS the source BS 34
detects that the MS has never accessed the target BS cell and sends a Handoff 35
Failure message to the MSC indicating the unsuccessful access by the MS. 36
o. The MSC sends a Clear Command to the target BS and starts timer T315. The 37
target BS stops timer T9. 38
p. The target BS sends an A9-Release-A8 message to the target PCF in order to 39
instruct it to release the associated dedicated resources and starts timer Tre19. 40
The target PCF stops timer Twaitho9. 41
q. Upon the receipt of the A9-Release-A8 message from the target BS, the target 42
PCF releases resources and responds with an A9-Release-A8 Complete 43
message. When the target BS receives the A9-Release-A8 Complete message 44
it stops timer Tre19. 45
3GPP2 A.S0013-0 v2.0
Section 3 127
r. Upon receipt of the Clear Command message from the MSC, the target BS 1
releases and deallocates radio and terrestrial resources. 2
s. The target BS then sends a Clear Complete message to the MSC. The MSC 3
stops timer T315. 4
3.17.4.17 MS Initiated Call Release to Null State 5
This section describes the call flow associated with an MS deactivation (active-to-null 6
state transition) initiated by MS. In order to simplify the diagram, it is assumed that for 7
purposes of this example, the packet call is not in inter-BS soft/softer handoff prior to the 8
deactivation. 9
M S BS M SC/VLR P CF PDSN Time Com m ent
C lear R eques t
C lear C om m and
C lear C om plete
A9-R elease-A8 C om plete
Active / PPP connected
Null state
a
b
c
d
e
f
h
i
A9-R eleas e-A8
j
T 300
T 315
T rel9
T C HRelease
Procedure
gA10 R eleas e
proc edure
Release O rder
10
Figure 3.17.4.17-1 MS Initiated Call Release to Null State 11
a. The MS shall maintain a packet data inactivity timer. The timer should be 12
reset whenever a non-idle RLP data frame is sent or received. 13
b. If the packet data service becomes inactive at the MS (transition to Null state), 14
the mobile requests the BS to disconnect the traffic channel. The MS sends a 15
Release Order with ORDQ=2 (Service Inactive), to the BS to request a 16
transition to the Null state. 17
c. The BS then sends a Clear Request message to the MSC to initiate the call 18
clear transaction, and starts timer T300. 19
d. The MSC starts timer T315 and sends a Clear Command message to the BS to 20
instruct the BS to release the associated dedicated resources. The BS stops 21
timer T300. 22
3GPP2 A.S0013-0 v2.0
Section 3 128
e. In response to the Clear Command message, the BS initiates call clearing over 1
the air interface by transmitting a Release Order. 2
f. The BS then sends an A9-Release-A8 message, with a bearer release (Normal 3
call release) indication, to the PCF to instruct the PCF to release the associated 4
dedicated resources, and starts timer Trel9. 5
g. Procedures for releasing A10 connection and removing mobility management 6
information from the PDSN are performed. 7
h. The PCF acknowledges the A9-Release-A8 message by returning an A9-8
Release-A8 Complete. The BS stops timer Trel9. 9
i. The BS then returns a Clear Complete message to the MSC. The MSC 10
releases the underlying transport connection and stops timer T315. Clear 11
Complete may occur any time after the traffic channel is released. 12
j. The MS goes to the Null State and the Packet Data Service is released. 13
3.17.4.18 Dormant MS Power Down, A10 Release Initiated by the MSC/BSC 14
A dormant MS with an active PPP session to a PDSN powers down. A power down 15
registration message is sent to the BS. Since the packet data session is dormant, there is 16
no A8 connection between the BS and the PCF for this mobile. 17
The BS sends a Location Update to the MSC indicating power down registration. The 18
MSC which previously received an Assignment Failure or a Clear Request message with 19
cause “packet call going dormant” (and therefore has the option of retaining the state of 20
the packet data session) may respond with a Location Updating Accept message. In this 21
situation, the following will occur: 22
• The response includes a release indicator informing the BS that a packet call was 23
dormant. 24
• Using the indicator, the BS triggers an A9-Update-A8 message to the PCF indicating 25
in the Update Reason information element that the MS has powered down. The BS 26
may also send this message to the PCF on its own. 27
• The PCF starts releasing the A10 connection by sending an A11-Registration 28
Request message. 29
3GPP2 A.S0013-0 v2.0
Section 3 129
Registration Acknowledge
BS MS MSC PCF PDSN
b
f
g
A9-Update-A8
A9-Update-A8 Ack
Active PPP session a
Location update
Registration
(power down)
d
c
e
h
Location. Update Accept (Release indicator)
Time
Tupd9 A10 Release
Procedures
1
Figure 3.17.4.18-1 Dormant MS Power Down, A10 Release Initiated by the MSC/BSC 2
a. An active PPP session exists between a dormant MS and the PDSN (no data 3
transferred over the PPP session). 4
b. The dormant MS powers down. A power down registration is sent to the BS. 5
c. The BS sends a location update message to the MSC indicating that the MS 6
has powered down. 7
d. If the MSC is aware that the packet data session is dormant, the MSC sends a 8
Loc. Update Accept message with a cause value set to “power down from 9
dormant state” to inform the BS that a dormant packet call is to be released. 10
e. The BS sends a Registration Acknowledgement to the MS after receiving a 11
power down registration message from the MS. 12
f. The BS shall send the A9-Update-A8 message to the PCF if it receives a 13
location update message with cause value “power down from dormant state” 14
from the MSC. The BS can also send the A9-Update-A8 message on its own. 15
In both cases, the cause value in the A9-Update-A8 message is set to “power 16
down from dormant state”. The BS starts timer Tupd9. 17
g. The PCF uses the MSID received in the A9-Update-A8 message to find the 18
corresponding A10 connection. Procedures for releasing the A10 connection 19
and removing mobility management information from the PDSN are 20
performed. 21
h. The PCF returns the acknowledgement back to the BS. The BS cancels timer 22
Tupd9. 23
3GPP2 A.S0013-0 v2.0
Section 3 130
3.17.4.19 Mobile Initiated Initial Call Setup – Successful Operation with Delayed 1
Accounting Information 2
When an MS initiates a packet data call and PPP negotiation has not been performed yet, 3
PPP negotiation is performed before transmitting packet data. It is assumed that the 4
mobile does not have an active voice call already in progress. 5
cdma2000 TCH establishment procedure may occur in parallel with the A8 connection 6
establishment, in which case the accounting information required to be included in the 7
“Active-start” airlink record on the A11 interface may not be available on the A9-setup-8
A8 message. 9
When the cdma2000 TCH establishment procedure has completed, BS updates the PCF 10
on the A9 connection with the accounting information required to be included in an 11
“Active-Start” Airlink record on the A11 interface. 12
BS sends an A9-Update-A8 message containing the information. 13
BS MS
Origination
BS ACK Order
MSC
CM Service Request
A9-Setup-A8
Assignment Request
PCF PDSN
A9-Connect-A8
Assignment Complete
a
b
c
d
e
f
g
h
i
j
A10/A11
Connection
T303
T10
TA8-Setup
Transmitting packet data
Establishing PPP connection
cdma2000
TCH
A9-Update-A8
A9-Update-A8 Ack
A10/A11
Accounting- Active
k
time
l
m
Tupd9
14
Figure 3.17.4.19-1 Mobile Initiated Initial Call Setup– Successful Operation with Delayed Accounting 15
Information 16
3GPP2 A.S0013-0 v2.0
Section 3 131
a. The MS transmits an Origination Message (DRS=1), with layer 2 1
acknowledgment required, over the access channel of the air interface to the 2
BS to request packet data service. 3
b. The BS acknowledges the receipt of the Origination Message with a Base 4
Station Acknowledgment Order to the MS. 5
c. The BS constructs the CM Service Request message, places it in the Complete 6
Layer 3 Information message, sends the message to the MSC, and starts timer 7
T303. 8
d. The MSC sends an Assignment Request message to the BS to request 9
assignment of radio resources and starts timer T10. For packet data service, 10
terrestrial circuit between the MSC and the BS is not required. 11
e. The BS and the MS initiate the establishment of a radio traffic channel. 12
f. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator 13
set to 1 to establish an A8 connection and starts timer TA8-setup. All the 14
required accounting information to be included on the A11 Active-Start 15
Airlink record on the A11 interfaces are not yet available. 16
g. Procedure for establishing A10/A11 connection is performed (including 17
“connection-setup” airlink record) 18
h. Upon establishment of the A10/A11 connection, the PCF establishes an A8 19
connection and transmits an A9-Connect-A8 message. The BS stops the timer 20
TA8-setup. The BS sends an Assignment Complete to the MSC. 21
i. The BS sends an assignment complete to the MSC. This step may occur any 22
time after radio link establishment. The MSC stops timer T10. 23
j. The cdma2000-TCH establishment procedure is completed. The BS informs 24
the PCF via A9-Update-A8 message that the traffic channel is now 25
successfully established to the MS. The message includes the required 26
accounting information to be included on the A11 Active-start Airlink record. 27
k. PCF initiates an A11 registration procedure (“Active-Start”) that provides the 28
accounting information to the PDSN. PCF acknowledges message A9-29
Update-A8 by returning A9-Update-A8 Ack back to the BS. 30
l. PPP connection establishment procedure and Mobile IP Registration (if 31
required) on the PPP connection are performed between the MS and PDSN. 32
m. The MS begins transmitting/receiving packet data. 33
3.17.4.20 Accounting Parameters Update Event Procedure 34
During an active connection, if any of the following parameters are changed: 35
• User zone 36
• Quality of service 37
• Forward/Reverse Mux Option 38
the BSC shall notify the PCF using A9-Update-A8 message. The message shall contain 39
the changed parameters. The PCF then triggers an A11 procedure to update the PDSN 40
with the new accounting information. 41
3GPP2 A.S0013-0 v2.0
Section 3 132
BS MSC PCF PDSN
b
c
d
Parameter change
notification/
A9-Update-A8
A9-Update-A8 Ack
A10/A11
Accounting- Active
Active PPP session a
Parameter change
notification/
Tupd9
MS Time
1
Figure 3.17.4.20-1 Accounting Parameters Update Event Procedure 2
a. An active PPP session exists and data is transferred over the connection 3
b. Event had occurred where parameters are changed/negotiated between the 4
BS/MSC and the MS. 5
c. The BS notifies the PCF using A9-Update-A8 message when any of the 6
following parameters have changed: User-Zone, Quality of Service, 7
Forward/Reverse Mux Option. The BS starts timer Tupd9. 8
d. The PCF updates the PDSN with the new accounting information and sends 9
A9-Update-A8 Ack message as an acknowledgment back to the BS. The BS 10
stops timer Tupd9. 11
3.17.5 A10/A11 Interface Call Flows 12
This section describes call flows for the A10/A11 interface. The following messages are 13
required to support the 3G packet data feature on the A10/A11 interface: 14
• A11-Registration Request 15
• A11-Registration Response 16
• A11-Registration Update 17
• A11-Registration Acknowledge 18
The A10/A11 interface uses Mobile IP messages for managing the A10 connections. The 19
MS initiates a packet data call by sending an IS-2000 Origination Message. Normal voice 20
service authentication procedures are followed for the subscriber, and then a traffic 21
channel is established with the mobile. After connection of a packet data service option, 22
RLP synchronization between the mobile station and the BS proceeds. The BS/PCF 23
3GPP2 A.S0013-0 v2.0
Section 3 133
initiates setup of an A10 connection with the PDSN by sending an A11-Registration 1
Request message on the A11 interface. The PDSN may accept or reject the connection 2
setup request. If the connection setup request is acceptable, the PDSN returns an A11-3
Registration Reply message with an accept indication, and the packet data call is 4
connected through the just established A10 connection. 5
With the A10 connection in place, link layer/network layer frames pass over this 6
connection in both directions via Generic Routing Encapsulation (GRE) framing. The 7
PDSN accepts these frames, strips the GRE, and processes them as normal incoming 8
frames for the appropriate interface and protocol. The other direction behaves 9
analogously, with the PDSN encapsulating the link layer/network layer frames in GRE, 10
and the PCF stripping the GRE before passing the frames over to the upper layer. At this 11
point, there is a point-to-point link layer/network layer connection between the MS and 12
the PDSN. 13
In order to setup an A10 connection, the PCF sends an A11-Registration Request 14
message to the PDSN. This message includes a PCF Session Identifier (PCF SID) to be 15
used by the PDSN as the Key in the GRE header when sending data frames on the A10 16
connection. The PCF Session Identifier (PCF SID) is unique only within the PCF entity. 17
In the A11-Registration Reply message, the PDSN assigns a PDSN Session Identifier 18
(PDSN SID) to be used by the PCF as the Key in the GRE header when sending data 19
frames on the A10 connection. If both the PCF and the PDSN support a Session Identifier 20
Version higher than 0, the PDSN SID may be different from the PCF SID. This allows 21
the PDSN to choose a PDSN SID that is unique within the PDSN. Otherwise, the PDSN 22
SID shall be identical to the PCF SID, thereby maintaining backwards compatibility. The 23
PCF will also use the MN Session Reference ID (MN-SRID) which is passed from the 24
mobile on each origination and which, together with the Mobile Identifier, can be used to 25
identify a packet data service session for a specific mobile across PCFs and PDSNs. In 26
the A11-Registration Request message, the PCF sets the Home Address field to zeros. 27
The IP source address (IP header) and the Care-of-Address field of the A11-Registration 28
Request message are set to the IP address of the PCF. The IP destination address in the IP 29
header and the Home Agent field in the A11-Registration Request message are set to the 30
address of the PDSN designated for the call. The PCF Session Identifier (PCF_SID), link 31
layer/network layer protocol type identifier, MN Session Reference ID and MS_ID of the 32
MS are set in the Session Specific Extension of the A11-Registration Request message. 33
For procedures for A10 interface Setup, Operation, Release, and Accounting, refer to 34
[17]. 35
3.17.5.1 Mobile Originated Packet Call Setup – Successful Operation 36
In order to obtain packet data services, the mobile performs registration with the serving 37
wireless network and then with the packet network. The mobile sends an Origination 38
Message to the BS that includes the packet data service option. It results in assignment of 39
the traffic channel, establishment of the A10 connection, establishment of the link layer 40
(PPP) and for the case where Mobile IP is used by the terminal, Mobile IP registration 41
with the serving packet network. 42
User data traffic can now be passed over the A10 connection encapsulated within GRE 43
frames. The PCF periodically re-registers with the selected PDSN by the use the of A11-44
Registration Request message before the A10 connection Lifetime expires. 45
3GPP2 A.S0013-0 v2.0
Section 3 134
MS BS/PCF MSC time comment
Origination
Base Station Ack Order
a
b
c
d
e
f
Complete L3 Info: CM Service Request
Assignment Request
g
h Assignment Complete
i
k
l
T10
j
T303
PDSN
A11-Registration Request
TCH Setup
A11-Registration Request
A11-Registration Reply
Establish PPP Connection
User Data Transmission
A11-Registration Reply
Tregreq
Tregreq
Trp
1
Figure 3.17.5.1-1 Mobile Originated Packet Call Setup – Successful Operation 2
Note: The following descriptions assume that the PCF is capable of determining whether 3
one or more PDSNs are reachable on the A10/A11 Network. Based on the algorithm 4
specified in Section 3.17.3, the PCF selects a PDSN best suited for handling this call. 5
a. In order to perform registration for packet data services the mobile sends an 6
Origination Message with Layer 2 Ack required indication over the Access 7
Channel to the BS. The Origination Message includes a packet data service 8
option. 9
b. The BS acknowledges the receipt of the Origination Message with a Base 10
Station Ack Order to the mobile. 11
c. The BS constructs a CM Service Request message, places it in the Complete 12
Layer 3 Information message, sends the message to the MSC, and starts timer 13
T303. 14
d. The MSC sends an Assignment Request message to the BS requesting 15
assignment of radio resources and starts timer T10. No terrestrial circuit 16
between the MSC and the BS is assigned to the packet data call. 17
e. On receipt of the Assignment Request message, the BS stops timer T303. The 18
BS and the mobile perform radio resources setup procedures if the mobile is 19
not already on a traffic channel. 20
3GPP2 A.S0013-0 v2.0
Section 3 135
f. The PCF recognizes that no A10 connection associated with this mobile is 1
available and selects a PDSN for this call. The PCF sends an A11-Registration 2
Request message with non-zero Lifetime value to the selected PDSN. This 3
message also includes Accounting Data (R-P Session Setup Airlink Record). 4
The PCF starts timer Tregreq. 5
g. The A11-Registration Request message is validated and the PDSN accepts the 6
connection by returning an A11-Registration Reply message with an accept 7
indication and the Lifetime set to the configured Trp value. Both the PDSN 8
and the PCF create a binding record for the A10 connection. The PCF stops 9
timer Tregreq. The PCF and PDSN start timer Trp. If the PDSN supports fast 10
handoff, the Anchor P-P Address is sent as part of the NVSE element to the 11
PCF. If the PCF does not support fast handoff, the Anchor P-P Address is 12
discarded and the call proceeds further. 13
h. After the radio link and A10 connection are setup, the BS sends an 14
Assignment Complete message to the MSC. The MSC stops timer T10 upon 15
receipt of the Assignment Complete message from the BS. 16
i. The mobile and the PDSN establish the link layer (PPP) connection and then 17
perform the MIP registration procedures (if required) over the link layer (PPP) 18
connection, thereby creating a mobility binding for the mobile. 19
j. After completion of MIP registration (if executed), the mobile can 20
send/receive data via GRE framing over the A10 connection. 21
k. The PCF sends an A11-Registration Request message before expiration of 22
registration Lifetime timer (Trp) for refreshing registration for the A10 23
connection. The A11-Registration Request message may also be used to send 24
accounting related and other information to the PDSN. The accounting related 25
and other information is sent at system defined trigger points. The PCF starts 26
timer Tregreq. 27
l. For a validated A11-Registration Request message, the PDSN returns an A11-28
Registration Reply message with an accept indication and a configured 29
Lifetime value. Both the PDSN and the PCF update the A10 connection 30
binding record. The PDSN stores the accounting related and other information 31
(if received) for further processing, before returning the A11-Registration 32
Reply message. The PCF stops timer Tregreq. The PCF and PDSN start timer 33
Trp. 34
3.17.5.2 Mobile Originated Packet Call Setup – Failure Operation 35
In order to obtain packet data services, the mobile performs registration with the serving 36
wireless network and then with the packet network. The mobile sends an Origination 37
Message to the BSC that includes the packet data service option. It results in assignment 38
of the traffic channel. The PCF initiates establishment of the A10 connection with the 39
PDSN by sending an A11-Registration Request message to the PDSN. If the connection 40
setup request is not acceptable, the PDSN returns an A11-Registration Reply message 41
with a reject code. Based on the reject code, the PCF may attempt to re-try setting up the 42
A10 connection. If the A10 connection is not able to be established, the PCF indicates 43
this to the BSC which returns a failure indication to the MSC, which in-turn releases the 44
call. 45
3GPP2 A.S0013-0 v2.0
Section 3 136
MS BS/PCF MSC time comment
Origination Message
Base Station Ack Order
a
b
c
d
e
f
Complete L3 Info: CM Service Request
Assignment Request
g
h Assignment Failure
i
k
T10
j
T303
PDSN
Clear Complete
TCH Setup
A11-Registration Request
A11-Registration Reply
Clear Command
Release Order
Tregreq
T315
1
Figure 3.17.5.2-1 Mobile Originated Packet Call Setup – Failure Operation 2
Note: The following descriptions assume that the PCF is capable of determining 3
reachability to one or more PDSNs on the A10/A11 Network. Based on the algorithm 4
specified in Section 3.17.3, the PCF selects a PDSN best suited for handling this call. 5
a. In order to perform A11-Registration for packet data services, the mobile 6
sends an Origination Message with Layer 2 Ack required indication over the 7
Access Channel to the BS. The Origination Message includes a packet data 8
service option. 9
b. The BS acknowledges the receipt of the Origination Message with a Base 10
Station Ack Order to the mobile. 11
c. The BS constructs a CM Service Request message, places it in the Complete 12
Layer 3 Information message, sends the message to the MSC, and starts timer 13
T303. 14
d. The MSC sends an Assignment Request message to the BS requesting 15
assignment of radio resources and starts timer T10. No terrestrial circuit 16
between the MSC and the BS is assigned to the packet data call. 17
e. On receipt of the Assignment Request message, the BS stops timer T303. The 18
BS and the mobile perform radio resources setup procedures if the mobile is 19
not already on a traffic channel. 20
f. The PCF recognizes that no A10 connection associated with this mobile is 21
available and selects a PDSN for this call. The PCF sends an A11-Registration 22
Request message with non-zero Lifetime value to the selected PDSN. This 23
message also includes Accounting Data (R-P Session Setup Airlink Record). 24
The PCF starts timer Tregreq. 25
3GPP2 A.S0013-0 v2.0
Section 3 137
g. The PDSN does not accept the A11-Registration Request message and fails 1
A10 connection setup by returning an A11-Registration Reply message with a 2
reject code. The PCF stops timer Tregreq. 3
h. Based on the reject code, the PCF may attempt to re-try setting up the A10 4
connection. If the A10 connection can not be established, the BSC returns an 5
Assignment Failure with cause “PDSN resource unavailable” to the MSC. 6
Upon receipt of this message, the MSC stops timer T10. 7
i. The MSC sends a Clear Command message to the BS, instructing the BS to 8
release the associated resources, including the radio resources. The MSC starts 9
timer T315. 10
j. The BS sends a Release Order to the mobile instructing the mobile to release 11
the radio resources. 12
k. The BS returns a Clear Complete message to the MSC. Upon receipt of this 13
message, the MSC stops timer T315. 14
Note: If the BSC has already returned an Assignment Complete message to the MSC 15
prior to receiving an A11-Registration Reply message with a reject code from the PDSN, 16
the BSC initiates release of the call by sending a Clear Request with Cause (PDSN 17
Resource Unavailable) to the MSC. 18
3.17.5.3 Mobile Originated Packet Call Setup – With Registration to Alternate PDSN 19
In order to obtain packet data services, the mobile performs registration with the serving 20
wireless network and then with the packet network. The mobile sends an Origination 21
Message to the BSC that includes the packet data service option. It results in assignment 22
of the traffic channel. The PCF initiates establishment of the A10 connection with the 23
selected PDSN by sending an A11-Registration Request message. If the PDSN does not 24
accept the connection and wants to propose another PDSN, it returns an A11-Registration 25
Reply message with code ‘88H’ (Registration Denied – unknown PDSN address). The 26
address of the alternate PDSN is also returned in the Home Agent field of the A11-27
Registration Reply message. The PCF may accept the alternate PDSN by sending another 28
A11-Registration Request message, or may use the algorithm specified in Section 3.17.3 29
to select a new PDSN. The PCF initiates establishment of the A10 connection with the 30
selected PDSN by sending an A11-Registration Request message. 31
3GPP2 A.S0013-0 v2.0
Section 3 138
MS BS/PCF MSC time comment
Origination
Base Station Ack Order
a
b
c
d
e
f
Complete L3 Info: CM Service Request
Assignment Request
g
h
Assignment Complete
i
k
l
T10
j
T303
PDSN-1
TCH Setup
A11-Registration Reply
Establish PPP Connection
User Data Transmission
Tregreq
regreq
PDSN-2
A11-Registration Request
A11-Registration Reply A11-Registration Reply (Lifetime, Reject)
A11-Registration Request
1
Figure 3.17.5.3-1 Mobile Originated Packet Call Setup – With Registration to Alternate PDSN 2
Note: The following descriptions assume that the PCF is capable of determining 3
reachability to one or more PDSNs on the A10/A11 Network. Based on the algorithm 4
specified in Section 3.17.3, the PCF selects a PDSN best suited for handling this call. 5
a. In order to perform registration for packet data services, the mobile sends an 6
Origination Message with Layer 2 Ack required indication over the Access 7
Channel to the BS. The Origination Message includes a packet data service 8
option. 9
b. The BS acknowledges the receipt of the Origination Message with a Base 10
Station Ack Order to the mobile. 11
c. The BS constructs a CM Service Request message, places it in the Complete 12
Layer 3 Information message, sends the message to the MSC, and starts timer 13
T303. 14
d. The MSC sends an Assignment Request message to the BS requesting 15
assignment of radio resources and starts timer T10. No terrestrial circuit 16
between the MSC and the BS is assigned to the packet data call. 17
3GPP2 A.S0013-0 v2.0
Section 3 139
e. On receipt of the Assignment Request message, the BS stops timer T303. The 1
BS and the mobile perform radio resources setup procedures if the mobile is 2
not already on a traffic channel. 3
f. The PCF recognizes that no A10 connection associated with this mobile is 4
available and selects a PDSN (PDSN-1) for this call. The PCF sends an A11-5
Registration Request message with non-zero Lifetime value to the selected 6
PDSN-1. This message also includes Accounting Data (R-P Session Setup 7
Airlink Record). The PCF starts timer Tregreq. 8
g. The A11-Registration Request message is validated and the PDSN-1 rejects 9
the connection and may proposes another PDSN (PDSN-2). The PDSN-1 10
returns an A11-Registration Reply message with a reject code of ‘88H’ 11
(Registration Denied – unknown PDSN address) and the address of the 12
alternate PDSN (PDSN-2) in the Home Agent address field of the A11-13
Registration Reply message. The PCF stops timer Tregreq. 14
h. The PCF initiates establishment of the A10 connection with the PDSN-2 by 15
sending an A11-Registration Request message with non-zero Lifetime value. 16
The PCF starts timer Tregreq. 17
i. The A11-Registration Request message is validated and the PDSN-2 accepts 18
the connection by returning an A11-Registration Reply message with an 19
accept indication and the Lifetime set to the configured Trp value. Both the 20
PDSN-2 and the PCF create a binding record for the A10 connection. If 21
PSDN-2 supports fast handoff , the Anchor PSDN IP Address is sent as a part 22
of the NVSE element to the PCF. If the PCF does not support fast handoff , 23
the Anchor PSDN IP Address is discarded and the call proceeds normally. 24
The PCF stops timer Tregreq. 25
j. After the radio link and the A10 connection have been established, the BS 26
sends an Assignment Complete message to the MSC. The MSC stops timer 27
T10. This step may occur any time after radio link establishment. 28
k. The mobile and the PDSN-2 establish the link layer (PPP) connection and 29
then perform the MIP registration procedures (if required) over the link layer 30
(PPP) connection, thereby creating a mobility binding for the mobile. 31
l. After completion of MIP registration (if executed), the mobile can 32
send/receive data via GRE frames over the A10 connection. 33
Note: The PCF continues to perform re-registration of the A10 connection with the 34
PDSN-2 by the exchange of A11-Registration Request messages and A11-Registration 35
Reply messages before expiration of Lifetime time Trp. 36
3.17.5.4 Packet Data Service Session Clearing-PDSN Initiated 37
User data traffic is passed over the A10 connection encapsulated within GRE frames. An 38
event occurs at the PDSN that requires closing of the packet data session. The PDSN 39
initiates release of the A10 connection with the PCF. If the mobile is on a traffic channel, 40
other resources assigned to the call are also released. 41
PDSN initiated service session clearing may occur, for example due to PPP timeout. For 42
such cases a traffic channel may not exist, and this scenario terminates at step d. 43
3GPP2 A.S0013-0 v2.0
Section 3 140
MS BS/PCF MSC time comment
a
c
d
b
PDSN
A11-Registration Request
e
h
f
g
Clear Command T300
T315
Clear Request
A11-Registration Update
A11-Registration Acknowledgement
Clear Complete
Tregreq
Tregupd
TCH Release
A11-Registration Reply
1
Figure 3.17.5.4-1 Packet Data Service Session Clearing - PDSN Initiated 2
a. An event occurs at the PDSN that requires release of the packet data session. 3
The PDSN initiates release of the A10 connection by sending an A11-4
Registration Update message to the PCF. The PDSN starts timer Tregupd. 5
b. The PCF responds with an A11-Registration Acknowledge message. Steps ‘c’ 6
through ‘d’ may occur in parallel with steps ‘e’ through ‘g’. The PDSN stops 7
timer Tregupd. 8
c. The PCF sends an A11-Registration Request message with Lifetime set to 9
zero, and accounting related information. The PCF starts timer Tregreq. 10
d. The PDSN stores the accounting related information for further processing 11
before returning an A11-Registration Reply message with an accept indication 12
and closes the A10 connection for the mobile. The PCF also closes the A10 13
connection. The PCF stops timer Tregreq. 14
e. The BS sends a Clear Request message to the MSC to initiate clearing of the 15
radio and other resources assigned to the call and starts timer T300. 16
f. The MSC sends a Clear Command message to the BS, instructing the BS to 17
release the associated resources, including the radio resources and starts timer 18
T315. The BS stops timer T300 upon receiving the Clear Command. 19
g. The BS sends a Release Order to the mobile instructing the mobile to close the 20
packet data session. The BS releases the radio resources and closes the packet 21
data session for the mobile. The mobile acknowledges the Release Order by 22
returning a Release Order to the BS and closes the packet data session. 23
3GPP2 A.S0013-0 v2.0
Section 3 141
h. The BS returns a Clear Complete message to the MSC. The MSC stops timer 1
T315. 2
3.17.5.5 Packet Data Service Session Clearing – MSC Initiated 3
User data traffic is now being passed over the A10 connection encapsulated within GRE 4
frames. An event occurs at the MSC that requires closing of the packet data session and 5
release of radio and other resources for the call. The MSC initiates release of the A10 6
connection with the PDSN. Traffic channel and other resources assigned to the call are 7
also released. 8
MS PDSN
time comment
b
c
d
e
Clear Command
T315
BS/PCF MSC
User Data Session
a
TCH Release
A11-Registration Request
Tregreq
Clear Complete
A11-Registration Reply
9
Figure 3.17.5.5-1 Packet Data Service Session Clearing – MSC Initiated 10
a. An event occurs at the MSC that requires release of the packet data session. 11
The MSC sends a Clear Command message to the BS, instructing the BS to 12
release the call and associated resources, including the radio resources. Steps c 13
and d may occur in parallel with step b. 14
b. The BS and the mobile release the traffic channel and other radio resource. 15
c. The PCF sends an A11-Registration Request message to the PDSN with a 16
Lifetime timer value of zero to close the A10 connection. Accounting data is 17
also included in the A11-Registration Request message. The PCF starts timer 18
Tregreq. 19
d. The PDSN stores the accounting data for further processing and sends an 20
A11-Registration Reply message with an accept indication to complete the 21
release of the A10 connection. The PCF stops timer Tregreq. 22
e. The BS sends a Clear Complete message to the MSC. The MSC stops timer 23
T315. 24
3.17.5.6 Packet Data Service Session Clearing – MS Initiated 25
The example below shows the termination of a packet data call as a result of a power 26
down operation by the MS. 27
3GPP2 A.S0013-0 v2.0
Section 3 142
Clear Command
Release Order (Power Down Indication)
MS PDSN time comment
a
b
c
d
Clear Request
T300
T315
e
BS/PCF MSC
f
g
TCH Release
A11-Registration Request
A11-Registration Reply Tregreq
Clear Complete
1
Figure 3.11.5.5.6-1 Packet Data Service Session Clearing – MS Initiated 2
a. The MS powers down resulting in termination of the packet data session. It 3
sends a Release Order to the BS with a power down indication. 4
b. The BS sends a Clear Request to the MSC. The BS starts timer T300. 5
c. The MSC responds with a Clear Command. The BS stops timer T300. The 6
MSC starts timer T315. 7
d. The BS responds to the MS with a Release Order and the traffic channel and 8
other radio resources are released. Step ‘d’ may occur in parallel with steps ‘e’ 9
and ‘f’. 10
e. The PCF sends an A11-Registration Request message to the PDSN with a 11
Lifetime timer value of zero to close the A10 connection. Accounting data is 12
included in the message. The PCF starts timer Tregreq. 13
f. The PDSN stores the accounting data for further processing and responds with 14
an A11-Registration Reply message with an accept indication to complete the 15
release of the A10 connection. The PCF stops timer Tregreq. 16
g. The BS sends a Clear Complete message to the MSC. The MSC stops timer 17
T315. 18
3.17.5.7 Packet Data Service Session Clearing – PDSN Initiated (Crossing A11-19
Registration Request and A11-Registration Update) 20
User data traffic is passed over the A10 connection, encapsulated within GRE frames. An 21
event occurs at the PDSN that requires closing of the packet data session. The PDSN 22
initiates release of the A10 connection with the PCF. At the same time, PCF sends an 23
A11-Registration Request message to the PDSN to perform periodic re-registration of the 24
A10 connection. Release of the A10 connection initiated by the PDSN takes precedence. 25
Traffic channel and other resources assigned to the call are also released. 26
3GPP2 A.S0013-0 v2.0
Section 3 143
MS BS/PCF MSC time comment
a
c
d
b
PDSN
A11-Registration Request
A11-Registration Reply
e
h
i
f
g
j
T300
T315
Clear Request
A11-Registration Acknowledge
Clear Complete
A11-Registration Request
A11-Registration Update
TregreqTregupd
Tregreq
TCH Release
A11-Registration Reply
Clear Command
1
Figure 3.17.5.7-1 Packet Data Service Session Clearing– PDSN Initiated (Crossing A11-Registration 2
Request and A11-Registration Update) 3
a. The PCF sends A11-Registration Request message with anon-zero Lifetime 4
value before expiration of registration Lifetime timer (Trp) for refreshing 5
registration for the A10 connection, and starts timer Tregreq. Accounting 6
related and other information may also be included in the A11-Registration 7
Request message. 8
b. An event occurs at the PDSN that requires release of the packet data session. 9
The PDSN initiates release of the A10 connection by sending an A11-10
Registration Update message to the PCF, and starts timer Tregupd. 11
c. On receipt of A11-Registration Request message while timer Tregupd is 12
running, the PDSN returns an A11-Registration Reply message with lifetime 13
set to zero (0). The PDSN, however stores the accounting related and other 14
3GPP2 A.S0013-0 v2.0
Section 3 144
information (if received) for further processing, before returning the A11-1
Registration Reply message. The PCF stops timer Tregreq. 2
d. On receipt of A11-Registration Update message, irrespective of timer Tregreq 3
condition, the PCF responds with an A11-Registration Acknowledge message. 4
Steps ‘e’ through ‘f’ may occur in parallel with steps ‘g’ through ‘i’. The 5
PDSN stops timer Tregupd. 6
e. The PCF sends an A11-Registration Request message with Lifetime set to 7
zero, and accounting related information to the PDSN. The PCF starts timer 8
Tregreq. 9
f. The PDSN stores the accounting related information for further processing 10
before returning A11-Registration Reply message with an accept indication 11
and releases the A10 connection for the mobile. The PCF also releases the 12
A10 connection. The PCF stops timer Tregreq. 13
g. The BS sends a Clear Request message to the MSC to initiate clearing of the 14
radio and other resources assigned to the call. The BS starts timer T300. 15
h. The MSC sends a Clear Command message to the BS, instructing the BS to 16
release the associated resources, including the radio resources. The MSC starts 17
timer T315. Upon receiving the Clear Command, the BS stops timer T300. 18
i. The BS and the MS release traffic channel and other the radio resources. 19
j. The BS returns a Clear Complete message to the MSC. The MSC stops timer 20
T315. 21
3.17.5.8 Inter-PCF Dormant Handoff – Mobile Continues to be Served by the Serving 22
PDSN 23
In order to obtain packet data services, the mobile performed registration with the packet 24
network. The packet data session transitioned to dormant mode. Both the A10 connection 25
and the link layer (PPP) connection are maintained. The source PCF continues to perform 26
re-registrations for the A10 connection with the PDSN by the exchange of A11-27
Registration Request messages and A11-Registration Reply messages before expiration 28
of A10 connection Lifetime timer Trp. 29
While in the dormant mode, the mobile detects a change of PZID, SID or NID. On 30
detection of a new PZID, SID or NID, the mobile sends an Origination Message to the 31
target BS that includes the packet data service option and the DRS bit set to ‘0’. The 32
Origination Message includes the previous PZID, SID and NID when any of these 33
parameters change during the dormant handoff. The target PCF establishes an A10 34
connection with the PDSN. Based on the IDs (PZID, NID and/or SID) in the Origination 35
Message, the target PCF sends the PANID of the source PCF and the CANID of target 36
PCF to the serving PDSN. The serving PDSN uses this information to determine whether 37
or not PPP re-negotiation is required. If the PDSN has data, the PDSN returns the ‘Data 38
Available Indicator’ in the Vendor/Organization Specific Extension within the 39
Registration Reply to the BS/PCF resulting in establishment of the traffic channel. The 40
PDSN releases the A10 connection with the source PCF. 41
After A10 establishment the target PCF periodically re-registers with the PDSN by the 42
use of an A11-Registration Request message before the A10 connection Lifetime expires. 43
3GPP2 A.S0013-0 v2.0
Section 3 145
Source BS/PCF
MSC time comment
Origination
Base Station Ack Order
a
b
c
d
e
f
Complete L3 Info: CM Service Request
Assignment Request
g
h
Assignment Failure
i
k
m
T10
j
T303
PDSN
A11-Registration Update
A11-Registration Request
A11-Registration Reply
A11-Registration Acknowledge
Target BS/PCF
A11-Registration Request
A11-Registration Reply
l
Tregreq
Tregreq
Tregupd
T_rp
Clear Complete
Clear Command
T20
MS
1
Figure 3.17.5.8-1 Inter-PCF Dormant Handoff – Mobile Continues to be Served by the Serving PDSN 2
a. On detection of a new PZID, SID or NID, the mobile sends an Origination 3
Message with DRS set to ‘0’ to the target BS. 4
b. The target BS acknowledges the receipt of the Origination Message with a BS 5
Ack Order to the mobile. 6
c. The target BS constructs a CM Service Request message, places it in the 7
Complete Layer 3 Information message, sends the message to the MSC, and 8
starts timer T303. 9
d. The MSC sends an Assignment Request message to the target BS requesting 10
assignment of radio resources and starts timer T10. On receipt of the 11
Assignment Request the BS stops timer T303. 12
e. The target PCF sends an A11-Registration Request message to the PDSN. The 13
Registration Request message includes the Mobility Event Indicator within 14
3GPP2 A.S0013-0 v2.0
Section 3 146
the Vendor/Organization Specific Extension. and a non-zero Lifetime. This 1
message also includes Accounting Data (R-P Session Setup Airlink Record). 2
The PCF starts timer Tregreq. 3
f. The A11-Registration Request message is validated and the PDSN accepts the 4
connection by returning an A11-Registration Reply message with an accept 5
indication. If the PDSN supports Fast Handoff the Anchor P-P Address is 6
included. If the PCF does not support Fast Handoff it ignores the Anchor P-P 7
Address. If the PDSN has data to send, it includes the Data Available 8
Indicator within the Vendor/Organization Specific Extension. The A10 9
connection binding information at the PDSN is updated to point to the target 10
PCF. The PCF stops timer Tregreq. 11
If the PDSN responds to the PCF with the Data Available Indicator, the BS 12
establishes traffic channels as in step e in Figure 3.11.5.5.1-1. In this case the 13
remaining steps in this procedure are omitted. 14
g. The target BS sends the Assignment Failure message to the MSC with the 15
cause value indicating Packet Call Going Dormant and starts timer T20. The 16
MSC stops timer T10. 17
h. The MSC sends Clear Command to target BS with Cause value Do Not Notify 18
Mobile and starts timer T315. BS stops timer T20 upon receipt of the Clear 19
Command message. 20
i. The target BS sends a Clear Complete message to the MSC. The MSC stops 21
timer T315 upon receipt of the Clear Complete. 22
j. The PDSN initiates release of the A10 connection with the source PCF by 23
sending an A11-Registration Update message. The PDSN starts timer Tregupd. 24
k. The source PCF responds with an A11-Registration Acknowledge message. 25
The PDSN stops timer Tregupd. 26
l. The source PCF sends an A11-Registration Request message with Lifetime set 27
to zero, to the PDSN. The PCF starts timer Tregreq. 28
m. The PDSN sends the A11-Registration Reply message with an accept 29
indication to the source PCF. The source PCF closes the A10 connection for 30
the mobile. The PCF stops timer Tregreq. 31
3.17.5.9 Inter-PCF Dormant Handoff – Mobile Served by a New Target PDSN 32
In order to obtain packet data services, the mobile performed registration with the packet 33
network. The packet data session transitioned to dormant mode. Both the A10 connection 34
and the link layer (PPP) connection are maintained. The source PCF continues to perform 35
re-registrations for the A10 connection with the source PDSN by the exchange of A11-36
Registration Request messages and A11-Registration Reply messages before expiration 37
of the A10 connection Lifetime timer Trp. 38
While the packet data session is in dormant mode, the mobile detects a change of PZID, 39
SID or NID. On detection of a new, PZID, SID, or NID, the mobile sends an Origination 40
Message to the target BS that includes the packet data service option and the DRS bit set 41
to ‘0’. The target PCF establishes an A10 connection with the target PDSN. The target 42
PCF is required to forward the PANID of the source PCF and the CANID of the target 43
PCF to the serving PDSN. 44
3GPP2 A.S0013-0 v2.0
Section 3 147
The BS normally does not establish a traffic channel when it receives an Origination 1
Message with DRS bit set to ‘0’; however, in this case, a traffic channel is established 2
after the BS/PCF receives an A11-Registration Reply message from the PDSN containing 3
the ‘Data Available Indicator’. Link layer (PPP) re-establishment between the mobile and 4
the target PDSN and Mobile IP re-registration (if required) between the mobile and the 5
packet network are then performed. If user data is available, it is exchanged between the 6
mobile and the corresponding node over the new A10 connection, encapsulated within 7
GRE frames. The source PDSN releases the A10 connection with the source PCF on 8
expiration of the MIP registration timer. The target PCF periodically re-registers with the 9
PDSN by the use of A11-Registration Request message before the A10 connection 10
Lifetime expires. 11
Complete L3 Info: CM Service Request
MS Source BS/PCF
MSC time comment
Origination
Base Station Ack Order
a
b
c
d
e
f
Assignment Request
g
h
i
k
m
T10
j
T303
Source PDSN
A11-Registration Request
A11-Registration Reply
Target BS/PCF
l
Tregreq
Assignment Complete
A11-Registration Update
A11-Registration Acknowledge
A11-Registration Request
A11-Registration Reply Tregreq
Tregupd
Target PDSN
TCH Setup
Establish PPP Connection
12
Figure 3.17.5.9-1 Inter-PCF Dormant Handoff – Mobile Served by a New Target PDSN 13
a. On detection of a new PZID, SID or NID, the mobile sends an Origination 14
Message with DRS set to ‘0’ to the target BS. 15
b. The target BS acknowledges the receipt of the Origination Message with a BS 16
Ack Order to the mobile. 17
3GPP2 A.S0013-0 v2.0
Section 3 148
c. The target BS constructs a CM Service Request message, places it in the 1
Complete Layer 3 Information message, sends the message to the MSC, and 2
starts timer T303. 3
d. The MSC sends an Assignment Request message to the target BS requesting 4
assignment of radio resources and starts timer T10. On receipt of the 5
Assignment Request the BS stops timer T303. 6
e. The target PCF initiates establishment of the A10 connection by sending an 7
A11-Registration Request message with non-zero Lifetime value to the target 8
PDSN. The message includes the Mobility Event Indicator within the 9
Vendor/Organization Specific Extension. This message also includes 10
Accounting Data (R-P Session Setup Airlink Record). The PCF starts timer 11
Tregreq. 12
f. The A11-Registration Request message is validated and the target PDSN 13
accepts the connection by returning an A11-Registration Reply message with 14
an accept indication and Data Available Indicator within the 15
Vendor/Organization Specific Extension. If the PDSN supports Fast Handoff 16
the Anchor P-P Address is included. If the PCF does not support Fast Handoff 17
it ignores the Anchor P-P Address. The PCF stops timer Tregreq. 18
g. On receipt of the A11-Registration Reply message with Data Availability 19
Indicator, the target BS initiates setup of the traffic channel with the MS. 20
h. The BSC sends the Assignment Complete message to the MSC. The MSC 21
stops timer T10. 22
i. The mobile and the target PDSN establish the link layer (PPP) connection and 23
then perform the MIP registration procedures (if required) over the link layer 24
(PPP) connection, thereby creating a mobility binding for the mobile. 25
j. On expiration of the Lifetime timer (Trp) or other events internal to the PDSN, 26
the source PDSN initiates release of the A10 connection with the source PCF 27
by sending a Registration Update message. The PDSN starts timer Tregupd. 28
k. The source PCF responds with an A11-Registration Acknowledge message. 29
The source PDSN stops timer Tregupd. 30
l. The source PCF sends an A11-Registration Request message with Lifetime set 31
to zero. The source PCF starts timer Tregreq. 32
m. The source PDSN stores the accounting related information for further 33
processing before returning A11-Registration Reply message with an accept 34
indication. The source PCF closes the A10 connection for the mobile. The 35
source PCF stops timer Tregreq. 36
3.17.5.10 Inter-PCF Hard Handoff – Mobile Continues to be Served by the Serving PDSN 37
In order to obtain packet data services, the mobile performed registration with the packet 38
network. The traffic channel is assigned and an A10 connection established between the 39
source PCF and the PDSN. It results in establishment of the link layer (PPP) connection 40
and Mobile IP registration (if required) with the serving packet network. The source PCF 41
continues to perform re-registrations for the A10 connection with the PDSN-S by the 42
exchange of A11-Registration Request messages and A11-Registration Reply messages 43
before expiration of A10 connection Lifetime timer Trp. 44
3GPP2 A.S0013-0 v2.0
Section 3 149
The mobile roams into the coverage area of a target BS resulting in a hard handoff. After 1
exchange of appropriate messages between the MSC and the source BS and the target 2
BS, the mobile is acquired by the target BS. The target PCF establishes an A10 3
connection with the PDSN. User data is exchanged between the mobile and the 4
correspondent node over the new A10 connection, encapsulated within GRE frames. The 5
PDSN releases the A10 connection with the source PCF. The target PCF periodically re-6
registers with the PDSN by the use of the A11-Registration Request message before the 7
A10 connection Lifetime expires. 8
3GPP2 A.S0013-0 v2.0
Section 3 150
x
Extended/General Handoff Direction
MS Source BS/PCF
time comment
Handoff Required
Handoff Request
a
b
c
d
e
f
Null forward traffic channels Frames
Handoff Request Ack
g
h
Handoff Complete
i
k
m
j
PDSN
A11-Registration Update
A11-Registration
A11-Registration Reply
User Data Transmission
A11-Registration Acknowledge
A11-Registration Reply
n
o
q
s
p
t
u
r
Handoff Command
T7
MS Ack Order Twaitho
Handoff Commenced
l
Reverse Traffic Channel Preamble or Data
Handoff Completion
BS Ack
Clear Complete
Clear Command
A11-Registration Request
T315
T306
MSC
Tregreq
Tregupd
Tregreq
Trp
Target BS/PCF
T11
T9
1
Figure 3.17.5.10-1 Inter-PCF Hard Handoff – Mobile Continues to be Served by the Serving PDSN 2
a. On detection of a condition that a hard handoff is required, the source BS 3
sends a Handoff Required message to the MSC with a preferred list of target 4
cells, and starts timer T7. The source BS includes the PANID of the source 5
PCF. 6
3GPP2 A.S0013-0 v2.0
Section 3 151
b. The MSC tries each of the elements in the preferred cell list until one cell is 1
found that has an available radio channel. The MSC sends a Handoff Request 2
message to the target BS which will include the PANID. The MSC starts timer 3
T11. 4
c. Upon receipt of the Handoff Request message, target BS allocates suitable 5
idle (radio) resources. The target BS starts transmitting null TCH data on the 6
forward traffic channel for the mobile. 7
d. The target BS returns a Handoff Request Ack message to the MSC with 8
appropriate RF channel information to allow the mobile to be instructed to 9
tune to the new RF channel, and starts timer T9 to wait for the mobile to arrive 10
on the radio channel. Upon receipt of the Handoff Request Ack message from 11
target BS, the MSC stops timer T11. 12
e. The MSC prepares to switch the call from source BS to target BS. The MSC 13
sends a Handoff Command message to source BS containing appropriate RF 14
channel information received from target BS. The source BS stops timer T7 15
upon receipt of this message. 16
f. The source BS instructs the mobile to handoff by sending the Handoff 17
Direction message. If the MS is allowed to return to the source BS, then timer 18
Twaitho is started by the source BS. 19
g. The mobile acknowledges receipt of the handoff direction message (HDM, 20
GHDM, EHDM, UHDM) by sending an MS Ack Order message to source 21
BS. 22
h. Upon receipt of confirmation from the mobile, the source BS sends a Handoff 23
Commenced message to the MSC. The source BS starts timer T306 to await 24
the Clear Command message from the MSC. If timer Twaitho has been started, 25
the source BS shall wait for that timer to expire before sending the Handoff 26
Commenced message. 27
i. The mobile starts sending reverse TCH frames or preamble data to the target 28
BS. 29
j. Upon synchronization of the traffic channel, the mobile sends a Handoff 30
Completion Message to the target BS. The target BS detects that the mobile 31
has successfully accessed the target BS and stops timer T9. 32
k. The target BS acknowledges receipt of the Handoff Completion Message by 33
sending a BS Ack Order to the mobile. 34
l. The target BS then sends a Handoff Complete message to the MSC indicating 35
successful completion of hard handoff. 36
m. The target PCF sends an A11-Registration Request message with a non-zero 37
Lifetime value and with a Mobility Event Indicator within 38
Vendor/Organization Specific Extension to the PDSN. This message also 39
includes Accounting Data (R-P Session Setup Airlink Record). It will also 40
include the PANID received and insert it’s own CANID) within a 41
Vendor/Organization Specific Extension. The PCF starts timer Tregreq. The 42
A11-Registration Request message is validated and PDSN accepts the 43
connection by returning an A11-Registration Reply message with an accept 44
indication. If the PDSN has data for the mobile, it responds to the PCF with an 45
A11-Registration Reply message with the Data Available Indicator in the 46
Vendor/Organization Specific Extension. The A10 connection binding 47
information at the PDSN is updated to point to target PCF. The target PCF 48
stops timer Tregreq. 49
3GPP2 A.S0013-0 v2.0
Section 3 152
n. The A11-Registration Request message is validated and PDSN accepts the 1
connection by returning an A11-Registration Reply message with an accept 2
indication. . If the PDSN has data for the mobile, it responds to the PCF with 3
an A11-Registration Reply message with the Data Available Indicator in the 4
Vendor/Organization Specific Extension. The A10 connection binding 5
information at the PDSN is updated to point to target PCF. The target PCF 6
stops timer Tregreq. 7
o. User data is exchanged between the mobile and the correspondent node over 8
this A10 connection. 9
p. Upon receipt of a Handoff Complete, the MSC initiates release of the MSC 10
resources used in the handoff. The MSC then sends a Clear Command 11
message to the source BS, informing it of the success of the hard handoff. The 12
source BS stops timer T306. The MSC starts timer T315 also. 13
q. The source BS sends a Clear Complete message to the MSC acknowledging 14
success of the handoff. MSC stops timer T315 on receipt of the Clear 15
Complete message. 16
r. The PDSN initiates release of the A10 connection with the source PCF by 17
sending an A11-Registration Update message. The PDSN starts timer Tregupd. 18
s. The source PCF responds with an A11-Registration Acknowledge message. 19
The PDSN stops timer Tregupd. 20
t. The source PCF sends an A11-Registration Request message with Lifetime set 21
to zero, and accounting related information to the PDSN. The source PCF 22
starts timer Tregreq. 23
u. The PDSN stores the accounting related information for further processing 24
before returning an A11-Registration Reply message with an accept 25
indication. The source PCF closes the A10 connection for the mobile. The 26
source PCF stops timer Tregreq. 27
3.17.5.11 Inter-BS Hard Handoff – Mobile Served by a New Target PDSN 28
In order to obtain packet data services, the mobile performed registration with the packet 29
network. The traffic channel is assigned and an A10 connection is established between 30
the source PCF and the source PDSN on behalf of the mobile. It results in establishment 31
of the link layer (PPP) connection and Mobile IP registration (if required) with the 32
serving packet network. The source PCF continues to perform re-registrations for the 33
A10 connection with the source PDSN by the exchange of A11-Registration Request 34
messages and A11-Registration Reply messages before expiration of A10 connection 35
Lifetime timer Trp. 36
The mobile roams into the coverage area of a target BS resulting in a hard handoff. After 37
exchange of appropriate messages between the MSC and the source BS, the mobile is 38
acquired by the target BS. The target PCF establishes an A10 connection with the target 39
PDSN. Link layer (PPP) establishment between the mobile and target PDSN and Mobile 40
IP re-registration (if required) between the mobile and the packet network may then be 41
performed. The target PCF is required to forward the PANID of the source PCF and the 42
CANID of the target PCF to the serving PDSN. User data is exchanged between the 43
mobile and the correspondent node over the new A10 connection, encapsulated within 44
GRE frames. The source PDSN releases the A10 connection with the source PCF on 45
expiration of the Lifetime timer (Trp) or other events internal to the PDSN. The target 46
3GPP2 A.S0013-0 v2.0
Section 3 153
PCF periodically re-registers with the target PDSN by the use of the A11-Registration 1
Request message before the A10 connection Lifetime expires. 2
x
MS Source BS/PCF
time comment
Handoff Required
Handoff Request
a
b
c
d
e
f
Null forward traffic channels Frames
Handoff Request Ack
g
h
Handoff Complete
i
k
m
j
A11-Registration Update
A11-Registration Request
A11-Registration Reply
User Data Transmission
A11-Registration Acknowledge
A11-Registration Reply
n
o
q
s
p
t
u
r
Handoff Command
T7
Extended/General Handoff Direction
MS Ack Order Twaitho
Handoff Commenced
l
Reverse Traffic Channel Preamble or Data
Handoff Completion
Clear Complete
Clear Command
A11-Registration Request
T9
T315
T306
MSC
Tregreq
Tregupd
Tregreq
BS Ack
Target BS/PCF
Target PDSN
Source PDSN
T11
3
Figure 3.17.5.11-1 Inter-BS Hard Handoff – Mobile Served by New Target PDSN 4
3GPP2 A.S0013-0 v2.0
Section 3 154
a. On detection of a condition that a hard handoff is required, the source BS 1
sends a Handoff Required message to the MSC with a preferred list of target 2
cells, and starts timer T7. The source BS includes the PANID of the source 3
PCF. 4
b. The MSC tries each of the elements in the preferred cell list until one cell is 5
found that has an available radio channel. The MSC sends a Handoff Request 6
message to the target BS, which includes the PANID received from the source 7
BS, and starts timer T11. 8
c. Upon receipt of the Handoff Request message, the target BS allocates suitable 9
idle (radio) resources. The BS starts transmitting null TCH data on the 10
forward traffic channel for the mobile. 11
d. The target BS returns a Handoff Request Ack message to the MSC with 12
appropriate RF channel information to allow the mobile to be instructed to 13
tune to the new RF channel, and starts timer T9 to wait for the mobile to arrive 14
on the radio channel. Upon receipt of the Handoff Request Ack message from 15
the target BS, the MSC stops timer T11. 16
e. The MSC prepares to switch the call from source BS to target BS. The MSC 17
sends a Handoff Command message to source BS containing appropriate RF 18
channel information received from the target BS. Upon receipt of the Handoff 19
Command message, the source BS stops timer T7. 20
f. The source BS instructs the mobile to handoff by sending a Handoff Direction 21
message. If the MS is allowed to return to the source BS, then timer Twaitho is 22
started by the source BS. 23
g. The mobile acknowledges receipt of the Handoff Direction message 24
(HDM/GHDM/EHDM) by sending an MS Ack Order message to source BS. 25
h. Upon receipt of confirmation from the mobile, the source BS sends a Handoff 26
Commenced message to the MSC. The source BS starts timer T306 to await 27
the Clear Command message from the MSC. If timer Twaitho has been started, 28
the source BS shall wait for that timer to expire before sending the Handoff 29
Commenced message. 30
i. The mobile starts sending reverse TCH frames or preamble data to the target 31
BS. 32
j. Upon synchronization of the traffic channel, the mobile sends a Handoff 33
Completion Message to the target BS. The target BS detects that the mobile 34
has successfully accessed the target and stops timer T9. 35
k. The target BS acknowledges receipt of the Handoff Completion Message by 36
sending a BS Ack Order to the mobile. 37
l. The target BS then sends a Handoff Complete message to the MSC indicating 38
successful completion of hard handoff. 39
m. The target PCF selects the target PDSN for this call and sends an A11-40
Registration Request message with a non-zero Lifetime value and with 41
Mobility Event Indicator within the NVSE to the target PDSN. This message 42
also includes Accounting Data (R-P Session Setup Airlink Record). This 43
message also includes the PANID the target PCF received and the target 44
PCF’s CANID; both are included within an NVSE. The target PCF starts 45
timer Tregreq. 46
3GPP2 A.S0013-0 v2.0
Section 3 155
n. The A11-Registration Request message is validated and the target PDSN 1
accepts the connection by returning an A11-Registration Reply message with 2
an accept indication and a Data Available Indicator within the NVSE. The 3
target PCF stops timer Tregreq. 4
o. The link layer (PPP) connection between the mobile and the target PDSN is 5
established and the mobile performs MIP registration (if required) with the 6
packet network. User data is exchanged between the mobile and the 7
correspondent node over this A10 connection. 8
p. Upon receipt of Handoff Complete, the MSC initiates release of the MSC 9
resources used in the handoff. MSC then sends a Clear Command message to 10
the source BS, informing it of the success of the hard handoff. The source BS 11
stops timer T306. The MSC starts timer T315. 12
q. The source BS sends a Clear Complete message to the MSC acknowledging 13
success of the handoff. MSC stops timer T315 on receipt of the Clear 14
Complete message. 15
r. On expiration of Lifetime timer (Trp), the source PDSN initiates closure of the 16
A10 connection with the PCF by sending an A11-Registration Update 17
message. The source PDSN starts timer Tregupd. 18
Note: additionally the source PCF has the option to immediately tear down the 19
A10 connection by sending an A11-Registration Request message with 20
lifetime = 0, instead of the source PDSN waiting for the Lifetime timer (Trp) 21
to expire. The tear down is triggered by the clear procedure started from the 22
MSC. 23
s. The source PCF responds with an A11-Registration Acknowledge message. 24
The source PDSN stops timer Tregupd. 25
t. The source PCF sends an A11-Registration Request message with Lifetime set 26
to zero, and accounting related information to the source PDSN. The source 27
PCF starts timer Tregreq. 28
u. The source PDSN stores the accounting related information for further 29
processing before returning the A11-Registration Reply message with an 30
accept indication. The source PCF closes the A10 connection for the mobile. 31
The source PCF stops timer Tregreq. 32
3GPP2 A.S0013-0 v2.0
Section 3 156
3.17.5.12 Accounting update due to parameter changes 1
BS/PCF MS MSC PDSN
b
c
d
Parameter
change
notification/
A11-Registration Request
Active PPP session a
Parameter
change
notification/
A11-Registration Reply
time
Tregreq
2
Figure 3.17.5.12-1 Accounting Update Due to Parameter Change 3
a. An active PPP session exists and data is transferred over the connection. 4
b. An event occurs causing parameters to be changed/negotiated between the 5
BS/MSC and the MS. 6
c. The PCF sends an A11-Registration Request message to notify the PDSN 7
when any of the following parameters have changed: User-Zone, Quality of 8
Service, Forward/Reverse Mux Option (refer to [5]). The message contains 9
the airlink records “Active-Stop” followed by an “Active Start” with the new 10
set of parameters. The PCF starts timer Tregreq. 11
d. The PDSN updates the accounting data and returns an A11-Registration-12
Reply message with an accept indication back to PCF. The PCF stops Tregreq 13
3.17.6 Version Interoperability Control 14
This section describes version control on the A10/A11 and A8/A9 interfaces. 15
3.17.6.1 A8/A9 Version Control 16
17
3.17.6.1.1 Example of a Successful BS initiated A9-Version Control Procedure 18
This call flow shows an example of a successful BS initiated A9-version control 19
procedure. 20
3GPP2 A.S0013-0 v2.0
Section 3 157
Time
a
b
BS PCF
A9-Version Info Ack
A9-Version Info
Comment
Tvers9
1
Figure 3.17.6.1.1-1 Successful BS Initiated A9-Version Control Procedure 2
a. The BS sends an A9-Version Info message to the PCF. The message includes 3
the BS software version information. If the message is sent as a result of a 4
reset, a Cause element is included in the message to indicate that a BS reset 5
occurred. The BS starts timer Tvers9. 6
b. The PCF responds with an A9-Version Info Ack message, which includes the 7
PCF’s software version information. If a BS reset occurred, the PCF initiates a 8
release of any resources previously allocated for packet data calls supported 9
by the BS. Upon reception of the message, the BS stops timer Tvers9. 10
3.17.6.1.2 Example of a Successful PCF Initiated A9-Version Control Procedure 11
This call flow shows an example of a successful PCF initiated A9-version control 12
procedure. 13
Time
a
b
BS PCF
A9-Version Info Ack
A9-Version Info
Comment
Tvers9
14
Figure 3.17.6.1.2-1 Successful PCF Initiated A9-Version Control Procedure 15
a. The PCF sends an A9-Version Info message to the BS. The message includes 16
the PCF software version information. If the message is sent as a result of a 17
reset, a Cause element is included in the message to indicate that a PCF reset 18
occurred. The PCF starts timer Tvers9. 19
b. The BS responds with an A9-Version Info Ack message, which includes the 20
BS software version information. If a PCF reset occurred, the BS releases any 21
resources previously allocated for packet data calls supported by the PCF. 22
Upon reception of the message, the PCF stops timer Tvers9. 23
3.17.6.2 A10/A11 Version Control 24
To preserve the interoperability between a PDSN and a PCF that have different IOS 25
versions, the use of two element types for the VOSE (Vendor Organization Specific 26
Extension) element is required, starting with the IOS version 4.1. The two types of VOSE 27
elements (i.e., the Critical VOSE and the Normal VOSE) are defined in [35]. 28
3GPP2 A.S0013-0 v2.0
Section 3 158
If all new Application Types (and associated information) — introduced in IOS version 1
4.1 and later — are included only in the Normal VOSE element, then a receiving entity 2
(PDSN or PCF) with an older IOS version (i.e., does not recognize an Application Type 3
or an Application Sub Type in the Normal VOSE element), simply shall ignore the 4
VOSE element. In this case, the remaining elements of a registration message are 5
processed by a receiving entity. Therefore the interoperability between the PDSN and the 6
PCF is preserved. 7
If an Application Type or an Application Sub Type (and associated information) are 8
included in a Critical VOSE element, and a receiving entity (PDSN or PCF) does not 9
recognize the fields in the VOSE element, then the receiving entity shall reject the 10
registration message containing the VOSE element. 11
3.17.7 Support of Short Data Bursts 12
This section describes call flows associated with the Short Data Burst feature. 13
3.17.7.1 A8/A9 Call Flows 14
15
3.17.7.1.1 Mobile Originated Short Data Burst Call Flows 16
An MS with a currently dormant packet data service instance may need to send a small 17
amount of data to the network. The MS may transmit it via a Short Data Burst (SDB) to 18
the BS in SDB format as specified in [23]. The short data burst is sent from the MS to the 19
BS over the signaling channel if there is not an active voice call in progress and over the 20
traffic channel if there is an active voice call in progress. If authentication is enabled in 21
the network (and the mobile is not engaged in an active voice call), before the data is sent 22
on from the BS, the MS may need to be authenticated. If authentication is performed, the 23
BS shall buffer the data during the authentication procedure. If authentication is 24
successful or not performed, the PCF sends this data on to the PDSN as normal packet 25
data. For A8/A9 implementations, the data shall be sent to the PCF in SDB format as 26
specified in [23]. The PCF shall then forward this data on to the PDSN as normal packet 27
data. 28
The following procedure shows the call flow associated with the receipt of a short data 29
burst on the access channel from the MS and it’s delivery to the PCF. This scenario 30
assumes that the mobile is not engaged in an active voice call. 31
3GPP2 A.S0013-0 v2.0
Section 3 159
A11-Reqistration Request
A11-Registration Reply
T60
ADDS Transfer
Layer 2 Ack
A9-Short Data Delivery
MS BS MSC PCF PDSN Time Comment
ADDS Transfer Ack
Dormant/PPP connected
a
b
c --- Optional
d --- Optional
e
Data Burst (type SDB)
f Packet
g
h
Tregreq
Dormant/PPP connected
1
Figure 3.17.7.1.1-1 cdma2000 Short Data Burst from an MS to the PCF 2
a. The MS sends an cdma2000 Short Data Burst to the network on the signaling 3
channel. 4
b. The BS acknowledges the cdma2000 Short Data Burst received on the 5
signaling channel by sending a Layer 2 Ack. 6
c. If the BS chooses to authenticate the mobile, the BS sends an ADDS Transfer 7
message to the MSC containing the authentication parameters received from 8
the MS, the BS computed authentication data element, and the data burst type 9
field of the ADDS User Part element set to short data burst. If authentication 10
is performed, the BS shall buffer the SDB data and start timer T60. The MSC 11
receives the ADDS Transfer message, reads the burst type field of the ADDS 12
User Part element, and determines that this an cdma2000 short data burst. The 13
MSC may then authenticate the MS. 14
d. The MSC sends the result of the short data burst authentication to the BS in 15
the ADDS Transfer Ack message. Upon receipt of the ADDS Transfer Ack 16
message, the BS stops timer T60. If the cause element is present and indicates 17
authentication failure, the BS shall discard the buffered data burst. If timer T60 18
expires at the BS before the BS receives the ADDS Transfer Ack message, the 19
BS shall discard the buffered short data burst. 20
3GPP2 A.S0013-0 v2.0
Section 3 160
e. If no cause element is present in the ADDS Transfer Ack response from the 1
MSC, or the BS chose not to authenticate the mobile, the BS sends the data 2
burst to the PCF in SDB format as specified in [23] in the A9-Short Data 3
Delivery message. 4
f. The PCF sends the data to the PDSN as normal packet data. 5
g. The PCF sends an A11-Registration Request message with the SDB Airlink 6
record to the PDSN. The PCF starts timer Tregreq. 7
h. The PDSN responds with A11–Registration Reply. The PCF stop Tregreq. 8
3.17.7.1.2 Mobile Terminated Short Data Burst Call Flows 9
When a small amount of data destined for a dormant packet data service instance on an 10
MS is received at the PCF, the PCF may send this data to the BS in SDB format as 11
specified in [23]. The PCF shall set a timer after sending the data to the mobile and shall 12
buffer this data. 13
If the BS accepts the data for delivery to the MS, the BS shall acknowledge the PCF’s 14
request. The PCF may then discard the buffered data. 15
If the BS determines that a short data burst may be used to deliver the data to the mobile, 16
the BS sends this data, in SDB format as specified in [23], directly to the mobile over the 17
signaling or traffic channel. 18
The BS may also send this data, in SDB format, on to the MSC for delivery to the MS via 19
the ADDS Page or ADDS Deliver procedure. The data is delivered to the MSC using the 20
BS Service Request/Response procedure. Furthermore, if the BS is unsuccessful in 21
delivering the SDB to the MS on its own, it may then choose to send the data to the MSC 22
for delivery to the mobile via the ADDS Page procedure. 23
If after receiving data from the PCF in SDB format the BS determines that the packet 24
data service instance should be re-activated, it shall reject the PCF’s request to send the 25
data as a short data burst. The PCF shall then be required to initiate the re-activation of 26
the packet data service instance. Once the session is active, the buffered data shall be 27
resent to the BS for transmission to the MS as normal packet data. 28
3.17.7.1.2.1 Short Data Delivery from the PCF to the MS 29
The following procedure shows the call flow associated with the receipt of a short data 30
message from the PCF and its delivery to the MS. 31
3GPP2 A.S0013-0 v2.0
Section 3 161
T311
A9-Short Data Ack
A11-Registration Reply
All-Registration Request
Data Burst (Type SDB)
Data Burst (SDB)
MS BS MSC/VLR PCF PDSN Time
Dormant/PPP connected
b
f
g
h
j
BS Service Response T311
Layer 2 Ack
BS Service Request
A9-Short Data Delivery
ADDS Page
Procedure.
Packet data a
Layer 2 Ack d
i
Tsdd
k
l
c
e
A9-Update-A8
A9-Update-A8 Ack
Tupd9 Tregreq
1
Figure 3.17.7.1.2.1-1 cdma2000 Short Data Burst from the PCF to the MS 2
a. The PDSN sends packet data to the PCF on an existing PPP connection and 3
A10 connection associated with a specific mobile. The PCF sends the packet 4
data to the BS in the A9 Short Data Delivery Message and starts timer Tsdd9. 5
The data is sent in SDB format as specified in [23] and is encapsulated in the 6
ADDS user part element. The PCF buffers the data sent. 7
b. The BS acknowledges receipt of the A9-Short Data Delivery message from 8
the PCF by returning the A9-Short Data Delivery Ack message along with an 9
indication that the BS shall attempt to send the data to the mobile as a short 10
data burst. The PCF stops timer Tsdd9 and discards the buffered data. If timer 11
Tsdd9 expires, the PCF discards the buffered data. 12
3GPP2 A.S0013-0 v2.0
Section 3 162
c. The BS may send a short data burst directly to the mobile, or alternatively the 1
BS may skip to step e to initiate the ADDS Page procedure. Note, the BS may 2
also decide to alternatively deliver the data to the mobile over a traffic channel 3
(refer to section 3.17.4.7).. 4
d. The MS sends a layer 2 acknowledgement in response to the short data burst 5
from the BS. If a layer 2 Ack is not received from the mobile, the BS may 6
continue with steps e-h below. If the Layer 2 Ack is received, the call flow 7
continues with step i. 8
e. The BS sends the SDB data in a SDB format to the MSC in the BS Service 9
Request message. The BS starts timer T311. If timer T311 expires, the SDB 10
information shall not be sent to the MS. 11
f. The MSC acknowledges reception of the BS Service Request message by 12
sending a BS Service Response message to the BS. The BS stops timer T311. 13
g. The MSC sends an ADDS Page message to the BS with the data burst type 14
field in the ADDS User Part element set to Short Data Burst, and the SDB in 15
the Application Data Message field. The BS forwards the Short Data Burst on 16
to the MS. 17
h. A layer 2 acknowledgement is sent by the MS after receiving the SDB from 18
the BS. If the MSC included a Tag element in the ADDS Page message, then 19
the BS returns an ADDS Page Ack message to the MSC after receiving the 20
layer 2 Ack from the mobile. The Tag element received from the MSC is 21
included in the message. 22
i. The BS sends an A9-Update-A8 message to the PCF to indicate successful 23
transmission of the Short Data Burst to the MS. The BS starts timer Tupd9. 24
j. The PCF sends an A11-Registration Request message with the SDB Airlink 25
record to the PDSN. The PCF starts timer Tregreq. 26
k. The PDSN responds with the A11–Registration Reply message. The PCF 27
stops Tregreq. 28
l. The PCF responds to the BS with an A9-Update-A8 Ack. The BS stops timer 29
Tupd9. 30
3.17.7.1.2.2 Short Data Delivery from the PCF – BS Refuses SDB Request 31
The following procedure shows the call flow associated with the BS refusal of the PCF 32
short data burst request, and delivery of the data to the mobile. 33
3GPP2 A.S0013-0 v2.0
Section 3 163
T311 MS BS MSC PCF PDSN Time
Dormant/PPP connected
b
f
A9-Short Data Delivery
Network initiated call
re-activation from dormant state
Active Packet Data Session
Packet data
a
c A9-Short Data Ack
Tsdd
d
e
1
Figure 3.17.7.1.2.2-1 cdma2000 Short Data Burst from the PCF to the MS 2
a. Packet data service is dormant. 3
b. The PDSN sends packet data to the PCF on an existing A10 connection 4
associated with a specific mobile. 5
c. The PCF sends the packet data to the BS in the A9-Short Data Delivery 6
message and sets timer Tsdd9. The data is sent in SDB format as specified in 7
[23] and is encapsulated in the ADDS user part element. The PCF buffers the 8
data sent. 9
d. The BS makes the determination, based on its internal algorithm, the data 10
count field in the A9-Short Data Delivery, or any other factors, not to send a 11
short data burst to the mobile. The BS sends an A9-Short Data Delivery Ack 12
message to the PCF with an indication that a short data burst is not to be sent 13
to the mobile by setting the Cause value to ‘Initiate Re-activation of Packet 14
Data Call’. 15
e. The PCF stops timer Tsdd9 and initiates a reactivation of the packet data 16
service. 17
f. Once the packet data service instance is active, the PCF sends the data 18
buffered earlier for the mobile to the BS which forwards the data on to the 19
mobile. 20
21
3GPP2 A.S0013-0 v2.0
Section 3 164
3.17.7.2 A10/A11 Call Flows 1
2
3.17.7.2.1 Short Data Burst Delivery to the PDSN 3
The following procedure shows the call flow associated with the receipt of a short data 4
burst on the access channel from the MS and its delivery to the PDSN. 5
a
b
c
Data Burst (type – SDB)
Layer 2 Ack
ADDS Transfer Ack
ADDS Transfer
d
PDSN BS/PCF MSC
packet data e
f
g
A11-Registration Request
A11-Registration Reply Tregreq
6
Figure 3.17.7.2.1-1 cdma2000 Short Data Burst from the MS to the PDSN 7
a. The MS sends an cdma2000 Short Data Burst to the network on the signaling 8
channel. 9
b. The BS acknowledges the cdma2000 Short Data Burst by sending a Layer 2 10
Ack on the paging channel. 11
c. If the BS chooses to authenticate the mobile, the BS sends an ADDS Transfer 12
message to the MSC containing the authentication parameters received from 13
the MS, the BS computed authentication data element, and the data burst type 14
field of the ADDS User Part element set to short data burst. If authentication 15
is performed, the BS shall buffer the SDB data and start timer T60. The MSC 16
receives the ADDS Transfer message, reads the burst type field of the ADDS 17
User Part element, and determines that this an cdma2000 short data burst. The 18
MSC may then authenticate the MS. 19
3GPP2 A.S0013-0 v2.0
Section 3 165
d. The MSC sends the result of the short data burst authentication to the BS in 1
the ADDS Transfer Ack message. If the cause element is present and indicates 2
authentication failure, the BS discards the data burst. If no cause element is 3
present, the BS sends the data burst to the PDSN. If timer T60 expires at the 4
BS before the BS receives the ADDS Transfer Response message, the BS 5
shall discard the short data burst. 6
Note: if the MSC chooses not to authenticate the mobile, the ADDS Transfer 7
Ack message shall still be sent to the BS. 8
e. If no cause element is present, or if authentication is not performed, the 9
BS/PCF sends the packet data to the PDSN. 10
f. The BS/PCF sends an A11-Registration Request message with the SDB 11
Airlink record to the PDSN. The PCF starts timer Tregreq. 12
g. The PDSN responds with the A11–Registration Reply message. The PCF 13
stops Tregreq. 14
3.17.7.2.2 Short Data Burst Delivery from the PDSN to the MS 15
The following procedure shows the call flow associated with the receipt of packet data 16
from the PDSN and its Short Data Burst delivery to the MS. 17
Time
a
b
c
MS
d
BS Service Request
BS Service Response
ADDS Page Procedure - See sect. 2.5.3.2
Layer 2 Ack
Data Burst (type – SDB)
T311
Packet data
BS/PCF MSC PDSN
Data Burst (type – SDB)
Layer 2 Ack
e
f
g
h
A11-Registration Request
A11-Registration Reply Tregreq
18
Figure 3.17.7.2.2-1 cdma2000 Short Data Burst from the PDSN to the MS 19
3GPP2 A.S0013-0 v2.0
Section 3 166
a. The PCF receives packet data from the PDSN and determines that this data 1
can be delivered to the dormant packet data service instance. The BS may 2
send a short data burst directly to the mobile. If the received data is for a 3
CCPD Device, the packet data shall always be sent to the mobile in a Short 4
Data Burst. 5
b. The MS sends a layer 2 acknowledgement in response to the short data burst 6
from the BS. If a layer 2 Ack is not received from the mobile the BS may 7
attempt to re-send the data to the MS. 8
c. Alternatively, the BS may send the data in SDB format as specified in [23] to 9
the MSC in the BS Service Request message. The BS starts timer T311. If 10
timer T311 expires, the SDB information is not sent to the MS. This step may 11
also occur if the BS fails to successfully deliver the SDB to the MS. 12
d. The MSC acknowledges the reception of the BS Service Request message by 13
sending a BS Service Response message to the BS. The BS stops timer T311. 14
e. The MSC sends an ADDS Page message to the BS with the data burst type 15
field in the ADDS User Part element set to Short Data Burst, and the SDB in 16
the Application Data Message field. The BS forwards the Short Data Burst on 17
to the MS. 18
f. A layer 2 acknowledgement is sent by the MS after receiving the SDB from 19
the BS. If the MSC included a Tag element in the ADDS Page message, then 20
the BS returns an ADDS Page Ack message to the MSC after receiving the 21
layer 2 Ack from the mobile. The Tag element received from the MSC is 22
included in the message. 23
g. The BS/PCF sends an A11-Registration Request message with the SDB 24
Airlink record to the PDSN. The PCF starts timer Tregreq. 25
h. The PDSN responds with the A11-Registration Reply message. The PCF 26
stops Tregreq. 27
3.17.8 Support for Common Channel Packet Data (CCPD) 28
This section describes support for Common Channel Packet Data (CCPD) mode of 29
packet data service. 30
3.17.8.1 A8/A9 Call Flows 31
This section describes call flows for CCPD support on the A8/A9 interface. 32
3.17.8.1.1 Mobile Originated CCPD Mode Request 33
A CCPD Device requests CCPD Mode from the network by sending an Origination 34
Message to the BS with the SDB_DESIRED_ONLY bit set to 1 and the 35
FCH_SUPPORTED and DCCH_SUPPORTED bits set to 0. Upon successful 36
authentication of the mobile, the PCF is informed that the call is for a CCPD Device. An 37
A8 bearer connection is not required. PPP connection setup and Mobile IP Registration 38
(if required) are performed using Short Data Bursts over Common Channels to exchange 39
the messages. Messages and data between the BS and PCF are passed over the A9 40
signaling channel. Upon successful completion of these procedures, the mobile’s packet 41
data service instance transitions from the Null/Inactive to Dormant state. A CCPD 42
Device’s packet data service state shall never transition to the Active/Connected state. 43
Upon successful establishment of the packet data session, the CCPD device and network 44
3GPP2 A.S0013-0 v2.0
Section 3 167
may exchange small amounts of data over common channels. Mobile IP Registration is 1
not required for CCPD applications that do not require mobility. The first Short Data 2
Burst sent to the CCPD Device serves as an acknowledgement of the mobile’s request for 3
CCPD Mode. If the BS is unable to support the mobile’s CCPD Mode request, the call 4
attempt shall fail. The CCPD Device may retry a CCPD Mode request. 5
A CCPD capable mobile requests CCPD Mode from the network by sending an 6
Origination Message to the BS with the SDB_DESIRED_ONLY and 7
FCH_SUPPORTED and/or DCCH_SUPPORTED bits set to 1. If the BS agrees to 8
support a mobile’s request for CCPD Mode, the mobile is first authenticated. Upon 9
successful authentication of the mobile, the PCF is informed that CCPD Mode shall be 10
used for the call. PPP connection setup and Mobile IP Registration (if required) are 11
performed using Short Data Bursts over Common Channels to exchange the messages. 12
Messages and data between the BS and PCF are passed over the A9 signaling channel; an 13
A8 bearer connection is not required. Upon successful completion of these procedures, 14
the mobile’s packet data service state transitions from the Null to the Dormant State. The 15
first Short Data Burst sent to the CCPD Capable mobile serves as an acknowledgement 16
for the request for CCPD Mode, the network may deny a CCPD capable mobile’s request 17
for CCPD Mode and apply normal packet data procedures to setup the packet data call or 18
transmit packet data. 19
Upon successful completion of PPP Connection and Mobile IP Registration (if required), 20
the CCPD mobile’s packet data service instance transitions from a Null/Inactive to 21
Dormant state. Note, if a CCPD mobile does not require support for mobility, Mobile IP 22
Registration is not required and Simple IP may be used. 23
The following messages are used to support a Mobile Originated CCPD Mode Request: 24
• ADDS Transfer 25
• ADDS Transfer Ack 26
• A9-Setup-A8 27
• A9-Release-A8 Complete 28
• A9-Short Data Delivery 29
• A11-Registration Request 30
• A-11 Registration Reply 31
The following call flow describes an MS initiated Common Channel Packet Data call. 32
When a CCPD mobile initiates a packet data call setup, upon successful authentication of 33
the CCPD mobile, a PPP connection setup and Mobile IP Registration (if required) are 34
performed using Short Data Bursts over the A9 signaling channel and common channels. 35
Once the PPP connection setup has been completed, packet data is exchanged between 36
the MS and the network using Short Data Bursts over common channels. The data shall 37
be sent to the PCF in SDB format as specified in [23]. 38
3GPP2 A.S0013-0 v2.0
Section 3 168
BS MS
Origination
BS ACK Order
MSC
ADDS Transfer
A9-Setup-A8
ADDS Transfer Ack
PCF PDSN
A9- Short Data Delivery
a
b c
d
e
f
g
h
i
A10/A11
Conn. Estab. Proc.
T60
TA8-Setup
Data Burst (SDB)
Establish PPP Connection
(Short Data Bursts)
Time
Null / Inactive State
Dormant / PPP Connected
Packet Data
A11-Registration Request
A11-Registration Reply
j
k
BS Ack
l
m
A9-Release-A8 Complete
n
Tregreq
1
Figure 3.17.8.1.1-1 CCPD MS Initiated Packet Data Call Setup and Data Transfer 2
a. A CCPD mobile transmits an Origination Message to the BS over the access 3
channel of the air interface with Layer 2 acknowledgment required to request 4
packet data service. The MS indicates it’s desire for CCPD Mode to the 5
network by setting the SDB_DESIRED_ONLY bit in the message to 1. 6
b. The BS acknowledges receipt of the Origination Message by sending a Base 7
Station Acknowledgment Order to the CCPD mobile. 8
c. The BS sends an ADDS Transfer message to the MSC containing the 9
authentication parameters received from the CCPD mobile, the BS computed 10
authentication data element, and the data burst type field of the ADDS User 11
Part element set to Short Data Burst. The BS starts timer T60. If the mobile 12
3GPP2 A.S0013-0 v2.0
Section 3 169
supports traffic channels and the BS decides not to support the mobile’s 1
request for CCPD Mode, the call is treated as a normal mobile originated 2
packet data call (refer to section 3.17.4.1 for the call flow). If the BS is unable 3
to support the CCPD Mode request from a CCPD Device, the call shall fail. 4
d. The MSC sends the result of authentication for the mobile back to the BS in 5
the ADDS Transfer Ack message. If authentication of the CCPD mobile fails, 6
the MSC includes a cause value set to ‘authentication failure’ in the message 7
and the CCPD call fails. The BS stops timer T60. 8
e. The BS sends an A9-Setup-A8 message to initiate an A10 connection setup. 9
The BS sets the CCPD Mode bit in the message to 1 to indicate to the PCF 10
that an A8 connection is not required. If the mobile requesting service is a 11
CCPD Device, the BS also sets the CCPD Device bit in the message to 1 to 12
indicate to the PCF that the data session is for a CCPD Device. The BS starts 13
timer TA8-Setup. 14
f. The A10/A11 connection establishment procedure is performed. 15
g. The PDSN and CCPD mobile exchange messages over the air using short data 16
bursts over common channels to set up the PPP connection and perform 17
Mobile IP Registration (if required). All messages exchanged between the 18
network and MS are in SDB format. The PCF formats messages for the 19
mobile into SDB format before sending them to the BS. The BS sends 20
messages from the mobile to the PCF in SDB format. The PCF converts them 21
into packet data format before transmitting the data to the PDSN. The first 22
short data burst sent from the BS to the mobile serves as an acknowledgement 23
to the mobile’s request for CCPD Mode. 24
h. The PCF sends an A9-Release-A8 Complete message to the BS with a 25
successful cause value. The BS stops timer TA8-Setup. Note: this step may 26
occur anytime after step f. 27
i. The mobile sends its packet data in a Short Data Burst over the common 28
channel to the BS. 29
j. The BS acknowledges receipt of the Short Data Burst from the mobile by 30
sending a BS Ack order to the mobile. 31
k. The BS sends an A9-Short Data Delivery message containing the packet data 32
from the mobile in SDB format to the PCF. 33
l. The PCF sends the data to the PDSN as normal packet data. 34
m. The PCF sends an A11-Registration Request message with the SDB Airlink 35
record for accounting to the PDSN. The PCF starts timer Tregreq. 36
n. The PDSN responds with an A11-Registration Reply message to the PCF. The 37
PCF stops Tregreq. 38
3.17.8.1.2 Mobile Terminated Packet Data for a CCPD Device 39
The PCF was informed that the mobile is a CCPD Device at the time the mobile initiated 40
a CCPD Mode Request from the network. If the network has data to send to a dormant 41
CCPD Device, the PCF sends the data to the BS in the A9-Short Data Delivery message. 42
Since the data is for a CCPD Device, the PCF doesn’t buffer the data for the mobile and 43
therefore does not require an acknowledgement from the BS after the data has been sent. 44
The BS sends the data to the CCPD Device in a Short Data burst as specified in [23]. If 45
the BS doesn’t receive an acknowledgement from the mobile after sending the Short Data 46
3GPP2 A.S0013-0 v2.0
Section 3 170
Burst to the mobile, the BS may resend the data or invoke ADDS Procedures to deliver 1
the data. 2
The following messages are used to support a Mobile Terminated Packet Data for a 3
CCPD Device: 4
• A9-Short Data Delivery 5
• A9-Update-A8 6
• A9-Update-Ack 7
• A11-Registration Request 8
• A-11 Registration Reply 9
The following call flow describes a mobile terminated packet data transfer to a CCPD 10
Device with a dormant packet data service instance. A PPP connection setup and Mobile 11
IP Registration (if required) has previously been performed between the network and the 12
MS. The PCF was informed that the mobile is a CCPD Device during the initial packet 13
data session setup. The data shall be sent to the PCF in SDB format as specified in [23]. 14
BS MS MSC PCF PDSN
a
b
c
d
e
f
g
h
i
Time
Dormant / PPP Connected
A11-Registration Request
A11-Registration Reply
Packet Data
A9-Short Data Delivery
Data Burst (SDB)
Layer 2 Ack
A9-Update A8
A9-Update A8 Ack
Tupd9
Tregreq
15
Figure 3.17.8.1.2-1 Mobile Terminated Packet Data for a CCPD Device 16
a. PPP Connection Setup and Mobile IP Registration (if required) have 17
previously been performed. The CCPD Device is currently in a dormant 18
packet data service state. 19
b. The PDSN sends packet data from the network to the PCF for the CCPD 20
Device. 21
c. The PCF sends the packet data in SDB format in the A9-Short Data Delivery 22
message to the BS. 23
3GPP2 A.S0013-0 v2.0
Section 3 171
d. The BS sends the packet data to the CCPD Device in a Short Data Burst over 1
the common channel. 2
e. The MS acknowledges receipt of the Short Data Burst by sending a layer 2 3
Ack to the BS. If a layer 2 Ack is not received from the mobile, the BS may 4
resend the SDB to the mobile. Alternatively, the BS may use the ADDS 5
procedure to deliver the SDB to the mobile. If the ADDS procedure is used, 6
refer to section 3.10.2.4. (step f-l) for the remainder of the call flow. 7
f. The BS sends an A9-Update-A8 message to the PCF to indicate the successful 8
transmission of the short data burst to the MS. The BS starts timer Tupd9. 9
g. The PCF sends an A-11 Registration Request message with the SDB Airlink 10
record for accounting to the PDSN. The PCF starts timer Tregreq. 11
h. The PDSN responds with an A11-Registration Reply message to the PCF. The 12
PCF stops Tregreq. 13
i. The PCF responds to the BS with an A9-Update-A8 Ack message. Upon 14
receipt of this message, the BS stops timer Tupd9. 15
3.17.8.1.3 CCPD Dormant Mode Packet Data Handoffs 16
The following calls flows describe dormant handoff for CCPD Devices and CCPD 17
Capable mobiles. Upon detection of a new PZID, SID, or NID, a CCPD mobile sends an 18
Origination Message to the BS with the SDB_DESIRED _ONLY bit set to 1. The PCF 19
establishes an A10 connection with the PDSN. If the mobile continues to be served by the 20
same PDSN, the PDSN releases the A10 connection with the previous PCF. If as a result 21
of the dormant mode handoff a new PDSN is selected for the call, a PPP connection is 22
setup and Mobile IP Registration (if required) is performed using Short Data Bursts over 23
Common channels. Note, the BS may refuse a CCPD capable mobile’s request for CCPD 24
Mode by applying normal packet data dormant mode handoff procedures. 25
The BS may initiate CCPD Mode for a CCPD capable mobile which has no data to send, 26
even though the mobile may not have explicitly requested CCPD Mode from the BS by 27
setting the SDB_DESIRED_ONLY bit to 1 in the Origination Message. The BS may use 28
this procedure to support dormant mode handoffs (e.g. if traffic channels are not 29
available). Upon detection of a new PZID, SID, or NID, a CCPD capable mobile sends 30
an Origination Message to the BS with the SDB_DESIRED_ONLY bit set to 0, and the 31
DRS bit set to 0. Instead of initiating normal dormant mode handoff procedures, the BS 32
authenticates the mobile and informs the PCF that CCPD Mode shall be used to support 33
the dormant Mode handoff. 34
The following IOS messages are used to support this feature: 35
• ADDS Transfer 36
• ADDS Transfer Ack 37
• A9-Setup-A8 38
• A9-Release-A8 Complete 39
• A9-Short Data Delivery. 40
3.17.8.1.3.1 Call Flow: CCPD MS Dormant Handoff - Mobile Served by the Same PDSN 41
The following call flow describes the procedure for a successful inter-PCF/intra-PDSN 42
dormant mode handoff of a CCPD mobile. It is assumed that the PCF is uniquely 43
identified by the CANID. On detection of a new PZID, NID or SID, the CCPD mobile 44
3GPP2 A.S0013-0 v2.0
Section 3 172
sends an Origination Message to the target BS with the packet data service option and the 1
SDB_DESIRED_ONLY bit set to 1. If the call is from a CCPD Device, the 2
FCH_SUPPORTED and DCCH_SUPPORTED bits are also set to 0. The Origination 3
Message includes the previous PZID, NID and SID when any of these parameters change 4
during the dormant handoff. Based on the IDs (PZID, NID and/or SID) in the Origination 5
Message, the target PCF sends the PANID of the source PCF and the CANID of the 6
target PCF to the serving PDSN. The serving PDSN uses this information to determine if 7
PPP re-negotiation is required. All messages using the SDB format in the call flow are as 8
specified in [23]. 9
This call flow may also be used if the network decides to initiate CCPD Mode for a 10
dormant mode handoff. For this case, the Mobile sends an Origination Message with the 11
SDB_DESIRED_ONLY and DRS bits set to 0. The first Short Data Burst sent to the 12
mobile serves as an indication to the mobile that CCPD procedures shall be used to 13
support the dormant mode handoff. 14
ADDS Transfer Ack
Source BS MSC
Source PCF
Time Comment
a
b
c
d
e
f
g
h
i
PDSN Target PCF MS
ADDS Transfer
Origination Message
A9-Setup-A8
A9-Release-A8 Complete
BS Ack Order
Dormant, PPP Connected
TA8-setup
Target BS
T60
PDSN Dormant HO
Dormant / PPP Connected
Data Burst (empty)
Dormant, PPP Connected
15
Figure 3.17.8.1.3.1-1 CCPD MS Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same 16
PDSN 17
a. The CCPD mobile has previously performed PPP connection establishment 18
and MIP Registration (if required) with the PDSN and is in the dormant state. 19
b. The CCPD mobile detects a change of PZID, SID or NID while monitoring 20
the broadcast channel and sends an Origination Message with the 21
SDB_DESIRED_ONLY bit set to 1. 22
3GPP2 A.S0013-0 v2.0
Section 3 173
c. The target BS acknowledges receipt of the Origination Message with a Base 1
Station Acknowledgement Order to the CCPD mobile. 2
d. The target BS sends an ADDS Transfer message to the MSC containing the 3
authentication parameters received from the mobile, the target BS computed 4
authentication data element, and the data burst type field of the ADDS User 5
Part element set to Short Data Burst. If the target BS determines that the 6
CCPD mobile supports traffic channels, the target BS may alternatively 7
execute the MS dormant mode handoff procedure described in section 8
3.17.4.9. The Target BS starts timer T60. 9
e. The MSC sends the ADDS Transfer Ack message to the target BS with no 10
cause value present. The target BS stops timer T60. If authentication of the 11
CCPD mobile fails, the MSC includes a cause value set to ‘authentication 12
failure’ in the message and the CCPD call fails. 13
f. The target BS sends an A9-Setup-A8 message, with the Data Ready Indicator 14
and Handoff Indicator bits set to 0 to the target PCF. The target BS sets the 15
CCPD Mode bit in the message to 1 to indicate to the PCF that an A8 16
connection is not required. If the mobile is a CCPD Device, the target BS also 17
sets the CCPD Device bit in the message to 1 to indicate to the PCF that the 18
data session is for a CCPD Device. The target BS starts timer TA8-setup. 19
g. The target PCF establishes an A10/A11 link with the PDSN. The PDSN 20
disconnects the A10/A11 link with the source PCF. If the PDSN has data for 21
the mobile, it responds to the PCF with a Registration Reply message with the 22
Data Available Indicator in the Vendor/Organization Specific Extension. 23
Refer to section 3.17.1. 24
h. The target PCF sends an A9-Release-A8 Complete message to the target BS 25
with a successful cause value. The target BS stops timer TA8-setup. 26
i. The target BS sends an empty short data burst to the MS. The short data burst 27
serves as an acknowledgement to the CCPD Mode request from the MS. 28
3.17.8.1.3.2 Call Flow: Dormant Handoff of a CCPD Mobile: Mobile Served by a New PDSN 29
The following call flow describes the procedure for a successful inter-PCF/inter-PDSN 30
dormant mode handoff of a CCPD mobile. When an MS in dormant state moves into a 31
different packet zone and ends up being connected to a different PDSN, the target PCF is 32
required to forward the ANID of the source PCF (PANID) and the ANID of the target 33
PCF (CANID) to the serving PDSN. PPP connection setup and Mobile IP Registration (if 34
required) are performed using Short Data Bursts over Common channels. All messages 35
using the SDB format in the call flow are as specified in [23]. 36
This call flow may also be used if the network decides to initiate CCPD Mode for a 37
dormant mode handoff. For this case, the Mobile sends an Origination Message with the 38
SDB_DESIRED_ONLY and DRS bits set to 0. The first Short Data Burst sent to the 39
mobile indicates that CCPD procedures shall be used to support the dormant mode 40
handoff. 41
3GPP2 A.S0013-0 v2.0
Section 3 174
BS MS
Origination
BS ACK Order
MSC
ADDS Transfer
A9-Setup-A8
ADDS Transfer Ack
PCF PDSN
PPP Connection Establishment
(Short Data Bursts over Common Channel)
a
b
c
d
e
f
g
h
T60
TA8-Setup
A10/A11
Connection
Establishment
A9-Release-A8 Complete
Time
1
Figure 3.17.8.1.3.2-1 CCPD MS Dormant Handoff (Inter-BSC/Inter-PCF) - Mobile Served by 2
Different PDSN 3
a. The CCPD MS detects a change of Packet Zone ID while monitoring the 4
broadcast channel and sends an Origination Message with the 5
SDB_DESIRED_ONLY bit set to 1. 6
b. The BS acknowledges receipt of the Origination Message with a Base Station 7
Acknowledgement Order to the CCPD mobile. 8
c. The BS sends an ADDS Transfer message to the MSC containing the 9
authentication parameters received from the mobile, the BS computed 10
authentication data element, and the data burst type field of the ADDS User 11
Part element set to Short Data Burst. If the BS determines that the CCPD 12
mobile supports traffic channels, the BS may alternatively execute the MS 13
dormant mode handoff procedure described in section 3.17.4.10. The BS starts 14
timer T60. 15
d. The MSC sends the ADDS Transfer Ack message to the BS with no cause 16
value present. The BS stops timer T60. If authentication of the terminal fails, 17
the MSC includes a Cause value set to ‘authentication failure’ in the message 18
and the CCPD call fails. 19
e. The BS sends an A9-Setup-A8 message, with Data Ready Indicator and 20
Handoff Indicator bits set to 0 to the target PCF. The BS sets the CCPD Mode 21
bit in the message to 1 to indicate to the PCF that an A8 connection is not 22
required. If the mobile requesting service is a CCPD Device, the BS also sets 23
the CCPD Device bit in the message to 1 to indicate to the PCF that the data 24
session is for a CCPD Device. The BS starts timer TA8-Setup. 25
3GPP2 A.S0013-0 v2.0
Section 3 175
f. Procedure for establishing A10/A11 is performed. 1
g. The PDSN and CCPD mobile exchange messages over the air using Short 2
Data Bursts over Common channels to set up the PPP connection and perform 3
Mobile IP Registration (if required). All messages exchanged between the 4
network and MS are in SDB format. The PCF formats messages for the 5
mobile into SDB format before sending them to the BS. The BS sends 6
messages from the mobile to the PCF in SDB format. The PCF converts them 7
into packet data format before transmitting the data to the PDSN. The first 8
Short Data Burst sent from the BS to the mobile serves as an 9
acknowledgement to the mobile’s request for CCPD Mode. 10
h. The PCF sends an A9-Release-A8 Complete message to the BS with a 11
successful cause value. The BS stops timer TA8-Setup. Note: this step may 12
occur anytime after step f. If the call is for a CCPD Capable Mobile and the 13
PDSN has data for the mobile, depending on the amount of data, the PCF may 14
respond to the BS with cause value indicating failure, followed by a network 15
initiated call re-activation (refer to 3.11.4.2.7). 16
3.17.8.2 A10/A11 Call Flows 17
This section describes call flows for support of CCPD on the A10/A11 interface. 18
3.17.8.2.1 Call Flow: CCPD Mobile Originated Packet Data Call Setup – Successful 19
Operation 20
The following call flow describes the procedures for an MS initiated Common Channel 21
Packet Data call. When a CCPD mobile initiates a packet data call setup, upon successful 22
authentication of the CCPD mobile, a PPP connection setup and Mobile IP Registration 23
(if required) are performed using Short Data Bursts over Common Channels. Once a PPP 24
connection is setup, packet data is exchanged between the MS and the network using 25
Short Data Bursts over Common channels. The data shall be sent to the PCF in SDB 26
format as specified in [23]. 27
3GPP2 A.S0013-0 v2.0
Section 3 176
MS BSC/PCF MSC time comment
Origination Message
Base Station Ack Order
a
b
c
d
e
f
ADDS Transfer
ADDS Transfer Ack
g
h Data Burst (SDB)
i
k l
j
T60
PDSN
A11-Registration Request (Accounting Data)
A11-Registration Request (Lifetime)
A11-Registration Reply (Lifetime, Accept)
Establish PPP Connection (Short Data Bursts)
BS Ack Order
A11-Registration Reply (Accept)
Tregreq
Tregreq
Trp
Packet Data
1
Figure 3.17.8.2.1-1 Mobile Originated CCPD Call Setup – Successful Operation 2
a. A CCPD mobile transmits an Origination Message to the BS over the access 3
channel of the air interface with Layer 2 acknowledgment required to request 4
packet data service. The MS indicates its desire for CCPD Mode to the 5
network by setting the SDB_DESIRED_ONLY bit in the message to 1. 6
b. The BS acknowledges receipt of the Origination Message with a Base Station 7
Ack Order to the mobile. 8
c. The BS sends an ADDS Transfer message to the MSC containing the 9
authentication parameters received from the CCPD mobile, the BS computed 10
authentication data element, and the data burst type field of the ADDS User 11
Part element is set to Short Data Burst. The BS starts timer T60. If the mobile 12
supports traffic channels and the BS decides not to support the mobile’s 13
request for CCPD Mode, the call is treated as a normal mobile originated 14
packet call setup (refer to section 3.17.4..1 for the procedure). If the BS is 15
unable to support the CCPD Mode request from a CCPD Device, the call shall 16
fail. 17
d. The MSC sends the result of authentication for the CCPD mobile back to the 18
BS in the ADDS Transfer Ack message. If authentication of the CCPD mobile 19
fails, the MSC includes a cause value set to ‘authentication failure’ in the 20
message and the CCPD call fails. The BS stops timer T60. 21
3GPP2 A.S0013-0 v2.0
Section 3 177
e. The PCF recognizes that no A10 connection associated with this mobile is 1
available and selects a PDSN for this call. The PCF sends an A11-Registration 2
Request message to the selected PDSN. The PCF starts timer Tregreq. 3
f. The A11-Registration Request message is validated and the PDSN accepts the 4
connection by returning an A11-Registration Reply message with an accept 5
indication and the Lifetime field set to the configured Trp value. The PCF 6
stops timer Tregreq. 7
g. The mobile and the PDSN exchange short data bursts over common channels 8
to establish the link layer (PPP) connection and then perform MIP registration 9
procedures (if required). The first short data burst sent from the BS to the 10
mobile serves as an acknowledgement to the mobile’s request for CCPD 11
Mode. 12
h. The mobile sends it’s data in a short data burst over the common channel to 13
the BS. 14
i. The BS acknowledges receipt of the short data burst from the mobile by 15
sending a BS Ack order to the mobile. 16
j. The BS/PCF sends the packet data to the PDSN. 17
k. The BS/PCF sends an A11-Registration Request message with an SDB 18
Airlink record to the PDSN. The PCF starts timer Tregreq. 19
l. The PDSN updates the accounting data and responds to the BS/PCF with an 20
A11-Registration Reply message. The PCF stops timer Tregreq. 21
3.17.8.2.2 Call Flow: CCPD MS Inter-PCF Dormant Handoff – Mobile Served by the Same 22
PDSN 23
In order to obtain packet data services, a CCPD mobile performed registration with the 24
packet network. Both the A10 connection and the link layer (PPP) connection are 25
maintained. The source PCF continues to perform re-registrations for the A10 connection 26
with the PDSN by the exchange of A11-Registration Request messages and A11-27
Registration Reply messages before expiration of A10 connection Lifetime timer Trp. 28
While in the dormant mode, the CCPD mobile detects a change of PZID, SID or NID. On 29
detection of a new PZID, SID or NID, the mobile sends an Origination Message to the 30
target BS with a packet data service option and the SDB_DESIRED_ONLY bit set to 1. 31
If the call if for a CCPD Device, the FCH_SUPPORTED and DCCH_SUPPORTED bits 32
are also set to 0. The Origination Message includes the previous PZID, SID and NID 33
when any of these parameters change during the dormant handoff. The target PCF 34
establishes an A10 connection with the PDSN. Based on the IDs (PZID, NID and/or SID) 35
in the Origination Message, the target PCF sends the PANID of the source PCF and the 36
CANID of target PCF to the serving PDSN. The serving PDSN uses this information to 37
determine if PPP re-negotiation is required. If the PDSN has data, the PDSN returns the 38
‘Data Available Indicator’ in the Vendor/Organization Specific Extension within the 39
Registration Reply message to the BS/PCF. The source PDSN releases the A10 40
connection with the source PCF. 41
This call flow may also be used if the network decides to initiate CCPD Mode for a 42
dormant mode handoff. For this case, the Mobile sends an Origination Message with the 43
SDB_DESIRED_ONLY and DRS bits set to 0. The first Short Data Burst sent to the 44
mobile indicates that CCPD procedures shall be used to support the dormant mode 45
handoff. 46
3GPP2 A.S0013-0 v2.0
Section 3 178
Source BS/PCF
MSC time comment
Origination
Base Station Ack Order
a
b
c
d
e
f
ADDS Transfer
Adds Transfer Ack
g
h
i
k
T60
j
PDSN
A11-Registration Update
A11-Registration Request (Lifetime, MEI)
A11-Registration Reply (Lifetime, Accept)
A11-Registration Acknowledge
Target BS/PCF
A11-Registration Request(Lifetime=0)
A11-Registration Reply (Lifetime=0, accept)
l
Tregreq
Tregreq
Tregupd
MS
Dormant / PPP Connected
Dormant / PPP Connected
Short Data Burst
Layer 2 Ack
1
Figure 3.17.8.2.2-1 Inter-PCF Dormant Handoff – Mobile Continues to be Served by the Same PDSN 2
The CCPD MS has previously performed PPP connection establishment and 3
Mobile IP Registration (if required) with the PDSN and is currently 4
maintaining a dormant packet data service instance. 5
a. Upon detection of a new Packet Zone ID, a CCPD mobile sends an 6
Origination Message with the SDB_DESIRED_ONLY bit set to 1. 7
b. The target BS acknowledges receipt of the Origination Message with a BS 8
Ack Order to the mobile. 9
c. The BS sends an ADDS Transfer message to the MSC containing the 10
authentication parameters received from the mobile, the BS computed 11
3GPP2 A.S0013-0 v2.0
Section 3 179
authentication data element, and the data burst type field of the ADDS User 1
Part element set to Short Data Burst. If the BS determines that the CCPD 2
mobile supports traffic channels, the BS may alternatively execute the MS 3
dormant mode handoff procedure described in section 3.17.4.9. The target BS 4
starts timer T60. 5
d. The MSC sends the ADDS Transfer Ack message to the target BS with no 6
cause value present. The target BS stops timer T60. If authentication of the 7
CCPD mobile fails, the MSC includes a Cause value set to ‘authentication 8
failure’ in the message and the CCPD call fails. 9
e. The target PCF sends an A11-Registration Request message to the PDSN. The 10
Registration Request message includes the Mobility Event Indicator within 11
the Vendor/Organization Specific Extension. The PCF starts timer Tregreq. 12
f. The A11-Registration Request message is validated and the PDSN accepts the 13
connection by returning an A11-Registration Reply message with an accept 14
indication. If the PDSN has data to send, it includes the Data Available 15
Indicator within the Vendor/Organization Specific Extension. If the data is for 16
a CCPD Capable mobile, a network initiated call re-origination may occur. 17
The A10 connection binding information at the PDSN is updated to point to 18
the target PCF. The PCF stops timer Tregreq. 19
g. The BS sends an empty Short Data Burst to the CCPD mobile to acknowledge 20
acceptance of the CCPD Mode Request. If the PDSN sent data for the mobile, 21
the data is included in the SDB. 22
h. The CCPD mobile responds with a layer 2 Ack to acknowledge receipt of the 23
SDB. 24
The mobile’s packet data service instance resumes a dormant state. If the 25
network or mobile have any data to send, the data may be sent using short data 26
bursts over common channels using CCPD procedures. 27
i. The PDSN initiates release of the A10 connection with the source PCF by 28
sending an A11-Registration Update message. The PDSN starts timer Tregupd. 29
j. The source PCF responds with an A11-Registration Acknowledge message. 30
The PDSN stops timer Tregupd. 31
k. The source PCF sends an A11-Registration Request message with Lifetime set 32
to zero, to the PDSN. The PCF starts timer Tregreq. 33
l. The PDSN sends the A11-Registration Reply message to the source PCF. The 34
source PCF closes the A10 connection for the mobile. The PCF stops timer 35
Tregreq. 36
3.17.8.2.3 CCPD Mobile Inter-PCF Dormant Handoff – Mobile Served by a New PDSN 37
While the packet data session is in dormant mode, the mobile detects a change of PZID, 38
SID or NID. On detection of a new PZID, SID, or NID, the mobile sends an Origination 39
Message to the target BS that includes the packet data service option and the 40
SDB_DESIRED_ONLY bit set to 0. If the call is for a CCPD Device, the 41
FCH_SUPPORTED and DCCH_SUPPORTED bits are also set to 0. The target PCF 42
establishes an A10 connection with the target PDSN. The target PCF is required to 43
forward the PANID of the source PCF and the CANID of the target PCF to the serving 44
PDSN. PPP Connection Setup and Mobile IP Registration (if required) occur using Short 45
Data Bursts over the common channels. The source PDSN releases the A10 connection 46
with the source PCF on expiration of the Lifetime timer (Trp) or other events internal to 47
3GPP2 A.S0013-0 v2.0
Section 3 180
the PDSN. The target PCF periodically re-registers with the PDSN by the use of the A11-1
Registration Request message before the A10 connection Lifetime expires. 2
This call flow may also be used if the network decides to initiate CCPD Mode for the 3
dormant mode handoff. For this case, the Mobile sends an Origination Message with the 4
SDB_DESIRED_ONLY and DRS bits set to 0. The first Short Data Burst sent to the 5
mobile indicates that CCPD procedures shall be used to support the dormant mode 6
handoff. 7
ADDS Transfer
MS Source
BS/PCF MSC
time comment
Origination
Base Station Ack Order
a
b
c
d
e
f
ADDS Transfer Ack
g
h
i
k
j
T60
Source PDSN
A11-Registration Request (Lifetime, MEI)
A11-Registration Reply (Lifetime, Accept, Data Available Indicator)
Target BS/PCF
Tregreq
A11-Registration Update
A11-Registration Acknowledge
A11-Registration Request(Lifetime=0, Accounting data)
A11-Registration Reply (Lifetime=0, accept) Tregreq
Tregupd
Target PDSN
Establish PPP Connection (Short Data Bursts)
Dormant / PPP Connected
8
Figure 3.17.8.2.3-1 Inter-PCF Dormant Handoff – Mobile Served by a New Target PDSN 9
The CCPD MS previously performed PPP connection establishment and 10
Mobile IP Registration (if required) with the PDSN and is currently 11
maintaining a dormant packet data service instance. 12
a. Upon detection of a new Packet Zone ID, the CCPD mobile sends an 13
Origination Message with the SDB_DESIRED_ONLY bit set to 1 to the 14
target BS. 15
3GPP2 A.S0013-0 v2.0
Section 3 181
b. The target BS acknowledges the receipt of the Origination Message with a BS 1
Ack Order to the mobile. 2
c. The BS sends an ADDS Transfer message to the MSC containing the 3
authentication parameters received from the mobile, the BS computed 4
authentication data element, and the data burst type field of the ADDS User 5
Part element set to Short Data Burst. If the BS determines that the CCPD 6
mobile supports traffic channels, the BS may alternatively execute the MS 7
dormant mode handoff procedure described in section 3.17.4.10. The target 8
BS starts timer T60. 9
d. The MSC sends the ADDS Transfer Ack message to the target BS with no 10
cause value present. The target BS stops timer T60. If authentication of the 11
terminal fails, the MSC includes a Cause value set to ‘authentication failure’ 12
in the message. 13
e. The target PCF initiates establishment of the A10 connection by sending an 14
A11-Registration Request message to the target PDSN. The Registration 15
Request message includes the Mobility Event Indicator within the 16
Vendor/Organization Specific Extension. The PCF starts timer Tregreq. 17
f. The A11-Registration Request message is validated and the target PDSN 18
accepts the connection by returning an A11-Registration Reply message with 19
an accept indication and Data Available Indicator within the 20
Vendor/Organization Specific Extension. If the data is for a CCPD Capable 21
mobile, a network initiated call re-origination may occur. The PCF stops timer 22
Tregreq. 23
g. The mobile and the target PDSN exchange short data bursts over common 24
channels to establish the link layer (PPP) connection and then perform MIP 25
registration procedures (if required) over the link layer (PPP) connection. The 26
first short data burst sent from the BS to the mobile serves as an 27
acknowledgement to the mobile’s request for CCPD Mode. 28
The mobile’s packet data service instance resumes a dormant state. If the 29
network or mobile have any data to send, the data is sent using short data 30
bursts over common channels using the CCPD procedures. 31
h. On expiration of the Lifetime timer (Trp) or other events internal to the 32
PDSN, the source PDSN initiates release of the A10 connection with the 33
source PCF by sending an A11-Registration Update message. The PDSN 34
starts timer Tregupd. 35
i. The source PCF responds with an A11-Registration Acknowledge message. 36
The source PDSN stops timer Tregupd. 37
j. The source PCF sends an A11-Registration Request message with Lifetime set 38
to zero, and accounting related information to the source PDSN. The source 39
PCF starts timer Tregreq. 40
k. The source PDSN stores the accounting related information for further 41
processing before returning A11-Registration Reply message. The source PCF 42
closes the A10 connection for the mobile. The source PCF stops timer Tregreq. 43
3.17.9 Packet Data Security Considerations 44
This section discusses packet data security considerations. Refer to section 2.17.4 for 45
more information. 46
3GPP2 A.S0013-0 v2.0
Section 3 182
3.17.9.1 PCF-PDSN Security Association 1
Security contexts are configurable between every PCF and PDSN pair on the packet data 2
network. Each security context indicates an authentication algorithm and mode, a secret 3
(a shared key, or appropriate public/private key pair), and a style of replay protection in 4
use.1 5
An index identifying a security context between a pair of PCF and PDSN is called 6
Security Parameter Index (SPI). SPI values ‘0’ through ‘255’ are reserved, hence not 7
used in any PCF-PDSN security association. 8
The “Mobile-Home Authentication Extension” and “Registration Update Authentication 9
Extension” provide a means for authenticating the registration messages on the A11 10
interface. The Authenticator value in the “Mobile-Home Authentication Extension” and 11
“Registration Update Authentication Extension” protects the following fields: 12
• the UDP payload of registration messages 13
• all prior extensions in their entirety, and 14
• the Type, Length and SPI fields of the extension 15
The authentication algorithm uses the default keyed-MD5 ([33]) in the “prefix-suffix” 16
mode to compute a 128-bit “message digest” of the registration message. The 17
Authenticator value is a 128-bit value computed as the MD5 checksum over the 18
following stream of bytes: 19
• the shared secret defined by the mobility security association between the PCF and 20
the PDSN and by the SPI value specified in the authentication extension, followed 21
by 22
• the protected fields from the registration message, in the order specified above, 23
followed by 24
• the shared secret again 25
The Authenticator field itself and the UDP header are NOT included in the computation 26
of the Authenticator value. The receiver uses the SPI value within an authentication 27
extension to determine the security context, and compute the Authenticator value. A 28
mismatch in the Authenticator values results in rejection of the registration message with 29
error code ‘131’ (sending node failed authentication). Refer to [34] for implementation 30
details. 31
3.18 Voice and Packet Concurrent Service 32
This section describes call flows associated with Concurrent Services. 33
3.18.1 Concurrent Service Examples - Mobile Origination 34
The following subsections describe the call flows for establishing an additional service 35
option connection through an MS originated action while the MS is already active with 36
another service. Mobile originated concurrent service setup involves exchange of the 37
following messages: 38
• Additional Service Request 39
1 Refer to [56] for details.
3GPP2 A.S0013-0 v2.0
Section 3 183
• Assignment Request 1
• Assignment Failure 2
• Assignment Complete 3
• A9-Setup-A8 4
• A9-Connect-A8. 5
3.18.1.1 Mobile Initiated Packet Data Service Connection, Voice Service is Already Active 6
This section describes the call flow associated with an MS initiated packet data service 7
connection in the system for the case that the MS is engaged in an active voice call. 8
Assignment Request
BSC MS
Enhanced Origination Message
BS ACK Order
MSC
Additional Service Request
A9-Setup-A8
PCF PDSN
A9-Connect-A8
Assignment Complete
a
b
c
d
e
f
g
h
i
j
A10/A11
Connection
T303
T10
TA8
Concurrent Service Active
Establishing PPP connection
Call Assignment Message
SCM/UHDM/GHDM
k
l
Service Connect Completion
Service Negotiation
Voice Active, Packet Null
Time
9
Figure 3.18.1.1-1 Mobile Initiated Packet Data Service Connection, Voice Service is Already Active 10
a. The MS transmits an Enhanced Origination Message, with layer 2 11
acknowledgment required, over the traffic channel of the air interface to the 12
BS to request service. 13
b. The BS acknowledges the receipt of the Enhanced Origination Message with a 14
Base Station Acknowledgment Order to the MS. 15
c. The BS constructs the Additional Service Request message, sends the 16
message to the MSC, and starts timer T303. 17
3GPP2 A.S0013-0 v2.0
Section 3 184
d. The MSC sends an Assignment Request message to the BS to request 1
assignment of radio resources and starts timer T10. For packet data service, an 2
additional terrestrial circuit between the MSC and the BSC is not required. 3
The BS stops timer T303 upon receipt of the Assignment Request message. 4
e. The BS may send a Call Assignment Message over the traffic channel of the 5
radio interface to initiate the establishment of a Call Control (CC) state 6
machine. 7
f. The BS sends one of the Service Connect Message, General Handoff 8
Direction Message or Universal Handoff Direction Message to the MS to 9
invoke the additional service option connection. 10
g. The MS responds with a Service Connect Completion Message upon 11
completion of the service negotiation procedure. 12
h. The BSC transmits an A9-Setup-A8 message to the PCF to establish an A8 13
connection and starts timer TA8-setup. 14
i. Procedure for establishing A10/A11 connection is performed. 15
j. Upon establishment of the A10/A11 connection, the PCF establishes an A8 16
connection and transmits an A9-Connect-A8 message. 17
k. Upon receiving an A9-Connect-A8 message, the BSC stops the timer TA8-18
setup and transmits Assignment Complete message. The MSC stops timer T10. 19
This step may occur any time after radio link establishment. 20
l. PPP connection establishment procedure and Mobile IP Registration (if 21
required) on the PPP connection are performed between the MS and PDSN. 22
3.18.1.2 Mobile Initiated Voice Service Connection, Packet Data Service is Already Active 23
This section describes the call flow associated with an MS initiated voice service 24
connection in the system for the case that the MS is engaged in an active packet data call. 25
3GPP2 A.S0013-0 v2.0
Section 3 185
MS BS MSCtime comment
Enhanced Origination Message
Base Station Ack Order
a
b
c
d
e
Additional Service Request
Assignment Request
Call Assignment Message
g
SCM/UHDM/GHDM
Assignment Complete
Ringback Tone i
T10
Transparent tosignaling
Service Connect Completion
T303
Concurrent Service active
h
ServiceNegotiation
1
Figure 3.18.1.2-1 Mobile Initiated Voice Service Connection, One Service is Already Active. 2
a. The MS transmits an Enhanced Origination Message, with layer 2 3
acknowledgment required, over the traffic channel of the air interface to the 4
BS to request service. 5
b. The BS acknowledges the receipt of the Enhanced Origination Message with a 6
Base Station Acknowledgment Order to the MS. 7
c. The BS constructs the Additional Service Request message, sends the 8
message to the MSC, and starts timer T303. For voice calls, the BS may 9
request the MSC to allocate a preferred terrestrial circuit. 10
d. The MSC sends an Assignment Request message to the BS to request 11
assignment of radio resources. This message includes information on the 12
terrestrial circuit, if one is to be used between the MSC and the BS. The MSC 13
then starts timer T10. If the BS requested a preferred terrestrial circuit in the 14
Additional Service Request message and that terrestrial circuit is available 15
(refer to [14]), the MSC shall use the same terrestrial circuit in the Assignment 16
Request message. Otherwise, the MSC may assign a different terrestrial 17
circuit. Upon receipt of the Assignment Request message from the MSC, the 18
BS stops timer T303. 19
e. The BS may send a Call Assignment Message over the traffic channel of the 20
radio interface to initiate the establishment of a CC state machine. 21
f. The BS sends one of the Service Connect Message, General Handoff 22
Direction Message or Universal Handoff Direction Message to the MS to 23
invoke the additional service option connection. 24
3GPP2 A.S0013-0 v2.0
Section 3 186
g. The MS responds with a Service Connect Completion Message upon the 1
completion of the service negotiation procedure. 2
h. After the radio traffic channel and circuit have both been established and fully 3
interconnected, the BS sends the Assignment Complete message to the MSC 4
and considers the additional service to be in conversation state. The MSC 5
stops timer T10 upon receipt of the Assignment Complete message. 6
i. As call progress tone is applied in-band in this case, ringback tone is available 7
on the audio circuit path towards the MS. This step is only applicable to the 8
additional voice service. 9
3.18.2 Concurrent Service Examples - Mobile Termination 10
The following subsections describe the call flows for establishing an additional service 11
option connection through a mobile terminated action while the mobile is already active 12
with another service. Mobile terminated concurrent service setup involves exchange of 13
the following MSC-BS messages: 14
• Additional Service Notification 15
• Additional Service Request 16
• Assignment Request 17
• Assignment Failure 18
• Assignment Complete 19
• Connect. 20
3.18.2.1 Mobile Termination for Voice Service, Packet Data is Already Active 21
This section describes the call flow associated with an MS call termination in the system 22
for the case that the MS is already active with an active packet data call. 23
3GPP2 A.S0013-0 v2.0
Section 3 187
MS BS MSC
time comment
c
d
e
f
g
h
i
j
Additional Service Request
Assignment Request
Call Assignment Message
k
Assignment Complete
T10
Connect
b
a Additional Service Notification
Extended Alert with Info
MS Ack Order
Connect Order
BS Ack Order
T301
T314
T303
l
SCM/UHDM/GHDM
Service Connect Completion
Service Negotiation
Concurrent Service active
1
Figure 3.18.2.1-1 Mobile Termination for Voice Service, Packet Data is Already Active 2
a. The MSC sends an Additional Service Notification Message to the BS to 3
initiate additional service option connection. The MSC then starts timer T314. 4
b. The BS constructs the Additional Service Request message, sends the 5
message to the MSC, and starts timer T303. For voice calls, the BS may 6
request the MSC to allocate a preferred terrestrial circuit. 7
The MSC stops timer T314 upon receipt of the Additional Service Request 8
message from the BS. 9
c. The MSC sends an Assignment Request message to the BS to request 10
assignment of radio resources. This message includes information on the 11
terrestrial circuit, if one is to be used between the MSC and the BS. The MSC 12
then starts timer T10. 13
If the BS requested a preferred terrestrial circuit in the Additional Service 14
Request message and that terrestrial circuit is available (refer to [14]), the 15
MSC shall use the same terrestrial circuit in the Assignment Request message. 16
Otherwise, the MSC may assign a different terrestrial circuit. 17
Upon receipt of the Assignment Request message from the MSC, the BS stops 18
timer T303. 19
d. The BS may send a Call Assignment Message over the traffic channel of the 20
radio interface to initiate establishment of a CC state machine. 21
3GPP2 A.S0013-0 v2.0
Section 3 188
e. The BS sends one of the Service Connect Message, General Handoff 1
Direction Message or Universal Handoff Direction Message to the MS to 2
invoke the additional service option connection. 3
f. The MS responds with a Service Connect Completion Message upon the 4
completion of the service negotiation procedure. 5
g. After the radio traffic channel and circuit have both been established and fully 6
interconnected, the BS sends the Assignment Complete message to the MSC. 7
The MSC stops timer T10 upon receipt of the Assignment Complete message. 8
The MSC starts timer T301. 9
h. The BS sends the Alert with Information Message to the MS to cause ringing 10
at the MS. 11
i. The MS acknowledges the reception of the Alert with Information Message by 12
transmitting the Mobile Station Acknowledgment Order. 13
j. When the call is answered at the MS, a Connect Order, with acknowledgment 14
required, is transmitted to the BS. 15
k. The BS acknowledges the Connect Order with the Base Station 16
Acknowledgment Order over the forward traffic channel. 17
l. The BS sends a Connect message to the MSC to indicate that the call has been 18
answered at the MS. At this point, the call is considered stable and in the 19
conversation state. 20
The MSC stops timer T301 upon receipt of the Connect message from the BS. 21
3.18.3 Concurrent Service Examples - BS Initiated Call Setup 22
The following subsections describe the call flows for establishing a packet data call to a 23
mobile that already has an active voice call, due to a request from the PDSN (through the 24
PCF) to send data packets to the mobile. BS initiated call setup for concurrent service 25
involves exchange of the following messages: 26
• Additional Service Request 27
• Assignment Request 28
• Assignment Failure 29
• Assignment Complete 30
• A9-BS Service Request 31
• A9-BS Service Response 32
• A9-Setup-A8 33
• A9-Connect-A8. 34
3.18.3.1 Network Initiated Call Re-Activation from Dormant State, MS is Already Active 35
with Voice Service 36
The following call flow diagram provides an illustration for a successful packet 37
reactivation procedure, when the MS is already active with voice service. 38
3GPP2 A.S0013-0 v2.0
Section 3 189
CommentMS Time
a
b
c
d
e
f
g
h
iA9-Setup-A8
A9-Connect-A8
Assignment Complete
SCM/UHDM/GHDM
j
TA8-Setup
T10
Voice Active, Packet Dormant, PPP connection is maintained
Packet Data
A9-BS Service Request
Additional Service Request
Assignment Request
A9-BS Service ResponseCall Assignment Message
BS MSC / VLR PDSNPCF
Tbsreq9T303
K
Service Connect Completion
ServiceNegotiation
Concurrent Service Active
1
Figure 3.18.3.1 PCF Initiated Call Re-Activation from Dormant State, Voice is Already Active 2
a. The PDSN sends data packets to the BS on an existing PPP connection and 3
A10/A11 connection associated with a specific mobile for packet service. 4
b. The PCF sends an A9-BS Service Request message to the BS in order to 5
request packet service, and starts timer Tbsreq9. 6
c. The BS sends an Additional Service Request message to the MSC and starts 7
timer T303, in order to reconnect the call. 8
d. The MSC sends an Assignment Request message to the BS to request 9
assignment of radio resources and the A8 (User Traffic) connection between 10
the BS and the PCF. The MSC then starts timer T10. Upon receipt of the 11
Assignment Request message from the MSC, the BS stops timer T303. 12
e. The BS responds with A9-BS Service Response. The PCF stops timer Tbsreq9 13
upon receipt of the A9-BS Service Response message. 14
f. The BS may send a Call Assignment Message over the traffic channel of the 15
radio interface to initiate the establishment of a CC state machine. 16
3GPP2 A.S0013-0 v2.0
Section 3 190
g. The BS sends one of the Service Connect Message, General Handoff 1
Direction Message or Universal Handoff Direction Message to the MS to 2
invoke the additional service option connection. 3
h. The MS responds with a Service Connect Completion Message upon the 4
completion of the service negotiation procedure. 5
i. The BS sends A9-Setup-A8 message to the PCF to establish A8 (User Traffic) 6
connection between the BS and the PCF, over the A9 (Signaling) connection. 7
The BS then starts timer TA8-Setup. 8
j. The PCF responds with A9-Connect-A8 message to complete the setup of A8 9
(User Traffic) connection for this packet service request. Upon receipt of the 10
A9-Connect-A8 message from the PCF, the BS stops timer TA8-Setup. 11
k. After the radio link and the A10 connection have been established, the BS 12
sends an Assignment Complete message to the MSC. The MSC stops timer 13
T10. 14
3.18.3.2 Network Initiated Call Re-Activation from Dormant State, MS is Active with a 15
Concurrent Voice Service and Has Performed an Inter-BS/Intra-PCF Voice Call 16
Handoff 17
The following call flow diagram provides an illustration of a successful packet 18
reactivation procedure for the case where an MS is active with a concurrent voice service 19
and has performed an inter-BS/intra-PCF voice call handoff. 20
3GPP2 A.S0013-0 v2.0
Section 3 191
Comment MS Time
a
b
c
d
e
f
g
h
i
A9-Setup-A8
A9-Connect-A8
Assignment Complete
SCM/UHDM/GHDM j
TA8-Setup
T10
Voice Active, Packet Dormant, PPP connection is maintained
Packet Data Traffic
A9-BS Service Request
BS Service Request
BS Service Response
A9-BS Service Response
Call Assignment Message
Source BS MSC / VLR PDSN PCF
Tbsreq9 T311
k
Service Connect Completion
Service Negotiation
Concurrent Service Active
Target BS
Additional Service Notification
Additional Service Request
Assignment Request
T314
l
T303
m
n
o
1
Figure 3.18.3.2-1 PCF Initiated Call Re-Activation from Dormant State, Voice is Already Active 2
a. The PDSN sends data packets to the PCF on an existing PPP connection and 3
A10/A11 connection associated with a specific mobile for packet service. 4
b. The PCF sends an A9-BS Service Request message to the source BS in order 5
to request packet service, and starts timer Tbsreq9. 6
c. The source BS sends a BS Service Request message to the MSC and starts 7
timer T311. 8
d. The MSC recognizes that the MS has performed a voice call hand off to the 9
target BS and sends a BS Service Response message to the source BS. 10
e. The source BS responds with A9-BS Service Response message to the PCF. 11
The PCF stops timer Tbsreq9 upon receipt of the A9-BS Service Response 12
message. 13
f. The MSC sends an Additional Service Notification message to the target BS 14
to initiate an additional service option connection and starts timer T314. 15
3GPP2 A.S0013-0 v2.0
Section 3 192
g. The target BS sends an Additional Service Request message to the MSC and 1
starts timer T303. The MSC stops timer T314 upon receipt of the Additional 2
Service Request message from the target BS. 3
h. The MSC sends an Assignment Request message to the target BS to request 4
assignment of radio resources. The MSC starts timer T10. 5
i. Upon receipt of the Assignment Request message from the MSC, the target 6
BS stops timer T303. 7
j. The target BS may send a Call Assignment Message over the traffic channel 8
of the radio interface to initiate the establishment of a CC state machine. 9
k. The target BS sends either the Service Connect Message, the General Handoff 10
Direction Message or the Universal Handoff Direction Message to the MS to 11
invoke the additional service option connection. 12
l. The MS responds with a Service Connect Completion Message upon the 13
completion of the service negotiation procedure. 14
m. The target BS sends an A9-Setup-A8 message over the A9 (Signaling) 15
connection to the PCF to establish an A8 (User Traffic) connection between 16
target BS and the PCF. The target BS then starts timer TA8-Setup. 17
n. The PCF responds with an A9-Connect-A8 message to complete the setup of 18
the A8 (User Traffic) connection for the packet service request. Upon receipt 19
of the A9-Connect-A8 message from the PCF, the target BS stops timer TA8-20
Setup. 21
o. After the radio link and the A8 connection have been established, the target 22
BS sends an Assignment Complete message to the MSC. The MSC stops 23
timer T10. 24
3.18.4 Concurrent Services: Call Clearing Examples 25
3.18.4.1 Call Clear via Service Release – MS Initiated 26
This section describes the call flow associated with a single service option connection 27
release initiated by MS from the two active service option connections in the system. 28
3GPP2 A.S0013-0 v2.0
Section 3 193
MS MSCtime comment
SreqM/RRRM/RRRMMa
b
c
d
Service Release
Service Release Complete
SCM/GHDM/UHDM
T308
BS
Concurrent Service active
Service Connect Completion
Service Negotiation
e
1
Figure 3.18.4.1-1 Releasing a Service That Is Not the Only One Connected (MS Initiated) 2
a. The MS may send one of the Service Request Message, Resource Release 3
Request Message or Resource Release Request Mini Message (RRRMM) for 4
releasing a service that is not the only service connected to the MS. 5
b. The BS then sends the Service Release message to the MSC to clear a call 6
control transaction associated with the service. The BS starts timer T308. 7
c. Upon receiving the Service Release Message from the BS, the MSC releases 8
the service option connection identifier, the terrestrial circuit (if allocated for 9
the associated service), and sends a Service Release Complete Message to the 10
BS. Upon receipt of the Service Release Complete Message, the BS stops 11
Timer T308. 12
d. Upon receiving the Service Release Complete message, the BS shall go to the 13
“null” state for the service option connection identifier, release the radio 14
resource for the associated service option connection identifier and then may 15
transmit one of the Service Connect Message, General Handoff Direction 16
Message or Universal Handoff Direction Message to the MS. 17
e. The MS responds with a Service Connect Completion Message upon the 18
completion of the service negotiation procedure. 19
3.18.4.2 Call Clear via Service Release - MSC Initiated 20
This section describes the call flow associated with a single service option connection 21
release initiated by MSC from the two active service option connections in the system. 22
3GPP2 A.S0013-0 v2.0
Section 3 194
MS MSCtime comment
a
b
c
d
Service Release
Service Release Complete
SCM/GHDM/UHDM
T308
BS
Concurrent Service active
Service Connect Completion
Service Negotiation
1
Figure 3.18.4.2-1 Releasing a Service That Is Not the Only One Connected (MSC Initiated) 2
a. The MSC sends a Service Release message to the BS to instruct the BS to 3
release a call control transaction associated with the service and starts timer 4
T308. 5
b. The BS sends one of the Service Connect Message, General Handoff 6
Direction Message or Universal Handoff Direction Message to the MS to 7
release the associated service option connection. 8
c. The MS responds with a Service Connect Completion Message upon the 9
completion of the service negotiation procedure. 10
d. The BS releases the service option connection identifier, the terrestrial circuit, 11
if allocated for the associated service and sends a Service Release Complete 12
Message to the MSC. Upon receipt of the Service Release Complete, the MSC 13
stops timer T308. 14
3.18.5 Concurrent Service - Handoff 15
This section describes the handoff call flows for concurrent service. 16
3.18.5.1 Concurrent Service (Active Voice and Packet Data Services) - Hard Handoff 17
This section describes call flows for the successful hard handoff of a mobile that is 18
engaged in active voice and packet data calls simultaneously. 19
3.18.5.1.1 Successful Inter-BS Hard Handoff Call Flows (Within the Same PCF) 20
The call flows in this section are identical to the call flows described in section 3.17.4.14. 21
3GPP2 A.S0013-0 v2.0
Section 3 195
3.18.5.1.2 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by the Same 1
PDSN) 2
The call flows in this section are identical to the call flows described in section 3.17.4.15 3
and section 3.17.5.10. 4
3.18.5.1.3 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by New PDSN) 5
The call flows in this section are identical to the call flows described in section 3.17.5.11. 6
3.18.5.2 Concurrent Service (Active Voice and Dormant Packet Data Services) - Handoff 7
This section describes call flows for the successful handoff of a mobile that is engaged in 8
an active voice call and has a dormant packet data session. 9
3.18.5.2.1 Successful Inter-PCF Handoff Call Flows (Mobile Served by the Same PDSN) 10
This section describes the call flows for the successful handoff between PCFs being 11
served by the same PDSN of a mobile that is engaged in an active voice call and has a 12
dormant packet data session. It is assumed that the PCFs are in different packet zones, 13
and that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus 14
no A3 connections need to be removed. 15
3GPP2 A.S0013-0 v2.0
Section 3 196
X
Time Comment
a
b
c
d
e
f
g
h
i
PDSN Dormant HO
j
k
l
MS Source BS Target BS MSC Source PCF
Target PCF PDSN
Handoff Request
Handoff Required
Handoff Request Ack T11
Handoff Command
T7
Handoff Direction
Null Forward Traffic frames
MS Ack Order Twaitho
Handoff Commenced
Reverse Traffic frames or traffic preamble
Handoff Completion Message
BS Ack Order Handoff Complete
T9
Clear Command
Clear Complete
T306
T315
Enhanced Origination Message
BS Ack Order
Additional Service Request
Assignment Request T303
A9-Setup-A8
TA8-Setup
Assignment Failure
A9-Release-A8
T10
Service Release
Service Release
T20
T308
m
n
o
p
q
r
s
t
u
v
w
x
y
In Traffic System Parameter
z Active Voice Session, Dormant Packet Data Session
1
Figure 3.18.5.2.1-1 Successful Inter-PCF Handoff (Mobile Served by the Same PDSN) 2
3GPP2 A.S0013-0 v2.0
Section 3 197
a. The MS currently has a voice call active and a packet data service that is 1
dormant. Based on an MS report that it crossed a network specified threshold 2
for signal strength or for other reasons, the source BS recommends a hard 3
handoff to one or more cells in the domain of the target BS. The source BS 4
sends a Handoff Required message with the list of cells to the MSC and starts 5
timer T7. 6
b. The MSC sends a Handoff Request message to the target BS with the IS-2000 7
Channel Identity element present since the hard handoff bit was set and/or the 8
Handoff Type element in the Handoff Required message indicated hard 9
handoff. The MSC starts timer T11. 10
c. Upon receipt of the Handoff Request message from the MSC, the target BS 11
allocates appropriate radio resources as specified in the message and connects 12
the call. As the HO Request message can have multiple cells specified, the 13
target BS can also choose to setup multiple cells for the handoff request. The 14
target BS sends null forward traffic channel frames to the MS. 15
d. The target BS sends a Handoff Request Acknowledge message to the MSC 16
and starts timer T9 to wait for arrival of the MS on its radio channel. The MSC 17
stops timer T11 upon the receipt of this message. The first cell in the cell 18
identifier list element of the message is treated as the new designated cell by 19
the MSC. The change of designated cell occurs upon receipt of the HO 20
Complete message. 21
If the service option received in the Handoff Request message is not available 22
at the target BS and the target BS selected a different service option for the 23
handoff then the target BS shall include the service option it selected in the 24
Service Configuration Record IE. 25
e. The MSC prepares to switch from the source BS to the target BS and sends a 26
Handoff Command to the source BS. The source BS stops timer T7. The MSC 27
shall include the service option it received from the Handoff Request 28
Acknowledgement message in the Handoff Command message. 29
f. The source BS sends the handoff direction message2 to the MS across the air 30
interface. If the MS is allowed to return to the source BS, then timer Twaitho is 31
also started by the source BS. 32
g. The MS may acknowledge the handoff direction message by sending a MS 33
Ack Order to the source BS. 34
If the handoff direction message is sent using quick repeats, the source BS 35
might not request an acknowledgment from the MS. 36
h. The source BS sends a Handoff Commenced message to the MSC to notify it 37
that the MS has been ordered to move to the target BS channel. The source BS 38
starts timer T306 to await the Clear Command message from the MSC. If timer 39
Twaitho has been started, the source BS shall wait for that timer to expire 40
before sending the Handoff Commenced message. 41
i. The MS sends reverse traffic channel frames or the traffic channel preamble to 42
the target BS. 43
2 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.S0013-0 v2.0
Section 3 198
j. Upon acquisition of the traffic channel, the MS sends a Handoff Completion 1
Message to the target BS. 2
k. The target BS sends the BS Ack Order to the MS over the air interface. 3
l. The target BS sends a Handoff Complete message to the MSC to notify it that 4
the MS has successfully completed the hard handoff. The target BS stops 5
timer T9. 6
m. The MSC sends a Clear Command to the source BS and starts timer T315. The 7
source BS stops timer T306. 8
n. The source BS sends a Clear Complete message to the MSC to notify it that 9
clearing has been accomplished. The MSC stops timer T315. 10
o. The target BS, upon detecting that the mobile has arrived from a different 11
packet zone, sends an In Traffic System Parameter Message to the mobile 12
indicating the current packet zone (CANID). The MS may acknowledge the 13
In-Traffic System Parameter Message by sending an MS Ack Order to the 14
target BS. 15
p. The MS detects a change in packet zone and sends an Enhanced Origination 16
Message to the target BS with DRS bit set to ‘0’. 17
q. The target BS acknowledges receipt of the Enhanced Origination Message by 18
sending a BS Ack Order to the MS. 19
r. The target BS sends an Additional Service Request message to the MSC and 20
starts timer T303. 21
s. The MSC sends an Assignment Request to the target BS and starts timer T10. 22
t. Upon receipt or the Assignment Request, the target BS stops timer T303. The 23
target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to 24
‘0’, to the PCF and starts timer TA8-Setup. The handoff indicator of the A9 25
Indicators IE shall be set to ‘0’. 26
u. The target PCF establishes the A10/A11 link and the PDSN disconnects the 27
old A10/A11 link (refer to procedure in 3.11.5.5.10). (If the PDSN has data 28
for the mobile, it responds to the PCF with a Registration Reply message with 29
the Data Available Indicator in the Vendor/Organization Specific Extension.) 30
v. The PCF responds to the BS with an A9-Release A8 Complete message. The 31
BS stops timer TA8-Setup. 32
If the PDSN responds to the PCF with a Data Available Indicator, the PCF 33
responds to the BS with an A9-Connect-A8 message with Cause element set 34
to Data Ready to Send. In this case, the target BS may send a Call Assignment 35
Message to the MS to initiate activation of the packet data service. The target 36
BS sends a handoff direction message3 to the MS to invoke the additional 37
packet data service option. After Service Negotiation, the MS responds with a 38
Service Connect Completion Message. In this case, the remaining steps in this 39
scenario are ignored. 40
3 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.S0013-0 v2.0
Section 3 199
w. The BS sends the Assignment Failure message to the MSC with Cause value 1
indicating Packet Call Going Dormant and starts timer T20. The MSC stops 2
timer T10. 3
x. The MSC sends a Service Release message to the target BS with Cause Value 4
set to Packet Call Going Dormant and starts timer T308. 5
y. The target BS sends a Service Release Complete message to the MSC. 6
z. Upon receipt of the Service Release Complete message, the MSC stops timer 7
T308. The voice call is now active, and the packet data call is dormant. 8
3.18.5.2.2 Successful Inter-PCF Handoff Call Flow (Mobile Served by New PDSN) 9
This section describes the call flows for the successful handoff between PCFs being 10
served by different PDSNs of a mobile that is engaged in an active voice call and has a 11
dormant packet data session. It is assumed that the PCFs are in different packet zones, 12
and that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus 13
no A3 connections need to be removed. 14
3GPP2 A.S0013-0 v2.0
Section 3 200
X
Time Comment
a
b
c
d
e
f
g
h
i
A10/A11
Connection
Procedures
j
k
l
MS Source BS Target BS MSC Source PCF
Target PCF PDSN
Handoff Request
Handoff Required
Handoff Request Ack T11
Handoff Command
T7
Handoff Direction Message
Null Forward Traffic frames
MS Ack Order Twaitho
Handoff Commenced
Reverse Traffic frames or traffic preamble
Handoff Completion Message
BS Ack Order Handoff Complete
T9
Clear Command
Clear Complete
T306
T315
Enhanced Origination Message
BS Ack Order Additional Service Request
Assignment Request T303
A9-Setup-A8
TA8-Setup
A9-Connect-A8
T10
Assignment Complete
m
n
o
p
q
r
s
t
u
v
w
x
Service Negotiation
Establish PPP connection
In Traffic System Parameter Message
y
1
Figure 3.18.5.2.2-1 Successful Inter-PCF Handoff (Mobile Served by New PDSN) 2
a. The MS currently has a voice call active and a packet data service that is 3
dormant. Based on an MS report that it crossed a network specified threshold 4
for signal strength or for other reasons, the source BS recommends a hard 5
3GPP2 A.S0013-0 v2.0
Section 3 201
handoff to one or more cells in the domain of the target BS. The source BS 1
sends a Handoff Required message with the list of cells to the MSC and starts 2
timer T7. 3
b. The MSC sends a Handoff Request message to the target BS with the IS-2000 4
Channel Identity element present since the hard handoff bit was set and/or the 5
Handoff Type element in the Handoff Required message indicated hard 6
handoff. The MSC starts timer T11. 7
c. Upon receipt of the Handoff Request message from the MSC, the target BS 8
allocates appropriate radio resources as specified in the message and connects 9
the call. As the HO Request message can have multiple cells specified, the 10
target BS can also choose to setup multiple cells for the handoff request. The 11
target BS sends null forward traffic channel frames to the MS. 12
d. The target BS sends a Handoff Request Acknowledge message to the MSC 13
and starts timer T9 to wait for arrival of the MS on its radio channel. The MSC 14
stops timer T11 upon the receipt of this message. The first cell in the cell 15
identifier list element of the message will be treated as the new designated cell 16
by the MSC. The change of designated cell occurs upon receipt of the HO 17
Complete message. The target BS starts timer T9 to wait for arrival of the MS 18
on its radio channel. 19
If the service option received in the Handoff Request message is not available 20
at the target BS and the target BS selected a different service option for the 21
handoff then the target BS shall include the service option it selected in the 22
Service Configuration Record IE. 23
e. The MSC prepares to switch from the source BS to the target BS and sends a 24
Handoff Command to the source BS. The source BS stops timer T7. The MSC 25
shall include the service option it received from the Handoff Request 26
Acknowledgement message in the Handoff Command message. 27
f. The source BS sends the handoff direction message4 to the MS across the air 28
interface. If the MS is allowed to return to the source BS, then timer Twaitho is 29
also started by the source BS. 30
g. The MS may acknowledge the handoff direction message by sending a MS 31
Ack Order to the source BS. 32
If the handoff direction message is sent using quick repeats, the source BS 33
might not request an acknowledgment from the MS. 34
h. The source BS sends a Handoff Commenced message to the MSC to notify it 35
that the MS has been ordered to move to the target BS channel. The source BS 36
starts timer T306 to await the Clear Command message from the MSC. If timer 37
Twaitho has been started, the source BS shall wait for that timer to expire 38
before sending the Handoff Commenced message. 39
i. The MS sends reverse traffic channel frames or the traffic channel preamble to 40
the target BS. 41
j. Upon acquisition of the traffic channel, the MS sends a Handoff Completion 42
Message to the target BS. 43
4 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.S0013-0 v2.0
Section 3 202
k. The target BS sends the BS Ack Order to the MS over the air interface. 1
l. The target BS sends a Handoff Complete message to the MSC to notify it that 2
the MS has successfully completed the hard handoff. The target BS stops 3
timer T9. 4
m. The MSC sends a Clear Command to the source BS and starts timer T315. The 5
source BS stops timer T306. 6
n. The source BS sends a Clear Complete message to the MSC to notify it that 7
clearing has been accomplished. The MSC stops timer T315. 8
o. The target BS, upon detecting that the mobile has arrived from a different 9
packet zone, sends an In Traffic System Parameter Message to the mobile 10
indicating the current packet zone (CANID). The MS may acknowledge the 11
In-Traffic System Parameter Message by sending an MS Ack Order to the 12
target BS. 13
p. The MS detects a change in packet zone and sends an Enhanced Origination 14
Message to the target BS with DRS bit set to ‘0’. 15
q. The target BS acknowledges receipt of the Enhanced Origination Message by 16
sending a BS Ack Order to the MS. 17
r. The target BS sends an Additional Service Request message to the MSC and 18
starts timer T303. 19
s. The MSC sends an Assignment Request to the target BS and starts timer T10. 20
t. Upon receipt or the Assignment Request, the target BS stops timer T303. The 21
target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to 22
‘0’, to the PCF and starts timer TA8-Setup. The handoff indicator of the A9 23
Indicators IE shall be set to ‘0’. 24
u. The target PCF establishes the A10/A11 link with the new PDSN (refer to 25
procedure in 3.11.5.5.11. In this scenario, the PDSN responds to the PCF with 26
a Registration Reply message with the Data Available Indicator in the 27
Vendor/Organization Specific Extension.) 28
v. The target PCF sends an A9-Connect-A8 message with Traffic Channel 29
Required indicator set to the target BS. The target BS stops timer TA8-Setup. 30
w. The target BS and the MS engage in over the air service negotiation to 31
connect the packet data service option. 32
x. Upon establishment of the A8/A9 and A10/A11 connections and connection 33
of the packet data service option, the target BS sends an Assignment 34
Complete message to the MSC. The MSC stops timer T10. 35
y. Establishment of the PPP connection between the MS and PDSN is now 36
possible. Mobile IP Registration may be performed once the PPP link has 37
been established. Following MIP registration (if required), if neither the MS 38
nor the PDSN have data to send, the packet data service may again transition 39
to dormant (refer to Section 3.17.4.3). 40
3.18.5.3 Concurrent Service - Soft / Softer Handoff 41
The same procedure as in section 3.19.2 apply for this scenario. 42
3GPP2 A.S0013-0 v2.0
Section 3 203
3.19 Handoff 1
Inter-BS hard handoffs are discussed in section 3.19.1.2 (Inter-BS Hard Handoff), and 2
intra-BS handoffs are discussed in section 3.19.1.5 (Intra-BS Handoff). Multi-carrier 3
(MC) inter-BS soft/softer handoff is discussed in section 3.19.2 (Handoff via Direct BS-4
to-BS Signaling). Call flows for each of these procedures can be found in section 3.19.3 5
(Handoff Call Flows). Message formats and definitions of timers used within this chapter 6
can be found in the associated interface documents. 7
3.19.1 Handoff via MSC 8
3.19.1.1 Introduction 9
This section describes handoff via the MSC procedures; refer to section 2.19.1 for more 10
information. 11
3.19.1.1.1 Recognition That a Handoff is Required by a BS 12
The BS shall be able to generate an indication that a hard handoff may be required to the 13
MSC using the protocols defined. 14
No additional guidance is given within this specification concerning the algorithm within 15
the BS that generates either an Intra-BS handoff, or an indication to the MSC that an 16
Inter-BS hard handoff is required. 17
3.19.1.1.2 Recognition That a Handoff is Required by the MSC 18
For this version of the standard, the MSC may not autonomously precipitate a handoff. 19
3.19.1.1.3 Concept of “Designated Cell” 20
A “designated cell” is a cell identifier (cell + sector) that is chosen by the BS to represent 21
the MS’s location. The initial cell identifier associated with the MS’s activity 22
(origination, termination, etc.) is by definition the first “designated cell.” When the air 23
interface only supports connection of the MS to a single sector at a time, the “designated 24
cell” is the currently connected sector. When the air interface supports connection of an 25
MS to multiple sectors (possibly on different cells) simultaneously, e.g., CDMA 26
soft/softer handoff, a single “designated cell” is to be identified to the MSC. 27
As long as the original cell identifier that was provided to the MSC to identify the initial 28
“designated cell” remains on the call, it may remain the “designated cell.” When the 29
sector identified as the “designated cell” is removed from the call, the BS currently 30
serving as the source BS for the call chooses a new “designated cell” from the set of 31
sectors serving the call and shall provide the appropriate cell identifier to the MSC. The 32
source BS may choose a new “designated cell” at any time from the set of cells currently 33
serving the call. The technique for choice of a “designated cell” is an 34
operator/manufacturer concern. 35
The notification to the MSC can be implicit through the use of the inter-BS handoff 36
procedure (Handoff Required, Handoff Request, Handoff Request Acknowledge, 37
Handoff Command messages), or explicit through the use of the Handoff Performed 38
message. The implicit notification occurs when the handoff type is a hard handoff. The 39
change of designated cell occurs upon receipt of the Handoff Complete message. 40
3GPP2 A.S0013-0 v2.0
Section 3 204
3.19.1.2 Inter-BS Hard Handoff 1
This section discusses the protocol to support hard handoff transitions where the source 2
and target cells are under the domain of different BSs. For this version of the standard, it 3
is assumed that the only CDMA traffic channels that may be transferred via inter-BS hard 4
handoff are the Fundamental and Dedicated Control Channels (FCH and DCCH, resp.). 5
Hard handoff of the Supplemental Channel is not supported in this version of the 6
standard. 7
For an MS operating on the CDMA traffic channel, an inter-BS hard handoff may occur 8
while the MS is in the Conversation State or Waiting for Answer State. All connected 9
services that are handed off shall be handed off together to the same BS. 10
3.19.1.2.1 Triggering Phase 11
Hard handoff triggering is initiated by the MS or the source BS. 12
3.19.1.2.2 Target Determination Phase 13
Having received an indication from a BS that an Inter-BS hard handoff is required, the 14
decision of when and whether an Inter-BS hard handoff is to take place shall be made by 15
the MSC. Inter-BS soft/softer handoff decisions can be made by the source and target 16
BSs involved, refer to section 3.19.2 (Handoff via Direct BS-to-BS Signaling). 17
The Handoff Required message is used for this phase of the handoff; refer to [14] for 18
procedure descriptions of this message. 19
3.19.1.2.3 Resource Establishment 20
The following A1 Interface messages are required for this phase: 21
• Handoff Request 22
• Handoff Request Acknowledge 23
Refer to [14] for procedure descriptions of these messages. 24
3.19.1.2.4 Execution Phase 25
The following A1 Interface messages are required for this phase: 26
• Handoff Request 27
• Handoff Command 28
• Handoff Commenced 29
• Handoff Complete 30
Refer to [14] for procedure descriptions of these messages. 31
3.19.1.3 Call Clearing 32
The call clearing procedure is described in section 3.2. It is used in hard handoff 33
scenarios to release the source RF channel and terrestrial resource after either the mobile 34
has been acquired by the target BS or the call is dropped. 35
3GPP2 A.S0013-0 v2.0
Section 3 205
The MSC may use call clearing to tear down either the source channel, the target channel, 1
or both in the event of a failure in the handoff process. The call clearing messages are 2
only used to clear full-rate circuits. 3
The Clear Command message shall contain a cause field to inform the source or target 4
cell of the success or failure of the handoff procedure. This indication can be used for 5
statistics purposes. 6
3.19.1.4 Handoff Failure Handling 7
There are two messages that indicate a failure in the handoff process; the Handoff 8
Required Reject and the Handoff Failure messages. These messages are defined in [14]. 9
Also, refer to section 3.19.3.1.4 (Hard Handoff With Return On Failure). 10
When a traffic channel is not available at the target BS, several options are available: 11
Option 1 Target can allocate AMPS channel 12
Option 2 Target indicates failure to MSC, MSC attempts to allocate AMPS 13
channel. 14
Option 3 Target indicates failure then MSC passes it along to the source BS and 15
lets the source BS decide. 16
Option 3 shall be supported. 17
NOTE: This standard does not specify the messaging required for Option 1. Support and 18
implementation of this option is a vendor concern. 19
Handoff Failure Handling utilizes the following A1 Interface messages: 20
• Handoff Required Reject 21
• Handoff Failure 22
Refer to [14] for procedure descriptions of these messages. 23
3.19.1.5 Intra-BS Handoff 24
The BS uses the Handoff Performed message to inform the MSC of handoff operations. 25
Refer to [14] for procedure descriptions of this message. 26
3.19.2 Handoff via Direct BS-to-BS Signaling 27
This section describes handoff via direct BS-to-BS signaling. 28
3.19.2.1 A3 Interface Messages 29
This section describes the messages used to support handoff on the A3 interface. It is 30
organized into three subsections: 31
• A3 Interface Setup Messages, 32
• A3 Interface Operational Messages, and 33
• A3 Interface Clearing Messages 34
3GPP2 A.S0013-0 v2.0
Section 3 206
3.19.2.1.1 A3 Interface Setup Messages 1
The following messages are used for A3 interface setup procedures: 2
• A3-Connect 3
• A3-Connect Ack 4
For descriptions of the messages and their procedures, refer to [15]. 5
3.19.2.1.2 A3 Interface Operational Messages 6
The following messages are used for A3 interface operational procedures. 7
• A3-Physical Transition Directive 8
• A3-Physical Transition Directive Ack 9
• A3-Propagation Delay Measurement Report 10
• A3-IS-95 FCH Forward 11
• A3-IS-95 FCH Reverse 12
• A3-Traffic Channel Status 13
• A3-IS-2000 FCH Forward 14
• A3-IS-2000 FCH Reverse 15
• A3-IS-2000 DCCH Forward 16
• A3-IS-2000 DCCH Reverse 17
• A3-IS-2000 SCH Forward 18
• A3-IS-2000 SCH Reverse 19
• A3-FCH Forward Traffic Frame 20
• A3-FCH Reverse Traffic Frame 21
• A3-DCCH Forward Traffic Frame 22
• A3-DCCH Reverse Traffic Frame 23
For descriptions of the messages and their procedures, refer to [15]. 24
3.19.2.1.3 A3 Interface Clearing Messages 25
The following messages are used for A3 interface clearing procedures. 26
• A3-Remove 27
• A3-Remove Ack 28
• A3-Drop 29
For descriptions of the messages and their procedures, refer to [15]. 30
3.19.2.2 A7 Interface Messages 31
This section describes the messages used between base stations on an A7 connection to 32
support direct BS to BS soft/softer handoff, access handoff, access probe handoff, and 33
channel assignment into soft/softer handoff. These messages are: 34
• A7-Handoff Request 35
3GPP2 A.S0013-0 v2.0
Section 3 207
• A7-Handoff Request Ack 1
• A7-Drop Target 2
• A7-Drop Target Ack 3
• A7-Target Removal Request 4
• A7-Target Removal Response 5
• A7-Paging Channel Message Transfer 6
• A7-Paging Channel Message Transfer Ack 7
• A7-Access Channel Message Transfer 8
• A7-Access Channel Message Transfer Ack 9
• A7-Burst Request 10
• A7-Burst Response 11
• A7-Burst Commit 12
• A7-Burst Release 13
For descriptions of the messages and their procedures, refer to [15]. 14
3.19.2.3 Soft/Softer Handoff Addition 15
The source BS decides what cells are to be added to a call in soft/softer handoff. An A7-16
Handoff Request message is sent directly to the target BS across the A7 connection 17
between the source and target BSs to request the addition of those cells to the call. The 18
target BS allocates and connects the appropriate resources and responds directly to the 19
source BS using an A7-Handoff Request Ack message once all expected A3-Connect 20
Ack messages have been received. 21
The A3-Connect message is used by the target BS to both create new A3 connections for 22
a call, and to add cells to existing A3 connections. In either case, information on all cells 23
attached to the A3 connection shall be included in the A3 Connect Information IE, and 24
there shall be an indication as to which cells were already existing and which cells were 25
newly associated with the A3 connection. 26
The A3-Connect message can be used to establish multiple A3 connections. To support 27
this capability, multiple sets of cell information may be included. A single A3-Connect 28
Ack message is used to respond to an A3-Connect message, regardless of the number of 29
A3 connections being established via the A3-Connect message. The A3-Connect Ack 30
message is returned to the address from which the A3-Connect message was sent. 31
In response to an A7 Handoff Request message that includes multiple cells to be added to 32
the call association in soft or softer handoff, the target BS may send a single A3-Connect 33
message including information for multiple connections, or it may send multiple A3-34
Connect messages where each message includes information for a single connection only. 35
However, the target BS shall not send multiple A3-Connect messages that each include 36
multiple connection information, nor any combination of such messages and A3-Connect 37
messages that include information for a single connection. The requirements of this 38
paragraph may be relaxed in a future revision of this standard. 39
The A3-Connect Ack and A3-Traffic Channel Status messages support the ability of the 40
source BS to request that the target BS send a notification that the target BS transmitter(s) 41
and receiver(s) are turned on. 42
3GPP2 A.S0013-0 v2.0
Section 3 208
3.19.2.4 Soft/softer Handoff Removal 1
Removal of cells in soft/softer handoff involves the sending by the source BS of an A7-2
Drop Target message to the target BS. The target BS removes the indicated cells and 3
responds with an A7-Drop Target Ack message. If the last cell(s) attached to a particular 4
A3 connection are removed, the target BS also initiates removal of that A3 connection. 5
3.19.2.5 Cell Removal by a Target BS 6
For a variety of reasons, a target BS may need to request that one or more of its cells be 7
removed from a call. This request can be for reasons of internal resource management, 8
OA&M, internal BS error situations, etc. The target BS, in these cases, sends an A7-9
Target Removal Request message to the source BS with appropriate information to 10
indicate what cells need to be removed from the call, and for what reason(s). The source 11
BS takes the appropriate actions and respond with an A7-Target Removal Response 12
message or it may indicate to the target BS that the target cell(s) are to remain in the call. 13
3.19.2.6 Call Clearing 14
Call clearing for calls using packet based soft/softer handoff is always accomplished via 15
the source BS. If the call clearing is initiated by either the MS or source BS, a Clear 16
Request message is sent to the MSC to request call clearing. If the MSC initiates the call 17
clearing, it sends a Clear Command message to the source BS. Clear Command messages 18
are not sent to target BSs involved in the call. Instead, the source BS is responsible for 19
using the A7 interface drop target procedure to remove all target BSs from the call. 20
When the A7 target drop procedure is used during call release scenarios, the A7 Drop 21
Target message shall contain the cell identify list with zero cells included. In this case, 22
the source should wait some period of time to allow any in progress adds or drops to 23
complete prior to sending the A7 Drop Target message. 24
3.19.2.7 Handoff Performed 25
The source BS is responsible for sending Handoff Performed messages to the MSC to 26
keep it informed of the identity of the cells currently involved in supporting the call. 27
Refer to section 3.19.1.1.3 “Concept of “Designated Cell” and [14]. 28
3.19.2.8 Access Handoff and Channel Assignment into Soft Handoff 29
In addition to setting up soft handoff legs during a call, the soft handoff legs can also be 30
setup during the establishment of the call. This procedure is required to support the 31
access probe handoff, access handoff, and channel assignment into soft/softer handoff. 32
The source BS decides what cells are to be setup in soft/softer handoff during the 33
establishment of the call and the A7-Handoff Request procedure is used. That is, an A7-34
Handoff Request message is sent directly to the target BS across the A7 connection 35
between the source and target BSs to request the setup of those cells to the call. The 36
target BS allocates and connects the appropriate resources and responds directly to the 37
source BS using an A7-Handoff Request Ack message once all expected A3-Connect 38
Ack messages have been received. 39
Cells that are likely candidates for access probe handoff and access handoff by the MS 40
are included in the ACCESS_HO_LIST. 41
3GPP2 A.S0013-0 v2.0
Section 3 209
For each message received on one of its access channels, the BS shall analyze the 1
PILOT_RECORD if such a record is included in the message. If the BS does not 2
correspond to the first attempted pilot in the record (i.e., is not the source BS), then it 3
shall forward the access channel message on an inter-BS (i.e., A7) link corresponding to 4
the first attempted pilot in the record. If the access channel message is an Origination or 5
Page Response, the BS shall forward the message as indicated above and shall not send 6
the corresponding CM Service Request message or Paging Response message to the 7
MSC. 8
The source BS sends A7-Paging Channel Message Transfer messages carrying an 9
appropriate channel assignment information to selected BSs, usually chosen from those 10
contained in the ACCESS_HO_LIST and OTHER_REPORTED_LIST, requesting that 11
they send the channel assignment message on specific cells. The channel assignment 12
message is used to assign the forward channel(s) to the MS. 13
The set of BSs to which the source BS sends the A7 Paging Channel Message Transfer 14
message may be different from the set of BSs that are set up in soft handoff. 15
Refer to section 3.1.2.2 for an example scenario showing access probe handoff, access 16
handoff and channel assignment into soft/softer handoff. 17
Also refer to [15] for information on the A7-Paging Channel Message Transfer, A7-18
Paging Channel Message Transfer Ack, A7-Access Channel Message Transfer, and A7-19
Access Channel Message Transfer Ack messages. 20
3.19.2.9 Soft/Softer Handoff of High Speed Packet Data 21
Support of high speed packet data (i.e., speeds greater than 14.4 kbps) may be 22
accomplished through the use of multiple physical channels. These physical channels are 23
supported in the infrastructure using A3 traffic connections during soft/softer handoff. 24
Setup of an A3 connection for a traffic burst is accomplished using A7-Burst Request, 25
A7-Burst Response, A7-Burst Commit, and A7-Burst Release messages. Establishment 26
of the A3 connection for the Supplemental Channel (SCH) is accomplished via the A7-27
Handoff Request, A7-Handoff Request Ack, A3-Connect and A3-Connect Ack messages. 28
In this version of this standard, it is assumed that any leg for a Supplemental Channel is 29
established on a cell that already supports a leg for the Fundamental Channel (FCH) or 30
the Dedicated Control Channel (DCCH) for the same MS. To minimize the time required 31
to establish a traffic burst, the A3 connection for an SCH is established on the target BS 32
at the transmission of the first data burst. When a leg is established for an SCH, only the 33
terrestrial resources are allocated, i.e., the A3 connection. This involves choosing the 34
traffic circuit to be used and establishing context between the target BS and the source 35
BS/SDU function. Allocation of radio resources for the SCH is made each time that a 36
traffic burst is set up. 37
When the source BS realizes that it is necessary to allocate radio resources for a traffic 38
burst in either the forward or reverse direction or both, it sends an A7-Burst Request 39
message to each target BS to request reservation of specific radio resources. Each target 40
BS responds with A7-Burst Response message(s) to indicate radio resource reservations 41
for the requested cells. Once the source BS has received the A7-Burst Response 42
messages, it sends either A7-Burst Commit or A7-Burst Release message(s) to each 43
target BS to indicate the set of radio resources to be used. A burst time that requires the 44
message to be pending for more than 7/8 of the modulo window in the future from its 45
time of arrival shall be considered late and the message shall be processed immediately. 46
End time shall still be calculated from the specified start time and duration. Each target 47
3GPP2 A.S0013-0 v2.0
Section 3 210
BS receiving A7-Burst Commit then prepares the indicated cell, connects it to the pre-1
established A3 connection, and then participates in the burst. Each target BS receiving an 2
A7-Burst Release then releases the resources reserved at the indicated cell(s). Both cases 3
are shown in examples in section 3.19.3.2. 4
3.19.2.9.1 Soft/Softer Handoff of Forward Link Bursts of Data 5
When a traffic burst is scheduled to begin, the SDU function begins to transmit forward 6
link frames carrying user traffic on the A3 connection for the SCH. At the termination of 7
a traffic burst in the forward direction, the SDU function ceases transmitting frames on 8
the SCH A3 connection. The SDU function may begin to send idle frames on the forward 9
A3 connection prior to the beginning of the burst to allow synchronization of the A3 10
connection. If the target BS receives forward idle frames and is not receiving reverse 11
frames from the MS, it shall send reverse idle frames to the SDU function to allow packet 12
arrival time error adjustments to occur. 13
The SDU function shall send no more than 9144 bits (i.e., 3 frames of data for a burst at 14
153.6 KBPS) to the target BS prior to the beginning of a traffic burst in the forward 15
direction. 16
When a new traffic burst is initiated on an A3 connection for a SCH, the target BS shall 17
wait for the first forward link frame before transmitting any reverse link frames. If the 18
target BS receives a forward link Idle Frame, it shall calculate the packet arrival time 19
error and transmit that information on the reverse link in an Idle Frame if it has no user 20
traffic to transmit in a non-idle frame. The target BS shall not transmit any air interface 21
frame when receiving a forward link Idle Frame. In this way, the SDU function can 22
control precisely the beginning of forward link traffic bursts on physical channels. 23
The source BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Forward message 24
with Forward Layer 3 Data elements containing Null or Idle frame contents. Refer to [15] 25
(IS-2000 Frame Content) for source and target operations with Null and Idle frames. 26
The target BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Reverse message 27
with Reverse Layer 3 Data information elements containing Null or Idle frame contents 28
if, and only if, an A3-IS-2000 SCH Forward message was not received in the previous 29
air-frame period. Refer to [15] (IS-2000 Frame Content) for source and target operations 30
with Null and Idle frames. 31
3.19.2.9.2 Soft/Softer Handoff of Reverse Link Bursts of SCH Data 32
When a traffic burst is expected by a target BS, the target BS shall wait as indicated 33
above for the first forward link frame so that the packet arrival time error can be correctly 34
calculated. Following reception of each forward link frame at the target BS, the target BS 35
shall transmit a reverse link frame. Reverse link frames may contain user traffic (i.e., 36
packet data), Idle Frames, Null Frames, Re-Acquiring Frames, or Erasure Frames. 37
Reverse link frames containing user traffic, Re-Acquiring Frames, or Erasure frames (i.e., 38
decoded from the air interface) may be sent without prior reception of forward link 39
frames. 40
The target BT shall decide whether Erasure Frames, Re-Acquired Frames, or Null Frames 41
should be sent to the SDU in the source BS in the cases of DTX or loss of finger lock. 42
3GPP2 A.S0013-0 v2.0
Section 3 211
3.19.3 Handoff Call Flows 1
3.19.3.1 Hard Handoff via MSC Call Flows 2
3
3.19.3.1.1 Successful Hard Handoff 4
The following call flow diagram provides an illustration for a successful hard handoff 5
event. It is assumed that the call is not in inter-BS soft/softer handoff prior to the hard 6
handoff, and thus no A3 connections need to be removed. 7
MS Source BS MSC Time Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Handoff Command
Handoff Direction Message
MS Ack Order
Target BS
Null forward traffic channel frames
Handoff Request Ack
T7
T9
Handoff Commenced h
j
i
k
l
m
n
Reverse Traffic Channel Frames or Traffic Channel Preamble
Handoff Completion Message
Clear Command
Clear Complete
BS Ack Order
Handoff CompleteT306
T315
Twaitho
x
T11
8
Figure 3.19.3.1.1-1 Successful Hard Handoff 9
a. Based on an MS report that it crossed a network specified threshold for signal 10
strength or for other reasons, the source BS recommends a hard handoff to one 11
or more cells in the domain of the target BS. The source BS sends a Handoff 12
Required message with the list of cells to the MSC and starts timer T7. 13
b. The MSC sends a Handoff Request message to the target BS with the IS-95 14
Channel Identity element or the IS-2000 Channel Identity element present 15
since the hard handoff bit was set and/or the Handoff Type element in the 16
Handoff Required message indicated hard handoff. The MSC starts timer T11. 17
In the case of hard handoff for an async data/fax call, the Circuit Identity 18
Code Extension element in the Handoff Request message indicates the Circuit 19
Identity Code of the circuit to be connected to the SDU function at the target 20
BS to support the A5 connection to the IWF. 21
3GPP2 A.S0013-0 v2.0
Section 3 212
c. Upon receipt of the Handoff Request message from the MSC, the target BS 1
allocates appropriate radio resources as specified in the message and connects 2
the call. As the Handoff Request message can have multiple cell(s) specified, 3
the target BS can also choose to setup multiple cell(s) for the handoff request. 4
The target BS sends null forward traffic channel frames to the MS. 5
d. The target BS sends a Handoff Request Acknowledge message to the MSC 6
and starts timer T9 to wait for arrival of the MS on its radio channel. The MSC 7
stops timer T11 upon the receipt of this message. The first cell in the cell 8
identifier list element of the message will be treated as the new designated cell 9
by the MSC. The change of designated cell occurs upon receipt of the Handoff 10
Complete message. If the service option received in the Handoff Request 11
message is not available at the target BS and the target BS selected a different 12
service option for the handoff then the target BS shall include the service 13
option it selected in the Service Configuration Record IE. 14
e. The MSC prepares to switch from the source BS to the target BS and sends a 15
Handoff Command to the source BS. The source BS stops timer T7. The MSC 16
shall include the service option it received from the Handoff Request 17
Acknowledgement message in the Handoff Command message. 18
f. The source BS sends the handoff direction message1 to the MS across the air 19
interface. If the MS is allowed to return to the source BS, then timer Twaitho is 20
also started by the source BS. 21
g. The MS may acknowledge the handoff direction message by sending a MS 22
Ack Order to the source BS. 23
If the handoff direction message is sent using quick repeats, the source BS 24
might not request an acknowledgment from the MS. 25
h. The source BS sends a Handoff Commenced message to the MSC to notify it 26
that the MS has been ordered to move to the target BS channel. The source BS 27
starts timer T306 to await the Clear Command message from the MSC. If timer 28
Twaitho has been started, the source BS shall wait for that timer to expire 29
before sending the Handoff Commenced message. 30
i. The MS sends reverse traffic channel frames or the traffic channel preamble to 31
the target cell(s). 32
j. The MS sends a Handoff Completion Message to the target BS. 33
k. The target BS sends the BS Ack Order to the MS over the air interface. 34
l. The target BS sends a Handoff Complete message to the MSC to notify it that 35
the MS has successfully completed the hard handoff. The target BS stops 36
timer T9. 37
m. The MSC sends a Clear Command to the source Bs and starts timer T315. The 38
source BS stops timer T306. 39
In the case of hard handoff for an async data/fax call, clearing of all resources 40
including the A5 connection at the old BS is accomplished via the Clear 41
Command message. 42
1 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.S0013-0 v2.0
Section 3 213
n. The source BS sends a Clear Complete message to the MSC to notify it that 1
clearing has been accomplished. The MSC stops timer T315. 2
3.19.3.1.2 Successful Hard Handoff to ANSI/TIA/EIA-553-A Systems 3
For the purpose of this specification, the single MSC in the following figure represents 4
the source and the target MSC connected by TIA/EIA IS-41. The message flows between 5
the target MSC and the target BS in the figure are not required. 6
The following call flow diagram provides an illustration for a successful hard handoff 7
event to an analog [18] system. 8
MS MSCtime comment
a
b
c
d
e
f
g
h
Analog Handoff Direction Msg
Handoff Required
i
Handoff Request
Handoff Request Ack
Handoff Command
Handoff Commenced
Handoff Complete
Clear Command
Clear Complete
T7
T9
j
k
Acknowledge Order
Transponded SAT
T306
T315
SourceBS
TargetBS
T11
9
Figure 3.19.3.1.2-1 Successful Hard Handoff to an ANSI/TIA/EIA-553-A System 10
a. Based on an MS report that it has crossed a network specified threshold for 11
signal strength, the source BS recommends a hard handoff to one or more 12
cells in the domain of the target BS. The source BS sends a Handoff Required 13
message with the Cell Identifier List to the MSC to find a target with available 14
resources and starts timer T7. The source BS indicates a response requirement 15
by including the Response Request element. 16
b. The MSC sends a Handoff Request message to the target BS without the IS-95 17
Channel Identity nor the IS-2000 Channel Identity element present, since this 18
is a CDMA to Analog hard handoff request. The MSC starts timer T11. 19
c. The target BS determines that appropriate resources are available, sends a 20
Handoff Request Acknowledge message to the MSC, and starts timer T9. The 21
MSC stops T11 upon receipt of this message. 22
d. The MSC prepares to switch from the source BS to the target BS and sends a 23
Handoff Command to the source BS to convey information from the target 24
BS. The source BS stops timer T7 upon receipt of this message. 25
3GPP2 A.S0013-0 v2.0
Section 3 214
e. The source BS transmits the Analog Handoff Direction Message to the MS 1
and may request a Layer 2 acknowledgment. 2
f. The MS returns an MS Ack Order to the source BS to confirm receipt of the 3
Analog Handoff Direction Message. 4
If the handoff direction message is sent using quick repeats the source BS 5
might not request an acknowledgement from the MS. 6
g. The source BS sends a Handoff Commenced message to the MSC to notify it 7
that the MS has been ordered to move to the target BS channel. The source BS 8
starts timer T306 to await the Clear Command from the MSC. 9
h. The MS tunes to the target BS SAT and initiates transmission of transponded 10
SAT. The target BS stops timer T9. 11
i. Upon reception of the correct MS transponded Supervisory Audio Tone 12
(SAT), the target BS sends a Handoff Complete message to the MSC to 13
indicate that the MS has successfully accessed the target BS. 14
j. The MSC releases the source BS’s terrestrial circuit and instructs the source 15
BS to release its radio resources by sending a Clear Command message to the 16
source BS with the Cause element set to “Handoff successful.” The MSC 17
starts timer T315. The source BS stops timer T306 when the Clear Command 18
message is received. 19
k. The source BS releases its source channel, clears any terrestrial resources, and 20
then returns a Clear Complete message to the MSC to indicate that the 21
transition is complete. The MSC stops timer T315 when the Clear Complete 22
message is received. 23
3.19.3.1.3 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 24
Alternative Rejected 25
For the purpose of this specification, the single MSC in the following figure represents 26
the source and the target MSC connected by TIA/EIA IS-41. The message flows between 27
the target MSC and the target BS in the figure are informative and are not required. 28
The following call flow diagram provides an illustration of an unsuccessful Hard 29
Handoff. In this example, the source BS determines that an ANSI/TIA/EIA-553-A 30
alternative is not acceptable, rejects the Handoff Command and maintains the mobile. 31
3GPP2 A.S0013-0 v2.0
Section 3 215
MS MSCtime comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Handoff Request Ack
Handoff Command
Handoff Failure
Clear Command
Clear Complete
T7
T9
T315
SourceBS
TargetBS
T11
1
Figure 3.19.3.1.3-1 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A 2
Alternative Rejected 3
a. Based on an MS report that it has crossed a network specified threshold for 4
signal strength, the source BS recommends a hard handoff to one or more 5
cells in the domain of the target BS. The source BS sends a Handoff Required 6
message with the Cell Identifier List to the MSC to find a target with available 7
resources and starts timer T7. The source BS indicates a response requirement 8
by including the Response Request element. 9
b. The MSC sends a Handoff Request message to the target BS without the IS-95 10
Channel Identity nor the IS-2000 Channel Identity element present, since this 11
is a CDMA to Analog hard handoff request. The MSC starts timer T11. 12
c. The target BS determines that a channel resource is not available and reserves 13
or allocates an ANSI/TIA/EIA-553-A channel. The target BS sends a Handoff 14
Request Acknowledge message to the MSC informing it of the availability of 15
the ANSI/TIA/EIA-553-A channel and starts timer T9. The MSC stops timer 16
T11. 17
d. The MSC sends a Handoff Command message to the source BS to convey 18
information from the target BS to the source BS. The source BS stops timer 19
T7 upon receipt of this message. In the Handoff Command, the Handoff Type 20
element, if present, shall be set to “CDMA-Analog Hard HO.” 21
e. Upon receipt of the Handoff Command message from the MSC, the source BS 22
recognizes that an analog [18] channel has been supplied and decides to reject 23
the assignment. The source BS keeps the MS and sends a Handoff Failure 24
message to the MSC with the Cause element set to “Alternate signaling type 25
reject.” 26
f. The MSC releases the terrestrial circuit to the target BS, instructs the target 27
BS to release its radio resources by sending a Clear Command message, and 28
starts timer T315. The target BS stops timer T9 upon receipt of this message. 29
. 30
g. The target BS sends a Clear Complete message to the MSC to indicate that the 31
resource release operation is complete. The MSC stops timer T315 upon 32
receipt of this message. 33
3GPP2 A.S0013-0 v2.0
Section 3 216
3.19.3.1.4 Hard Handoff With Return On Failure 1
The following call flow diagram provides an illustration for a hard handoff event. In this 2
scenario, the MS successfully returns to the source BS after hard handoff fails. It is 3
assumed that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and 4
thus no inter-BS connections need to be removed. 5
MS Source BS MSC Time Comment
a
b
c
d
e
f
g
Handoff Required
Handoff Request
Handoff Command
handoff direction message
MS Ack Order
Target BS
Null forward traffic channel frames
Handoff Request Ack
T7
T9
h
i
j
k
Clear Command
Handoff Failure
CF Search Report Message
Clear CompleteT315
Twaitho
T11
6
Figure 3.19.3.1.4-1 Hard Handoff with Return On Failure 7
a. Based on an MS report that it crossed a network specified threshold for signal 8
strength or for other reasons, the source BS recommends a hard handoff to one 9
or more cells in the domain of the target BS. The source BS sends a Handoff 10
Required message with the list of cells to the MSC and starts timer T7. 11
b. The MSC sends a Handoff Request message to the target BS with the IS-95 12
Channel Identity element or the IS-2000 Channel Identity element present 13
since the hard handoff bit was set and/or the Handoff Type element in the 14
Handoff Required message indicated hard handoff. The MSC starts timer T11. 15
In the case of hard handoff for an async data/fax call, the Circuit Identity 16
Code Extension element in the Handoff Request message indicates the Circuit 17
Identity Code of the circuit to be connected to the SDU function at the target 18
BS to support the A5 connection to the IWF. 19
c. Upon receipt of the Handoff Request message from the MSC, the target BS 20
allocates appropriate radio resources, as specified in the message, and 21
connects it to the terrestrial circuit. The target BS sends null forward traffic 22
channel frames to the MS. 23
d. The target BS sends a Handoff Request Acknowledgment message to the 24
MSC and starts timer T9 to wait for arrival of the MS on its radio channel. The 25
MSC stops timer T11 upon receipt of this message. 26
e. The MSC prepares to switch from the source BS to the target BS and sends a 27
Handoff Command to the source BS. The source BS stops timer T7. 28
3GPP2 A.S0013-0 v2.0
Section 3 217
f. The source BS sends the handoff direction message2 to the MS across the air 1
interface. The source BS indicates in the message that the MS is permitted to 2
return to the source BS if handoff to the target fails. The source BS starts 3
timer Twaitho. 4
g. The MS may acknowledge the handoff direction message by sending a MS 5
Ack Order to the source BS. 6
If the handoff direction message is sent using quick repeats, the source BS 7
might not request an acknowledgment from the MS. 8
h. The MS sends a Candidate Frequency (CF) Search Report Message to the 9
source BS after handoff to the target has failed. The source BS stops timer 10
Twaitho. 11
i. Upon receipt of the CF Search Report Message from the MS the source BS 12
detects that the MS has never accessed the target BS cell and sends a Handoff 13
Failure message to the MSC with the Cause element set to “Reversion to old 14
channel.” 15
j. The MSC sends a Clear Command to the target BS and starts timer T315. The 16
target BS stops timer T9 upon receipt of this message. 17
k. The target BS releases and de-allocates the radio and terrestrial resources. The 18
target BS sends a Clear Complete message to the MSC to indicate that the 19
resource release operation is complete. The MSC stops timer T315 upon 20
receipt of this message. 21
3.19.3.1.5 Hard Handoff Failure – Connection Refused 22
The following call flow diagram provides an illustration for a hard handoff failure event. 23
In this scenario, the target BS notifies the MSC that the handoff has failed by sending a 24
Handoff Failure Message as a Connection Refused (CREF) message. It is assumed that 25
the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no inter-26
BS connections need to be removed. 27
Source BS MSC Time Comment
a
b
c
d
Handoff Required
Handoff Request
Handoff Required Reject
Target BS
Handoff Failure
T7T11
28
Figure 3.19.3.1.5-1 Hard Handoff Failure 29
a. Based on an MS report that it crossed a network specified threshold for signal 30
strength or for other reasons, the source BS recommends a hard handoff to one 31
2 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.S0013-0 v2.0
Section 3 218
or more cells in the domain of the target BS. The source BS sends a Handoff 1
Required message with the list of cells to the MSC and starts timer T7. 2
b. The MSC sends a Handoff Request message to the target BS with the IS-95 3
Channel Identity element or the IS-2000 Channel Identity element present 4
since the hard handoff bit was set and/or the Handoff Type element in the 5
Handoff Required message indicated hard handoff. The MSC starts timer T11. 6
In the case of hard handoff for an async data/fax call, the Circuit Identity 7
Code Extension element in the Handoff Request message indicates the Circuit 8
Identity Code of the circuit to be connected to the SDU function at the target 9
BS to support the A5 connection to the IWF. 10
c. The target BS receives the Handoff Request message but is unable to 11
accommodate the handoff request. The target BS then sends a Handoff Failure 12
message as a SCCP Connection Refused message to the MSC. 13
d. Upon receipt of the Handoff Failure message, the MSC stops timer T11. The 14
MSC then sends a Handoff Required Reject message to the source BS. Upon 15
receipt of the Handoff Required Reject message, the source BS stops timer T7. 16
A new handoff procedure may be initiated if the condition of the call 17
connection warrants immediate action. 18
3.19.3.2 Soft/softer Handoff via Direct BS-to-BS Signaling Call Flows 19
20
3.19.3.2.1 Soft/softer Handoff Addition 21
Soft/softer handoff addition occurs as shown in the following diagram. Soft/softer 22
handoff addition includes both the creation of new A3 traffic connections, as well as the 23
addition of cells to existing A3 traffic connections. In this section, “A3-CEData 24
Forward/Reverse” messages represent “A3-IS-95 FCH Forward/Reverse”, “A3-IS-2000 25
FCH Forward/Reverse”, or “A3-IS-2000 DCCH Forward/Reverse” messages. For SCH 26
soft/softer handoff addition, refer to sections 3.19.3.2.4 and 3.19.3.2.5. 27
3GPP2 A.S0013-0 v2.0
Section 3 219
Source BS
Target BS
MS
MSC
A7- Handoff Request
A3-Connect
A3-Connect Ack
A7- Handoff Request Ack
A3-Traffic Channel Status
handoff direction message
Handoff Performed
a
b
c
g
h
i
j
Time Comment
Conditional: (see [x])
MS Ack Order
Handoff Completion Message
BS Ack Order
k
l
m
Thoreq
Tconn3
d A3-CEData Forward (Forward Frames)
Forward Frames
e
f
A3-CEData Reverse (Idle Frames)
Conditional: (See section 3.14.1.1.3)
1
Figure 3.19.3.2.1-1 Soft/Softer Handoff Addition 2
a. The source BS decides that one or more cells at the target BS are needed to 3
support the call in soft/softer handoff. The source BS sends an A7-Handoff 4
Request to the target BS and starts timer Thoreq. 5
b. The target BS initiates an A3 traffic connection (or adds to an existing one) by 6
sending an A3-Connect message to the source BS and starts timer Tconn3. 7
Note that a single A7-Handoff Request message may result in multiple A3 8
traffic connections being established, each using a separate A3-Connect 9
message. This example shows only a single A3 traffic connection being 10
established. 11
c. The source BS replies with an A3-Connect Ack message to complete the A3 12
connection or to acknowledge the addition of cells to an existing A3 13
connection. The target BS stops timer Tconn3. 14
d. The source BS begins to send forward frames to the target BS. 15
e. The target BS begins to send reverse idle frames as soon as the first forward 16
frame is received from the source BS. The reverse frames contain the timing 17
adjustment information necessary to achieve synchronization. 18
f. The target BS begins to transmit the forward frames as soon as 19
synchronization has occurred. 20
g. The target BS sends an A7-Handoff Request Ack message to the source BS to 21
indicate the success of the cell addition(s). The source BS stops timer Thoreq. 22
3GPP2 A.S0013-0 v2.0
Section 3 220
h. If the source BS has chosen to be notified of the start of transmission and 1
reception at the target BS, when its SDU function and the target BS have 2
synchronized the A3 traffic subchannel, the target BS replies with an A3-3
Traffic Channel Status message. Refer to also [15] “A3-Connect Ack”. Note 4
that this step may occur any time after step (d). 5
i. The source BS sends a handoff direction message3 to the MS to add the new 6
cell(s) to the active set. 7
j. The MS acknowledges receipt of the handoff direction message with an MS 8
Ack Order. 9
k. The MS indicates successful results of processing the handoff direction 10
message by sending a Handoff Completion Message. 11
l. The source BS acknowledges receipt of the Handoff Completion Message by 12
sending a BS Ack Order. 13
m. The source BS may send a Handoff Performed message to the MSC. Refer to 14
section 3.19.1.1.3 “("Concept of A "Designated Cell")”. The Handoff 15
Performed message may be sent any time after the Handoff Completion 16
Message is received by the BS. 17
3.19.3.2.2 Soft/softer Handoff Removal 18
Soft/softer handoff removal occurs as shown in the following diagram. In this section, 19
“A3-CEData Forward/Reverse” messages represent “A3-IS-95 FCH Forward/Reverse”, 20
“A3-IS-2000 FCH Forward/Reverse”, or “A3-IS-2000 DCCH Forward/Reverse” 21
messages. 22
3 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.S0013-0 v2.0
Section 3 221
Conditional: (See section 3.14.1.1.3)
MS
Source BS
Target BS
MSC
A7-Drop Target
A3-Remove
A3-Remove Ack
A7-Drop Target Ack
handoff direction message
Handoff Performed
b
c MS Ack Order
Handoff Completion Message
BS Ack Order
e
f
k
g
h
i
j
Time Comment
Tdrptgt Tdiscon3
A3-CEData Forward (HO Dir. Msg.)
A3-CEData Reverse (MS Ack Order)
a
d
1
Figure 3.19.3.2.2-1 Soft/Softer Handoff Removal 2
a. The source BS sends a handoff direction message4 in an A3-CEData Forward 3
message to the target BS to be sent to the MS to drop one or more cell(s) from 4
the active set. 5
b. The source BS and target BS transmit the handoff direction message to the 6
MS. 7
c. The MS acknowledges receipt of the handoff direction message with an MS 8
Ack Order transmitted to both the source and target BSs. 9
d. The target BS relays the MS Ack Order to the source BS in an A3-CEData 10
Reverse message. 11
e. The MS indicates successful results of processing the handoff direction 12
message by sending a Handoff Completion Message. 13
f. The source BS acknowledges receipt of the Handoff Completion Message by 14
sending a BS Ack Order. 15
g. The source BS sends an A7-Drop Target message to the target BS to request 16
that the specified cells be removed from the call. The source BS starts timer 17
Tdrptgt. 18
h. The target BS, upon receipt of the A7-Drop Target message, deallocates 19
internal resources related to the specified cells. The target BS sends an A3-20
Remove message to the SDU function of the source BS and starts timer 21
Tdiscon3. 22
4 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.S0013-0 v2.0
Section 3 222
i. The SDU function of the source BS replies with an A3-Remove Ack message 1
and deallocates internal resources. The target BS stop timer Tdiscon3. 2
j. The target BS sends an A7-Drop Target Ack message to the source BS to 3
acknowledge the removal of the specified cells. The source BS stops timer 4
Tdrptgt. 5
k. The source BS may send a Handoff Performed message to the MSC. Refer to 6
section 3.19.1.1.3 “Concept of A Designated Cell”. The Handoff Performed 7
message may be sent any time after the Handoff Completion Message is 8
received by the BS. 9
3.19.3.2.3 Cell Removal by a Target BS 10
The example below shows a Target Removal initiated by a target BS, where the last cell 11
attached to an A3 call leg is removed, thus causing the A3 call leg connections to be torn 12
down. As can be seen in the example, the A7-Target Removal Request message initiates 13
normal call leg removal, that is, the normal A7 interface call leg removal procedure is 14
used between the A7-Target Removal Request and A7-Target Removal Response 15
messages. 16
Source BS
Target BS
MS
MSC
A7-Drop Target
A3-Remove
A3-Remove Ack
A7-Drop Target Ack
handoff direction message
Handoff Performed
b
c MS Ack Order
Handoff Completion Message
BS Ack Order d
e
j
f
g
h
i
Time Comment
A7-Target Removal Request a
A7-Target Removal Response k
Ttgtrmv
Tdrptgt
Tdiscon3
Conditional: (See section 3.14.1.1.3)
17
Figure 3.19.3.2.3-1 Cell Removal Initiated by the Target BS 18
a. The target BS decides that one or more of its cells can no longer be involved 19
in the soft/softer handoff and sends an A7-Target Removal Request message 20
to the source BS. The target BS starts timer Ttgtrmv. 21
3GPP2 A.S0013-0 v2.0
Section 3 223
b. The source BS sends a handoff direction message5 to the MS to drop the 1
cell(s) from the active set. 2
c. The MS acknowledges receipt of the handoff direction message with an MS 3
Ack Order. 4
d. The MS indicates successful results of processing the handoff direction 5
message by sending a Handoff Completion Message. 6
e. The source BS acknowledges receipt of the Handoff Completion Message by 7
sending a BS Ack Order. 8
f. The source BS sends an A7-Drop Target message to the target BS to request 9
that the specified cells be removed from the call. The source BS starts timer 10
Tdrptgt. 11
g. The target BS, upon receipt of the A7-Drop Target message, deallocates 12
internal resources related to the specified cells. In this example, it is assumed 13
that all cells attached to an A3 connection are removed from the call. The 14
target BS sends an A3-Remove message to the SDU function of the source BS 15
and starts timer Tdiscon3. 16
h. The SDU function of the source BS replies with an A3-Remove Ack message 17
and deallocates internal resources. The target BS stop timer Tdiscon3. 18
i. The target BS sends an A7-Drop Target Ack message to the source BS to 19
acknowledge the removal of the specified cells. The source BS stops timer 20
Tdrptgt. 21
j. The source BS may send a Handoff Performed message to the MSC. Refer to 22
section 3.19.1.1.3 “Concept of A Designated Cell”. The Handoff Performed 23
message may be sent any time after the Handoff Completion Message is 24
received by the BS. 25
k. The source BS responds to the target BS with an A7-Target Removal 26
Response message. The target BS stops timer Ttgtrmv. 27
3.19.3.2.4 Initial Traffic Burst Example – A3 Connection Not Yet Established 28
The following example describes the support of an initial traffic burst when the A3 29
connection has not yet been established. 30
In this version of this standard, it is assumed that any leg for a Supplemental Channel is 31
established on a cell that also supports a leg for the Fundamental Channel (FCH) or the 32
Dedicated Control Channel (DCCH) for the same MS. To minimize the time required to 33
establish a traffic burst, the A3 connection for the SCH is established on the target BS at 34
the transmission of the first data burst. When a leg is established for a SCH, only the 35
terrestrial resources are allocated, i.e., the A3 connection. This involves choosing the 36
traffic circuit to be used and establishing context between the target BS and the source 37
BS/SDU function. Allocation of radio resources for the SCH is made each time that a 38
traffic burst is set up. 39
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.S0013-0 v2.0
Section 3 224
i
A3 -Physical Transition Directive
Tconn3 A3-Connect Ack
A3-Connect
A7-Burst Request
Thoreq
A7- Handoff Request Ack
A7- Handoff Request
Source BS
Target BS
MS
b
c
d
Time Comment
Tbstcom
e
A7-Burst Response
f
g
A7-Burst Commit
Forward and/or reverse traffic burst j
i ESCAM
Layer 2 Ack
Tbstreq
SCRM Msg
PDSN
(data to be sent) a
h
k
l
1
Figure 3.19.3.2.4-1 Initial Traffic Burst Example 2
a. Either the source BS receives an indication from the MS (via a Supplemental 3
Channel Request Message (SCRM)) or from the network (via data being 4
received from the PDSN) that data needs to be sent to/from the MS. The 5
source BS decides a traffic burst on one or more new cells at a target BS is 6
required in support of a service instance in soft/softer handoff. This example 7
assumes that a Fundamental Channel (FCH) or Dedicated Control Channel 8
(DCCH) leg already exists on the selected cell(s) at the target BS. For 9
simplicity, only one SCH is shown. 10
b. The source BS assigns an A7 Originating ID value and sends an A7 Handoff 11
Request to the target BS to establish an A3 traffic connection to support a 12
Supplemental Channel (SCH) for the call. This example shows only a single 13
A3 connection being established. The source BS is not required to assign a 14
physical Frame Selector at this time. The source BS starts timer Thoreq. 15
c. The target BS assigns a traffic circuit and optionally a Channel Element ID 16
(CE ID) for each A3 traffic connection and sends an A3-Connect message to 17
the source BS indicating the Traffic Circuit ID, optional A3 Originating ID 18
and CE ID to be associated with the specified cell. The source BS and target 19
BS save the association of CE ID, Traffic Circuit ID, with Cell ID(s). The 20
source BS also saves the A3 Originating ID value, to be included in 21
subsequent A3 messages to the target BS. The target BS starts timer Tconn3. 22
This is only done at the initial burst. 23
d. The source BS responds with an A3 Connect Ack message to complete the A3 24
connection. This may include an A3 Originating ID value assigned by the 25
source BS, which is included by the target BS in subsequent A3 messages to 26
the source BS. The target BS stops timer Tconn3. 27
3GPP2 A.S0013-0 v2.0
Section 3 225
e. The target BS sends A7-Handoff Request Ack messages to the source BS to 1
complete the A3 traffic circuit connection setup procedure for the specified set 2
of cells. This may include an A7 Originating ID value assigned by the target 3
BS, which is included by the source BS in subsequent A7 messages to the 4
target BS for this call association. Upon receipt of the A7-Handoff Request 5
Ack message, the source BS stops timer Thoreq. 6
f. The source BS sends an A7-Burst Request to the target BS to request the 7
reservation of the needed radio resources at one or more cells for the 8
Supplemental Channel. The source BS starts timer Tbstreq. Note that the 9
source BS may send an A7-Burst Request to the target BS at any time after 10
receiving the A3-Connect message in step c, and that the set of cells may be a 11
subset of the cells assigned in steps a-e. 12
g. The target BS determines that it can reserve part or all of the requested 13
resources and sends A7-Burst Response message(s) to the source BS 14
indicating the resources that have been reserved and committed to the traffic 15
burst, and the cause value for any uncommitted cells. Each A7-Burst 16
Response message can contain up to one committed cell and multiple 17
uncommitted cells. Each reservation includes a physical Channel Element. 18
Note that the physical Channel Element may be allocated any time after step 19
(b). The target BS starts timer Tbstcom. The source BS stops timer Tbstreq. 20
h. The source BS makes a final decision on the resources using the A7-Burst 21
Response information from the target BSs, associates a frame selector with the 22
physical channel, and sends an A7-Burst Commit message to the target BS 23
indicating the cell resources to be used for the traffic burst. Upon receipt of 24
the A7-Burst Commit message, the target BS stops time Tbstcom. Note that the 25
source BS may allocate the frame selector any time after step (b). The target 26
BS sets up the burst. 27
Note that the source BS is not required to wait for all A7-Burst Responses 28
before committing the burst, but it shall not send A7-Burst Commit for a 29
given cell until after receiving the corresponding A7-Burst Response for that 30
cell. 31
i. The source BS commands the MS to prepare for the traffic burst via an 32
Extended Supplemental Channel Assignment Message (ESCAM). 33
j. The MS acknowledges the command from the source BS with a Layer 2 Ack. 34
If the handoff direction message is sent using quick repeats, the source BS 35
might not request an acknowledgment from the MS. 36
k. The network and MS exchange forward and/or reverse traffic burst 37
information for the specified duration, or until the source BS or target BS 38
terminates or extends the traffic burst. 39
l. The source BS sends an A3-Physical Transition Directive message if the old 40
Power Control Mode is to be restored when the burst ends. This step may 41
occur anytime after step h. 42
3.19.3.2.5 Subsequent Traffic Burst Example 43
The following example describes the support of a traffic burst when the A3 connection 44
for the Supplemental Channel (SCH) has already been established. Note that this could be 45
the initial data burst if the A3 connection for the SCH was established previously via the 46
A7-Handoff Request procedure. 47
3GPP2 A.S0013-0 v2.0
Section 3 226
Source BS Target BSMS
A7- Burst Request
A7- Burst Commit
b
c
d
Time Comment
Tbstcom
e
f
g
Forward and/or reverse traffic burst
ESCAM
Layer 2 Ack
SCRM Msg
PDSN
(data to be sent)a
A7- Burst Response
Tbstreq A7- Burst ResponseTbstreq
TbstcomA7- Burst Release
h
i 1
Figure 3.19.3.2.5-1 Subsequent Traffic Burst Example 2
a. Either the source BS receives an indication from the MS (via a Supplemental 3
Channel Request Message (SCRM)) or from the network (via data being 4
received from the PDSN) that data needs to be sent to/from the MS. 5
b. The source BS decides a traffic burst is required on one or more cells for 6
which an A3 connection already exists in support of a Supplemental Channel. 7
The source BS sends an A7-Burst Request to the target BS to request the 8
reservation of the needed radio resources for the Supplemental Channel. The 9
source BS starts timer Tbstreq. 10
c. The target BS determines that it can reserve part or all of the requested 11
resources at some of the cells and sends A7-Burst Response message(s) to the 12
source BS indicating the resources that have been reserved and committed to 13
the traffic burst, and the cause value for any uncommitted cells. Each A7-14
Burst Response message can contain up to one committed cell and multiple 15
uncommitted cells. Each reservation includes a physical Channel Element. 16
Note that the physical Channel Element may be allocated any time after step 17
(b). The target BS starts an instance of timer Tbstcom for each committed cell. 18
d. Upon receipt of the last A7-Burst Response message accounting for all 19
requested cells, the source BS stops timer Tbstreq. 20
e. The source BS makes a final decision on the resources using the A7-Burst 21
Response information from the target BSs, associates a frame selector with the 22
physical channel, and sends A7-Burst Commit messages to each target BS for 23
each cell chosen to support the traffic burst, indicating the cell resources to be 24
used for the traffic burst. In this scenario, the source BS decides to use the 25
resources reserved by the target BS. Upon receipt of the A7-Burst Commit 26
message for a given cell, the target BS stops the corresponding timer Tbstcom 27
and sets up the burst. Note that the source BS may allocate the frame selector 28
any time after step (b). 29
Note that the source BS is not required to wait for all A7-Burst Responses 30
before committing the burst, but it shall not send A7-Burst Commit for a 31
given cell until after receiving the corresponding A7-Burst Response for that 32
cell. 33
3GPP2 A.S0013-0 v2.0
Section 3 227
Refer to the call flow in section 3.19.3.2.6 for any reserved resources that are 1
not used for the traffic burst. 2
f. The source BS sends A7-Burst Release message(s) to target BS(s) for cells 3
that reserved resources but that will not be used to support the burst. Upon 4
receipt of A7-Burst Release for a given cell, the target BS stops the 5
corresponding timer Tbstcom. The target BS frees the reserved resources. 6
Note that the source BS is not required to wait for all A7-Burst Responses 7
before committing the burst, but it shall not send A7-Burst Release for a given 8
cell until after receiving the corresponding A7-Burst Response for that cell. 9
g. The source BS commands the MS to prepare for the traffic burst via an 10
Extended Supplemental Channel Assignment Message (ESCAM). 11
h. The MS acknowledges the command from the source BS with a Layer 2 Ack. 12
If the handoff direction message is sent using quick repeats, the source BS 13
might not request an acknowledgment from the MS. 14
i. The network and MS exchange forward and/or reverse traffic burst 15
information for the specified duration, or until the source BS or target BS 16
terminates or extends the traffic burst. 17
3.19.3.2.6 Source BS Releases Reserved Resources 18
The following example describes how the source BS releases resources reserved at the 19
target BS for a cell that will not be used to support the burst. 20
Source BS Target BS
A7- Burst Request
A7- Burst Response
A7- Burst Release
b
c
Time Comment
Tbstreq
Tbstcom
a
21
Figure 3.19.3.2.6-1 Source BS Releases Reserved Resources 22
a. The source BS sends an A7-Burst Request to the target BS to request the 23
reservation of the needed radio resources for the Supplemental Channel. The 24
source BS starts timer Tbstreq. 25
b. The target BS determines that it can reserve part or all of the requested 26
resources and sends A7-Burst Response message(s) to the source BS 27
indicating the resources that have been reserved and committed to the traffic 28
burst, and the cause value for any uncommitted cells. The target BS starts a 29
timer Tbstcom for each A7-Burst Response message sent. Upon receipt of the 30
last A7-Burst Response, the source BS stops timer Tbstreq. 31
c. In this scenario, the source BS decides not to use the resources reserved by the 32
target BS. The source BS sends A7-Burst Release(s) for the reserved cell(s) 33
that are not used for the traffic burst. Upon receipt of each A7-Burst Release 34
message, the target BS stops the timer Tbstcom corresponding to the indicated 35
cell(s) and releases its resources. 36
3GPP2 A.S0013-0 v2.0
Section 3 228
3.19.3.2.7 Early Burst Termination Initiated by Source BS 1
The following example describes how the source BS terminates a burst in progress. 2
Source BS Target BS
A7- Burst Commit
A7- Burst Release
b
c
Time Comment
a
Forward and/or reverse traffic burst
MS
3
Figure 3.19.3.2.7-1 Early Burst Termination Initiated by Source BS 4
a. The source BS sends A7-Burst Commit messages to all target BSs indicating 5
the set of committed resources that are actually used for the traffic burst. The 6
target BS sets up the burst. 7
b. The network and MS exchange forward and/or reverse traffic burst 8
information. 9
c. While the burst is in progress, the source BS decides to terminate the burst 10
early at one or more cells. The source BS sends A7-Burst Release to the cells 11
which are to terminate the burst. The target BS releases all resources 12
associated with the burst. 13
3.19.3.2.8 Early Burst Termination Initiated by Target BS 14
The following example describes how the target BS terminates a burst in progress. 15
Source BS
Target BS
A7- Burst Release b
Time Comment
a Forward and/or reverse traffic burst
MS
16
Figure 3.19.3.2.8-1 Early Burst Termination Initiated by Target BS 17
a. The network and MS exchange forward and/or reverse traffic burst 18
information. 19
b. While the burst is in progress, the target BS decides to terminate the burst 20
early at one or more cells. The target BS sends A7-Burst Release(s) for the 21
cells which are being removed from the burst. The source BS releases all 22
resources associated with the cells that are being removed from the burst. If 23
there are other cells supporting the SCH, then the burst continues on those 24
cells. 25
3.19.4 Fast Handoff Call Flows 26
This section describes call flows for Fast Handoff. Refer to section 2.19.4 for more 27
information on this feature. 28
3GPP2 A.S0013-0 v2.0
Section 3 229
3.19.4.1 Anchor PDSN Reachable from Target PCF 1
This call flow shows the case of an initial fast handoff (source PDSN is the same as the 2
anchor PDSN) where the target BS/PCF is able to reach the anchor PDSN because the 3
target BS/PCF is in the same PDSN selection domain as the anchor PDSN. 4
Source BSC
Handoff Required
Handoff Request
Source PCF
A9-Setup-A8
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
Handoff Completion
A9-AL Connected A9-AL-Connected Ack
Handoff Complete
Clear Command
A9-Release-A8 A9-Release-A8 Complete
Clear Complete
MS Ack Order
BS Ack Order
Target PCF
A9-AL Disconnected A9-AL Disconnected Ack
a
b
d
e
c
f
g
h
i
m
l
k
j
A11-Registration Request A11-Registration Reply
n
o
p
q
s
r
t
u
A11-Registration Update A11-Registration Acknowledge A11-Registration Request A11-Registration Reply
A11-Registration Request A11-Registration Reply
v
x
Twaitho
MS Target BSC MSC Anchor PDSN
A9-Connect-A8
5
Figure 3.19.4.1-1 Anchor PDSN Reachable From Target PCF 6
3GPP2 A.S0013-0 v2.0
Section 3 230
a. User data flow is active using a PPP session between the mobile station and 1
the currently source/anchor PDSN. During the setup of the A10 connection, 2
the source/anchor PDSN returned its Anchor P-P Address in the A11-3
Registration Reply to the source PCF. The source PCF in turn relayed both the 4
anchor PDSN address and the anchor P-P address to the source BS. Note that 5
if the source PDSN was not the same as the anchor PDSN, then a P-P 6
connection would exist between the source PDSN and the anchor PDSN. 7
b. Based on an MS report that the MS crossed a network specified threshold for 8
signal strength, changes to a different ANID, or for other reasons, the source 9
BS recommends cdma2000 to cdma2000 hard handoff to one or more cells in 10
the domain of the target BS. The source BS sends a Handoff Required 11
message with the list of cells to the MSC and starts timer T7. The source BS 12
includes the PANID information in the Handoff Required message. It also 13
includes the source PDSN, Anchor PDSN, and Anchor P-P Addresses. 14
15
c. The MSC sends a Handoff Request message (which includes the PANID 16
information previously communicated to the MSC via the Handoff Required 17
message) to the target BS with hard handoff indicator (e.g., Handoff Type 18
element in the message indicating hard handoff). In this message the MSC 19
also relays the Anchor PDSN and Anchor P-P Addresses. Note that the target 20
BS stores the source PDSN, Anchor PDSN, and Anchor P-P Addresses for use 21
in the event that this fast handoff is superseded by another fast handoff. 22
d. The target BS sends an A9-Setup-A8 message to the target PCF in order to 23
establish the A8-Connection and sets timer TA8-Setup. In this case, the 24
handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during 25
handoff). The target BS includes the Current (source) PDSN, Anchor PDSN 26
and Anchor P-P Addresses. The target PCF establishes the A8-Connection. 27
The target PCF sends the A9-Connect-A8 message and starts timer Twaitho9. 28
e. Upon receipt of the A9-Setup-A8 message from the target BS, the target PCF 29
recognizes the presence of the Anchor P-P Address and establishes an A10 30
connection with the anchor PDSN using the Anchor PDSN Address. The 31
lifetime field in the A11-Registration Request in set to Tpresetup, the ‘S’ bit is 32
set to ‘1’ indicating simultaneous binding and the P-P address VSE is attached 33
(indicating Fast Handoff request). The A11-Registration Request also 34
contains the A10 Connection Setup Airlink Record. The PDSN accepts the 35
connection and indicates that the Fast Handoff is accepted by returning the 36
A11-Registration Reply with the same Anchor PDSN and Anchor P-P 37
Addresses. Note that if the source PDSN was not the same as the anchor 38
PDSN, and the anchor PDSN was not reachable from the target BS/PCF, then 39
target PCF connects to the source PDSN, and the existing P-P connection 40
would be reused for the new A10 connection. 41
f. The target PCF returns an A9-Connect-A8 message that includes the current 42
(target) PDSN Address. It also contains the Anchor PDSN and Anchor P-P 43
Addresses to indicate that the Fast Handoff was accepted. When the target BS 44
receives the A9-Connect-A8 message it stops timer TA8-Setup. The target BS 45
sends a Handoff Request Acknowledgment message to the MSC. The target 46
BS starts timer T9 to wait for arrival of the MS on its radio channel. 47
g. At this point in time, PDSN continues to forward packet data to the source BS 48
via source PCF. It also forwards user data down the target PCF, which at this 49
time discards the data. 50
h. The MSC prepares to switch from the source BS to the target BS and sends a 51
Handoff Command to the source BS. The source BS stops timer T7. 52
3GPP2 A.S0013-0 v2.0
Section 3 231
i. The source BS sends an A9-AL (Air Link) Disconnected message to the 1
source PCF. The PCF stops packet transmission to the source BS upon receipt 2
of A9-AL (Air Link) Disconnected from the source BS. At this point in time, 3
the source BS starts timer Tald9. The PCF sends A9-AL (Air Link) 4
Disconnected Ack message as response of A9-AL (Air Link) Disconnected 5
message. The BS stops timer Tald9. 6
j. The source BS sends the General Handoff Direction Message or Universal 7
Handoff Direction Message to the mobile station across the air interface. If the 8
MS is allowed to return to the source BS, then timer Twaitho is started by the 9
source BS. 10
k. The MS may acknowledge the General Handoff Direction Message or 11
Universal Handoff Direction Message by sending an MS Ack Order to the 12
source BS. If the General Handoff Direction Message or Universal Handoff 13
Direction Message is sent using quick repeats, the source BS might not 14
request an acknowledgment from the MS. 15
l. The source BS sends a Handoff Commenced message to the MSC to notify it 16
that the MS has been ordered to move to the target BS channel. The source BS 17
starts timer T306 to await the Clear Command message from the MSC. If 18
timer Twaitho has been started (i.e., return on failure was requested), the 19
source BS shall wait for that timer to expire before sending the Handoff 20
Commenced message. 21
m. The MS sends a Handoff Completion Message to the target BSC. 22
n. The target BS sends the BS Ack Order to the MS over the air interface. 23
o. Upon the receipt of the Handoff Completion message from the MS, the target 24
BS sends A9-AL (Air Link) Connected message to the target PCF and starts 25
timer Talc9. In that message it will include the PANID received previously in 26
the Handoff Requested message. The target PCF stops timer Twaitho9. The 27
target PCF sends the A9-AL (Air Link) Connected Ack as the response of the 28
A9-AL (Air Link) Connected message and stops timer Talc9. If timer Talc9 is 29
expired, the target BS may resend the A9-AL Connect message. However, if 30
timer T9 had expired before the BS receives the A9-AL Connected Ack 31
message, the BS shall send Handoff Failure message to the MSC. Refer to IS-32
2001.3-B for detail procedure. 33
p. The target PCF sends an Active Start Airlink Record to the anchor PDSN in 34
an A11-Registration Request. The A11-Registration Request contains Trp as 35
lifetime and the S bit is cleared. The PDSN sends an A11-Registration Reply 36
to the target PCF. Note: before receipt of the Active Start Airlink Record the 37
PDSN is still transmitting user data stream to the old BS/PCF and the target 38
BS/PCF via the pre-setup A10 connection. On receipt of the Active Start 39
Airlink Record, the target BS/PCF stops discarding user data coming from the 40
PDSN. 41
q. The PDSN now initiates termination the A10 connection(s) to the source PCF 42
as follows: The PDSN sends an A11-Registration Update with lifetime of zero 43
to the source PCF to disconnect the A10 connection. The source PCF sends an 44
A11-Registration Acknowledge to the PDSN. The source PCF sends an A11-45
Registration Request to the PDSN with lifetime zero. The PDSN sends an 46
A11-Registration Reply to the source PCF. The A10 connection is now 47
released. 48
r. Data flows between the anchor PDSN and target PCF. Data no longer flows 49
to or from the source BS/PCF and PDSN. 50
3GPP2 A.S0013-0 v2.0
Section 3 232
s. The target BS sends a Handoff Complete message to the MSC to notify it that 1
the MS has successfully completed the hard handoff. The target BS stops 2
timer T9. 3
t. The MSC sends a Clear Command to the source BSC. The source BS stops 4
timer T306. The MSC starts timer T315. 5
u. The source BS sends an A9-Release-A8 message to the source PCF in order to 6
release the A8 connection and starts timer Tre19. Upon the receipt of the A9-7
Release-A8 message from the source BS, the source PCF releases the A8 8
connection and responds with an A9-Release-A8 Complete message. When 9
the source BS receives the A9-Release-A8 Complete message it stops timer 10
Tre19. 11
v. The source BS sends a Clear Complete message to the MSC to notify it that 12
clearing has been accomplished. The MSC stops timer T315. Clear Complete 13
may occur any time after the service instance is released. 14
3.19.4.2 Anchor PDSN Not Reachable from Target PCF 15
This call flow shows the case of an initial fast handoff (source PDSN is the same as the 16
anchor PDSN) from the source BS/PCF to a target BS/PCF where the target BS/PCF is 17
not able to reach the anchor PDSN because the target BS/PCF is in a different PDSN 18
selection domain than the anchor PDSN. 19
3GPP2 A.S0013-0 v2.0
Section 3 233
MS Source BS MSC
Handoff Required
Handoff Request
Source PCF
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
Handoff Completion
A9-AL Connected A9-AL-Connected Ack
MS Ack Order
BS Ack Order
A9-AL Disconnected A9-AL Disconnected Ack
a
b
d
e
c
f
g
h
i
m
l
k
j
A11-Registration Request A11-Registration Reply
A11-Registration Request A11-Registration Reply
n
o
p
q
r
P-P Registration Request P-P Registration Reply
P-P Registration Request P-P Registration Reply
A11-Registration Update A11-Registration Acknowledge A11-Registration Request A11-Registration Reply
s
x
Twaitho
Target BS Target PCF
Anchor PDSN
Target PDSN
A9-Setup-A8
A9-Connect-A8
1
Figure 2.19.4.2-1 Anchor PDSN Not Reachable From Target PCF 2
3GPP2 A.S0013-0 v2.0
Section 3 234
PDSN Target
PCF
t
v
w
u
x
y
aa
z
Target PDSN
Handoff Complete
Clear Command
A9-Release-A8 A9-Release-A8 Complete
Clear Complete
A11 Registration Request A11 Registration Reply
A9-Release-A8 A9-Release-A8 Complete
Last service instance goes dormant; MN sends Release Order
P-P Registration Request P-P Registration Reply
A9-Setup-A8 A9-Connect-A8
PPP negotiation
A11 Registration Request A11 Registration Reply
bb
cc
ff
gg
hh
dd
ee
ii
MS Source BS Source PCF
Target BS MSC
Origination BS Ack Order
IS-2000 TCH
Establishment procedure
1
Figure 2.19.4.2-1 (Cont.) Anchor PDSN Not Reachable From Target PCF 2
a. User data flow is active using a PPP session between the mobile station and 3
the source/anchor PDSN. During the setup of the A10 connection(s), the 4
source/anchor PDSN returned its P-P address in the A11-Registration Reply 5
message(s). The source PCF in turn relayed both the Anchor PDSN and 6
Anchor P-P Addresses to the source BS. Note that if the source PDSN was 7
not the same as the anchor PDSN, then a P-P connection would exist between 8
the source PDSN and the anchor PDSN. 9
3GPP2 A.S0013-0 v2.0
Section 3 235
b. Based on an MS report that the MS crossed a network specified threshold for 1
signal strength, changes to a different ANID, or for other reasons, the source 2
BS recommends a cdma2000 to cdma2000 hard handoff to one or more cells 3
in the domain of the target BS. The source BS sends a Handoff Required 4
message with the list of cells to the MSC and starts timer T7. The source BSC 5
includes the PANID information in the Handoff Required message. The 6
source BSC supports fast handoff, so it also includes the source PDSN, 7
Anchor PDSN, and Anchor P-P addresses to request fast handoff. 8
c. The MSC sends a Handoff Request message (which includes the PANID 9
information previously communicated to the MSC via the Handoff Required 10
message) to the target BS with hard handoff indicator (e.g., Handoff Type 11
element in the message indicating hard handoff). In this message it relays the 12
source PDSN, Anchor PDSN, and Anchor P–P Addresses. Note that the target 13
BS stores the Anchor PDSN and Anchor P-P Addresses for use in the event 14
that this fast handoff is superseded by another fast handoff. 15
d. The target BS sends an A9-Setup-A8 message to the target PCF to establish 16
the A8-Connection and sets timer TA8-Setup. The handoff indicator field of 17
the A9-Setup-A8 message is set to ‘1’ (during handoff). The target BS 18
includes the Anchor PDSN Address and Anchor P-P Address. Upon receipt of 19
the A9-Setup-A8 message from the target BS, the target PCF determines it 20
cannot establish an A10 connection with the anchor PDSN or with the source 21
PDSN and selects another PDSN, the target PDSN. Note that if the source 22
PDSN was not the same as the anchor PDSN and the source PDSN Address 23
had been reachable, then the call flow in Figure 3.14.4.3.1-1 starting at step e 24
applies. Note that if the Anchor PDSN Address had been reachable, then the 25
target PCF shall select the anchor PDSN to be the target PDSN. At this point, 26
the call flow in Figure 3.14.4.1-1 starting at step e applies and the fast handoff 27
is completed; i.e., the P-P connection(s) are released and no new ones are 28
created. 29
e. The target PCF establishes A10 connections, one for each service instance to 30
be handed off. The lifetime field in the A11 Registration Request in set to 31
Tpresetup, the ‘S’ bit is set to ‘1’ indicating simultaneous binding, and the 32
Anchor P-P Address VSE is included to indicate a fast handoff operation. The 33
A11-Registration Request also includes the A10 Connection Setup Airlink 34
Record. The target PDSN accepts the connection and the fast handoff request 35
by returning the A11-Registration Replies with the same Anchor PDSN and 36
Anchor P-P Addresses it received in the A11-Registration Request. The target 37
PDSN buffers the airlink records as it will need these for accounting purposes 38
after the fast handoff completes (assuming the target PDSN becomes the 39
anchor PDSN at that point in time). Upon receipt of the A11-Registration 40
Reply, the target PCF sends the A9-Connect-A8 message to the target BS. 41
The target PCF indicates acceptance of the fast handoff by including the 42
Anchor PDSN and Anchor P-P Addresses. When the target BS receives the 43
A9-Connect-A8 message it stops timer TA8-Setup. 44
f. The target PDSN establishes a P-P connection with the anchor PDSN for each 45
A10 connection that was setup. P-P establishment is done concurrently with 46
subsequent RAN procedures. The anchor PDSN indicates the PPP service 47
instance to the target PDSN in the PPP Link Indicator extension. 48
g. The target BS sends a Handoff Request Acknowledgment message to the 49
MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio 50
channel. 51
h. The anchor PDSN forwards packet data to the source BS via the source PCF. 52
It also forwards the data over the P-P connection to the target PDSN that, in 53
3GPP2 A.S0013-0 v2.0
Section 3 236
turn, forwards to the target BS via the target PCF. The target BSC discards 1
data received from the target PCF. 2
i. The MSC prepares to switch from the source BS to the target BS and sends a 3
Handoff Command to the source BS. The source BS stops timer T7. 4
j. The source BS sends a A9-AL Disconnected to the source PCF. The PCF 5
sends A9-AL Disconnected Ack message in response to the A9-AL 6
Disconnected message. The BS stops timer Tald9. 7
k. The source BS sends the General Handoff Direction Message or Universal 8
Handoff Direction Message to the mobile station across the air interface. If the 9
MS is allowed to return to the source BS, then timer Twaitho is started by the 10
source BS. 11
l. The MS may acknowledge the General Handoff Direction Message or 12
Universal Handoff Direction Message by sending an MS Ack Order to the 13
source BS. If the General Handoff Direction Message or Universal Handoff 14
Direction Message is sent using quick repeats, the source BS might not 15
request an acknowledgment from the MS. 16
m. The source BS sends a Handoff Commenced message to the MSC to notify it 17
that the MS has been ordered to move to the target BS channel. The source BS 18
starts timer T306 to await the Clear Command message from the MSC. If 19
timer Twaitho has been started (i.e., return on failure was requested), the 20
source BS shall wait for that timer to expire before sending the Handoff 21
Commenced message. 22
n. Upon the receipt of the Handoff Completion message from the MS, the target 23
BS sends A9-AL (Air Link) Connected message to the target PCF and starts 24
timer Talc9. In that message it will include the PANID received previously in 25
the Handoff Requested message. The target PCF stops timer Twaitho9. 26
o. The target BS sends the BSC Ack Order to the MS over the air interface. 27
p. Upon the receipt of the Handoff Completion message from the MS, the target 28
BS sends A9-AL (Air Link) Connected message to the target PCF and starts 29
timer Talc9. In that message it will include the PANID received previously in 30
the Handoff Requested message. The target PCF stops timer Twaitho9. The 31
target PCF sends the A9-AL (Air Link) Connected Ack as the response of the 32
A9-AL (Air Link) Connected message and stops timer Talc9. If timer Talc9 is 33
expired, the target BSC may resend the A9-AL Connect message. However, if 34
timer T9 had expired before the BS receives the A9-AL Connected Ack 35
message, the BS shall send Handoff Failure message to the MSC. Refer to IS-36
2001.3-B for detail procedure. 37
q. The target PCF sends the Active Start Airlink Record to the target PDSN in 38
an. A11-Registration Request that contains Trp as lifetime and ‘S’ bit cleared. 39
r. The target PDSN forwards the Active Start Airlink Record to the anchor 40
PDSN in a P-P Registration Request that likewise has the ‘S’ bit clear. The 41
source PDSN acknowledges this to the target PDSN with a P-P Registration 42
Reply. 43
s. The source PDSN requests the source PCF to disconnect the A10 44
connection(s) upon receipt of the P-P Registration Request by sending A11-45
Registration Update message(s). The source PCF sends a A11-Registration 46
Acknowledge to the source PDSN. The source PCF sends a A11-Registration 47
Request in response with a final Active Stop Airlink Record. The source 48
PDSN acknowledges this with an A11-Registration Reply. Note that if the 49
3GPP2 A.S0013-0 v2.0
Section 3 237
source PDSN was not the same as the anchor PDSN, then the source PDSN 1
also tears down the P-P connection(s) to the anchor PDSN at this time. 2
t. The target BS sends a Handoff Complete message to the MSC to notify it that 3
the MS has successfully completed the hard handoff. The target BS stops 4
timer T9. 5
u. The MSC sends a Clear Command to the source BS. The source BS stops 6
timer T306. The MSC starts timer T315. 7
v. The source BS sends an A9-Release-A8 message to the source PCF in order to 8
release the A8-Connection and starts timer Tre19. Upon the receipt of the A9-9
Release-A8 message from the source BS, the source PCF releases the A8-10
Connection and responds with an A9-Release-A8 Complete message. When 11
the source BS receives the A9-Release-A8 Complete message it stops timer 12
Tre19. 13
w. The source BS sends a Clear Complete message to the MSC to notify it that 14
clearing has been accomplished. The MSC stops timer T315. Clear Complete 15
may occur any time after the service instance is released. 16
x. Data now flows bidirectionally from the anchor PDSN to target PDSN to 17
target PCF and target BS. 18
y. At some point in time, all remaining service instances to the MS are dormant. 19
This is triggered either by releasing a service instance or by a service instance 20
going dormant. 21
z. The target BS sends an A9-Release-A8 to the target PCF for the last service 22
instance that transitioned state. The target PCF acknowledges this with an 23
A9-Release-A8 Complete message. 24
aa. The target PCF sends an A11-Registration Request to the target PDSN with an 25
indication that all service instances are dormant. If the triggering event in step 26
y was a service instance going dormant, this indication shall be sent in the 27
same A11-Registration Request as the final Active Stop Airlink Record for 28
the associated service instance. The ‘S’ bit and the lifetime are set to zero. 29
The target PDSN acknowledges this to the target PCF with an A11-30
Registration Reply. 31
bb. The target PDSN forwards the indication that all service instances are dormant 32
in a P-P Registration Request to the anchor PDSN. The target PDSN includes 33
the Active Stop Airlink Record if it was included in the associated A11-34
Registration Request. The anchor PDSN acknowledges each of these with a P-35
P Registration Reply message and releases the associated P-P connection. 36
cc. At this point, there are no P-P connections between the anchor and target 37
PDSN. The A10 and A8 connections are all intact. 38
dd. After all remaining service instances go dormant, the MS monitors the 39
broadcast channel and detects that the PZID, SID and/or NID have changed. 40
The MS initiates an origination with the DRS bit set to' 0. This step may 41
occur at any time after step y. 42
ee. The target BS establishes an A8 connection by sending an A9-Setup-A8. The 43
target BS responds with A9-Connect-A8. 44
ff. The target BS and the MS initiate the establishment of a radio traffic channel. 45
This brings the MS packet data service instance that supports PPP control 46
messages to the active state. 47
48
3GPP2 A.S0013-0 v2.0
Section 3 238
gg. Triggered by the A9-Connect-A8, the target PCF sends an A11-Registration 1
Request with an Active Start Airlink Record to the target PDSN and Lifetime 2
= Trp. The target PDSN uses this airlink record with an A10 Connection 3
Setup Airlink Record it previously stored to correct carry out accounting 4
procedures. 5
hh. PPP negotiation occurs. 6
ii. Data now flows bidirectionally from the target (now the anchor) PDSN to 7
target BS/PCF (now e anchor BS/PCF). 8
3.19.5 Intergeneration Packet Data Handoff 9
Throughout this section it is assumed that that MS is capable of supporting both 3G and 10
2G packet data services and both air interfaces as defined in [1-6] and [10]. 11
3.19.5.1 Hard Handoff from 2G System to 3G System 12
The mobile is engaged in a 2G packet call on the 2G system. The packet data call needs 13
to be re-established on the 3G side, since 2G packet data service is not supported on the 14
3G system. It is assumed that the 2G BS instructs the mobile to reconnect the packet data 15
service upon completion of handoff (refer to [23]). After the mobile has been acquired on 16
the 3G BS, the service option is negotiated and changed to 3G packet data service. In this 17
call flow, the box marked “MSC” may represent one or two MSCs. In the case of inter-18
MSC handoff, ANSI-41 signaling is not specified. The message flows between the MSC 19
and the 2G BS are not required. 20
3GPP2 A.S0013-0 v2.0
Section 3 239
MS 2G BS time comment
(Handoff Required)
Handoff Request
a
b
c
d
e
f
Null forward traffic channels Frames
Handoff Request Ack g
h
Handoff Complete
i
k
m
j
PCF
PPP
n
o
q
s
p
r
(Handoff Command)
(Handoff Direction Message)
(MS Ack Order)
(Handoff Commenced)
l Reverse Traffic Channel Preamble or Data
Handoff Completion
(Clear Complete)
(Clear Command)
T9
MSC
BS Ack
3G BS
User Data Transmission
t
PDSN
A9-Setup-A8
A9-Connect-A8 TA8-Setup
A9-AL Connected
A9-AL Connected Ack
u
Talc A10/A11 Establishment Procedures
(Service Option Control Message)
Service Option Reconnect
v
w
1
Figure 3.19.5.1-1 Hard Handoff from 2G System to 3G System 2
3GPP2 A.S0013-0 v2.0
Section 3 240
a. On detection of a condition that a hard handoff is required, the 2G BS sends 1
the equivalent of a Handoff Required message to the MSC with a preferred 2
list of target cells. 3
b. The 2G BS requires the MS to reconnect the packet data service upon 4
successful completion of the hard handoff (refer to [23]). 5
c. The MSC tries each of the elements in the preferred cell list until one cell is 6
found that has an available radio channel. The MSC sends a Handoff Request 7
message to the 3G BS, indicating the Service Option as 2G packet data. 8
d. Upon receipt of the Handoff Request message, 3G BS allocates suitable idle 9
(radio) resources. The BS starts transmitting null TCH data on the forward 10
traffic channel for the mobile. 11
e. The 3G BS sends an A9-Setup-A8 message to the PCF with the Handoff 12
indicator in the A9 Indicators information element set to 1, and starts timer 13
TA8-Setup. 14
f. Upon receipt of the A9-Setup-A8 message, the PCF sends an A9-Connect-A8 15
message to the 3G BS. Upon receipt of the A9-Connect-A8 message, the 3G 16
BS stops timer TA8-Setup. 17
g. The 3G BS returns a Handoff Request Ack message to the MSC with 18
appropriate RF channel information to allow the mobile to be instructed to 19
tune to the new RF channel, and starts timer T9 to wait for the mobile to arrive 20
on the radio channel. The 3G BS indicates the Service Option as 2G packet 21
data. 22
h. Upon receipt of the Handoff Request Ack message from 3G BS, the MSC 23
prepares to switch the call from the 2G BS to 3G BS. The MSC sends the 24
equivalent of a Handoff Command message to the 2G BS containing 25
appropriate RF channel information received from the 3G BS. 26
i. The 2G BS instructs the mobile to handoff by sending a handoff direction 27
message. 28
j. The mobile acknowledges receipt of the handoff direction message. 29
k. Upon receipt of confirmation from the mobile, the 2G BS sends the equivalent 30
of a Handoff Commenced message to the MSC. 31
l. The mobile starts sending reverse TCH frames or preamble data to the 3G BS. 32
m. Upon synchronization of the traffic channel, the mobile sends a Handoff 33
Completion Message to the 3G BS. 34
n. The 3G BS acknowledges receipt of the Handoff Completion Message by 35
sending a BS Ack Order to the mobile. 36
o. The MS attempts to reconnect the packet data service option. Following 37
service negotiation, 3G packet data service is connected. 38
p. The 3G BS sends an A9-AL Connected message to the PCF and starts timer 39
Talc. 40
q. Procedure for establishing A10/A11 connection is performed. 41
r. The PCF sends an A9-AL Connected Ack to the 3G BS. The 3G BS stops 42
timer Talc. 43
s. The 3G BS detects that the mobile has successfully accessed the target and 44
stops timer T9. The 3G BS then sends a Handoff Complete message to the 45
3GPP2 A.S0013-0 v2.0
Section 3 241
MSC indicating successful completion of hard handoff and that the 3G packet 1
data service has been connected. 2
t. The link layer (PPP) connection between the mobile and the PDSN is 3
established and the mobile performs MIP registration (if required) with the 4
packet network. 5
u. User data is exchanged between the mobile and the correspondent node over 6
this A10 connection. 7
v. Upon receipt of Handoff Complete, the MSC initiates release of the MSC 8
resources used in the handoff. MSC then sends the equivalent of a Clear 9
Command message to the 2G BS, informing it of the success of the hard 10
handoff. 11
w. The 2G BS sends the equivalent of a Clear Complete message to the MSC 12
acknowledging success of the handoff. 13
3.19.5.2 Hard Handoff from 3G System to 2G System 14
The mobile is engaged in a 3G packet call on the 3G system. The packet data call needs 15
to be re-established on the 2G side, since 3G packet data service is not supported on the 16
2G system. In this call flow, the box marked “MSC” may represent one or two MSCs. In 17
the case of inter-MSC handoff, ANSI-41 signaling is not specified. The message flows 18
between the MSC and the 2G BS are not required. 19
3GPP2 A.S0013-0 v2.0
Section 3 242
twaitho
Service Option Control Message
MS 3G BS time comment
Handoff Required a
b
c
d
e
f
Null forward traffic channels Frames
g
h
(Handoff Complete)
i
k
m
j
PCF
n
o
q
p
r
Handoff Command
T7
Handoff Direction Message
MS Ack Order
Handoff Commenced
l Reverse Traffic Channel Preamble or Data
(Handoff Completion)
Clear Complete
Clear Command
T315
T306
MSC
(BS Ack)
2G BS PDSN
A9-AL Disconnected
A9-AL Disconnected Ack Tald9
A9-Release A8
A9-Release A8 Ack
t
Trel9
A10/A11 Disconnection Procedures
s
(Handoff Request Ack)
(Handoff Request)
1
Figure 3.19.5.2-1 Hard Handoff from 3G System to 2G System 2
a. On detection of a condition that a hard handoff is required, the 3G BS sends a 3
Handoff Required message to the MSC with a preferred list of target cells, and 4
starts timer T7. 5
b. The 3G BS requires the MS to reconnect the packet data service upon 6
successful completion of the hard handoff (refer to [23]). 7
c. The MSC tries each of the elements in the preferred cell list until one cell is 8
found that has an available radio channel. The MSC sends the equivalent of a 9
Handoff Request message to the 2G BS. 10
3GPP2 A.S0013-0 v2.0
Section 3 243
d. The 2G BS allocates suitable idle (radio) resources. The BS starts transmitting 1
null TCH data on the forward traffic channel for the mobile. 2
e. The 2G BS returns the equivalent of a Handoff Request Ack message to the 3
MSC with appropriate RF channel information to allow the mobile to be 4
instructed to tune to the new RF channel. 5
f. The MSC prepares to switch the call from 3G BS to 2G BS. The MSC sends a 6
Handoff Command message to 3G BS containing appropriate RF channel 7
information received from the 2G BS. Upon receipt of the Handoff Command 8
message, the 3G BS stops timer T7. 9
g. The 3G BS sends an A9-Al Disconnected message to the PCF. The 3G BS 10
starts timer Tald9. 11
h. The PCF sends an A9-AL Disconnected Ack to the 3G BS. The 3G BS stops 12
timer Tald9. 13
i. The 3G BS instructs the mobile to handoff by sending a handoff direction 14
message. If the MS is allowed to return to the 3G BS, then timer Twaitho is 15
started by the 3G BS. 16
j. The mobile acknowledges receipt of the handoff direction message by sending 17
an MS Ack Order message to 3G BS. 18
k. Upon receipt of confirmation from the mobile, the 2G BS sends the equivalent 19
of a Handoff Commenced message to the MSC. 20
l. The mobile starts sending reverse TCH frames or preamble data to the 2G BS. 21
m. Upon synchronization of the traffic channel, the mobile sends the equivalent 22
of a Handoff Completion Message to the 2G BS. 23
n. The 2G BS sends the equivalent of a BS Ack Order to the mobile. 24
o. The 2G BS detects that the mobile has successfully accessed the target and 25
sends the equivalent of a Handoff Complete message to the MSC indicating 26
successful completion of hard handoff and that the 2G packet data service has 27
been connected. 28
p. The MSC initiates release of the MSC resources used in the handoff. MSC 29
sends a Clear Command message to the 3G BS, informing it of the success of 30
the hard handoff, and starts timer T315. The 3G BS stops timers Twaitho and 31
T306 upon receipt of this message. 32
q. The 3G BS sends an A9-Release A8 message to the PCF and starts timer Trel9. 33
r. The PCF sends an A9-Release A8 Ack to the 3G BS; the 3G BS stops timer 34
Trel9. 35
s. The 3G BS sends a Clear Complete message to the MSC acknowledging 36
success of the handoff. MSC stops timer T315 on receipt of the Clear 37
Complete message. 38
t. The A10 connection is released following expiration of the Lifetime timer 39
(Trp) or other events internal to the PDSN. 40
3GPP2 A.S0013-0 v2.0
Section 3 244
3.19.5.3 Intra-PCF Hard Handoff from 3G System to 2G System 1
The mobile is engaged in a 3G packet call on the 3G BS. The 3G BS and the 2G BS are 2
both connected to the same PCF. The message flows between the MSC and the 2G BS 3
and the PCF and the 2G BS are not required. 4
MS 3G BS MSC Time Comment
a
b
c
d
e
f
g
Handoff Required
(Handoff Request)
2G BS
h
j
i
k
l
m
n
T306
T315
Twaitho
x
PCF
(A9-Setup-A8)
(A9-Connect-A8)
(Handoff Request Ack)
Handoff Command
Handoff Direction Message
Handoff Commenced
T7
(Handoff Completion)
(A9-AL Connected)
(A9-AL Connected Ack)
(Handoff Complete)
Clear Command
A9-Release-A8
A9-Release Complete-A8
Clear Complete
MS Ack Order
(BS Ack Order)
o
p
q
r
A9-AL Disconnected
s
A9-AL Disconnected Ack
t
Tald9
Tre19
Service Option Control Message
u
Service OptionReconnect
v
5
Figure 3.19.5.3-1 Intra-PCF Hard Handoff from 3G System to 2G System 6
a. Based on an MS report that it crossed a network specified threshold for signal 7
strength or for other reasons, the 3G BS recommends a hard handoff to one or 8
more cells in the domain of the 2G BS. The 3G BS sends a Handoff Required 9
message with the list of cells to the MSC and starts timer T7. 10
b. The 3G BS requires the MS to reconnect the packet data service upon 11
successful completion of the hard handoff (refer to [23]). 12
3GPP2 A.S0013-0 v2.0
Section 3 245
c. The MSC sends the equivalent of a Handoff Request message to the 2G BS 1
with a hard handoff indicator. 2
d. The 2G BS sends the equivalent of an A9-Setup-A8 message to the PCF. 3
e. The PCF sends the equivalent of an A9-Connect-A8 message to the 2G BS. 4
f. The 2G BS sends the equivalent of a Handoff Request Acknowledgment 5
message to the MSC. The 2G BS waits for the arrival of the MS on its radio 6
channel. 7
g. The MSC prepares to switch from the 3G BS to the 2G BS and sends a 8
Handoff Command to the 3G BS. The 3G BS stops timer T7. 9
h. The PCF stops packet transmission to the 3G BS upon receipt of A9-AL (Air 10
Link) Disconnected message from the 3G BS. At this point in time, the 3G BS 11
starts timer Tald9. 12
i. The PCF sends an A9-AL (Air Link) Disconnected Ack message in response 13
to the A9-AL Disconnected message. The 3G BS stops timer Tald9. 14
j. The 3G BS sends the Handoff Direction Message to the MS across the air 15
interface. If the MS is allowed to return to the 3G BS, then timer Twaitho is 16
started by the 3G BS. 17
k. The MS may acknowledge the Handoff Direction Message by sending an MS 18
Ack Order to the source BS. 19
l. The 3G BS sends a Handoff Commenced message to the MSC to notify it that 20
the MS has been ordered to move to the 2G BS channel. The 3G BS starts 21
timer T306 to await the Clear Command message from the MSC. If timer 22
Twaitho has been started, the 3G BS shall wait for that timer to expire before 23
sending the Handoff Commenced message. 24
m. The MS sends the equivalent of a Handoff Completion message to the 2G BS. 25
n. The 2G BS sends the equivalent of a BSC Ack Order to the MS over the air 26
interface. 27
o. The MS attempts to reconnect the packet data service option. Following 28
service negotiation, 2G packet data service is connected. 29
p. The 2G BS sends the equivalent of an A9-AL (Air Link) Connected message 30
to the PCF. 31
q. The PCF sends the equivalent of an A9-AL (Air Link) Connected Ack to the 32
2G BS. 33
r. The 2G BS sends the equivalent of a Handoff Complete message to the MSC 34
to notify it that the MS has successfully completed the hard handoff and that 35
the 2G packet data service has been connected. 36
s. The MSC sends a Clear Command to the 3G BS, and starts timer T315. The 37
3G BS stops timer T306 upon receipt of this message. 38
t. The 3G BS sends an A9-Release-A8 message to the PCF in order to release 39
the A8-Connection and starts timer Tre19. 40
u. Upon the receipt of the A9-Release-A8 message from the 3G BS, the PCF 41
releases the A8-Connection and responds with an A9-Release-A8 Complete 42
message. Upon receiving A9-Release-A8 message the 3G BS stops timer 43
Tre19. 44
3GPP2 A.S0013-0 v2.0
Section 3 246
v. The 3G BS sends a Clear Complete message to the MSC to notify it that 1
clearing has been accomplished. The MSC stops timer T315. Clear Complete 2
may occur any time after the traffic channel is released. 3
3.19.5.4 Dormant Handoff from 2G System to 3G System 4
The mobile is engaged in a 2G packet call on the 2G system, and is dormant. The packet 5
data call needs to be re-established on the 3G side, since 2G packet data service is not 6
supported on the 3G system. The call flow is identical to the call flow shown in 3.14.7.10 7
Dormant Handoff (Inter-BSC/Inter-PCF) - Mobile served by a different PDSN. 8
3.19.5.5 Dormant Handoff from 3G System to 2G System 9
If a Dormant mobile roams to a 2G system, the procedures on the 3G simply allow for the 10
A10 link to be torn down when the PPP timer expires. Refer to Section 3.17.5.9 Inter-11
PCF Dormant Handoff – Mobile Served by a New Target PDSN. 12
3.20 Security Features 13
This chapter discusses security features supported by the IOS. 14
3.20.1 Authentication and Privacy 15
The following table indicates the requirements for Authentication and Privacy while the 16
MS is idle, during registration, during origination, during termination, and during a call. 17
The table further illustrates whether the authentication is required for the Paging/Access 18
Channel and/or the Traffic Channel. 19
Table 3.20.1-1 Authentication and Voice Privacy Requirements 20
STATE On PAGING/ACCESS On TRAFFIC
While IDLE
Global Challenge N/A N/A
Unique Challenge Required N/A
SSD Update Not Required N/A
Parameter Update (Count) N/A N/A
Voice Privacy On/Off N/A N/A
Data Privacy On/Off Required N/A
During REGISTRATION
Global Challenge Required N/A
Unique Challenge Not Required N/A
SSD Update N/A N/A
Parameter Update (Count) N/A N/A
Voice Privacy On/Off N/A N/A
Data Privacy On/Off N/A N/A
During ORIGINATION
Global Challenge Required N/A
3GPP2 A.S0013-0 v2.0
Section 3 247
STATE On PAGING/ACCESS On TRAFFIC
Unique Challenge N/A (See: During Call)
SSD Update N/A (See: During Call)
Parameter Update (Count) N/A (See: During Call)
Voice Privacy On/Off N/A Required
Data Privacy On/Off N/A Required
During TERMINATION
Global Challenge Required N/A
Unique Challenge N/A (See: During Call)
SSD Update N/A (See: During Call)
Parameter Update (Count) N/A (See: During Call)
Voice Privacy On/Off N/A Required
During CALL
Global Challenge N/A N/A
Unique Challenge N/A Required
SSD Update N/A Required
Parameter Update (Count) N/A Not Required
Voice Privacy On/Off N/A Required
Data Privacy On/Off N/A Required
Data Privacy On/Off N/A Required
1
The assumptions in this specification are: 2
• the BS shall be able to generate the RAND parameter 3
• the MSC shall support BS generated RAND authentication 4
The SSD update procedure involves exchange of the following MSC-BS messages: 5
• SSD Update Request 6
• Base Station Challenge 7
• Base Station Challenge Response 8
• SSD Update Response 9
3.20.1.1 SSD Update Procedure - Successful Case 10
The call flow diagram in Figure 3.15.2.1.1-1 provides an illustration of a Shared Secret 11
Data (SSD) Update procedure. 12
3GPP2 A.S0013-0 v2.0
Section 3 248
MS BS MSCtime comment
SSD Update Message
Base Station Challenge Order
a
b
c
d
SSD Update Request
Base Station Challenge
T3270
Base Station Challenge Confirmation Order
SSD Update Confirmation Order
e
f
g
h
Base Station Challenge Response
SSD Update Response
T3271
1
Figure 3.20.1.1-1 SSD Update - Successful Case 2
a. The MSC sends an SSD Update Request message to the BS to indicate that 3
the Shared Secret Data at the MS needs updating. The update information is in 4
the form of a random number (RANDSSD) that is used by the MS to calculate 5
the new SSD. The MSC starts timer T3270. 6
b. Based on the SSD Update Request message from the MSC, the BS sends the 7
SSD Update message to indicate to the MS that it should update its SSD. 8
c. Upon receipt of the SSD Update message from the BS, the MS uses the 9
RANDSSD as input to the algorithm to generate the new SSD. The MS then 10
selects a 32 bit random number (RANDBS) and sends it to the BS in a Base 11
Station Challenge Order message. 12
d. The BS forwards the Base Station Challenge message to the MSC to verify 13
the new SSD calculated at the MS is the same as the number in the network. 14
The MSC stops timer T3270. 15
e. On reception of the Base Station Challenge message, the MSC uses the new 16
SSD as input to the algorithm to generate the authentication response 17
signature (AUTHBS). The MSC then sends the authentication response 18
signature (AUTHBS) to the BS in the Base Station Challenge Response 19
message. The MSC starts timer T3271. 20
f. Upon receipt of the Base Station Challenge Response message from the MSC, 21
the BS transmits this information in a Base Station Challenge Confirmation 22
Order message to the MS. 23
g. If AUTHBS from the MSC is valid, the MS returns an SSD Update 24
Confirmation Order message to the BS. 25
If AUTHBS from the MSC is invalid, the MS returns an SSD Update 26
Rejection Order message to the BS. 27
3GPP2 A.S0013-0 v2.0
Section 3 249
h. The BS forwards the information in the SSD Update Response message to the 1
MSC. The MSC stops timer T3271. 2
3.20.1.2 Terminal Authentication 3
MS BS MSC time comment
Authentication Challenge Response
Authentication Challenge
a
b
c
d Authentication Response
T3260
Authentication Request
4
Figure 3.20.1.2-1 Terminal Authentication 5
a. The MSC sends the Authentication Request to the BS and starts timer T3260. 6
b. The BS forwards the information (RANDU) to the MS in an Authentication 7
Challenge Message over the air interface. 8
c. The MS computes the result AUTHU based on the specified RANDU and the 9
MS’s SSD. It then returns an Authentication Challenge Response Message to 10
the BS, with the enclosed AUTHU. 11
d. The BS forwards the AUTHU information to the MSC using the 12
Authentication Response message. 13
Upon receipt of the Authentication Response message from the BS, the MSC 14
stops timer T3260. 15
3.20.1.3 Parameter Update 16
This procedure is performed when the MSC is instructed to update the call history count 17
(COUNT) at the MS. 18
The MSC sends a Parameter Update Request message to the BS and starts timer T3220. 19
Upon receiving this message, the BS shall instruct the MS to update its count by sending 20
the Parameter Update Order on a traffic channel. When the MS receives this order, it 21
increments its call history count and responds by sending a Parameter Update 22
Confirmation Order message to the BS. Upon receiving the Parameter Update 23
Confirmation Order message from the MS, the BS shall send the Parameter Update 24
Confirm message to the MSC. Upon receipt of this message, the MSC shall update the 25
call history count and stops timer T3220. 26
3GPP2 A.S0013-0 v2.0
Section 3 250
Time
T3220
a
b
c
d
MS BS MSC
Parameter Update Request
Parameter Update Order
Parameter Update Confirmation Order
Parameter Update Confirm
Comment
1
Figure 3.20.1.3-1 Parameter Update 2
a. When the BS receives the Parameter Update Request from the MSC, it orders 3
the MS to update its call history count. The MSC starts timer T3220. 4
b. When the Parameter Update Order is received by the MS, it increments its call 5
history count. 6
c. MS acknowledges that the call history count has been successfully updated. 7
d. The BS sends the Parameter Update Confirm to the MSC indicating that the 8
MS incremented its call history count. Upon receipt of this message, the MSC 9
updates the call history count. The MSC stops timer T3220. 10
3.20.1.4 Privacy Mode Procedure 11
This section describes the call flow associated with voice privacy activation. 12
If broadcast challenge is not active in the system, then voice privacy cannot be invoked. 13
The privacy mode procedure should be completed either before handoff is initiated or 14
after a handoff operation is complete. 15
Voice Privacy is shown here being invoked during an established call. 16
MS BS MSC
time comment
dPrivacy Mode Complete
aPrivacy Mode Command
Mobile Order
Mobile Responseb
cT3280
17
Figure 3.20.1.4-1 Privacy Mode Procedure 18
3GPP2 A.S0013-0 v2.0
Section 3 251
a. The MSC at any point during the call following the receipt of the Assignment 1
Complete message may send the Privacy Mode Command message to the BS 2
to specify that privacy is to be provided for traffic information. The MSC then 3
starts timer T3280. 4
b. After the radio traffic channel has been acquired, voice privacy can be 5
established when the BS transmits a voice privacy request order to the MS. 6
c. The MS performs the required privacy mode procedures and acknowledges 7
the BS with a voice privacy response order. 8
d. The BS returns the Privacy Mode Complete message to the MSC to indicate 9
successful receipt of the Privacy Mode Command message. 10
The MSC stops timer T3280 upon receipt of the Privacy Mode Complete 11
message. 12
3.21 Flex Rate 13
This feature utilizes the same call flows as soft/softer handoff using direct BS-to-BS 14
signaling. Refer to section 3.19.3.2. 15
3.22 Status Inquiry 16
This section describes the call flow associated with Status Inquiry. 17
3.22.1 Status Inquiry Example 18
The following call flow diagram provides an illustration of the status inquiry procedure. 19
MS BS MSC time comment
a
c
Status Request
Status Response
Status Response Message
Status Request Message b
d
T3272
20
Figure 3.22.1-1 Status Inquiry 21
a. The MSC sends a Status Request message to the BS to request certain MS 22
capabilities and starts timer T3272. The type of capability information 23
requested is included in the Information Record Requested element. 24
3GPP2 A.S0013-0 v2.0
Section 3 252
b. The BS forwards the request for information to the MS in one of the following 1
CDMA air interface message: 2
1. the Status Request Order on the traffic channel, 3
2. the Status Request Message on the traffic channel or the paging 4
channel. 5
c. The MS returns the requested information to the BS in one of the following 6
CDMA air interface message: 7
1. the Status Message on the traffic channel, 8
2. the Status Response Message on the traffic channel or the access 9
channel. 10
d. The BS, in turn, returns the requested information in the MS Information 11
Records element of the Status Response message. The MSC stops timer T3272. 12
3.23 3X Multi-Carrier Operation 13
This section describes how 3X Multi-Carrier Operation can be implemented using 14
existing messages and information elements. 15
3.23.1 Hard Handoff Support 16
The following messages are impacted: 17
Handoff Request: IS-2000 Channel Identity 3X information element is sent in place of 18
the IS-2000 Channel Identity information element. 19
Handoff Request Acknowledge: IS-2000 Channel Identity 3X information element is 20
sent in place of the IS-2000 Channel Identity information element. 21
Handoff Command: IS-2000 Channel Identity 3X information element is sent in place 22
of the IS-2000 Channel Identity information element. 23
3.23.2 Soft Handoff Support 24
The following messages are impacted: 25
A7 Handoff Request: In the Physical Channel Info information element, the AFRCN 26
field refers to the center 3X frequency. Indication of the use of 3X Multi-Carrier is 27
contained in the IS-2000 Service Configuration Record. 28
A7 Burst Response: In the Forward Burst Radio Info information element, the SR3 Incl 29
bit should be set to ‘1’, and the proper QOF Mask and Forward Code Channel 30
information coded for all three carriers. 31
A7 Burst Commit: In the Forward Burst Radio Info information element, the SR3 Incl 32
bit should be set to ‘1’, and the proper QOF Mask and Forward Code Channel 33
information coded for all three carriers. 34
A3 Connect: In the A3 Connect Information information element, for each cell record 35
the SR3 Incl bit should be set to ‘1’, and the proper QOF Mask and Forward Code 36
Channel information coded for all three carriers. 37
3GPP2 A.S0013-0 v2.0
Section 3 253
3.24 5 ms Messaging 1
This section outlines how support for 5 ms messaging is supported. 2
3.24.1 Forward Link 3
When a 5 ms message is to be sent to an MS that is in soft handoff, the source BS 4
includes the message in either an A3-FCH Forward Traffic Frame or an A3-DCCH 5
Forward Traffic frame, depending on which physical channel the message is being sent. 6
The Air Interval Content Mask field of the FCH/DCCH Forward Air Interval Control 7
information element indicates in which 5 ms slot the message is to be sent. The source 8
BS may send up to four 5 ms messages in one traffic frame. The source BS may also 9
include a 20 ms data frame in the traffic frame. If this data frame is included, the 5 ms 10
message(s) is (are) punctured into the correct 5 ms slot(s) during the 20 ms frame 11
transmission. 12
3.24.2 Reverse Link 13
When a 5 ms message is received from an MS that is in soft handoff, the target BS 14
includes the message in either an A3-FCH Reverse Traffic Frame or an A3-DCCH 15
Reverse Traffic frame, depending on which physical channel the message was received. 16
The Air Interval Content Mask field of the FCH/DCCH Reverse Air Interval Control 17
information element indicates in which 5 ms slot the message received. The target BS 18
may receive up to four 5 ms messages in one traffic frame. The target BS shall also 19
include a 20 ms data frame in the traffic frame, if this traffic was received in addition to 20
the 5 ms message(s) during the 20 ms interval. 21
3.25 Enhanced Rate Adaptation Mode (ERAM) 22
This feature utilizes the same call flows as soft/softer handoff using direct BS-to-BS 23
signaling. Refer to section 3.19.3.2.. 24
3.26 Code Combining Soft Handoff (CCSH) 25
This feature utilizes the same call flows as soft/softer handoff using direct BS-to-BS 26
signaling. Refer to section 3.19.3.2.. 27
3.27 Rescue Channel 28
This section describes call flows for the Rescue Channel feature. 29
Upon reception of 12 consecutive bad frames, a mobile station disables its transmitter. 30
After a configurable period of time, the mobile autonomously promotes one or more 31
eligible rescue cells from its neighbor set to its active set, re-enables it transmitter, and 32
starts sending reverse traffic frames and an EPSMM flagging the newly promoted 33
pilot(s). 34
Upon recognition that the mobile has stopped transmitting, the source BS selects a rescue 35
cell candidate(s) based on the mobile’s neighbor list, last reported EPSMM, and possibly 36
other factors, and initiates soft handoff addition procedures to prepare the target rescue 37
cell(s) to acquire the mobile. The rescue A3 connection is activated when the A7 Handoff 38
Request message is received at the target. The message indicates that a call rescue 39
3GPP2 A.S0013-0 v2.0
Section 3 254
procedure is requested and that the target BS shall not transmit forward frames until the 1
mobile is acquired. The target BS indicates with the A7 Handoff Request Ack message if 2
the rescue procedure can be supported. If it can, the target base station begins listening 3
for the mobile on the frequency indicated in the A7 Handoff Request. When the mobile 4
re-enables its transmitter and sends an EPSMM, the source BS examines the EPSMM to 5
determine if any of the rescue cell(s) it selected matches any cell(s) the MS autonomously 6
promoted into the active set. 7
If the EPSMM indicates that none of the rescue cells selected by the source BS was 8
autonomously promoted into the active set by the MS, the source BS adds a soft handoff 9
leg(s) to the target BS for the cell that was promoted by the MS, and releases the handoff 10
leg(s) for the previously added rescue cell(s). The target rescue cell is instructed to begin 11
transmitting forward frames immediately since the mobile is already listening for its 12
transmission. 13
Once the mobile is successfully recovered, the call shall be moved from the rescue 14
channel on to a normal traffic channel on the rescue cell to make the rescue channel 15
available for other rescue attempts. Soft handoff legs to any other potentially strong 16
neighbors may also be added, while any weak cells may be removed. If despite rescue 17
attempts from the network, a call fails to be recovered, normal call failure processing 18
shall occur. The following call flows describe these rescue channel procedures. 19
3.27.1 Rescue Channel – Network and MS Select the Same Rescue 20
Cell(s) 21
In this call flow, the source BS correctly selected at least one rescue cell autonomously 22
promoted to the active set by the MS. Note: forward/reverse frames between the source 23
and target BS in the call flow represent A3-IS-2000 FCH Forward/Reverse messages. 24
3GPP2 A.S0013-0 v2.0
Section 3 255
M S Target BS tim e com m ent
b
c
a
d
Source BS
Active Voice Call
EN LUM M essage
Reverse T raffic Frames/EPSM M
e
f
g
h
i
j
k
Forward T raffic Frames
A7 H andoff Request
A7 Handoff Request Ack
H andoff Direction M sg
A7-D rop Target Ack
Reverse Traffic Frames/EPSM M
A3-IS-2000 FCH Forward (H andoff Direction).
M S Ack Order
H andoff Completion M sg
BS Ack O rder
M SC
Reverse Frames
H andoff Performed
Forward Traffic Frames
l
m
n
o
p
q
r
s
Soft/Softer Handoff Addition Procedure
Reverse Traffic Frames
A7-Drop T arget
-----conditional
M S stops T ransmitting
T drptgt
A7-D rop Target Ack
A7-Drop T arget
T drptgt
t
u
T horeq
1
Figure 3.27.1-1 Rescue Channel – Network and MS Select the Same Rescue Cell(s) 2
a. The MS is engaged in an active voice call with the network. 3
b. The source BS sends an Extended Neighbor List Update Message (ENLUM) 4
to the MS, which includes the rescue channel parameters. Note: if the MS has 5
not yet received an ENLUM, the MS uses the rescue channel parameters 6
received in the Universal Neighbor List Message (UNLM), General Neighbor 7
List Message (GNLM), or Extended Neighbor List Message (ENLM). 8
c. The MS receives a predetermined number of frames of insufficient signal 9
quality and disables its transmitter. 10
3GPP2 A.S0013-0 v2.0
Section 3 256
d. The source BS detects a loss of transmission from the MS. The source BS 1
selects one or more rescue cell candidates for the MS based on the mobile’s 2
neighbor list, current active set, and possibly other factors. The source BS 3
sends an A7-Handoff Request message to the target BS indicating that a 4
rescue cell is required. The message includes the cell ID(s) of one or more 5
rescue cell candidates selected by the source BS, and the Rescue Request Info 6
IE. The transmit flag in the element is set to ‘0’ instructing the target BS not 7
to transmit forward frames until the MS is acquired. The source BS starts 8
timer Thoreq. 9
e. The source BS begins sending forward traffic frames to the target BS to 10
synchronize the A3 rescue link. 11
f. The target BS begins sending reverse idle frames to the source BS as soon as 12
the first forward frame is received to synchronize the A3 rescue link. The 13
target BS sends reverse traffic frames if it has already acquired the mobile. 14
g. The target BS sends an A7-Handoff Request Ack message to the source BS to 15
acknowledge if a rescue procedure can be supported. If the target BS can 16
support the rescue procedure, it attempts to acquire the MS on the selected 17
rescue cell(s).The source BS stops timer Thoreq. 18
h. After a configurable period of time (as specified in the 19
ENLUM/UNLM/GNLM/ENLM), the MS re-enables its transmitter. The 20
target BS begins receiving reverse frames from the MS. 21
i. The target BS starts transmitting forward traffic frames to the MS over the 22
rescue channel(s) as soon as the MS is acquired. 23
j. The target BS sends reverse traffic frames and EPSMM to the source BS. The 24
EPSMM indicates that at least one rescue cell selected by the source BS was 25
autonomously promoted by the MS to the active set. 26
k. For any rescue cells that were both successfully selected by the source BS and 27
autonomously promoted into the active set by the MS, the source BS performs 28
soft/softer handoff addition procedure(s) to add a normal traffic channel onto 29
each of those rescue cells (rescue A3 connections and rescue channels remain 30
active). For any cell(s) that the MS autonomously promoted into the active set 31
that the source BS did not select, the source BS performs soft handoff addition 32
procedures using normal traffic channels in order sync up with the current 33
active set. 34
l. For any rescue cell(s) selected by the source BS that was not autonomously 35
promoted into the active set by the MS, the source BS sends an A7-Drop 36
Target to the target BS to indicate that the rescue channel is no longer needed. 37
The target BS deactivates the A3 rescue channel, but the A3 traffic connection 38
remains connected for future rescue attempts. The source BS starts timer 39
Tdrptgt. 40
m. The target BS sends an A7-Drop Target Ack message to the source BS to 41
acknowledge release of the specified cell. The source BS stops timer Tdrptgt. 42
n. The source BS sends a Handoff Direction message in the A3-IS-2000 FCH 43
Forward message to the target BS. 44
o. The target BS sends the Handoff Direction message to the MS to sync up the 45
active sets and move the MS off the rescue channel. 46
p. The MS acknowledges receipt of the message with an MS Ack Order. 47
3GPP2 A.S0013-0 v2.0
Section 3 257
q. The MS indicates successful results of processing the Handoff Direction 1
message by responding with a Handoff Completion message. 2
r. The target BS responds with a BS Ack Order. 3
s. The source BS may send a Handoff Performed message to the MSC 4
(conditional, refer to section 3.14.3.1). The Handoff Performed message may 5
be sent at any time after the Handoff Completion message is received at the 6
BS. 7
t. The source BS sends an A7-Drop Target message to the target BS(s) to 8
request release of the rescue channel(s) used to recover the call. The source 9
BS starts timer Tdrptgt. Note: Rescue A3 traffic connections remain connected 10
for future rescue attempts. 11
u. The target BS sends an A7-Drop Target Ack message to the source BS to 12
acknowledge release of the specified channel(s). The source BS stops timer 13
Tdrptgt. 14
3.27.2 Rescue Channel – Network and MS Selected Different Rescue 15
Cell(s) 16
The MS has disabled its transmitter due to poor quality of forward frames received from 17
the network. The network detects loss of transmission from the MS, which triggers 18
selection and setup of rescue cell candidates. The MS autonomously promotes one or 19
more rescue cells to its active set, re-enables its transmitter, and starts sending reverse 20
traffic frames and an EPSMM reflecting the newly promoted pilots. The EPSMM 21
indicates that none of the rescue cells selected by the source BS match those 22
autonomously promoted to the active set by the MS. The MS selected a rescue cell(s) 23
from the target BS2. Note: forward/reverse frames between the source and target BS in 24
the calls flow represent the A3-IS-2000 FCH Forward/Reverse messages. 25
3GPP2 A.S0013-0 v2.0
Section 3 258
M S T -BS1 time comment
b
c
a
d
S-BS
R escue Channel Setup: 2 .23.1 (d-g)
R everse Traffic Frames/EPSM M
e
f
g
h
i
j
k
Reverse Traffic Frames
M SC
Forward Traffic Frames
l
m
n
Rescue Channel R elease: 2.23.1 (k-u)
R everse Traffic Frames
Forward Traffic Frames
A7 Handoff Request
A7 Handoff R equest Ack
Reverse Frames
T -B S2
A7-Drop Target
A7-Drop Target Ack
Reverse Traffic Fram es/EPSM M
A3-Traffic Channel Status
M S stops Transm itting
o
Forward Traffic Frames
Tdrptgt
Thoreq
1
Figure 3.27.2-1 Rescue Channel – Network and MS Selected Different Rescue Cells 2
a. The MS receives a predetermined number of frames of insufficient signal 3
quality and disables its transmitter. 4
b. The source BS initiates a rescue channel procedure with the target BS1 as 5
described in section 3.27.1, steps (d)-(g). The target BS1 is listening for the 6
MS, but is not transmitting over the air. 7
c. After a configurable period of time (as specified in the 8
ENLUM/UNLM/GNLM/ENLM), the MS re-enables its transmitter. The 9
source BS and/or target BS1 begin receiving reverse frames from the MS. 10
d. The target BS1 starts transmitting forward traffic frames to the MS over the 11
rescue channel(s) as soon as the MS is acquired. 12
e. The target BS1 sends reverse traffic frames and EPSMM to the source BS. 13
The EPSMM indicates that no rescue cell(s) selected by the source BS 14
matched a cell(s) autonomously promoted to the active set by the MS. The MS 15
promoted a rescue cell(s) from the target BS2. 16
f. The source BS sends an A7 Handoff Request messages to the target BS2, 17
indicating that a rescue cell is required and starts timer Thoreq. The message 18
includes the cell ID of one more rescue cell(s) autonomously promoted to the 19
active set by the MS as reported in the EPSMM message. The message also 20
includes the Rescue Request Info IE with the transmit flag set to ‘1’ 21
instructing the target BS2 to begin transmitting forward frames to the MS on 22
3GPP2 A.S0013-0 v2.0
Section 3 259
the rescue channel(s) as soon as synchronization with the source BS is 1
achieved. 2
g. The source BS begins sending forward traffic frames to the target BS2 to 3
synchronize the A3 rescue link. 4
h. The target BS2 begins sending reverse idle frames to the source BS as soon as 5
the first forward frame is received to synchronize the A3 rescue link. Reverse 6
traffic frames are sent if the target BS2 has acquired the mobile. 7
i. The target BS2 sends an A7-Handoff Request Ack message to the source BS, 8
to acknowledge if the rescue procedure can be supported. If the target BS2 can 9
support the rescue procedure, it attempts to acquire the MS on the rescue 10
cell(s). The source BS stops timer Thoreq. 11
j. The target BS2 begins transmitting forward frames to the MS as soon as 12
synchronization with the source BS has occurred. 13
k. If the source BS has chosen to be notified of the start of transmission and 14
reception at the target BS2 when its SDU function and the target BS2 have 15
synchronized the A3 rescue link, the target BS2 replies with an A3-Traffic 16
Channel Status message. Note: this step may occur any time after step (f). 17
l. After acquiring the MS, the target BS2 begins to send reverse traffic frames to 18
the source BS. 19
m. The source BS sends an A7-Drop Target message to the target BS1 to request 20
release of any rescue cell(s) previously added in step (b) that was not 21
autonomously promoted by the MS. Rescue A3 traffic connection is 22
deactivated but remains connected. Note: this step may occur anytime after 23
step (e). 24
n. The target BS1 sends an A7-Drop Target Ack message to the source BS to 25
acknowledge release of the specified cell(s). Note: Rescue A3 traffic 26
connections remain connected for future rescue attempts. 27
o. Rescue channel cleanup procedure occurs – the source BS attempts to sync up 28
the active sets, moves the mobile off the rescue channel, and sends a Handoff 29
Direction message to the MS. Refer to 3.23.1 steps (k)-(u) for the remainder 30
of the call flow. 31
3.28 Terrestrial Circuit Management 32
The following sections describe those procedures involved with the management of 33
terrestrial circuits on the A2, A5, and A3 interfaces. 34
3.28.1 Terrestrial Circuit Management for the A2/A5 Interfaces 35
This section describes Terrestrial Circuit management for the A2 and A5 interfaces. 36
Section 3.28.1.1 describes circuit allocation and deallocation. Section 3.28.1.2 describes 37
blocking and unblocking of terrestrial circuits. Sections 3.28.1.3 and 3.28.1.4 describe 38
resetting of circuits. 39
3.28.1.1 A2/A5 Terrestrial Circuit Allocation 40
The MSC chooses the terrestrial circuit to be used. 41
The Terrestrial Circuit allocation procedure is described in [14]. 42
3GPP2 A.S0013-0 v2.0
Section 3 260
NOTE: There is at least one single logical trunk group serving the BS. 1
3.28.1.2 A2/A5 Terrestrial Circuit Blocking/Unblocking 2
The MSC needs to be informed of any MSC-BS A2/A5 terrestrial circuits that are out of 3
service or that return to service at the BS. The Block or Unblock message is sent by the 4
BS as a connectionless mode message for terrestrial circuits that are out of service or that 5
return to service. Upon receiving a Block or Unblock message, the MSC takes 6
appropriate action and acknowledges the action to the BS. The MSC may locally block a 7
circuit by not choosing it. No information flow across the interface concerning this type 8
of blocking is needed. 9
The following sections describe the operation of blocking and unblocking procedures. 10
3.28.1.2.1 Block Procedure Scenario Diagram 11
Figure 3.24.2.2-1 below shows the Block procedure. 12
Time
a
b
BS MSC
Block Acknowledge
Block
T1
Comment
13
Figure 3.29.1.2.1-1 Block Procedure 14
a. The BS sends the Block message to the MSC with information on the circuits 15
to be blocked. The BS starts timer T1. 16
b. In response to the Block message, the MSC returns a Block Acknowledge 17
message, indicating the involved circuit have been blocked. The BS stops 18
timer T1. 19
3.28.1.2.2 Unblock Procedure Scenario Diagram 20
The diagram in Figure 3.24.2.3-1 shows the Unblock procedure. 21
Time
a
b
BS MSC
Unblock Acknowledge
Unblock
T1
Comment
22
Figure 3.28.1.2.2-1 Unblock Procedure 23
a. The BS sends the Unblock message to the MSC in a request to unblock 24
blocked circuits. The BS starts timer T1. 25
3GPP2 A.S0013-0 v2.0
Section 3 261
b. The MSC marks the circuits as available and sends the Unblock Acknowledge 1
message to the BS. The BS stops timer T1. 2
3.28.1.3 Reset Circuit Procedure 3
The reset circuit procedure is needed to initialize information in the MSC/BS when a 4
failure has occurred affecting only a small part of the equipment and in which the SCCP 5
connection has been released. If the MSC/BS detects that one or more circuits have to be 6
idled due to abnormal SCCP connection release, a Reset Circuit message is sent. Upon 7
receipt of the Reset Circuit message, the receiver idles the indicated circuits and returns 8
an acknowledgment. 9
The following sections describe the operation of the reset circuit procedures. 10
3.28.1.3.1 Reset Procedure at the BS Scenario Diagram 11
The diagram in Figure 3.24.3.1-1 shows the Reset Circuit procedure. 12
Time
a
b
BS MSC
Reset Circuit Acknowledge
Reset Circuit
T12
Comment
13
Figure 3.28.1.3.1-1 A1 Reset Circuit Procedure at the BS 14
a. Once the BS detects that one or more circuits have to be idled, it sends a Reset 15
Circuit message to the MSC with information on the circuit identities and the 16
cause of the reset. The BS starts timer T12 after sending the Reset Circuit 17
message. 18
b. Upon receipt of the Reset Circuit message, the MSC returns a Reset Circuit 19
Acknowledge message to indicate that the circuits have been reset. The BS 20
stops timer T12. 21
3.28.1.3.2 A1 Reset Circuit Procedure at the MSC 22
The diagram in Figure 3.29.1.3.2-1 shows a simple reset circuit procedure initiated by the 23
MSC. 24
Time
a
b
BS MSC
Reset Circuit Acknowledge
Reset Circuit
T12
Comment
25
Figure 3.28.1.3.2-1 A1 Reset Circuit Procedure at the MSC 26
3GPP2 A.S0013-0 v2.0
Section 3 262
a. Once the MSC detects that one or more circuits have to be put to idle, it sends 1
a Reset Circuit message to the BS with information on the circuits and the 2
cause of the reset. The MSC starts timer T12. 3
b. Upon receipt of the Reset Circuit message, the BS returns a Reset Circuit 4
Acknowledge message to indicate that the circuits have been reset. The MSC 5
stops timer T12. 6
3.28.1.3.3 A1 Reset Circuit Procedure at the MSC with BS Block Response 7
The diagram in Figure 3.29.1.3.3-1 shows a reset circuits procedure initiated by the MSC 8
that is responded to from the BS by a Block message. 9
Time
a
b
BS MSC
Block
Reset Circuit
T12
Comment
cBlock AcknowledgeT1
10
Figure 3.28.1.3.3-1 Reset Circuit Procedure at the MSC with BS Block Response 11
a. Once the MSC detects that one or more circuits have to be put to idle, it sends 12
a Reset Circuit message to the BS with information on the circuit identities 13
and the cause of the reset. The MSC starts timer T12. 14
b. If the BS cannot set a circuit to idle it sends the Block message to the MSC 15
with information on the circuit identities to be blocked and the cause of the 16
blocking. The BS starts timer T1. In this example, it is assumed that all of the 17
circuits indicated in the Reset Circuit message need to be blocked. The MSC 18
stops Timer T12 upon receipt of the Block message. 19
c. In response to the Block message, the MSC returns a Block Acknowledge 20
message, indicating the involved circuit have been blocked. The BS stops 21
timer T1 upon receipt of this message. 22
3.28.1.4 Global System Reset 23
The purpose of the global system reset procedure is to cause the initialization of the MSC 24
or BSC in the event of a global failure by its counterpart. Since the type of failure is 25
global, the messages of the procedure are sent as connectionless messages on the A1 26
interface. 27
Upon detection of a global failure or as a result of an initialization, the BSC or MSC 28
sends an A1 global reset message to its counterpart. The counterpart then performs all 29
necessary initialization functions such as: releasing of affected calls and references, idling 30
of circuits, blocking of circuits, and ensuring as necessary that all MSs previously 31
involved in a call are no longer transmitting. After a guard period sufficient to allow all 32
necessary initialization to occur, the counterpart acknowledges the A1 global reset 33
message. 34
3GPP2 A.S0013-0 v2.0
Section 3 263
The following sections describe the call flows involved in the reset procedures. The 1
message structures and the information elements in these messages are described in [14]. 2
3.28.1.4.1 Successful Reset at the MSC 3
This example shows a successful reset procedure when the MSC (re-)initializes. 4
Time
a
b
BS MSC
Reset Acknowledge
Reset
T16
Comment
BS blocks circuits as necessaryusing the blocking procedure.
c
T13
x
5
Figure 3.28.1.4.1-1 Successful Reset at the MSC 6
a. As the MSC (re-)initializes, it sends a Reset message to the BS to notify the 7
BS of the reset procedure it is undertaking. The MSC starts timer T16. The BS 8
starts timer T13. 9
b. The BS may use the circuit blocking procedure to block circuits, as necessary, 10
between itself and the MSC. 11
c. Upon expiration of timer T13, the BS returns a Reset Acknowledge message. 12
The MSC stops timer T16. Both the MSC and BS begin normal operations 13
relative to each other. 14
3.28.1.4.2 Successful Reset at the BS 15
This example shows a successful reset procedure when the BS (re-) initializes. 16
3GPP2 A.S0013-0 v2.0
Section 3 264
Time
a
b
BS MSC
Reset Acknowledge
Reset
T2
Comment
BS blocks circuits as necessaryusing the blocking procedure.
c
T4
x
1
Figure 3.28.1.4.2-1 Successful Reset at the BS 2
a. As the BS (re-) initializes, it sends a Reset message to the MSC to notify the 3
MSC of the reset procedure it is undertaking. The MSC starts timer T2. The 4
BS starts timer T4. 5
b. The BS may use the circuit blocking procedure to block circuits, as necessary, 6
between itself and the MSC. 7
c. Upon expiration of timer T2, the MSC returns a Reset Acknowledge message. 8
The BS stops timer T4. Both the MSC and BS begin normal operations 9
relative to each other. 10
3.28.1.4.3 Reset Glare Noted at the MSC 11
This example shows parallel reset procedures at the BS and MSC. In this case, the MSC 12
notes that a timing condition has occurred since the Reset message from the BS arrives 13
after the Reset message is sent from the MSC. The MSC shall assume that the Reset 14
message it has sent has been lost. As a result, the MSC shall act as though it is not also 15
performing a reset procedure. 16
3GPP2 A.S0013-0 v2.0
Section 3 265
Time
b
c
BS MSC
Reset Acknowledge
Reset
T2
Comment
BS blocks circuits as necessaryusing the blocking procedure.
d
T4
x
aReset
T16
1
Figure 3.28.1.4.3-1 Reset Glare Noted at the MSC 2
a. As the MSC (re-) initializes, it sends a Reset message to the BS to notify the 3
BS of the reset procedure it is undertaking. The MSC starts timer T16. In this 4
example, the Reset message is lost or cannot be successfully processed by the 5
BS. 6
b. As the BS (re-) initializes, it sends a Reset message to the MSC to notify the 7
MSC of the reset procedure it is undertaking. The MSC stops timer T16 and 8
starts timer T2. The BS starts timer T4. 9
c. The BS may use the circuit blocking procedure to block circuits, as necessary, 10
between itself and the MSC. 11
d. Upon expiration of timer T2, the MSC returns a Reset Acknowledge message. 12
The BS stops timer T4. Both the MSC and BS begin normal operations 13
relative to each other. 14
3.28.1.4.4 Reset Glare Noted at the BS 15
This example shows parallel reset procedures at the BS and MSC. In this case, the BS 16
notes that a timing condition has occurred since the Reset message from the MSC arrives 17
after the Reset message is sent from the BS. The BS shall assume that the Reset message 18
it has sent has been lost. As a result, the BS shall act as though it is not also performing a 19
reset procedure. 20
3GPP2 A.S0013-0 v2.0
Section 3 266
Time
b
c
BS MSC
Reset Acknowledge
Reset
T16
Comment
BS blocks circuits as necessaryusing the blocking procedure.
d
T13
x
aReset
T4
1
Figure 3.28.1.4.4-1 Reset Glare Noted at the BS 2
a. As the BS (re-) initializes, it sends a Reset message to the MSC to notify the 3
MSC of the reset procedure it is undertaking. The BS starts timer T4. In this 4
example, the Reset message is lost or cannot be successfully processed by the 5
MSC. 6
b. As the MSC (re-) initializes, it sends a Reset message to the BS to notify the 7
BS of the reset procedure it is undertaking. The BS stops timer T4 and starts 8
timer T16. The BS starts timer T13. 9
c. The BS uses the circuit blocking procedure to block circuits, as necessary, 10
between itself and the MSC. 11
d. Upon expiration of timer T13, the BS returns a Reset Acknowledge message. 12
The MSC stops timer T16. Both the MSC and BS begin normal operations 13
relative to each other. 14
3.28.1.4.5 Reset Glare Noted at Both the MSC and the BS 15
This example shows parallel reset procedures at the BS and MSC. In this case, the Reset 16
messages pass each other en route and are both received. The BS notes that a timing 17
condition has occurred since the Reset message from the MSC arrives after the Reset 18
message is sent from the BS. The BS shall assume that the Reset message it has sent has 19
been lost. As a result, the BS shall act as though it is not also performing a reset 20
procedure. Similarly, the MSC notes that a timing condition has occurred since the Reset 21
message from the BS arrives after the Reset message is sent from the MSC. The MSC 22
shall assume that the Reset message it has sent has been lost. As a result, the MSC shall 23
act as though it is not also performing a reset procedure. 24
3GPP2 A.S0013-0 v2.0
Section 3 267
Time
b
c
BS MSC
Reset Acknowledge
Reset
T16
Comment
BS blocks circuits as necessaryusing the blocking procedure.
d
T13
x
aReset
T4
T2
Reset Acknowledgex e
1
Figure 3.28.1.4.5-1 Reset Glare Noted at Both the MSC and the BS 2
a. As the BS (re-) initializes, it sends a Reset message to the MSC to notify the 3
MSC of the reset procedure it is undertaking. The BS starts timer T4. In this 4
example, the MSC also sends a Reset message due to (re-) initialization and 5
starts timer T16. 6
b. When the BS receives the Reset message, it stops timer T4 and starts timer 7
T13. When the MSC receives the Reset message, it stops timer T16 and starts 8
timer T2. 9
c. The BS uses the circuit blocking procedure to block circuits, as necessary, 10
between itself and the MSC. 11
d. Upon expiration of timer T13, the BS returns a Reset Acknowledge message. 12
The MSC discards the message as an unexpected message. The BS begins 13
normal operations relative to the MSC. 14
e. Upon expiration of timer T2, the MSC returns a Reset Acknowledge message. 15
The BS discards the message as an unexpected message. The MSC begins 16
normal operations relative to the BS. 17
NOTE: Steps (d) and (e) could occur in the reverse order. 18
3.28.2 Terrestrial Circuit Management for the A3 Interface 19
This section contains examples of the A7-Reset procedure, including glare situations. 20
Refer to section 2.28.2 for more information. 21
3.28.2.1 Successful Reset at a BS 22
This example shows a successful A7-Reset procedure when a BS (re)-initializes. 23
3GPP2 A.S0013-0 v2.0
Section 3 268
Time
a
b
SecondBSC
FirstBSC
A7-Reset Acknowledge
A7-Reset
Comment
xT2 T4
1
Figure 3.28.2.1-1 Successful A7-Reset at a BS 2
a. As the first BS (re-) initializes, it sends an A7-Reset message to another 3
(second) BS to notify the second BS of the reset procedure it is undertaking. 4
The second BS starts timer T2. The first BS starts timer T4. 5
b. Upon expiration of timer T2, the second BS returns an A7-Reset 6
Acknowledge message. The first BS stops timer T4. Both BSs begin normal 7
operations relative to each other. 8
3.28.2.2 A7-Reset Glare Noted at the First BS 9
This example shows parallel reset procedures at two BSs. In this case, the first BS notes 10
that a timing condition has occurred since the A7-Reset message from the other (second) 11
BS arrives after the A7-Reset message is sent from the first BS. The first BS shall assume 12
that the A7-Reset message it has sent has been lost. As a result, the first BS shall act as 13
though it is not also performing an A7-Reset procedure. 14
Time
b
c
SecondBSC
FirstBSC
A7-Reset Acknowledge
A7-Reset
T2
Comment
T4
x
aA7-Reset
T4
15
Figure 3.28.2.2-1 A7-Reset Glare Noted at the First BS 16
a. As a (first) BS (re-) initializes, it sends an A7-Reset message to another 17
(second) BS to notify the second BS of the A7-Reset procedure it is 18
undertaking. The first BS starts timer T4. In this example, the A7-Reset 19
3GPP2 A.S0013-0 v2.0
Section 3 269
message is lost or cannot be successfully processed by the second BS, which 1
is itself (re)-initializing. 2
b. As the second BS (re-) initializes, it sends an A7-Reset message to the first BS 3
to notify the first BS of the A7-Reset procedure it is undertaking. The first BS 4
stops timer T4 and starts timer T2. The second BS starts timer T4. 5
c. Upon expiration of timer T2, the first BS returns an A7-Reset Acknowledge 6
message. The second BS stops timer T4. Both the first BS and second BS 7
begin normal operations relative to each other. 8
3.28.2.3 A7-Reset Glare Noted at Both BSs 9
This example shows parallel A7 reset procedures at two BSs. In this case, the A7-Reset 10
messages pass each other en route and are both received. The first BS notes that a timing 11
condition has occurred since the A7-Reset message from the second BS arrives after the 12
A7-Reset message is sent from the first BS. The first BS shall assume that the A7-Reset 13
message it has sent has been lost. As a result, the first BS shall act as though it is not also 14
performing a reset procedure. Similarly, the second BS notes that a timing condition has 15
occurred since the A7-Reset message from the first BS arrives after the A7-Reset 16
message is sent from the second BS. The second BS shall assume that the A7-Reset 17
message it has sent has been lost. As a result, the second BS shall act as though it is not 18
also performing a reset procedure. 19
Time
b
c
FirstBSC
A7-Reset Acknowledge
A7-Reset
T4
Comment
d
T2
x
aA7-Reset
T4
T2
A7-Reset Acknowledgex
SecondBSC
20
Figure 3.28.2.3-1 A7-Reset Glare Noted at Both BSs 21
a. As the first BS (re-) initializes, it sends an A7-Reset message to the second BS 22
to notify the second BS of the reset procedure it is undertaking. The first BS 23
starts timer T4. In this example, the second BS also sends an A7-Reset 24
message due to (re-) initialization and starts timer T4. 25
3GPP2 A.S0013-0 v2.0
Section 3 270
b. When the first BS receives the A7-Reset message, it stops timer T4 and starts 1
timer T2. When the second BS receives the A7-Reset message, it stops timer 2
T4 and starts timer T2. 3
c. Upon expiration of timer T2, the first BS returns an A7-Reset Acknowledge 4
message. The second BS discards the message as an unexpected message. The 5
first BS begins normal operations relative to the second BS. 6
d. Upon expiration of timer T2, the second BS returns an A7-Reset 7
Acknowledge message. The first BS discards the message as an unexpected 8
message. The second BS begins normal operations relative to the first BS. 9
NOTE: Steps (c) and (d) could occur in the reverse order. 10
3.29 Vocoder Support 11
This version of the IOS supports two vocoder types: 12
• 13K (SO=8000H, 0011H) 13
• EVRC (SO=0003H) 14
This section describes the IOS messaging required to support vocoder assignment by the 15
BS. This section pre-supposes the assumptions listed in Section 1.0 of this document. 16
3.29.1 Mobile Originated Calls 17
The following call flow demonstrates the general sequence for vocoder selection for a 18
mobile originated call: 19
3GPP2 A.S0013-0 v2.0
Section 3 271
MS BS MSCTime
Origination
CM Service Request
Assignment Request
Channel Assignment, ServiceNegotiation
Assignment Complete
a
b
c
d
e
T303
T10
fRingback Tone
1
Figure 3.29.1-1 Vocoder Selection – Mobile Originated Case 2
a. MS originates the call by sending an Origination Message to the BS. This 3
message contains the voice service option that the mobile prefers (13K, 4
EVRC). 5
b. BS sends a CM Service Request message to the MSC, containing the service 6
option that was requested by the mobile. The BS starts timer T303. 7
c. Upon receipt of the CM Service Request message, the MSC sends an 8
Assignment Request message to the BS containing the same Service Option 9
that was received in the CM Service Request message. The MSC starts timer 10
T10. 11
d. Upon receipt of the Assignment Request message, the BS stops timer T303 12
and assigns a traffic channel to the MS. Once the traffic channel has been 13
established, the BS and MS negotiate the service option for the voice service. 14
Refer to “Circuit mode voice service assumptions:” in Section 1.0. 15
e. The BS sends an Assignment Complete message to the MSC indicating the 16
service option for the voice call. Upon receipt of the Assignment Complete 17
message, the MSC stops timer T10. 18
f. Voice call is now connected. 19
3GPP2 A.S0013-0 v2.0
Section 3 272
3.29.2 Mobile Terminated Calls 1
The following call flow demonstrates the general sequence for vocoder selection for a 2
mobile terminated call: 3
MS BS MSCTime
Page
Paging Response
Paging Request
Channel Assignment, ServiceNegotiation
Assignment Complete
a
b
c
d
e
Page Response
Assignment Request
f
g
MS Rings, User Answers
Connect
T3113
T303
T10
T301h
i
4
Figure 3.29.2-1 Vocoder Selection – Mobile Terminated Case 5
a. MSC initiates mobile terminated call be sending Paging Request message to 6
the BS. This message contains either the 13K or EVRC voice service option. 7
The MSC starts timer T3113. 8
b. The BS pages the MS with the same Service Option is received in the Paging 9
Request message. 10
c. The MS responds with a Page Response message. This message contains the 11
voice service option (either 13K, EVRC) that the MS prefers. 12
d. Upon receipt of the Page Response message from the MS, the BS sends a 13
Paging Response message to the MSC, including the service option sent by 14
the MS. The BS starts timer T303. 15
e. Upon receipt of the Paging Response message the MSC stops timer T3113. 16
The MSC sends an Assignment Request message to the BS, containing the 17
same service option that was included in the Paging Response message. The 18
MSC starts timer T10. 19
f. Upon receipt of the Assignment Request message, the BS stops timer T303 20
and assigns a traffic channel to the MS. Once the traffic channel has been 21
3GPP2 A.S0013-0 v2.0
Section 3 273
established, the BS and MS negotiate the service option for the voice service. 1
Refer to “Circuit mode voice service assumptions:” in Section 1.0. 2
g. The BS sends an Assignment Complete message to the MSC indicating the 3
service option for the voice call. Upon receipt of the Assignment Complete 4
message, the MSC stops timer T10 and starts timer T301. 5
h. The BS alerts the MS to ring. 6
i. When the user answers the MS, the BS sends a Connect message to the MSC. 7
3.29.3 Service Option Change During Handoff 8
This section describes the scenario for changing vocoder types during a hard handoff. It 9
is assumed that the target BS does not support the vocoder type that the MS is currently 10
using, and that the source BS is aware of the vocoder type(s) supported by the target BS. 11
MS Source BS MSC
Handoff Required
Handoff Request
Handoff Command
Handoff Direction Message
MS Ack Order
Target BS
Null forward traffic channel frames
Handoff Request Ack
T7
T9
Handoff Commenced
Reverse Traffic Channel Frames or Traffic Channel Preamble
Handoff Completion Message
Clear Command
Clear Complete
BS Ack Order Handoff Complete T306
T315
Twaitho
x
Service Connect Message
Service Connect Completion Message
Time
a
b
c
d e f
g
h
i
j
k l m
n
o
T11
p
12
Figure 3.29.3-1 Vocoder Selection – Handoff Case 13
a. Based on an MS report that it crossed a network specified threshold for signal 14
strength or for other reasons, the source BS recommends a hard handoff to one 15
or more cells in the domain of the target BS. The source BS sends a Handoff 16
Required message with the list of cells to the MSC and starts timer T7. The 17
message contains the service option for one of the vocoder types supported by 18
the target BS. 19
b. The MSC sends a Handoff Request message to the target BS with the IS-95 20
Channel Identity element or the IS-2000 Channel Identity element present 21
since the hard handoff bit was set and/or the Handoff Type element in the 22
Handoff Required message indicated hard handoff. The MSC starts timer T11. 23
3GPP2 A.S0013-0 v2.0
Section 3 274
c. Upon receipt of the Handoff Request message from the MSC, the target BS 1
allocates appropriate radio resources as specified in the message and connects 2
the call. As the Handoff Request message can have multiple cell(s) specified, 3
the target BS can also choose to setup multiple cell(s) for the handoff request. 4
The target BS sends null forward traffic channel frames to the MS. 5
d. The target BS sends a Handoff Request Acknowledge message to the MSC. 6
The target BS starts timer T9 to wait for arrival of the MS on its radio channel. 7
The first cell in the cell identifier list element of the message is treated as the 8
new designated cell by the MSC. The change of designated cell occurs upon 9
receipt of the Handoff Complete message. If the service option received in the 10
Handoff Request message is not available at the target BS and the target BS 11
selected a different service option for the handoff then the target BS shall 12
include the service option it selected in the Service Configuration Record IE. 13
e. Upon receipt of the Handoff Request Acknowledge message the MSC stops 14
timer T11. The MSC prepares to switch from the source BS to the target BS 15
and sends a Handoff Command to the source BS. The MSC shall include the 16
service option it received from the Handoff Request Acknowledgement 17
message in the Handoff Command message. The source BS stops timer T7. 18
f. The source BS sends a Service Connect Message to the mobile indicating the 19
new service option for the call. Note this step is only necessary for IS-95-A 20
mobiles; for IS-95-B and cdma2000 mobiles, the service option can be 21
included in the General or Universal Handoff Direction Message. 22
g. The source BS sends the handoff direction message to the MS across the air 23
interface. The action time is set to the same action time as the Service Connect 24
Message (step f). If the MS is allowed to return to the source BS, then timer 25
Twaitho is also started by the source BS. 26
h. The MS may acknowledge the handoff direction message by sending a MS 27
Ack Order to the source BS. 28
If the handoff direction message is sent using quick repeats, the source BS 29
might not request an acknowledgment from the MS. 30
i. The source BS sends a Handoff Commenced message to the MSC to notify it 31
that the MS has been ordered to move to the target BS channel. The source 32
BS starts timer T306 to await the Clear Command message from the MSC. If 33
timer Twaitho has been started, the source BS shall wait for that timer to expire 34
before sending the Handoff Commenced message. 35
j. The MS sends reverse traffic channel frames or the traffic channel preamble to 36
the target cell(s). 37
k. The MS sends a Handoff Completion Message to the target BS. 38
l. The MS sends a Service Connect Completion message to the target BS to 39
complete the change to the new service option. 40
m. The target BS sends the BS Ack Order to the MS over the air interface. 41
n. The target BS sends a Handoff Complete message to the MSC to notify it that 42
the MS has successfully completed the hard handoff. The target BS stops 43
timer T9. 44
o. The MSC sends a Clear Command to the source BS and starts timer T315. 45
The source BS stops timer T306. 46
3GPP2 A.S0013-0 v2.0
Section 3 275
p. The source BS sends a Clear Complete message to the MSC to notify it that 1
clearing has been accomplished. The MSC stops timer T315. 2
3
