3gpp2 a.s0013-d v2 · 2017-02-08 · 1.5.1.1 traffic channel radio link supervision ... 2.6.1...
TRANSCRIPT
3GPP2 A.S0013-D v2.0
August 2009
Interoperability Specification (IOS) for cdma2000 Access Network Interfaces — Part 3 Features
(3G-IOS v5.1.1)
© 2009, 3GPP2 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. Refer to www.3gpp2.org for more information.
1
2
3
4
5
6
(This page intentionally left blank.)
3GPP2 A.S0013-D v2.0
Table of Contents 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
1.0 Introduction ........................................................................................................................................ 1
1.1 Overview ........................................................................................................................................ 1 1.1.1 Purpose ................................................................................................................................... 6 1.1.2 Scope ...................................................................................................................................... 6
1.2 References ...................................................................................................................................... 6 1.2.1 Normative References ............................................................................................................ 6 1.2.2 Informative References........................................................................................................... 8
1.3 Terminology ................................................................................................................................... 8 1.3.1 Acronyms................................................................................................................................ 8 1.3.2 Definitions ............................................................................................................................ 11
1.4 Call Processing and Supplementary Services Assumptions ......................................................... 12 1.4.1 Call Control .......................................................................................................................... 12
1.4.1.1 A2, and A5 Bearer Allocation .......................................................................................... 12 1.4.1.2 Radio Channel Allocation................................................................................................. 12 1.4.1.3 Traffic Channel Release.................................................................................................... 12 1.4.1.4 A3 User Traffic Subchannel Allocation ........................................................................... 12 1.4.1.5 A2p Bearer Allocation...................................................................................................... 12
1.5 Radio Resource Management Assumptions ................................................................................. 13 1.5.1 Radio Channel Supervision .................................................................................................. 13
1.5.1.1 Traffic Channel Radio Link Supervision.......................................................................... 13 1.5.1.2 Idle Channel Observation ................................................................................................. 13
1.5.2 Radio Channel Management................................................................................................. 13 1.5.2.1 Radio Channel Configuration Management ..................................................................... 13 1.5.2.2 Radio Traffic Channel Management................................................................................. 13
1.5.2.2.1 Radio Channel Allocation.......................................................................................... 13 1.5.2.2.2 Radio Traffic Channel Release .................................................................................. 13 1.5.2.2.3 Radio Traffic Channel Power Control ....................................................................... 13 1.5.2.2.4 Channel Encoding and Decoding............................................................................... 14
2.0 Feature Descriptions ......................................................................................................................... 15 2.1 Call Setup of Voice and Circuit Data Calls .................................................................................. 15 2.2 Call Clearing of Voice and Circuit Data Calls.............................................................................. 15
2.2.1 Call Clearing Initiated by the MS or BS............................................................................... 15 2.2.2 Call Clearing Initiated by the MSC ...................................................................................... 16
2.3 Tandem Free Operation (TFO) Support ....................................................................................... 16 2.4 Test Calls ...................................................................................................................................... 17 2.5 Support of DTMF ......................................................................................................................... 18 2.6 Support of Supplementary Services.............................................................................................. 18
2.6.1 Feature Activation and Deactivation .................................................................................... 18 2.6.2 Call Waiting.......................................................................................................................... 19 2.6.3 Three Way Calling................................................................................................................ 19 2.6.4 Message Waiting Notification .............................................................................................. 19 2.6.5 Call Barring .......................................................................................................................... 20 2.6.6 Calling Number ID Presentation / Restriction ...................................................................... 20
2.6.6.1 CNIR for Mobile Originated Calls ................................................................................... 21 2.6.6.2 CNIP/CNIR for Mobile Terminated Calls ........................................................................ 21
2.6.7 Distinctive Ringing............................................................................................................... 21 2.6.8 Answer Holding.................................................................................................................... 21 2.6.9 User Selective Call Forwarding............................................................................................ 22
2.7 Mobile Registration ...................................................................................................................... 22 2.8 Global Emergency Call Origination ............................................................................................. 22 2.9 E911 Phase 1 and Phase 2 ............................................................................................................ 23 2.10 Short Message Service.................................................................................................................. 23
i
3GPP2 A.S0013-D v2.0
2.11 Priority Access and Channel Assignment (PACA) ...................................................................... 24 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
2.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration (OTAPA)............................................................................................................. 25
2.12.1 OTASP Support .................................................................................................................... 25 2.12.2 OTAPA Support ................................................................................................................... 25
2.13 Mobile Position Determination..................................................................................................... 25 2.13.1 Support of Position Determination Services (MS – PDE Approach) ................................... 25 2.13.2 Software Calculation Position Determination (BS – MSC Approach) ................................. 26
2.14 User Zone ..................................................................................................................................... 26 2.15 ISDN Interworking ....................................................................................................................... 26 2.16 Circuit Data Calls ......................................................................................................................... 27 2.17 3G Packet Data Calls.................................................................................................................... 27
2.17.1 Packet Data Assumptions ..................................................................................................... 29 2.17.2 Previous and Current Access Network Identifiers (PANID/CANID)................................... 30 2.17.3 PDSN Selection Algorithm................................................................................................... 30 2.17.4 Packet Data Interface Descriptions....................................................................................... 30
2.17.4.1 A8/A9 Interface Descriptions ........................................................................................... 30 2.17.4.2 A10/A11 Interface Descriptions ....................................................................................... 31
2.17.5 Interoperability Control ........................................................................................................ 31 2.17.6 Short Data Bursts.................................................................................................................. 31 2.17.7 Common Channel Packet Data (CCPD) ............................................................................... 32 2.17.8 Packet Data Security Considerations .................................................................................... 32 2.17.9 Support for AAA-Based Radio Network Packet Data Inactivity Timer (RN-PDIT)............ 33 2.17.10 Support for Always-on Service............................................................................................. 33 2.17.11 1x-Evolved High-Speed Integrated Data and Voice Support ............................................... 33 2.17.12 Flow Control......................................................................................................................... 34
2.18 Concurrent Services (Circuit Voice and Packet Data).................................................................. 34 2.19 Handoff......................................................................................................................................... 34
2.19.1 Handoff via MSC.................................................................................................................. 34 2.19.2 Handoff via Direct BS-to-BS Signaling ............................................................................... 35 2.19.3 Inter-BS Hard Handoff into Intra-BS Soft Handoff.............................................................. 35 2.19.4 Fast Handoff ......................................................................................................................... 35 2.19.5 Intergeneration Packet Data Handoff.................................................................................... 39 2.19.6 Alternate Dormant Handoff .................................................................................................. 39
2.20 Security Features .......................................................................................................................... 40 2.20.1 Authentication....................................................................................................................... 40
2.20.1.1 2G Terminal Authentication and Key Generation ............................................................ 40 2.20.1.2 3G Authentication and Key Generation............................................................................ 41
2.20.2 Signaling Message Encryption ............................................................................................. 42 2.20.3 Voice/Data Privacy............................................................................................................... 42 2.20.4 Extended Encryption for Signaling and User Traffic ........................................................... 42 2.20.5 Message Integrity.................................................................................................................. 43
2.21 Flex Rate....................................................................................................................................... 43 2.22 Status Inquiry................................................................................................................................ 43 2.23 3X Multi-Carrier Operation.......................................................................................................... 44 2.24 5 ms Messaging ............................................................................................................................ 44 2.25 Enhanced Rate Adaptation Mode (ERAM) .................................................................................. 44 2.26 Code Combining Soft Handoff (CCSH)....................................................................................... 44 2.27 Rescue Channel ............................................................................................................................ 44 2.28 Terrestrial Circuit Management.................................................................................................... 45
2.28.1 Terrestrial Circuit Management for the A2/A5 Interface ..................................................... 45 2.28.2 Terrestrial Circuit Management for the A3 Interface ........................................................... 45
2.29 Vocoder Support........................................................................................................................... 46 2.30 Reverse FCH Gating..................................................................................................................... 46 2.31 Voice-over-IP (VoIP) ................................................................................................................... 47
2.31.1 Voice over IP Handoff Considerations ................................................................................. 47
ii
3GPP2 A.S0013-D v2.0
2.32 Network Directed System Selection (NDSS) ............................................................................... 47 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
2.33 Transcoder Free Operation (TrFO)............................................................................................... 48 2.34 Remote Transcoder Operation (RTO) .......................................................................................... 48 2.35 Voice Preference Over Packet (VPOP) ........................................................................................ 48 2.36 Circuit Switched Video Conferencing Calls................................................................................. 49 2.37 Fast Call Setup.............................................................................................................................. 49
2.37.1 Direct Channel Assignment .................................................................................................. 49 2.38 Support for cdma2000 Pre-Rev D MEID Capable Mobiles ......................................................... 49 2.39 Support for Enhanced Frequency Hashing and Band Subclasses................................................. 49 2.40 Event Notification ........................................................................................................................ 50 2.41 Additional Geographical Location Information............................................................................ 50 2.42 Flex Duplex Channel .................................................................................................................... 50 2.43 Features Supported Transparently in this Standard ...................................................................... 50
2.43.1 Emergency Service (Basic) via Specific Dialed Number ..................................................... 50 2.43.2 Carrier Access....................................................................................................................... 51 2.43.3 Call Forwarding .................................................................................................................... 51
2.43.3.1 Call Forwarding Unconditional ........................................................................................ 51 2.43.3.2 Call Forwarding When Busy ............................................................................................ 51 2.43.3.3 Call Forwarding - No Answer .......................................................................................... 51 2.43.3.4 Call Forward Default ........................................................................................................ 52
2.43.4 Call Delivery......................................................................................................................... 52 2.43.5 Advice of Charge.................................................................................................................. 52 2.43.6 Call Transfer ......................................................................................................................... 52 2.43.7 Lawfully Authorized Wiretap............................................................................................... 53 2.43.8 Access Control by Call Type (ACCT).................................................................................. 53
3.0 Feature Call Flows............................................................................................................................ 55 3.1 Call Setup of Voice and Circuit Data Calls .................................................................................. 55
3.1.1 Mobile Origination Examples............................................................................................... 55 3.1.1.1 Mobile Origination ........................................................................................................... 55
3.1.1.1.1 Mobile Origination via a Circuit Switched MSC....................................................... 55 3.1.1.1.2 Mobile Origination with an MSCe with Bearer Parameters Sent in the
CM Service Request Message ................................................................................... 58 3.1.1.1.3 Mobile Origination with an MSCe with Bearer Parameters Sent in the
Assignment Complete Message ................................................................................. 61 3.1.1.2 Mobile Origination with Access Probe Handoff, Access Handoff and Channel
Assignment into Soft/Softer Handoff ............................................................................... 65 3.1.2 Mobile Termination Examples ............................................................................................. 70
3.1.2.1 Mobile Termination .......................................................................................................... 70 3.1.2.1.1 Mobile Termination via a Circuit switched MSC ...................................................... 70 3.1.2.1.2 Mobile Termination via an MSCe with the Bearer Parameters sent in the Paging
Response Message ..................................................................................................... 73 3.1.2.1.3 Mobile Termination via an MSCe Interfaces with Bearer Parameters sent in the
Assignment Complete Message ................................................................................. 75 3.1.2.2 Mobile Termination, Assignment Retry ........................................................................... 78
3.1.3 Mid-Call Bearer Modification Examples.............................................................................. 81 3.1.3.1 MSCe Initiated Bearer Modification ................................................................................ 81 3.1.3.2 BS Initiated Bearer Modification...................................................................................... 82
3.2 Call Clearing of Voice and Circuit Data Calls.............................................................................. 82 3.2.1 Call Clearing Initiated by the MS or BS............................................................................... 83 3.2.2 Call Clearing Initiated by the MSC ...................................................................................... 83
3.2.2.1 Clear from the Network .................................................................................................... 83 3.2.2.2 Call Clearing when Tones/Announcements are Provided ................................................ 84 3.2.2.3 Mobile Origination Failure – Call Clearing with Local Tone Generation ........................ 84
3.2.3 Call Clearing Collision ......................................................................................................... 85 3.2.4 Call Flows for Call Clear Operation ..................................................................................... 85
3.2.4.1 Call Clear via Clear Request (MS Initiated) ..................................................................... 86
iii
3GPP2 A.S0013-D v2.0
3.2.4.2 Call Clear via Clear Request (BS Initiated) ...................................................................... 86 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
3.2.4.3 Call Clear via Clear Command......................................................................................... 87 3.3 TFO Support................................................................................................................................. 88
3.3.1 Call Flows for Transcoder Control ....................................................................................... 88 3.4 Test Calls ...................................................................................................................................... 88 3.5 Support of DTMF ......................................................................................................................... 88 3.6 Support of Supplementary Services.............................................................................................. 88
3.6.1 Feature Activation and Deactivation .................................................................................... 89 3.6.1.1 Feature Activation/Deactivation in Idle Mode.................................................................. 89 3.6.1.2 Feature Activation/Deactivation While in a Call .............................................................. 89
3.6.2 Call Waiting.......................................................................................................................... 90 3.6.3 Three Way Calling................................................................................................................ 91
3.6.3.1 Three-Way Calling – (Method 1) ..................................................................................... 91 3.6.3.2 Three-Way Calling - (Method 2) ...................................................................................... 92
3.6.4 Message Waiting Notification .............................................................................................. 93 3.6.4.1 Message Waiting Notification on the Paging Channel ..................................................... 93 3.6.4.2 Message Waiting Notification on the Traffic Channel ..................................................... 94
3.6.5 Call Barring .......................................................................................................................... 94 3.6.5.1 Call Barring Incoming ...................................................................................................... 94 3.6.5.2 Call Barring Outgoing ...................................................................................................... 94
3.6.6 Calling Number ID Presentation/Restriction ........................................................................ 95 3.6.7 Distinctive Ringing............................................................................................................... 95 3.6.8 Answer Holding.................................................................................................................... 95
3.6.8.1 Answer Holding of a Mobile Terminated Call ................................................................. 96 3.6.8.2 Answer Holding of Call Waiting ...................................................................................... 96
3.6.9 User Selective Call Forwarding............................................................................................ 97 3.6.9.1 User Selective Call Forwarding of a Mobile Terminated Call.......................................... 98 3.6.9.2 User Selective Call Forwarding of Call Waiting .............................................................. 98
3.7 Mobile Registration ...................................................................................................................... 99 3.7.1 Mobile Initiated Location Registration............................................................................... 100 3.7.2 Power Down Registration at the End of a Call ................................................................... 100 3.7.3 Network Initiated Location Registration ............................................................................ 101 3.7.4 Mobile Station Registered Notification .............................................................................. 102
3.8 Global Emergency Call Origination ........................................................................................... 102 3.9 E911 Phase I and Phase 2 ........................................................................................................... 102 3.10 Short Message Service................................................................................................................ 102
3.10.1 SMS Feature Description.................................................................................................... 103 3.10.1.1 SMS - Mobile Originated Point-to-Point ........................................................................ 103 3.10.1.2 SMS - Mobile Terminated Point-to-Point....................................................................... 103 3.10.1.3 SMS - Broadcast ............................................................................................................. 103
3.10.2 SMS Delivery on a Common Channel................................................................................ 104 3.10.2.1 SMS Broadcast Delivery over a Common Channel........................................................ 104 3.10.2.2 SMS Receipt from an MS on the Access Channel.......................................................... 104 3.10.2.3 SMS Delivery to an MS on a Common Channel - Example 1........................................ 105 3.10.2.4 SMS Delivery to an MS on a Common Channel - Example 2
(without Early Traffic Channel Assignment).................................................................. 106 3.10.2.5 SMS Delivery to an MS on a Common Channel - Example 3
(with Early Traffic Channel Assignment)....................................................................... 107 3.10.2.6 SMS Delivery to an MS on a Common Channel - Example 4
using Registration Procedures ........................................................................................ 108 3.10.3 SMS Delivery on the Traffic Channel ................................................................................ 110
3.10.3.1 SMS Delivery to an MS on a Traffic Channel................................................................ 110 3.10.3.2 SMS Receipt from an MS on a Traffic Channel ............................................................. 111
3.11 Priority Access and Channel Assignment (PACA) .................................................................... 111 3.11.1 Mobile Origination with PACA Service............................................................................. 112
3.11.1.1 Mobile Origination with PACA Service – Radio Resources not Available.................... 112
iv
3GPP2 A.S0013-D v2.0
3.11.1.2 Mobile Origination, Idle Handoff with PACA Active.................................................... 113 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
3.11.1.3 Mobile Origination with PACA Active, Consecutive PACA Calls................................ 114 3.11.2 PACA Call Cancellation Initiated by the MS ..................................................................... 115 3.11.3 PACA Call Cancellation Initiated by Either MSC or BS ................................................... 115
3.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration (OTAPA).................................................................................................................................... 116
3.12.1 OTASP Support .................................................................................................................. 116 3.12.1.1 OTASP Call Setup.......................................................................................................... 117 3.12.1.2 OTASP Data Exchanges................................................................................................. 117 3.12.1.3 SSD Update Procedure ................................................................................................... 117 3.12.1.4 Privacy Mode Procedure................................................................................................. 117 3.12.1.5 Rejection......................................................................................................................... 117 3.12.1.6 OTASP Call Clear .......................................................................................................... 117 3.12.1.7 OTASP Call Flow........................................................................................................... 118
3.12.2 OTAPA Support ................................................................................................................. 119 3.13 Mobile Position Determination................................................................................................... 119
3.13.1 Call Flows for Position Location Service (MS-PDE) ......................................................... 120 3.13.1.1 Mobile Originated Position Location Service on the Traffic Channel............................ 120 3.13.1.2 Mobile Terminated Position Location Service on the Traffic Channel .......................... 122 3.13.1.3 Position Determination Service over Common Channels – Mobile Terminated ............ 123 3.13.1.4 Position Determination Services over Common Channels – Mobile Originated............ 124
3.13.2 Call Flows for Software Calculation Position Determination (BS-MSC) .......................... 125 3.14 User Zone ................................................................................................................................... 126
3.14.1 Invoking User Zone at Registration.................................................................................... 127 3.14.2 Use of User Zones During Call Setup................................................................................. 128 3.14.3 Changing User Zone During a Call (Mobile Initiated) ....................................................... 129 3.14.4 Changing User Zone During a Call (Network Initiated)..................................................... 129
3.15 ISDN Interworking Service via a Circuit Switched MSC .......................................................... 130 3.16 Circuit Data Calls via a Circuit Switched MSC.......................................................................... 130 3.17 3G Packet Data Calls.................................................................................................................. 130
3.17.1 Data Ready to Send (DRS) Indicator.................................................................................. 130 3.17.2 Previous and Current Access Network Identifiers (PANID/CANID)................................. 131 3.17.3 PDSN Selection Algorithm................................................................................................. 132 3.17.4 3G Packet Data Call Flows................................................................................................. 133
3.17.4.1 Interface Messages.......................................................................................................... 133 3.17.4.1.1 A9 Interface Messages............................................................................................. 133 3.17.4.1.2 A11 Interface Messages........................................................................................... 134
3.17.4.2 MS Initiated PDSI Setup................................................................................................. 135 3.17.4.2.1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive ................. 135 3.17.4.2.2 Mobile Initiated Setup of a PDSI When the Packet Data Session Already
Is Active– Successful Operation .............................................................................. 137 3.17.4.3 Mobile Originated PDSI Setup – Failure Operation ....................................................... 139 3.17.4.4 Mobile Originated Packet Call Setup – With Registration to Alternate PDSN .............. 141 3.17.4.5 BS Initiated PDSI Release to Dormant State .................................................................. 143
3.17.4.5.1 BS Initiated PDSI Release to Dormant State When No Other PDSI is Active ........ 144 3.17.4.5.2 BS Initiated PDSI Release to Dormant State When Other PDSIs are Active .......... 145
3.17.4.6 MS Initiated PDSI Release to Dormant State ................................................................. 146 3.17.4.6.1 MS Initiated PDSI Release to Dormant State when no other PDSI is Active.......... 146 3.17.4.6.2 MS Initiated PDSI Release to Dormant State when other PDSIs are Active ........... 148
3.17.4.7 Active MS Power Down................................................................................................. 149 3.17.4.8 PDSN Initiated PDSI Release to Inactive/Null State...................................................... 150
3.17.4.8.1 PDSN Initiated Release of a Dormant PDSI............................................................ 150 3.17.4.8.2 PDSN Initiated Release of an Active PDSI – Packet Data Session
Remains Active........................................................................................................ 152 3.17.4.8.3 PDSN Initiated Release of an Active PDSI – Packet Data Session
Becomes Dormant or Inactive.................................................................................. 153
v
3GPP2 A.S0013-D v2.0
3.17.4.8.4 PDSI Clearing – PDSN Initiated (Crossing A11-Registration Request and A11-Registration Update) ................................................................................................ 154
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
3.17.4.9 Packet Data Session Clearing – MSC Initiated............................................................... 156 3.17.4.10 MS Initiated PDSI Re-Activation from Dormant State (intra-PCF) ............................... 158 3.17.4.11 Network Initiated PDSI Re-Activation from Dormant State .......................................... 158
3.17.4.11.1 Network Initiated PDSI Reactivation when the Packet Data Session is Dormant ... 159 3.17.4.11.2 Network Initiated PDSI Reactivation when the Packet Data Session is Active....... 161
3.17.4.12 Mobile Terminated Packet Data Rejection During a Voice Call .................................... 162 3.17.4.13 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN..................... 163
3.17.4.13.1 Intra-PDSN Dormant Handoff of a PDSI, While the Packet Data Session is Dormant .................................................................................................. 163
3.17.4.13.2 Intra-PDSN Dormant Handoff, while the Packet Data Session is Active................ 166 3.17.4.14 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Inter-PDSN)..................................... 167 3.17.4.15 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN), Packet Data
Session is Dormant - Failed Authentication in MSC Following Session Establishment (PDSN Has Data to Send) ....................................................................... 171
3.17.4.16 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN) - Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have Data to Send) .................................................................................................. 173
3.17.4.17 Soft / Softer Handoff Packet Data .................................................................................. 175 3.17.4.18 Hard Handoff (Inter-BS/Intra-PCF/Intra-PDSN)............................................................ 175 3.17.4.19 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN)............................................................ 178 3.17.4.20 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN) With Return On Failure..................... 183 3.17.4.21 Inter-BS Hard Handoff – Mobile Served by a New Target PDSN ................................. 186 3.17.4.22 MS Initiated Call Release to Null State .......................................................................... 189
3.17.4.22.1 MS Initiated PDSI Release to the Inactive/Null State when no other PDSI is Active ......................................................................................................... 190
3.17.4.22.2 MS Initiated PDSI Release to the Inactive/Null State when other PDSI(s) are Active ................................................................................................... 191
3.17.4.23 Dormant MS Power Down, A10 Release Initiated by the MSC/BS............................... 192 3.17.4.24 Mobile Initiated Initial PDSI Setup – Successful Operation with Delayed
Accounting Information.................................................................................................. 194 3.17.4.25 Accounting Parameters Update Event Procedure ........................................................... 196 3.17.4.26 MS Initiated Reactivation from Dormant State .............................................................. 197
3.17.5 Interoperability Control ...................................................................................................... 198 3.17.5.1 A9 Version Control......................................................................................................... 198
3.17.5.1.1 Example of a Successful BS initiated A9 Version Control Procedure..................... 198 3.17.5.1.2 Example of a Successful PCF Initiated A9 Version Control Procedure .................. 198
3.17.5.2 A11 Capabilities Control ................................................................................................ 199 3.17.5.2.1 PCF Initiated A11 Capabilities Control ................................................................... 199 3.17.5.2.2 PDSN Initiated A11 Capabilities ............................................................................. 199
3.17.6 Support of Short Data Bursts .............................................................................................. 200 3.17.6.1 Mobile Originated Short Data Burst Call Flows............................................................. 200 3.17.6.2 Mobile Terminated Short Data Burst Call Flows ........................................................... 202
3.17.6.2.1 Short Data Delivery from the PDSN to the MS....................................................... 202 3.17.6.2.2 Short Data Delivery from the PDSN – BS Refuses SDB Request........................... 204
3.17.7 Support for Common Channel Packet Data (CCPD).......................................................... 206 3.17.7.1 Mobile Originated CCPD Mode Packet Data Call Setup Request.................................. 206 3.17.7.2 Mobile Terminated Packet Data for CCPD .................................................................... 209 3.17.7.3 CCPD Mode Packet Data Handoffs................................................................................ 209
3.17.7.3.1 CCPD MS Handoff (Inter-BS/Inter-PCF/Intra-PDSN)............................................ 210 3.17.7.3.2 CCPD MS Dormant Handoff (Inter-BS/Inter-PCF/Inter-PDSN) ............................ 212
3.17.8 Packet Data Security Considerations .................................................................................. 215 3.17.9 Support for PDSN Initiated Packet Data Session Updates ................................................. 215 3.17.10 Flow Control....................................................................................................................... 216
3.18 Voice and Packet Concurrent Service ........................................................................................ 217
vi
3GPP2 A.S0013-D v2.0
3.18.1 Concurrent Service Examples - Mobile Origination........................................................... 217 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
3.18.1.1 Mobile Initiated Packet Data Service Connection, Packet Data Session is Null or Dormant, Voice Service is Already Active..................................................................... 217
3.18.1.2 Mobile Initiated Voice Service Connection, Packet Data Session is Already Active..... 219 3.18.1.2.1 Mobile Initiated Voice Service Connection via a Circuit Switched MSC,
Packet Data Session is Already Active .................................................................... 219 3.18.1.2.2 Mobile Initiated Voice Service Connection via an MSCe, Packet Data
Session is Already Active ........................................................................................ 220 3.18.1.3 Mobile Initiated Packet Data Service Connection, Packet Data Session is
Already Active, Voice Service is Already Active .......................................................... 222 3.18.1.4 Mobile Initiated Voice Service Connection, Packet Data Session is Dormant............... 222
3.18.2 Concurrent Service Examples - Mobile Termination ......................................................... 222 3.18.2.1 Mobile Termination via a Circuit Switched MSC for Voice Service, Packet
Data Session is Already Active....................................................................................... 223 3.18.2.2 Mobile Termination via an MSCe for Voice Service, Packet Data Session
is Already Active ............................................................................................................ 224 3.18.3 Concurrent Service Examples - Network Initiated PDSI Re-Activation ............................ 226
3.18.3.1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a Voice Service, Packet Data Session is Dormant: Case 1 ............................................. 227
3.18.3.2 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a Voice Service and the Packet Data Session is Dormant; Case 2.................................. 228
3.18.3.3 Network Initiated Service Instance Reactivation When There is Another Active PDSI and MS is Already Active with a Voice Service ....................................... 230
3.18.4 Concurrent Services: Call Clearing Examples.................................................................... 230 3.18.4.1 Call Clear via Service Release – MS Initiated................................................................ 230 3.18.4.2 Call Clear via Service Release - MSC Initiated.............................................................. 231 3.18.4.3 PDSN Initiated Service Instance Release, Voice Service is Active................................ 233
3.18.4.3.1 PDSN Initiated Release of Last Active PDSI, Voice Service is Active................... 233 3.18.4.4 BS Initiated Release to Dormant State of a PDSI, Voice Service is Active ................... 234
3.18.4.4.1 BS Initiated Release to Dormant State of Last Active PDSI, Voice Service is Active ...................................................................................................... 234
3.18.5 Concurrent Service - Handoff............................................................................................. 236 3.18.5.1 Concurrent Service (Active Voice and Packet Data Services) - Hard Handoff .............. 236
3.18.5.1.1 Successful Inter-BS Hard Handoff Call Flows (Within the Same PCF).................. 236 3.18.5.1.2 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served
by the Same PDSN) ................................................................................................. 236 3.18.5.1.3 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served
by New PDSN) ........................................................................................................ 236 3.18.5.2 Concurrent Service (Active Voice and Dormant Packet Data Services) - Handoff........ 236
3.18.5.2.1 Successful Inter-PCF Handoff Call Flows (Mobile Served by the Same PDSN) .... 236 3.18.5.2.2 Successful Inter-PCF Handoff Call Flow (Mobile Served by New PDSN)............. 238
3.18.5.3 Concurrent Service - Soft / Softer Handoff .................................................................... 240 3.19 Handoff....................................................................................................................................... 240
3.19.1 Handoff via MSC................................................................................................................ 241 3.19.1.1 Introduction .................................................................................................................... 241
3.19.1.1.1 Recognition That a Handoff is Required by a BS.................................................... 241 3.19.1.1.2 Recognition That a Handoff is Required by the MSC ............................................. 241 3.19.1.1.3 Concept of “Designated Cell”.................................................................................. 241
3.19.1.2 Inter-BS Hard Handoff ................................................................................................... 241 3.19.1.2.1 Triggering Phase ...................................................................................................... 242 3.19.1.2.2 Target Determination Phase..................................................................................... 242 3.19.1.2.3 Resource Establishment ........................................................................................... 242 3.19.1.2.4 Execution Phase....................................................................................................... 242
3.19.1.3 Call Clearing................................................................................................................... 242 3.19.1.4 Handoff Failure Handling............................................................................................... 243 3.19.1.5 Intra-BS Handoff ............................................................................................................ 243
vii
3GPP2 A.S0013-D v2.0
3.19.2 Handoff via Direct BS-to-BS Signaling ............................................................................. 243 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
3.19.2.1 A3 Interface Messages.................................................................................................... 243 3.19.2.2 A7 Interface Messages.................................................................................................... 244 3.19.2.3 Soft/Softer Handoff Addition ......................................................................................... 245 3.19.2.4 Soft/Softer Handoff Removal ......................................................................................... 245 3.19.2.5 Cell Removal by a Target BS ......................................................................................... 245 3.19.2.6 Call Clearing................................................................................................................... 245 3.19.2.7 Handoff Performed ......................................................................................................... 246 3.19.2.8 Access Handoff and Channel Assignment into Soft Handoff......................................... 246 3.19.2.9 Soft/Softer Handoff of High Speed Packet Data ............................................................ 247
3.19.2.9.1 Soft/Softer Handoff of Forward Link Bursts of Data .............................................. 247 3.19.2.9.2 Soft/Softer Handoff of Reverse Link Bursts of SCH Data ...................................... 248
3.19.3 Handoff Call Flows............................................................................................................. 248 3.19.3.1 Hard Handoff via MSC Call Flows ................................................................................ 248
3.19.3.1.1 Successful Hard Handoff via the A1 and A2 Interfaces .......................................... 248 3.19.3.1.2 Successful Hard Handoff via the A1p and A2p Interfaces ...................................... 250 3.19.3.1.3 Successful Hard Handoff From a Circuit Switched MSC to an MSCe.................... 252 3.19.3.1.4 Successful Hard Handoff From an MSCe to a Circuit Switched MSC.................... 253 3.19.3.1.5 Successful Hard Handoff to ANSI/TIA/EIA-553-A Systems.................................. 253 3.19.3.1.6 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A
Alternative Rejected ................................................................................................ 254 3.19.3.1.7 Hard Handoff with Return On Failure ..................................................................... 256 3.19.3.1.8 Hard Handoff Failure............................................................................................... 257
3.19.3.2 Soft/Softer Handoff via Direct BS-to-BS Signaling Call Flows..................................... 259 3.19.3.2.1 Soft/Softer Handoff Addition................................................................................... 259 3.19.3.2.2 Soft/Softer Handoff Removal .................................................................................. 260 3.19.3.2.3 Cell Removal by a Target BS .................................................................................. 262 3.19.3.2.4 Initial Traffic Burst Example – A3 Connection Not Yet Established ...................... 263 3.19.3.2.5 Subsequent Traffic Burst Example .......................................................................... 266 3.19.3.2.6 Source BS Releases Reserved Resources ................................................................ 267 3.19.3.2.7 Early Burst Termination Initiated by Source BS ..................................................... 268 3.19.3.2.8 Early Burst Termination Initiated by Target BS ...................................................... 269
3.19.4 Fast Handoff Call Flows..................................................................................................... 269 3.19.4.1 Anchor PDSN Reachable from Target PCF ................................................................... 269 3.19.4.2 Anchor PDSN Not Reachable from Target PCF ............................................................ 273 3.19.4.3 Fast Handoff Superseded by Another Fast Handoff ....................................................... 278
3.19.5 Intergeneration Packet Data Handoff.................................................................................. 284 3.19.5.1 Hard Handoff from 2G System to 3G System ................................................................ 284 3.19.5.2 Hard Handoff from 3G System to 2G System, PCF not used in the 2G system............. 287 3.19.5.3 Intra-PCF Hard Handoff from 3G BS to 2G BS............................................................. 290 3.19.5.4 Dormant Handoff from 2G System to 3G System.......................................................... 293 3.19.5.5 Dormant Handoff from 3G System to 2G System.......................................................... 293
3.19.6 Alternate Dormant Handoff ................................................................................................ 293 3.19.6.1 Intra-PDSN Alternate Dormant Handoff of a PDSI, While the Packet
Data Session is Dormant................................................................................................. 293 3.19.6.2 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a
Different PDSN .............................................................................................................. 296 3.19.6.3 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - with Concurrent
Authentication Mobile Served by Same PDSN, Failed Authentication in MSC Following session establishment (PDSN Does Not Have Data to Send) .............. 299
3.20 Security Features ........................................................................................................................ 301 3.20.1 Authentication and Privacy................................................................................................. 301
3.20.1.1 SSD Update Procedure - Successful Case ...................................................................... 302 3.20.1.2 2G Terminal Authentication ........................................................................................... 304 3.20.1.3 Parameter Update............................................................................................................ 304 3.20.1.4 Privacy Mode Procedure................................................................................................. 305
viii
3GPP2 A.S0013-D v2.0
3.20.1.5 BS Initiated Terminal Authentication............................................................................. 306 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
3.20.1.6 3G Authentication and Message Integrity ...................................................................... 306 3.20.1.6.1 3G Authentication.................................................................................................... 306 3.20.1.6.2 3G Authentication with Resync of Authentication Vector Information .................. 307 3.20.1.6.3 Encryption and Message Integrity Info Update ....................................................... 308 3.20.1.6.4 BS Initiated Encryption and Message Integrity Info Update ................................... 308 3.20.1.6.5 Mobile Originated and Mobile Terminated Call Setup with Authentication and
Message Integrity..................................................................................................... 309 3.20.1.6.6 MSC Resynchronization of Authentication Vector Information ............................. 311
3.21 Flex Rate..................................................................................................................................... 312 3.22 Status Inquiry.............................................................................................................................. 312
3.22.1 Status Inquiry Example....................................................................................................... 312 3.23 3X Multi-Carrier Operation........................................................................................................ 313
3.23.1 Hard Handoff Support ........................................................................................................ 313 3.23.2 Soft Handoff Support.......................................................................................................... 314
3.24 5 ms Messaging .......................................................................................................................... 314 3.24.1 Forward Link ...................................................................................................................... 314 3.24.2 Reverse Link....................................................................................................................... 314
3.25 Enhanced Rate Adaptation Mode (ERAM) ................................................................................ 314 3.26 Code Combining Soft Handoff (CCSH)..................................................................................... 315 3.27 Rescue Channel .......................................................................................................................... 315
3.27.1 Rescue Channel – Network and MS Select the Same Rescue Cell(s)................................. 315 3.27.2 Rescue Channel – Network and MS Selected Different Rescue Cell(s) ............................. 318
3.28 Terrestrial Resource Management .............................................................................................. 320 3.28.1 Terrestrial Resource Management for the A2/A2p/A5 Interfaces ...................................... 320
3.28.1.1 A2/A5 Terrestrial Circuit Allocation .............................................................................. 321 3.28.1.2 A2/A5 Terrestrial Circuit Blocking/Unblocking ............................................................ 321
3.28.1.2.1 Block Procedure Scenario Diagram......................................................................... 321 3.28.1.2.2 Unblock Procedure Scenario Diagram..................................................................... 321
3.28.1.3 A2/A5 Reset Circuit Procedure ...................................................................................... 322 3.28.1.3.1 Reset Procedure at the BS Scenario Diagram.......................................................... 322 3.28.1.3.2 Reset Circuit Procedure at the Circuit-Switched MSC ............................................ 323 3.28.1.3.3 Reset Circuit Procedure at the Circuit-Switched MSC with BS Block Response.... 323
3.28.1.4 A2/A2p/A5 Global System Reset ................................................................................... 324 3.28.1.4.1 Successful Reset at the MSC ................................................................................... 324 3.28.1.4.2 Successful Reset at the BS....................................................................................... 325 3.28.1.4.3 Reset Glare Noted at the MSC................................................................................. 325 3.28.1.4.4 Reset Glare Noted at the BS .................................................................................... 326 3.28.1.4.5 Reset Glare Noted at Both the MSC and the BS...................................................... 327
3.28.2 Terrestrial Circuit Management for the A3 Interface ......................................................... 328 3.28.2.1 Successful Reset at a BS................................................................................................. 329 3.28.2.2 A7-Reset Glare Noted at the First BS............................................................................. 329 3.28.2.3 A7-Reset Glare Noted at Both BSs................................................................................. 330
3.29 Vocoder Support......................................................................................................................... 331 3.29.1 Mobile Originated Calls...................................................................................................... 331 3.29.2 Mobile Terminated Calls .................................................................................................... 333 3.29.3 Service Option Change During Handoff............................................................................. 334
3.30 Reverse FCH Gating................................................................................................................... 336 3.31 Voice over IP (VoIP).................................................................................................................. 336 3.32 Network Directed System Selection (NDSS) ............................................................................. 336
3.32.1 Redirection During Mobile Origination.............................................................................. 336 3.32.2 Redirection During Mobile Registration ............................................................................ 338 3.32.3 Re-Origination Upon Failed Re-Direction.......................................................................... 339 3.32.4 Re-Registration Upon Failed Re-Direction......................................................................... 341
3.33 Transcoder Free Operation (TrFO)............................................................................................. 342 3.34 Remote Transcoder Operation (RTO) ........................................................................................ 342
ix
3GPP2 A.S0013-D v2.0
3.35 Voice Preference Over Packet (VPOP) ...................................................................................... 342 1
2
3
4
5
6
7
8
9
10
11
3.36 Circuit Switched Video Conferencing Calls............................................................................... 344 3.37 Fast Call Setup............................................................................................................................ 344
3.37.1 Direct Channel Assignment (DCA) .................................................................................... 344 3.37.1.1 Mobile Termination with Direct Channel Assignment................................................... 344 3.37.1.2 Network Initiated PDSI Reactivation via Direct Channel Assignment
(Dormant Packet Data Session, SCCP connection maintained) ..................................... 346 3.38 Event Notification ...................................................................................................................... 348
3.38.1 Event Notification – Multiple Pages................................................................................... 348 3.38.2 Event Notification – Early Traffic Channel Assignment .................................................... 349
x
3GPP2 A.S0013-D v2.0
List of Figures 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
Figure 2.17-1 Packet Data Session State Transitions ...................................................................... 28 Figure 2.19.4-1 General Configuration Prior to a Fast Handoff......................................................... 36 Figure 2.19.4-2 Configuration Without Prior Fast Handoff – Target PDSN Identical to
Source/Anchor PDSN............................................................................................... 37 Figure 2.19.4-3 Configuration Without Prior Fast Handoff – Target PDSN Different from
Source/Anchor PDSN............................................................................................... 37 Figure 2.19.4-4 Configuration With Prior Fast Handoff - When the Target BS/PCF Can Reach
the Anchor PDSN ..................................................................................................... 37 Figure 2.19.4-5 Configuration With Prior Fast Handoff - When the Target BS/PCF Can Reach
the Source PDSN ...................................................................................................... 38 Figure 2.19.4-6 General Configuration During a Fast Handoff, Step 1 ............................................. 38 Figure 2.19.4-7 General Configuration During a Fast Handoff, Step 2 ............................................. 39 Figure 3.1.1.1.1-1 Mobile Origination via a Circuit Switched MSC...................................................... 56 Figure 3.1.1.1.2-1 Mobile Origination with Bearer Parameters Sent in the CM Service Request
Message .................................................................................................................... 59 Figure 3.1.1.1.3-1 Mobile Origination with Bearer Parameters sent in the Assignment Complete
Message .................................................................................................................... 62 Figure 3.1.1.2-1 Mobile Origination with Access Probe Handoff, Access Handoff and Channel
Assignment into Soft/Softer Handoff ....................................................................... 66 Figure 3.1.2.1.1-1 Mobile Termination via a Circuit switched MSC..................................................... 71 Figure 3.1.2.1.2-1 Mobile Termination via an MSCe with the Bearer Parameters sent in the
Paging Response Message ........................................................................................ 73 Figure 3.1.2.1.3-1 Mobile Termination Interfaces with Bearer Parameters sent in the Assignment
Complete Message.................................................................................................... 76 Figure 3.1.2.2-1 Mobile Termination: Assignment Retry ................................................................... 79 Figure 3.1.3.1-1 MSCe Initiated Bearer Modification ....................................................................... 81 Figure3.1.3.2-1 BS Initiated Bearer Modification.............................................................................. 82 Figure 3.2.2.3-1 Call Clearing with Local Tone Generation ............................................................... 84 Figure 3.2.4.1-1 Call Clear Initiated by MS........................................................................................ 86 Figure 3.2.4.2-1 Call Clear Initiated by BS (via Clear Request) ......................................................... 87 Figure 3.2.4.3-1 Call Clear Initiated by MSC (via Clear Command).................................................. 87 Figure 3.3.1-1 Transcoder Control Call Flow .................................................................................. 88 Figure 3.6.1.2-1 Feature Activation/Deactivation While in a Call ...................................................... 89 Figure 3.6.2-1 Call Waiting.............................................................................................................. 90 Figure 3.6.3.1-1 Three-Way Calling (Method 1) ................................................................................ 91 Figure 3.6.3.2-1 Three-Way Calling (Method 2) ................................................................................ 92 Figure 3.6.4.1-1 Message Waiting Notification on the Paging Channel ............................................. 93 Figure 3.6.4.2-1 Message Waiting Notification on the Traffic Channel ............................................. 94 Figure 3.6.5.2-1 Call Barring Outgoing .............................................................................................. 95 Figure 3.6.8.1-1 Answer Holding of a Mobile Terminated Call ......................................................... 96 Figure 3.6.8.2-1 Answer Holding of Call Waiting .............................................................................. 97 Figure 3.6.9.1-1 User Selective Call Forwarding of Mobile Terminated Call .................................... 98 Figure 3.6.9.2-1 User Selective Call Forwarding of Call Waiting ...................................................... 99 Figure 3.7.1-1 Location Registration - Successful Case................................................................. 100 Figure 3.7.3-1 Network Initiated Location Registration - Successful Case.................................... 101 Figure 3.7.4-1 Mobile Station Registered Notification .................................................................. 102 Figure 3.10.2.1-1 SMS-Broadcast Delivery to MSs over a Common Channel .................................. 104 Figure 3.10.2.2-1 SMS-MO Delivery on the Access Channel ........................................................... 105 Figure 3.10.2.3-1 SMS-MT Delivery to an MS on a Common Channel - Example 1 ....................... 105 Figure 3.10.2.4-1 SMS-MT Delivery to an MS on a Common Channel - Example 2 ....................... 106 Figure 3.10.2.5-1 SMS-MT Delivery to an MS on a Common Channel - Example 3 ....................... 107 Figure 3.10.2.6-1 SMS-MT Delivery to an MS on a Common Channel - Example 4 ....................... 109 Figure 3.10.3.1-1 SMS Message Delivery to an MS on a Traffic Channel ........................................ 110
xi
3GPP2 A.S0013-D v2.0
Figure 3.10.3.2-1 SMS Receipt from an MS on a Traffic Channel .................................................... 111 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Figure 3.11.1.1-1 Mobile Origination with PACA Service................................................................ 112 Figure 3.11.1.2-1 Mobile Origination, Idle Handoff with PACA Active........................................... 113 Figure 3.11.1.3-1 Mobile Origination with Consecutive PACA Call Requests ................................. 114 Figure 3.11.2-1 PACA Call Cancellation Initiated by the MS ......................................................... 115 Figure 3.11.3-1 PACA Call Cancellation Initiated by the MSC ...................................................... 116 Figure 3.12.1.7-1 OTASP Message Flow: CDMA ............................................................................ 118 Figure 3.13.1.1-1 Mobile Originated Position Location Service on a Traffic Channel...................... 121 Figure 3.13.1.2-1 Mobile Terminated Position Location Service on a Traffic Channel .................... 122 Figure 3.13.1.3-1 Position Location Service over Common Channels – Mobile Terminated............ 124 Figure 3.13.1.4-1 Position Location Service over Common Channels – Mobile Originated ............. 125 Figure 3.13.2-1 Software Calculation for Position Determination................................................... 126 Figure 3.14.1-1 Location Registration using User Zones................................................................. 127 Figure 3.14.2-1 Mobile Call Setup Using User Zone....................................................................... 128 Figure 3.14.3-1 Updating the User Zone During a Call (Mobile Initiated) ...................................... 129 Figure 3.14.4-1 Updating the User Zone During a Call (Network initiated).................................... 129 Figure 3.17.4.2.1-1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive ................ 136 Figure 3.17.4.2.2-1 Mobile Initiated Setup of a PDSI When the Packet Data Session is Already
Active– Successful Operation................................................................................. 138 Figure 3.17.4.3-1 Mobile Originated PDSI Setup When the Packet Data Session is Dormant or
Inactive – Failure Operation ................................................................................... 140 Figure 3.17.4.4-1 Mobile Originated Packet Service Instance Setup – With Registration to
Alternate PDSN ...................................................................................................... 142 Figure 3.17.4.5.1-1 BS Initiated PDSI Release to Dormant State When No Other PDSI is Active....... 144 Figure 3.17.4.5.2-1 BS Initiated PDSI Release to Dormant State When Other PDSIs are Active ......... 145 Figure 3.17.4.6.1-1 MS Initiated PDSI Release to Dormant State When No Other PDSI is Active ...... 146 Figure 3.17.4.6.2-1 MS Initiated PDSI Release to Dormant State When Other PDSIs are Active ........ 148 Figure 3.17.4.7-1 Active MS Power Down........................................................................................ 149 Figure 3.17.4.8.1-1 PDSN Initiated Service Release of a Dormant PDSI.............................................. 150 Figure 3.17.4.8.2-1 PDSN Initiated Service Release of an Active Packet Service Instance – Packet
Data Session Remains Active ................................................................................. 152 Figure 3.17.4.8.3-1 PDSN Initiated Release of an Active PDSI – Packet Data Session Becomes
Dormant or Inactive................................................................................................ 153 Figure 3.17.4.8.4-1 PDSI Clearing – PDSN Initiated (Crossing A11-Registration Request and A11-
Registration Update) ............................................................................................... 155 Figure 3.17.4.9-1 Packet Data Session Clearing – MSC Initiated....................................................... 157 Figure 3.17.4.11.1-1 Network Initiated PDSI Re-Activation from Dormant State – Packet Data
Session is Dormant ................................................................................................. 159 Figure 3.17.4.11.2-1 Network Initiated PDSI Re-Activation from Dormant State – Packet Data
Session is Active..................................................................................................... 161 Figure 3.17.4.12-1 Mobile Terminated Packet Data Rejection During a Voice Call ............................ 162 Figure 3.17.4.13.1-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN), Packet Data
Session Dormant..................................................................................................... 164 Figure 3.17.4.13.2-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN), Packet Data
Session Active ........................................................................................................ 166 Figure 3.17.4.14-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Inter-PDSN)............................. 169 Figure 3.17.4.15-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN) - Failed
Authentication in MSC Following Session Establishment (PDSN Has Data to Send)....................................................................................................................... 172
Figure 3.17.4.16-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN) - Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have Data to Send)................................................................................................. 174
Figure 3.17.4.18-1 Hard Handoff (Inter-BS/Intra-PCF/Intra-PDSN).................................................... 176 Figure 3.17.4.19-1 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN).................................................... 180 Figure 3.17.4.20-1 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN) With Return On Failure............. 184 Figure 3.17.4.21-1 Inter-BS Hard Handoff – Mobile Served by New Target PDSN............................ 187
xii
3GPP2 A.S0013-D v2.0
Figure 3.17.4.22.1-1 MS Initiated PDSI Release to Null State When No Other PDSI is Active ............. 190 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Figure 3.17.4.22.2-1 MS Initiated PDSI Release to Inactive/Null State When Other PDSIs are Active . 191 Figure 3.17.4.23-1 Dormant MS Power Down, A10 Release Initiated by the MSC/BS....................... 193 Figure 3.17.4.24-1 Mobile Initiated Initial PDSI Setup – Successful Operation with Delayed
Accounting Information.......................................................................................... 195 Figure 3.17.4.25-1 Accounting Parameters Update Event Procedure ................................................... 197 Figure 3.17.5.1.1-1 Successful BS Initiated A9 Version Control Procedure ......................................... 198 Figure 3.17.5.1.2-1 Successful PCF Initiated A9-Version Control Procedure....................................... 199 Figure 3.17.5.2.1-1 A11 Capabilities Information Exchange – PCF Initiated ....................................... 199 Figure 3.17.5.2.2-1 A11 Capabilities Information Exchange................................................................. 200 Figure 3.17.6.1-1 cdma2000 Short Data Burst from an MS to the PDSN.......................................... 201 Figure 3.17.6.2.1-1 cdma2000 Short Data Burst from the PDSN to the MS.......................................... 203 Figure 3.17.6.2.2-1 Short Data Burst from the PDSN to the MS – BS Refuses SDB Request .............. 205 Figure 3.17.7.1-1 MS Initiated CCPD Mode Setup and Data Transfer.............................................. 207 Figure 3.17.7.3.1-1 CCPD MS Handoff (Inter-BS/Inter-PCF/Intra-PDSN) .......................................... 211 Figure 3.17.7.3.2-1 CCPD MS Dormant Handoff (Inter-BS/Inter-PCF/Inter-PDSN) - Mobile
Served by Different PDSN ..................................................................................... 213 Figure 3.17.9-1 PDSN Initiated Packet Data Session Update .......................................................... 216 Figure 3.18.1.1-1 Mobile Initiated Packet Data Service Connection, Packet Data Session Null or
Dormant, Voice Service is Already Active............................................................. 218 Figure 3.18.1.2.1-1 Mobile Initiated Voice Service Connection via Circuit Switched MSC, Packet
Data Session is Already Active............................................................................... 219 Figure 3.18.1.2.2-1 Mobile Initiated Voice Service Connection via an MSCe, Packet Data Session
is Already Active. ................................................................................................... 221 Figure 3.18.2.1-1 Mobile Termination via a Circuit Switched MSC for Voice Service, Packet
Data Session is Already Active............................................................................... 223 Figure 3.18.2.2-1 Mobile Termination via an MSCe for Voice Service, Packet Data Session is
Already Active........................................................................................................ 225 Figure 3.18.3.1-1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with
a Voice Service, Packet Data Session is Dormant, Case 1 ..................................... 227 Figure 3.18.3.2-1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with
a Voice Service and the Packet Data Session is Dormant; Case 2.......................... 229 Figure 3.18.4.1-1 Releasing a Service That Is Not the Only One Connected (MS Initiated)............. 231 Figure 3.18.4.2-1 Releasing a Service That Is Not the Only One Connected (MSC Initiated) .......... 232 Figure 3.18.4.3.1-1 PDSN Initiated Service Release of the Last Active PDSI – Voice Service
Active...................................................................................................................... 233 Figure 3.18.4.4.1-1 BS Initiated Service Instance Release to Dormant State of Last Active PDSI,
Voice Service Active .............................................................................................. 235 Figure 3.18.5.2.1-1 Successful Inter-PCF Handoff (Mobile Served by the Same PDSN) ..................... 237 Figure 3.18.5.2.2-1 Successful Inter-PCF Handoff (Mobile Served by New PDSN) ............................ 239 Figure 3.19.3.1.1-1 Successful Hard Handoff via the A1 and A2 Interfaces ......................................... 249 Figure 3.19.3.1.2-1 Successful Hard Handoff via the A1p and A2p Interfaces ..................................... 251 Figure 3.19.3.1.5-1 Successful Hard Handoff to an ANSI/TIA/EIA-553-A System ............................. 253 Figure 3.19.3.1.6-1 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A
Alternative Rejected ............................................................................................... 255 Figure 3.19.3.1.7-1 Hard Handoff with Return On Failure .................................................................... 256 Figure 3.19.3.1.8-1 Hard Handoff Failure.............................................................................................. 258 Figure 3.19.3.2.1-1 Soft/Softer Handoff Addition ................................................................................. 259 Figure 3.19.3.2.2-1 Soft/Softer Handoff Removal ................................................................................. 261 Figure 3.19.3.2.3-1 Cell Removal Initiated by the Target BS................................................................ 262 Figure 3.19.3.2.4-1 Initial Traffic Burst Example.................................................................................. 264 Figure 3.19.3.2.5-1 Subsequent Traffic Burst Example ......................................................................... 266 Figure 3.19.3.2.6-1 Source BS Releases Reserved Resources ............................................................... 268 Figure 3.19.3.2.7-1 Early Burst Termination Initiated by Source BS .................................................... 268 Figure 3.19.3.2.8-1 Early Burst Termination Initiated by Target BS..................................................... 269 Figure 3.19.4.1-1 Anchor PDSN Reachable From Target PCF.......................................................... 270
xiii
3GPP2 A.S0013-D v2.0
Figure 3.19.4.2-1 Anchor PDSN Not Reachable From Target PCF................................................... 274 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
Figure 3.19.4.3-1 Fast Handoff Superseded by Another Fast Handoff .............................................. 279 Figure 3.19.5.1-1 Hard Handoff from 2G System to 3G System ....................................................... 285 Figure 3.19.5.2-1 Hard Handoff from 3G System to 2G System ....................................................... 288 Figure 3.19.5.3-1 Intra-PCF Hard Handoff from 3G BS to 2G BS.................................................... 291 Figure 3.19.6.1-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served
by Same PDSN, Packet Data Session Dormant ...................................................... 294 Figure 3.19.6.2-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served
by a Different PDSN............................................................................................... 297 Figure 3.19.6.3-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) with Concurrent
Authentication - Mobile Served by Same PDSN, Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have Data to Send) .............. 300
Figure 3.20.1.1-1 SSD Update - Successful Case .............................................................................. 303 Figure 3.20.1.2-1 Terminal Authentication ........................................................................................ 304 Figure 3.20.1.3-1 Parameter Update................................................................................................... 305 Figure 3.20.1.4-1 Privacy Mode Procedure........................................................................................ 305 Figure 3.20.1.5-1 BS Initiated Terminal Authentication.................................................................... 306 Figure 3.20.1.6.1-1 3G Authentication................................................................................................... 307 Figure 3.20.1.6.2-1 3G Authentication with Synch Failure ................................................................... 307 Figure 3.20.1.6.3-1 Encryption and Integrity Info Update ..................................................................... 308 Figure 3.20.1.6.4-1 BS Initiated Encryption and Integrity Info Update ................................................. 309 Figure 3.20.1.6.5-1 3G Authentication for Mobile Originated and Mobile Terminated Scenarios........ 310 Figure 3.20.1.6.6-1 Resync of Authentication Vector Information........................................................ 311 Figure 3.22.1-1 Status Inquiry.......................................................................................................... 313 Figure 3.27.1-1 Rescue Channel – Network and MS Select the Same Rescue Cell(s)..................... 316 Figure 3.27.2-1 Rescue Channel – Network and MS Selected Different Rescue Cells.................... 319 Figure 3.28.1.2.1-1 Block Procedure...................................................................................................... 321 Figure 3.28.1.2.2-1 Unblock Procedure ................................................................................................. 322 Figure 3.28.1.3.1-1 A1 Reset Circuit Procedure at the BS..................................................................... 322 Figure 3.28.1.3.2-1 Reset Circuit Procedure at the Circuit-Switched MSC........................................... 323 Figure 3.28.1.3.3-1 Reset Circuit Procedure at the Circuit-Switched MSC with BS Block Response .. 323 Figure 3.28.1.4.1-1 Successful Reset at the MSC .................................................................................. 324 Figure 3.28.1.4.2-1 Successful Reset at the BS...................................................................................... 325 Figure 3.28.1.4.3-1 Reset Glare Noted at the MSC................................................................................ 326 Figure 3.28.1.4.4-1 Reset Glare Noted at the BS ................................................................................... 327 Figure 3.28.1.4.5-1 Reset Glare Noted at Both the MSC and the BS..................................................... 328 Figure 3.28.2.1-1 Successful A7-Reset at a BS.................................................................................. 329 Figure 3.28.2.2-1 A7-Reset Glare Noted at the First BS.................................................................... 330 Figure 3.28.2.3-1 A7-Reset Glare Noted at Both BSs........................................................................ 331 Figure 3.29.1-1 Vocoder Selection – Mobile Originated Case......................................................... 332 Figure 3.29.2-1 Vocoder Selection – Mobile Terminated Case ....................................................... 333 Figure 3.29.3-1 Vocoder Selection – Handoff Case......................................................................... 334 Figure 3.32.1-1 Service Redirection During Mobile Origination..................................................... 337 Figure 3.32.2-1 Service Redirection During Mobile Registration.................................................... 338 Figure 3.32.3-1 Re-Origination Upon Failed Re-Direction.............................................................. 339 Figure 3.32.4-1 Re-Registration Upon Failed Re-Direction............................................................. 341 Figure 3.35-1 Voice Call Preemption of a Traffic Channel .......................................................... 343 Figure 3.37.1.1-1 Mobile Termination Support with Direct Channel Assignment ............................ 345 Figure 3.37.1.2-1 Network Initiated PDSI Reactivation via Direct Channel Assignment
(Dormant Packet Data Session, SCCP connection maintained) ............................. 347 Figure 3.38.1-1 Event Notification for Multiple Page Scenario....................................................... 349 Figure 3.38.2-1 Event Notification for Early Traffic Channel Assignment ..................................... 350
xiv
3GPP2 A.S0013-D v2.0
List of Tables 1
2
3
4
5
Table 3.20.1-1 Authentication and Voice Privacy Requirements ................................................... 301
xv
3GPP2 A.S0013-D v2.0
xvi
1
2
3
4
5
6
(This page intentionally left blank.)
3GPP2 A.S0013-D v2.0
1.0 Introduction 1
2
3
This document contains the procedures and call flows associated with the features that are supported by this release of the IOS specification.
1.1 Overview 4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
This document includes a description of the protocol and some generic procedures to support the following features and functions. Conformance to this standard may be claimed on a feature by feature and/or interface by interface basis. If conformance on a given interface is claimed for a feature, it shall be supported as defined in this standard.
Features and Functions Explicitly Supported in this Standard:
1x Enhancement support for:
Additional geographical location information
Flex-duplex channel (FDC)
3G Packet Data Calls
Call Setup (mobile originated)
Reactivation (mobile initiated and network initiated)
Handoffs (dormant, alternate dormant, hard, fast)
Call Clearing (mobile initiated and network initiated)
Transition to Dormancy
Accounting
Common Channel Packet Data (CCPD)
Short Data Bursts
F-PDCH support
R-PDCH support
3X Multi-Carrier
5 ms Messaging
A10 Flow Control
A11 Capabilities indication
Access Control by Call Type (ACCT)
AES, AKA & message integrity support
Call Clearing of Voice and Circuit Data Calls (mobile initiated and network initiated)
Call Setup for Voice and Circuit Data Calls (mobile originated and mobile terminated)
Circuit Data Calls (asynchronous data and group-3 fax)
Circuit Switched Video Conferencing Calls
Circuit Voice and Packet Data Concurrent Services
Code Combining Soft Handoff (CCSH)
Direct Channel Assignment
1 Section 1
3GPP2 A.S0013-D v2.0
E911 Phase 1 and Phase 2 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Enhanced Rate Adaptation Mode (ERAM)
Event Notification
Flex Rate
Global Emergency Call Origination
Handoff
Handoff via MSC
Handoff via direct BS-to-BS signaling
Fast Handoff
Hard Handoff into Soft Handoff
Intergenerational Packet Data Handoff
Alternate dormant handoff
ISDN Interworking
Mobile Equipment Identifier (MEID) Support
Mobile Position Determination
Mobile Registration
Network Directed System Selection (NDSS)
New types of Public Long Code Mask (PLCM)
Over the Air Service Provisioning (OTASP)
Over the Air Parameter Administration (OTAPA)
Page Set Maintenance
PPP/IP packet boundaries using GRE segmentation
Priority Access and Channel Assignment (PACA)
Remote Transcoder Operation (RTO)
Rescue Channel
Reverse FCH Gating
Security Features
Terminal Authentication
Signaling Message Encryption
Voice/Data Privacy
Short Message Service (mobile originated, mobile terminated, and broadcast) (SMS)
Status Inquiry
Support of DTMF
Support for DS-41 base stations
Support for Enhanced Frequency Hashing and Band Subclasses
Support for cdma2000®1 Pre-Rev D MEID Capable Mobiles
1 cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.
Section 1 2
3GPP2 A.S0013-D v2.0
Support of Supplementary Services 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Feature Activation/Deactivation: Idle and In-Call
Call Waiting
Three-Way Calling
Message Waiting Notification
Call Barring
Calling Number ID Presentation (CNIP) and Calling Number ID Restriction (CNIR)
Distinctive Ringing
Answer Holding
User Selective Call Forwarding
Terrestrial Circuit Management
Test Calls
TFO Support
Transcoder Free Operation (TrFO)
User Zone
Vocoder Support
13K
Enhanced Variable Rate Codec (EVRC)
Selectable Mode Vocoder (SMV)
Wideband Speech Codec
Enhanced Variable Rate Codec rev. B (EVRC-B) on A2 and A2p
Enhanced Variable Rate Codec Wide Band (EVRC-WB) on A2 and A2p
Enhanced Variable Rate Codec Narrowband-Wideband (EVRC-NW) on A2 and A2p
Voice over IP (VoIP) Service
Voice Preference Over Packet (VPOP)
Features and Functions Transparently Supported in this Standard:
Advice of Charge
Call Delivery
Call Forwarding
Call Forwarding Unconditional
Call Forwarding When Busy
Call Forwarding – No Answer
Call Forwarding Default
Call Transfer
Carrier Access
Emergency Service (Basic) via specific dialed number (e.g., “911”)
Lawfully Authorized Wiretap
3 Section 1
3GPP2 A.S0013-D v2.0
Active Handoff (MC-41 to MC-41 and DS-41 to DS-41): the following types of handoffs are supported:
1
2
Type of Handoff
Voice calls
Async Data and G3 Fax
Packet Data Calls
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 Yesf Yese
* Inter-BS, Intra-MSC Hard Handoff Yes Yes Yesa Yese
Inter-BS, Inter-MSC Soft Handoff Yes Yes Yesf 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 are supported:
3
4
Type of Handoff
Voice calls
Async Data and G3 Fax
Packet Data Calls
* Inter-BS, Intra-MSC Hard Handoff Yes Yes Yesa
* Inter-BS, Inter-MSC Hard Handoff Yes No Yesb
* Hard handoff is not supported for the Supplemental Channels and Packet Data Channels in this revision of the standard.
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
a. Inter-BS, intra-MSC hard handoff may result in handoff across PDSN boundaries.
b. Inter-BS, inter-MSC hard handoff may result in handoff across PDSN boundaries. In addition, this requires extensions to ANSI-41 for packet data services.
c. Intergenerational handoff describes handoff of an MS between a system that supports packet data service as specified in [11]~[17] and a system that supports a packet data service as specified in [10].
d. The Service Option changes in this scenario.
e. Not applicable for DS-41 to DS-41 handoffs.
f. Soft/softer handoff is not applicable to the Forward Packet Data Channels. Soft/softer handoff is not supported for the Reverse Packet Data Channel in this revision of the standard. Inter-BS cell switching is not supported for the Forward and Reverse Packet Data Channels in this revision of the standard.
Soft handoff enhancements as specified in [10] are supported by this specification.
Access Handoff, Access Probe Handoff and CDMA Channel Assignment into Soft Handoff and Access Entry Handoff as specified in [10] are supported in this specification.
Access Entry Handoff is transparent to this standard.
Mobile-Assisted CDMA-to-CDMA Inter-Frequency Handoff Enhancement is supported as specified in [10].
Section 1 4
3GPP2 A.S0013-D v2.0
Circuit mode voice service assumptions: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
The following assumptions are made:
All MSs are capable of executing a service option change and a hard handoff simultaneously. That is, the Action Time for both of these activities may be the same.
For inter-vendor soft handoff, all target BS channel elements are capable of supporting 13K, EVRC, SMV (i.e., rate set 1 and rate set 2), EVRC-B, EVRC-WB, EVRC-NW and Wideband Speech Codec service options.
A default service configuration shall be used at all target BSs for hard handoff.
Hard handoff from 13K to EVRC is disallowed for TIA/EIA-95-B MSs.
For cdma2000 MSs, if the target BS does not have the proposed service option available, the target BS may send a new service option to the source BS.
Currently, only 13K (8000H and 0011H), EVRC, SMV, EVRC-B, EVRC-WB, EVRC-NW and Wideband Speech Codec voice service options are supported.
The default service option for IOS networks is operator configurable.
All MSs are capable of supporting the default voice service option.
Service negotiation is between the Base Station (BS) and the Mobile Station (MS).
Service negotiation only depends on the capabilities of the BS and of the MS.
If a change of vocoder type is necessary, the source BS can accomplish it by commanding the MS to execute a service option change and a hard handoff simultaneously. Thus, service negotiation messaging is not needed on either the A1 or A3 interfaces.
The following procedures are to be followed:
If the BS receives a Paging Request message from the MSC specifying a service option valid for this version of the IOS but not supported by the BS, the BS pages the MS with the service option in the Paging Request message.
If the BS receives an Origination Message / Paging Response Message from an MS specifying a service option not valid for this standard, the BS may deny the request. In the case of an originating call, the BS may order the MS to generate a local Reorder signal.
Otherwise, if the BS receives an Origination Message / Paging Response Message from an MS specifying a supported service option that is not supported on the particular BS, the BS shall send a CM Service Request message / Paging Response message to the MSC containing the service option received from the MS.
The MSC sends the service option that was received in the CM Service Request / Paging Response message in the Assignment Request message.
Otherwise, the call is handled using the call setup procedures of this specification.
In all cases, if a call is successfully set up, the BS shall inform the MSC of the agreed service option in the Assignment Complete message.
In the intra-MSC hard handoff scenario, if the source BS asks for a service option not supported by the target BS, then the MSC may reject the handoff request.
TrFO/RTO mode voice service assumptions:
1. A1p interface is used for call control and mobility management.
5 Section 1
3GPP2 A.S0013-D v2.0
2. Bearer formats for the A2p (and hence vocoders in use for the call) may be changed during the call.
1
2
3
4
5
6
7
8
9
10
11
12
3. The MGW shall be capable of transcoding. For TrFO and RTO calls, the A2p interface carries only compressed (i.e., vocoded) voice packets. For calls that are neither TrFO nor RTO, transcoding shall be supported in the MGW and may also be supported at the operator’s discretion in the BS2.
4. The decision on where (or if) transcoding is done is made by either the originating MSCe, the terminating MSCe, or both for call setup on a call-by-call basis.
5. Existing air interface traffic channel and service negotiation procedures between the BS and MS do not change.
6. In the logical reference architecture, the BS connects to either the MSCe or a circuit switched MSC, but not both.
1.1.1 Purpose 13
14
15
The purpose of this document is to provide IOS Feature Description (Stage 1) and IOS Feature Call Flows (Stage 2) for the access network features.
1.1.2 Scope 16
17
18
19
20
21
22
This document provides user level descriptions and access network call flows designed to assist in the development of the interfaces that coincide with the Reference Points: “A”, “Ater”, “Aquater”, and “Aquinter”, as defined in the Network Reference Model (refer to [I-2]), and Reference Points 48 and 27 as defined in Network Reference Model (refer to [31]). Refer to [14]~[17] for definitions of messages and timers used in this document.
1.2 References 23
24
25
26
27
References are either normative or informative. A normative reference is used to include another document as a mandatory part of a 3rd Generation Partnership Project 2 (3GPP2) specification. Documents that provide additional non-essential information are included in the informative references section.
1.2.1 Normative References 28
29
30
31
32
33
The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below.
2 The intent of allowing transcoding at the BS is to support needs of operators to make use of existing BS-based transcoders, and yet grow transcoding capabilities in the MGW. This supports a cap-and-grow strategy to allow operators to transition to MGW based transcoding. It is the intention of operators that all transcoder growth occur exclusively in MGWs.
Section 1 6
3GPP2 A.S0013-D v2.0
[1] 3GPP2 C.S0001-E v1.0, Introduction to cdma2000 Standards for Spread Spectrum Systems, May 2009.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
[2] 3GPP2 C.S0002-D v1.0, Physical Layer Standard for cdma2000 Spread Spectrum Systems, May 2009.
[3] 3GPP2 C.S0003-D v1.0, Medium Access Control (MAC) Standard for cdma2000 Spread Spectrum Systems, May 2009.
[4] 3GPP2 C.S0004-D v1.0, Signaling Link Access Control (LAC) Standard for cdma2000 Spread Spectrum Systems, June 2009.
[5] 3GPP2 C.S0005-E v1.0, Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems, June 2009.
[6] 3GPP2 C.S0006-D v2.0, Analog Signaling Standard for cdma2000 Spread Spectrum Systems, September 2005.
[7] Reserved. [8] 3GPP2 X.S0011-D v2.0, Wireless IP Network Standard, six parts, November
2008. [9] 3GPP2 X.S0004-E v8.0, Mobile Application Part (MAP), January 2009. [10] TIA/EIA-95-B, Mobile Station – Base Station Compatibility Standard for Dual-
Mode Wideband Spread Spectrum Cellular Systems, March 1999. [11] 3GPP2 A.S0011-D v2.0, Interoperability Specification (IOS) for cdma2000
Access Network Interfaces – Part 1 Overview, August 2009. [12] 3GPP2 A.S0012-D v2.0, Interoperability Specification (IOS) for cdma2000
Access Network Interfaces – Part 2 Transport, August 2009. [13] 3GPP2 A.S0013-D v2.0, Interoperability Specification (IOS) for cdma2000
Access Network Interfaces – Part 3 Features, August 2009. [14] 3GPP2 A.S0014-D v2.0, Interoperability Specification (IOS) for cdma2000
Access Network Interfaces – Part 4 (A1, A2,A1p, and A5 Interfaces), August 2009.
[15] 3GPP2 A.S0015-D v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces – Part 5 (A3 and A7 Interfaces), August 2009.
[16] 3GPP2 A.S0016-D v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces – Part 6 (A8 and A9 Interfaces), August 2009.
[17] 3GPP2 A.S0017-D v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces – Part 7 (A10 and A11 Interfaces), August 2009.
[18] TIA/EIA-553-A, Mobile Station – Base Station Compatibility Specification, November 1999.
[19] 3GPP2 C.S0015-B v2.0, Short Message Service (SMS) for Wideband Spread Spectrum Systems, Release B, September 2005.
[20] 3GPP2 C.S0016-C v2.0, Over the Air Service Provisioning of Mobile Stations in Spread Spectrum Systems, October 2008.
[21] 3GPP2 C.S0017-A all parts v1.0, Data Service Options for Spread Spectrum Systems, July 2004.
[22] 3GPP2 N.S0011-0 v1.0, OTASP and OTAPA, January 1999. [23] 3GPP2 N.S0019-0 v1.0, InterSystem Link Protocol, January 2000. [24] 3GPP2 C.S0022-B v1.0, Position Determination Service for cdma2000 Spread
Spectrum Systems, April 2009. [25] 3GPP2 A.S0004-B v2.0, CDMA Tandem Free Operation, August 2002. [26] 3GPP2 S.S0053 v2.0, Common Cryptographic Algorithms, May 2009. [27] 3GPP2 C.S0047-0 v1.0, Link-Layer Assisted Service Options for Voice-over-IP:
Header Removal (SO 60) and Robust Header Compression (SO 61), April 2003. [28] 3GPP2 X.S0001-A v1.0, MAP Enhancements for CDMA Packet Data Service
(C-PDS), April 2007. [29] 3GPP2 N.S0004-0 v1.0, WIN Phase 2, - Trigger for Preferred Language, Advice
of Charge, Rejection of Undesired Annoying Calls, Premium Rate Charging, Freephone, April 2001.
[30] 3GPP2 C.S0042-0 v1.0, Circuit Switched Video Conferencing Services, August 2002.
7 Section 1
3GPP2 A.S0013-D v2.0
[31] 3GPP2 X.S0012-0 v2.0, Legacy MS Domain Step 1, March 2004. 1
2
3
4
5
6
7
8
9
10
11
[32] 3GPP2, C.S0072-0 v1.0, Mobile Station Equipment Identifier (MEID) Support for cdma2000 Spread Spectrum Systems, July, 2005.
[33] 3GPP2 X.S0006-0 v1.0, MAP Support of Authentication and Key Agreement (AKA), October 2005.
[34] IETF, RFC 2002 – IP Mobility Support, October 1996. [35] IETF, RFC 2784 – Generic Routing Encapsulation (GRE), September 2000. [36] IETF, RFC 3115 – Mobile IP Vendor/Organization-Specific Extensions, April
2001. [37] IETF, RFC 3550 – RTP: A Transport Protocol for Real Time Applications, July
2003.
1.2.2 Informative References 12
13
14
15
16
[I-1] 3GPP2 S.R0006-A v1.0, Wireless Features Description, June 2007. [I-2] 3GPP2 S.R0005-B v2.0, Network Reference Model for cdma2000 Spread
Spectrum Systems, May 2007.
1.3 Terminology 17
18
1.3.1 Acronyms 19
20
Acronym Meaning 2G Second Generation
3G Third Generation
3GPP2 Third Generation Partnership Project 2
AAA Authentication, Authorization and Accounting entity
AC Authentication Center
ACCT Access Control by Call Type
ADDS Application Data Delivery Service
AES Advanced Encryption Standard
AH Answer Holding
AKA Authentication and Key Agreement
AMPS Advanced Mobile Phone System
APM Access Parameters Message
ASCII American Standard Code for Information Interchange
AUTHBS Authentication
AUTHR Authentication Response
AUTHU Unique Challenge Authentication Response
AV Authentication Vector
BCD Binary Code Decimal
BS Base Station
Section 1 8
3GPP2 A.S0013-D v2.0
Acronym Meaning BSC Base Station Controller
BTS Base Transceiver System
CANID Current Access Network Identifiers
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
DS-41 Direct Spread (ANSI)-41
DTMF Dual Tone Multi-Frequency
DTX Discontinuous Transmission
EAPM Enhanced Access Parameters Message
EIA Electronics Industry Association
EPSMM Extended Pilot Strength Measurement Message
ERAM Enhanced Rate Adaption Mode
ESCAM Extended Supplemental Channel Assignment Message
EVRC Enhanced Variable Rate Codec
EVRC-B Enhanced Variable Rate Codec rev. B
EVRC-WB Enhanced Variable Rate Codec Wide Band
EVRC-NW Enhanced Variable Rate Codec Narrowband-Wideband
FCH Fundamental Channel
FDC Flex Duplex Channel
FER Frame Error Rate
F-PDCH Forward Packet Data Channel
GRE Generic Routing Encapsulation
HLR Home Location Register
IE Information Element
IETF Internet Engineering Task Force
IMSI International Mobile Subscriber Identity
IOS Interoperability Specification
IP Internet Protocol
IS Interim Standard
ISDN Integrated Services Digital Network
ISLP Intersystem Link Protocol
9 Section 1
3GPP2 A.S0013-D v2.0
Acronym Meaning IWF Interworking Function
MC Message Center (alternatively: Mobile Client)
MC-41 Multi-Carrier (ANSI)-41
MGW Media Gateway
MIP Mobile IP
MS Mobile Station
MSC Mobile Switching Center
MSCe Mobile Switching Center Emulation
MWI Message Waiting Indication
NID Network Identification
NDSS Network Directed System Selection
NVSE Normal Vendor Specific Extension
OAM&P Operations, Administration, Maintenance, and Provisioning
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
PDSI Packet Data Service Instance
PDS Position Determination Services
PDSN Packet Data Serving Node
PIN Personal Identification Number
PLCM Public Long Code Mask
PPP Point to Point Protocol
PZID Packet Zone Identifier
RAN Radio Access Network
RAND Random variable
RANDBS Random variable - BS
RANDSSD Random SSD
RANDU Random variable – Unique challenge
RF Radio Frequency
RLP Radio Link Protocol
RN-PDIT Radio Network Packet Data Inactivity Timer
RTO Remote Transcoder Operation
RTP Real Time Protocol
R-PDCH Reverse Packet Data Channel
SAT Supervisory Audio Tone
Section 1 10
3GPP2 A.S0013-D v2.0
Acronym Meaning
1
SCCP Signaling Connection Control Part
SCH Supplemental Channel
SDB Short Data Burst
SDU Selection/Distribution Unit
SID System Identification
SIP Session Initiation Protocol
SME Signaling Message Encryption
SMS Short Message Service
SMS-MO SMS Mobile Originated
SMS-MT SMS Mobile Terminated
SMV Selectable Mode Vocoder
SO Service Option
SOCI Service Option Connection Identifier
SR_ID Service Reference Identifier
SSD Shared Secret Data
TCH Traffic Channel
TDSO Test Data Service Option
TFO Tandem Free Operation
TIA Telecommunications Industry Association
TrFO Transcoder Free Operation
UDI Unrestricted Digital Information
UDP User Datagram Protocol
VoIP Voice over IP
VPOP Voice Preference Over Packet
1.3.2 Definitions 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Refer to [11] for additional definitions.
DS-41: An operational mode in which the BS and MS operate with the direct spread (DS) radio layers of the UMTS system defined by 3GPP, and the upper layers defined in IS-2000 that conform to and interoperate with ANSI-41 based networks.
MC-41: An operational mode in which the BS and MS operate with the multi-carrier (MC) radio layers and the upper layers defined in IS-2000 that conform to and interoperate with ANSI-41 based networks.
origination message:
In this document, “origination message” is used to indicate either an Origination or Enhanced Origination air interface message.
In this document, “MSC” refers to either a circuit-switched MSC or a packet-based MSC emulator (MSCe). In situations where a statement applies to either the circuit-switched or packet-based MSC exclusively, the type of MSC is specifically identified (i.e. “circuit-
11 Section 1
3GPP2 A.S0013-D v2.0
switched MSC” or “MSCe”). For signaling, the term MSC refers to either a circuit-switched MSC or an MSCe. For bearer path, the term MSC refers to either a circuit-switched MSC or a MGW.
1
2
3
1.4 Call Processing and Supplementary Services Assumptions 4
5
6
7
8
9
This section contains assumptions for call processing and supplementary services.
In some of the call processing and services functions, it is possible that an inter-BS hard handoff may occur during the process. In such an event, the target BS (i.e., the BS to which the MS has been handed off) shall assume responsibility for functionality ascribed to the BS as defined herein.
1.4.1 Call Control 10
11
12
Call control shall be primarily the responsibility of the MSC. The BS provides message transmission and interworking between the particular air interface and the MSC.
1.4.1.1 A2, and A5 Bearer Allocation 13
14
15
16
17
18
19
20
21
The circuit switched MSC manages Terrestrial Circuit allocation on the A2 and A5 interfaces in the following manner:
The circuit switched MSC considers the interface to the BS as a route of “n” circuits. The circuit switched MSC shall therefore ensure that the terrestrial circuit chosen is able to support the type of call involved.
The BS may suggest a preferred terrestrial circuit to the circuit switched MSC, in which case, the circuit switched MSC shall use the suggested terrestrial circuit if available. Refer to section 2.28 for the definition of “available”.
1.4.1.2 Radio Channel Allocation 22
23
24
The BS allocates the radio channel to be used. This may be based on information received from the MSC.
1.4.1.3 Traffic Channel Release 25
26
27
The release of a dedicated resource is primarily controlled by the MSC. However, for radio propagation reasons, the BS may request that the MSC release a call.
1.4.1.4 A3 User Traffic Subchannel Allocation 28
29
30
31
32
The target BS considers the interface to the SDU as a route of multiple A3 User Traffic Subchannels. The target BS chooses an A3 User Traffic Subchannel from the idle A3 User Traffic Subchannels connected to the SDU where the call being processed is anchored.
1.4.1.5 A2p Bearer Allocation 33
34
35
The MSCe and BS manage RTP session allocation on the A2p interface in the following manner:
Section 1 12
3GPP2 A.S0013-D v2.0
The A2p interface supports several RTP sessions. Refer to [37]. 1
2
3
4
5
6
7
8
Sessions in the context of this section are RTP associations that are used to carry packet voice traffic between the MGW and the BS. An RTP session is relevant only when the call is up and is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP).
The BS selects the IP address and port assignments for its bearer termination point. The MSCe selects or obtains the IP address and port assignments for the MGW termination point.
1.5 Radio Resource Management Assumptions 9
10 This section contains assumptions about radio resource management.
1.5.1 Radio Channel Supervision 11
1.5.1.1 Traffic Channel Radio Link Supervision 12
13
14
Radio link supervision of dedicated radio resources shall be the responsibility of the BS. If communication with the MS is lost then the BS can request that the call be cleared.
1.5.1.2 Idle Channel Observation 15
16 The quality of idle radio channels may be measured by the BS.
1.5.2 Radio Channel Management 17
1.5.2.1 Radio Channel Configuration Management 18
19
20
21
The channel configuration management shall be controlled between the BS and the Operations System (OS) over the “O” interface. The BS shall be able to support one cell or multiple cells. The “O” interface is beyond the scope of this specification.
1.5.2.2 Radio Traffic Channel Management 22
23
1.5.2.2.1 Radio Channel Allocation 24
25 The BS shall always choose the radio channel to be used.
1.5.2.2.2 Radio Traffic Channel Release 26
27
28
The release of a dedicated radio resource is primarily controlled by the MSC. However, for radio propagation reasons the BS can request of the MSC that a call be released.
1.5.2.2.3 Radio Traffic Channel Power Control 29
30 All power control functions shall be performed between the MS and the BS.
13 Section 1
3GPP2 A.S0013-D v2.0
Section 1 14
1.5.2.2.4 Channel Encoding and Decoding 1
2
3
4
5
6
The radio channel encoding and decoding, and interleaving shall be performed by the BS. The type of radio channel coding and interleaving is derived from the information in the air interface messages from the MS and the Assignment Request message or Bearer Update Request message from the MSC. Refer to [14] for information on this message.
3GPP2 A.S0013-D v2.0
2.0 Feature Descriptions 1
2
2.1 Call Setup of Voice and Circuit Data Calls 3
4
5
6
7
8
9
10
11
12
13
Call setup is a process where a sequence of messages is used to advance the call to a stable condition where the parties involved may communicate.
The call setup may be a normal call setup, emergency call setup, SMS, OTAPA, PACA call setup, or other supplementary service invocation.
Call Setup messages are defined in [14].
Refer to section 3.1.1 for mobile originated call flows and section 3.1.2 for mobile terminated call flows associated with this feature. An MS-to-MS call is handled as a combination of a mobile originated and a mobile terminated call. Tandem Free Operation (TFO) or Transcoder Free Operation (TrFO) may be applied for MS-to-MS calls to enhance speech quality, refer to sections 2.3 and 2.34.
2.2 Call Clearing of Voice and Circuit Data Calls 14
15
16
17
18
19
20
21
22
23
24
25
Call clearing is a process where a sequence of messages is used to free in a controlled manner all resources in the network associated with one or all service instances of an MS.
There are two types of call clearing:
1. Call clearing of a single service, when other services are connected.
2. Call clearing of all services connected (including the case where only one service is connected).
Call clearing may be initiated by either the BS, the MS, or the MSC.
Call clearing collision occurs when two entities independently initiate the call clearing procedures; refer to section 3.2.3 for description of cases of call clearing collisions.
Refer to section 3.2 for call flows related to this feature. Refer to section 3.18 for call flows related to concurrent services.
2.2.1 Call Clearing Initiated by the MS or BS 26
27
28
29
30
31
32
33
34
When the MS initiates a normal clearing of all services including the only service connected, the MS sends a Release Order to the BS. The BS shall send a Clear Request message to the MSC and wait for the Clear Command message from the MSC. The call flow scenario is illustrated in section 3.2.4.1.
The circuit switched MSC is responsible for clearing A1, A2, and/or A5 connections associated with the call. The MSCe is responsible for clearing A1p and A2p sessions associated with a call. To release all allocated resources associated with all services, the MSC shall send a Clear Command message to the BS..
15 Section 2
3GPP2 A.S0013-D v2.0
The MS may also initiate a release of a service that is not the only service connected to the MS. The scenario is illustrated in section 3.18.4.1.
1
2
3
4
5
If for any reason the radio channel failed between the MS and the BS or if some internal BS failure occurs, then the BS initiates call clearing. The BS sends a Clear Request message to the MSC. The scenario is illustrated in section 3.2.4.2.
2.2.2 Call Clearing Initiated by the MSC 6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
When the circuit-switched MSC chooses to deny call setup initiated by the reception of a CM Service Request or Paging Response message contained in an SCCP Connection Request, the circuit-switched MSC may send an SCCP Connection Refused containing no user data. Refer to [12].
When the MSCe chooses to deny call setup initiated by the reception of a CM Service Request or Paging Response message contained in a SUA Connection Request, the MSCe may send an SUA Connection Refused containing no user data. Refer to [12].
When the MSC initiates a normal clearing of a single service that is not the only service connected, the MSC sends a Service Release message to the BS. This normal call clearing scenario is illustrated in section 3.18.4.2.
In case the MSC initiates a normal clearing of all services, the MSC shall send a Clear Command message to the BS. This normal call clearing scenario is illustrated in section 3.2.4.3.
Call clearing messages are not affected if the network provides either tones or announcements immediately before clearing a call.
2.3 Tandem Free Operation (TFO) Support 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
MS-to-MS calls are handled as a combination of mobile originated and mobile terminated calls. For information on Tandem Free Operation, refer to [25]. This feature applies only to circuit-switched MS-to-MS voice calls.
It is generally known that tandeming of vocoders results in noticeable audio degradation. Although some vocoders handle tandeming better than others, all suffer from this effect. Such tandeming occurs in an MS-to-MS digital call.
For an MS-to-MS digital call, vocoding currently takes place at both the originating and terminating SDUs. Encoded audio received at the SDU is decoded and subsequently routed to the terminating SDU via the MSC(s). At the terminating SDU, the decoded voice is encoded again prior to transmission over the air. This “tandem” vocoding results in an audio quality degradation and increased throughput delay compared to an MS-to-land or land-to-MS call.
The TFO feature enhances current operation by bypassing the vocoding process at the SDU(s) for MS-to-MS calls. If both MS parties are using the same voice service option, the encoded voice received from the BTS is not decoded at the SDU. Instead the encoded voice is converted to the appropriate MSC/BS signaling format (e.g., rate adapted to a 64K DS0 timeslot, but not decoded) for transmission through the MSCs. The terminating MSC in turn routes the encoded speech to the appropriate SDU where it is converted back to the appropriate signaling format for routing to the BTS.
Section 2 16
3GPP2 A.S0013-D v2.0
TFO setup operation relies on inband signaling exchange between the SDUs. The SDUs use inband signaling to determine when it is appropriate to establish TFO operation. Refer to
1
2
3
4
5
6
7
8
9
10
11
12
[25] for complete details regarding the inband signaling protocol.
The TFO feature also provides the capability of controlling TFO operation via “out-of-band” signaling. Specifically, the Transcoder Control Request and Transcoder Control Acknowledge messages could be used over the A1 interface to disable/enable the inband signaling mechanism at the SDUs. Disabling the inband signaling mechanism, forces the call to revert to tandem vocoding mode. These same messages can also be used to re-start/enable the inband signaling protocol at the SDUs. This capability is beneficial for supplementary feature interaction scenarios (e.g., Answer Hold and Three Party Conferencing).
Refer to section 3.3 for call flows associated with this feature.
2.4 Test Calls 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
The purpose of test calls is to generate test data (e.g., frame error rate (FER), forward and reverse link capacity estimates, etc.) for performance analysis. These calls need not require any trunks (DS0 circuits) on the A2 interfaces or sessions on the A2p interface. Therefore, these interfaces are not affected by test calls. The MS or the MSC may initiate a test call.
The test data service option (TDSO) provides for the generation of an arbitrary (preselected or random) data source for transport over forward and reverse traffic channels while following an arbitrary (preselected or random) transmission frame activity. The test is performed at a fixed data rate. The MS and the BS generate test data frames for the configured and allocated traffic channels. The frame generation processes are synchronized between the MS and the BS. This permits the receiving station to reproduce the transmitted frames and compare them to the received frames.
The Markov service option provides pseudo-random data for testing the Fundamental Channel between the MS and the BS. The test can be performed at a fixed data rate or at a variable data rate. A pseudo-random process governs the selection of the data rate for each data block in a variable rate test. A pseudo-random process also generates the content of each data block. The pseudo-random processes are synchronized between the MS and the BS. This permits the receiving station to reproduce the transmitted data blocks and compare them to the received data blocks.
The loopback service options provide a loopback of primary traffic information bits through the MS. These service options provide the means for a BS to supply a known data stream on both the Forward and Reverse traffic channels so that an MS’s receiving and transmitting performance can be measured. In addition, these service options provide a convenient means of setting up calls and generating traffic for system testing.
When the test call uses a TDSO, Markov, or loopback operation, reception of any supplementary service messages or inter-BS hard handoff requests may be considered unexpected and may be ignored.
Hard handoff is not supported for test calls.
Refer to section 3.4 for call flows associated with this feature.
17 Section 2
3GPP2 A.S0013-D v2.0
2.5 Support of DTMF 1
2
3
4
5
6
7
8
9
10
11
12
13
14
DTMF digit transmission can be sent using in-band tones between the MS and MSC once a call is in Conversation State. No action is required by the BS for transmission of in-band DTMF signals.
Alternatively, DTMF digits may be sent in a Send Burst DTMF Message over the air interface, refer to [5]. On the A2 interface, in the MS to network direction, the BS is required to generate the DTMF tones and inject them into the 64 kbps PCM stream. On the A2p interface, the BS is required to generate RTP packets containing DTMF payloads and inject them on the appropriate RTP session towards the MGW.
In the network to MS direction, the BS may extract the DTMF signal from the 64 kbps PCM stream received via the A2 interface and generate the Send Burst DTMF Message to be delivered over the air interface. The BS may generate a Send Burst DTMF message over the air for RTP packets containing DTMF payloads received on the A2p interface.
There are no call flows associated with this feature.
2.6 Support of Supplementary Services 15
16 Overview descriptions of these features are given in the following subsections.
2.6.1 Feature Activation and Deactivation 17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Feature Activation/Deactivation is invoked by the MS by sending either the Flash With Information Message, Origination Message, or Enhanced Origination Message to the network. The mobile subscriber activates, deactivates, registers, and erases a supplementary service by entering a digit string at the MS which is sent to the MSC. The MSC performs digit analysis on the dialed digits to determine that the subscriber requires a supplementary service operation and processes the request.
Feature activation/deactivation in idle mode is accomplished by the sending of a string of digits and end marks (*, #) that identify the feature to be activated/deactivated, along with any additional PIN information, called party number, etc. in a mobile origination. The MSC, after doing digit analysis, determines that the request is for feature activation/deactivation, processes the request, and gives the MS an indication of the acceptance or rejection of the request using normal call setup procedures. After taking appropriate action (e.g., setting up a call and playing a tone or announcement), the MSC or MS may initiate call clearing. No special action is required at the BS to process supplementary service requests using this method. Refer to the message flow diagrams for the mobile originated call setup (section 3.1.1) for an illustration of this message handling.
Feature activation/deactivation while in a call is accomplished by sending a string of digits and end marks (*, #) that identify the feature to be activated/deactivated, along with any additional PIN information, called party number, etc. in an air interface Flash with Information message or Enhanced Origination message from the MS to the BS and in a Flash with Information message or Additional Service Request message from the BS to the MSC. Any response by the MSC to the BS is via in-band signals provided by the MSC. Such actions are treated as activities that are independent of the Flash with Information messages going in the other direction.
Refer to section 3.6.1 for the call flow associated with this feature.
Section 2 18
3GPP2 A.S0013-D v2.0
2.6.2 Call Waiting 1
2
3
4
5
6
7
8
9
10
11
12
13
Call Waiting provides notification to a subscriber of an incoming call while the subscriber is in the Conversation State. Subsequently, the subscriber can either answer or ignore the incoming call. If the subscriber answers the second call, it may alternate between the two calls. For additional description, refer to [I-1].
The Call Waiting notification of the incoming call is sent as Flash with Information messages to the MS from the MSC via the BS, or, alternatively, the Call Waiting notification is sent as an in-band tone between the MS and the MSC.
The second call (Call Waiting call) is answered by the MS by sending a Flash with Information message to the MSC via the BS. The MS may alternate between the two calls by sending Flash with Information messages to the MSC via the BS.
This feature is activated according to Feature Activation described in section 2.6.1.
Call flows associated with this feature can be found in section 3.6.2.
2.6.3 Three Way Calling 14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Three Way Calling provides the controlling subscriber the capability of adding a third party to an established two-party call, so that all three parties may communicate in a call. If either of the two non-controlling parties in an established three-party call disconnects, the remaining party is reconnected to the controlling subscriber as a normal two-party call. If the controlling subscriber of a three-party call disconnects, all other parties are released.
An MS requests three-way calling by sending a Flash with Information message to the BS, which forwards this request to the MSC. This message puts the remote party on hold. This request may include the address of the third party that is to be included in the three-party call. If the initial Flash with Information message does not included the address of the third party, the MS sends a subsequent Flash with Information containing the third party address.
A call is established to the third party address. When the call is answered, the MS establishes the three-way call by sending a Flash with Information to the BS, which forwards it to the MSC, which places all three parties in a conference call.
For further description, refer to [I-1].
Call flows associated with this feature can be found in section 3.6.3.
2.6.4 Message Waiting Notification 32
33
34
35
36
37
38
39
Message Waiting Notification (MWN) informs a subscriber when a voice message is available for retrieval. The MWN may use different types of indications to inform a subscriber of an unretrieved voice message.
The Feature Notification message is used to deliver a Message Waiting Indication (MWI) to the MS while it is idle. There is a possible race condition when the Feature Notification message is sent while an MS is originating a call. If this occurs, the message waiting indication may not be successfully delivered. It is recommended that the MSC
19 Section 2
3GPP2 A.S0013-D v2.0
request an acknowledgment with the Feature Notification message, and resend the MWI information on the traffic channel, if necessary.
1
2
3
4
5
6
7
The Flash with Information message is used to deliver a Message Waiting Indication while the MS is on a traffic channel, i.e., after an Assignment Complete message has been received at the MSC.
For further description, refer to [I-1].
Refer to section 3.6.4 for the call flows associated with this feature.
2.6.5 Call Barring 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Call Barring provides the possibility to bar a subscriber from originating calls and receiving calls. This may exclude emergency numbers. The reason a subscriber is barred from originating or receiving calls is defined as an implementation issue. Call Barring can be of the following types:
Origination denied.
Termination denied.
Local calls only.
Selected leading digits of directory number.
Selected leading digits of directory number and local calls only.
National long distance (including local calls and may include neighboring counties).
International calls (includes national long distance and local calls).
Single Directory Number (only number allowed).
Call Barring Incoming is transparent to the IOS interfaces.
Call Barring Outgoing requires the MSC to assign a channel to the originating MS, apply call treatment (e.g. announcement to mobile subscriber on the traffic channel) and then clear the call after treatment has been applied. Note that the subscriber may also initiate call clearing upon hearing the announcement or other appropriate treatment (e.g., tones).
Refer to section 3.6.5 for the call flow associated with this feature.
2.6.6 Calling Number ID Presentation / Restriction 27
28
29
30
31
32
33
34
35
Calling Number ID Presentation provides the number identification of the calling party to the called subscriber.
Calling Number ID Restriction restricts presentation of the subscriber’s Calling Number Identification to the called party. The Calling Number ID Restriction may be made permanently or temporary on the subscriber’s request.
The following subsections describe the support for:
Calling Number Identification Presentation (CNIP).
Calling Number Identification Restriction (CNIR).
Section 2 20
3GPP2 A.S0013-D v2.0
2.6.6.1 CNIR for Mobile Originated Calls 1
2
3
4
For CNIR, the calling party can request CNIR on a per call basis by including the feature code before the Called Party Number digits in the Called Party BCD Number or Called Party ASCII Number in the CM Service Request message.
2.6.6.2 CNIP/CNIR for Mobile Terminated Calls 5
6
7
8
9
10
11
12
13
14
15
16
17
18
There are two types of CNIP/CNIR supported:
1. If the MS is idle, for mobile terminated calls, the CNIP/CNIR information is sent in the Assignment Request message. The call flows for this feature are identical to the call flows for a mobile terminated call, refer to section 3.1.2.
2. If the MS user subscribes to the Call Waiting (CW) feature and is engaged in a call, the CNIP/CNIR information is sent in the Flash with Information message. The call flow for this feature is identical to the call flow for Call Waiting, refer to section 3.6.2.
The MSC codes the presentation restriction information as “presentation allowed” when providing text, e.g., “Unknown Number” or “Private Number”, corresponding to the cases when the number is not available or is presentation restricted. When the “screening indicator” is not provided or can not be determined, a default value of “network provided” is recommended.
2.6.7 Distinctive Ringing 19
20
21
22
23
24
25
26
Distinctive Ringing provides the MS with the possibility to receive information from the MSC to create a distinctive ring signal.
The A1 and A1p interfaces use the Signal element or the MS Information Records element to carry information to the MS via the BS, concerning the specific ringing pattern to be used. Refer to [14].
The call flows for this feature are identical to the call flows for a mobile terminated call, refer to section 3.1.2.
2.6.8 Answer Holding 27
28
29
30
31
32
33
34
35
36
37
38
39
Answer Holding (AH) provides a called subscriber the capability to answer the call, but selectively delay the conversation (e.g., calls in the alerting or Call Waiting State). The incoming call is provided an appropriate network announcement to notify the calling party to please hold.
AH is also applicable to incoming calls being delivered to called AH authorized subscribers as Call Waiting (CW) calls.
This feature is activated according to Feature Activation described in section 2.6.1.
The MS uses the Flash with Information message to invoke Answer Holding in the Alerting and Call Waiting State. The Flash with Information message is also used to toggle between two calls, one of which in Answer Holding State, while in Call Waiting State.
Call flows for Answer Holding are shown in section 3.6.8.
21 Section 2
3GPP2 A.S0013-D v2.0
2.6.9 User Selective Call Forwarding 1
2
3
4
5
6
7
8
9
10
11
12
13
User Selective Call Forwarding provides a called subscriber the capability to selectively redirect unanswered, incoming calls to an alternate destination (e.g., to a voice mail system, to a network registered Directory Number, or to a Directory Number stored in the MS). User Selective Call Forwarding is applicable both to calls being offered to a subscriber via alerting and to calls being offered to a subscriber via Call Waiting Notification.
This feature is activated according to the Feature Activation described in section 2.6.1:
The Forward-To-Number registration is handled by the regular Feature Activation feature.
When an MS is in the alerting state, or in the Conversation State and receiving a Call Waiting Notification, the MS sends a Flash with Information to invoke this feature.
Call flows for User Selective Call Forwarding are shown in section 3.6.9.
2.7 Mobile Registration 14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Mobile registration is a process whereby MS characteristics such as location or status are provided to the network. Registration may be initiated by the MS, by the network, or implied during an MS access.
The MSC may infer registration information based on an MS’s system access. This form of registration is transparent to the BS and the MS, and requires no additional message passing over the A1 or A1p interface.
The MS may initiate registration for a number of reasons. The types of registration performed are enabled and controlled through parameters transmitted by the BS on the forward (downlink) control channels. Selection of control channel parameters and enabling of specific registration types are beyond the scope of this specification.
The network may initiate an ordered registration procedure. The ordered registration procedure allows a MSC to request the MS to register.
Network may autonomously register an MS (refer to [28]) and direct the BS to notify the MS that the network has registered it.
Refer to section 3.7 for call flows associated with this feature.
2.8 Global Emergency Call Origination 30
31
32
33
34
35
36
37
The phone number required to access a Public Safety Answering Point (emergency assistance) in a given geographic area may not be known to the user. In fact, there may be different access numbers for difference agencies (e.g., police, fire, medical).
Global Emergency Call Origination is a mechanism whereby the user initiates an emergency service call via some vendor specific means. The MS Origination Message includes an indication that this is an emergency service request and the network handles the call accordingly.
Section 2 22
3GPP2 A.S0013-D v2.0
The MS Origination Message may include user dialed digits. The network may use the dialed digits, if present, to determine more specific information regarding the type of emergency support requested.
1
2
3
4 Normal mobile originated call setup call flows apply to this feature; refer to section 3.1.1.
2.9 E911 Phase 1 and Phase 2 5
6
7
8
9
10
11
12
13
14
15
For E911 phase 1, the CM Service Request message provides the location of the E911 MS and also provides the MSID (IMSI) of the MS to be used for the callback number.
For E911 phase 2, this standard supports delivery of the mobile location data from the MS to a Position Determining Entity (PDE). Procedures and protocols used on the interface between the PDE and other network entities are outside the scope of this standard. Further, this standard assumes that all involved elements (i.e. MS, BS, MSC and PDE) conform to [24]. The PDE functionality resides in the core network. The MSC conveys BS-supplied, position related information for an MS to the PDE.
Call back feature is transparently supported by the normal call establishment procedures. Refer to section 3.13 for call flows associated for this feature.
2.10 Short Message Service 16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
The Short Message Service (SMS) provides for the transfer of short messages between an application residing on an MS and an application within the network, e.g., at a Message Center (MC). The MSC and BS provide a conduit for these short messages. Other network procedures carried out by entities providing an SMS, are beyond the scope of this standard (refer to [9]).
Three types of basic short messaging are supported: mobile originated point-to-point, mobile terminated point-to-point, and broadcast. Both mobile originated and mobile terminated point-to-point short messaging may require that messages be exchanged in both directions on the air interface.
Short messages can be exchanged between the MS and BS on both the control and traffic channels. Thus, an active MS is able to send and receive short messages at any time. The maximum number of short message characters that can be handled varies with the air interface and teleservice type employed. Each short message shall be carried within a single message on the A1 or A1p interface. No provision is made for segmentation and reassembly of short messages.
The Short Message Service is divided into a number of protocol layers: the SMS teleservice layer, the SMS transport layer, and the SMS relay layer (refer to [19]). The relay layer may sit on top of other air interface layers. Not all air interfaces may support the full range of SMS capabilities and layers. All of these layers are transparent to the A1 or A1p interface, and are carried as part of the SMS user part element in the A1 or A1p interface messages.
For point-to-point delivery, the MSC can request that the BS report that a Layer 2 Ack was received from the MS. This indicates that the MS received the short message. In addition, both the transport and teleservice layers may generate acknowledgments (refer to [19]) but these acknowledgments are transparent to the A1 or A1p interface.
23 Section 2
3GPP2 A.S0013-D v2.0
The scope of the requirements and specifications outlined in this document are limited to the A1 and A1p interfaces, as defined in the Network Reference Model (refer to
1
2
3
4
[I-2]). Descriptions of operations at other interfaces are included for information only.
Refer to section 3.10 for call flows associated with this feature.
2.11 Priority Access and Channel Assignment (PACA) 5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
PACA (Priority Access Channel Assignment) allows a user to have priority access to traffic channels on call origination. When the traffic channel is not available, the BS can queue the MS and update the queue position subsequently. When a traffic channel becomes available, the BS serves the MS based on first come first served within a priority.
The subscriber has two options for invocation of PACA: Permanent or Demand (refer to [I-1]). In the permanent option, the feature is always available and is used automatically whenever the user attempts to originate a call. In the demand option, the feature is available only on request via dialing the feature code before the telephone number at the time of origination for that specific call.
By sending the PACA Message over the air-interface, the BS can notify the user that the call is queued, the queue position is updated, or the PACA call should be re-originated. When the PACA call is enabled, the MS shall operate in non-slotted mode. If the MS is directed by the user to cancel the queued PACA call, the MS shall send the PACA Cancel Message.
Two conditions may occur on a call origination with PACA service. In the first condition, the BS can not determine the availability of radio resources before sending the CM Service Request to the MSC. Thus, the BS sends the Radio and Environment Resources Information element (without indicating the availability of its radio resources) in the CM Service Request message to the MSC. Refer to [14] for further explanations of this message and information element. In this case, the origination call flows shown in section 3.1.1 are followed.
In the second case, the BS determines that radio resources are not available before sending the CM Service Request. The BS sends an indication in the CM Service Request message to notify the MSC that the radio resources are unavailable. In this case, the origination call flow shown in section 3.11 is followed.
The PACA Service feature is defined based on the following principles:
The PACA queue is maintained and managed at the BS.
The MSC assigns the priority level and time of a PACA eligible call and informs the BS in the Assignment Request or PACA Command message.
The MSC manages the timestamp information for the PACA call and assists in maintaining the priority while the MS is roaming within the system by passing the timestamp information to the new BS in the Assignment Request or PACA Update message.
The BS may keep the MS informed of the updated queue position.
The BS informs the MSC in case of re-origination of a PACA call using the CM Service Request message.
The PACA call can be canceled implicitly or explicitly by the MS, the BS or the MSC.
Section 2 24
3GPP2 A.S0013-D v2.0
Refer to section 3.11 for call flows associated with this feature. 1
2 2.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration (OTAPA) 3
4 Overviews and descriptions of these features are given in the following subsections.
2.12.1 OTASP Support 5
6
7
8
9
10
11
Normal call setup procedures for voice calls are used to establish an OTASP call. The mechanism for transporting OTASP data messages over the air interface is defined in [20]. The processing of OTASP data messages at the MSC or BS is the responsibility of the vendors. OTASP data messages are transported on the A1 or A1p interface via the ADDS Deliver/Ack messages. The MSC interface to the network is addressed in [22].
Refer to section 3.12.1 for the call flow associated with this feature.
2.12.2 OTAPA Support 12
13
14
15
16
17
18
19
OTAPA is supported in this specification by the ADDS Deliver/Ack set of messages. A specific Service Option (18 or 19) is required to set up the call. No specific messages or information are required beyond the messages necessary to set up a mobile terminated call and to transfer ADDS messages. The only requirement for the BS is to provide interworking between the air interface and the A1 or A1p interface for these messages. The use of these messages by the MS and the MSC is beyond the scope of this specification.
2.13 Mobile Position Determination 20
21
22
23
24
This section includes descriptions of how to support determination of the MS’s position. Various approaches are possible. The supported approaches are discussed in the following subsections.
2.13.1 Support of Position Determination Services (MS – PDE Approach) 25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Position Determination Services (PDS) provides for the transfer of position location data between an application residing on an MS and an application within the network (i.e. Position Determining Entity (PDE)). Normal call setup procedures for voice calls are used to establish a Position Determination Services call. The mechanism for transporting position location data over the air interface is defined in [20]. Other network procedures carried out by entities providing PDS are beyond the scope of this standard.
Position location data is transferred between the MSC and BS using ADDS procedures and between the BS and the MS on both the control and traffic channels. Normally the ADDS messages are used to carry application data between the MS and the MSC which is transparent to the BS; however, for PDS applications a BS may trigger the position determination process. Thus, an active MS is able to send and receive PDS messages at any time. The position location data and associated messaging is defined in [24]. This data is transparent to the A1 or A1p interface, and is carried as part of the ADDS User Part element.
25 Section 2
3GPP2 A.S0013-D v2.0
Refer to section 3.13.1 for call flows associated with this feature. 1
2
3
4
NOTE: In prior versions of this specification Position Determination Services were referred to as Position Location Determination (PLD).
2.13.2 Software Calculation Position Determination (BS – MSC Approach) 5
6
7
8
9
10
11
12
13
14
15
16
Through the use of software calculation techniques, a network based position determination process can take advantage of the radio interface parameters and measurements to determine the location of an MS that is on a traffic channel. The messages used to support this approach are applicable to both network based and mobile-assisted position determination. The MSC requests certain measurements and parameters from the BS, and the BS provides those measurements in a response message. Calculations then take place to determine the location of the MS.
For PDS applications that have a base station based position determination process, the BS may return the Geographic Location IE in the Radio Measurements for Position Response message.
Refer to section 3.13.2 for call flows associated with this feature.
2.14 User Zone 17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
The concept of User Zones is important to the operation of CDMA Tiered Services; refer to [5]. It is via User Zones that the network offers custom services based upon the MS location.
User Zones are associated with a set of features and services, plus a geographic area in which the User Zone features/services are made available to the customers that have subscribed to that User Zone. The boundary of the User Zone geographic area may be established based on the coverage area of a BS, or it may be established independent of RF topology. Refer to [5] for further details on User Zones.
The MS User Zone may be indicated at registration time in the Location Updating Request message, or at call setup in the CM Service Request or Paging Response messages sent by the BS to the MSC. The User Zone may also be changed during the call by using the User Zone Update Request message. A User Zone Reject message or a User Zone Update message is sent by the MSC to the BS to reject or change the MS’s active User Zone.
Refer to section 3.14 for call flows associated with this feature.
2.15 ISDN Interworking 33
34
35
36
37
38
39
ISDN interworking service provides interoperable communications between an MS and an existing ISDN subscriber terminal operating in the public ISDN as well as between MSs. The procedures and interfaces are specified in [21]. This feature requires a circuit-switched MSC.
For all calls supporting ISDN interworking services, the MSC shall provide a function of protocol conversion between upper layer signaling over the A1 interface and ISDN
Section 2 26
3GPP2 A.S0013-D v2.0
signaling, and the SDU shall construct Unrestricted Digital Information (UDI) data/RLP frames from RLP frames/UDI data respectively.
1
2
3 Refer to section 3.15 for more details on this feature.
2.16 Circuit Data Calls 4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Circuit Data calls include Asynchronous Data and Group-3 Fax services. These services allow the MS to send and receive asynchronous data and facsimiles. Refer to [14] for information on valid service options. The procedures and interfaces are specified by [21]. This feature requires a circuit-switched MSC.
For all calls supporting circuit-oriented data services, an Interworking Function (IWF) exists that interfaces between the transmission of the data in the fixed network and the transmission of the data over the air interface. For this standard, the IWF for circuit-oriented data calls is considered to be located at the MSC. The A5 interface connects the SDU to the IWF. The A5 interface carries a duplex stream of user traffic between the MSC and SDU. Once an IWF has been allocated for a circuit-oriented data call, it shall remain anchored for the duration of the call.
According to [21], RLP is terminated in the SDU. The A5 interface in this case carries the output of the RLP function specified in [21] from the SDU function to the IWF. The protocol currently defined in this standard for the A5 interface is ISLP. Refer to [23].
Both mobile origination and mobile termination applications of this service shall be “Data Only”.
Normal call origination, call termination, and call clearing procedures apply.
Call flows associated with this feature are described in sections 3.1.1, 3.1.2, and 3.2.
This standard supports handoffs for Asynchronous Data and Group 3 fax calls as indicated in section 1.1.
2.17 3G Packet Data Calls 25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
This section applies to packet data calls only. It is assumed that no circuit switched services are present. For packet data interaction with circuit switched services, refer to section 2.18, Concurrent Services.
Packet data calls allow users to exchange data between the MS and an IP data network. This section describes IOS support for 3G packet data services. These services are primarily identified with service option 33, as defined in [21], or service options 60 and 61, as defined in [27]. Other service options also may be used (refer to [14]) for intergeneration handoff (handoff between systems supporting packet data services based on ANSI/TIA/EIA/95-B and systems supporting packet data service based on cdma2000). Intergeneration handoffs are described in section 2.19.5.
For all calls supporting packet data services, a Packet Data Serving Node (PDSN) exists that interfaces between the transmission of the data in the packet data network and the transmission of the data (via the Radio Access Network (RAN)) over the air interface. The PDSN interfaces to the BS through a Packet Control Function (PCF), which may or may not be co-located with the BS.
27 Section 2
3GPP2 A.S0013-D v2.0
In a 3G packet data call, the MS may initialize one or several packet data service instances (PDSIs). Each service instance is a separate connection between the MS and the PDSN, used to exchange user data. Each PDSI is associated with a packet data service option and identified by a Service Reference Identifier (SR_ID). The first service instance established by the MS is of service option type ‘33’. The states of a PDSI associated with service option 33 are defined in
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[21]. For the purposes of this standard, distinction is made between the Null/Inactive State, the Active/Connected State and the Dormant State of PDSIs. Voice-over-IP service instances (service option 60 and 61) do not have a Dormant State, only Null/Inactive State and Active/Connected State.
When the MS initializes the first PDSI, a packet data session is started. Associated with the packet data session is a PPP session. For every packet data session, there is at least one service instance, referred to as the main service instance, which is used to negotiate the PPP session. Other service instances established subsequently, if any, are referred to as auxiliary service instances and may be of service option type 60 or 61. The packet data session ends when all service instances are released.
For purposes of the protocol of this standard, there are three packet data session states: Active/Connected, Dormant, and Null/Inactive. In the Active/Connected State, at least one service instance is active and a physical traffic channel exists between the MS and the BS, and either side may send data on the active service instances. In the Dormant State, all service instances are dormant and no physical traffic channel exists between the MS and the BS, but the PPP link between the MS and the PDSN is maintained. In the Null/Inactive State, all service instances are in the Inactive/Null State and there is no traffic channel between the MS and the BS and no PPP link between the MS and the PDSN. Figure 2.17-1 shows the possible transitions between the states of a packet data session.
Active / Connected
State
Dormant State
Null/Inactive State
26
27
28
29
30
31
32
33
34
35
36
37
38
Figure 2.17-1 Packet Data Session State Transitions
The MS may cross packet zone boundaries while the packet data session is in the Dormant State. This is referred to as dormant handoff. The dormant handoff procedures specified in this standard allow the A10 connections between the PCF and PDSN to be moved (or established) for the MS when it enters a new packet zone.
A dormant packet data session may transition to Active State (e.g., if the user has data to send) at any time. This transition is referred to as Re-Activation from Dormant.
Packet data is typically transmitted over the air on dedicated traffic channels. Mechanisms also exist for transmitting data over the common channels. Short Data Burst is a part of the 3G Packet Data feature that enables small amounts of data to be transmitted over the common channels. Common Channel Packet Data is a mode of 3G Packet Data where all data is transmitted using Short Data Bursts.
Section 2 28
3GPP2 A.S0013-D v2.0
An A1 or A1p connection is maintained during the Active / Connected State of the packet data session and released during transition to Dormant or Null/Inactive State of the packet data session. An A8 connection is maintained for each active PDSI and released when the service instance transitions to the Dormant or Null State. The BS may maintain a packet data inactivity timer for each PDSI associated with a service option that supports dormancy. An A10 connection is maintained for each service instance during the Active/Connected and the Dormant State of the service instance. Each A10 connection is assigned a separate Key to be used in the GRE header and also a separate lifetime; refer to
1
2
3
4
5
6
7
8
9
10
11
[12].
Refer to section 3.17 and accompanying subsections for call flows associated with packet data.
2.17.1 Packet Data Assumptions 12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
The following assumptions are made regarding packet data.
1. Each PCF corresponds to a packet zone, each PCF is uniquely identified by the Access Network Identifiers (ANID) and every PCF knows its ANID value. The MS initiates a dormant handoff when it moves into a new packet zone and it determines that it needs to notify the packet data network. Refer to [21]. No dormancy knowledge is required by the PDSN.
2. The set of PDSNs that a PCF may connect to is known at the PCF.
3. The PDSN selection algorithm specified in section 3.17.3 is used for initial PDSN assignment and PDSN reselection.
4. When connecting to a PDSN during an active session handoff or during dormant handoff, if the target PDSN recognizes the session, it does not require a restart of PPP.
5. Links between PCFs and PDSNs support both the signaling and traffic channels.
The signaling channels support call connects, disconnects, as well as signaling for QoS, accounting information etc.
The traffic channels support in-sequence delivery of data payload.
6. A PCF initiates an A10 connection, but either the PCF or the PDSN may drop it.
7. The A8/A9 and A10/A11 interfaces are assumed to be supported on a private IP network for security considerations.
8. Standard IP QoS mechanisms may be employed at the network layer for the A8 and A10 bearers.
9. The BS contacts the MSC so that the MS (IMSI/ESN) can be authenticated and the access to the PDSN can be authorized during traffic channel setup.
10. The packet core network authenticates the user (NAI) and authorizes each PDSI.
11. When the MS is on the traffic channel for a voice call, the BS contacts the MSC when the packet data session is not active and the MS sends an Enhanced Origination message for a PDSI. This is done so that the use of concurrent services can be authorized.
12. When the MS is on the traffic channel, the BS does not contact the MSC when the packet data session is active and the MS sends an Enhanced Origination message for an additional PDSI. This is because the MSC needs to be aware only of the state of the packet data session and not the state of each PDSI.
29 Section 2
3GPP2 A.S0013-D v2.0
2.17.2 Previous and Current Access Network Identifiers (PANID/CANID)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
An Access Network Identifier (ANID) consists of a packet zone identifier (PACKET_ZONE_ID, or PZID), a system identifier (SID), and a network identifier (NID). The ANID defines a packet zone. Each PCF is uniquely identified by an ANID and knows its ANID value. The ANID of the current PCF (PCF to which the MS is currently connected to) is referred to as the CANID. The ANID of the PCF that the MS was previously connected to is referred to as the PANID. The PDSN uses the PANID and CANID to determine if an inter-PDSN handback has occurred.
When an MS moves into a new packet zone and determines that it needs to notify the packet data network, it initiates a dormant mode handoff (refer to [21]). The MS sends an origination message which may include ANID information. The ANID information may include the previous Packet Zone (PREV_PZID), System Identification (PREV_SID) or Network Identification (PREV_NID) parameters (or any combination of these fields), which the BS uses to determine the ANID of the previous PCF (PANID). The BS sends the PANID to the PCF if the MS sent any ANID information to the BS. The PCF sets the PANID to zero if no ANID information was received from the BS. The PCF sets the CANID to its own ANID and passes the PANID and CANID to the PDSN.
In a hard handoff, the ANID of the source PCF is sent from the source BS to the target PCF via the MSC and the target BS. The target PCF forwards the received ANID as the PANID together with its own ANID as the CANID to the PDSN.
Refer to section 3.17.2 for more details.
2.17.3 PDSN Selection Algorithm 23
24
25
26
27
28
29
30
The PDSN selection algorithm specified in this standard shall be used for initial PDSN selection of the first service instance and PDSN re-selection initiated by dormant handoff. This algorithm increases the likelihood that the MS will be re-connected to the same PDSN upon dormant handoff, thereby avoiding possible PPP and MIP re-establishment on a new PDSN. The algorithm is based upon the MS’s IMSI, which is assumed to be known at the PCF at the time of A10 establishment.
Refer to section 3.17.3 for details of this algorithm.
2.17.4 Packet Data Interface Descriptions 31
32
33
The A9 and A11 interfaces provide for signaling for packet data services. Call flows associated with this feature can be found in section 3.17.4.
2.17.4.1 A8/A9 Interface Descriptions 34
35
36
37
38
39
The A9 interface provides for signaling to initiate establishment and release of the A8 connection for packet data services. The A8 interface provides the user traffic path between the BS and the PCF. A9 signaling is also used to provide new or updated session parameters to the BS, notify the PCF of successful handoff completions, pass Accounting Parameters to the PCF, and to acknowledge A9 messages as required.
Section 2 30
3GPP2 A.S0013-D v2.0
2.17.4.2 A10/A11 Interface Descriptions 1
2
3
4
5
6
7
The A11 interface provides for signaling to request establishment, refresh, update and release of an A10 connection for packet data services. The A10 interface provides the user traffic path between the PCF and the PDSN. When an A10 connection is active, A11 signaling is also used to provide new or updated accounting parameters between the PCF and the PDSN, forward airlink records to the PDSN and to acknowledge A11 messages as required.
2.17.5 Interoperability Control 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
The architectural assumptions for the A10-A11 interface interoperability control scheme for a communicating PDSN-PCF pair are:
The architectural principle in [34] on which the A10-A11 interface is based shall not be violated.
The latest IOS version shall be backward compatible with older supported IOS versions.
A Critical Vendor Specific Extension (CVSE) shall not be added to a pre-existing message of the A11 interface. A Normal Vendor Specific Extension (NVSE) may be used to add new information to existing messages. The processing of messages containing CVSEs or NVSEs is specified in [17], and follows the rules of [36].
The structure of the mandatory elements shall not change in revisions of the IOS standard. Interoperability control on the A10/A11 interface is accomplished by the forward compatibility guidelines specified in [17].
Refer to section 3.17.5.1 for a description of the call flow demonstrating how version control is implemented on the A8/A9 interface.
In many RANs the PDSN is connected to one or more PCFs. The messages that are used on the A11 interface to set up and maintain A10 bearer connections often change with new releases of the standard. Depending upon which version of the standard the PCF/PDSN is based on, the PCF/PDSN may support different features and different formats for the A11 signaling messages.
The A11 Capabilities Info message can be sent from either the PCF or the PDSN upon restart. This message contains information about the features supported by the PCF (e.g. Short Data Indication) or the PDSN (e.g. Flow Control), depending on which entity is sending the message. Refer to section 3.17.5.2 for the call flows associated with capabilities control on the A11 interface.
2.17.6 Short Data Bursts 34
35
36
37
38
39
40
41
42
43
44
cdma2000 defines short data bursts as messages or data associated with a data service that consist of a small number of frames that are transmitted to or from an MS with a dormant PDSI. Short Data Bursts are not supported across packet zone boundaries. Data may be lost if an MS moves to a new packet zone shortly after transmitting a Short Data Burst (SDB). Mobile terminated data may also be lost if a short data burst is sent to the BS/PCF from the PDSN, but the MS moves to a new packet zone before the data is transmitted to the MS. The BS shall ensure that multiple mobile originated short data bursts from the same MS shall be sent to the PCF in the order in which they were received from the MS. The PDSN may indicate suitability of a packet for short data burst transmission via an attribute in its GRE payload as defined in [12].
31 Section 2
3GPP2 A.S0013-D v2.0
Refer to section 3.17.6 for call flows describing this feature. 1
2.17.7 Common Channel Packet Data (CCPD) 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
The Common Channel Packet Data (CCPD) feature supports packet data call setup, dormant mode handoffs, and data transmission using Short Data Bursts over Common Channels. This is referred to as “CCPD Mode”. Short Data Bursts are specified in [21].
A CCPD capable MS is a cdma2000 MS that supports CCPD Mode. A CCPD capable MS may request CCPD Mode from the network when the amount of data to be transmitted is expected to be small and infrequent. The BS may deny CCPD Mode to a CCPD capable MS by either rejecting the call or allocating a traffic channel to it.
A CCPD capable MS requests Common Channel Packet Data (CCPD) Service from the network by setting the SDB_DESIRED_ONLY bit in the Origination Message to 1. If the BS agrees to support the MS’s request for CCPD Mode, PPP connection setup and MIP registration (if required) are performed over common channels using Short Data Bursts. An A8 bearer connection is not required. Upon successful completion of these procedures, the PDSI transitions from the Null to the Dormant State.
A CCPD capable MS originating a CCPD Mode call setup or CCPD Mode dormant mode handoff is authenticated by the network at the start of the procedure. A CCPD capable MS may be authenticated again upon subsequent Short Data Burst transmissions in support of the CCPD Mode call setup or CCPD Mode dormant mode handoff procedures.
If the target BS is able to determine that the MS supports CCPD mode, the BS may initiate CCPD Mode to support a dormant mode handoff, even though a CCPD capable MS may not have explicitly requested CCPD Mode from the network. The BS responds to the MS’s Origination Message with a Release Order rather than assigning a traffic channel for the call. Subsequent communication between the MS and the network occurs using Short Data Bursts over Common Channels.
For call flows associated with this feature, refer to section 3.17.7.
2.17.8 Packet Data Security Considerations 27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
The PCF-PDSN interface is designed for use over a protected, private network between the PCFs and the PDSNs. Pre-arranged security associations, in the style of “IP Mobility Support” ([34]) are assumed to exist among every PCF and PDSN pair that forms an A10 connection.
Several potential vulnerabilities exist in the absence of such security associations. If an A10 connection is accessible to an attacker, the GRE encapsulated user traffic may be intercepted and/or spoofed if end-to-end security mechanisms are not in place. Such end-to-end security issues are outside the scope of this standard. However, all A11 signaling messages are authenticated to prevent an A10 connection setup and tear down by an unauthorized node. “Mobile-Home Authentication Extension” and “Registration Update Authentication Extension” provide a means of protecting the A11 signaling messages. If registration messages are not authenticated, a denial-of-service attack is possible. If a PCF sends an A11-Registration Request message to the PDSN with a spoofed Session Specific Extension, the PDSN would then send an explicit tunnel tear down to the previous PCF, causing user traffic to be misdirected to the new PCF. This would cause a loss of service and possibly interception of traffic, depending on what other security measures are in place.
Section 2 32
3GPP2 A.S0013-D v2.0
The A8/A9 interfaces are assumed to be supported on a private IP network for security considerations.
1
2
3
4
For details on packet data security, refer to section 3.17.8.
2.17.9 Support for AAA-Based Radio Network Packet Data Inactivity Timer (RN-PDIT) 5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Each PDSI is associated with a packet data inactivity timer, which the BS uses to limit the time that a service instance may be active while no data is being sent to or received from the MS. When the inactivity timer expires, the BS transitions the service instance to the Dormant State. Refer to [21] for further details. This feature allows the value of the inactivity timer associated with a service instance to be determined by the packet data network and stored at the Authentication, Authorization, and Accounting (AAA) infrastructure. For example, RN-PDIT may be based on the realm(s) accessed through the service instance, the application(s) using the service instance, QoS of the service instance, or other parameters.
A pre-provisioned default inactivity timer value stored at the BS is used until an inactivity timer value associated with the service instance is passed from the PDSN to the BS. The inactivity timer value passed from the PDSN to the BS may be overwritten by the BS due to RAN resource considerations.
How the inactivity timer value is determined in the packet data network is outside the scope of this standard. This standard only specifies the procedure for passing this parameter from the PDSN to the BS. The transfer of the inactivity timer value from the PDSN to the BS is supported by the PDSN Initiated Packet Data Session Update procedure (refer to section 3.17.9).
2.17.10 Support for Always-on Service 24
25
26
27
28
29
30
31
32
The packet data network supports MSs with Always-on service MSs (refer to [8]). The PDSN provides an indication of an Always-on MS to the PCF.
Paging of an MS occurs as part of network initiated re-activation from dormant when the MS is not on a traffic channel. No response from an Always-on MS is interpreted as the Always-on MS being temporarily out of radio coverage; this event should not trigger release by the PCF of dormant PDSIs of Always-on MSs.
Refer to section 3.17.9 for call flows associated with the transfer of the Always-on information from the PDSN to the PCF.
2.17.11 1x-Evolved High-Speed Integrated Data and Voice Support 33
34
35
36
37
38
39
40
This feature is commonly referred to as 1xEV-DV and is supported by the Forward and Reverse Packet Data Channels (F-PDCH, R-PDCH) in addition to other control channels.
The forward and reverse packet data channels support high-speed packet data services on the same RF carrier that supports other cdma2000 1x services such as voice. Support of packet-switched high-speed data is provided by means of a shared channel in a time division multiplexed manner in conjunction with code division multiplexing (refer to [1]~[6] for details). The packet data channels support higher data rates than the
33 Section 2
3GPP2 A.S0013-D v2.0
supplemental channels. Signaling and user traffic may be multiplexed over the forward and reverse packet data channels.
1
2
3
4
5
The IOS supports this feature by specifying the signaling for the forward and reverse packet data channel related MS capabilities. This feature is supported by the call flows for the 3G packet data calls; refer to section 3.17.
2.17.12 Flow Control 6
7
8
9
10
11
12
13
14
15
16
17
18
19
The Flow Control feature allows a PCF to request the PDSN to stop GRE packet transmission to the PCF in response to certain RAN events. Such a request can occur for example due to poor RF conditions, if the MS is temporarily unable to receive packets from the network, a high water mark for buffer overflow is reached in the RAN, or other reasons. The PDSN in response to the request may either buffer or drop the packets at the PDSN instead of sending them to the RAN. This helps in preventing buffer overflows within the RAN and facilitates more accurate packet accounting for the packet data user. The PCF may request the PDSN to resume the transfer of GRE packets to the PCF when conditions return to normal in the RAN.
Flow control can only be requested by the PCF if the PDSN enables it for a particular PDSI. Flow control is enabled by the PDSN over the A11 signaling interface. Flow control is requested by the PCF by including flow controls signals in GRE frames sent over the A10 interface to the PDSN.
2.18 Concurrent Services (Circuit Voice and Packet Data) 20
21
22
23
24
25
Concurrent service provides support for one circuit voice and one packet data session (which may be comprised of one or more PDSIs) simultaneously. Other service combinations may be supported by a future release.
Refer to section 3.18 for call flows associated with this feature.
In addition, refer to section 3.2 when clearing all service instances.
2.19 Handoff 26
27
2.19.1 Handoff via MSC 28
29
30
31
32
33
34
35
36
37
38
39
Handoffs (intra-BS, inter-BS and inter-MSC) can occur for one of several reasons including radio propagation, traffic distribution, OAM&P activity, and equipment failure. Refer to [11] for handoff definitions. Refer also to section 3.17.4 for packet data scenarios.
Intra-BS Handoff: An intra-BS handoff is a handoff performed under the domain of one BS. As such, the MSC is not involved in the execution of the handoff. Once an intra-BS hard handoff is successfully completed, the BS shall inform the MSC if the old cell is no longer involved in the call.
Inter-BS Handoff: An inter-BS handoff is attempted whenever a potential target may be outside of the domain of the source BS. The MSC may use inter-BS hard handoff procedures to perform handoffs where the source BS and target BS are the same.
Section 2 34
3GPP2 A.S0013-D v2.0
Inter-MSC Handoff: An inter-MSC handoff is attempted when the source BS and the target BS are controlled by different MSCs. Refer to
1
2
3
[28].
Refer to section 3.19.1 for more information on handoffs.
2.19.2 Handoff via Direct BS-to-BS Signaling 4
5
6
7
8
9
10
11
12
13
14
15
16
Efficient inter-BS soft handoff is supported via direct BS-to-BS signaling and traffic connections between base stations.
The A3 interface, composed of signaling and user traffic subchannels, provides the ability to establish and remove A3 traffic connections. The A3 interface also provides support for operational procedures, such as turning on/off voice privacy or changing the service configuration of a call.
The A7 interface provides direct BS-to-BS signaling for the support of efficient soft handoff. Only a call release procedure should interrupt any handoff procedure. Multiple concurrent A7 Handoff Add procedures are prohibited for the same physical channel on the same call. Multiple concurrent A7 Handoff Drop procedures for the same physical channel on the same call are prohibited.
Refer to section 3.19.2 for more information on BS-to-BS handoff.
2.19.3 Inter-BS Hard Handoff into Intra-BS Soft Handoff 17
18
19
20
21
22
23
24
25
26
27
28
Hard handoff into (i.e. coincident with) soft handoff can increase the probability of successful handoff of a call. This feature allows the source BS to specify a list of target cells for the handoff by including these cells in the Cell Identifier List in the Handoff Required message sent to the MSC. The cell list is forwarded by the MSC to the target BS in the Handoff Request message. The target BS decides which cells are included in the handoff and allocates resources on these cells. The target BS then indicates these cells to the MSC in the Cell Identifier List of the Handoff Request Ack message, and this cell list is forwarded to the source BS in the Handoff Command message. The source BS directs the MS to these cells using a handoff direction message. It is the target BS’s responsibility to set up the soft handoff. Refer to section 3.19.3.1.1 for a call flow related to this feature.
2.19.4 Fast Handoff 29
30
31
32
33
34
35
36
37
38
Fast handoff provides a low interruption packet data service hard handoff mechanism by:
1. Maintaining an MS’s PPP session as long as the MS has an active packet data session, and
2. Transmitting the forward data stream to the source and target PCFs during the handoff procedures (bicasting).
The general configuration and nomenclature for fast handoff are shown in Figure 2.19.4-1. Note that the general configuration illustrates the scenario where a prior fast handoff has taken place during the current Active State of the MS from the anchor PDSN to the source PDSN and a P-P connection exists between the source and the anchor PDSNs.
35 Section 2
3GPP2 A.S0013-D v2.0
Source PDSN
A10/A11
Anchor PDSN
MS
A10/A11 A10/A11
Target PDSN
A10/A11
Target BS/PCF
Anchor PDSN Address
Source PDSN Address
Anchor P-P Address
Source BS/PCF
P-P Connection
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Figure 2.19.4-1 General Configuration Prior to a Fast Handoff
The anchor PDSN is defined to be the PDSN that terminates the PPP connection, and the anchor P-P Address is the anchor PDSN’s P-P (PDSN to PDSN) interface IP address. The source PDSN is defined to be the PDSN connected to the source BS/PCF and the target PDSN is defined to be the PDSN connected to the target BS/PCF.
The source BS initiates hard handoff of an active packet data session by sending a Handoff Required or Handoff Request message via the MSC to the target BS. Inclusion of the Anchor P-P Address indicates to the target BS that fast handoff is requested. The Handoff Required or Handoff Request messages also include the source PDSN Address and the anchor PDSN Address.
When selecting the target PDSN, the target BS/PCF should use the anchor PDSN address or else the source PDSN address provided in the Handoff Request message if possible. If both anchor and source PDSNs are not reachable the PDSN selection algorithm applies.
The target PDSN uses the Anchor P-P Address to establish a P-P connection to the anchor PDSN for each PDSI of the MS (both active and dormant). During fast handoff, the anchor PDSN remains fixed.
Depending on the handoff situation, any pair of PDSNs among the anchor, source and target PDSNs, or all three of them, may be identical. The target BS recognizes these cases based on comparing the addresses included in the Handoff Request message with each other and with the target PDSN address. For instance:
If no fast handoff has taken place previously during the current active phase of the MS, then the Anchor and the source PDSN are identical, and no P-P connection(s) exist prior to the handoff. If the target BS/PCF can reach the source/anchor PDSN, then the target BS/PCF should select the target PDSN to be identical to the source/anchor PDSN. Note that this will result in an intra-PDSN handoff where the source, anchor and target PDSNs are identical (Figure 2.19.4-2). If the target BS/PCF is unable to reach the source/anchor PDSN, then the target BS/PCF selects a target PDSN that is different from the source/anchor PDSN (Figure 2.19.4-3).
Section 2 36
3GPP2 A.S0013-D v2.0
Source/Anchor/Target
PDSN
A10/A11
MS
A10/A11 A10/A11 A10/A11
Target BS/PCF
Source/Anchor/Target PDSN Address
Source/Anchor /Target P-P Address
Source BS/PCF
1
2
3
Figure 2.19.4-2 Configuration Without Prior Fast Handoff – Target PDSN Identical to Source/Anchor PDSN
Source/Anchor PDSN
A10/A11
MS
A10/A11 A10/A11
Target PDSN
A10/A11
Target BS/PCF
Source/Anchor PDSN Address
Source/Anchor P-P Address
Source BS/PCF
4
5
6
7
8
9
10
Figure 2.19.4-3 Configuration Without Prior Fast Handoff – Target PDSN Different from Source/Anchor PDSN
If a prior fast handoff has taken place, a P-P connection exists between the source and the anchor PDSNs. In this case, if the target BS/PCF can reach the anchor PDSN, then the target BS/PCF should select the target PDSN to be identical to the anchor PDSN (Figure 2.19.4-4).
SourcePDSN
A10/A11
MS
A10/A11 A10/A11
Anchor/Target PDSN
A10/A11
Target BS/PCF
Source PDSN Address
Anchor/Target P-P Address
Source BS/PCF
P-P Connection
11
12
13
Figure 2.19.4-4 Configuration With Prior Fast Handoff - When the Target BS/PCF Can Reach the Anchor PDSN
37 Section 2
3GPP2 A.S0013-D v2.0
If a prior fast handoff has taken place and if the target BS/PCF cannot reach the anchor PDSN, but can reach the source PDSN, then the target BS/PCF should select the target PDSN to be identical to the source PDSN.
1
2
3
Source/ TargetPDSN
Anchor PDSN
MS
TargetBS/PCF
Anchor PDSN Address
Source PDSN Address
Anchor P-P Address
Source BS/PCF
P-P Connection
4
5
6
7
8
9
10
11
12
13
14
15
Figure 2.19.4-5 Configuration With Prior Fast Handoff - When the Target BS/PCF Can Reach the Source PDSN
If a prior fast handoff has taken place, and the target PCF can reach neither the anchor PDSN nor the source PDSN, then the target PCF will connect to a target PDSN, and the target PDSN will set up a P-P connection to the anchor PDSN. In this case, all three PDSNs are distinct (Figure 2.19.4-1).
Prior to handing off the MS, the target BS/PCF selects a target PDSN and initiates pre-setup of a transmission path for each service instance between the target BS/PCF and the anchor PDSN via the target PDSN. The transmission path between the source BS/PCF and the anchor PDSN is maintained. Data from the anchor PDSN is bicast to the source and the target BS/PCFs. This is shown in Figure 2.19.4-6.
Source BS/PCF
SourcePDSN
A10/A11
Anchor PDSN
MS
A10/A11 A10/A11
TargetPDSN
A10/A11
Target BS/PCF
A10/A11
P-P connection
P-P connection
16
17
18
19
20
21
22
23
24
25
Figure 2.19.4-6 General Configuration During a Fast Handoff, Step 1
If the target and source PDSN are identical, but distinct from the anchor PDSN, then the P-P connection(s) existing prior to the handoff are reused and the data stream(s) are bicast at the source PDSN. When the target PDSN is distinct from the source and the anchor PDSN, new P-P connection(s) are set up between the Anchor and the target PDSN. When the target PDSN is identical to the anchor PDSN, no new P-P connection(s) are set up.
After the MS connects to the target BS, the transmission path(s) between the anchor PDSN and the source BS/PCF is (are) torn down (except for the P-P connection(s) when
Section 2 38
3GPP2 A.S0013-D v2.0
the existing P-P connection(s) are reused for the target PDSN). This is shown in Figure 2.19.4-7.
1
2
Source BS/PCF
SourcePDSN
Anchor PDSN
MS
TargetPDSN
TargetBS/PCF
A10/A11
P-P connection
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Figure 2.19.4-7 General Configuration During a Fast Handoff, Step 2
If the target PDSN is the same as the anchor PDSN, then the fast handoff is completed; i.e., the P-P connection(s) are released and no new ones are created.
Otherwise, the fast handoff stays up until one of the following events occurs:
It is superseded by another fast handoff (i.e., the target BS/PCF and target PDSN in Figure 2.19.4-3 becomes the source BS/PCF and source PDSN in Figure 2.19.4-1.
All PDSIs on the MS are dormant. Completion of the fast handoff entails the target PDSN releasing all P-P connections to the anchor PDSN, which triggers PPP session renegotiation between the target PDSN and the MS. To minimize impact, this is done when the MS has no active PDSIs.
If a target BS/PCF that does not support fast handoff receives a Handoff Request message from the MSC indicating fast handoff, then the basic hard handoff procedures specified in section 3.17.4 apply.
Call flows for this feature are provided in section 3.19.4. Refer to [8] for details on the P-P interface.
2.19.5 Intergeneration Packet Data Handoff 19
20
21
22
23
24
25
Intergenerational handoff is defined to be the handoff of an MS between a system that supports packet data service as specified in [11]~[17] (referred to as “3G” in this section) and a system that supports a packet data service as specified in [10] (referred to as “2G” in this section). Note that packet data service based on [10] is not explicitly supported in this version of the standard. A PDSI needs to be re-established following an intergeneration packet data handoff. Refer to section 3.19.5 for details on this feature.
2.19.6 Alternate Dormant Handoff 26
27
28
29
30
31
32
33
This feature provides alternate procedures for performing dormant handoffs of PDSIs. Refer to section 2.17. It differs from the default dormant handoff method by using connectionless signaling on the A1 or A1p interface. Fewer messages are exchanged and no SCCP/SUA connection is established unless the handoff results in a reactivation of the PDSI and a traffic channel needs to be set up. The alternate dormant handoff procedures are not applied when the MS is already on a traffic channel, i.e., during a concurrent voice call or when other PDSIs are active.
39 Section 2
3GPP2 A.S0013-D v2.0
The alternate dormant handoffs procedures may be more efficient in networks with small packet zones where MSs initiate dormant handoffs frequently and when dormant handoffs rarely result in the establishment of a traffic channel.
1
2
3
4
5
6
7
8
9
10
11
12
When the BS receives an Origination Message from an MS initiating a dormant handoff, the BS may opt for the alternate dormant handoff method by sending an ADDS Transfer message to the MSC including parameters for authentication, authorization, and registration. The BS shall not send the ADDS Transfer message for dormant handoffs unless the MSC supports this feature. The MSC authorizes the BS to initiate the setup of the A10 connection at the target PCF by returning an ADDS Transfer Ack message. Refer to [14] for details on the ADDS Transfer / ADDS Transfer Ack message procedures.
Refer to section 3.19.6 for call flows for this feature.
2.20 Security Features 13
14
15
16
17
18
19
20
The security features supported by this version of the IOS comprise:
2G terminal authentication and key generation,
3G authentication and key generation,
Signaling Message Encryption,
Voice/data privacy,
Extended Encryption for signaling and user traffic, and
Message integrity.
2.20.1 Authentication 21
2.20.1.1 2G Terminal Authentication and Key Generation 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Terminal Authentication is the process by which information is exchanged between an MS and a network for the purpose of confirming the identity of the MS.
This feature is supported using Shared Secret Data (SSD). SSD is a 128-bit pattern stored in the MS and readily available to the network. SSD is not passed across the air interface or across the A1 or A1p interface. The first 64 bits of the SSD are defined as SSD-A and are used to support the authentication procedures. The last 64 bits of the SSD are defined as SSD-B and are used to support voice/data privacy, signaling message encryption, extended encryption for signaling and user traffic and message integrity. Air interface procedures are defined to update the SSD at the MS (refer to [5]). The new SSD is generated at the HLR/AC, which initiates the SSD update procedure. Invocation of the SSD update procedure is an HLR/AC or OAM&P concern. The SSD update procedure can take place on traffic channels for MSs capable of authentication and the related security procedures.
Usually, the entity controlling the authentication in the network initiates the Unique Challenge procedure as specified in section 3.20.1.2 after an SSD update procedure is completed.
A successful outcome of the authentication process occurs only when it can be demonstrated that the MS and the network possess identical sets of secret provisioning information, SSD. In the case of an authentication failure, service providers may deny
Section 2 40
3GPP2 A.S0013-D v2.0
network access to invalid MSs and thereby deter fraud. The method involves a common algorithm in the network and the MS, and a parameter unique to each MS, and known only to the MS and the network, called the A-key. The common cryptographic authentication algorithms are described in
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
[26].
The SSD is derived from the A-key and a random challenge (RANDSSD) as described in section 3.20.1.1. The A-key and the SSD are never broadcast across the air interface. Instead, a publicly available random number (RAND) is sent to the MS. The RAND and SSD are used as input to the authentication algorithm at both the MS and the network. The authentication response result (referred to as AUTHR) is computed by the MS and returned to the network. It is compared to the network’s computed result AUTHR. If the results match, the authentication procedure was successful. If the authentication procedure fails, the MSC may initiate call clearing per section 3.2.2.
Three forms of authentication are available for use with MSs capable of authentication and the related security procedures. In the first form, the RAND value is broadcast on the forward control/Paging Channel and is common to all MSs accessing the cell. The MS computes the AUTHR using this RAND, and provides it in its initial access message, which may be a location registration, origination, or page response. Refer to section 3.1.1 for details on the use of this form of authentication for mobile origination and page responses. Also refer to section 3.7.
In the second form of authentication, the MSC initiates an explicit authentication procedure, with messaging separate from that used for call setup and registration. The MSC issues a challenge to the MS containing a specific (unique) RANDU value, and the MS responds with its computed AUTHU value. This is referred to as the unique challenge/response procedure. This procedure is always initiated and controlled by the MSC. The MSC may initiate this procedure at any time on either control or traffic channels. The call flow for this form of authentication is described in section 3.20.1.2.
In the third form of authentication, the BS Initiated Terminal Authentication feature enables the BS to ask the MSC to issue an authentication request to a specific MS. This feature may be used in situations where the BS is aware of an event (e.g., temporary loss of the traffic channel) that warrants specifically authenticating the MS to verify that it is legitimate. The call flow for BS Initiated Terminal Authentication is described in section 3.20.1.5.
A 2G authentication results in the MSC having the CMEA Key, if it is needed for Signaling Message Encryption, Extended Encryption or Message Integrity. A 2G authentication results in the Private Long Code Mask if it is needed for Voice/Data Privacy.
2.20.1.2 3G Authentication and Key Generation 37
38
39
40
41
42
43
44
45
46
47
3G Authentication provides mutual authentication of the MS by the network and the network by the MS.
3G Authentication uses the Authentication and Key Agreement (AKA) protocol (refer to [33]) and is the process by which information is exchanged between an MS and a network for the purpose of confirming the identity of the MS by the BS and the BS by the MS. For 3G Authentication, the MSC receives Authentication Vectors from the HLR/AC. An Authentication Vector includes the following variables; RANDA, AUTN, XRES, CK, IK and UAK. The network initiates a 3G Authentication by sending RANDA and AUTN to the MS. The mobile checks the AUTN to authenticate the network and if this is successful it sends its response, RES, back to the network. The network checks if
41 Section 2
3GPP2 A.S0013-D v2.0
RES=XRES and if it is, the authentication is successful. After a successful authentication, IK is used to provide Message Integrity between the MS and BS, UAK provides for UIM authentication while CK may be used to provide Extended Encryption between the MS and BS.
1
2
3
4
5
6
7
8
All BSs with P_REV greater than or equal to ten shall be able to execute 2G authentication and AKA. Whether the AKA procedures are actually performed on an MS depends on various factors such as whether the HLR/AC has enabled AKA and whether the ANSI-41 interface between the MSC/VLR and the AC supports AKA.
2.20.2 Signaling Message Encryption 9
10
11
12
13
14
15
16
17
18
If provided by the air interface, Signaling Message Encryption (SME) protects certain fields within selected air interface signaling messages. SME enhances the authentication process and protects sensitive subscriber information (e.g., PINs).
To provide this protection, the relevant device used for the signaling message needs to be loaded with the appropriate key. This is supplied by the MSC over the A1 or A1p interface. Refer to the definition of the information element “Encryption Information” in [14]. Signaling Message Encryption cannot be invoked unless broadcast authentication is activated in the system. This feature is only possible after a 2G authentication.
There are no call flows associated with this feature.
2.20.3 Voice/Data Privacy 19
20
21
22
23
24
25
26
If provided by the air interface, voice/data privacy is between the BS and the MS3. To provide this protection, the relevant device used for the voice privacy needs to be loaded with the appropriate key. This is supplied by the MSC over the A1 or A1p interface. Refer to the definition of the information element “Encryption Information” in [14]. Voice/Data Privacy cannot be invoked unless broadcast authentication is activated in the system. This feature is only possible after a 2G authentication.
There are no call flows associated with this feature.
2.20.4 Extended Encryption for Signaling and User Traffic 27
28
29
30
31
32
33
34
35
If provided by the air interface, enhanced voice and data privacy is between the BS and the MS. This feature allows both the signaling and/or the user traffic to be protected by encrypting the data. Providing this protection requires the use of some authentication and key generation procedure for the BS and the MS to have an agreed key in which to encrypt the data. The agreed key is derived from the CMEA key if 2G authentication is used. With 3G authentication, CK is used as the agreed key. The agreed key is supplied by the MSC over the A1 or A1p interface. Refer to the definition of the information element “Encryption Information” in [14].
3 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 the 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.
Section 2 42
3GPP2 A.S0013-D v2.0
There are no call flows associated with this feature. 1
2.20.5 Message Integrity 2
3
4
5
6
7
8
9
10
If provided by the air interface, message integrity is between the BS and the MS. This feature allows signaling traffic to be integrity protected. Providing this protection requires the use of some authentication and key generation procedure, for the BS and the MS to have an agreed key in which to encrypt the data. The agreed key is derived from the CMEA key if 2G authentication is used. With 3G authentication, IK is used as the agreed key. The agreed key is supplied by the MSC over the A1 or A1p interface. Refer to the definition of the information element “Integrity Information” in [14].
There are no call flows associated with this feature.
2.21 Flex Rate 11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Flex Rate provides the user the ability to assign data rates to the MS with greater granularity than previously allowed in cdma2000. To use Flex Rate, the MS is required to download a table (or series of tables) from the BS as part of the Non-Negotiable Service Configuration Record (NNSCR). The NNSCR contains a mapping of physical channels to tables; the tables contain a 4-bit index to each row and an associated bits-per-frame value. There is a default table that is standardized. In addition, the NNSCR contains a one-bit Flex Rate indicator. To assign a data rate for a data burst, the BS sends a 4-bit index into the table for each Supplemental Channel (SCH) in use (REV_SCH_NUM_BITS_IDX and FOR_SCH_NUM_BITS_IDX). If the Flex Rate indicator is turned off, the index refers to the standardized table, and this is used to determine the number bits per frame. If the Flex Rate indicator is turned on and the channel is mapped to a table other than the default table, the index and this Flex Rate table are used to determine the bits per frame for this channel and this burst.
Since the NNSCR is passed to the target base stations during establishment of soft handoff legs, there is no need to explicitly pass the Flex rate tables or the Flex Rate indicator to the target base stations. If the MS is in soft handoff, and a burst is being assigned using Flex Rate, the 4-bit index into the Flex Rate table shall be passed to the target BS.
2.22 Status Inquiry 30
31
32
33
34
35
36
37
38
39
40
41
42
This procedure is performed on a CDMA traffic channel or control channel to query certain capabilities of the MS. The MSC sends the Status Request message to the BS to instruct the MS to report parameters such as call mode, terminal information, roaming information, security status, etc. For details on the various information records that the MSC may request from MS, refer to [5].
When the MSC sends the Status Request message to the BS, it shall indicate the type of information requested from the MS. The MSC may include the qualification information of the requested capabilities in the message. The MS responds by sending the requested information to the BS. Consequently, the BS responds by sending the Status Response message to the MSC.
This operation shall not be applied to DS-41 systems.
Refer to section 3.22 for call flows associated with this feature.
43 Section 2
3GPP2 A.S0013-D v2.0
2.23 3X Multi-Carrier Operation 1
2
3
4
5
In this standard, 3X Multi-Carrier implementation affects handoff procedures. 3X parameters are required to be properly passed in the handoff messages for the feature to be successfully used. Section 3.23 describes how this feature can be implemented using existing messages and information elements.
2.24 5 ms Messaging 6
7
8
9
5 ms messaging allows for faster signaling between the BS and the MS. The only IOS impact is on the A3 traffic frames, which are used to carry the 5 ms messages during soft handoff. Section 3.24 outlines how this feature is implemented.
2.25 Enhanced Rate Adaptation Mode (ERAM) 10
11
12
13
14
15
16
17
18
19
20
21
Enhanced Rate Adaptation Mode (ERAM) enhances the flexible and variable rate features by using low rate turbo coding schemes. When flexible or variable data rate transmission is used for the Supplemental Channel with turbo codes, low rate turbo codes are used instead of pure code symbol repetition to match the length of the encoder output with the interleaver size of the maximum assigned data rate. By doing this, a performance gain can be achieved due to the inherent low rate coding gain.
The source BS indicates the use of ERAM to the target BS (in either a hard handoff or soft handoff scenarios) in the Non-Negotiable Service Configuration IE. To indicate MS support for this feature, the sender sets the ERAM Supported bit in the IS-2000 Mobile Capabilities information element.
There are no call flows associated with this feature.
2.26 Code Combining Soft Handoff (CCSH) 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
This feature only applies to packet data service. Code Combining Soft Handoff (CCSH) utilizes iterative turbo decoding, which can achieve coding diversity gain in addition to the conventional diversity gain during the soft-handoff process. CCSH is a soft handoff method where certain cells encode and transmit the data with the default turbo encoder, whereas other cells use the complementary turbo encoder. The MS combines the code symbols transmitted by each BS for turbo decoding. This is only used for forward link data bursts.
The target BS indicates support for this feature to the source BS by setting the CCSH bit in the A3 Connect Information IE of the A3 Connect message. When a Supplemental Channel is assigned for a data burst, the source BS informs the target BS of the turbo encoder type to be used on the Supplemental Channel for each cell in the active set by setting the CCSH Encoder Type bit in the Forward Burst Radio Info IE in the Burst Commit message.
There are no call flows associated with this feature.
2.27 Rescue Channel 37
38
39
40
The Rescue Channel feature supports the use of pre-allocated radio resources at neighboring base stations to attempt to recover a voice call in danger of being dropped. An MS disables its transmitter upon detection of a loss of forward frames from the
Section 2 44
3GPP2 A.S0013-D v2.0
network. Once the source BS detects a loss of transmission from the MS, it may attempt to re-establish communication with the MS by performing soft handoff additions to rescue cells at neighboring base stations. These base stations are selected based on the MS’s neighbor list, last reported Extended Pilot Strength Measurement Message (EPSMM), and possibly other factors.
1
2
3
4
5
6
7
8
9
10
11
Rescue Channel procedures require reserved A3 connections be provisioned between the source and target base stations. When the source BS adds a BS to the neighbor list of the MS, it indicates to the MS if that neighbor supports a rescue channel. Later, if a call rescue is required, the MS may autonomously promote the neighbor cell into its active set and begin to use the pre-allocated rescue channel.
Refer to section 3.27 for call flows describing this feature.
2.28 Terrestrial Circuit Management 12
13
14
This section describes management of terrestrial circuits between the circuit-switched MSC and the BS and between BSs.
2.28.1 Terrestrial Circuit Management for the A2/A5 Interface 15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Terrestrial circuits in the context of this section are those DS0 facilities that are used to carry traffic (voice or data) (A2/A5) between the MSC and the BS. This section applies only to circuit-switched MSCs.
The terrestrial circuit management message structures and the information elements in these messages are described in [14].
The following definitions are to be used when considering the condition of a terrestrial circuit:
Available The condition of a terrestrial circuit (A2/A5) that is available for selection by the MSC.
Blocked The condition of a terrestrial circuit (A2/A5) which the BS has identified as out of service, and is therefore not available for selection by the MSC.
Idle The condition of a terrestrial circuit (A2/A5) that is not carrying traffic. The idle condition does not imply availability.
Refer to section 3.28.1 for more details on this feature.
2.28.2 Terrestrial Circuit Management for the A3 Interface 31
32
33
34
35
36
37
38
Terrestrial circuits in the context of this section are ATM virtual circuits (A3) that are used to carry traffic (voice or data) and signaling information between the SDU and the BTS.
The following definitions are to be used when considering the condition of a terrestrial circuit:
Available The condition of a virtual circuit connection (A3) that is available for selection by the BTS.
45 Section 2
3GPP2 A.S0013-D v2.0
Blocked The condition of a virtual circuit connection (A3) which the SDU has identified as out of service, and is therefore not available for selection by the BTS.
1
2
3
4
5
6
Idle The condition of a virtual circuit connection (A3) that is not carrying traffic. The idle condition does not imply availability.
For call flows associated with this feature, refer to section 3.28.2.
2.29 Vocoder Support 7
8
9
10
11
12
13
14
15
16
17
18
This version of the IOS supports the following vocoder types:
13K (SO=8000H, 0011H)
EVRC (SO=0003H)
SMV (SO=0038H)
Wideband Speech Codec (SO=003EH)
Enhanced Variable Rate Codec rev. B (EVRC-B) (SO=0044H) on A2 and A2p
Enhanced Variable Rate Codec Wide Band (EVRC-WB) (SO=0046H) on A2 and A2p
Enhanced Variable Rate Codec Narrowband-Wideband (EVRC-NW) on A2 and A2p
Section 3.29 describes the IOS messaging required to support vocoder assignment by the BS.
2.30 Reverse FCH Gating 19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
This feature is intended to increase MS talk time and reverse link capacity by using discontinuous transmission mode operation for 1/8 rate frames on the reverse Fundamental channel. The transmission of the Reverse Fundamental Channel with Radio Configuration 3, 4, 5, or 6 may be gated when no other reverse traffic channel is assigned and the data rate is 1500 bps for Radio Configurations 3 and 5, or 1800 bps for Radio Configurations 4 and 6. The MS performs reverse Fundamental Channel gating on the reverse 1/8th rate frames by gating off for 10 ms per one frame. The reverse Fundamental Channel gating operation is synchronized with the Reverse Pilot Channel gating operation when there is no reverse traffic channel other than the FCH. The forward power control bits on the Reverse Pilot Channel are transmitted at half rate (400 Hz) during gated mode operation.
This feature is supported in this standard by use of A1, A1p, A3 and A7 messages. For hard handoff scenarios, the source base station indicates the use of FCH gating by setting the REV_FCH_GATING bit to ‘1’ in the IS-2000 Channel Identity information element. The Reverse Power Control Delay is indicated in the Hard Handoff Parameters information element.
For soft handoff scenarios, the source base station indicates the use of FCH gating by setting the REV_FCH_GATING bit to ‘1’ in the Physical Channel Info information element (sent in the A7 Handoff Request message). The target base station can indicate cell support for this feature by setting the REV_FCH_GATING bit to ‘1’ in the A3 Connect Info information element (sent in the A3 Connect message). The Reverse Power Control Delay is indicated in the IS-2000 Power Control Info information element.
Section 2 46
3GPP2 A.S0013-D v2.0
If the cell being added for soft handoff does not support this feature, the target base station sets the REV_FCH_GATING bit in the A3 Connect Info information element to ‘0’. In this situation, the source base station does not add this soft handoff leg.
1
2
3
2.31 Voice-over-IP (VoIP) 4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Efficient Voice-over-IP (VoIP) service requires minimizing transmission overhead over the air. Two service options are currently supported that reduce RTP/UDP/IP headers for VoIP service: Link-Layer Assisted Header Removal and Link-Layer Assisted Robust Header Compression (SO’s 60 and 61, respectively); refer to [27]. These service options are supported over a fundamental channel on the air interface.
Establishing a VoIP session requires a SO 33 PDSI to exchange Session Initiation Protocol (SIP) messages (or an equivalent signaling protocol) between the MS and a remote VoIP peer. This exchange establishes the vocoder and transport endpoints (IP addresses and UDP ports) that are used by the Real Time Protocol (RTP) flow. Note that this signaling may be initiated either by the MS or by the remote VoIP peer as long as a SO 33 PDSI exists. To establish a VoIP PDSI, the MS sends an origination message to the BS to request the VoIP service instance. The MS always initiates the request since there is no provision for network-initiated establishment of a PDSI. A PDSI used for the VoIP session signaling may transition to the Dormant State once VoIP setup is complete.
To release a VoIP session gracefully, and consequently the VoIP PDSI, a PDSI used for VoIP session signaling is reactivated (if necessary) and the MS and the remote peer use SIP (or an equivalent signaling protocol) over this PDSI.
Refer to section 3.17 for packet data service call flows (e.g., section 3.17.4.2 for call setup).
2.31.1 Voice over IP Handoff Considerations 24
25
26
27
28
29
There is no Dormant State defined for the VoIP service options; a VoIP SO is either active or inactive. Therefore, all handoffs of VoIP service instances are active (hard or soft) handoffs. The procedures for active packet data handoff, including those procedures termed “fast handoff” in section 2.19.4, which involve pre-establishment of A10 and P-P connections, are followed.
2.32 Network Directed System Selection (NDSS) 30
31
32
33
34
35
36
37
38
39
40
41
42
43
The Network Directed System Selection (NDSS) feature provides a network-based mechanism for a service provider, based on various customer and service provider specified criteria, to automatically re-direct an MS origination or registration to a desired serving system. The desired serving system may be any system, regardless of frequency band, technology (e.g. analog or digital) or generation (2G or 3G).
This feature is intended to re-direct the origination or registration of the MS from a cdma2000 1x system to another system (e.g., IS-95 A/B system, Analog system). When the MSC re-directs the registration or origination from the MS, it can allow the MS to return if the redirection to the desired system fails. In this situation, the source BS may inform the MSC that the CM Service Request or Location Updating Request message is caused by the return of the MS.
This feature may be used, for example, when a voice origination from a dual mode (e.g., IS-95 A/B and cdma2000 1x) MS is re-directed from the cdma2000 1x system to an IS-
47 Section 2
3GPP2 A.S0013-D v2.0
95A/B system for distributed overload control. This can be used to avert overload conditions in the cdma2000 1x system.
1
2
3 Refer to section 3.32 for call flows associated with this feature.
2.33 Transcoder Free Operation (TrFO) 4
5
6
7
8
9
10
11
12
13
14
15
16
17
TrFO is a mechanism for configuring a call such that no transcoders are needed in the core network. The vocoders that are needed for this call are located in the MSs. TrFO utilizes out of band signaling capabilities that include the ability to determine the negotiated codec type to be used at the two end nodes. If the two end nodes are capable of the same codec operations, it may be possible to traverse the entire packet network using only the compressed speech (of the preferred codec).
By transporting only compressed speech, TrFO achieves bandwidth efficiencies in the bearer stream and reduces round trip delays introduced by unnecessary coding and decoding of the signal by intermediate elements in the bearer path. Elimination of unnecessary transcoding may also increase voice quality.
The MSCe(s) control the transcoder configuration in the bearer path on a call-by-call basis and may change the transcoder configuration during a call.
TrFO is a capability of the Legacy MS domain.
2.34 Remote Transcoder Operation (RTO) 18
19
20
21
22
23
24
25
26
27
28
Remote Transcoder Operation (RTO) is a mechanism for configuring a call such that a transcoder resource is needed in the core network. RTO does not imply a tandem operation, instead only a single resource may be needed. E.g., to support a MS to PSTN call, a transcoder is inserted at the MGW. For a MS to MS call, where the codecs in the two MSs differ, a transcoder is needed in the network. This eliminates the typical tandem use where two transcoders are used to transcode the two endpoints to a common but unique protocol for transport.
The MSCe(s) control the configuration of the bearer path on a call-by-call basis. The MSCe may change the bearer path during a call.
2.35 Voice Preference Over Packet (VPOP) 29
30
31
32
33
34
35
36
37
38
39
The VPOP feature gives priority to voice calls over packet data calls (e.g. SO 33 packet data call). VPOP enables voice calls to be delivered to a subscriber engaged in an active packet data session when concurrent services are either not supported by the MS or the network, or the MSC chooses to perform VPOP call delivery over concurrent service invocation. The packet data session is suspended (i.e. transitioned to the Dormant State) for the duration of the voice call delivered by the MSC. Once the voice call is terminated the data call can resume (this can be MS or network initiated).
A user may subscribe to VPOP as a supplementary service (e.g., as is done with Call Waiting) and activate and de-activate the feature as specified in section 2.6 Supplementary Services.
Section 2 48
3GPP2 A.S0013-D v2.0
Refer to section 3.35 for call flows associated with this feature. 1
2.36 Circuit Switched Video Conferencing Calls 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Circuit Switched Video Conferencing Services allow the MS to send and receive synchronized audio and video for real-time conferencing. Service Option 57 is used for a data rate of 32 kbps and Service Option 58 is used for a data rate of 64 kbps. This feature applies to circuit-switched MSCs only. Refer to [30] for details on the service options (57 and 58).
Per [30], RLP is terminated in the SDU. A Rate Adaptation function at the BS adapts the rate above RLP to the fixed rate of the terrestrial bearer for traffic flowing from the MS to the network. The Rate Adaptation function performs the complementary procedure for traffic flowing from the network to the MS. The A2 interface carries the rate adapted data between the BS and the MSC.
Normal call origination, call termination, and call clearing procedures apply.
Call flows associated with this feature are described in sections 3.1.1, 3.1.2, and 3.2.
Inter-BS hard handoffs for circuit video conferencing calls are not supported in this release.
2.37 Fast Call Setup 17
18
19
Fast Call Setup refers to a group of air interface features that help facilitate reduced call setup time.
2.37.1 Direct Channel Assignment 20
21
22
23
24
The Direct Channel Assignment (DCA) feature facilitates faster mobile terminated call setups by reducing the air interface signaling required to set up the call. DCA allows the BS to bypass normal paging procedures and directly assign the mobile to a traffic channel.
2.38 Support for cdma2000 Pre-Rev D MEID Capable Mobiles 25
26
27
28
29
30
31
32
The support for cdma2000 pre-Revision D MEID capable mobiles feature addresses the impending exhaustion of ESNs available to operators. MEID is used to uniquely identify an MS in a wireless system and is supported in IOS v5.0 for cdma2000 Revision D MSs. This feature provides MEID and enhanced Public Long Code Mask (PLCM) support for Pre-Rev-D MEID capable MSs (cdma2000 Revision 0, Revision A, Revision B, or Revision C mobile stations). For a detailed description of this feature, refer to [32].
2.39 Support for Enhanced Frequency Hashing and Band Subclasses 33
34
35
36
37
To support enhanced frequency hashing specified in [1]~[6] or BS resource allocation in general within a multi-band class and/or multi-band subclass environment, the BS needs to determine all band classes and band subclasses supported by the MS. The BS may get this information in various ways:
49 Section 2
3GPP2 A.S0013-D v2.0
it may use the Status Request Message to retrieve the information from the MS, 1
2
3
4
5
6
7
8
it may retrieve the information through overhead queries, or
it may receive the information from the MSC.
The IOS supports this feature by including the MS's supported band classes and band subclasses in various A1/A1p messages sent from the MSC to the BS. This information is also sent in various A1/A1p messages from the BS to the MSC, so that the information may be stored in the core network for later use or forwarded to the target BS during a handoff.
2.40 Event Notification 9
10
11
12
13
Event notification is a feature that allows the MSC to alert a BS that an event has occurred that may alter processing of a call, before an SCCP link has been set up for the call. This feature uses the Event Notification message defined in [14]. Two examples are given in section 3.38.
2.41 Additional Geographical Location Information 14
15
16
17
18
19
20
21
The additional information, ADD_GEO_LOC_TYPE (refer to [5]), allows the MS to inform the network of its additional positioning capabilities (e.g., Global Navigation Satellite Systems capabilities (refer to [24])), in addition to its positioning capabilities (e.g., Global Positioning System capabilities (refer to [24])) as provided in the Geo_Location_Type. The additional information is included by the BS when available, for registration, originations and status responses (similar to the inclusion of Geo Location Type information).
2.42 Flex Duplex Channel 22
23
24
25
26
27
28
29
30
Typical CDMA systems assign forward CDMA channels and reverse CDMA channels that have a fixed spacing. Flex duplex allows for variable spacing between the forward and reverse channels. Refer to [5]. The cdma2000 air interface supports a new overhead message, Flex Duplex CDMA Channel List message, to list flex duplex channels and provide band class/subclass information. This information is used for channel assignment and for handoff into a flex duplex channel (FDC). To support hard handoff into an FDC, the forward/reverse channel frequency and band class are passed from the target BS to the source BS.
2.43 Features Supported Transparently in this Standard 31
32
33
34
35
The features included in this section are supported transparently (i.e., there are no messages, call flows, information elements, fields, value ranges, etc., that need to be added or modified to support them) by this version of the standard. The list is not intended to be exhaustive.
2.43.1 Emergency Service (Basic) via Specific Dialed Number 36
37
38
39
For E911 Phase 1 and Phase 2, refer to section 2.9.
Emergency calls are handled as regular calls by the BS. There is no impact to the RAN. For basic emergency calls, the specific digit string (e.g. 911) constitutes the dialed digits.
Section 2 50
3GPP2 A.S0013-D v2.0
Alternatively, the MS may signal that the call is an emergency call, in which case the Global Emergency Call Indication is used (refer to section 2.8).
1
2
3
4
The call flows for this feature are identical to the call flows for a mobile originated call; refer to section 3.1.1.
2.43.2 Carrier Access 5
6
7
8
This feature uses carrier access codes as prefixes to the called party number to set up an MS originated call. It is supported transparently by the IOS interfaces (IOS allows up to a total of 32 digits in the Origination Messages).
2.43.3 Call Forwarding 9
10
11
12
13
14
15
16
17
18
19
20
21
Call Forwarding permits a called subscriber to send incoming calls addressed to the called subscriber’s Directory Number to another Directory Number (forward-to number) or to the called subscriber’s designated voice mailbox. The call forwarding may be done under following conditions:
Unconditional
When Busy
No Answer
Default
Feature codes are sent in the Called Party BCD Number or Called Party ASCII Number parameter of the CM Service Request message (refer to [14]) when a subscriber initiates actions (e.g. to activate or deactivate Call Forwarding). Incoming calls are forwarded by the MSC; this is transparent to the IOS interfaces.
2.43.3.1 Call Forwarding Unconditional 22
23
24
25
Call Forwarding Unconditional provides the capability to a subscriber to forward calls regardless of the condition of the termination.
This feature is transparent to IOS interfaces. For further description, refer to [I-1].
2.43.3.2 Call Forwarding When Busy 26
27
28
29
Call Forwarding When Busy provides the capability to a subscriber to forward calls when the subscriber is busy.
This feature is transparent to IOS interfaces. For further description, refer to [I-1].
2.43.3.3 Call Forwarding - No Answer 30
31
32
33
34
Call Forwarding When No Answer provides the capability to a subscriber to forward calls when the subscriber fails to answer a call or is otherwise inaccessible (excluding busy).
This feature is transparent to IOS interfaces. For further description, refer to [I-1].
51 Section 2
3GPP2 A.S0013-D v2.0
2.43.3.4 Call Forward Default 1
2
3
4
Call Forwarding Default provides the capability to a subscriber to forward calls when the subscriber fails to answer a call, is busy or is otherwise inaccessible.
This feature is transparent to IOS interfaces. For further description, refer to [I-1].
2.43.4 Call Delivery 5
6
7
8
Call Delivery allows a subscriber to receive a call to his or her directory number while roaming.
This feature is transparent to IOS interfaces. For further description, refer to [I-1].
2.43.5 Advice of Charge 9
10
11
12
13
14
15
16
17
18
19
20
21
Advice of Charge (refer to [29]) permits a wireless subscriber to receive charging information for telecommunication services.
Information is presented at the start of a call, during a call, or at the end of a call. Information is conveyed to the subscriber within five (5) seconds of the appropriate event (start of call, mid-call charging event, and end of call).
Information may be presented using visual display, distinctive alerting, audible tone or announcement, or a combination of visual display, distinctive alerting, and audible tone or announcement.
This feature is activated according to Feature Activation described in section 2.6.1.
Information is sent from the MSC to the MS via the BS using Flash with Information messages.
There are no call flows associated with this feature.
2.43.6 Call Transfer 22
23
24
25
26
27
28
29
30
31
32
33
Call Transfer enables a subscriber to transfer an in-progress established call to a third party. The call to be transferred may be an incoming or outgoing call.
Call Transfer allows a controlling subscriber to put a call on hold, dial a third party, then connect the held party and the third party into a call
Call Transfer also allows a controlling subscriber, that also has Three-Way Calling (3WC) active, to set up a three-way call and drop out of the call leaving the other two parties of call connected to each other.
This feature is activated according to Feature Activation described in section 2.6.1.
The feature is invoked using the Flash with Information messages.
There are no call flow is associated with this feature.
For further description refer to [I-1].
Section 2 52
3GPP2 A.S0013-D v2.0
2.43.7 Lawfully Authorized Wiretap 1
2
3
4
5
6
7
8
9
10
11
12
13
14
Lawfully Authorized Wiretap refers to accessing communications as an intercept access service. The service fall into four categories:
Non-call associated service to provide information about a subject that is not necessary related to a call.
Call associated service to provide call-identification information about calls involving the intercept subject.
Call associated and non-call associated service to provide subject and network signaling call-identifying information.
Content surveillance services to provide access to an intercept subject’s communication.
Location support for wiretapping is not required; however, location of the wiretap subject may be provided using the most recent Cell ID parameter provided to the MSC.
There are no call flows associated with this feature.
2.43.8 Access Control by Call Type (ACCT) 15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
The Access Control by Call Type (ACCT) feature is activated by the BS for controlling access attempts by certain classes of MSs for a specific service option or a set of service options. For instance, if both voice and packet data calls are supported in the same frequency band, and the RAN is having problems establishing packet data calls but is not having problems establishing voice calls, ACCT allows the BS to control access attempts by MSs based on the call type, by allowing voice calls but blocking data calls. Refer to [5].
ACCT may be activated by the BS based on interaction with the PDSN or the MSC, or triggers internal to the BS. On activation of ACCT, the base station includes the SOs that it is going to control within the APM/EAPM messages. For each specified SO, the BS also lists group(s) of MSs to block. MSs that belong to the groups that are blocked do not originate calls for those SOs. The BS may also use APM/EAPM to modify the ACCT for groups of MSs for specific service option(s), add control for different service option(s), remove control for specific service option(s) or turn off the ACCT control completely.
No call flows are associated with this feature.
53 Section 2
3GPP2 A.S0013-D v2.0
Section 2 54
1
2
3
4
5
6
(This page intentionally left blank.)
3GPP2 A.S0013-D v2.0
3.0 Feature Call Flows 1
2 Refer to [14]~[17] for definitions of messages and timers used in this document.
3.1 Call Setup of Voice and Circuit Data Calls 3
4
5
6
Call flows for setup of mobile originated and terminated voice and circuit data calls are described in this section.
For details on call clearing call flows, refer to section 3.2.
3.1.1 Mobile Origination Examples 7
8
9
10
11
12
13
14
15
Mobile originated call setup involves exchange of the following A1 or A1p messages:
Complete Layer 3 Information with Connection Management (CM) Service Request
Connection Management (CM) Service Request Continuation
Assignment Request
Assignment Failure
Assignment Complete
Bearer Update Request
Bearer Update Response.
3.1.1.1 Mobile Origination 16
17 This section describes the call flow associated with an MS call origination in the system.
3.1.1.1.1 Mobile Origination via a Circuit Switched MSC 18
19
20
This section describes the call flow associated with an MS call origination via a circuit switched MSC.
55 Section 3
3GPP2 A.S0013-D v2.0
MS BS MSC time comment
Origination Message
Base Station Ack Order
a
b
c
d
e
f
Complete L3 Info: CM Service Request
Assignment Request
channel assignment
Tch Preamble
g
h
BS Ack Order
MS Ack Order
Service Connect Message
Assignment Complete
Call Progress Indication
i
k
l
T10
Transparent to signaling
Service Connect Completion j
T303
Origination Continuation Message CM Service Request Continuation
T312
m
n
Conditional
Conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Figure 3.1.1.1.1-1 Mobile Origination via a Circuit Switched MSC
a. The MS transmits an Origination Message, with Layer 2 Ack required, over the Access Channel of the air interface to the BS to request service.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
If the BS can determine that resources, e.g., a traffic channel, are not available, the BS may perform the “PACA” call flow described in section 3.11 provided that the MS indicated PACA supported in the Origination message. Otherwise, the call is allowed to proceed.
c. The BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the circuit-switched MSC, and starts timer T303. For circuit switched calls, the BS may request the circuit-switched MSC to allocate a preferred terrestrial circuit. If the Origination Message sent in step ‘a’ indicated that it is to be followed by an Origination Continuation Message, the CM Service Request message shall include an Origination Continuation Indicator element and the MSC shall start timer T312 to await the CM Service Request Continuation message.
If the 2G global challenge or 3G authentication (refer to the AKA support in Step ‘d’) is used, the circuit-switched MSC continues the call setup process while waiting for an authentication confirmation. If an authentication failure indication is received at the circuit-switched MSC, it may clear the call. Some in-band treatment may be provided on discretion of the circuit-switched MSC manufacturer, e.g., tone or announcement, assuming the BS has already done radio channel assignment and set up a bearer path to the circuit-switched MSC.
Section 3 56
3GPP2 A.S0013-D v2.0
d. The circuit-switched MSC sends an Assignment Request message to the BS to request assignment of radio resources. This message includes information on the terrestrial circuit, if one is to be used between the circuit-switched MSC and the BS. The circuit-switched MSC then starts timer T10.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
If the BS requested a preferred terrestrial circuit in the CM Service Request message and the circuit-switched MSC can support that terrestrial circuit, the circuit-switched MSC shall use the same terrestrial circuit in the Assignment Request message. Otherwise, the circuit-switched MSC may assign a different terrestrial circuit.
If the ‘Include Priority’ bit of the Radio Environment and Resources element was set to ‘1’ in the CM Service Request message to indicate that no lower priority channels are available (e.g., when a PACA channel reservation scheme is used) the circuit-switched MSC shall include the actual call priority.
Upon receipt of the Assignment Request message from the circuit-switched MSC, the BS stops timer T303.
The MSC may include authentication and integrity information in the Assignment Request message (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSC and BS support AKA). If the Assignment Request message includes authentication vector information the BS shall initiate mutual authentication with the MS as defined in [5]. Upon receipt of an MS response, the BS shall return an Authentication Report message to the MSC. Refer to section 3.20.1.6 for 3G authentication and message integrity procedures.
e. If a traffic channel is available for the call, the BS sends a channel assignment message4 over the Paging Channel of the radio interface (with the MS address) to initiate the establishment of a radio traffic channel, if the MS is not already on a traffic channel.
If for any reason the BS is unable to assign resources (e.g., a traffic channel) for this call and the call is given PACA service, the BS queues the request and notifies the MS of the reason and the current queue position (refer to section 3.11). The BS then sends an Assignment Failure message to the circuit-switched MSC with the Cause field set to ‘PACA Call Queued’. The circuit-switched MSC initiates normal call clearing call flow as described in section 3.2.2 to release the underlying transport connection.
When a traffic channel becomes available, the BS instructs the MS to re-originate the call by sending a PACA Message.
f. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
g. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
h. The MS acknowledges the reception of the BS Ack Order by transmitting the Mobile Station Acknowledgment Order and by sending null traffic channel data (Null TCH Data) over the reverse traffic channel.
i. The BS sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
4 This may be Channel Assignment Message or Extended Channel Assignment Message.
57 Section 3
3GPP2 A.S0013-D v2.0
j. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
k. If the MS indicated in the Origination Message in step ‘a’ that an Origination Continuation Message would follow, the MS sends this message.
l. If the BS received an Origination Continuation Message in step ‘k’, it sends a CM Service Request Continuation message to the circuit-switched MSC. Upon receipt of this message the MSC shall stop timer T312.
m. After the radio traffic channel and circuit have both been established and fully interconnected, the BS sends the Assignment Complete message to the circuit-switched MSC and considers the call to be in Conversation State.
The circuit-switched MSC stops timer T10 upon receipt of the Assignment Complete message.
n. As call progress tone is applied in-band in this case, ringback tone is available on the audio circuit path towards the MS.
3.1.1.1.2 Mobile Origination with an MSCe with Bearer Parameters Sent in the CM Service Request Message 16
17
18
19
This section describes the call flow associated with an MS call origination via an MSCe with bearer parameters sent in the CM Service Request Message. The call flow supports TrFO and RTO.
Section 3 58
3GPP2 A.S0013-D v2.0
1
conditional
conditional
optional
MS BS MSCe time comment
MS Origination
Base Station Ack Order a
b
c
d
e
f
CM Service Request
Assignment Request
channel assignment
TCH Preamble
g
h
BS Ack Order
MS Ack Order
Service Connect
Assignment Complete
Call Progress Indication Enabled
k
m
n
T10
Transparent tosignaling
Service Connect Completion
l
T303
Origination Continuation CM Service RequestContinuation
T312
o
p
Bearer Update Request
Bearer Update Response q
r
MGW
i
j
Tyyp
Bidirectional Audio Enabled Transparent tosignaling
Service Change
conditional
Txxp
conditional
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Figure 3.1.1.1.2-1 Mobile Origination with Bearer Parameters Sent in the CM Service Request Message
a. The MS transmits an Origination Message, with Layer 2 Ack required, over the Access Channel of the air interface to the BS to request service.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
If the BS can determine that resources, e.g., a traffic channel, are not available, the BS may perform the “PACA” call flow described in section 3.11 provided that the MS indicated PACA supported in the Origination message. Otherwise, the call is allowed to proceed.
c. The BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSCe, and starts timer T303. Since the bearer formats and addressing are known in this scenario, the BS includes the
59 Section 3
3GPP2 A.S0013-D v2.0
A2p bearer parameters5. If the Origination Message sent in step ‘a’ indicated that it is to be followed by an Origination Continuation Message, the CM Service Request message shall include an Origination Continuation Indicator element and the MSCe shall start timer T312 to await the CM Service Request Continuation message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
If the 2G global challenge or 3G authentication (refer to the AKA support in step ‘d’) is used, the MSCe continues the call setup process while waiting for an authentication confirmation. If an authentication failure indication is received at the MSCe, it may clear the call. Some in-band treatment may be provided on discretion of the MSCe manufacturer, e.g., tone or announcement, assuming the BS has already done radio channel assignment and set up a bearer path to the MGW.
d. The MSCe sends an Assignment Request and starts timer T10. This message may contain the bearer format and transport address of the MGW to be used for this call. If the MSCe does not include this information in the Assignment Request message then the MSCe shall send it in a Bearer Update Request message.
If the ‘Include Priority’ bit of the Radio Environment and Resources element was set to ‘1’ in the CM Service Request message to indicate that no lower priority channels are available (e.g., when a PACA channel reservation scheme is used) the MSCe shall include the actual call priority.
Upon receipt of the Assignment Request message from the MSCe, the BS stops timer T303.
The MSCe may include authentication and integrity information in the Assignment Request message (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSCe and BS support AKA). If the Assignment Request message includes authentication vector information the BS shall initiate mutual authentication with the MS as defined in [5]. Upon receipt of an MS response, the BS shall return an Authentication Report message to the MSCe. Refer to section 3.20.1.6 for 3G authentication and message integrity procedures.
e. If a traffic channel is available for the call, the BS sends a channel assignment message6 over the Paging Channel of the radio interface (with the MS address) to initiate the establishment of a radio traffic channel, if the MS is not already on a traffic channel.
If for any reason the BS is unable to assign resources (e.g., a traffic channel) for this call and the call is given PACA service, the BS queues the request and notifies the MS of the reason and the current queue position (refer to section 3.11). The BS then sends an Assignment Failure message to the MSCe with the Cause field set to ‘PACA Call Queued’. The MSCe initiates normal call clearing call flow as described in section 3.2.2 to release the underlying transport connection.
When a traffic channel becomes available, the BS instructs the MS to re-originate the call by sending a PACA Message.
f. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
5 Parameters contained within the A2p Bearer Session Parameters IE and/or the A2p Bearer Format Specific Parameters IE.
6 This may be Channel Assignment Message or Extended Channel Assignment Message.
Section 3 60
3GPP2 A.S0013-D v2.0
g. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
h. The MS acknowledges the reception of the BS Ack Order by transmitting the Mobile Station Acknowledgment Order and by sending null traffic channel data (Null TCH Data) over the reverse traffic channel.
i. The BS and MS may perform service negotiation as needed, to decide on the service configuration to be used. The BS sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
j. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
k. If the MS indicated in the Origination Message in step ‘a’ that an Origination Continuation Message would follow, the MS sends this message.
l. If the BS received an Origination Continuation Message in step ‘k’, it sends a CM Service Request Continuation message to the MSCe. Upon receipt of this message the MSCe shall stop timer T312.
m. After the radio traffic channel has been established, the BS sends the Assignment Complete message to the MSCe. In this scenario, the A2p bearer parameters are not included in this message. The MSCe stops timer T10 upon receipt of the Assignment Complete message. If the BS has received the bearer format and transport address to be used, the BS establishes the necessary transport facilities and considers the call to be in Conversation State. If the BS has not received the bearer format and transport address to be used from the MSCe, the BS starts timer Txxp and, if Txxp expires, the BS releases the call.
n. As call progress indications may be applied in-band, ringback tones and/or audio announcements may be sent on the A2p audio path towards the MS after step ‘m’ provided that the A2p bearer path has been established.
o. If the MSCe determines that a change in the bearer session is needed or if the MSCe did not send the bearer format and transport address to be used in the Assignment Request message, then the MSCe sends a Bearer Update Request message containing the A2p bearer parameters, to the BS. The MSCe starts timer Tyyp. Upon receipt of this message, the BS stops timer Txxp if it is running.
p. If the BS receives a Bearer Update Request message, the BS may change the traffic channel and/or the Service Option as needed.
q. If a Bearer Update Request message was received, the BS sends a Bearer Update Response message to the MSCe, conveying any changes in the bearer or session address for the call. The BS establishes the necessary transport facilities and considers the call to be in Conversation State. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
r. After the BS sends the Bearer Update Response message, bi-directional audio is enabled on the A2p interface.
3.1.1.1.3 Mobile Origination with an MSCe with Bearer Parameters Sent in the Assignment Complete Message 45
46
47
This section describes the call flow associated with an MS call origination via an MSCe with A2p bearer parameters sent in the Assignment Complete Message, since the
61 Section 3
3GPP2 A.S0013-D v2.0
information is not available at the time that the CM Service Request is sent. The call flow supports TrFO and RTO.
1
2
Call Progress Indication
MS BS MSCe time comment
MS Origination
Base Station Ack Order a
b
c
d
e
f
CM Service Request
Assignment Request
Channel Assignment
TCH Preamble
g
h
BS Ack Order
MS Ack Order
Service Connect
Assignment Complete
i
k
l
T10
Transparent to signaling
Service Connect Completion j
T303
Origination Continuation CM Service RequestContinuation
T312
m
n Bearer Update Request
Bearer Update Response
o
p
q
MGW
Tyyp
Bidirectional Audio Enabled r
Transparent to A1p signaling
Txxp
Service Change
Conditional
Conditional
Conditional
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Figure 3.1.1.1.3-1 Mobile Origination with Bearer Parameters sent in the Assignment Complete Message
a. The MS transmits an Origination Message, with Layer 2 Ack required, over the Access Channel of the air interface to the BS to request service.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
If the BS can determine that resources, e.g., a traffic channel, are not available, the BS may perform the “PACA” call flow described in section 3.11 provided that the MS indicated PACA supported in the Origination message. Otherwise, the call is allowed to proceed.
c. The BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSCe, and starts timer T303. If the Origination Message sent in step ‘a’ indicated that it is to be followed by an
Section 3 62
3GPP2 A.S0013-D v2.0
Origination Continuation Message, the CM Service Request message shall include an Origination Continuation Indicator element and the MSCe shall start timer T312 to await the CM Service Request Continuation message. In this scenario, the BS does not have enough information to include the A2p bearer parameters in the CM Service Request message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
If the 2G global challenge or 3G authentication (refer to the AKA support in step ‘d’) is used, the MSCe continues the call setup process while waiting for an authentication confirmation. If an authentication failure indication is received at the MSCe, it may clear the call. Some in-band treatment may be provided on discretion of the MSCe manufacturer, e.g., tone or announcement, assuming the BS has already done radio channel assignment and set up a bearer path to the MGW.
d. The MSCe sends an Assignment Request message to the BS to request assignment of radio resources.
If the ‘Include Priority’ bit of the Radio Environment and Resources element was set to ‘1’ in the CM Service Request message to indicate that no lower priority channels are available (e.g., when a PACA channel reservation scheme is used) the MSCe shall include the actual call priority.
Upon receipt of the Assignment Request message from the MSCe, the BS stops timer T303.
The MSCe may include authentication and integrity information in the Assignment Request message (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSCe and BS support AKA). If the Assignment Request message includes authentication vector information the BS shall initiate mutual authentication with the MS as defined in [5]. Upon receipt of an MS response, the BS shall return an Authentication Report message to the MSCe. Refer to section 3.20.1.6 for 3G authentication and message integrity procedures.
e. If a traffic channel is available for the call, the BS sends a channel assignment message7 over the Paging Channel of the radio interface (with the MS address) to initiate the establishment of a radio traffic channel, if the MS is not already on a traffic channel.
If for any reason the BS is unable to assign resources (e.g., a traffic channel) for this call and the call is given PACA service, the BS queues the request and notifies the MS of the reason and the current queue position (refer to section 3.11). The BS then sends an Assignment Failure message to the MSCe with the Cause field set to ‘PACA Call Queued’. The MSCe initiates normal call clearing call flow as described in section 3.2.2 to release the underlying transport connection.
When a traffic channel becomes available, the BS instructs the MS to re-originate the call by sending a PACA Message.
f. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
g. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
h. The MS acknowledges the reception of the BS Ack Order by transmitting the Mobile Station Acknowledgment Order and by sending null traffic channel data (Null TCH Data) over the reverse traffic channel.
7 This may be Channel Assignment Message or Extended Channel Assignment Message.
63 Section 3
3GPP2 A.S0013-D v2.0
i. The BS sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
j. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
k. If the MS indicated in the Origination Message in step ‘a’ that an Origination Continuation Message would follow, the MS sends this message.
l. If the BS received an Origination Continuation Message in step ‘k’, it sends a CM Service Request Continuation message to the MSCe. Upon receipt of this message the MSCe shall stop timer T312.
m. After the radio traffic channel has been established, the BS sends the Assignment Complete message to the MSCe. The A2p bearer parameters shall be included in this message. The BS starts timer Txxp and, if Txxp expires, the BS releases the call.
The MSCe stops timer T10 upon receipt of the Assignment Complete message.
n. The MSCe sends a Bearer Update Request message containing the A2p bearer parameters, to the BS. The MSCe starts timer Tyyp. Upon receipt of this message, the BS stops timer Txxp.
o Conditioned upon the contents of the Bearer Update Request message received in step ‘n’ the BS may need to change the traffic channel and/or the Service Option as needed. The BS establishes the necessary transport facilities and considers the call to be in Conversation State.
p. The BS sends a Bearer Update Response message to the MSCe, conveying any changes in bearer or session address configuration for the call. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
q. As call progress indications may be applied in-band, ringback tones and/or audio announcements may be sent on the A2p audio path towards the MS after step ‘p’.
r. After the BS sends the Bearer Update Response message, bi-directional audio is enabled on the A2p interface.
Section 3 64
3GPP2 A.S0013-D v2.0
3.1.1.2 Mobile Origination with Access Probe Handoff, Access Handoff and Channel Assignment into Soft/Softer Handoff
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
This section describes the call flow associated with mobile origination and access probe handoff, access handoff and channel assignment into soft handoff using the source BS (the BS on which the first probe was sent). The same technique applies to the mobile termination case.
The call flow assumes that all BSs (source and target) are either all connected to a circuit-switched MSC or to an MSCe. If all BSs are connected to an MSCe, then Bearer Update Request/Response messages (not shown in Figure 3.1.1.2-1) may be exchanged between the MSCe and the BS to specify the bearer format and address to be used with the MGW.
The access handoff, access probe handoff, and channel assignment into soft handoff functions shown in the following diagram are not all necessarily required for each call setup. The diagram gives an example of a call where all three are used, but that is not the case for all calls. In this section, “A3-CEData Forward/Reverse” messages represent “A3-IS-95 FCH Forward/Reverse”, “A3-IS-2000 FCH Forward/Reverse”, or “A3-IS-2000 DCCH Forward/Reverse” messages.
65 Section 3
3GPP2 A.S0013-D v2.0
Origination Message (II)
x
MS Source
BS MSC time comment
a
c
e
f
g
h
T303
Base Station Ack Order
b
d
Target BS-1
Target BS-2
Target BS-3
x Origination 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
m A7-Handoff Request Ack
A3-Connect Ack
Thoreq
n Origination Message (III)
o Base Station Ack Order
q
p A7-Access Channel Message Transfer
A7-Access Channel Message Transfer Ack
Tacm
Assignment Request
s
A7-Paging Channel Message Transfer
r
x x
x
Extended Channel Assignment Message
t
u
Pilot Preamble T10
Source BS was attempted first
Access probe handoff to target BS-1
Access probe handoff to target BS-2
Access probe handoff ends
Access handoff to target BS-3
SCENARIO CONTINUES NEXT PAGE
These messages are used to set up soft handoff legs for channel assignment into soft handoff.
1
2
3
Figure 3.1.1.2-1 Mobile Origination with Access Probe Handoff, Access Handoff and Channel Assignment into Soft/Softer Handoff
Section 3 66
3GPP2 A.S0013-D v2.0
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 PREVIOUSPAGE MS Ack Order
Service Connect Message
Service Connect Completion Message
aaHandoff Performed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Figure 3.1.1.2-1 (Cont.) Mobile Origination with Access Probe Handoff, Access Handoff and Channel Assignment into Soft/Softer Handoff
a. The MS transmits an Origination Message (Origination (I)), with Layer 2 Ack required, over the Access Channel of the air interface to the source BS to request service. Because this BS is the first to which the MS sends an access probe, it becomes by definition the source BS for this call setup attempt. In this message the MS reports the pilot strength of all the pilots in the MS’s Paging Channel Active Set. It also reports other pilots using the ACCESS_HO_LIST and the OTHER_REPORTED_LIST (refer to [1]~[6]). This message is not received by the source BS.
b. The MS performs an access probe handoff and sends a second Origination Message (Origination (II)), with Layer 2 Ack required, over the Access Channel of the air interface to the target BS-1 to request service. Note that the target BS-1 may not have been in the ACCESS_HO_LIST in step ‘a’.
c. The target BS-1 acknowledges the receipt of the Origination Message with a Base Station Acknowledge Order to the MS. The BS Ack Order is not received by the MS.
d. The target BS-1 recognizes that it is not the first accessed BS and encapsulates the Origination Message received from the MS in the A7-Access Channel Message Transfer message and forwards it to the source BS instead of sending the CM Service Request message to the MSC. The target BS-1 starts timer Tacm.
e. The source BS acknowledges the A7-Access Channel Message Transfer message by sending an A7-Access Channel Message Transfer Ack message to the target BS-1. The target BS-1 stops timer Tacm.
f. The source BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303.
g. Since the Origination Message sent to the source BS carries the pilot report of other strong pilots, the source BS initiates the inter-BS soft handoff setup procedure by sending the A7-Handoff Request message to one or more target BSs. (In this example scenario, the source BS chooses target BS-1, target BS-2, and target BS-3). The source BS starts an instance of timer Thoreq for each A7 Handoff Request message sent. Alternatively, the initiation of soft handoff may be performed after receiving the Assignment Request message from the MSC.
67 Section 3
3GPP2 A.S0013-D v2.0
h. The target BSs initiate A3 connections by sending A3-Connect messages to the specified address. Each target BS starts an instance of timer Tconn3. The target BSs may begin sending null frames over the air.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
i. The source BS replies with A3-Connect Ack messages to complete the A3 connections. The target BSs stop timer Tconn3. The source BS starts an instance of timer Tchanstat for each A3 Connect Ack message sent if the source BS requests to receive A3-Traffic Channel Status messages from the target BSs.
j. The source BS begins to send idle forward frames to the target BSs.
k. The target BSs begin to send reverse idle frames as soon as the first forward frame is received from the source BS. The reverse frames contain the timing adjustment information necessary to achieve synchronization.
l. If the source BS has chosen to be notified of the start of transmission and reception at the target BSs, when its SDU function and the target BSs have synchronized the A3 traffic subchannel, the target BS replies with an A3-Traffic Channel Status message. Note that this step can occur any time after step ‘i’. The source BS stops Tchanstat timers.
m. Target BS-1, target BS-2 and target BS-3 send A7-Handoff Request Ack messages to the source BS to complete the soft handoff setup procedure. Note that this message can be sent at any time following the receipt of the A3-Connect Ack messages at each target BS. The source BS stops Thoreq timers.
n. The MS did not receive the Layer 2 Ack in response to the Origination Message at step ‘c’; therefore, it performs an access probe handoff to target BS-2, and sends a third Origination Message (Origination (III)) with the first accessed BS identified and with Layer 2 Ack required.
Note that the ACCESS_HO_LIST identifies the source BS as the first attempted, and that target BS-1 and target BS-2, which may not have been included in the ACCESS_HO_LIST in step ‘a’, are included in the ACCESS_HO_LIST in this step.
o. Target BS-2 responds with a Base Station Ack Order to the MS. The MS receives the Base Station Ack Order, which successfully completes the access attempt.
p. The target BS-2 recognizes that it is not the first accessed BS (i.e., the source BS) and encapsulates the Origination Message received from the MS in the A7-Access Channel Message Transfer message and forwards it to the source BS instead of sending the CM Service Request message to the MSC. The target BS-2 starts timer Tacm.
q. The source BS acknowledges the A7-Access Channel Message Transfer message by sending an A7-Access Channel Message Transfer Ack message to the target BS-2.
The source BS upon receiving the Origination Message from the target- BS-2 for the same MS and the same call may send a second CM Service Request to the MSC, though this option is not shown in this example. Upon receipt of the A7-Access Channel Message Transfer Ack message the target BS-2 stops timer Tacm.
r. The MSC sends an Assignment Request message to the source BS to request assignment of radio resources. The MSC then starts timer T10. Upon receipt of the Assignment Request message from the MSC, the BS stops timer T303. This step may occur any time after step ‘f’.
s. After receiving the Assignment Request message from the MSC and optionally receiving A3-Connect messages from the potential target BSs, the source BS constructs an air-interface Extended Channel Assignment message and forwards it in
Section 3 68
3GPP2 A.S0013-D v2.0
the A7-Paging Channel Message Transfer message to one or more base stations, usually chosen from those that are in the ACCESS_HO_LIST and OTHER_REPORTED_LIST (which may not be the same BSs set up in soft handoff). The A7-Paging Channel Message Transfer message may be sent any time after the A3 Connections are completed.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
t. The source BS and target BSs send the appropriate channel assignment message over the air to the MS. The probability of the MS receiving this message is substantially increased by sending this message from multiple base stations. In the meantime, the MS has performed an access handoff to target BS-3. Since the MS is listening to the Paging Channel of only one BS, it does not receive the Extended Channel Assignment Message from any other BSs than target BS-3. At any time after sending/receiving the A7-Paging Channel Message Transfer message, all soft handoff legs on the source BS and target BS begin sending null forward traffic frames to the MS.
u. After receiving the Extended Channel Assignment Message from the target BS-3 and the forward traffic frames from one or more base stations, the MS starts sending the traffic frames or preambles.
In steps ‘v’ through ‘y’, the full activity of the messaging between the source BS and the MS via the target BSs using A3-CEData Forward and A3-CEData Reverse messages and transmission and reception of messages to and from the MS by the target BSs is not shown for simplicity in the diagram.
v. If a target BS detects the reverse preamble, it sends it to the source BS in an A3-CEData Reverse message. Once the source BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel. The source BS also informs the target BSs that the reverse traffic channel was acquired by starting to send non-idle frame content type in the A3-CEData Forward messages. Upon receiving non-idle frame content in the A3-CEData Forward messages, the target BS terminates any attempts to send the channel assignment message to the MS.
w. The MS acknowledges the reception of the BS Ack Order by transmitting the Mobile Station Acknowledgment Order and by sending null traffic channel data (Null TCH Data) over the reverse traffic channel.
x. The source BS then sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
y. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
z. The source BS sends the Assignment Complete message to the MSC. At this time, the MS is on the traffic channel and the call setup into soft/softer handoff is completed successfully. The MSC stops timer T10. At this time, the MS is set up directly in soft/softer handoff with one or more base stations.
aa. The source BS may send a Handoff Performed message to the MSC as explained in section 3.19.1.1.3 “Concept of A Designated Cell”.
69 Section 3
3GPP2 A.S0013-D v2.0
3.1.2 Mobile Termination Examples 1
2
3
4
5
6
7
8
9
10
11
Mobile terminated call setup involves exchange of the following A1 or A1p messages:
Paging Request
Complete Layer 3 Information with Paging Response
Assignment Request
Assignment Complete
Assignment Failure
Alert with Information
Connect
Bearer Update Request
Bearer Update Response.
3.1.2.1 Mobile Termination 12
13
3.1.2.1.1 Mobile Termination via a Circuit switched MSC 14
15 This section describes the call flow associated with an MS call termination in the system.
Section 3 70
3GPP2 A.S0013-D v2.0
Base Station Ack Order
MS BS MSC time
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 Message b
a Paging Request
n
o
Alert with Info
MS Ack Order
Connect Order
q BS Ack Order
T301
T3113
T303
Service Connect Completion l
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.1.2.1.1-1 Mobile Termination via a Circuit switched MSC
a. The circuit-switched MSC determines that an incoming call terminates to an MS within its serving region and sends the Paging Request message to the BS to initiate a mobile terminated call setup scenario. The circuit-switched MSC then starts timer T3113.
b. The BS issues a Page Message containing the MS address over the Paging Channel.
c. The MS acknowledges the page by transmitting a Page Response Message over the Access Channel.
d. The BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, sends the message to the circuit-switched MSC, and starts timer T303. The BS may request the circuit-switched MSC to allocate a preferred terrestrial circuit.
The circuit-switched MSC stops timer T3113 upon receipt of the Paging Response message from the BS.
e. The BS acknowledges the receipt of the Page Response Message with a Base Station Acknowledgment Order to the MS.
f. The circuit-switched MSC sends an Assignment Request message to the BS to request assignment of radio resources. This message also includes terrestrial circuit if
71 Section 3
3GPP2 A.S0013-D v2.0
one is to be used between the circuit-switched MSC and the BS. The circuit-switched MSC then starts timer T10.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
If the BS requested a preferred terrestrial circuit in the Paging Response message and the circuit-switched MSC can support that terrestrial circuit, the circuit-switched MSC shall use the same terrestrial circuit in the Assignment Request message. Otherwise, the circuit-switched MSC may assign a different terrestrial circuit.
Upon receipt of the Assignment Request message from the circuit-switched MSC, the BS stops timer T303.
The MSC may include authentication and integrity information in the Assignment Request message (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSC and BS support AKA). If the Assignment Request message includes authentication vector information the BS shall initiate mutual authentication with the MS as defined in [5]. Upon receipt of an MS response, the BS shall return an Authentication Report message to the MSC. Refer to section 3.20.1.6 for 3G authentication and message integrity procedures.
g. The BS sends a channel assignment message8 over the control channel of the radio interface (with the MS address) to initiate the establishment of a radio traffic channel, if the MS is not already on a traffic channel.
h. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
i. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
j. The MS acknowledges the reception of the BS order by transmitting the Mobile Station Acknowledgment Order.
k. The BS then sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
l. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
m. After the radio traffic channel and circuit have both been established, the BS sends the Assignment Complete message to the circuit-switched MSC.
The circuit-switched MSC stops timer T10 upon receipt of the Assignment Complete message from the BS, and starts timer T301.
n. The BS sends the Alert with Information Message to the MS to cause ringing at the MS.
o. The MS acknowledges the reception of the Alert with Information Message by transmitting the Mobile Station Acknowledgment Order.
p. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted to the BS.
q. The BS acknowledges the Connect Order with the Base Station Acknowledgment Order over the forward traffic channel.
r. The BS sends a Connect message to the circuit-switched MSC to indicate that the call has been answered at the MS. The circuit-switched MSC stops timer T301 upon
8 This may be Channel Assignment Message or Extended Channel Assignment Message.
Section 3 72
3GPP2 A.S0013-D v2.0
receipt of the Connect message from the BS. At this point, the call is considered stable and in the Conversation State.
1
2
3 3.1.2.1.2 Mobile Termination via an MSCe with the Bearer Parameters sent in the Paging Response Message 4
5
6
7
This section describes the call flow associated with an MS call termination via an MSCe with bearer parameters sent in the Paging Response message. The call flow supports TrFO and RTO.
optional
Base Station Ack Order
MS BS MSCe time comment
Page Response c
d
e
f
g
h
i
j
Paging Response
Assignment Request
Channel Assignment
Tch Preamble
k
m
BS Ack Order
MS Ack Order
Service Connect
Assignment Complete
T10
Connect
s
u
Page Message b
a Paging Request
q
r
Alert with Info
MS Ack Order
Connect Order
t BS Ack Order
T301
T3113
T303
Service Connect Completion l
MGW
Bearer Update Request
Bearer Update Response
n
o
v
p
Bi-directional Audio Enabled
Service Change Tyyp
Txxp
conditional
conditional
8
9
10
11
12
13
Figure 3.1.2.1.2-1 Mobile Termination via an MSCe with the Bearer Parameters sent in the Paging Response Message
a. The MSCe determines that an incoming call terminates to an MS within its serving region and sends the Paging Request message to the BS to initiate a mobile terminated call setup scenario. The Paging Request message may include one or
73 Section 3
3GPP2 A.S0013-D v2.0
more A2p bearer formats within the A2p Bearer Format-Specific Parameters IE. The MSCe then starts timer T3113.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
If a list of one or more A2p bearer formats is included in the received Paging Request message, the BS attempts to page the MS using the service option associated with the first bearer format in the list that is supported by the BS. The first bearer format contained in the A2p Bearer-Format Specific IE and the Service Option IE should be consistent. If they are not consistent, then the Service Option IE shall take precedence.
b. The BS issues a Page Message containing the MS address over the Paging Channel.
c. The MS acknowledges the page by transmitting a Page Response Message over the Access Channel. The MS indicates a preferred Service Option for the call.
d. The BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, sends the message to the MSCe, and starts timer T303. Since the A2p bearer formats and addressing are known in this scenario, the BS includes the A2p bearer parameters in the Paging Response message. The MSCe stops timer T3113 upon receipt of the Paging Response message from the BS.
e. The BS acknowledges the receipt of the Page Response Message from the MS with a Base Station Acknowledgment Order to the MS.
f. The MSCe sends an Assignment Request message to the BS to request assignment of radio resources and starts timer T10. This message may contain the A2p bearer format and transport address to be used. Upon receipt of the Assignment Request message from the MSCe, the BS stops timer T303. If the MSCe does not include this information in the Assignment Request message then the MSCe shall send it in a Bearer Update Request message.
The MSCe may include authentication and integrity information in the Assignment Request message (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSCe and BS support AKA). If the Assignment Request message includes authentication vector information the BS shall initiate mutual authentication with the MS as defined in [5]. Upon receipt of an MS response, the BS shall return an Authentication Report message to the MSCe. Refer to section 3.20.1.6 for 3G authentication and message integrity procedures.
g. The BS sends a channel assignment message9 over the control channel of the radio interface (with the MS address) to initiate the establishment of a radio traffic channel, if the MS is not already on a traffic channel.
h. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
i. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
j. The MS acknowledges the reception of the BS order by transmitting the Mobile Station Acknowledgment Order.
k. The BS then sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
9 This may be Channel Assignment Message or Extended Channel Assignment Message.
Section 3 74
3GPP2 A.S0013-D v2.0
l. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
m. After the radio traffic channel has been established, the BS sends the Assignment Complete message to the MSCe. In this scenario, the A2p bearer parameters are not included in this message. If the BS has received the bearer format and transport address to be used the BS establishes the necessary transport facilities. If the BS has not received the bearer format and transport address to be used from the MSCe, the BS starts timer Txxp and, if Txxp expires, may release any resources that are not required for the call. The MSCe stops timer T10 upon receipt of the Assignment Complete message from the BS, and starts timer T301.
n. If the MSCe determines that a change in the bearer session is needed or if the MSCe did not send the bearer format and transport address to be used in the Assignment Request message, then the MSCe sends a Bearer Update Request message, containing the A2p bearer parameters, to the BS. The MSCe starts timer Tyyp. Upon receipt of this message, the BS stops timer Txxp if running.
o. The BS may change the traffic channel and/or the service option as needed. If a bearer path does not exist, the BS shall establish the necessary transport facilities.
p. If a Bearer Update Request message was received; the BS sends a Bearer Update Response message to the MSCe, conveying any changes in bearer or session address for the call. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
q. After the bearer path between the BS and the MGW has been established and the BS has the sent Assignment Complete message to the MSCe, the BS sends the Alert with Information Message to the MS to cause ringing at the MS.
r. The MS acknowledges the reception of the Alert with Information Message by transmitting the Mobile Station Acknowledgment Order.
s. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted to the BS.
t. The BS acknowledges the Connect Order with the Base Station Acknowledgment Order over the forward traffic channel.
u. The BS sends a Connect message to the MSCe to indicate that the call has been answered at the MS. The MSCe stops timer T301 upon receipt of the Connect message from the BS. At this point, the MSCe considers the call to be stable and in the Conversation State.
v. After the BS sends the Connect message, bi-directional audio is enabled on the A2p interface.
3.1.2.1.3 Mobile Termination via an MSCe Interfaces with Bearer Parameters sent in the Assignment Complete Message 38
39
40
41
42
This section describes the call flow associated with an MS call termination via an MSCe with A2p bearer parameters sent in the Assignment Complete Message, since the information is not available at the time that the Paging Response message is sent. The call flow supports TrFO and RTO.
75 Section 3
3GPP2 A.S0013-D v2.0
Base Station Ack Order
MS BS MSCe time comment
Page Response c
d
e
f
g
h
i
j
Paging Response
Assignment Request
Channel Assignment
Tch Preamble
k
m
BS Ack Order
MS Ack Order
Service Connect
Assignment Complete
T10
Connect
s
u
Page Message b
a Paging Request
q
r
Alert with Info
MS Ack Order
Connect Order
t BS Ack Order
T301
T3113
T303
Service Connect Completion l
MGW
Bearer Update Request
Bearer Update Response
n
o
v
p
Bi-directional Audio Enabled
Service Change Tyyp
Txxp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Figure 3.1.2.1.3-1 Mobile Termination Interfaces with Bearer Parameters sent in the Assignment Complete Message
a. The MSCe determines that an incoming call terminates to an MS within its serving region and sends the Paging Request message to the BS to initiate a mobile terminated call setup scenario. The Paging Request message may include one or more A2p bearer formats within the A2p Bearer Format-Specific Parameters IE. The MSCe then starts timer T3113.
If a list of one or more A2p bearer formats is included in the received Paging Request message, the BS attempts to page the MS using the service option associated with the first bearer format in the list that is supported by the BS. The first bearer format contained in the A2p Bearer-Format Specific IE and the Service Option IE should be consistent. If they are not consistent, then the Service Option IE shall take precedence.
b. The BS issues a Page Message containing the MS address over the Paging Channel.
Section 3 76
3GPP2 A.S0013-D v2.0
c. The MS acknowledges the page by transmitting a Page Response Message over the Access Channel. The MS indicates a preferred Service Option for the call.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
d. The BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, sends the message to the MSCe, and starts timer T303. The MSCe stops timer T3113 upon receipt of the Paging Response message from the BS.
e. The BS acknowledges the receipt of the Page Response Message from the MS with a Base Station Acknowledgment Order to the MS.
f. The MSCe sends an Assignment Request message to the BS to request assignment of radio resources and starts timer T10. Upon receipt of the Assignment Request message from the MSCe, the BS stops timer T303.
The MSCe may include authentication and integrity information in the Assignment Request message (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSCe and BS support AKA). If the Assignment Request message includes authentication vector information the BS shall initiate mutual authentication with the MS as defined in [5]. Upon receipt of an MS response, the BS shall return an Authentication Report message to the MSCe. Refer to section 3.20.1.6 for 3G authentication and message integrity procedures.
g. The BS sends a channel assignment message10 over the control channel of the radio interface (with the MS address) to initiate the establishment of a radio traffic channel, if the MS is not already on a traffic channel.
h. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
i. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
j. The MS acknowledges the reception of the BS order by transmitting the Mobile Station Acknowledgment Order.
k. The BS then sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
l. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
m. After the radio channel has been established, the BS sends the Assignment Complete message to the MSCe. In this scenario, the A2p bearer parameters are included in this message. Upon receipt of the Bearer Update message, the BS starts timer Txxp. and, if Txxp expires, may release resources that have been reserved for a Bearer Update Request.
The MSCe stops timer T10 upon receipt of the Assignment Complete message from the BS, and starts timer T301.
n. The MSCe sends a Bearer Update Request message, containing the A2p bearer parameters, to the BS. The MSCe starts timer Tyyp. Upon receipt of this message, the BS stops timer Txxp.
10 This may be Channel Assignment Message or Extended Channel Assignment Message.
77 Section 3
3GPP2 A.S0013-D v2.0
o. Upon receipt of a Bearer Update Request message, the BS may need to change the traffic channel and/or the Service Option by repeating all or parts of steps ‘g’ through ‘l’ as needed.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
p. The BS sends a Bearer Update Response message to the MSCe, conveying any changes in bearer or session address configuration for the call. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
q. The BS sends the Alert with Information Message to the MS to cause ringing at the MS.
r. The MS acknowledges the reception of the Alert with Information Message by transmitting the Mobile Station Acknowledgment Order.
s. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted to the BS.
t. The BS acknowledges the Connect Order with the Base Station Acknowledgment Order over the forward traffic channel.
u. The BS sends a Connect message to the MSCe to indicate that the call has been answered at the MS. The MSCe stops timer T301 upon receipt of the Connect message from the BS. At this point, the MSCe considers the call to be stable and in the Conversation State.
v. After the BS sends the Connect message, bi-directional audio is enabled on the A2p interface.
3.1.2.2 Mobile Termination, Assignment Retry 21
22
23
24
25
26
27
This section describes the call flow when channel assignment is retried between the BS and circuit-switched MSC interface for a mobile terminated call. Assignment Retry procedures can also be supported by an MSCe. The call flow for this scenario would be similar to that of 3.1.2.1.1-1 with Bearer Update Request/Response messages exchanged between the MSCe and the BS to specify the bearer format and address to be used with the MGW.
Section 3 78
3GPP2 A.S0013-D v2.0
MS BS MSC time
Page Response Message
Base Station Ack Order
c
d
e
Complete L3 Info: Paging Response
Page Message b
a Paging 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
s BS Ack Order
T301
f Assignment Request
g Assignment Failure
T10
T20
Service Connect Completion n
T303
1
2
3
4
5
6
7
8
9
10
11
12
13
Figure 3.1.2.2-1 Mobile Termination: Assignment Retry
a The MSC determines that an incoming call terminates to an MS within its serving region and sends the Paging Request message to the BS to initiate a mobile terminated call setup scenario. The MSC starts timer T3113.
b. The BS issues a Page Message containing the MS address over the Paging Channel.
c. The MS acknowledges the page by transmitting a Page Response Message over the Access Channel.
d. The BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303. The BS may request the MSC to allocate a preferred terrestrial circuit.
The MSC stops timer T3113 upon receipt of the Paging Response message from the BS.
79 Section 3
3GPP2 A.S0013-D v2.0
e. The BS acknowledges the receipt of the Page Response Message with a Base Station Acknowledgment Order over the air interface.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
f. The MSC sends an Assignment Request message to the BS to request assignment of radio resources. This message also assigns the terrestrial circuit, if one is to be used, between the MSC and the BS. The MSC then starts timer T10.
If the BS requested a preferred terrestrial circuit in the Paging Response message and the MSC can support that terrestrial circuit, the MSC shall assign the same terrestrial circuit in the Assignment Request message. Otherwise, the MSC may assign a different terrestrial circuit.
The BS stops timer T303 upon receipt of the Assignment Request message.
The MSC may include authentication and integrity information in the Assignment Request message (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSC and BS support AKA). If the Assignment Request message includes authentication vector information the BS shall initiate mutual authentication with the MS as defined in [5]. Upon receipt of an MS response, the BS shall return an Authentication Report message to the MSC. Refer to section 3.20.1.6 for 3G authentication and message integrity procedures.
g. In this example, the BS recognizes that the assignment cannot be completed, (e.g., the requested terrestrial circuit is not available) and sends the Assignment Failure message to the MSC. The BS then starts timer T20.
The MSC stops timer T10 upon receipt of the Assignment Failure message from the BS.
h. The MSC retries by sending an Assignment Request message to the BS to request assignment of radio resources. This message also assigns a different terrestrial circuit to be used between the MSC and the BS, if one is needed for the call. The MSC restarts timer T10.
Upon receipt of the retry of the Assignment Request message, the BS stops timer T20. In this example, it is assumed that this second Assignment Request message is acceptable to the BS. The BS connects the traffic channel to the designated terrestrial circuit.
i. The BS sends a channel assignment message11 over the Paging Channel of the radio interface (with the MS address) to initiate the establishment of a radio traffic channel, if the MS is not already on a traffic channel.
j. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
k. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
l. The MS acknowledges the reception of the Base Station Acknowledgment Order by transmitting the Mobile Station Acknowledgment Order.
m. The BS then sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
11 This may be Channel Assignment Message or Extended Channel Assignment Message.
Section 3 80
3GPP2 A.S0013-D v2.0
n. On receipt of the Service Connect Message the MS responds with a Service Connect Completion Message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
o. After the radio traffic channel and circuit have both been established, the BS sends the Assignment Complete message to the MSC.
Upon receipt of the Assignment Complete message, the MSC stops timer T10, and starts timer T301.
p. The BS sends the Alert with Information Message to the MS to cause ringing at the MS.
q. The MS acknowledges the reception of the Alert with Information Message by transmitting the Mobile Station Acknowledgment Order.
r. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted to the BS.
s. The BS acknowledges the Connect Order with the Base Station Acknowledgment Order over the forward traffic channel.
t. The BS sends a Connect message to the MSC to indicate that the call has been answered at the MS. Upon receipt of the Connect message from the BS, the MSC stops timer T301. At this point, the call is considered stable and in the Conversation State.
3.1.3 Mid-Call Bearer Modification Examples 19
20
21
22
23
Mid-call bearer modification involves exchange of the following A1p messages:
Bearer Update Required
Bearer Update Request
Bearer Update Response
3.1.3.1 MSCe Initiated Bearer Modification 24
25
MS BS MSCetime comment
a
b
Tyyp
Bearer Update Request
c
Service negotiation procedures
Bearer Update Response
26
27
28
29
30
Figure 3.1.3.1-1 MSCe Initiated Bearer Modification
a. The MSCe determines that it needs to change the A2p bearer, sends a Bearer Update Request message to the BS containing the desired A2p bearer parameters and starts timer Tyyp.
81 Section 3
3GPP2 A.S0013-D v2.0
b When the BS receives a Bearer Update Request message, it may need to change the traffic channel and/or the Service Option by performing service negotiation procedures.
1
2
3
4
5
6
7
c The BS sends a Bearer Update Response message to the MSCe, conveying any changes in the address configuration for the call as a result of the Bearer Update Request. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
3.1.3.2 BS Initiated Bearer Modification 8
9
10
11
This section describes the call flow associated with a BS initiated bearer update request. It is assumed that an A2p bearer already exists between the BS and the MGW and that the BS determines that it needs to change the existing bearer.
MS BS MSCe time comment
a
b
c Tyyp
Bearer Update Request
d
Service negotiation procedures
Bearer Update Required
Tzzp optional
optional
conditional
conditional Bearer Update Response
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure3.1.3.2-1 BS Initiated Bearer Modification
a. The BS, upon determining that an A2p bearer change is needed, sends a Bearer Update Required message to the MSCe containing the desired A2p bearer parameters and starts timer Tzzp.
b. The MSCe responds to the Bearer Update Required message with a Bearer Update Request message based on the A2p bearer parameters requested in the Bearer Update Required message, and starts timer Tyyp. The BS stops timer Tzzp.
c. When the BS receives a Bearer Update Request message, it may need to change the traffic channel and/or the Service Option by performing service negotiation procedures.
d. The BS sends a Bearer Update Response message to the MSCe, conveying any changes in the address configuration for the call as a result of the Bearer Update Request. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
3.2 Call Clearing of Voice and Circuit Data Calls 27
28
29
30
31
There are two types of clearing call flows over the A1 or A1p interface:
1. Call clearing for a single service that is not the only one connected.
2. Call clearing of all services connected (including the case where only one service is connected).
Section 3 82
3GPP2 A.S0013-D v2.0
For call flows showing call clearing involving concurrent services (call clearing for a single service that is not the only one connected), refer to section 3.18. The call clearing call flows shown in this section apply when all services are cleared.
1
2
3
4
5
6
Call clearing may be initiated by either the BS, the MS, the PDSN/PCF, the MSCe, or the MSC.
Call clearing of packet data call flows is specified in section 3.17.
3.2.1 Call Clearing Initiated by the MS or BS 7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
When the MS initiates a normal clearing of all services including the only service connected, the MS sends a Release Order to the BS. The BS shall send a Clear Request message to the MSC and start timer T300 to wait for the Clear Command message from the MSC. For packet data calls, call clearing does not normally clear the service session. The service session is cleared using call flows in this section for conditions such as MS power down, termination of the PPP session by the MS or the network, etc.
The MSC is responsible for clearing A1, A1p, A2, A2p, and/or A5 connections associated with the call. To release all allocated resources associated with all services, the MSC shall send a Clear Command message to the BS. The BS responds with a Clear Complete message and stops timer T300.
If the MS is not active (powered off) or if for any reason the radio channel failed between the MS and the BS or if some internal BS failure occurs, then the BS initiates call clearing. The BS sends a Clear Request message to the MSC. The MSC responds with a Clear Command message to the BS and waits for a Clear Complete message from the BS. The scenario is illustrated in section 3.2.4.2.
Refer to [14] for unsuccessful call clearing procedures related to the Service Release, Clear Request and Clear Command messages.
3.2.2 Call Clearing Initiated by the MSC 25
26
27
28
When the MSC chooses to deny call setup initiated by the reception of a CM Service Request or Paging Response message contained in an SCCP/SUA Connection Request, the MSC may send an SCCP/SUA Connection Refused containing no user data.
3.2.2.1 Clear from the Network 29
30
31
32
33
34
35
36
37
38
When the MSC initiates a normal clearing of a single service that is not the only service connected, the MSC sends a Service Release message to the BS and starts timer T308 to wait for a Service Release Complete message from the BS. This normal call clearing scenario is illustrated in section 3.18.4.2.
In case the MSC initiates a normal clearing of all services including the only one connected, the MSC shall send a Clear Command message to the BS, start timer T315, and wait for a Clear Complete message from the BS. Timer T315 is stopped when the Clear Complete message is received. This normal call clearing scenario is illustrated in section 3.2.4.3.
83 Section 3
3GPP2 A.S0013-D v2.0
3.2.2.2 Call Clearing when Tones/Announcements are Provided 1
2
3
Call clearing messages are not affected if the network provides either tones or announcements immediately before clearing a call.
3.2.2.3 Mobile Origination Failure – Call Clearing with Local Tone Generation 4
5
6
7
8
This section describes the call flow associated with a Progress message. The Progress message is used to trigger tone generation at the MS (e.g., via a Reorder Order or Intercept Order message to the MS) prior to clearing a call request. Local tone generation allows the network to convey information to a user by means of tones.
Progress
Base Station Ack Order
BS MSC time comment
a
b
c
d
e
f
g
h
T303
T315
Clear Command
Tone generation
MS
Release
Complete L3 Info: CM Service Request
Clear Complete
Origination Message
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Figure 3.2.2.3-1 Call Clearing with Local Tone Generation
a. The MS transmits an Origination Message, with Layer 2 Ack required, over the Access Channel of the air interface to the BS to request service.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
c. The BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303.
d. The MSC decides to reject the call prior to sending an Assignment Request. The MSC sends a Progress message to the BS to trigger local tone generation at the MS conveying information regarding the reason for rejection (e.g., reorder) to the user.
e. Upon receipt of the Progress message, the BS instructs the MS to generate the appropriate tone (e.g., by sending a Reorder Order message).
f. The MSC sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resource and starts timer T315.
The MSC should delay sending the Clear Command message after the Progress message to allow the local tone generation at the MS.
Section 3 84
3GPP2 A.S0013-D v2.0
g. After receiving the Clear Command message, the BS initiates call clearing over the air interface and stops timer T303. Note that the BS may need to be aware of the time needed by the MS to generate the local tone.
1
2
3
4
5
6
h. Upon acknowledgement of the call clearing over the air interface, the BS returns a Clear Complete message. The MSC stops timer T315 upon receipt of the Clear Complete message and releases the underlying transport connection.
3.2.3 Call Clearing Collision 7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Call clearing collision occurs in the following cases:
1. The BS sends a Clear Request message and the MSC simultaneously sends a Clear Command message.
When the MSC receives the Clear Request message, it shall note it and continue to wait for the Clear Complete message. When the BS receives the Clear Command message, it shall complete the call clearing.
2. The BS and MSC simultaneously send Service Release messages and each Service Release message contains the same Service Option Connection Identifier (SOCI).
When the MSC receives the Service Release message, it shall note it and continue to wait for a Service Release Complete message. When the BS receives the Service Release message, stop timer T308 and send a Service Release Complete message to the MSC.
3. The BS and MSC simultaneously send Service Release messages and each Service Release message contains different SOCI.
When the MSC receives the Service Release message and the MSC realizes that all services are being released, the MSC sends the Clear Command message to the BS and starts timer T315. When the BS receives the Clear Command message it stops timer T308 and shall proceed with the normal call clearing call flows as in 3.2.4.3.1.
4. The BS sends a Service Release message and the MSC simultaneously sends a Clear Command message.
When the BS receives the Clear Command message, it shall complete the clearing of all services including the only one connected and send a Clear Complete message to the MSC. The BS then stops timer T308. When the MSC receives the Service Release message, it shall note it and continue to wait for a Clear Complete message.
5. The BS sends a Clear Request message and the MSC simultaneously sends a Service Release message
When the MSC receives the Clear Request message, it shall send a Clear Command message and stop timer T308. The MSC starts timer T315 to wait for a Clear Complete message. When the BS receives the Service Release message, it shall note it and continue to wait for a Clear Command message.
3.2.4 Call Flows for Call Clear Operation 37
38 The following subsections provide the call flows for call clearing operations.
85 Section 3
3GPP2 A.S0013-D v2.0
3.2.4.1 Call Clear via Clear Request (MS Initiated) 1
2
3
4
In this example, when the MS initiates call clearing by sending a Release Order to the BS, the BS sends a Clear Request message to the MSC and waits to receive a Clear Command message.
MS MSC time comment
release a
b
c
d
Clear Request
Clear Command
Clear Complete
release
T300
T315
e
BS
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.2.4.1-1 Call Clear Initiated by MS
a. The MS initiates call clearing by transmitting a release12 over the reverse traffic channel.
b. The BS then sends the Clear Request message to the MSC to initiate the call clear transaction. Timer T300 is started by the BS.
c. The MSC sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resource (such as terrestrial circuit) and starts timer T315. The BS stops timer T300.
d. In response to the Clear Command message, the BS releases the terrestrial circuit, if allocated. The BS then acknowledges the MS by sending it a release over the forward traffic channel and releases the radio resource.
e. The BS returns a Clear Complete message to the MSC. The MSC stops timer T315 upon receipt of the Clear Complete message. The MSC releases the underlying transport connection.
3.2.4.2 Call Clear via Clear Request (BS Initiated) 20
21
22
23
In this example, if the BS decides to clear the call because of radio channel failure or other reasons, the BS initiates call clearing by sending a Clear Request message to the MSC.
12 This may be a Release Order, Extended Release Message or Extended Release (Mini) Message as appropriate.
Section 3 86
3GPP2 A.S0013-D v2.0
MS BS MSC time comment
a
b
c
Clear Request
Clear Command
Clear Complete
T300
T315
1
2
3
4
5
6
7
8
9
10
Figure 3.2.4.2-1 Call Clear Initiated by BS (via Clear Request)
a. If the BS decides to clear the call because of radio channel failure or other reasons, the BS sends a Clear Request message to the MSC. The BS starts timer T300 and waits for the Clear Command from the MSC.
b. The MSC sends a Clear Command message to instruct the BS to release the associated dedicated resource (such as terrestrial circuit) and starts timer T315. The BS stops timer T300.
c. The BS returns a Clear Complete message. The MSC stops timer T315 upon receipt of the Clear Complete message and releases the underlying transport connection.
3.2.4.3 Call Clear via Clear Command 11
12
13
In this example, the MSC initiates call clearing by using the Clear procedure (Clear Command and Clear Complete messages).
MS MSC
time comment
b
c
Clear Command
Clear Complete
release
release
a
d
T315
BS
14
15
16
17
18
19
20
21
22
23
Figure 3.2.4.3-1 Call Clear Initiated by MSC (via Clear Command)
a. The MSC sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resource and starts timer T315.
b. The BS initiates call clearing over the air interface by transmitting a release over the forward traffic channel.
c. The MS acknowledges the Release Order by returning a release over the reverse traffic channel.
d. The BS returns a Clear Complete message. The MSC stops timer T315 upon receipt of the Clear Complete message and releases the underlying transport connection.
87 Section 3
3GPP2 A.S0013-D v2.0
3.3 TFO Support 1
2
3
4
This section describes call flows associated with Tandem Free Operation. Refer to section 2.3 for more description of this feature. This feature only applies to circuit-switched MSCs.
3.3.1 Call Flows for Transcoder Control 5
6 Figure 3.3.1-1 shows the Transcoder Control call flow.
time
a
b
BS MSC
Transcoder Control Acknowledge
Transcoder Control Request
T309
comment
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.3.1-1 Transcoder Control Call Flow
a. The circuit-switched MSC sends a Transcoder Control Request message to enable or disable the inband signaling mechanism at the BS. If the inband signaling mechanism is already enabled and the call is not in the TFO Operation state, an enable directive simply resets the inband signaling state machine logic. Timer T309 is started by the circuit-switched MSC.
b. Upon receipt of the Transcoder Control Request message, the BS sets the inband signaling mechanism to the appropriate state and returns a Transcoder Control Acknowledge message without a ‘cause’ value if TFO operation was successfully enabled/disabled. A Transcoder Control Acknowledge message with a ‘cause’ value indicating failure is sent if the BS is unable to process the Transcoder Control Request directive. The circuit-switched MSC stops timer T309.
3.4 Test Calls 20
21
22
23
Test calls initiated by the MS use the call flows described in section 3.1.1. Test calls initiated by the MSC use the call flows described in section 3.1.2. Handoff of test calls is not supported in this standard.
3.5 Support of DTMF 24
25 This feature is supported using existing call flows.
3.6 Support of Supplementary Services 26
27
28
The following subsections contain call flows demonstrating the procedures for supporting Supplementary Services. Refer to section 2.6 for overview descriptions of these features.
Section 3 88
3GPP2 A.S0013-D v2.0
The features defined in [I-1] generally involve transactions between the MSC and the MS. The required information is passed through the BS using the following messages:
1
2
3
4
5
6
7
8
9
10
11
12
13
Flash with Information
Flash with Information Ack
Feature Notification
Feature Notification Ack
CM Service Request
Assignment Request
Assignment Complete
Clear Command
Clear Complete
Bearer Update Request
Bearer Update Response.
3.6.1 Feature Activation and Deactivation 14
15
16
The sections below indicate the call flows used to handle feature activation and deactivation both when the MS is idle and is in a call.
3.6.1.1 Feature Activation/Deactivation in Idle Mode 17
18
19
Refer to section 3.1.1 for call flows associated with this feature.
3.6.1.2 Feature Activation/Deactivation While in a Call 20
21
MS BS MSC time comment
a Flash with Information
c
b
In-Band information
Flash with Information
22
23
24
25
26
27
Figure 3.6.1.2-1 Feature Activation/Deactivation While in a Call
a. The MS sends a Flash with Information message to the BS to pass a string of digits and end marks to request feature activation/deactivation.
b. The BS places the string of digits and end marks in a Flash with Information message and sends it to the MSC.
89 Section 3
3GPP2 A.S0013-D v2.0
c. The MSC generates in-band tones or announcements. 1
3.6.2 Call Waiting 2
3 This section provides the call flow description for the call waiting feature.
MS
BS
MSC
time
comment
b
c
e
f
Flash with Information
a
Flash with Information
d
Flash with Information
Flash with Information
Flash with Information
Flash with Information
g
h
Bearer Update Request
Bearer Update Response
Conditional
Conditional
Bearer Update Request
Bearer Update Response
i
j
Conditional
Conditional
Tyyp
Tyyp
Service Change
k Conditional
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Figure 3.6.2-1 Call Waiting
a. The MSC sends a Flash with Information message to the BS to alert the MS that there is a call waiting.
b. The BS takes the information from the MSC and sends a Flash with Information message to the MS.
c. The MS sends the Flash with Information message to the BS to indicate the acceptance of the second call.
d. The BS sends a Flash with Information message to the MSC. The MSC then places the original call on hold.
e. If required, a Bearer Update Request message is sent from the MSCe to the BS to modify the A2p bearer interface. The MSCe starts timer Tyyp. This message is not sent from circuit switched MSCs.
f. If the BS received a Bearer Update Request message it responds with a Bearer Update Response message. Upon receipt of this message, the MSCe stops timer Tyyp.
g. The MSC connects the second call to the MS. To toggle between the two callers, the MS sends the Flash with Information message to the BS.
h. The BS sends a Flash with Information message to the MSC. The MSC then places the second call on hold and reconnects the original call to the MS.
Section 3 90
3GPP2 A.S0013-D v2.0
i. If required, a Bearer Update Request message is sent from the MSCe to the BS to modify the A2p bearer interface. The MSCe starts timer Tyyp. This message is not sent from circuit switched MSCs.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
j. If the BS received a Bearer Update Request message, the BS may choose to change the TCH and service option with the MS.
k. If the BS received a Bearer Update Request message it responds with a Bearer Update Response message. Upon receipt of this message, the MSCe stops timer Tyyp.
The MSC may optionally apply an inband tone to alert the user of a waiting call. Such an action takes the place of or supplements steps ‘a’ and ‘b’ above.
If an MS releases an active call after receiving a call waiting notification, and while a call is waiting, the active call is cleared using normal call release call flows as described in section 3.2.4.2, and the waiting call is offered using normal mobile termination call flows, as described in section 3.1.2.
If an MS releases the active call while another call is held (by the Call Waiting feature), the active call is cleared using normal call release call flows as described in section 3.2.4.2, and the held call is offered using normal mobile termination call flows, as described in section 3.1.2.
3.6.3 Three Way Calling 19
3.6.3.1 Three-Way Calling – (Method 1) 20
21
22
This section provides the call flow description for the Three-Way Calling feature (Method 1).
MS BS MSC time
a
b Flash with Information
Flash with Information
c
d Flash with Information
Flash with Information (2nd party called address)
e
f
Flash with Information
Flash with Information
g
h
Flash with Information
Flash with Information
Bearer Update Request
i
j
comment
conditional
conditional Bearer Update Response Tyyp
23
24 Figure 3.6.3.1-1 Three-Way Calling (Method 1)
91 Section 3
3GPP2 A.S0013-D v2.0
a. To initiate Three-Way Calling while a call is in progress, the MS sends a Flash with Information Message to the BS to request the original call be placed on hold.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
b. The BS sends the Flash with Information message to the MSC. The MSC places the original call on hold.
c. The MS sends a Flash with Information Message to the BS containing the dialed digits of the second party.
d. The BS sends a Flash with Information message to the MSC with the dialed digits of the second party.
e. If required, a Bearer Update Request message is sent from the MSCe to the BS to modify the A2p bearer interface. The MSCe starts timer Tyyp. This message is not sent from circuit switched MSCs.
f. If the BS received a Bearer Update Request message it responds with a Bearer Update Response message. Upon receipt of this message, the MSCe stops timer Tyyp.
g. Once the second party answers, it is connected to the MS. The MS sends a Flash with Information Message to the BS to request connection of all three parties.
h. The BS sends a Flash with Information message to the MSC. The MSC places all three parties in a conference call.
i. To disconnect the second party, the MS sends a Flash with Information Message to the BS.
j. The BS sends a Flash with Information message to the MSC, which disconnects the second call.
3.6.3.2 Three-Way Calling - (Method 2) 23
24
25
26
This section provides the call flow description for the Three-Way Calling feature (Method 2). In Method 2, the called address information of the second call is sent during the first hook flash indication from the MS.
MS BS MSC time
a
b Flash with Information
Flash with Information (2nd party called address)
c
d
Flash with Information
Flash with Information e
f
Flash with Information
Flash with Information
Bearer Update Request
Bearer Update Response
g
h
commen
conditional
conditionalTyyp
27
28 Figure 3.6.3.2-1 Three-Way Calling (Method 2)
Section 3 92
3GPP2 A.S0013-D v2.0
a. To initiate Three-Way Calling while a call is in progress, the MS sends a Flash with Information Message containing the dialed digits of the second call to the BS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
b. The BS sends a Flash with Information message to the MSC along with the dialed digits of the second party. The MSC places the original call on hold and starts call setup procedures for the second party.
c. If required, a Bearer Update Request message is sent from the MSCe to the BS to modify the A2p bearer interface. The MSCe starts timer Tyyp. This message is not sent from circuit switched MSCs.
d. If the BS received a Bearer Update Request message it responds with a Bearer Update Response message. Upon receipt of this message, the MSCe stops timer Tyyp.
e. Once the second party answers, it is connected to the MS. The MS sends a Flash with Information Message to the BS to request connection of all three parties.
f. The BS sends a Flash with Information message to the MSC. The MSC places all three parties in a conference call.
g. To disconnect the second party, the MS sends a Flash with Information Message to the BS.
h. The BS sends a Flash with Information message to the MSC, which disconnects the second call.
3.6.4 Message Waiting Notification 20
3.6.4.1 Message Waiting Notification on the Paging Channel 21
22
23
The following example demonstrates the delivery of a Message Waiting Indication via the Feature Notification message over the control channel.
MS BS MSC time
b
c
d Feature Notification Ack
Layer 2 Ack
a Feature Notification
Feature Notification
T63
24
25
26
27
28
29
30
31
Figure 3.6.4.1-1 Message Waiting Notification on the Paging Channel
a. The MSC sends a Feature Notification message containing message waiting information and starts timer T63.
b. The BS sends a Feature Notification Message to the MS.
c. The MS acknowledges the receipt of the message by a Layer 2 Ack.
d. BS sends the Feature Notification Ack message to the MSC. The MSC stops timer T63.
93 Section 3
3GPP2 A.S0013-D v2.0
3.6.4.2 Message Waiting Notification on the Traffic Channel 1
2
3
The following example shows the delivery of a Message Waiting Indication to the MS while on a traffic channel via the Flash with Information message.
MS BS MSC time
b
c
d Flash with Information Ack
Layer 2 Ack
a Flash with Information
Flash with Information
T62
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.6.4.2-1 Message Waiting Notification on the Traffic Channel
a. When the MS is on traffic channel, the MSC may include message waiting information in the Flash with Information message to inform the MS that there are zero or more messages waiting. In this scenario, it is assumed that the MSC also includes the Tag element in the Flash with Information message to request that the BS notify the MSC when a Layer 2 Ack is received from the MS. The MSC starts timer T62.
b. The BS sends the information in the Flash with Information air interface message.
c. Once the MS has received the Flash with Information message, it responds with a Layer 2 Ack message.
d. The BS sends the Flash with Information Ack message to the MSC including the Tag element included by the MSC in the Flash with Information message. The MSC stops timer T62.
3.6.5 Call Barring 18
19 This section contains call flows associated with the Call Barring Feature.
3.6.5.1 Call Barring Incoming 20
21 Call Barring Incoming is transparent to the IOS.
3.6.5.2 Call Barring Outgoing 22
23
Section 3 94
3GPP2 A.S0013-D v2.0
Clear Command
Clear Complete
T315
b
c
d
a Mobile Originated Call
release
release
e
time BS MS MSC
1
2
3
4
5
6
7
8
9
Figure 3.6.5.2-1 Call Barring Outgoing
a. The MS originates a call; refer to section 3.1.1.
b. If the MSC determines that the call should be blocked, it applies treatment (announcement), sends a Clear Command to instruct the BS to release the associated dedicated resources and starts timer T315.
c. The BS sends a release to the MS.
d. The MS sends a release to the BS.
e. The BS returns the Clear complete message and the MSC stops timer T315.
3.6.6 Calling Number ID Presentation/Restriction 10
11
12
13
14
15
16
17
For mobile originated CNIR, refer to the call flows in section 3.1.1.
For mobile terminated CNIP/CNIR, if the MS is idle, the CNIP/CNIR information is sent in the Assignment Request message. The call flows for this feature are identical to the call flows for a mobile terminated call, refer to section 3.1.2.
If the MS user subscribes to the Call Waiting (CW) feature and is engaged in a call, the CNIP/CNIR information is sent in the Flash with Information message. The call flow for this feature is identical to the call flow for Call Waiting; refer to section 3.6.2.
3.6.7 Distinctive Ringing 18
19
20
The call flows for this feature are identical to the call flows for a mobile terminated call; refer to section 3.1.2.
3.6.8 Answer Holding 21
22
23
This section provides the call flows description for Answer Holding. The following types of Answer Holding may occur:
95 Section 3
3GPP2 A.S0013-D v2.0
Answer Holding of a Mobile Terminated Call 1
2 Answer Holding of Call Waiting.
3.6.8.1 Answer Holding of a Mobile Terminated Call 3
4 This call flow describes Answer Holding of a Mobile Terminated Call.
MS BS MSC
time
c
d
e
b
a
Alert with Info
Flash W ith Information
Flash W ith Information
T301
Terminating call setup
Flash W ith Information
Flash W ith Information f
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.6.8.1-1 Answer Holding of a Mobile Terminated Call
a. The MSC determines that an incoming call terminates to an MS within its serving region and uses the normal procedure for terminating call setup to establish the radio traffic channel and set up the bearer path to the MSC. Refer to section 3.1.2. Timer T301 is running.
b. The BS sends the Alert with Information Message to the MS to cause ringing at the MS.
c. The MS decides to invoke answer holding of the call and sends a Flash with Information Message to the BS with an indication that the call shall be put on hold.
d. The BS sends a Flash with Information message to the MSC with the indication that the call shall be put on hold. The MSC stops timer T301.
e. At some later time, the MS decides to answer the call that is holding. The MS sends a Flash With Information Message to the BS.
f. The BS sends a Flash With Information message to the MSC to connect the call.
3.6.8.2 Answer Holding of Call Waiting 20
21 This call flow describes the Answer Holding of Call Waiting.
Section 3 96
3GPP2 A.S0013-D v2.0
M S BS M SC tim e com m ent
b
c Flash with In form ation
a Flash with In form ation
d
Flash with In form ation
Flash with In form ation
Flash with In form ation
Flash with In form ation e
f
Bearer Update Response
Bearer Update Request g
h
Conditional
ConditionalTyyp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.6.8.2-1 Answer Holding of Call Waiting
a. The MSC sends a Flash with Information message to the BS to alert the MS that there is a call waiting.
b. The BS takes the information from the MSC and sends a Flash with Information Message to the MS.
c. The MS sends the Flash with Information Message to the BS to indicate that the new call shall be put on hold.
d. The BS sends a Flash with Information message to the MSC with the indication that the new call shall be put on hold.
e. At some later time, the MS decides to answer the call that is holding. The MS sends a Flash With Information Message to the BS.
f. The BS sends a Flash With Information message to the MSC to connect the call.
g. If required, a Bearer Update Request message is sent from the MSCe to the BS to modify the A2p bearer interface. The MSCe starts timer Tyyp. This message is not sent from circuit switched MSCs.
h. If the BS received a Bearer Update Request message it responds with a Bearer Update Response message. Upon receipt of this message, the MSCe stops timer Tyyp.
3.6.9 User Selective Call Forwarding 20
21
22
23
24
This section provides the call flows description for User Selective Call Forwarding. The following types of User Selective Call Forwarding may occur:
User Selective Call Forwarding of a Mobile Terminated Call
User Selective Call Forwarding of Call Waiting.
97 Section 3
3GPP2 A.S0013-D v2.0
3.6.9.1 User Selective Call Forwarding of a Mobile Terminated Call 1
2 This call flow describes the User Selective Call Forwarding of a Mobile Terminated Call.
MS BS MSC
time
c
d
e
b
a
Alert with Info
Flash With Information
Flash With Information
T301
Terminating call setup
Network initiated call clearing
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.6.9.1-1 User Selective Call Forwarding of Mobile Terminated Call
a. The MSC determines that an incoming call terminates to an MS within its serving region and uses the normal procedure for terminating call setup to establish the radio traffic channel and set up the bearer path to the MSC. Refer to section 3.1.2. Timer T301 is running.
b. The BS sends an Alert with Information Message to the MS to cause ringing at the MS.
c. The MS decides to invoke user selective call forwarding of the call and sends a Flash with Information Message to the BS with an indication that the call shall be forwarded.
d. The BS sends a Flash with Information message to the MSC with the indication that the call shall be forwarded. The MSC stops timer T301.
e. The MSC initiates a network initiated call clearing.
3.6.9.2 User Selective Call Forwarding of Call Waiting 18
19 This call flow describes the User Selective Call Forwarding of Call Waiting.
Section 3 98
3GPP2 A.S0013-D v2.0
M S BS M SC
time
b
c
Flash with Information
a Flash with Information
d
Flash with Information
Flash with Information
1
2
3
4
5
6
7
8
9
10
Figure 3.6.9.2-1 User Selective Call Forwarding of Call Waiting
a. The MSC sends a Flash with Information message to the BS to alert the MS that there is a call waiting.
b. The BS takes the information from the MSC and sends a Flash with Information Message to the MS.
c. The MS sends a Flash with Information Message to the BS to indicate that the call shall be forwarded.
d. The BS sends a Flash with Information message to the MSC with the indication that the call shall be forwarded.
3.7 Mobile Registration 11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
This section describes procedures related to Registration and Deregistration.
Successful location registration requests involve the exchange of the following messages:
Complete Layer 3 Information with Location Updating Request
Authentication Request / Authentication Response (optional)
Location Updating Accept
Registration Request (Network initiated registration)
Mobile Station Registered Notification.
The call flows for the location update request procedure are illustrated in Figure 3.7.1 and 3.7.3.
When authentication is supported by the BS/MSC, a challenge RAND is broadcast on the control channel. RAND is specified in [14] and utilized for the process of registration, call origination and call termination. The MS utilizes the broadcast RAND to compute the Authentication Response AUTHR specified in [14].
The Location Updating Request message is sent by the BS to notify the MSC of a registration attempt by the MS.
When the network performs an autonomous registration of an MS (refer to [28]), the MSC sends the Mobile Station Registered Notification message to the serving BS. This message directs the BS to send the Mobile Station Registered Message [5] on the traffic channel to the MS to notify the MS of this registration.
99 Section 3
3GPP2 A.S0013-D v2.0
The call flow for the use of Mobile Station Registration Notification message is illustrated in section 3.7.4.
1
2
3.7.1 Mobile Initiated Location Registration 3
4
5
The call flow in Figure 3.7.1-1 provides an illustration of a successful Location Registration procedure initiated by the MS.
MS BS MSC time comment
Registration Message a
b
c
d
Location Updating Request
Location Updating Accept T3210
Registration Acknowledgement optional
e conditional Authentication Report
f conditional Authentication Report Response Tar
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Figure 3.7.1-1 Location Registration - Successful Case
a. The MS initiates a registration operation by sending the Registration Message to the BS.
b. On reception of the Registration Message the BS constructs the Location Updating Request message, places it in the Complete Layer 3 Information message, and sends it to the MSC. The BS then starts timer T3210.
c. The MSC sends the Location Updating Accept message to the BS to indicate that the Location Updating Request message has been processed.
Upon receipt of the Location Updating Accept message, the BS stops timer T3210.
d. The BS transmits a Registration Accepted Order to the MS to acknowledge the registration explicitly, or optionally the BS acknowledges the registration implicitly by initiating mutual authentication with the MS as defined in [5] (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSC and BS support AKA (as indicated by the MSC including the authentication information in the Location Updating Accept message in step ‘c’)).
e. If mutual authentication was performed in step ‘d’, the BS forwards the results to the MSC in an Authentication Report message and starts timer Tar.
f. The MSC responds with an Authentication Report Response message. The BS stops timer Tar.
3.7.2 Power Down Registration at the End of a Call 26
27
28
The MS may send a power down indication in a Release Order when clearing a call. The BS shall forward a power down indication to the MSC by including the Power Down
Section 3 100
3GPP2 A.S0013-D v2.0
Indicator element in the Clear Complete message. Refer to [14] “Clear Complete” for more information.
1
2
3.7.3 Network Initiated Location Registration 3
4
5
The call flow in Figure 3.7.3-1 provides an illustration of a successful Network Initiated Location Registration procedure.
MS BS MSC time comment
Registration Message c
d
e
f
Location Updating Request
Location Updating Accept T3210
Registration Request a
b Registration Request Order
Tordreg
Registration Acknowledgement
g Authentication Report
optional
conditional
Authentication Report Response h conditional Tar
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.7.3-1 Network Initiated Location Registration - Successful Case
a. The MSC initiates an ordered registration procedure by sending a Registration Request message to the BS. The MSC starts timer Tordreg.
b. The BS sends a Registration Request Order to the MS on the common signaling channel.
c. The MS responds by sending the Registration Message to the BS.
d. Upon reception of the Registration Message, the BS constructs the Location Updating Request message, places it in the Complete Layer 3 Information message, and sends it to the MSC. The BS then starts timer T3210.
Upon receipt of the Location Updating Request message from the BS, the MSC stops timer Tordreg.
e. The MSC sends the Location Updating Accept message to the BS to indicate that the Location Updating Request message has been processed. Upon receipt of the Location Updating Accept message, the BS stops timer T3210.
f. The BS transmits a Registration Accepted Order to the MS to acknowledge the registration explicitly, or optionally the BS acknowledges the registration implicitly by initiating mutual authentication with the MS as defined in [5] (e.g., if P_REV_IN_USE is greater or equal to 10 and the MSC and BS support AKA (as indicated by the MSC including the authentication information in the Location Updating Accept message in step ‘e’)).
101 Section 3
3GPP2 A.S0013-D v2.0
g. If mutual authentication was performed in step ‘f’, the BS forwards the results to the MSC in an Authentication Report message and starts timer Tar.
1
2
3
4
h. The MSC responds with an Authentication Report Response message. The BS stops timer Tar.
3.7.4 Mobile Station Registered Notification 5
6
7
The call flow in Figure 3.7.4-1 provides an illustration of the Mobile Station Registered Notification procedure.
b
time
Mobile Station Registered Notification
Mobile Station Registered Message
a
MSC performs autonomous registration
Layer 2 Ack c
BS MS MSC
8
9
10
11
12
13
14
Figure 3.7.4-1 Mobile Station Registered Notification
a. The MSC sends a Mobile Station Registered Notification message to the serving BS following an autonomous registration of an MS.
b. Upon receipt of the Mobile Station Registered Notification message, the BS sends the Mobile Station Registered Message to the MS.
c. The MS may acknowledge the receipt of the message by a Layer 2 Ack.
3.8 Global Emergency Call Origination 15
16 Normal mobile originated call setup call flows apply to this feature; refer to section 3.1.1.
3.9 E911 Phase I and Phase 2 17
18
19
Normal mobile originated call setup call flows apply to this feature; refer to section 3.1.1. This feature also uses Mobile Position Determination; refer to section 3.13.
3.10 Short Message Service 20
21
22
This section contains descriptions and call flows for the Short Message Service feature. Refer to section 2.10 for more details on this feature.
Section 3 102
3GPP2 A.S0013-D v2.0
3.10.1 SMS Feature Description 1
2
3
4
5
The subsections below contain descriptions of the following SMS cases:
SMS Mobile Originated Point-to-Point
SMS Mobile Terminated Point-to-Point
SMS Broadcast
3.10.1.1 SMS - Mobile Originated Point-to-Point 6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
A mobile originated SMS (SMS-MO) message may be sent from the MS to the BS on either a control (access) or traffic channel.
An MS already on a traffic channel uses that traffic channel to send an SMS-MO message. An idle MS may use either an Access Channel, or may request a traffic channel for delivery of an SMS-MO message. If an idle MS wants to use a traffic channel to send an SMS-MO message, it sends an Origination Message with the short message service option number in the service option field. The call origination call flows described in section 3.1.1 are then used. Once the traffic channel is established the transport of the SMS-MO message on the MSC-BS interface is accomplished by sending an Application Data Delivery Service (ADDS) Deliver message from the BS to the MSC. If the Access Channel is used for SMS-MO message transmission from the MS to the BS, then no call establishment is performed. When the SMS-MO message is transmitted from the MS to the BS on an Access Channel, the transport of the SMS-MO message is accomplished by sending an Application Data Delivery Service (ADDS) Transfer message from the BS to the MSC.
3.10.1.2 SMS - Mobile Terminated Point-to-Point 22
23
24
25
26
27
28
29
30
31
An SMS Mobile Terminated (SMS-MT) message can be transmitted from the BS to the MS on either a common or traffic channel. An SMS-MT message intended for an MS already on a traffic channel is sent on that traffic channel.
When the SMS-MT message is sent to the MS on a traffic channel, the transport of the SMS-MT message is accomplished by sending the ADDS Deliver message from the MSC to the BS.
When the SMS-MT message is sent to the MS on a common channel, the transport of the SMS-MT message is accomplished by sending the ADDS Page message from the MSC to the BS.
3.10.1.3 SMS - Broadcast 32
33
34
35
36
37
SMS Broadcast is a mobile terminated short message that is sent to all MSs operating within the BS serving region. The broadcast address determines which MSs receive the message.
When the MSC sends an SMS Broadcast message to idle MSs, the message is sent from the MSC to the BS using an ADDS Page message.
103 Section 3
3GPP2 A.S0013-D v2.0
3.10.2 SMS Delivery on a Common Channel 1
2
3
4
5
6
7
8
9
The delivery of SMS-MT, SMS-MO, and SMS-Broadcast messages on a common (e.g. Paging or Common Control) channel is accomplished by the exchange of ADDS Page, ADDS Page Ack, and ADDS Transfer messages.
The ADDS Page is sent from the MSC to the BS and is used for SMS-MT and SMS-Broadcast messages. It may be acknowledged with the ADDS Page Ack message.
The ADDS Transfer message is sent from the BS to the MSC when the BS receives a Data Burst message on the Access Channel.
This section contains examples of SMS delivery on the control channel.
3.10.2.1 SMS Broadcast Delivery over a Common Channel 10
11
12
This section provides the call flow description for SMS Broadcast delivery over a common channel.
MS BS MSC time comment
b
c
ADDS Page Ack
a ADDS Page
Data Burst Message
T3113
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.10.2.1-1 SMS-Broadcast Delivery to MSs over a Common Channel
a. The MSC receives SMS Broadcast information for delivery to idle MSs.
The MSC sends an ADDS Page message to the BS. The ADDS Page contains the SMS Broadcast message in its ADDS User Part information element.
If the MSC requires an acknowledgment to the ADDS Page message, the Tag element shall be included in the ADDS Page message and starts timer T3113.
b. If the MSC requested an acknowledgment from the BS by including the Tag element in the ADDS Page message, the BS replies with an ADDS Page Ack message including the Tag element set to the same value as received from the MSC. The MSC stops timer T3113, if it was started.
c. The BS sends the SMS Broadcast information to the appropriate MSs over the Paging Channel or Forward Common Control Channel. The BS does not request that the MSs receiving the SMS broadcast message send Layer 2 Acks.
3.10.2.2 SMS Receipt from an MS on the Access Channel 27
28
29
This section provides the call flow description for the receipt of an SMS-MO message on the Access Channel.
Section 3 104
3GPP2 A.S0013-D v2.0
time
a
b
c
MS BS MSC
ADDS Transfer
Data Burst Message
Layer 2 Ack
1
2
3
4
5
6
7
Figure 3.10.2.2-1 SMS-MO Delivery on the Access Channel
a. The MS sends a point-to-point SMS message to the network on the Access Channel.
b. If the MS had requested a Layer 2 Ack, the BS acknowledges the short message received on the Access Channel by sending a Layer 2 Ack on the Paging Channel.
c. The BS sends an ADDS Transfer message to the MSC containing the SMS message received from the MS in the ADDS User Part element.
3.10.2.3 SMS Delivery to an MS on a Common Channel - Example 1 8
9
10
This section provides the call flow description for the delivery of an SMS-MT message on a common channel using the ADDS Page message.
MS BS MSC time comment
b
c
d ADDS Page Ack
Layer 2 Ack
a ADDS Page
Data Burst Message T3113
Conditional
Conditional
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Figure 3.10.2.3-1 SMS-MT Delivery to an MS on a Common Channel - Example 1
a. The MSC determines that a point-to-point short message is to be sent to an idle MS.
The MSC sends an ADDS Page message to the BS. The ADDS Page contains the short message in its ADDS User Part information element.
If the MSC requires an acknowledgment, it includes the Tag information element in the ADDS Page message and starts timer T3113.
b. The BS sends the short message to the MS on the Paging Channel or the Forward Common Control Channel. Before sending the short message, the BS may perform vendor specific procedures such as paging the MS to determine the cell in which the MS is located.
c. If a Layer 2 Ack was solicited, the MS acknowledges the receipt of the message by a Layer 2 Ack.
d. If the MSC requested an acknowledgment by including the Tag information element in the ADDS Page message, the BS replies with an ADDS Page Ack message
105 Section 3
3GPP2 A.S0013-D v2.0
including the Tag information element set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped.
1
2
3 3.10.2.4 SMS Delivery to an MS on a Common Channel - Example 2 (without Early Traffic Channel Assignment) 4
5
6
7
8
9
This section provides an example call flow description for the delivery of an SMS-MT message on a common channel without early traffic channel assignment by the BS. In this example, the MS is first paged, and then held on the common signaling channel (i.e., not allowed to go to slotted mode) until the SMS messages are delivered. After delivery, the MS is released.
MS BS MSC time comment
g
h
i ADDS Page Ack
Layer 2 Ack
f ADDS Page
Data Burst Message T3113
b
a Paging Request
Base Station Ack Order
T3113
c
d
Complete L3 Info: Paging Response
Page Response Message
Page Message
MSC releases underlying transport connection
k Release Order
e
j
Conditional
Conditional
T303
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Figure 3.10.2.4-1 SMS-MT Delivery to an MS on a Common Channel - Example 2
a. The MSC sends a Paging Request message to the BS and starts timer T3113.
b. The BS sends a Page Message on the Paging Channel.
c. The MS responds with a Page Response Message.
d. The BS sends a Complete Layer 3 Information message containing a Paging Response message to the MSC and starts timer T303. Upon receipt of this message the MSC stops timer T3113.
e. The BS sends a Base Station Ack Order to acknowledge the Page Response Message from the MS.
f. The Radio Environment and Resources element in the Paging Response message indicates no early traffic channel assignment by the BS. The MSC sends an ADDS Page message to the BS. The ADDS Page message contains the short message in its ADDS User Part information element.
Section 3 106
3GPP2 A.S0013-D v2.0
If the MSC requires an acknowledgment, it includes the Tag information element in the ADDS Page message and starts timer T3113.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
g. The BS sends the short message to the MS on either the Paging Channel or the Forward Common Control Channel.
h. If a Layer 2 Ack was solicited, the MS acknowledges the receipt of the message by a Layer 2 Ack.
i. If the MSC requested an acknowledgment by including the Tag information element in the ADDS Page message, the BS replies with an ADDS Page Ack message including the Tag information element set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped.
j. The MSC releases the underlying transport connection to clear the pending page response. The BS stops timer T303 during this process.
k. The BS, upon the release of the underlying transport connection, sends a Release Order to the MS.
3.10.2.5 SMS Delivery to an MS on a Common Channel - Example 3 (with Early Traffic Channel Assignment) 16
17
18
This section provides an example call flow description for the delivery of an SMS-MT message on a common channel with early traffic channel assignment by the BS.
MS BS MSC time comment
g
h
i
ADDS Page Ack
Layer 2 Ack
f
ADDS Page Paging Channel SMS Delivery
T3113
b
a Paging Request
Base Station Ack Order
T3113
c
d
Complete L3 Info:Paging Response
Page Response Message
Page Message
k
l
Release Order
Release Order
e
j
Conditional
Conditional
T303
m
TCH Setup (MSC refuses underlyingtransport connection)
19
20
21
Figure 3.10.2.5-1 SMS-MT Delivery to an MS on a Common Channel - Example 3
a. The MSC sends a Paging Request message to the BS and starts timer T3113.
107 Section 3
3GPP2 A.S0013-D v2.0
b. The BS sends a Page Message on the Paging Channel. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
c. The MS responds with a Page Response Message.
d. The BS sends a Complete Layer 3 Information message containing a Paging Response message to the MSC and starts timer T303. The MSC stops timer T3113.
e. The BS sends a Base Station Ack Order to acknowledge the Page Response Message from the MS.
f. The BS establishes a traffic channel to the MS.
g. The Radio Environment and Resources element in the Paging Response message indicates early traffic channel assignment by the BS. The MSC refuses the underlying transport connection. The BS stops timer T303.
h. The BS, upon the refusal of the underlying transport connection, sends a Release Order to the MS.
i. The MS sends a Release Order to the BS to acknowledge the release.
j. The MSC sends an ADDS Page message to the BS. The ADDS Page contains the short message in its ADDS User Part information element. Note that the MSC should wait a sufficient amount of time after step ‘g’ before sending this message, to allow steps ‘h’ and ‘i’ to complete.
If the MSC requires an acknowledgment, it includes the Tag information element in the ADDS Page message and starts timer T3113.
k. The BS sends the short message to the MS on either the Paging Channel or Forward Control Channel.
l. If a Layer 2 Ack was solicited, the MS acknowledges the receipt of the message by a Layer 2 Ack.
m. If the MSC requested an acknowledgment by including the Tag information element in the ADDS Page message, the BS replies with an ADDS Page Ack message including the Tag information element set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped.
3.10.2.6 SMS Delivery to an MS on a Common Channel - Example 4 using Registration Procedures 30
31
32
33
34
This section provides an example call flow description for the delivery of an SMS-MT message on a common signaling channel using registration procedures. It uses the MS Registration Request message instead of the Paging Request message shown in section 3.10.2.5.
Section 3 108
3GPP2 A.S0013-D v2.0
MS BS MSC time comment
g
h
i ADDS Page Ack
Layer 2 Ack
f
ADDS Page
T3113
b
a
Tordreg
c
d
e
j
Conditional
Conditional
T3210
Optional
Registration Request Order
Registration Message
Registration Accept Order
Data Burst (SMS)
Registration Request
Location UpdateRequest
Location Update Accept
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.10.2.6-1 SMS-MT Delivery to an MS on a Common Channel - Example 4
a. The MSC sends a Registration Request message to the BS and starts timer Tordreg.
b. The BS sends a Registration Request Order on the common signaling channel.
c. The MS responds with a Registration Message.
d. The BS sends a Complete Layer 3 Information message containing a Location Updating Request message to the MSC and starts timer T3210. The MSC stops timer Tordreg.
e. The MSC sends a Location Updating Accept message to the BS. The BS stop timer T3210. This message releases the underlying signaling connection.
f. The BS may optionally send a Registration Accept Order to the MS.
g. The MSC sends an ADDS Page message to the BS. The ADDS Page contains the short message in its ADDS User Part information element. If the MSC requires an acknowledgment, it includes the Tag information element in the ADDS Page message and starts timer T3113.
h. The BS sends the short message to the MS on either the Paging Channel or Forward Control Channel.
i. The MS acknowledges the receipt of the message by a Layer 2 Ack.
j. If the MSC requested an acknowledgment by including the Tag information element in the ADDS Page message, the BS replies with an ADDS Page Ack message including the Tag information element set identical to the value sent by the MSC. If timer T3113 was previously started, it is now stopped.
109 Section 3
3GPP2 A.S0013-D v2.0
3.10.3 SMS Delivery on the Traffic Channel 1
2
3
4
This section describes the delivery of SMS messages on the traffic channel.
The delivery of Short Messages on the traffic channel is accomplished with the ADDS Deliver and ADDS Deliver Ack messages on the A1 interface.
3.10.3.1 SMS Delivery to an MS on a Traffic Channel 5
6
7
This section provides the call flow description for delivery of an SMS-MT short message on a traffic channel.
a
b
c
d
MS BS MSC
ADDS Deliver
Data Burst Message
ADDS Deliver Ack
Layer 2 Ack
comment time
e
Mobile is on a traffic channel
Mobile is on a traffic channel f
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Figure 3.10.3.1-1 SMS Message Delivery to an MS on a Traffic Channel
a. The MSC determines that a short message is to be sent to the MS while it is on the traffic channel. Alternatively, if the MS is not on a traffic channel, an SMS-MT call is established using call flows in section 3.1.2; the service option used in this case is either ‘6H’ or ‘EH’.
b. The MSC sends an ADDS Deliver message to the BS. The ADDS Deliver message contains the short message in the ADDS User Part element.
c. The BS transmits the short message over the forward traffic channel. If the BS does not receive an acknowledgment after transmitting the Data Burst message, it shall retransmit the message. The BS shall not exceed a maximum number of retransmissions, to be selected by the BS manufacturer. When the BS reaches the maximum number of retransmissions, it shall declare a Layer 2 Ack failure and initiate call clearing.
d. The MS acknowledges delivery of the short message on the traffic channel with a Layer 2 Ack.
e. If the MSC has requested a response by including the tag element in the ADDS Deliver message, the BS replies with an ADDS Deliver Ack message when it has received acknowledgment from the MS that the message was delivered. If a Tag element was included in the ADDS Deliver message, the BS shall include the Tag element in the ADDS Deliver Ack message, and set it to the same value as that received in the ADDS Deliver message.
Section 3 110
3GPP2 A.S0013-D v2.0
f. The MS may remain on the traffic channel (e.g. if a voice call is in progress in step ‘a’). Alternatively, the MSC may initiate call clearing if a traffic channel was established in step ‘a’ using SO ‘6H’ or ‘EH’. Refer to section 3.2.4.3.
1
2
3
3.10.3.2 SMS Receipt from an MS on a Traffic Channel 4
5
6
This section provides the call flow description for the receipt of an SMS-MO message on a traffic channel.
a
b
c
MS BS MSC
ADDS Deliver
Data Burst Message
Layer 2 Ack
time
d
e
Mobile is on a traffic channel
Mobile is on a traffic channel
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.10.3.2-1 SMS Receipt from an MS on a Traffic Channel
a. An MS that is currently on a traffic channel determines that a short message is to be sent to the network. Alternatively, if the MS is not on a traffic channel, an SMS-MO call is established using call flows in section 3.1.1.1; the service option used in this case is either ‘6H’ or ‘EH’.
b. The BS receives a Traffic Channel SMS Delivery message from an MS on the traffic channel with a burst type indicating SMS.
c. If a Layer 2 Ack was requested by the MS, the BS sends a Layer 2 Ack to the MS on the traffic channel.
d. The BS sends an ADDS Deliver message to the MSC. The ADDS User Part element contains the short message which was received from the MS.
e. The MS may remain on the traffic channel (e.g. if a voice call is in progress in step ‘a’). Alternatively, the MS may initiate call clearing if a traffic channel was established in step ‘a’ using SO ‘6H’ or ‘EH’. Refer to section 3.2.4.1.
3.11 Priority Access and Channel Assignment (PACA) 22
23
24
25
26
27
The following subsections describe call flows associated with the PACA feature. Refer to section 2.11 for more information on this feature. PACA service involves exchange of the following messages:
PACA Command
PACA Command Ack
111 Section 3
3GPP2 A.S0013-D v2.0
PACA Update 1
2
3
4
5
PACA Update Ack
CM Service Request
Assignment Request
Assignment Failure.
3.11.1 Mobile Origination with PACA Service 6
7
8
9
10
11
12
13
Two conditions may occur on a call origination with PACA service. Under the first condition, the BS can not determine that radio resources are not available for a call before sending the CM Service Request message to the MSC. In this case the origination call flows shown in section 3.1.1.1 is followed. In the second case, the BS determines that radio resources are not available for a call before sending the CM Service Request message. In this second case, the origination call flow shown in section 3.11.1.1 is followed.
3.11.1.1 Mobile Origination with PACA Service – Radio Resources not Available 14
15
16
This section describes the call flow associated with an MS call origination with PACA service in the system.
MS MSC time
BS
Origination Message a
c
e
f
g
h
Complete L3 Info: CM Service Request
PACA Command Ack
T303
PACA Message
Base Station Ack Order b
PACA Command d
Tpaca1
PACA Message
PACA Message
17
18
19
20
21
22
23
24
25
26
27
28
29
Figure 3.11.1.1-1 Mobile Origination with PACA Service
a. The MS transmits an Origination, with Layer 2 Ack required, over the Access Channel of the air interface to the BS to request service. The MS sets the PACA_REORIG field to ‘0’ to indicate a user-directed origination.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
c. The BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303. The BS includes the Radio Environment and Resources element in the CM Service Request message. The ‘Avail’ bit of the Radio Environment and Resources element is set to ‘0’ to indicate that resources at the BS are not available. The PSI field in the Classmark Information Type 2 IE is set to ‘1’.
Section 3 112
3GPP2 A.S0013-D v2.0
The MSC receives the call origination and dialed digits in the CM Service Request message and determines that the call is eligible for PACA service.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
d. The MSC sends a PACA Command message to inform the BS that PACA service shall be applied to this call. The PACA Command message includes the Priority and the PACA Time Stamp information elements to provide information to the BS for PACA queuing. The MSC starts timer Tpaca1. Upon receipt of the PACA Command message the BS stops timer T303.
e. Based on the information received in the PACA Command message the BS queues the call. The BS sends a PACA Command Ack message to the MSC. The MSC stops timer Tpaca1 after receiving the acknowledgment. The MSC releases the underlying transport connection.
f. The BS sends a PACA Message to the MS to indicate that the service request has been queued and includes the queue position.
g. The BS may optionally send additional PACA messages over the Paging Channel to update the MS on its PACA queue position. The BS may resend this message as needed until radio resources become available.
h. When radio resources become available, the BS sends a PACA Message to instruct the MS to re-originate the call. In this case, the PURPOSE field is set to ‘0010’ to request PACA re-origination. The normal Origination call flows (refer to section 3.1.1.1) processes the re-origination request.
3.11.1.2 Mobile Origination, Idle Handoff with PACA Active 21
22
23
24
This section describes the call flow associated with MS call origination with PACA active in the system while idle handoff occurs. This scenario assumes that the idle handoff is intra-MSC.
MS BS-1 MSC time
b
c
d PACA Update Ack
a
PACA Update
Tpaca2
BS-2
Origination Procedure with PACA Service Involving the BS-2
Origination Procedure with PACA Service Involving the BS-1
25
26
27
28
29
30
Figure 3.11.1.2-1 Mobile Origination, Idle Handoff with PACA Active
a. The MS previously attempted a call origination and the call has been queued as in steps ‘a’ through ‘f’ of Figure 3.11.1.1-1.
b. While approaching the boundary of the cell, the MS detects an adequately strong pilot signal transmitted by one of the neighboring cells (BS-1). The MS performs an
113 Section 3
3GPP2 A.S0013-D v2.0
idle handoff and starts monitoring the new Paging Channel. The MS then transmits an Origination Message, with Layer 2 Ack required, over the Access Channel of the air interface to BS-1 to request service. In this case, the PACA_REORIG field received in the Origination Message is set to ‘1’. The re-origination request is processed as in a normal Origination call flows (refer to section 3.1.1.1).
1
2
3
4
5
6
7
8
9
10
11
12
c. The MSC sends a PACA Update message to instruct BS-2 to remove the service request from its PACA queue. The MSC can send the PACA Update message anytime after receiving the CM Service Request message from BS-1. The MSC starts timer Tpaca2.
d. BS-2 sends a PACA Update Ack message to the MSC to confirm that appropriate action has been taken and that its PACA information has been updated. Upon receipt of the PACA Update Ack message the MSC stops timer Tpaca2.
3.11.1.3 Mobile Origination with PACA Active, Consecutive PACA Calls 13
14
15
16
17
This section describes the call flow associated with a successful MS PACA call origination with consecutive service requests in the system. In this scenario the MS originates a PACA call to another number while the first call request is in a PACA queue. The second call is placed in the queue, and the first call is removed.
MS BS MSC
time
b
c
d PACA Update Ack
a
PACA Update
Tpaca2
Origination Procedure with PACA Service
Origination Procedure with PACA Service
18
19
20
21
22
23
24
25
26
27
28
29
30
Figure 3.11.1.3-1 Mobile Origination with Consecutive PACA Call Requests
a. The MS previously attempted a call origination and the call has been queued as in steps ‘a’ through ‘f’ of Figure 3.11.1.1-1.
b. While the first call request is pending, the MS sends an Origination Message, with Layer 2 Ack required, over the Access Channel of the air interface to the BS to request service using a different called party number. In this case, the PACA_REORIG field received in the Origination Message is set to ‘0’. Steps ‘a’ through ‘f’ in Figure 3.11.1.1-1 are followed, and the second call is placed in the PACA queue.
c. The MSC requests that the BS remove the first call from the PACA queue by sending a PACA Update message to the BS with the PACA Order indicating “Remove MS from the queue”. The MSC can send the PACA Update message
Section 3 114
3GPP2 A.S0013-D v2.0
anytime after receiving the second CM Service Request message. The MSC starts timer Tpaca2.
1
2
3
4
5
6
d. The BS sends a PACA Update Ack message to the MSC to confirm that the first call has been removed from the PACA queue and that its PACA information has been updated. Upon receipt of the PACA Update Ack message the MSC stops timer Tpaca2.
3.11.2 PACA Call Cancellation Initiated by the MS 7
8
9
This section describes the call flow associated with cancellation of a PACA queued call in the system. In this scenario the cancellation is initiated by the MS.
MS BS MSC
time
b
c
e PACA Update Ack
a
PACA Update
Tpaca2
Origination Procedure with PACA Service
PACA Cancel
d
BS Ack Order
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Figure 3.11.2-1 PACA Call Cancellation Initiated by the MS
a. The MS previously attempted a call origination and the call has been queued as in steps ‘a’ through ‘f’ of Figure 3.11.1.1-1.
b. The MS sends a PACA Cancel Message, with layer 2 Ack required, over the Access Channel of the air interface to the BS to request that the call be canceled.
c. The BS acknowledges the receipt of the PACA Cancel Message with a Base Station Acknowledgment Order to the MS.
d. The BS cancels the call and removes the request from its PACA queue. The BS then sends a PACA Update message to the MSC to indicate that the call has been canceled. The BS starts timer Tpaca2.
e. The MSC sends a PACA Update Ack message to the BS to confirm the receipt of the PACA Update message. Upon receipt of the PACA Update Ack message the BS stops timer Tpaca2.
3.11.3 PACA Call Cancellation Initiated by Either MSC or BS 24
25
26
27
28
This section describes the call flow associated with cancellation of a PACA call in the system. In this example scenario the cancellation is initiated by the MSC. The BS-initiated PACA call cancellation is identical except the BS sends the PACA Update message to the MSC.
115 Section 3
3GPP2 A.S0013-D v2.0
MS BS MSC
time comment
b
c
e PACA Update Ack
a
PACA Update
Tpaca2
Origination Procedure with PACA Service
PACA Message
d MS Ack Order
MSC decides to cancel the
queued PACA call.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Figure 3.11.3-1 PACA Call Cancellation Initiated by the MSC
a. The MS previously attempted a call origination and the call has been queued as in steps ‘a’ through ‘f’ of Figure 3.11.1.1-1.
b. The MSC sends a PACA Update message to the BS with the PACA Order indicating “Remove MS from the queue and release MS”. The MSC starts timer Tpaca2.
c. The BS cancels the call and removes the request from its PACA queue. The BS then sends a PACA Message (PURPOSE=‘0011’) to the MS to indicate that the PACA call has been canceled.
d. The MS sends an MS Ack order to the BS to acknowledge PACA cancellation.
e. The BS sends a PACA Update Ack message to the MSC to confirm that appropriate action has been taken by the BS and that its PACA information has been updated. Upon receipt of the PACA Update Ack message the MSC stops timer Tpaca2.
3.12 Over-The-Air Service Provisioning (OTASP) and Over The Air Parameter Administration (OTAPA) 15
16
17
This section describes the messages and call flows to support the OTASP and OTAPA features. These features are fully specified in [20].
3.12.1 OTASP Support 18
19
20
21
22
23
This section describes the messages and call flows to support OTASP calls. This includes a mechanism for transporting OTASP data messages, as defined in [20]. The processing of OTASP forward and reverse data messages at the MSC or BS is the responsibility of the vendors. The air interface between the BS and MS is described in [20] and the MSC interface to the network is addressed in [22].
Section 3 116
3GPP2 A.S0013-D v2.0
Successful OTASP processing involves the following procedures and exchange of the following messages:
1
2
3
4
5
6
7
8
9
10
1. OTASP Call Setup procedure
2. OTASP Data Exchange procedure which includes exchange of following messages:
ADDS Deliver
ADDS Deliver Ack
Some existing procedures may also be applied as sub-procedures:
SSD update procedure
Privacy Mode request procedure 3. OTASP Call Clearing procedure
3.12.1.1 OTASP Call Setup 11
12
13
Normal call setup procedures for mobile origination (refer to section 3.1.1) are used to establish the OTASP call.
3.12.1.2 OTASP Data Exchanges 14
15
16
17
18
After a traffic channel has been set up, the ADDS Deliver message is used in both directions to support exchange of OTASP data. In addition, the SSD update procedure and the Privacy Mode procedure over the traffic channel may also be utilized. Refer to section 3.20.1 for the call flows.
3.12.1.3 SSD Update Procedure 19
20
21
22
After the A-key has been derived at the MS as a result of receiving appropriate information via an ADDS Deliver message, an SSD Update procedure over the traffic channel may also be used.
3.12.1.4 Privacy Mode Procedure 23
24
25
26
27
Privacy Mode procedures include pre-loading the BS with parameters for signaling message encryption (SME) or privacy, as well as enabling or disabling SME or privacy.
A Privacy Mode procedure may be applied after an SSD Update procedure has been successfully completed.
3.12.1.5 Rejection 28
29
30
31
When the BS receives a rejection indication (e.g., a Mobile Station Reject Order), it sends the Rejection message to the MSC. No response is expected from the MSC. Refer to [14] for Rejection message procedures and format.
3.12.1.6 OTASP Call Clear 32
33 Normal call clearing procedures (refer to section 3.2) are utilized to clear OTASP calls.
117 Section 3
3GPP2 A.S0013-D v2.0
3.12.1.7 OTASP Call Flow 1
2
3
This section describes the message transactions between an MSC and BS to support OTASP message transfer for the MS.
MS BS MSCtime comment
Origination Message a
b
c
d
e
f
i
j
k
l
n
o
ADDS Deliver
ADDS Deliver Ack
Data Burst (OTA)
Layer 2 Ack/Reject Order with Layer 2 Ack
Data Burst (OTA)
ADDS DeliverLayer 2 Ack
p
Reject Order
Rejection g
h
SSD Update
Privacy Mode Request
Repeat Steps c through k
Normal Call Clearing
mTerminal Re-Authentication
If a Rejection message is
received, the remainder of this scenario
may be omitted.
Optional
Optional
Optional
Optional
Normal Call Setup
4
5
6
7
8
9
10
11
Figure 3.12.1.7-1 OTASP Message Flow: CDMA
a. The MS transmits an Origination Message over the Access Channel of the air interface to the BS to initiate the OTASP process.
b. The MSC and the BS utilize normal call setup procedures (refer to section 3.1.1) to establish the OTASP call.
c. Upon request from the Over the Air Function (OTAF), the MSC encapsulates an OTASP data message within an ADDS Deliver message and sends it to the BS.
Section 3 118
3GPP2 A.S0013-D v2.0
d. The BS extracts the OTASP data message and places it in the CDMA Data Burst Message and transmits it over the traffic channel to the MS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
e. The MS may respond with a Layer 2 Ack or a Reject Order containing a Layer 2 Ack, acknowledging the Data Burst Message.
f. When the BS receives a Layer 2 Ack or a Reject Order containing a Layer 2 Ack acknowledging the Data Burst Message from the MS, in response to an ADDS Deliver message that contained a Tag information element, it sends an ADDS Deliver Ack message to the MSC with the corresponding Tag value.
g. The MS may return a Reject Order.
h. If the MS sends a Reject Order, the BS sends a Rejection message to the MSC to convey the information contained in the Reject Order. If a Rejection message is received, the remainder of this scenario may be omitted.
i. The OTASP application in the MS responds by sending an OTASP data message. The MS places the OTASP data message in the CDMA Data Burst Message and transmits it over the traffic channel to the BS.
j. Upon reception of the CDMA Data Burst Message, the BS responds with a Layer 2 Ack.
k. The BS extracts the OTASP data message and places it in the ADDS Deliver message to the MSC.
Steps ‘l’ through ‘o’ are optional.
l. After the A-key has been derived from information transferred via ADDS Deliver messages, an SSD Update procedure over the traffic channel may also be utilized to exchange authentication information (RANDSSD, RANDBS, AUTHBS).
m. After an SSD Update procedure, Terminal Re-Authentication (refer to [20]) needs to be performed to generate the cipher key that is used for Privacy.
n. After Terminal Re-Authentication, Privacy Mode procedures over the traffic channel may also be applied to specify the use of either Signaling Message Encryption (SME) or Privacy for the call.
o. Multiple forward and reverse OTASP messages can be sent between the OTASP endpoint in the network and the MS. The MSC and the BS transfer these messages whenever they are received.
p. Once the OTASP service programming has been successful, the call can be cleared using regular call clearing procedures (refer to section 3.2).
3.12.2 OTAPA Support 34
35
36
37
38
39
40
The network initiates OTAPA by placing a mobile terminated call to the MS (refer to Figure 3.1.2) using OTAPA service option 18 or 19. With the exception that during the OTAPA session, access to individual NAM parameters of the active NAM is controlled by the Subscriber Parameter Administration Security Mechanism (which is transparent to the IOS), the remainder of the OTAPA procedure is the same as steps ‘c’ through ‘p’ of Figure 3.12.1.7-1.
3.13 Mobile Position Determination 41
42
43
This section presents several call flows which provide examples for mobile position determination. The approaches that are supported in this version of the standard are the
119 Section 3
3GPP2 A.S0013-D v2.0
Position Determination Services (MS-PDE) approach and the Software Calculation Position Determination (BS-MSC) approach. Examples of both of these approaches are given in this section.
1
2
3
4
5
6
7
8
9
10
11
The following messages (defined in [14]) are used to support this feature:
Radio Measurements for Position Request
Radio Measurements for Position Response
ADDS Page
ADDS Page Ack
ADDS Transfer
ADDS Deliver
ADDS Deliver Ack
3.13.1 Call Flows for Position Location Service (MS-PDE) 12
13
14
15
16
17
18
19
This section provides call flows for the MS - PDE approach to position location. Position Location Service may be done on either the common channels (Access and Paging) or traffic channel. Position Location Service over common channels is very similar to SMS delivery on the common channels. Position Location Service on the traffic channel may be accomplished over an existing traffic link by sending Position Location Service data bursts over the existing channel. Alternatively, the MS or the network may initiate a Position Location Services call on a traffic channel if no other services are active.
3.13.1.1 Mobile Originated Position Location Service on the Traffic Channel 20
21
22
This section describes how an MS may initiate Position Location Service on a traffic channel.
Section 3 120
3GPP2 A.S0013-D v2.0
MS BS MSC
Mobile Originated Call Setup
Unique Challenge-Response
Data Burst
ADDS Deliver
ADDS Deliver
Data Burst
Layer 2 Ack
ADDS Deliver Ack
Clear Command
Release Order
Release Order
Clear Complete
time
a
b
c
d
e
f
g
h
i
j
k
l
m
optional
T315
Layer 2 Ack
Clear Request
T300
n
Release Order
o
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.13.1.1-1 Mobile Originated Position Location Service on a Traffic Channel
a. The MS originates a position location service call. Refer to call flows in section 3.1.1.1.
b. Optionally, the MSC may initiate a unique challenge request-response.
c. The MS sends position location data to the BS on the traffic channel in a Data Burst Message, and indicates that a Layer 2 Ack is required.
d. The BS sends a Layer 2 Ack to the MS.
e. The BS encapsulates the Position Location Service data in an ADDS Deliver message and sends it to the MSC.
f. If the PDE has information for the MS, the MSC sends the information in an ADDS Deliver message to the BS. This message includes the Tag information element.
g. The BS sends a Data Burst Message to the MS over the traffic channel and indicates that a Layer 2 Ack is required.
h. Upon receipt of the Data Burst, the MS sends a Layer 2 Ack to the BS.
i. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Deliver Ack to the MSC including the Tag information element it received in the ADDS Deliver message.
j. The MS decides to terminate the position location service and sends a Release Order to clear the call.
121 Section 3
3GPP2 A.S0013-D v2.0
k. The BS sends a Clear Request message to the MSC and starts timer T300. 1
2
3
4
5
6
7
8
9
10
l. The MSC sends a Clear Command message to the BS to instruct the BS to release the traffic channel and starts timer T315. Upon receipt of this message, the BS stops timer T300.
m. The BS initiates call clearing over the air interface by transmitting a Release Order over the forward traffic channel.
n. The MS responds by sending a Release Order to the BS and releasing the traffic channel.
o. The BS sends a Clear Complete message to the MSC. Upon receipt of this message, the MSC stops timer T315.
3.13.1.2 Mobile Terminated Position Location Service on the Traffic Channel 11
12
13
This section describes how the network may initiate Position Location Service on a traffic channel.
MS BS MSC
Mobile terminated call setup
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
mT315
ADDS Deliver
Layer 2 Ack
Clear Request
T300
Release Order
n
14
15
16
17
18
Figure 3.13.1.2-1 Mobile Terminated Position Location Service on a Traffic Channel
a. The MSC determines that a Position Location Service data request needs to be sent to an MS within its serving region and initiates a mobile terminated call. Refer to section 3.1.2.
Section 3 122
3GPP2 A.S0013-D v2.0
b. The MSC sends a Position Location Service data request encapsulated in an ADDS Deliver message to the BS. The MSC includes the Tag information element with this message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
c. The BS delivers the Position Location Service request in a Data Burst Message to the MS over the traffic channel, and indicates that a Layer 2 Ack is required.
d. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the BS.
e. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Deliver Ack message to the MSC with the same Tag value it received from the MSC in the ADDS Deliver message in step ‘b’.
f. The MS sends Position Location Service data response to the BS in a Data Burst Message over the traffic channel and indicates that a Layer 2 Ack is required.
g. Upon receipt of the Data Burst Message, the BS sends a Layer 2 Ack to the MS.
h. The BS encapsulates the Position Location Information in an ADDS Deliver message and sends it to the MSC.
i. The MS decides to terminate the position location service and sends a Release Order to clear the call.
j. The BS sends a Clear Request message to the MSC and starts timer T300.
k. The MSC sends a Clear Command message to the BS to instruct the BS to release the traffic channel and starts timer T315. Upon receipt of this message, the BS stops timer T300.
l. The BS initiates call clearing over the air interface by transmitting a Release Order over the forward traffic channel.
m. The MS acknowledges the Release Order by returning a Release Order over the reverse traffic channel.
n. The BS sends a Clear Complete message to the MSC. The MSC stops timer T315 upon receipt of the Clear Complete message and releases the underlying transport connection.
3.13.1.3 Position Determination Service over Common Channels – Mobile Terminated 28
29
30
This section describes how mobile terminated Position Determination Services may be supported using common channels.
123 Section 3
3GPP2 A.S0013-D v2.0
MS BS MSC
Data Burst
Layer 2 AckT311
3
ADDS Transfer
time
a
b
c
d
e
f
ADDS Page
Data Burst
Layer 2 Ack
g
ADDS Page Ack
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Figure 3.13.1.3-1 Position Location Service over Common Channels – Mobile Terminated
a. The MSC determines that a Position Determination Services data request needs to be sent to an MS within its serving region and sends the ADDS Page message to the BS. The Data Burst Type field in the ADDS User Part is set to ‘05H (PDS)’. The MSC includes the Tag information element in this message. The MSC starts timer T3113.
b. The BS sends the PDS data request to the MS using a Data Burst Message over the Paging Channel. The BS indicates that a Layer 2 Ack is required.
c. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the BS.
d. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Page Ack message to the MSC including the Tag information element with the same value it received in the ADDS Page message. Upon receipt of this message, the MSC stops timer T3113.
e. The MS sends the PDS data response to the BS in a Data Burst Message on the Access Channel. The MS indicates that a BS Ack is required.
f. Upon receipt of the Data Burst Message, the BS sends a Layer 2 Ack to the MS to acknowledge receipt of the Data Burst Message on the Access Channel.
g. The BS encapsulates the PDS data response in an ADDS Transfer message and sends it to the MSC.
3.13.1.4 Position Determination Services over Common Channels – Mobile Originated 19
20
21
This section describes how mobile originated Position Determination Services may be supported using common channels.
Section 3 124
3GPP2 A.S0013-D v2.0
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 Ack g
T3113
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.13.1.4-1 Position Location Service over Common Channels – Mobile Originated
a. The MS sends the Position Determination Services data request to the BS in a Data Burst on the Access Channel. The MS indicates that a BS Ack is required.
b. The BS sends a BS Ack Order to the MS to acknowledge receipt of the Data Burst Message on the Access Channel.
c. The BS encapsulates the PDS data request in an ADDS Transfer message and sends it to the MSC.
d. The MSC determines that a PDS data response needs to be sent to the MS and sends the ADDS Page message to the BS. The Data Burst Type field in the ADDS User Part is set to ‘05H (PLD)’. The MSC includes the Tag information element in this message. The MSC then starts timer T3113.
e. The BS sends the PDS data response to the MS using a Data Burst Message over the Paging Channel. The BS indicates that a Layer 2 Ack is required.
f. Upon receipt of the Data Burst Message, the MS sends a Layer 2 Ack to the BS.
g. Upon receipt of the Layer 2 Ack, the BS sends an ADDS Page Ack message to the MSC including the Tag information element with the same value it received in the ADDS Page message. Upon receipt of this message, the MSC stops timer T3113.
3.13.2 Call Flows for Software Calculation Position Determination (BS-MSC) 20
21
22
This section describes a call flow for the Software Calculation Position Determination approach. This approach is network initiated.
125 Section 3
3GPP2 A.S0013-D v2.0
Tsoftpos
a
b
MS BS MSC
Radio Measurements for Position Request
Radio Measurements for Position Response
time
c
Mobile is on a traffic channel
Mobile is on a traffic channel d
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Figure 3.13.2-1 Software Calculation for Position Determination
a. The PDE determines that position determination by means of software calculation is to take place for a given MS that is on a traffic channel.
b. The MSC sends a Radio Measurements for Position Request message to the BS. The MSC starts timer Tsoftpos.
c. Upon receipt of the Radio Measurements for Position Request message, the BS gathers the requested measurements and returns them in a Radio Measurements for Position Response message. Upon receipt of the Radio Measurements for Position Response message, the MSC stops timer Tsoftpos. Optionally, if the BS is capable of providing the position location, the BS sends the geographic location instead of the requested measurements to the MSC in the Radio Measurements for Position Response message.
d. The MS remains on the traffic channel (e.g. if a voice call is in progress in step ‘a’).
3.14 User Zone 15
16
17
This section contains call flows describing the procedures for User Zones. Refer to section 2.14 for more information on this feature.
Section 3 126
3GPP2 A.S0013-D v2.0
3.14.1 Invoking User Zone at Registration 1
e
User Zone Reject
Location Updating Accept
Location Updating Request
MS BS MSC time comment
Registration Message a
b
c
d Conditional
T3210
User Zone Reject Conditional
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.14.1-1 Location Registration using User Zones
a. The MS initiates a registration operation by sending a Registration Message to the BS.
b. Upon reception of the Registration Message, the BS constructs the Location Updating Request message, including the MS’s User Zone, places it in a Complete Layer 3 Information message, and sends it to the MSC. The BS starts timer T3210.
c. The MSC sends the Location Updating Accept message to the BS to indicate that the Location Updating Request message has been processed. Upon receiving the Location Updating Accept message the BS stops timer T3210.
The following two steps are only used when the MSC rejects the User Zone requested by the MS.
d. The MSC sends a User Zone Reject message to reject the User Zone. The MSC may include an alternate User Zone for the MS to use.
e. The BS sends the User Zone Reject message to the MS with the information it received from the MSC.
127 Section 3
3GPP2 A.S0013-D v2.0
3.14.2 Use of User Zones During Call Setup 1
2
MS BS MSC time comment
a
b
User Zone Reject
User Zone Reject Conditional
c
Mobile Originated/Terminated Call Setup
Conditional 3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.14.2-1 Mobile Call Setup Using User Zone
a. A mobile terminated call (refer to call flows in section 3.1.2) or mobile originated call (refer to call flows in section 3.1.1.1) occurs. The BS includes the User Zone received from the MS in either the CM Service Request message or Paging Response message, depending on the scenario (mobile originated or mobile terminated).
The following two steps are only used when the MSC rejects the User Zone requested by the MS.
b. The MSC sends a User Zone Reject message to reject the MS’s preferred User Zone. The MSC may send an alternate User Zone for the MS to use. This message may be sent any time after the MSC receives either the CM Service Request or Paging Response message, depending on the scenario (mobile originated or mobile terminated).
c. The BS sends the User Zone Reject message to the MS with the information it received from the MSC.
Section 3 128
3GPP2 A.S0013-D v2.0
3.14.3 Changing User Zone During a Call (Mobile Initiated) 1
User Zone Reject
User Zone Update Request
MS BS MSC time comment
a
b
c
d
User Zone Update Request
User Zone Reject Conditional
Conditional
2
3
4
5
6
7
8
9
10
11
12
Figure 3.14.3-1 Updating the User Zone During a Call (Mobile Initiated)
a. The MS transmits a User Zone Update Request over the reverse traffic channel of the air interface to the BS. Included in this message is the User Zone the MS prefers.
b. The BS sends a User Zone Update Request message to the MSC. Included is the preferred User Zone the MS transmitted.
c. If the MSC rejects the MS preferred User Zone the MSC sends a User Zone Reject message which may contain an alternate User Zone for the MS to use. Note, this message is sent only if the MSC rejects the MS preferred User Zone.
d. The BS sends a User Zone Reject message to the MS. Included is the User Zone information the MSC transmitted.
3.14.4 Changing User Zone During a Call (Network Initiated) 13
User Zone Update
MS BS MSC time comment
a
b
User Zone Update
14
15
16
17
18
19
Figure 3.14.4-1 Updating the User Zone During a Call (Network initiated)
a. If the MSC wants to change the User Zone being used by the MS, it sends the User Zone Update message to the BS, including the new User Zone to be used by the MS.
b. The BS sends a User Zone Update message to the MS. Included is the User Zone information the MSC transmitted.
129 Section 3
3GPP2 A.S0013-D v2.0
3.15 ISDN Interworking Service via a Circuit Switched MSC 1
2
3
4
5
6
7
8
9
For ISDN interworking calls, normal call origination, call termination, handoff and call clearing call flows apply. These call flows are described in section 3.1.1, 3.1.2, 3.19.3, and 3.2. Refer to [14] for information on valid service options.
For ISDN interworking calls, the A2 interface carries unrestricted digital information of user traffic between the MSC and the SDU. The SDU shall construct 64 kbps Unrestricted Digital Information (UDI) data from RLP frames transmitted over the air-interface and shall construct RLP frames from 64 kbps unrestricted digital data received from the MSC.
3.16 Circuit Data Calls via a Circuit Switched MSC 10
11
12
Normal call origination, call termination, and call clearing procedures apply.
Call flows associated with this feature are described in sections 3.1.1, 3.1.2, and 3.2.
3.17 3G Packet Data Calls 13
14
15
16
17
18
19
20
21
22
This section describes the procedures and call flows for packet data support in the IOS. Refer to [28] for further explanation of MSC operations and [8] for further explanation of PDSN operations. The call flows in this section assume that the MS does not have an active voice call in progress. Refer to section 3.18 for call flows associated with concurrent services.
For packet data services an A2p connection between the BS and the MGW or a terrestrial circuit between the circuit-switched MSC and the BS is not required. Neither terrestrial circuit between the MSC and the BS nor A2p connection between the BS and the MGW is assigned to the packet data call.
3.17.1 Data Ready to Send (DRS) Indicator 23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
As part of the support for the Dormant State of a service instance, the cdma2000 air interface [21] supports a Data Ready to Send indicator that is used on origination. When an MS sends an origination message13 with a packet data service option specified, it includes the Data Ready to Send (DRS) bit. This indicator is set to ‘1’ on setup of a new service instance and when a service instance transitions from Dormant to Active State because the MS has data to send on that service instance and is requesting the establishment of a traffic channel or service negotiation of an existing traffic channel. The DRS bit is set to ‘0’ to indicate that the terminal has detected that it has crossed a Packet Zone boundary while the service instance was dormant, and is sending the origination message for each service instance to update the network as to its current location. On receipt of an origination with the DRS bit set to ‘1’, the BS initiates the service instance setup procedure as described in section 3.17.4.2, which normally results in the establishment or service negotiation of a traffic channel and in the A8 and A10 bearer connections being established.
When the BS receives an origination message with the DRS bit set to ‘0’, the BS delays the establishment or service negotiation of a traffic channel until after the A8 and A10 bearer connection establishment procedures are complete. During the A8 bearer
13 This may be an Origination Message or an Enhanced Origination Message.
Section 3 130
3GPP2 A.S0013-D v2.0
connection establishment procedure, the BS indicates to the PCF that a DRS=0 has been received through the use of the Data Ready Indicator element in the A9-Setup-A8 message. If the PDSN has data to send (e.g. PPP connection setup) on the service instance, the PDSN indicates this to the PCF by including a Data Available Indicator (DAI) field in the A11-Registration Reply message, and the PCF indicates this to the BS by setting the cause element in the A9-Connect-A8 message to the ‘Data ready to send’ value. The BS requests establishment or service negotiation of a traffic channel using the normal service instance setup procedure as in section 3.17.4.2.
1
2
3
4
5
6
7
8
9
10
11
12
If the PDSN does not have data to deliver to the MS on the service instance, the PCF indicates to the BS that an A8 connection is not to be established by sending the A9-Release-A8 Complete message to the BS, and the dormant mode handoff is completed.
3.17.2 Previous and Current Access Network Identifiers (PANID/CANID) 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
Each PCF shall be uniquely identified by an ANID and shall know its ANID value.
For an MS originated packet data session, the MS does not send any ANID information to the BS. The BS shall not send any ANID information to the PCF. The PCF shall send an ANID NVSE in the A11-Registration Request message to the PDSN with the PANID field set to ‘0’ and the CANID field set to its own ANID. The PDSN shall store the received CANID and associate it with the A10 connections for the MS.
The MS initiates a dormant handoff when it moves into a new packet zone and determines that it needs to notify the packet data network. The MS sends an Origination Message or Enhanced Origination Message to the target BS for each of its dormant service instances in which it may include the PREV_SID, PREV_NID, or PREV_PZID, whichever is different from the current SID, NID and PZID. The BS shall use these fields to determine the ANID of the PCF the MS was previously connected to (i.e., the PANID). The target BS shall send the PANID information to the target PCF in the Access Network Identifiers information element of the A9-Setup-A8 message. The target PCF shall set the PANID field to the received ANID and the CANID field to its own ANID, and shall send this information in an ANID NVSE in each A11-Registration Request message to the PDSN. If the target PCF did not receive the ANID information element from the BS, it sets the PANID field to zero.
In the case of hard or fast handoff, the source BS shall include the ANID of the source PCF in the ANID field of the Handoff Required message sent to the MSC. The MSC shall forward this information to the target BS in the Handoff Request message, which in turn, shall send the received ANID to the target PCF. The target PCF shall include the ANID received from the target BS in the PANID field, along with its own ANID in the CANID field to the PDSN in an ANID NVSE in each A11-Registration Request message.
When the PDSN receives an A11-Registration Request message, it first examines the received mobile identity information to determine if it owns the call. If the PDSN does not recognize the identity of the MS, PPP negotiation and MIP registration (if required) are performed. If the PDSN recognizes the MSID, the PDSN compares the PANID (if not set to zero) to the stored CANID to determine if PPP re-negotiation is required. If the received PANID does not match the stored CANID at the PDSN for the A10 connection, PPP re-negotiation and MIP re-registration (if required) are performed for the packet data session. If multiple service instances are present, PPP re-negotiation and MIP registration (if required) are performed once for the packet data session. When the PDSN determines that all A11 registrations corresponding to a packet data session have been successfully
131 Section 3
3GPP2 A.S0013-D v2.0
processed and the A10 connection for the main service instance has been successfully set up, the PDSN shall update its stored ANID for the MS with the CANID received in the A11-Registration Request message(s) (so that it is up-to-date with the currently active PCF).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
For a mobile initiated dormant re-activation:
When a packet zone change did not occur, or
When a packet zone change did occur, but the MOB_P_REV of the MS is 6,
the MS does not send any ANID information to the BS. The BS shall not send any ANID information to the PCF. The PCF shall not send an ANID NVSE to the PDSN if an A10 connection exists with the PDSN for this service instance for this MS. If an A10 connection does not exist with the PDSN for this service instance for this MS, the PCF shall send an A11-Registration Request message including an ANID NVSE with the PANID field set to ‘0’ and the CANID field set to its own ANID.
If the MS determines that it has moved into a new packet zone at the time of a mobile initiated reactivation, and the MS sends ANID information to the BS, then the BS shall determine the ANID of the source PCF from the ANID information received from the MS and shall send it to the target PCF. The target PCF shall then send an ANID NVSE to the PDSN with the PANID field set to the ANID received from the BS and the CANID field set to the ANID of the target PCF.
For a network initiated dormant reactivation, the MS does not send any ANID information to the BS. The BS shall not send any ANID information to the PCF. If the A10 connections for the MS’s service instances have already been established at the PCF, the PCF shall not send an ANID NVSE to the PDSN. Otherwise, the PCF shall include an ANID NVSE in the A11-Registration Request with the PANID field set to ‘0’ and the CANID field set to its own ANID.
3.17.3 PDSN Selection Algorithm 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
This section only applies to establishment of the first A10 bearer connection for a given MS. Requests for additional A10 bearer connections (for additional PDSIs) shall be sent to the PDSN currently supporting the existing A10 bearer connection(s).
Each PCF shall maintain a configuration table with IP addresses as follows:
PDSN Number PDSN IP Address
0 a b c d
1 k l m n
…
N-1 w x y z
The PDSNs accessible from the PCF shall be listed in ascending order of PDSN IP addresses. In order for two PCFs to resolve the same IMSI to the same PDSN, the PCFs need to have tables of equal lengths. In network configurations with full connectivity, the PDSN selection algorithm allows two PCFs to resolve the same IMSI to the same PDSN. In network configurations with partial connectivity, tables of equal lengths can be
Section 3 132
3GPP2 A.S0013-D v2.0
achieved by adding dummy entries in the tables for PDSNs that exist in the network but are not accessible from the PCF. The PCF shall be capable of including dummy entries in the configuration table. Each dummy entry shall be placed in the position in the table that the PDSN entry would have had if the PCF had had connectivity to that PDSN. The PDSN IP address for such “dummy” PDSN entries shall be set to ‘0.0.0.0’. Finally, the entries shall be numbered from 0 to N-1 in ascending order, N being the total number of entries in the table.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
For initial PDSN assignment and for PDSN reselection, the PCF shall determine which PDSN to use for a particular MS by the following PDSN Selection algorithm:
PDSN No. = (truncated Mobile IMSI) modulo N,
where (truncated Mobile IMSI) is defined to be the least significant 4 digits of the IMSI taken as a decimal value.
The IP address of the selected PDSN shall be obtained by indexing at the PDSN Number entry in the configuration table. If the selected PDSN entry is a dummy, the PCF shall select another PDSN by performing the following algorithm, up to N-1 times, till a non-dummy PDSN IP Address entry is found in the configuration table.
PDSN No. = (PDSN No. +1 ) modulo N.
After the PCF has selected a non-dummy PDSN entry using the selection algorithm, the PCF shall initiate establishment of the A10 connection with the selected PDSN. If the selected PDSN responds with code “Unknown PDSN address” (88H) in the A11-Registration Reply, thereby proposing another PDSN, the PCF may initiate establishment of the A10 connection with the proposed PDSN.
If the selected PDSN does not reply to the registration request or replies with a code other than “Registration accepted” (00H), “Identification mismatch” (85H), or “Unknown PDSN address” (88H), the PCF may select another PDSN among the other non-dummy entries. The PCF may repeat this procedure until it successfully establishes an A10 connection.
3.17.4 3G Packet Data Call Flows 28
29
30
This section lists the messages and describes call flows for the A8/A9 and A10/A11 interfaces.
3.17.4.1 Interface Messages 31
32 This section lists the A9 and A11 interface messages.
3.17.4.1.1 A9 Interface Messages 33
34
35
36
37
38
39
The following messages are required to support the 3G packet data feature on the A9 interface:
A9-Setup-A8
A9-Connect-A8
A9-AL Connected
A9-AL Connected Ack
133 Section 3
3GPP2 A.S0013-D v2.0
A9-Release-A8 1
2
3
4
5
6
7
8
A9-Release-A8 Complete
A9-Update-A8
A9-Update-A8 Ack
A9-Disconnect-A8
A9-BS Service Request
A9-BS Service Response
For A8 interface Setup, Release, Handoff, and Accounting procedures, refer to [16].
3.17.4.1.2 A11 Interface Messages 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
The following messages are required to support the 3G packet data feature on the A11 interface:
A11-Registration Request
A11-Registration Response
A11-Registration Update
A11-Registration Acknowledge
A11-Session Update
A11-Session Update Acknowledge
The A10/A11 interface uses messages modeled after Mobile IP for managing the A10 connections. The MS initiates PDSIs by sending an IS-2000 origination (Origination Message or Enhanced Origination Message). Normal voice service authentication procedures are followed for the subscriber, and then a traffic channel is assigned, if necessary, and associated with the service instance. After connection of the packet data service option, RLP synchronization between the MS and the BS proceeds if applicable. The BS/PCF initiates setup of an A10 connection with the PDSN by sending an A11-Registration Request message that includes the service option of the requested A10 connection on the A11 interface. The PDSN may accept or reject the connection setup request. If the connection setup request is acceptable, the PDSN returns an A11-Registration Reply message with an accept indication, and the PDSI is connected through the just established A10 connection.
The AAA stores subscription information such as the maximum number of PDSIs allowed and subscribed packet data service options. Therefore the RAN should send the SO value to the PDSN in the A11-Registration Request message; the PDSN may check the request against the information in the AAA and then either accept or reject the request.
With the A10 connection in place, link layer/network layer frames pass over this connection in both directions via Generic Routing Encapsulation (GRE) framing; refer to [35]. The PDSN accepts these frames, strips the GRE, and processes them as normal incoming frames for the appropriate interface and protocol. The other direction behaves analogously, with the PDSN encapsulating the link layer/network layer frames in GRE, and the PCF stripping the GRE before passing the frames over to the upper layer. At this point, there is a point-to-point link layer/network layer connection between the MS and the PDSN.
To set up an A10 connection, the PCF sends an A11-Registration Request message to the PDSN. This message includes a PCF Session Identifier (PCF SID) to be used by the
Section 3 134
3GPP2 A.S0013-D v2.0
PDSN as the Key in the GRE header when sending data frames on the A10 connection. In the case of multiple A10 connections for one MS, each A10 connection is assigned a separate Key to be used in the GRE header and a separate Lifetime timer. The PCF Session Identifier (PCF SID) is unique only within the PCF entity. In the A11-Registration Reply message, the PDSN assigns a PDSN Session Identifier (PDSN SID) to be used by the PCF as the Key in the GRE header when sending data frames on the A10 connection. If both the PCF and the PDSN support a Session Identifier Version higher than ‘0’, the PDSN SID may be different from the PCF SID. This allows the PDSN to choose a PDSN SID that is unique within the PDSN. Otherwise, the PDSN SID shall be identical to the PCF SID, thereby maintaining backwards compatibility. The PCF also uses the MN Session Reference ID, that is set to the SR_ID that is passed from the MS on each origination and which, together with the Mobile Station Identifier (MS-ID), can be used to identify a PDSI for a specific MS across PCFs and PDSNs. In the A11-Registration Request message, the PCF sets the Home Address field to zeros. The IP source address (IP header) and the Care-of-Address field of the A11-Registration Request message are set to the IP address of the PCF. The IP destination address in the IP header and the Home Agent field in the A11-Registration Request message are set to the address of the PDSN designated for the call. The PCF Session Identifier (PCF_SID), link layer/network layer protocol type identifier, MN Session Reference ID and MS_ID of the MS are set in the Session Specific Extension of the A11-Registration Request message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
For procedures for A10 interface Setup, Operation, Release, and Accounting, refer to [17].
3.17.4.2 MS Initiated PDSI Setup 23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
The MS initiates the setup of all PDSIs. To initiate a PDSI, the MS performs registration with the serving wireless network and then with the packet network. There are two cases of an MS-Initiated PDSI setup:
1. Setup of a PDSI when the packet data session is dormant (i.e., all existing packet service instances are dormant) or the packet data session is in Null/Inactive State (i.e., no existing PDSIs exist for the MS). The MS sends an Origination Message to the BS that includes the packet data service option. It results in assignment of the traffic channel, and establishment of an A10 connection. For the first PDSI that the MS initiates (main service instance), the Origination Message also results in the establishment of the link layer (PPP) and for the case where Mobile IP is used by the terminal, Mobile IP registration with the serving packet network.
2. Setup of a PDSI while the packet data session is active (i.e., at least one other PDSI is active). In this case, the MS sends an Enhanced Origination Message to the BS that includes the packet data service option, which results in a reconfiguration of the traffic channel and establishment of an A10 connection.
User data traffic can now be passed over the A10 connection encapsulated within GRE frames. The PCF periodically re-registers with the selected PDSN by the use the of A11-Registration Request message before the A10 connection Lifetime expires.
3.17.4.2.1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive 42
43
44
When an MS initiates a PDSI and PPP negotiation has not been initiated yet, PPP negotiation is performed over that PDSI before transmitting packet data.
135 Section 3
3GPP2 A.S0013-D v2.0
A9-Connect-A8
time PDSN MS
IS-2000 TCH
Establishment procedure
Origination
BS ACK Order
BS PCF
CM Service Request
T303 Assignment Request
MSC
A9-Setup-A8
T10
TA8-setup
i
g
h
A11-Registration Request
A11-Registration Reply
f
Tregreq
a
b
c
d
e
k
Active Packet Data Session
Establishing PPP connection
l
Assignment Complete j
A11-Registration Request
A11-Registration Reply Tregreq
m
n 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.17.4.2.1-1 MS Initiated PDSI Setup - Packet Data Session is Dormant or Inactive
Note: The following descriptions assume that the PCF is capable of determining whether one or more PDSNs are reachable on the A10/A11 network. Based on the algorithm specified in section 3.17.3, the PCF selects a PDSN best suited for handling this call.
a. The MS transmits an Origination Message (DRS=1), with layer 2 acknowledgment required, over the access channel of the air interface to the BS to request packet data service.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
c. The BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303.
d. The MSC sends an Assignment Request message to the BS to request assignment of radio resources and starts timer T10. No terrestrial circuit between the MSC and the BS is assigned to the packet data call. The BS stops timer T303.
e. The BS and the MS initiate the establishment of a radio traffic channel.
f. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator set to ‘1’ to establish an A8 connection and starts timer TA8-setup. This step may occur anytime after step ‘d’.
Section 3 136
3GPP2 A.S0013-D v2.0
g. If the PCF recognizes that there are no A10 connections associated with this MS, the PCF selects a PDSN for the call. If, however, one or more A10 connections already exist for the MS at the PCF, the PCF selects the same PDSN to establish the A10 connection for the new service instance. The PCF sends an A11-Registration Request message with non-zero Lifetime value and the ANID of the PCF (sent in the CANID field) to the selected PDSN. This message also includes Accounting Data (R-P Session Setup Airlink Record). The PCF starts timer Tregreq.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
h. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and the Lifetime set to the configured Trp value. Both the PDSN and the PCF create a binding record for the A10 connection. The PCF stops timer Tregreq. The PCF and PDSN start timer Trp. If the A10 connection is the first set up for the MS and the PDSN supports fast handoff, the Anchor P-P Address is sent as part of an NVSE element to the PCF. If the PCF does not support fast handoff, the Anchor P-P Address is discarded.
i. Upon establishment of the A10 connection, the PCF establishes an A8 connection and transmits an A9-Connect-A8 message with cause value set to ‘Successful operation’. If the PCF supports fast handoff, it provides the Anchor PDSN Address and Source PDSN Address and the PDSN provides the Anchor P-P Address. The PCF supporting fast handoff passes this information to the BS as part of this message. In the message, the PCF includes a Service Instance Info information element identifying all dormant PDSIs. BS stops timer TA8-setup.
j. The BS transmits an Assignment Complete message. The MSC stops timer T10.
k. If the PDSI is the first to be set up (i.e. main PDSI), the PPP connection establishment procedure and Mobile IP Registration (if required) on the PPP connection are performed between the MS and PDSN.
l. The PDSI is ready for data transmission and the MS begins to send/receive user data via GRE framing over the A10 connection.
m. The PCF sends an A11-Registration Request message before expiration of the registration Lifetime timer (Trp) for refreshing registration for the A10 connection. The A11-Registration Request message may also be used to send accounting related and other information to the PDSN. The accounting related and other information is sent at system defined trigger points. The PCF starts timer Tregreq.
n. For a validated A11-Registration Request message, the PDSN returns an A11-Registration Reply message with an accept indication and a configured Lifetime value. Both the PDSN and the PCF update the A10 connection binding record. The PDSN stores the accounting related and other information (if received) for further processing, before returning the A11-Registration Reply message. The PCF stops timer Tregreq. The PCF and PDSN start timer Trp.
3.17.4.2.2 Mobile Initiated Setup of a PDSI When the Packet Data Session Already Is Active– Successful Operation 41
42 In this scenario, another PDSI has already been established and is active.
137 Section 3
3GPP2 A.S0013-D v2.0
conditional
comment
EOM
BS ACK Order b
c
TA8-setup
d
f
g
Service negotiation procedure
a
A9-Connect-A8
A9-Setup-A8
A11-Registration Request
A11-Registration Reply Tregreq
e
h Active Packet Data Service Instance
BS MS PCF MSC PDSN time
j
A11-Registration Request
A11-Registration Reply Tregreq
i
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Figure 3.17.4.2.2-1 Mobile Initiated Setup of a PDSI When the Packet Data Session is Already Active– Successful Operation
Note: The following descriptions assume that one or more A10 connections already exist at the PCF for this MS.
a. The MS has an active packet session, and decides to initiate another PDSI. The MS transmits an Enhanced Origination Message (DRS=1) to the BS to initiate a PDSI.
b. If a layer 2 acknowledgement was requested in step ‘a’, the BS acknowledges the receipt of the Enhanced Origination Message with a Base Station Acknowledgment Order to the MS.
c. Service negotiation procedures take place to associate the new service instance with the traffic channel.
d. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator set to ‘1’ to establish an A8 connection and starts timer TA8-setup.
e. The PCF recognizes that one or more A10 connections associated with this MS already exist at the PCF and selects the same PDSN to establish the A10 connection for the new service instance. The PCF sends an A11-Registration Request message with non-zero Lifetime value and the ANID of the PCF (sent in the CANID field) to the selected PDSN. This message also includes Accounting Data (A10 Connection Setup Airlink Record). The PCF starts timer Tregreq.
f. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and the Lifetime set to the configured Trp value. Both the PDSN and the PCF create a binding record for the A10 connection. The PCF stops timer Tregreq. The PCF and PDSN start timer Trp.
Section 3 138
3GPP2 A.S0013-D v2.0
g. Upon establishment of the A10 connection, the PCF establishes an A8 connection and transmits an A9-Connect-A8 message with cause value set to ‘Successful Operation’. The BS stops timer TA8-setup upon receipt of this message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
h. The PDSI is ready for data transmission and the MS begins to send/receive user data via GRE framing over the A10 connection.
i. The PCF sends an A11-Registration Request message before expiration of the registration Lifetime timer (Trp) for refreshing registration for the A10 connection. The A11-Registration Request message may also be used to send accounting related and other information to the PDSN. The accounting related and other information is sent at system defined trigger points. The PCF starts timer Tregreq.
j. For a validated A11-Registration Request message, the PDSN returns an A11-Registration Reply message with an accept indication and a configured Lifetime value. Both the PDSN and the PCF update the A10 connection binding record. The PDSN stores the accounting related and other information (if received) for further processing, before returning the A11-Registration Reply message. The PCF stops timer Tregreq. The PCF and PDSN start timer Trp.
3.17.4.3 Mobile Originated PDSI Setup – Failure Operation 17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
To initiate a PDSI, the MS performs registration with the serving wireless network and then with the packet network. The MS sends an Origination Message or an Enhanced Origination Message to the BS that includes the packet data service option. It results in assignment or reconfiguration of the traffic channel. The PCF initiates establishment of the A10 connection with the PDSN by sending an A11-Registration Request message to the PDSN. If the connection setup request is not acceptable, the PDSN returns an A11-Registration Reply message with a reject code. Based on the reject code, the PCF may attempt to establish the A10 connection again. If the A10 connection is not able to be established, the PCF indicates this to the BS. If the MS has no other active service instance, the BS returns a failure indication to the MSC, which, in-turn, releases the call. Otherwise, if the MS has other active service instances, the BS initiates service negotiation back to the previous configuration.
The following call flow shows the case where the MS does not have any other active service instances prior to attempting to initiate a new service instance. The case where the MS does have other active service instances is analogous with the following modifications:
1. The MS sends an Enhanced Origination Message instead of an Origination Message.
2. The BS and MSC exchange no messages.
3. The traffic channel is reconfigured rather than set up and released.
139 Section 3
3GPP2 A.S0013-D v2.0
MS BS/PCF MSC time
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
Release Order
l
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.17.4.3-1 Mobile Originated PDSI Setup When the Packet Data Session is Dormant or Inactive – Failure Operation
Note: The following descriptions assume that the PCF is capable of determining reachability to one or more PDSNs on the A10/A11 network. Based on the algorithm specified in section 3.17.3, the PCF selects a PDSN best suited for handling this call.
a. To initiate a packet data service, the MS sends an Origination Message with Layer 2 Ack required indication over the Access Channel to the BS. The Origination Message includes a packet data service option.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Ack Order to the MS.
c. The BS constructs a CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303.
d. The MSC sends an Assignment Request message to the BS requesting assignment of radio resources and starts timer T10. No terrestrial circuit between the MSC and the BS is assigned to the packet data call.
e. On receipt of the Assignment Request message, the BS stops timer T303. The BS and the MS perform radio resources setup procedures if the MS is not already on a traffic channel.
f. If the PCF recognizes that there are no A10 connections associated with this MS, the PCF selects a PDSN for the call. If, however, one or more A10 connections already exist for the MS at the PCF, the PCF selects the same PDSN to establish the A10 connection for the new service instance. The PCF sends an A11-Registration Request message with non-zero Lifetime value to the selected PDSN. This message also includes Accounting Data (A10 Connection Setup Airlink Record). The PCF starts timer Tregreq.
Section 3 140
3GPP2 A.S0013-D v2.0
g. The PDSN does not accept the A11-Registration Request message and fails A10 connection setup by returning an A11-Registration Reply message with a reject code. The PCF stops timer Tregreq.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
h. Based on the reject code, the PCF may attempt to establish the A10 connection again. If the A10 connection can not be established, the BS returns an Assignment Failure with cause “PDSN resources are not available” or “Equipment failure” to the MSC. Upon receipt of this message, the MSC stops timer T10.
i. The MSC sends a Clear Command message to the BS, instructing the BS to release the associated resources, including the radio resources. The MSC starts timer T315.
j. The BS sends a Release Order to the MS instructing the MS to release the radio resources.
k. The MS sends a Release Order to the BS.
l. The BS returns a Clear Complete message to the MSC. Upon receipt of this message, the MSC stops timer T315.
Note: If the BS has already returned an Assignment Complete message to the MSC prior to receiving an A11-Registration Reply message with a reject code from the PDSN, the BS initiates release of the call by sending a Clear Request with cause (Equipment failure) to the MSC in place of the Assignment failure in step ‘h’.
3.17.4.4 Mobile Originated Packet Call Setup – With Registration to Alternate PDSN 19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
To initiate a PDSI, the MS performs registration with the serving wireless network and then with the packet network. The MS sends an Origination Message to the BS that includes the packet data service option, which results in assignment of the traffic channel. The PCF initiates establishment of the A10 connection with the selected PDSN by sending an A11-Registration Request message. If the PDSN does not accept the connection and wants to propose another PDSN, it returns an A11-Registration Reply message with code ‘88H’ (Registration Denied – unknown PDSN address). The address of the alternate PDSN is also returned in the Home Agent field of the A11-Registration Reply message. The PCF may accept the alternate PDSN by sending another A11-Registration Request message, or may use the algorithm specified in section 3.17.3 to select a new PDSN. The PCF initiates establishment of the A10 connection with the selected PDSN by sending an A11-Registration Request message.
Note that this scenario is relevant only for the case where the MS attempts to set up the first (main) service instance, since all service instances shall be served by the same PDSN.
141 Section 3
3GPP2 A.S0013-D v2.0
MS BS/PCF MSC time
Origination Message
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
PDSN-2
A11-Registration Request
A11-Registration Reply
A11-Registration Request
Tregreq
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Figure 3.17.4.4-1 Mobile Originated Packet Service Instance Setup – With Registration to Alternate PDSN
Note: The following descriptions assume that the PCF is capable of determining reachability to one or more PDSNs on the A10/A11 network. Based on the algorithm specified in section 3.17.3, the PCF selects a PDSN best suited for handling this call.
a. To initiate a PDSI, the MS sends an Origination Message with Layer 2 Ack required indication over the Access Channel to the BS. The Origination Message includes a packet data service option.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Ack Order to the MS.
c. The BS constructs a CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303.
d. The MSC sends an Assignment Request message to the BS requesting assignment of radio resources and starts timer T10. No terrestrial circuit between the MSC and the BS is assigned to the packet data call.
Section 3 142
3GPP2 A.S0013-D v2.0
e. On receipt of the Assignment Request message, the BS stops timer T303. The BS and the MS perform radio resources setup procedures if the traffic channel has not already been set up.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
f. The PCF recognizes that no A10 connection associated with this MS is available and selects a PDSN (PDSN-1) for this call. The PCF sends an A11-Registration Request message with non-zero Lifetime value to the selected PDSN-1. This message also includes Accounting Data (A10 Connection Setup Airlink Record). The PCF starts timer Tregreq.
g. The A11-Registration Request message is validated. PDSN-1 rejects the connection and proposes another PDSN (PDSN-2). PDSN-1 returns an A11-Registration Reply message with a reject code of ‘88H’ (Registration Denied – unknown PDSN address) and the address of the alternate PDSN (PDSN-2) in the Home Agent address field of the A11-Registration Reply message. The PCF stops timer Tregreq.
h. The PCF initiates establishment of the A10 connection with PDSN-2 by sending an A11-Registration Request message with non-zero Lifetime value. The PCF starts timer Tregreq.
i. The A11-Registration Request message is validated and PDSN-2 accepts the connection by returning an A11-Registration Reply message with an accept indication and the Lifetime set to the configured Trp value. Both PDSN-2 and the PCF create a binding record for the A10 connection. If PSDN-2 supports fast handoff, the Anchor P-P address is sent as a part of the NVSE element to the PCF. If the PCF does not support fast handoff, the Anchor P-P address is discarded. The PCF stops timer Tregreq.
j. The BS sends an Assignment Complete message to the MSC. The MSC stops timer T10. This step may occur any time after radio link establishment.
k. The MS and PDSN-2 establish the link layer (PPP) connection and then perform the MIP registration procedures (if required) over the link layer (PPP) connection, thereby creating a mobility binding for the MS.
l. The MS begins to send/receive user data via GRE framing over the A10 connection.
Note: The PCF continues to perform re-registration of the A10 connection with PDSN-2 by the exchange of A11-Registration Request messages and A11-Registration Reply messages before expiration of Lifetime time Trp.
3.17.4.5 BS Initiated PDSI Release to Dormant State 33
34
35
36
37
38
39
40
This section presents example call flows associated with a BS initiated PDSI release to Dormant. To simplify the diagrams, it is assumed that for purposes of these examples, the packet call is not in inter-BS soft/softer handoff prior to the release and that the MS does not have an active voice call in progress.
There are two cases of a BS-initiated PDSI release to Dormant State:
1. Release of a PDSI when no other PDSI is active.
2. Release of a PDSI when other PDSIs are active.
143 Section 3
3GPP2 A.S0013-D v2.0
3.17.4.5.1 BS Initiated PDSI Release to Dormant State When No Other PDSI is Active 1
2
Clear Request
Clear Complete
A9-Release-A8
Clear Command
A9-Release-A8 Complete
MS BS MSC/VLR PCF PDSN time
a
b
c
d
f
h
i
T300
T315
Trel9
TCH
Release
g
Active packet data service instance / packet data session
Dormant packet data service instance / Dormant packet data session
A11-Registration Request
A11-Registration Reply Tregreq
e
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Figure 3.17.4.5.1-1 BS Initiated PDSI Release to Dormant State When No Other PDSI is Active
a. The BS determines the service needs to be moved to the Dormant State. The BS sends a Clear Request message with cause set to ‘Packet call going dormant’ to the MSC to initiate the call clear transaction, and starts timer T300.
b. The MSC starts timer T315 and sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resources. The BS stops timer T300.
c. BS initiates traffic channel release using existing procedures.
d. The BS sends an A9-Release-A8 message, with a cause value set to “Packet call going dormant”, to the PCF to instruct the PCF to release the associated dedicated resources, and starts timer Trel9. This step may occur anytime after step ‘c’. Note that in this scenario the A10 connection is not released.
e. The PCF sends an A11-Registration Request message with updated accounting data. Refer to section 3.17.4.25. The PCF sends the ‘All-Dormant Indicator’ to the PDSN. Any P-P connections that may exist to an anchor PDSN (refer to section 3.19.4.2) are released according to procedures specified in [8]. The PCF starts timer Tregreq.
f. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops Tregreq.
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
Section 3 144
3GPP2 A.S0013-D v2.0
h. The BS returns a Clear Complete message to the MSC. The MSC stops timer T315 and releases the underlying transport connection. This step may occur any time after the traffic channel is released.
1
2
3
4 i. At this point, the packet data session is considered to be in the Dormant State.
3.17.4.5.2 BS Initiated PDSI Release to Dormant State When Other PDSIs are Active 5
6
A9-Release-A8
A9-Release-A8 Complete
MS BS MSC/VLR PCF PDSN time
a
b
d
Trel9
e
f
Service
Negotiation
Dormant packet data service instance/ active packet data session
Active packet data service instance/ active packet data session
cA11-Registration Request
A11-Registration Reply Tregreq
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Figure 3.17.4.5.2-1 BS Initiated PDSI Release to Dormant State When Other PDSIs are Active
a. The BS determines the service needs to be moved to the Dormant State. Service negotiation procedures take place to dissociate the service instance from the traffic channel.
b. The BS sends an A9-Release-A8 message, with a cause value set to “Packet call going dormant”, to the PCF to instruct the PCF to release the associated dedicated resources, and starts timer Trel9. Note that in this scenario the A10 connection is not released.
c. The PCF sends an A11-Registration Request message with updated accounting data. Refer to section 3.17.4.25. The PCF starts timer Tregreq.
d. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops Tregreq.
e. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
f. At this point, the PDSI is considered to be in the Dormant State but the packet data session remains in Active State.
145 Section 3
3GPP2 A.S0013-D v2.0
3.17.4.6 MS Initiated PDSI Release to Dormant State 1
2
3
4
5
6
7
8
9
This section presents example call flows associated with PDSI release to Dormant initiated by the MS. To simplify the call flows, it is assumed that for purposes of these examples, the packet data call is not in inter-BS soft/softer handoff prior to the release and the MS does not have an active voice call in progress.
Refer to section 3.17.4.22 for MS initiated release of the PDSI to the Inactive/Null State.
There are two cases of an MS-initiated PDSI release to the Dormant State:
1. Release of a PDSI to Dormant State when no other PDSI is active.
2. Release of a PDSI to Dormant State when other PDSIs are active.
3.17.4.6.1 MS Initiated PDSI Release to Dormant State when no other PDSI is Active 10
Release Order
TCH Release
Procedure
Clear Request
Clear CommandT300
A9-Release-A8
T315
Trel9
Active packet data service instance / Active packet data session
A11-Registration Request
A11-Registration Reply Tregreq
MS BS MSC/VLR PCF PDSN time
Clear Complete
a
f
i
j
h
Dormant packet data service instance / Dormant packet data session
A9-Release-A8 Complete
b
c
d
e
g
11
12
13
14
15
16
17
18
19
20
Figure 3.17.4.6.1-1 MS Initiated PDSI Release to Dormant State When No Other PDSI is Active
a. The MS determines that the service needs to be released to Dormant State. The MS sends a Release Order with “ORDQ = 00000000” to the BS to request a transition of the active PDSI to the Dormant State.
b. The BS then sends a Clear Request message with cause set to ‘Packet call going dormant’ to the MSC to initiate the call clear transaction, and starts timer T300.
c. The MSC sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resources and starts timer T315. The BS stops timer T300.
Section 3 146
3GPP2 A.S0013-D v2.0
d. The traffic channel is released. Upon reading the overhead messages on the common channels the MS may discover that it has moved to another packet zone while active and initiate a dormant handoff. Refer to section 3.17.4.13.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
e. The BS sends an A9-Release-A8 message, with a cause value set to “Packet call going dormant”, to the PCF to instruct the PCF to release the associated dedicated resources, and starts timer Trel9. Note that in this scenario the A10 connection is not released.
f. The PCF sends an A11-Registration Request message to the PDSN with updated accounting data and starts timer Tregreq. Refer to section 3.17.4.25. The PCF sends the ‘All Dormant Indicator’ to the PDSN. Any P-P connections that may exist to an anchor PDSN (refer to section 3.19.4.2) are released according to procedures specified in [8].
g. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops timer Tregreq.
h. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
i. The BS returns a Clear Complete message to the MSC. The MSC releases the underlying transport connection and stops timer T315. This step may occur any time after the traffic channel is released.
j. At this point the packet data session is considered to be in the Dormant State.
147 Section 3
3GPP2 A.S0013-D v2.0
3.17.4.6.2 MS Initiated PDSI Release to Dormant State when other PDSIs are Active 1
RRRM / RRRMM
MS BS MSC/VLR PCF PDSN time
A9-Release-A8 Complete
a
d
f
g
A9-Release-A8
Trel9
b
c
Service negotiation procedures
Active Packet Data Service Instance / Active Packet Data Session
Dormant Packet Data Service Instance / Active Packet Data Session
A11-Registration Request Tregreq
eA11-Registration Reply
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Figure 3.17.4.6.2-1 MS Initiated PDSI Release to Dormant State When Other PDSIs are Active
a. To transition an active PDSI to Dormant State, the MS sends either a Resource Release Request Message (RRRM) or a Resource Release Request Mini Message (RRRMM) with the Purge Indicator set to ‘0’. The ‘CON_REF’ parameter in the message allows the BS to determine the corresponding SR_ID for the affected PDSI.
b. Service negotiation procedures take place to dissociate the service instance from the traffic channel.
c. The BS sends an A9-Release-A8 message with the cause value set to “Packet call going dormant” to the PCF to instruct the PCF to release the associated dedicated resources, and starts timer Trel9.
d. The PCF sends an A11-Registration Request message with updated accounting data. Refer to section 3.17.4.25. The PCF starts timer Tregreq.
e. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops Tregreq.
f. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
g. At this point, the PDSI is considered to be in the Dormant State; however, the packet data session is still in Active State.
Section 3 148
3GPP2 A.S0013-D v2.0
3.17.4.7 Active MS Power Down 1
2
3
4
This section describes the call flow associated with a packet data session release initiated by an MS power down when the packet data session is active. Refer to section 3.17.4.23 for MS power down when the packet data session is in the Dormant State.
MS BS PCF MSC PDSN time
Clear Request
Clear CommandRelease Order
Release Order
Clear Complete
A9-Release-A8 Complete
a
b
c
d
e
f
h
i
A9-Release-A8
T300
T315
Trel9
g
A11-Registration Request
A11-Registration Reply Tregreq
(Power Down Ind).
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Figure 3.17.4.7-1 Active MS Power Down
a. The MS powers down causing the packet data session to terminate. It sends a Release Order to the BS with a power down indication.
b. The BS sends a Clear Request message with cause set to ‘call processing’ and Cause Layer 3 set to ‘Normal Clearing or Normal Unspecified’ to the MSC to initiate the call clear transaction, and starts timer T300.
c. The MSC sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resources and starts timer T315. The BS stops timer T300.
d. In response to the Clear Command message, the BS acknowledges the MS by sending it a Release Order and releases the radio resource. Step ‘d’ may occur in parallel with step ‘e’.
e. The BS sends an A9-Release-A8 message with a cause value set to “Packet data session release” to the PCF to instruct the PCF to release the dedicated resource associated with all PDSIs (both active and dormant) of the MS, and to release the associated A10 connection(s). The BS uses the SR_ID of any one of the active PDSIs in the A9-Release-A8 message. The BS starts timer Trel9.
f. The PCF sends one or more A11-Registration Request messages to the PDSN with a Lifetime timer value of zero to release each A10 connection (both active and dormant). Accounting data is included in the message. The PCF starts a timer Tregreq associated with each message.
g. The PDSN stores the accounting data for further processing and responds with A11-Registration Reply message(s) with an accept indication for each A11-Registration Request message received to complete the release of the A10 connection(s). The PCF stops the associated timer Tregreq.
149 Section 3
3GPP2 A.S0013-D v2.0
h. The PCF sends an A9-Release-A8 Complete message to the BS. The BS stops timer Trel9. The BS and PCF release all A8 connections for the MS.
1
2
3
4
5
6
i. The BS returns a Clear Complete message to the MSC and includes the Power Down Indicator information element. The MSC releases the underlying transport connection and stops timer T315. This step may occur any time after the traffic channel is released.
3.17.4.8 PDSN Initiated PDSI Release to Inactive/Null State 7
8
9
10
11
12
13
14
15
16
This section presents example call flows associated with a PDSI release initiated by the PDSN. It is assumed that the MS does not have an active voice call in progress.
There are four cases of PDSN initiated inactivation of a PDSI:
1. inactivation of a dormant PDSI
2. inactivation of an active PDSI when other PDSIs are active. In this case the packet data session remains active
3. inactivation of an active PDSI when no other PDSIs are active. In this case, the packet data session becomes dormant or inactive.
4 crossing A11-Registration Request and A11-Registration Update.
3.17.4.8.1 PDSN Initiated Release of a Dormant PDSI 17
18
19
20
In this scenario the PDSN releases the A10 connection associated with a dormant PDSI. However, since there is no communication with the MS, the PDSI may continue to exist in the MS.
= MS BS MSC/VLR PCF PDSN time comment
a
c
f
Active, Dormant or Inactive/Null Packet Data Session
A9-Update-A8
A9-Update-A8 Ack g
h
Tupd9
conditional
conditional
Active or Dormant Packet Data Session
b A11-Registration Update
A11-Registration Ack
A11-Registration Request
A11-Registration Reply Tregreq
Tregupd
d
e
21
22 Figure 3.17.4.8.1-1 PDSN Initiated Service Release of a Dormant PDSI
Section 3 150
3GPP2 A.S0013-D v2.0
a. The packet service instance is dormant. Other PDSIs may exist and be active (active packet data session) or dormant (if all dormant – packet data session is dormant).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
b. An event occurs at the PDSN that requires release of a dormant PDSI. The PDSN initiates release of the associated A10 connection by sending an A11-Registration Update message to the PCF. The PDSN starts timer Tregupd.
c. The PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
d. The PCF sends an A11-Registration Request message with Lifetime set to zero for the PDSI being released, and accounting related information. The PCF starts timer Tregreq.
e. The PDSN stores the accounting related information for further processing before returning an A11-Registration Reply message with an accept indication, and releases the A10 connection for the MS. The PCF also releases the A10 connection. The PCF stops timer Tregreq.
f. If the packet data session is active, the PCF sends an A9-Update-A8 message to the BS to update the number of stored dormant PDSIs in the BS. The PCF starts timer Tupd9.
g. The BS responds with an A9-Update-A8 Ack message to the PCF. The PCF stops timer Tupd9.
h. After the PDSI has been released, the packet data session is active, dormant or inactive/null. If the released service instance was the main service instance, then all other service instances are also released.
151 Section 3
3GPP2 A.S0013-D v2.0
3.17.4.8.2 PDSN Initiated Release of an Active PDSI – Packet Data Session Remains Active
1
2
= MS BS MSC/VLR PCF PDSN time
A9-Disconnect-A8
b
e
f
g
A9-Release-A8
A9-Release-A8 Complete
Tdiscon9
Trel9
h
Service negotiation procedure
A11-Registration Update
A11-Registration Ack
A11-Registration Request
A11-Registration Reply Tregreq
a
c
d
Tregupd
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.17.4.8.2-1 PDSN Initiated Service Release of an Active Packet Service Instance – Packet Data Session Remains Active
a. An event occurs at the PDSN that requires release of an active PDSI. The PDSN initiates release of the associated A10 connection by sending an A11-Registration Update message to the PCF. The PDSN starts timer Tregupd.
b. The PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
c. The PCF sends an A11-Registration Request message with Lifetime set to zero for the PDSI being released, and accounting related information. The PCF starts timer Tregreq.
d. The PDSN stores the accounting related information for further processing before returning an A11-Registration Reply message with an accept indication, and releases the A10 connection for the MS. The PCF also releases the A10 connection. The PCF stops timer Tregreq.
e. When the PCF recognizes that the A10 connection is released, the PCF sends an A9-Disconnect-A8 message to the BS and starts timer Tdiscon9.
f. The BS initiates release of the A8 connection by transmitting an A9-Release-A8 message and starts timer Trel9. The PCF stops timer Tdiscon9.
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
h. Service negotiation procedures take place to dissociate the service instance from the traffic channel. Service negotiation may occur anytime after receipt of the A9-Disconnect-A8 message.
Section 3 152
3GPP2 A.S0013-D v2.0
3.17.4.8.3 PDSN Initiated Release of an Active PDSI – Packet Data Session Becomes Dormant or Inactive
1
2
= MS BS MSC/VLR PCF PDSN time
Clear Request
Clear Command
Clear Complete
A9-Disconnect-A8
a
e
f
g
h
i
j
A9-Release-A8
A9-Release-A8 Complete
k
Tdiscon9
Trel9
T300
T315 TCH
Release
A11-Registration Update
A11-Registration Ack
A11-Registration Request
A11-Registration Reply Tregreq
b
c
d
Tregupd
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Figure 3.17.4.8.3-1 PDSN Initiated Release of an Active PDSI – Packet Data Session Becomes Dormant or Inactive
a. An event occurs at the PDSN that requires release of an active PDSI. The PDSN initiates release of the associated A10 connection by sending an A11-Registration Update message to the PCF. The PDSN starts timer Tregupd. If the Packet Data Session transitions to the Dormant State, then the PCF sends the “All Dormant Indicator” that is part of this release procedure.
b. The PCF responds with an A11-Registration Acknowledge message. Steps ‘f’ through ‘g’ may occur in parallel with steps ‘h’ through ‘j’. The PDSN stops timer Tregupd.
c. The PCF sends an A11-Registration Request message with Lifetime set to zero for the PDSI being released, and accounting related information. The PCF starts timer Tregreq.
d. The PDSN stores the accounting related information for further processing before returning an A11-Registration Reply message with an accept indication, and releases the A10 connection for the MS. The PCF also releases the A10 connection. The PCF stops timer Tregreq.
e. When the PCF recognizes that the A10 connection is released, the PCF sends an A9-Disconnect-A8 message to the BS and starts timer Tdiscon9.
f. The BS initiates release of the A8 connection by transmitting an A9-Release-A8 message and starts timer Trel9. The PCF stops timer Tdiscon9.
153 Section 3
3GPP2 A.S0013-D v2.0
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
h. The BS sends a Clear Request message to the MSC and starts timer T300. The cause value in this message is set to ‘packet call going dormant’ if the session is going to the Dormant State and ‘call processing’ if the session is going to the Null/Inactive State. The Cause Layer 3 value is set to ‘Normal clearing or Normal Unspecified’ in both cases .
i. The MSC sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resources and starts timer T315. The BS stops timer T300.
j. In response to the Clear Command message, the BS releases the traffic channel.
k. The BS returns a Clear Complete message to the MSC. The MSC stops timer T315 and releases the underlying transport connection. This step may occur any time after the traffic channel is released.
3.17.4.8.4 PDSI Clearing – PDSN Initiated (Crossing A11-Registration Request and A11-Registration Update) 15
16
17
18
19
20
21
22
User data traffic is passed over an A10 connections, encapsulated within GRE frames. An event occurs at the PDSN that requires release of the associated PDSI. The PDSN initiates release of the A10 connection with the PCF. At the same time, PCF sends an A11-Registration Request message to the PDSN to perform periodic re-registration for the A10 connection. In this scenario, release of the same A10 connection initiated by the PDSN takes precedence. The traffic channel (if the PDSI being release is the only one) and/or other resources assigned to the call are also released.
Section 3 154
3GPP2 A.S0013-D v2.0
Tregupd
T300
MS BS/PCF MSC time
b
f
g
d
PDSN
A11-Registration Request
h
k
i
j
Clear Command
T315
Clear Request
A11-Registration Update
A11-Registration Acknowledgement
Clear Complete
Tregreq
Service Negotiation or TCH Release
A11-Registration Reply
Packet Data Session Active
Packet Data Session Active, Dormant, or Null
a
l
A11-Registration Request
A11-Registration Reply
Tregreq
c
e
conditional
conditional
conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.17.4.8.4-1 PDSI Clearing – PDSN Initiated (Crossing A11-Registration Request and A11-Registration Update)
a. The MS has a packet data session in the Active State.
b. The PCF sends an A11-Registration Request message with a non-zero Lifetime value to refresh an A10 connection before expiration of that connection’s registration Lifetime timer (Trp). The PCF starts a timer Tregreq associated with the A10 connection. Accounting related and other information may also be included in the A11-Registration Request message.
c. An event occurs at the PDSN that requires release of an active PDSI. The PDSN initiates release of the associated A10 connection by sending an A11-Registration Update message to the PCF, and starts timer Tregupd. This occurs before the PDSN receives the A11-Registration Request message sent by the PCF in step ‘b’.
d. On receipt of A11-Registration Request message for the service instance being released while timer Tregupd is running, the PDSN returns an A11-Registration Reply message with lifetime set to zero. However, the PDSN stores the accounting related and other information (if received) for further processing before returning the A11-
155 Section 3
3GPP2 A.S0013-D v2.0
Registration Reply message. Upon receiving the A11-Registration Reply message, the PCF stops timer Tregreq for the service instance being released.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
e. On receipt of the A11-Registration Update message, irrespective of timer Tregreq condition, the PCF responds with an A11-Registration Acknowledge message. Steps ‘f’ through ‘g’ may occur in parallel with steps ‘h’ through ‘i’. The PDSN stops timer Tregupd.
f. The PCF sends an A11-Registration Request message with Lifetime set to zero for the PDSI being released and accounting related information to the PDSN. The PCF starts timer Tregreq.
g. The PDSN stores the accounting related information for further processing before returning an A11-Registration Reply message with an accept indication and releases the A10 connection. The PCF also releases the A10 connection. The PCF stops timer Tregreq. If the MS has other active PDSIs, steps ‘h’, ‘i’, and ‘k’ are omitted.
h. If the MS has no other active PDSI, the BS sends a Clear Request message to the MSC to initiate clearing of the radio and other resources assigned to the call. The BS starts timer T300.
i. The MSC sends a Clear Command message to the BS, instructing the BS to release the associated resources (including the radio resources). The MSC starts timer T315. Upon receiving the Clear Command message, the BS stops timer T300.
j. If the MS has no other active PDSI, the BS and the MS release the traffic channel and other resources. If the MS has other active PDSIs, the BS initiates service negotiation to dissociate the PDSI from the traffic channel.
k. If a Clear Command message was received in step ‘i’, the BS returns a Clear Complete message to the MSC. The MSC stops timer T315.
l. The packet data session remains in the Active State or transitions to the Dormant State or Null/Inactive State depending on whether the MS has remaining active or dormant PDSIs.
3.17.4.9 Packet Data Session Clearing – MSC Initiated 28
29
30
31
32
An event occurs at the MSC that requires release of the packet data session and release of radio and other resources for the call. The MSC initiates release of all the A8 and the A10 connections associated with the MS. Traffic channel and other resources assigned to the call are also released.
Section 3 156
3GPP2 A.S0013-D v2.0
MS BS MSC/VLR PCF PDSN time
Clear Command
Release Order
Clear Complete
A9-Release-A8 Complete
a
b
c
d
e
f
h
A9-Release-A8
T315
Trel9
Packet Data Session Active
Release Order
Packet Data Session Null/Inactive
i
g
A11-Registration Request
A11-Registration Reply Tregreq
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.17.4.9-1 Packet Data Session Clearing – MSC Initiated
a. The packet data session is active when the MSC determines for some reason to release the call.
b. The MSC sends a Clear Command message to the BS to instruct the BS to release the associated dedicated resources and starts timer T315.
c. The BS initiates release of the traffic channel by sending a Release Order to the MS.
d. The MS acknowledges the Release Order from the BS by returning a Release Order to the BS.
e. The BS then sends an A9-Release-A8 message with a cause value set to “Packet data session release” to the PCF to instruct the PCF to release the dedicated resource associated with all PDSIs (both active and dormant) of the MS, and to release the associated A10 connection(s). The BS uses the SR_ID of any one of the active PDSIs in the A9-Release-A8 message. The BS starts timer Trel9. Steps ‘e’ through ‘h’ may occur in parallel with steps ‘c’ and ‘d’.
f. For each service instance (both active and dormant), the PCF sends an A11-Registration Request message to the PDSN with a Lifetime timer value of zero to release the A10 associated connection. Accounting data is also included in the A11-Registration Request message. The PCF starts a timer Tregreq associated with each A11-Registration Request message sent.
g. The PDSN stores the accounting data for further processing and sends an A11-Registration Reply message with an accept indication for each A11-Registration Request message to complete the release of each A10 connection. The PCF stops the associated timer Tregreq.
h. The PCF then sends an A9-Release-A8 Complete message to the BS. The BS stops timer Trel9. The BS and PCF release all A8 connections for the MS.
157 Section 3
3GPP2 A.S0013-D v2.0
i. The BS returns a Clear Complete message to the MSC. The MSC releases the underlying signaling connection and stops timer T315. Clear Complete may occur any time after the traffic channel is released.
1
2
3
3.17.4.10 MS Initiated PDSI Re-Activation from Dormant State (intra-PCF) 4
5
6
7
8
9
10
Once in the Dormant State, a PDSI is reconnected by the MS by including a packet data specific service option in an Origination Message or an Enhanced Origination Message with DRS bit set to ‘1’. The PPP and MIP sessions need not be re-established. That is, the A10 connection need not be reestablished, and the PCF does not indicate its ANID to the PDSN. In all other respects, this call is no different than a normal A8 connection setup procedure. Refer to section 3.17.4.2 for details.
3.17.4.11 Network Initiated PDSI Re-Activation from Dormant State 11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Once in the Dormant State, a PDSI is reconnected when the PCF sends an A9-BS Service Request message containing a packet data service specific service option to the BS and an SR_ID value identifying the PDSI. The BS acknowledges the request by sending the A9-BS Service Response message to the PCF and initiates a normal BS initiated call setup.
This section describes the call flow examples associated with the establishment of an A8 connection upon Dormant State to Active State transition. In this scenario:
1. The MS has already performed MIP registration (if required) and established a PPP connection with the PDSN.
2. The A8 (User Traffic) connection between the PCF and the BS does not exist.
3. The MS does not have an active voice call in progress.
Note, if the MS performed an intra-PCF dormant mode handoff, the target BS that initiates the A8 connection setup may be different than the source BS that was initially contacted by the PCF.
The PDSN sends data packets to the PCF on an existing A10 connection.
There are two cases of network initiated PDSI reactivation from Dormant State:
1. Reactivation of a PDSI when the packet data session is dormant.
2. Reactivation of a PDSI when the packet data session is active.
Section 3 158
3GPP2 A.S0013-D v2.0
3.17.4.11.1 Network Initiated PDSI Reactivation when the Packet Data Session is Dormant 1
Assignment Complete
MS 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 Tch
Setup
Active Packet Data Session
j
TA8-setup
T303
T10
Packet Data Traffic
A9-BS Service Request
BS Service Request
BS Service Response
A9-BS Service Response
Paging Request
Page Message
BS MSC / VLR PDSN PCF
Tbsreq9T311
T3113
k
l
m
p
q
Dormant Packet Data Session, PPP connection is maintained
n
oA11-Registration Reply
A11-Registration Request
Tregreq
2
3
4
5
6
7
8
9
10
11
12
13
14
Figure 3.17.4.11.1-1 Network Initiated PDSI Re-Activation from Dormant State – Packet Data Session is Dormant
a. The PDSN sends data packets to the PCF on an existing PPP connection and A10 connection associated with a specific MS and dormant PDSI.
b. The PCF sends an A9-BS Service Request message containing the SR_ID identifying the PDSI to the BS to request reactivation of PDSI, and starts timer Tbsreq9.
c. The BS sends a BS Service Request message containing the SR_ID identifying the PDSI to the MSC and starts timer T311.
d. The MSC stores the SR_ID and acknowledges the call setup request by sending a BS Service Response message to the BS. Upon receipt of the BS Service Response message from the MSC the BS stops timer T311.
159 Section 3
3GPP2 A.S0013-D v2.0
e. The BS sends an A9-BS Service Response message to the PCF. The PCF stops timer Tbsreq9 upon receipt of the A9-BS Service Response message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
f. The MSC sends a Paging Request message to initiate PDSI re-activation from dormant and starts timer T3113.
g. The BS issues a Page message containing the MS address over the Paging Channel.
h. The MS acknowledges the page by transmitting a Page Response message over the access channel.
i. The BS constructs the Paging Response message, places it in Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303. The MSC stops timer T3113 upon receipt of the Paging Response message from the BS.
j. The BS acknowledges the receipt of the Page Response message with a BS Ack order to the MS.
k. The MSC sends an Assignment Request message containing the stored SR_ID to the BS to request assignment of radio resources and the A8 (User Traffic) connection between the BS and the PCF. The MSC then starts timer T10.
Upon receipt of the Assignment Request message from the MSC the BS stops timer T303.
l. The BS and the MS perform radio resources setup procedure. The BS uses the SR_ID to identify the PDSI to be re-activated.
m. The BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) connection between the BS and the PCF. The BS starts timer TA8-setup. Note: if the MS performed an intra-PCF dormant mode handoff, the BS sending this message may not be the same BS that was initially contacted by the PCF.
n. The PCF sends an A11-Registration Request message with updated accounting data. Refer to section 3.17.4.25. The PCF starts timer Tregreq.
o. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops timer Tregreq.
p. The PCF responds with an A9-Connect-A8 message to complete the setup of an A8 (User Traffic) connection for this packet service request. If fast handoff is supported, the PCF passes the Anchor P-P Address to the BS as part of this message. In the message, the PCF includes a Service Instance Info information element identifying all dormant PDSIs if any exist. Upon receipt of the A9-Connect-A8 message from the PCF, the BS stops timer TA8-setup.
q. After the radio link and the A8 connection have been established, the BS sends an Assignment Complete message to the MSC. The MSC stops timer T10.
Section 3 160
3GPP2 A.S0013-D v2.0
3.17.4.11.2 Network Initiated PDSI Reactivation when the Packet Data Session is Active 1
Packet Data Traffic
A9-BS Service Request
Tbsreq9
A9-Connect-A8
Active Packet Data Session, Dormant Packet Data Service Instance
Service Instance Active
e
h
i
f
A9-Setup-A8
TA8-setup
A9-BS Service Response
A11-Registration Request
A11-Registration ReplyTregreqg
MS time
a
b
c
d
BS MSC / VLR PDSN PCF
Service negotiation procedures
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.17.4.11.2-1 Network Initiated PDSI Re-Activation from Dormant State – Packet Data Session is Active
a. The PDSN sends data packets to the PCF on an existing A10 connection associated with a specific MS and dormant PDSI.
b. The PCF sends an A9-BS Service Request message containing the SR_ID identifying the PDSI to the BS to request reactivation of PDSI, and starts timer Tbsreq9.
c. The BS responds with an A9-BS Service Response message. The PCF stops timer Tbsreq9 upon receipt of the A9-BS Service Response message.
d. Service negotiation procedures take place to associate the new service instance with the traffic channel.
e. The BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) connection between the BS and the PCF. The BS starts timer TA8-setup.
f. The PCF sends an A11-Registration Request message with updated accounting data. Refer to section 3.17.4.25. The PCF starts timer Tregreq.
g. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops timer Tregreq.
161 Section 3
3GPP2 A.S0013-D v2.0
h. The PCF responds with an A9-Connect-A8 message to complete the setup of an A8 (User Traffic) connection for this PDSI request. Upon receipt of the A9-Connect-A8 message from the PCF, the BS stops timer TA8-setup.
1
2
3
4 i. Packet data flows on the PDSI.
3.17.4.12 Mobile Terminated Packet Data Rejection During a Voice Call 5
6
7
8
9
This procedure is only applicable to the cases that the MS is operating with protocol revision less than 7 or the BS and/or the MSC does not support concurrent voice and packet data services. The following call flow provides an illustration for rejection of packet data termination during a voice call.
A9-BS Service Response(Cause: “MS Busy”)
time
a
b
c
d
e
Dormant packet data session, PPP connection is maintained
Packet Data Traffic
A9-BS Service Request
BS Service Request
BS Service Response
MS BS MSC / VLR PDSN PCF
Tbsreq9T311
voice call
voice call
Dormant packet data session, PPP connection is maintained
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.17.4.12-1 Mobile Terminated Packet Data Rejection During a Voice Call
a. It is assumed that the MS has performed MIP registration (if required) and established a PPP connection. The PDSI is dormant. Packet data arrives at the PDSN and is sent on the A10 connection to the PCF.
b. The PCF sends an A9-BS Service Request message to the BS to request packet service and starts timer Tbsreq9.
c. The BS sends a BS Service Request message to the MSC and starts timer T311.
d. The MSC sends a BS Service Response message with cause value ‘MS busy’ to the BS. The BS stops timer T311 upon receipt of the BS Service Response message.
e. The BS sends an A9-BS Service Response message to the PCF containing the cause value “MS busy”. The PCF stops timer Tbsreq9 upon receipt of the A9-BS Service Response message.
Section 3 162
3GPP2 A.S0013-D v2.0
3.17.4.13 Dormant Handoff (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN 1
2
3
4
5
6
7
To perform dormant handoff of a packet data session, the MS initiates the dormant handoff of each of its dormant PDSIs. The packet data session may become active as a result of the dormant handoff of one PDSI (i.e. PDSN has data to send to the MS over that PDSI) in which case the dormant handoff of the remaining PDSIs occur as given in section 3.17.4.13.2.
3.17.4.13.1 Intra-PDSN Dormant Handoff of a PDSI, While the Packet Data Session is Dormant 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
To obtain packet data services, the MS performs registration(s) with the packet network resulting in the establishment of one or more service instances. The packet data session transitioned to Dormant State. While in the Dormant State the A10 connection for each service instance and the link layer (PPP) connection of the MS are maintained. The source PCF continues to perform re-registrations for the A10 connection with the PDSN by the exchange of A11-Registration Request messages and A11-Registration Reply messages before expiration of A10 connection Lifetime timer Trp.
While in the dormant mode, the MS detects a change of PZID, SID or NID. On detection of a new PZID, SID or NID, and the MS determining that the network needs to be notified, the MS sends an Origination Message (or an Enhanced Origination Message if the dormant handoff of another PDSI forced the packet data session to transition to the Active State) for each PDSI to the target BS that includes the packet data service option and the DRS bit set to ‘0’. The MS sends an origination message with DRS bit set to ‘0’ for each of its dormant PDSIs. The origination messages include the previous PZID, SID and NID when any of these parameters change during the dormant handoff. The target PCF establishes an A10 connection with the PDSN for each service instance. Based on the ANID information (PZID, NID and/or SID) received in the origination message, the target PCF sets the PANID field to the ANID received from the BS and the CANID field to the ANID of the target PCF, and sends this information to the serving PDSN. If the previous PZID, NID, and/or SID were not received from the MS, the PANID field is set to zero. Upon determining that it supports a packet data session for the MS, the serving PDSN compares the received PANID (if non-zero) to the stored CANID and determines that PPP re-negotiation is not required. When the PDSN determines that all A11 registrations corresponding to a packet data session have been successfully processed and the main service instance has been successfully registered, the PDSN updates the stored ANID with the CANID received from the target PCF. If the PDSN has data to send to the MS over a particular service instance, the PDSN returns the ‘Data Available Indicator’ in the CVSE within the A11-Registration Reply message to the BS/PCF for that service instance, resulting in establishment or reconfiguration of the traffic channel. The PDSN releases the A10 connection with the source PCF for each service instance established with the target PCF.
After each A10 establishment the target PCF periodically re-registers with the PDSN by the use of an A11-Registration Request message before that A10 connection Lifetime expires.
To perform dormant handoff of a packet data session, the MS initiates the dormant handoff of each of its PDSIs. The packet data session may become active as the result of the dormant handoff of one PDSI (e.g., the PDSN may have data to send for a PDSI), in which case the dormant handoff of the remaining PDSIs occur as given in section 3.17.4.13.2.
163 Section 3
3GPP2 A.S0013-D v2.0
The following call flow shows the case where the MS sends an Origination Message with the DRS bit set to ‘0’ to handoff a service instance. Since the PDSN already has a PPP session for this MS, PPP negotiation is not required and the traffic channel is not needed in this scenario.
1
2
3
4
Source BS/PCF
MSC time
Origination Message
Base Station Ack Order b
c
f
h
m
n
o
q
p
PDSN Target
BS
Tregreq
Tregreq
Tregupd
MS
Release Order
T303 d
e Assignment Request
CM Service Request
A11-Registration Request
A11-Registration Reply
Clear Command
Assignment Failure
T20
A11-Registration Request
A11-Registration Reply
A11-Registration Acknowledge
A11-Registration Update
Clear Complete
T10
T315
j
k
l
Packet Data Session Dormant, PPP session is maintained a
Packet Data Session Dormant, PPP session is maintained r
Target PCF
TA8-setup
A9-Setup-A8
A9-Release-A8 Complete
g
i
5
6
7
8
9
10
11
12
Figure 3.17.4.13.1-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN), Packet Data Session Dormant
a. It is assumed that the MS has performed a MIP registration (if required) and established a PPP connection with the PDSN but the packet data session is now dormant. The MS does not have an active voice call in progress.
b. On detection of a new PZID, SID or NID, the MS sends an Origination Message with DRS set to ‘0’ to the target BS.
Section 3 164
3GPP2 A.S0013-D v2.0
c. The target BS acknowledges the receipt of the Origination Message with a BS Ack Order to the MS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
d. The target BS constructs a CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC and starts timer T303.
e. The MSC sends an Assignment Request message to the target BS to request assignment of radio resources and starts timer T10. For packet data services, a terrestrial circuit between the MSC and the BS is not required. On receipt of this message the target BS stops timer T303.
f. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the target PCF and starts timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
g. The target PCF sends an A11-Registration Request message to the PDSN. This message includes the Mobility Event Indicator within the CVSE and a non-zero Lifetime. This message also includes Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information (CANID/PANID). The PCF starts timer Tregreq.
h. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. If the PDSN supports fast handoff the Anchor P-P Address is included. If the target PCF does not support fast handoff it ignores the Anchor P-P Address. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF. The target PCF stops timer Tregreq.
If the PDSN responds to the target PCF with the Data Available Indicator, the target BS establishes traffic channels. In this case the remaining steps after step ‘i’ in this call flow are omitted.
i. The target PCF responds to the target BS with an A9-Release-A8 Complete message. The target BS stops timer TA8-setup.
j. The target BS sends the Assignment Failure message to the MSC with the cause value indicating Packet Call Going Dormant and starts timer T20. The MSC stops timer T10.
k. After the MSC has successfully authenticated the MS, it sends a Clear Command message to the target BS with the cause value ‘Do not notify mobile’ and starts timer T315. Upon receipt of the Clear Command the target BS stops timer T20.
l. The target BS may send a Release Order to the MS. This allows the MS to send Origination Messages for remaining PDSIs sooner.
m. The target BS sends a Clear Complete message to the MSC. The MSC stops timer T315.
n. The PDSN initiates release of the A10 connection with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
o. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
p. The source PCF sends an A11-Registration Request message with Lifetime set to zero to the PDSN. The source PCF starts timer Tregreq.
165 Section 3
3GPP2 A.S0013-D v2.0
q. The PDSN sends the A11-Registration Reply message with an accept indication to the source PCF. The source PCF releases the A10 connection for the MS. The source PCF stops timer Tregreq.
1
2
3
4
5
6
7
8
If the MS sends an Origination Message with DRS = 0 for additional dormant service instances (this may occur any time after step ‘l’ or when timer T42m expires for last dormant service instance handed off), this procedure is repeated for each such service instance.
r. The packet data session remains dormant.
3.17.4.13.2 Intra-PDSN Dormant Handoff, while the Packet Data Session is Active 9
10
11
12
If the PDSN indicated that it has data to send on a PDSI that was handed off according to the call flow in the previous sections (refer to section 3.17.4.13.1), any PDSI that has not yet been handed off is handed off according to the following call flow.
A11-Registration Request
A11-Registration Request
timeMS Source BS Target BS MSC
Source PCF
Target PCF
PDSN
Enhanced Origination Message
BS Ack Order
A9-Setup-A8
TA8-setup
A9-Release-A8 Complete
a
b
c
f
Active Packet Data Session
Active Packet Data Session
eTregreq A11-Registration Reply
d
g
h
i
jA11-Registration Reply Tregreq
Tregupd
A11-Registration Update
A11-Registration Ack
13
14
15
16
17
18
19
20
21
Figure 3.17.4.13.2-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN), Packet Data Session Active
a. The MS detected a change in packet zone (while the packet data session was dormant) and sent an Origination Message for a dormant PDSI. The PDSN indicated it had data to send on that PDSI and a traffic channel was assigned (Refer to Call flow 3.17.4.14). The MS sends an Enhanced Origination Message to the target BS with DRS bit set to ‘0’ for another dormant PDSI. If the MS has more than one additional PDSI (besides the active PDSI) it sends an Enhanced Origination with
Section 3 166
3GPP2 A.S0013-D v2.0
DRS bit set to ‘0’ for each of those instances resulting in the execution of this procedure for each such PDSI.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
b. The target BS acknowledges receipt of the Enhanced Origination Message by sending a BS Ack Order to the MS.
c. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the PCF and starts timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
d. The target PCF sends an A11-Registration Request message to the PDSN. This message includes the Mobility Event Indicator within the CVSE and a non-zero Lifetime. This message also includes Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information (CANID/PANID). The PCF starts timer Tregreq.
e. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. If the PDSN supports fast handoff the Anchor P-P Address is included. If the target PCF does not support fast handoff it ignores the Anchor P-P Address. If the PDSN has data to send, it includes the Data Available Indicator within the CVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF. The target PCF stops timer Tregreq.
f. The PCF responds to the BS with an A9-Release A8 Complete message. The BS stops timer TA8-setup.
If the PDSN responds to the target PCF with a Data Available Indicator, the target PCF responds to the target BS with an A9-Connect-A8 message with cause element set to ‘Data ready to send’. In this case, the target BS may initiate service negotiation procedures and continue as in ‘l’-‘o’ in Figure 3.17.4.14-1 so that accounting information can be sent to PDSN.
g. The PDSN initiates release of the A10 connection with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
h. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
i. The source PCF sends an A11-Registration Request message with Lifetime set to zero to the PDSN. The source PCF starts timer Tregreq.
j. The PDSN sends the A11-Registration Reply message with an accept indication to the source PCF. The source PCF releases the A10 connection for the MS. The source PCF stops timer Tregreq.
3.17.4.14 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Inter-PDSN) 36
37
38
39
40
41
42
43
44
This section provides a call flow for the case where an MS with a packet data session in Dormant State moves into a different packet zone and ends up being connected to a different PDSN.
To obtain packet data services, the MS performs registration(s) with the packet network resulting in the establishment of one or more service instances. The packet data session transitioned to dormant mode. While in the Dormant State, the A10 connection of each service instance and the link layer (PPP) connection of the MS are maintained. The source PCF continues to perform re-registrations for the A10 connection with the source
167 Section 3
3GPP2 A.S0013-D v2.0
PDSN by the exchange of A11-Registration Request messages and A11-Registration Reply messages before expiration of the A10 connection Lifetime timer Trp.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
While the packet data session is in dormant mode, the MS detects a change of PZID, SID or NID. On detection of a new PZID, SID, or NID, the MS sends an Origination Message to the target BS that includes the packet data service option and the DRS bit set to ‘0’. The MS sends an Origination or Enhanced Origination Message (if the dormant handoff of another PDSI forced the packet data session to transition to the Active State) with DRS bit set to ‘0’ for each of its dormant PDSIs. The target PCF establishes an A10 connection with the target PDSN for each such service instance. The Origination Messages may contain the ANID information of the previous packet zone, which the target PCF is required to forward as a PANID of the source PCF (if received from the MS) together with its own ANID (CANID) to the serving PDSN. If the previous ANID information is not received from the BS, the PANID field is set to ‘0’. If the target PDSN already has a packet data session for the MS, it compares the received PANID (if set to a non-zero value) and the stored ANID for the MS, and in this example the PDSN determines that PPP re-negotiation is required. When the PDSN determines that all A11 registrations corresponding to a packet data session have been successfully processed and the A10 connection for the main service instance has been successfully set up, the PDSN updates the stored ANID with the CANID received from the target PCF. In the event that multiple service instances are supported, PPP re-negotiation is performed once for the packet data session.
The BS normally does not establish a traffic channel when it receives an Origination Message with DRS bit set to ‘0’. However, in this case, a traffic channel is established if the BS/PCF receives an A11-Registration Reply message from the PDSN for a service instance containing the ‘Data Available Indicator’. Link layer (PPP) re-establishment between the MS and the target PDSN and Mobile IP re-registration (if required) between the MS and the packet network are then performed over the main service instance. The target PCF establishes an A10 connection with the target PDSN for each dormant service instance for which the MS sends Origination or Enhanced Origination with DRS bit set to ‘0’. If user data is available, it is exchanged between the MS and the corresponding node over the new A10 connection(s), encapsulated within GRE frames. The source PDSN releases the A10 connection(s) with the source PCF on expiration of the PPP timer or other events internal to the source PDSN. The target PCF periodically re-registers with the PDSN by the use of the A11-Registration Request message before the A10 connection Lifetime expires.
To handoff a dormant packet data session, the MS initiates the dormant handoff of each of its PDSIs. The packet data session may transition to the Active State as the result for one of the PDSIs (e.g., the PDSN has data to send to the MS over the PDSI), in which case the dormant handoff of the remaining PDSIs occur as shown in section 3.17.4.13.2.
Section 3 168
3GPP2 A.S0013-D v2.0
A9-Connect-A8
Assignment Request
Source BS/PCF
MSC time
Origination Message
Base Station Ack Order b
c
g
h
r
s
t
q
u
Target BS
Tregreq
Tregreq
Tregupd
MS
T303 d
e
CM Service Request
A11-Registration Request
Assignment Complete
A11-Registration Request
A11-Registration Reply
A11-Registration Acknowledge
A11-Registration Update
T10
i
j
p
a
Packet Data Session Active, New PPP Session Established
Source PDSN
Target PDSN
TCH Setup
A11-Registration Reply
l
o
Tregreq
A11-Registration Request
A11-Registration Reply
Target PCF
Packet Data Session Dormant, PPP session is maintained
Establish PPP Connection MIP Registration
A9-Update-A8 Ack
A9-Update-A8
Tupd9
A9-Setup-A8
TA8-setup
f
k
m
n
1
2
3
4
5
6
7
8
9
10
11
Figure 3.17.4.14-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Inter-PDSN)
a. It is assumed that the MS has performed a MIP registration (if required) and established a PPP connection with the PDSN but the packet data session is now dormant. The MS does not have an active voice call in progress.
b. On detection of a new PZID, SID or NID, the MS sends an Origination Message with DRS set to ‘0’ to the target BS.
c. The target BS acknowledges the receipt of the Origination Message with a BS Ack Order to the MS.
d. The target BS constructs a CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC and starts timer T303.
169 Section 3
3GPP2 A.S0013-D v2.0
e. The MSC sends an Assignment Request message to the target BS to request assignment of radio resources and starts timer T10. For packet data services a terrestrial circuit between the MSC and the BS is not required. On receipt of this message the target BS stops timer T303.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
f. The target BS transmits an A9-Setup-A8 message to the target PCF, with DRS=‘0’, to establish an A8 connection and starts timer TA8-setup. The Handoff Indicator of the A9 Indicators IE shall be set to ‘0’.
g. The target PCF initiates establishment of the A10 connection by sending an A11-Registration Request message with non-zero Lifetime value to the target PDSN. The message includes the Mobility Event Indicator within a CVSE and a non-zero Lifetime. This message also includes Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information (CANID/PANID). The target PCF starts timer Tregreq.
h. The A11-Registration Request message is validated and the target PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and Data Available Indicator within a CVSE. If the PDSN supports fast handoff the Anchor P-P Address is included. If the target PCF does not support fast handoff it ignores the Anchor P-P Address. The target PCF stops timer Tregreq.
i. Upon establishment of the A10 connection, the target PCF establishes an A8 connection and transmits an A9-Connect-A8 Message with cause set to ‘Data ready to send’. If fast handoff is supported, the target PCF passes the Anchor P-P Address and the PDSN Address (set to the address of the target PDSN) to the target BS as part of this message. Upon reception of the A9-Connect-A8 message, the target BS stops the timer TA8-setup.
j. The target BS initiates setup of the traffic channel with the MS.
k. The target BS sends the Assignment Complete message to the MSC. The MSC stops timer T10.
l. The target BS sends an A9-Update-A8 message to the target PCF to pass Accounting Parameters and starts timer Tupd9.
m. The target PCF sends an A11-Registration Request message to the target PDSN containing an Airlink Start accounting record. The target PCF starts timer Tregreq.
n. The target PDSN updates the accounting data and returns an A11-Registration Reply message with an accept indication back to the target PCF. The target PCF stops timer Tregreq.
o. The target PCF, upon receipt of the A9-Update-A8 message, responds with an A9-Update-A8 Ack message. Upon receipt of this message, the target BS stops timer Tupd9.
p. The MS and the target PDSN establish the link layer (PPP) connection and then perform the MIP registration procedures (if required) over the link layer (PPP) connection, thereby creating a mobility binding for the MS.
q. The packet data session is active and a new PPP session has been established.
r. On expiration of the PPP timer or other events internal to the source PDSN, the source PDSN initiates release of the A10 connection with the source PCF by sending an A11- Registration Update message. The source PDSN starts timer Tregupd.
s. The source PCF responds with an A11-Registration Acknowledge message. The source PDSN stops timer Tregupd.
Section 3 170
3GPP2 A.S0013-D v2.0
t. The source PCF sends an A11-Registration Request message with Lifetime set to zero. The source PCF starts timer Tregreq.
1
2
3
4
5
6
7
u. The source PDSN stores the accounting related information for further processing before returning an A11-Registration Reply message with an accept indication. The source PCF releases the A10 connection. The source PCF stops timer Tregreq.
3.17.4.15 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN), Packet Data Session is Dormant - Failed Authentication in MSC Following Session Establishment (PDSN Has Data to Send) 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
The following call flow provides an illustration for a handoff of a dormant PDSI during the Dormant State of the packet data session from source PCF to target PCF. The BS does not immediately establish a traffic channel when it receives an origination message with DRS set to ‘0’.
The MSC starts its authentication procedure using the authentication data received in the CM Service Request message and in parallel instructs the BS to assign necessary resources via the Assignment Request message.
The BS communicates with the PCF to set up an A10 connection. The PCF establishes the A10 connection and notifies the BS that a traffic channel and an A8 connection are required. This is a result of the PDSN indicating that it has data to send in the A11-Registration Reply. The BS then sends an Assignment Complete message to the MSC after successful establishment of the traffic channel. Meanwhile, the MSC was still waiting for the authentication results to come back from the authentication center. The results are received indicating that the authentication has failed. The MSC initiates a clearing of the packet data call by sending a Clear Command message with the cause value indicating “Authentication Failure” to the BS. The BS sends an A9-Release-A8 message to the PCF containing a cause value set to ‘Authentication failure’. The PCF initiates the release of all A10 connections
The above scenario is illustrated in the following call flow.
171 Section 3
3GPP2 A.S0013-D v2.0
A9-Release-A8
MSC Target PCF time
a
PDSN MS
Packet Data Session Dormant, PPP connection is maintained
Target BS
Clear Command. (Auth. Failed )
A9-Release-A8Complete
Clear Complete
d
TCH release e
f
g
c
T315
i
j
Dormant Handoff Procedure with Reactivation of the PDSI b
k Packet Data Session Null/Inactive
Packet Data Session Active
Trel9
Source PCF
A11-Registration Request
A11-Registration Reply
Tregreq
h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.17.4.15-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN) - Failed Authentication in MSC Following Session Establishment (PDSN Has Data to Send)
a. It is assumed that the MS has established a PPP connection with PDSN and performed a MIP registration (if required) but is now dormant.
b. The MS detects a change of PZID, SID or NID and initiates a dormant handoff, which results in the reactivation of the PDSI and traffic channel establishment. Refer to section 3.17.4.13.1 (or 3.19.6.1 if the alternate dormant handoff procedure is used). During this step, the MSC requests the target BS to proceed with the handoff before it had authenticated the MS.
c. The packet data session is active. If the MS has additional PDSIs, they may be handed off while the packet data session is active (refer to section 3.17.4.13.2).
d. The MSC receives the authentication result from the authentication center indicating that the authentication has failed, sends a Clear Command message to the target BS indicating that authentication has failed and starts timer T315. This step may occur any time after the MSC requested the target BS to assign a traffic channel to the MS during step ‘c’.
e. The target BS sends a Release Order to the MS indicating “Service Option Rejected”. The MS returns a Release Order to the BS.
f. The target BS informs the target PCF via an A9-Release-A8 message with the cause value set to “Authentication failure”. The target BS uses the SR_ID of any one of the active PDSIs in the A9-Release-A8 message. The target BS starts timer Trel9.
Section 3 172
3GPP2 A.S0013-D v2.0
g. The target PCF initiates release of all A10 connections associated with the MS by sending an A11-Registration Request message to the PDSN with Lifetime value set to ‘0’ for each PDSI. The PCF starts a timer Tregreq associated with each A11-Registration Request message sent.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
h. The PDSN sends an A11-Registration Reply message with an accept indication for each A11-Registration Request message to complete the release of each A10 connection. The PCF stops the associated timer Tregreq.
i. After all A10 connections associated with the MS have been released, the PCF sends an A9-Release-A8 complete message back to the BS. The BS and PCF release all A8 connections for the MS. The BS stops Trel9.
j. The BS sends a Clear Complete message back to the MSC indicating that resources for the packet data call have been released. Upon reception of the message, the MSC stops timer T315.
k. The packet data session is in the Null/Inactive State.
3.17.4.16 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN) - Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have Data to Send) 17
18
19
20
21
22
23
This scenario is similar to the scenario in section 3.17.4.15, except the PDSN does not have data to send. The MSC sends the Assignment Request message to the BS before it has received the authentication results. If authentication of the MS later fails, the MSC sends a Clear Command message to the BS with the “Authentication failure” cause value. The BS then uses the A9-Update-A8 message to alert the PCF that it should tear down the A10 connection for that MS.
173 Section 3
3GPP2 A.S0013-D v2.0
1
MSC Target PCF time comment
a
PDSNSource PCFMS
Packet Data Session Dormant, PPP connection is maintained
Target BS
Release Order
d Clear Command
T20
Clear Complete
T315e
j
k Packet Data Session Null/Inactive
Conditional
MS authentication failure c
A9-Update-A8
A9-Update-A8 Ack
Tupd9
f
g
i
Intra-PDSN Dormant Handoff Procedures b
A11-Registration Request
A11-Registration Reply Tregreq
h
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.17.4.16-1 Dormant Handoff of a PDSI (Inter-BS/Inter-PCF/Intra-PDSN) - Failed Authentication in MSC Following Session Establishment (PDSN Does Not Have Data to Send)
a. It is assumed that the MS has performed a MIP registration (if required) and established a PPP connection with the PDSN but is now dormant.
b. The MS with a dormant packet data session detects a change of PZID, SID or NID and initiates a dormant handoff, which results in the MS being served by the same PDSN. Refer to Figure 3.17.4.13.1-1, steps ‘b’ through ‘j’. During this step, the MSC requests the target BS to proceed with the handoff before it had authenticated the MS. Timer T20 is still running at the target BS.
c. The MSC receives authentication results from the authentication center indicating that authentication has failed.
d. The MSC sends the Clear Command message to the target BS indicating that authentication has failed. The target BS stops timer T20.
e. The target BS sends a Release Order to the MS indicating “Service Option Rejected”.
f. The target BS sends an A9-Update-A8 message with the cause value set to “authentication failure”. The target BS starts timer Tupd9. The target BS uses the SR_ID of any of the dormant service instances in the A9-Update-A8 message.
g. The target PCF initiates release of all A10 connections associated with the MS by sending an A11-Registration Request message to the PDSN with Lifetime value set
Section 3 174
3GPP2 A.S0013-D v2.0
to ‘0’ for each PDSI. The PCF starts a timer Tregreq associated with each A11-Registration Request message sent.
1
2
3
4
5
6
7
8
9
10
11
h. The PDSN sends an A11-Registration Reply message with an accept indication for each A11-Registration Request message to complete the release of each A10 connection. The PCF stops the associated timer Tregreq.
i. Upon completion of the A10 release procedures, the target PCF sends an A9-Update-A8 Ack message to target BS. The target BS stops timer Tupd9.
j. After the resources for the packet data call have been released, the BS sends a Clear Complete message to the MSC. The MSC stops timer T315 upon the receipt of this message.
k. The packet data session is in the Null/Inactive State.
3.17.4.17 Soft / Softer Handoff Packet Data 12
13
14
Call flows for soft/softer handoff of the FCH, DCCH, and SCH are explained in section 3.19.2.
3.17.4.18 Hard Handoff (Inter-BS/Intra-PCF/Intra-PDSN) 15
16
17
18
19
The following call flow provides an illustration for a successful hard handoff event during packet data services. To simplify the diagram, it is assumed that for purposes of this example, the packet call is not in inter-BS soft/softer handoff prior to the handoff, and no other service options are connected.
175 Section 3
3GPP2 A.S0013-D v2.0
MS Source BS MSC time
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 A8 Complete
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
A9-Setup-A8
A9-Release-A8 Complete
u
v
TA8-setup
T11
T8
Taldak
1
2
3
4
5
6
7
8
9
10
11
12
Figure 3.17.4.18-1 Hard Handoff (Inter-BS/Intra-PCF/Intra-PDSN)
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends cdma2000 to cdma2000 hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7. The Service Configuration Record in this message identifies the active PDSIs. The Service Option List information element identifies all PDSIs of the MS (both active and dormant).
b. The MSC sends a Handoff Request message to the target BS and starts timer T11. Note the target BS determines which PDSIs are dormant by comparing this list with the list of packet data active service options in the Service Configuration Record.
Section 3 176
3GPP2 A.S0013-D v2.0
c. For each active PDSI, the target BS sends an A9-Setup-A8 message to the PCF to establish the A8-Connection and starts timer TA8-setup. In this case, the handoff indicator field of the A9-Setup-A8 message is set to ‘1’.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
d. Upon receipt of each A9-Setup-A8 message from the target BS, the PCF establishes the A8 connection. At this point of time, the PCF continues to forward packet data received from PDSN to the source BS (i.e., the target BS doesn’t receive packet data from the PCF). For each A9-Setup-A8 message it receives, the PCF sends an A9-Connect-A8 message to the BS. The PCF starts timer Twaitho9 for each A9-Connect-A8 message sent and waits for the A9-AL Connected message. When the target BS receives the A9-Connect-A8 message it stops timer TA8-setup.
The establishment of the A10 connection is not performed because this is an intra-PCF handoff.
e. The target BS sends a Handoff Request Acknowledgment message to the MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio channel. Upon receipt of the Handoff Request Acknowledgement message the MSC stops timer T11.
f. The MSC prepares to switch the MS from the source BS to the target BS. The MSC sends a Handoff Command message to the source BS. The source BS stops timer T7.
g. The PCF stops packet transmission for the MS to the source BS upon receipt of A9-AL (Air Link) Disconnected message from source BS. At this point in time, the source BS starts timer Tald9.
h. The PCF sends an A9-AL Disconnected Ack message in response to the A9-AL Disconnected message and starts timer Taldak. The source BS stops timer Tald9.
i. The source BS sends the General Handoff Direction Message or Universal Handoff Direction Message to the MS and starts timer T8. If the MS is allowed to return to the source BS, then timer Twaitho is started by the source BS.
j. The MS may acknowledge the General Handoff Direction Message or Universal Handoff Direction Message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message.
If the General Handoff Direction Message or Universal Handoff Direction Message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
k. The source BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the target BS channel. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been started, the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
l. The MS sends a Handoff Completion message to the target BS. The target BS detects that the MS has successfully accessed the target BS and stops timer T9. However, if timer T9 expires before the target BS detects that the MS has successfully accessed the target BS, the target BS shall send a Handoff Failure message to the MSC. Refer to [14] for detailed procedures.
m. The target BS sends the BS Ack Order to the MS over the air interface.
n. Upon the receipt of the Handoff Completion message from MS, the target BS sends an A9-AL Connected message to the PCF and starts timer Talc9. The PCF stops timer Twaitho9, updates its routing table to route packet data sent from the PDSN to the target BS, and restarts packet data transmission to the target BS. In this case, PCF
177 Section 3
3GPP2 A.S0013-D v2.0
does not perform the A10 connection establishment procedure because the A10 connection has already been established.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
o. The PCF sends the A9-AL Connected Ack message as the response to the A9-AL Connected message. The target BS stops timer Talc9.
p. The target BS sends a Handoff Complete message to the MSC to notify it that handoff has been successfully completed.
q. The MSC sends a Clear Command message to the source BS and starts timer T315. The source BS stops timer T306.
r. For each A8 connection, the source BS sends an A9-Release-A8 message to the PCF to release the A8-Connection and starts timer Tre19. The PCF stops timer Taldak.
s. Upon the receipt of each A9-Release-A8 message from the source BS, the PCF releases the A8-Connection and responds with an A9-Release-A8 Complete message. Upon receiving the A9-Release-A8 message the source BS stops timer Tre19.
t. The source BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315. This step may occur any time after the traffic channel is released.
u. For each dormant PDSI (if any), the target BS sends an A9-Setup-A8 message to the PCF with Data Ready Indicator set to ‘0’ and starts an associated timer TA8-setup. The message also includes the ANID of the PCF. Steps ‘u’ – ‘v’ may occur any time after step ‘l’.
v. The target PCF determines that no A11 procedures are needed since an A10 connection already exists for each dormant PDSI and the handoff is within the same PCF (based on the received ANID information). The target PCF returns an A9-Release-A8-Complete message as a response to each A9-Setup-A8 message. The target BS stops the associated TA8-setup timer for each A9-Setup-A8 message.
3.17.4.19 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN) 27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
The following call flow provides an illustration for a successful hard handoff event from a cdma2000 system to another cdma2000 system during packet data services. In this scenario, it is assumed that the source and target PCF are both served by the same PDSN. To simplify the diagram, it is assumed that for purposes of this example, the packet call is not in inter-BS soft/softer handoff prior to the handoff, and no other service options are connected. This call flow shows the case of hard handoff without fast handoff. For fast handoff, refer to the call flow in section 3.19.4.
To obtain packet data services, the MS performs registration with the packet network. The traffic channel is assigned and an A10 connection for each service instance of the MS is established between the source PCF and the PDSN. This results in establishment of the link layer (PPP) connection and Mobile IP registration (if required) with the serving packet network. The source PCF continues to perform re-registrations for each A10 connection with the PDSN by the exchange of A11-Registration Request messages and A11-Registration Reply messages before expiration of A10 connection Lifetime timer Trp.
The MS moves into the coverage area of a target BS resulting in a hard handoff. The ANID of the source PCF is communicated by the source BS to the target BS via the Handoff Required/Request messages and is subsequently sent to target PCF via the A9-
Section 3 178
3GPP2 A.S0013-D v2.0
AL-Connected message. The target PCF inserts its ANID (CANID) and communicates both sets of access network identifiers to the PDSN.
1
2
3
4
5
6
7
8
9
10
After exchange of appropriate messages between the MSC, the source BS and the target BS, the MS is acquired by the target BS. The target PCF establishes an A10 connection with the PDSN for each service instance (both active and dormant) handed off. User data is exchanged between the MS and the corresponding node over the new A10 connection(s), encapsulated within GRE frames. The PDSN releases the A10 connection(s) with the source PCF associated with each service instance handed off to target PCF. The target PCF periodically re-registers with the PDSN by the use of the A11-Registration Request message before the A10 connection Lifetime expires.
179 Section 3
3GPP2 A.S0013-D v2.0
MS Source BS MSC time
a
b
c
d
e
f
g
Handoff Required
Handoff Request
h
j
i
k
l
m
n
Twaitho
x
Source PCF PDSN
A9-Setup-A8
A9-Connect-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
o
q
r
s
Target PCF
Target BS
t
u
A9-AL Disconnected
v
A9-AL Disconnected AckTald9
TA8-setup
Tre19
A9-Setup-A8
A9-Release-A8-Complete
w
z
bb
T8
A11-Registration Request
A11-Registration Reply Tregreq p
aa
A11-Registration Update
A11-Registration Ack
A11-Registration Request
A11-Registration ReplyTregreq
x
y
Tregupd
T7
T9
Talc9
Taldak
T306
TA8-setup
Twaitho9
T315
cc
dd
ee
ff
gg
hh
A11-Registration Request
A11-Registration Reply Tregreq
A11-Registration Update
A11-Registration Ack Tregupd
A11-Registration Request
A11-Registration ReplyTregreq
1
2 Figure 3.17.4.19-1 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN)
Section 3 180
3GPP2 A.S0013-D v2.0
a. Based on an MS report that it crossed a network specified threshold for signal strength, changes to a different ANID or for other reasons, the source BS recommends cdma2000 to cdma2000 hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7. The source BS includes the ANID information of the source PCF in the Handoff Required message. The Service Configuration Record in this message identifies the active PDSIs. The Service Option List information element identifies all PDSIs of the MS (both active and dormant).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
b. The MSC sends a Handoff Request message (which includes the ANID information previously communicated to the MSC via the Handoff Required message) to the target BS. Note the target BS determines which PDSIs are dormant by comparing this list with the list of active service options in the Service Configuration Record.
c. For each active PDSI, the target BS sends an A9-Setup-A8 message to the target PCF to establish the A8 connection and starts timer TA8-setup. In this case, the handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during handoff).
d. Upon receipt of each A9-Setup-A8 message from the target BS, the target PCF establishes the A8 connection. At this point of time, the PDSN continues to forward packet data to the source BS via source PCF. (i.e., target BS and target PCF don’t receive packet data from the PDSN.) For each A9-Setup-A8 message it receives, the target PCF sends an A9-Connect-A8 message to the target BS. The target PCF starts timer Twaitho9 for each A9-Connect-A8 message sent and waits for the A9-AL Connected message. When the target BS receives the A9-Connect-A8 message it stops timer TA8-setup.
The establishment of the A10 connection is not performed because the handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during handoff).
e. The target BS sends a Handoff Request Acknowledgment message to the MSC. The target BS starts timer T9 to wait for the arrival of the MS on its radio channel.
f. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The source BS stops timer T7.
g. The source PCF stops packet transmission for the MS to the source BS upon receipt of A9-AL Disconnected message from the source BS. At this point of time, the source BS starts timer Tald9.
h. The source PCF sends the A9-AL Disconnected Ack message as a response to the A9-AL Disconnected message and starts timer Taldak. The source BS stops timer
Tald9.
i. The source BS instructs the MS to handoff by sending the handoff direction message (HDM, GHDM, EHDM, UHDM) and starting timer T8. If the MS is allowed to return to the source BS, then timer Twaitho is started by the source BS.
j. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message. If the General Handoff Direction Message or Universal Handoff Direction Message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
k. The source BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the target BS channel. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been
181 Section 3
3GPP2 A.S0013-D v2.0
started, the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
l. The MS sends a Handoff Completion Message to the target BS. The target BS detects that the MS has successfully accessed the target BS and stops timer T9. However, if timer T9 expires before the target BS detects that the MS has successfully accessed the target BS, the target BS shall send a Handoff Failure message to the MSC. Refer to [14] for detailed procedures.
m. The target BS sends the BS Ack Order to the MS over the air interface.
n. Upon the receipt of the Handoff Completion message from the MS, the target BS sends an A9-AL Connected message, including the ANID received previously in the Handoff Request message, to the target PCF and starts timer Talc9. The target PCF stops timer Twaitho9.
o. The target PCF sends an A11-Registration Request message with a non-zero Lifetime value and with a Mobility Event Indicator within the CVSE to the PDSN for the active service instance of the MS. The message includes Accounting Data (R-P Session Setup Airlink Record) within a CVSE. It also includes the ANID of the source PCF (in the PANID field) received in the Handoff Request message and the ANID of the target PCF (in the CANID field) in an ANID NVSE. The PCF starts timer Tregreq.
p. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. If the PDSN has data for the MS, it responds to the PCF with an A11-Registration Reply message with the Data Available Indicator in the CVSE. The A10 connection binding information at the PDSN for the service instance is updated to point to target PCF. The target PCF stops timer Tregreq.
q. The PDSN initiates release of the old A10 connections associated with the MS at the source PCF by sending an A11-Registration Update message. The PDSN starts the timer Tregupd.
r. The source PCF responds with an A11-Registration Acknowledge message for the A11-Registration Update message received. The PDSN stops the associated timer Tregupd.
s. The source PCF sends an A11-Registration Request message with Lifetime set to zero, and accounting related information to the PDSN for the A10 connection to be cleared. The source PCF starts the timer Tregreq.
t. The PDSN stores the accounting related information for further processing before returning an A11-Registration Reply message with an accept indication. The source PCF releases the A10 connection for the MS. The source PCF stops the associated timer Tregreq.
u. The target PCF sends the A9-AL Connected Ack message in response to the A9-AL Connected message and stops timer Talc9. If timer Talc9 expires, the target BS may resend the A9-AL Connect message.
v. The target BS sends a Handoff Complete message to the MSC to indicate that the handoff was successfully completed.
w. The MSC sends a Clear Command message to the source BS and starts timer T315. The source BS stops timer T306.
Section 3 182
3GPP2 A.S0013-D v2.0
x. For each A8 connection, the source BS sends an A9-Release-A8 message to the source PCF to release the A8 connection and starts timer Tre19. The source PCF stops timer Taldak.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
y. Upon the receipt of each A9-Release-A8 message from the source BS, the source PCF releases the A8 connection and responds with an A9-Release-A8 Complete message. When the source BS receives the A9-Release-A8 Complete message it stops timer Tre19.
z. The source BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315. This step may occur any time after the traffic channel is released.
aa. For each dormant PDSI (if any), the target BS sends an A9-Setup-A8 message to the PDSN with Data Ready Indicator set to ‘0’ and starts an associated timer TA8-setup. Steps ‘aa’ through ‘hh’ may occur any time after step ‘l’.
bb. The target PCF sends an A11-Registration Request message to the PDSN. This message includes the Mobility Event Indicator within the CVSE and a non-zero Lifetime. This message also includes Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information (CANID/PANID). The PCF starts timer Tregreq.
cc. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The target PCF stops timer Tregreq.
dd. The target PCF sends an A9-Release-A8-Complete message as a response to the A9-Setup-A8 message. The target BS stops the TA8-setup timer.
ee. The PDSN initiates release of the A10 connections associated with the MS at the source PCF by sending an A11-Registration Update message. The PDSN starts an associated timer Tregupd.
ff. The source PCF responds with an A11-Registration Acknowledge message for the A11-Registration Update message received. The PDSN stops the associated timer Tregupd.
gg. The source PCF sends an A11-Registration Request message with Lifetime set to zero, and accounting related information to the PDSN for the A10 connection to be cleared. The source PCF starts an associated timer Tregreq.
hh. The PDSN stores the accounting related information for further processing before returning an A11-Registration Reply message with an accept indication. The source PCF releases the A10 connection for the MS. The source PCF stops the associated timer Tregreq.
3.17.4.20 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN) With Return On Failure 37
38
39
40
41
42
The following call flow provides an illustration for a hard handoff event from a cdma2000 system to another cdma2000 system. In this scenario, the MS successfully returns to the source BS after hard handoff fails. It is assumed that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no inter-BS connections need to be removed.
183 Section 3
3GPP2 A.S0013-D v2.0
MS Source BS MSC time
a
b
c
d
e
f
g
Handoff Required
Handoff Request
T9
h
j
i
k
l
m
n
T315
Twaitho
Source PCF
PDSN
A9-Setup-A8
A9-Connect-A8
Handoff Request Ack
Handoff Command
GHDM / UHDM
CF Search Report
Message
T7
Clear Command
A9-Release-A8
A9-Release-A8 Complete
Clear Complete
MS Ack Order
Target PCF
Target 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
TaldakT8
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.17.4.20-1 Hard Handoff (Inter-BS/Inter-PCF/Intra-PDSN) With Return On Failure
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends cdma2000 to cdma2000 hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7. The Service Configuration Record in this message identifies the active PDSIs. The Service Option List information element identifies all PDSIs of the MS (both active and dormant).
b. The MSC sends a Handoff Request message to the target BS. Note the target BS determines which PDSIs are dormant by comparing this list with the list of active packet data service options in the Service Configuration Record.
c. For each active PDSI, the target BS sends an A9-Setup-A8 message to the target PCF to establish the A8 connection and starts timer TA8-setup. In this case, the handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during handoff).
d. Upon receipt of each A9-Setup-A8 message from the target BS, the target PCF establishes the A8 connection. At this point in time, the PDSN continues to forward packet data to the source BS via the source PCF (i.e. the target BS and target PCF don’t receive packet data from the PDSN). For each A9-Setup-A8 message it receives, the target PCF sends an A9-Connect-A8 message to the BS. The target PCF starts timer Twaitho9 for each A9-Connect-A8 message sent and waits for the A9-AL
Section 3 184
3GPP2 A.S0013-D v2.0
Connected message. When the target BS receives the A9-Connect-A8 message it stops timer TA8-setup.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
The establishment of the A10 connection is not performed because the handoff indicator field of the A9-Setup-A8 message is set to ‘1’ (during handoff).
e. The target BS sends a Handoff Request Acknowledgment message to the MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio channel.
f. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The source BS stops timer T7.
g. Upon receipt of the Handoff Command message, the source BS sends the A9-AL Disconnected message to the source PCF and starts timer Tald9. The source PCF stops packet data transmission for the MS to the source BS upon receipt of the A9-AL Disconnected message from the source BS.
h. The PCF sends the A9-AL Disconnected Ack message as a response of the A9-AL Disconnected message and starts timer Taldak. Upon receipt of this message, the
source BS stops timer Tald9.
i. The source BS sends the General Handoff Direction Message or Universal Handoff Direction Message to the MS and starts timer T8. Because the MS is allowed to return to the source BS, timer Twaitho is started by the source BS.
j. The MS may acknowledge the General Handoff Direction Message or Universal Handoff Direction Message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message.
If the General Handoff Direction Message or Universal Handoff Direction Message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
k. The MS sends a Candidate Frequency (CF) Search Report Message to the source BS after handoff to the target has failed.
l. Upon receipt of the CF Search Report Message, the source BS sends the A9-AL Connected message to the source PCF and starts timer Talc9. The source PCF stops timer Taldak.
m. The source PCF sends an A9-AL Connected Ack message to the source BS. The source PCF restarts packet data transmission for the MS over existing A8 connection(s) upon receipt of the A9-AL Connected message from the source BS. The source BS stops timer Talc9.
n. The source BS sends a Handoff Failure message to the MSC with cause value set to ‘Reversion to old channel’.
o. The MSC sends a Clear Command message to the target BS and starts timer T315. The target BS stops timer T9.
p. Upon receipt of the Clear Command message from the MSC, the target BS releases and deallocates radio resources. The target BS sends an A9-Release-A8 message to the target PCF for each active PDSI to instruct it to release the associated dedicated resources and starts timer Tre19. The target PCF stops timer Twaitho9.
q. Upon the receipt of each A9-Release-A8 message from the target BS, the target PCF releases resources and responds with an A9-Release-A8 Complete message. When the target BS receives an A9-Release-A8 Complete message it stops the associated timer Tre19.
185 Section 3
3GPP2 A.S0013-D v2.0
r. The target BS sends a Clear Complete message to the MSC. The MSC stops timer T315.
1
2
3.17.4.21 Inter-BS Hard Handoff – Mobile Served by a New Target PDSN 3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
To obtain packet data services, the MS performs registration with the packet network. The traffic channel is assigned and an A10 connection for each service instance of the MS is established between the source PCF and the source PDSN on behalf of the MS. This results in establishment of the link layer (PPP) connection and Mobile IP registration (if required) with the serving packet network. The source PCF continues to perform re-registrations for each A10 connection with the source PDSN by the exchange of A11-Registration Request messages and A11-Registration Reply messages before expiration of A10 connection Lifetime timer Trp.
The MS moves into the coverage area of a target BS resulting in a hard handoff. After exchange of appropriate messages between the MSC and the source BS, the MS is acquired by the target BS. The target PCF establishes an A10 connection with the target PDSN for each service instance (both active and dormant) handed off. Link layer (PPP) establishment between the MS and target PDSN and Mobile IP re-registration (if required) between the MS and the packet network may then be performed over the main service instance. The target PCF populates the PANID and CANID fields of the ANID NVSE and sends it to the target PDSN. User data is exchanged between the MS and the corresponding node over the new A10 connection(s), encapsulated within GRE frames. The source PDSN releases the A10 connection(s) with the source PCF on expiration of the Lifetime timer (Trp) or other events internal to the PDSN. The target PCF periodically re-registers with the target PDSN by the use of the A11-Registration Request message before the A10 connection Lifetime expires.
Section 3 186
3GPP2 A.S0013-D v2.0
x
MS Source BS/PCF
time
Handoff Required
Handoff Request
a
b
c
d
e
f
Null forward traffic channels Frames Handoff Request
Ack
g
h
i
k
m
j
A11-Registration Update
A11-Registration Request
A11-Registration Reply
User Data Transmission
A11-Registration Acknowledge
A11-Registration Reply
n
p
r
t
q
u
v
s
Handoff Command
T7
Extended/General Handoff Direction Message
MS Ack Order
Twaitho
Handoff Commenced
l
Reverse Traffic Channel Preamble or Data
Handoff Completion Message
Clear Complete
Clear Command
A11-Registration Request
T9
T315
T306
MSC
Tregreq
Tregupd
Tregreq
BS Ack Order
Target BS/PCF
Target PDSN
Source PDSN
T11
Service Negotiation o*
Handoff Complete
T8
* conditional
1
2
3
4
5
Figure 3.17.4.21-1 Inter-BS Hard Handoff – Mobile Served by New Target PDSN
a. On detection of a condition that a hard handoff is required, the source BS sends a Handoff Required message to the MSC with a preferred list of target cells, and starts timer T7. The source BS includes the ANID of the source PCF. The Service
187 Section 3
3GPP2 A.S0013-D v2.0
Configuration Record in this message identifies the active service instances and the Service Option List information element identifies all service instances.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
b. The MSC sends a Handoff Request message to the target BS, which includes the ANID received from the source BS, and starts timer T11. The target BS determines which service instances are dormant by comparing these two lists.
c. Upon receipt of the Handoff Request message, the target BS allocates suitable idle (radio) resources. The BS starts transmitting null TCH data on the forward traffic channel for the MS.
d. The target BS returns a Handoff Request Ack message to the MSC with appropriate RF channel information to allow the MS to be instructed to tune to the new RF channel, and starts timer T9 to wait for the MS to arrive on the radio channel. Upon receipt of the Handoff Request Ack message from the target BS, the MSC stops timer T11.
e. The MSC prepares to switch the MS from source BS to target BS. The MSC sends a Handoff Command message to the source BS containing the appropriate RF channel information received from the target BS. Upon receipt of the Handoff Command message, the source BS stops timer T7.
f. The source BS instructs the MS to handoff by sending a handoff direction message (HDM/GHDM/EHDM/UHDM) and starting timer T8. If the MS is allowed to return to the source BS timer Twaitho is started by the source BS.
g. The MS acknowledges receipt of the handoff direction message by sending an MS Ack Order message to the source BS. The source BS stops timer T8 upon receipt of this message.
h. Upon receipt of confirmation from the MS, the source BS sends a Handoff Commenced message to the MSC. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been started, the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
i. The MS starts sending reverse TCH frames or preamble data to the target BS.
j. Upon synchronization of the traffic channel, the MS sends a Handoff Completion Message to the target BS. The target BS detects that the MS has successfully accessed the target and stops timer T9.
k. The target BS acknowledges receipt of the Handoff Completion Message by sending a BS Ack Order to the MS.
l. The target PCF selects the target PDSN for this call and sends an A11-Registration Request message with a non-zero Lifetime value and with Mobility Event Indicator within a CVSE to the target PDSN for each active and dormant service instance of the MS. This message also includes Accounting Data (A10 Connection Setup Airlink Record). This message also includes the PANID the target PCF received in the Handoff Request message and the target PCF’s CANID; both are included within an NVSE. The target PCF starts a timer Tregreq associated with the A11-Registration Request message sent for each service instance.
m. Each A11-Registration Request message is validated and the target PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The first A11-Registration Reply message also contains a Data Available Indicator within a CVSE. The target PCF stops the associated timer Tregreq.
n. The target BS then sends a Handoff Complete message to the MSC indicating successful completion of hard handoff.
Section 3 188
3GPP2 A.S0013-D v2.0
o. If the PDSN indicates that it has data available for the MS on a service instance that is dormant, the BS initiates service negotiation with the MS to reconnect the dormant service instance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
p. The link layer (PPP) connection between the MS and the target PDSN is established and the MS performs MIP registration (if required) with the packet network over the main service instance. User data is exchanged between the MS and the corresponding node over the A10 connection(s).
q. Upon receipt of the Handoff Complete, the MSC initiates release of the MSC resources used in the handoff. MSC then sends a Clear Command message to the source BS, informing it of the success of the hard handoff. The source BS stops timer T306. The MSC starts timer T315.
r. The source BS sends a Clear Complete message to the MSC acknowledging success of the handoff. MSC stops timer T315 on receipt of the Clear Complete message.
s. On expiration of the PPP timer or other events internal to it, the source PDSN initiates closure of each A10 connection with the PCF by sending an A11-Registration Update message. The source PDSN starts an associated timer Tregupd.
Note: The source BS/PCF may initiate tear down of the A10 connections after receiving the Clear Command (in step ‘q’).
t. The source PCF responds with an A11-Registration Acknowledge message to each A11-Registration Update message. The source PDSN stops associated timer Tregupd.
u. The source PCF sends an A11-Registration Request message with Lifetime set to zero, and accounting related information to the source PDSN for each service instance for which A11-Registration Update is received. The source PCF starts an associated timer Tregreq.
v. The source PDSN stores the accounting related information for further processing before returning the A11-Registration Reply message with an accept indication for each A11-Registration Request message received. The source PCF releases the associated A10 connection(s) for the MS. The source PCF stops the associated timer(s) Tregreq for each A11-Registration Request message.
3.17.4.22 MS Initiated Call Release to Null State 30
31
32
33
34
35
36
37
This section presents example call flows associated with an MS deactivation of a PDSI (Active-to-Null State Transition) initiated by the MS. To simplify the diagram, it is assumed that for purposes of this example, the packet call is not in inter-BS soft/softer handoff prior to the deactivation.
There are two cases for MS Initiated PDSI Release to Null State:
1. MS Initiated Release when no other PDSI is Active
2. MS Initiated Release when other PDSI(s) are Active.
189 Section 3
3GPP2 A.S0013-D v2.0
3.17.4.22.1 MS Initiated PDSI Release to the Inactive/Null State when no other PDSI is Active
1
2
Release Order
MS BS MSC/VLR PCF PDSN time
a
b
e
h
A9-Release-A8
Trel9 g
c
dTCH
Release Procedure
Active Packet Data Service Instance / Active Packet Data Session
Packet Data Session Released / in Null state
A9-Release-A8 Complete
T300
T315
Clear Request
Clear Command
Clear Completei
j
A11-Registration Request
A11-Registration Reply Tregreq f
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Figure 3.17.4.22.1-1 MS Initiated PDSI Release to Null State When No Other PDSI is Active
a. If the PDSI becomes inactive at the MS (transition to Null State), the MS requests the BS to disconnect the traffic channel. The MS sends a Release Order with ORDQ=2 (Service Inactive) to the BS to request a transition to the Null State.
b. The BS sends a Clear Request message to the MSC with cause value set to ‘call processing’ and Cause Layer 3 set to ‘Normal clearing/Normal Unspecified’ to initiate the call clear transaction, and starts timer T300.
c. The MSC sends a Clear Command message to the BS to instruct the BS to release the dedicated resources associated with the PDSI and starts timer T315. The BS stops timer T300.
d. In response to the Clear Command message, the BS initiates call clearing over the air interface by transmitting a Release Order.
e. The BS sends an A9-Release-A8 message, with cause value set to ‘Normal call release’, to the PCF to instruct the PCF to release the dedicated resources associated with the PDSI and its A10 connection. The BS starts timer Trel9.
f. The PCF initiates release of the A10 connection by sending an A11-Registration Request message to the PDSN with Lifetime value set to ‘0’ and starts timer Tregreq.
g. The PDSN sends an A11-Registration Reply message with an accept indication to complete the release of the A10 connection and stops timer Tregreq.
h. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
Section 3 190
3GPP2 A.S0013-D v2.0
i. The BS returns a Clear Complete message to the MSC. The MSC releases the underlying transport connection and stops timer T315. This step may occur any time after the traffic channel is released.
1
2
3
4
5
6
7
j. The PDSI in the MS goes to the Null State and the PDSI is released in the BS/PCF/PDSN.
3.17.4.22.2 MS Initiated PDSI Release to the Inactive/Null State when other PDSI(s) are Active 8
RRRM / RRRMM
MS BS MSC/VLR PCF PDSN time
a
b
e
h
A9-Release-A8
Trel9
g
c
d
Service Negotiation Procedure
Packet Data Session Active / PPP connected
Packet Data Session Active / PPP connected
A9-Release-A8 Complete
f
A11-Registration Request
A11-Registration Reply Tregreq
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.17.4.22.2-1 MS Initiated PDSI Release to Inactive/Null State When Other PDSIs are Active
a. The MS is exchanging data on a PDSI.
b. The MS sends an RRRM or RRRMM message with Purge Indicator set to ‘1’ to the BS to request a transition of the active PDSI to the Inactive/Null State. The ‘CON_REF’ parameter in the message allows the BS to determine the SR_ID of the affected PDSI.
c. Service negotiation procedures take place to dissociate the service instance from the traffic channel.
d. The BS sends an A9-Release-A8 message to the PCF to instruct the PCF to release the associated dedicated resources and starts timer Trel9. The cause code in this message is set to “Normal call release”.
191 Section 3
3GPP2 A.S0013-D v2.0
e. The PCF initiates release of the A10 connection by sending an A11-Registration Request message to the PDSN with Lifetime value set to ‘0’ and starts timer Tregreq.
1
2
3
4
5
6
7
f. The PDSN sends an A11-Registration Reply message with an accept indication to complete the release of the A10 connection and stops timer Tregreq.
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
h. At this point, the PDSI is considered to be in the Inactive/Null State.
3.17.4.23 Dormant MS Power Down, A10 Release Initiated by the MSC/BS 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
An MS with a dormant packet data session and an active PPP session to a PDSN powers down. A power down registration message is sent to the BS. Since the packet data session is dormant, there is no A8 connection between the BS and the PCF for this MS. Refer to section 3.17.4.7 for Active MS Power Down.
The BS sends a Location Updating Request message to the MSC indicating power down registration. The MSC, which previously received an Assignment Failure or a Clear Request message with cause “Packet call going dormant” (and therefore has the option of retaining the state of the packet data session), may respond with a Location Updating Accept message. In this situation, the following occurs:
The response includes a cause value set to ‘Power down from dormant state’ informing the BS that a packet call was dormant.
Using the indicator, the BS triggers an A9-Update-A8 message to the PCF indicating in the Cause information element that the MS has powered down. The BS may also send this message to the PCF on its own.
The PCF starts releasing the A10 connection of each PDSI of the MS by sending an A11-Registration Request message. Procedures for releasing all A10 connections associated with the MS and removing mobility management information from the PDSN are performed.
Section 3 192
3GPP2 A.S0013-D v2.0
Registration Acknowledge
BS MS MSC PCF PDSN
b
f
h
A9-Update-A8
A9-Update-A8 Ack
Active PPP session a
Location UpdatingRequest
Registration (power down)
d
c
e
i
Location. Updating Accept
(Release indicator)
time
Tupd9
T32
A11-Registration Request
A11-Registration Reply Tregreqg
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.17.4.23-1 Dormant MS Power Down, A10 Release Initiated by the MSC/BS
a. An active PPP session exists between an MS with a dormant packet data session and the PDSN (no data transferred over the PPP session).
b. The dormant MS powers down. A power down registration is sent to the BS.
c. The BS sends a Location Updating Request message to the MSC indicating that the MS has powered down. The BS starts timer T3210.
d. If the MSC is aware that the packet data session is dormant, the MSC sends a Location Updating Accept message with a cause value set to “Power down from dormant state” to inform the BS that a dormant packet data session is to be released. The BS stops timer T3210.
e. The BS sends a Registration Acknowledgement Message to the MS after receiving a power down registration message from the MS.
f. The BS sends the A9-Update-A8 message to the PCF if it receives a Location Updating Accept message with cause value “Power down from dormant state” from the MSC. The BS may also send the A9-Update-A8 message on its own. In both cases, the cause value in the A9-Update-A8 message is set to “Power down from dormant state”. The BS starts timer Tupd9.
g. The PCF uses the MSID received in the A9-Update-A8 message to find the corresponding A10 connection(s). The PCF initiates release of all A10 connections associated with the MS by sending an A11-Registration Request message to the PDSN with Lifetime value set to ‘0’ for each PDSI. The PCF starts a timer Tregreq associated with each A11-Registration Request message sent.
h. The PDSN sends an A11-Registration Reply message with an accept indication for each A11-Registration Request message to complete the release of each A10 connection. The PCF stops the associated timer Tregreq.
193 Section 3
3GPP2 A.S0013-D v2.0
i. The PCF sends an A9-Update-A8 Ack message to the BS. The BS stops timer Tupd9. 1
2 3.17.4.24 Mobile Initiated Initial PDSI Setup – Successful Operation with Delayed Accounting Information 3
4
5
6
7
8
9
10
11
12
13
14
15
16
When an MS initiates a PDSI setup and PPP negotiation has not yet been performed over that PDSI (main PDSI), PPP negotiation is performed before transmitting packet data. In the case of auxiliary PDSI setup PPP negotiation is not required before data transfer since the main PDSI has already been set up. It is assumed that the MS does not have an active voice call already in progress.
cdma2000 TCH establishment procedure may occur in parallel with the A8 connection establishment, in which case the accounting information required to be included in the “Active-Start” airlink record on the A11 interface may not be available in the A9-Setup-A8 message.
When the cdma2000 TCH establishment procedure has completed, the BS updates the PCF on the A9 connection with the accounting information required to be included in an “Active-Start” Airlink record on the A11 interface. The BS sends an A9-Update-A8 message containing the information.
Section 3 194
3GPP2 A.S0013-D v2.0
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
i
j
k
T303
T10
Tregreq
Transmitting packet data
Establishing PPP connection
cdma2000 TCH
Establishment procedure
A9-Update-A8
A9-Update-A8 Ack m
time
n
o
Tupd9
p
A11-Registration Request
A11-Registration Reply h
Tregreq
A11-Registration Request
A11-Registration Reply
l
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Figure 3.17.4.24-1 Mobile Initiated Initial PDSI Setup – Successful Operation with Delayed Accounting Information
a. The MS transmits an Origination Message (DRS=1), with layer 2 acknowledgment required, over the access channel of the air interface to the BS to request PDSI setup.
b. The BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
c. The BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303.
d. The MSC sends an Assignment Request message to the BS to request assignment of radio resources and starts timer T10. For packet data service, an A2p connection between the BS and the MGW or a terrestrial circuit between the MSC and the BS is not required.
e. The BS and the MS initiate the establishment of a radio traffic channel.
195 Section 3
3GPP2 A.S0013-D v2.0
f. The BS transmits an A9-Setup-A8 message to PCF with Data Ready Indicator set to ‘1’ to establish an A8 connection and starts timer TA8-setup. All the required accounting information to be included in the A11 Active-Start Airlink record is not yet available.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
g. The PCF sends an A11-Registration Request message with non-zero Lifetime value and the ANID of the PCF (sent in the CANID field) to the PDSN. This message includes the “connection-setup” airlink record. The PCF starts timer Tregreq.
h. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and the Lifetime set to the configured Trp value. The PCF stops timer Tregreq.
i. Upon establishment of the A10 connection, the PCF establishes an A8 connection and transmits an A9-Connect-A8 message to the BS. The BS stops timer TA8-setup.
j. The BS sends an Assignment Complete message to the MSC. This step may occur any time after radio link establishment. The MSC stops timer T10.
k. The cdma2000 TCH establishment procedure is completed. The BS informs the PCF via an A9-Update-A8 message that the traffic channel is now successfully established to the MS by including the cause value ‘Update accounting: late traffic channel setup’. The message includes the required accounting information to be included in the A11 Active-Start Airlink record. The BS starts timer Tupd9.
l. The PCF sends an A11-Registration Request message for the PDSI to provide accounting information (“Active-Start”) to the PDSN. The PCF starts timer Tregreq.
m. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops Tregreq.
n. The PCF acknowledges the A9-Update-A8 message by returning an A9-Update-A8 Ack message back to the BS. Upon receipt of this message, the BS stops timer Tupd9.
o. The PPP connection establishment procedure and Mobile IP Registration (if required) are performed on the PPP connection between the MS and PDSN in the case of first/main PDSI setup. This setup does not apply to auxiliary PDSI setup.
p. The MS begins transmitting/receiving packet data.
3.17.4.25 Accounting Parameters Update Event Procedure 31
32
33
34
35
During an active connection, if a change occurs to any of the accounting parameters identified in [8] as triggering an accounting update the BS shall notify the PCF using the A9-Update-A8 message. The message shall contain the changed parameters. The PCF then triggers an A11 procedure to update the PDSN with the new accounting information.
Section 3 196
3GPP2 A.S0013-D v2.0
BS MSC PCF PDSN
b
c
d
Parameter change notification/ negotiation
A9-Update-A8
A9-Update-A8 Ack
Active PPP session a
Tupd9
MS time
f
Parameter change notification/ negotiation
A11-Registration Request
A11-Registration Reply Tregreq
e
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.17.4.25-1 Accounting Parameters Update Event Procedure
a. An active PPP session exists and data is transferred over the connection.
b. An event occurs where parameters are changed/negotiated between the BS/MSC and the MS.
c. The BS notifies the PCF using an A9-Update-A8 message when a change occurs to any of the parameters identified in [8] as triggering an accounting update have changed. The BS starts timer Tupd9.
d. The PCF sends an A11-Registration Request message for the affected service instance/A10 connection to notify the PDSN that a parameter has changed (refer to [8] for a list of parameters that trigger an accounting parameter update). The message contains the airlink records “Active-Stop” followed by an “Active Start” with the new set of parameters. The PCF starts timer Tregreq.
e. The PDSN updates the accounting data and returns an A11-Registration-Reply message with an accept indication to PCF. The PCF stops timer Tregreq.
f. The PCF sends the A9-Update-A8 Ack message as an acknowledgment back to the BS. The BS stops timer Tupd9.
3.17.4.26 MS Initiated Reactivation from Dormant State 18
19
20
21
22
23
24
While in a dormant packet data session state, the MS has data to send to the network. The MS sends an Origination Message to the target BS with the DRS bit set to ‘1’.
If the MS is reactivating in the same packet zone where it was last registered, the MS does not include any ANID information in the Origination message. The call flow in section 3.17.4.2.1 may serve as an illustration of this case, with the modification that step ‘g’ does not serve the purpose of establishing an A10 connection but is used to pass
197 Section 3
3GPP2 A.S0013-D v2.0
accounting information (Active Start Airlink Record). The PCF does not include any ANID NVSE in step ‘g’.
1
2
3
4
5
6
7
If the MS is reactivating in a new packet zone, it may notify the packet data network by including ANID information in the Origination Message. The PCF may also detect that the MS is originating in a new packet zone if there is no A10 connection for the user. The call flow in section 3.17.4.2.1 may serve as an illustration of this case.
3.17.5 Interoperability Control 8
9 This section describes version control on the A8/A9 and A10/A11 interfaces.
3.17.5.1 A9 Version Control 10
11 This section describes version control on the A8/A9 interfaces.
3.17.5.1.1 Example of a Successful BS initiated A9 Version Control Procedure 12
13
14
This call flow shows an example of a successful BS initiated A9 version control procedure.
time
a
b
PCF
A9-Version Info Ack
A9-Version Info
comment
Tvers9
BS
15
16
17
18
19
20
21
22
23
24
Figure 3.17.5.1.1-1 Successful BS Initiated A9 Version Control Procedure
a. The BS sends an A9-Version Info message to the PCF. The message includes the BS software version information. If the message is sent as a result of a reset, a cause element is included in the message to indicate that a BS reset occurred. The BS starts timer Tvers9.
b. The PCF responds with an A9-Version Info Ack message, which includes the PCF’s software version information. If a BS reset occurred, the PCF initiates a release of any resources previously allocated for packet data calls supported by the BS. Upon reception of the message, the BS stops timer Tvers9.
3.17.5.1.2 Example of a Successful PCF Initiated A9 Version Control Procedure 25
26
27
This call flow shows an example of a successful PCF initiated A9 version control procedure.
Section 3 198
3GPP2 A.S0013-D v2.0
time
a
b
PCF
A9-Version Info Ack
A9-Version Info
comment
Tvers9
BS
1
2
3
4
5
6
7
8
9
10
Figure 3.17.5.1.2-1 Successful PCF Initiated A9-Version Control Procedure
a. The PCF sends an A9-Version Info message to the BS. The message includes the PCF software version information. If the message is sent as a result of a reset, a cause element is included in the message to indicate that a PCF reset occurred. The PCF starts timer Tvers9.
b. The BS responds with an A9-Version Info Ack message, which includes the BS software version information. If a PCF reset occurred, the BS releases any resources previously allocated for packet data calls supported by the PCF. Upon reception of the message, the PCF stops timer Tvers9.
3.17.5.2 A11 Capabilities Control 11
12 This section describes capabilities control on the A10/A11 interfaces.
3.17.5.2.1 PCF Initiated A11 Capabilities Control 13
14 The section illustrates an example scenario for PCF initiated A11 Capabilities Control.
time
a
b
PDSN
A11-Capabilities Info Ack
A11-Capabilities Info
comment
Tvers11
PCF
15
16
17
18
19
20
21
22
Figure 3.17.5.2.1-1 A11 Capabilities Information Exchange – PCF Initiated
a. Upon restart, or for other reasons, the PCF sends an A11-Capabilities Info message to the PDSN and starts timer Tvers11. The PCF may send this message to all PDSNs to which it is connected.
b. Upon receipt of the A11-Capabilities Info message, the PDSN sends an A11- Capabilities Info Ack message. Upon receipt of this message, the PCF stops timer Tvers11.
3.17.5.2.2 PDSN Initiated A11 Capabilities 23
24 The section illustrates an example scenario for PDSN initiated A11 Capabilities Control.
199 Section 3
3GPP2 A.S0013-D v2.0
a
b
PDSN
A11-Capabilities Info Ack
A11-Capabilities Info
Tvers11
PCF
c
BS
A9-Version procedures
1
2
3
4
5
6
7
8
9
10
Figure 3.17.5.2.2-1 A11 Capabilities Information Exchange
a. Upon restart, or for other reasons, the PDSN sends an A11-Capabilities Info message to the PCF and starts timer Tvers11. The PDSN may send this message to all PCFs it is connected to.
b. Upon receipt of the A11-Capabilities Info message, the PCF conducts A9 Version procedures. Refer to section 3.17.5.1.
c. Upon completion of A9 Version procedures, the PCF sends an A11- Capabilities Info Ack message to the PDSN. Upon receipt of this message, the PDSN stops timer Tvers11.
3.17.6 Support of Short Data Bursts 11
12 This section describes call flows associated with the Short Data Burst feature.
3.17.6.1 Mobile Originated Short Data Burst Call Flows 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
An MS with a currently dormant PDSI may need to send a small amount of data to the network. The MS may transmit it via a Short Data Burst (SDB) to the BS in SDB format as specified in [21]. The short data burst is sent from the MS to the BS over the signaling channel if there is no active voice or packet data call in progress and over the traffic channel if there is an active voice or packet data call in progress. If authentication is enabled in the network (and the MS is not engaged in an active voice or packet data call), before the data is sent on from the BS, the MS may need to be authenticated. If authentication is performed, the BS shall buffer the data during the authentication procedure. If authentication is successful or not performed, the BS sends the data to the PCF in SDB format as specified in [21]. The PCF sends this data on to the PDSN as normal packet data.
The following call flow shows the receipt of a short data burst on the Access Channel from the MS and its delivery to the PCF. This scenario assumes that the MS is not engaged in an active voice or packet data call.
Section 3 200
3GPP2 A.S0013-D v2.0
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 -- conditional
e
Data Burst
(type SDB)
f
g
h
Tregreq
Dormant/PPP connected
Packet data
A11-Reqistration Request
A11-Registration Reply
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.17.6.1-1 cdma2000 Short Data Burst from an MS to the PDSN
a. The MS sends a cdma2000 Short Data Burst to the network on a reverse common signaling channel.
b. The BS acknowledges the cdma2000 Short Data Burst received by sending a Layer 2 Ack.
c. If the BS chooses to authenticate the MS, the BS sends an ADDS Transfer message to the MSC containing the authentication parameters received from the MS, the BS computed authentication data element, and the Data Burst Type field of the ADDS User Part element set to short data burst. If authentication is performed, the BS shall buffer the SDB data and start timer T60. The MSC receives the ADDS Transfer message, reads the burst type field of the ADDS User Part element, and determines that this a cdma2000 short data burst. The MSC may then authenticate the MS.
d. The MSC sends the result of the short data burst authentication to the BS in the ADDS Transfer Ack message. Upon receipt of the ADDS Transfer Ack message, the BS stops timer T60. If the cause element is present and indicates authentication failure, the BS shall discard the buffered short data burst. If timer T60 expires at the BS before the BS receives the ADDS Transfer Ack message, the BS shall discard the buffered short data burst.
201 Section 3
3GPP2 A.S0013-D v2.0
e. If no cause element is present in the ADDS Transfer Ack response from the MSC, or if the BS chose not to authenticate the MS, the BS sends the short data burst to the PCF in SDB format as specified in
1
2
3
4
5
6
7
[21] in the A9-Short Data Delivery message.
f. The PCF sends the data to the PDSN as normal packet data.
g. The PCF sends an A11-Registration Request message with the SDB Airlink record to the PDSN. The PCF starts timer Tregreq.
h. The PDSN responds with an A11-Registration Reply message. The PCF stop Tregreq.
3.17.6.2 Mobile Terminated Short Data Burst Call Flows 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
When a small amount of data destined for a dormant PDSI on an MS is received at the PCF, the PCF may send this data to the BS in SDB format as specified in [21]. The PDSN may indicate suitability of this data for short data burst transmission via an attribute in its GRE payload as defined in [12].
If the BS accepts the data for delivery to the MS, the BS shall acknowledge the PCF’s request. The PCF may then discard the buffered data.
If the BS determines that a short data burst may be used to deliver the data to the MS, the BS sends this data, in SDB format as specified in [21], directly to the MS over the signaling or traffic channel.
If the BS is unsuccessful in delivering the SDB to the MS on its own or for other implementation specific reasons, the BS may also send this data, in SDB format, on to the MSC for delivery to the MS via the ADDS Page procedure. The BS may also send the data to the MSC for delivery to the MS via the ADDS Deliver procedure if a voice call is active. The data is delivered to the MSC using the BS Service Request/Response procedure.
If after receiving data from the PCF in SDB format the BS determines that the PDSI should be re-activated, it shall reject the PCF’s request to send the data as a short data burst by sending the cause value ‘Initiate Re-Activation of Packet Data Call’ in the A9-Short Data Ack message. The PCF shall then be required to initiate the re-activation of the PDSI. Once the session is active, the buffered data shall be resent to the BS for transmission to the MS as normal packet data. Refer to section 3.17.6.2.2 for this scenario.
3.17.6.2.1 Short Data Delivery from the PDSN to the MS 31
32
33
The following procedure shows the call flow associated with the receipt of a short data message from the PCF and its delivery to the MS.
Section 3 202
3GPP2 A.S0013-D v2.0
T311
A9-Short Data Ack
A11-Registration
Reply
All-Registration
Request
Data Burst
(Type SDB)
MS BS MSC/VLR
time
c
g
h
i
k
BS Service Response T311
BS Service Request
A9-Short Data Delivery
ADDS Page Procedure
Packet data a
Layer 2 Ack e
j
Tsdd9
d
f
A9-Update-A8
A9-Update-A8 Ack
Tupd9 Tregreq
conditional
conditional
conditional
l
PCF PDSN
Dormant/PPP connected
b
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Figure 3.17.6.2.1-1 cdma2000 Short Data Burst from the PDSN to the MS
a. The PDSN sends packet data to the PCF on an existing PPP connection and A10 connection associated with a specific MS. This data may have an attribute in its GRE payload, indicating its suitability for SDB transmission.
b. The PCF sends the packet data to the BS in the A9-Short Data Delivery message and starts timer Tsdd9. The data is sent in SDB format as specified in [21] and is encapsulated in the ADDS user part element. The PCF buffers the data sent.
c. The BS acknowledges receipt of the A9-Short Data message from the PCF by returning the A9-Short Data Ack message with cause value ‘Successful operation’ to indicate that it will deliver the data as a short data burst. The PCF stops timer Tsdd9 and discards the buffered data. If timer Tsdd9 expires, the PCF discards the buffered data. This message may alternatively be sent after step ‘e’ with the cause value set to “SDB successfully delivered” or “SDB couldn’t be delivered” to indicate if the SDB was successfully delivered to the MS.
203 Section 3
3GPP2 A.S0013-D v2.0
d. The BS may send a short data burst directly to the MS, or alternatively the BS may skip to step ‘f’ to initiate the ADDS Page procedure. Note, the BS may also decide to alternatively deliver the data to the MS over a traffic channel (refer to section 3.17.6.2.2).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
e The MS sends a layer 2 Ack in response to the short data burst from the BS. If a layer 2 Ack is not received from the MS, the BS may continue with steps ‘f’ through ‘h’ below. If the Layer 2 Ack is received, the call flow continues with step ‘i’.
f. The BS sends the SDB data in a SDB format to the MSC in the BS Service Request message. The BS starts timer T311. If timer T311 expires, the SDB information shall not be sent to the MS.
g. The MSC acknowledges reception of the BS Service Request message by sending a BS Service Response message to the BS. The BS stops timer T311.
h. The MSC sends an ADDS Page message to the BS with the Data Burst Type field in the ADDS User Part element set to Short Data Burst, and the SDB in the Application Data Message field. The BS forwards the Short Data Burst on to the MS. Refer to section 3.10.2.3.
i. The BS sends an A9-Update-A8 message to the PCF to indicate successful transmission of the Short Data Burst to the MS. The BS starts timer Tupd9. Note, steps ‘i’ and ‘l’ do not occur if the BS previously informed the PCF of the successful delivery of the SDB to the MS.
j. The PCF sends an A11-Registration Request message with the SDB Airlink record to the PDSN. The PCF starts timer Tregreq.
k. The PDSN responds with the A11-Registration Reply message. The PCF stops Tregreq.
l. The PCF responds to the BS with an A9-Update-A8 Ack. The BS stops timer Tupd9.
3.17.6.2.2 Short Data Delivery from the PDSN – BS Refuses SDB Request 26
27
28
29
The following procedure shows the call flow associated with the BS refusal of the PCF short data burst request, and subsequent delivery of the data to the MS on a traffic channel.
Section 3 204
3GPP2 A.S0013-D v2.0
T311 MS BS MSC PCF PDSN time
b
A9-Short Data Delivery
Network initiated call re-activation from dormant
state
Active Packet Data Session
Packet data a
c A9-Short Data Ack Tsdd9
d
e
Dormant/PPP connected
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.17.6.2.2-1 Short Data Burst from the PDSN to the MS – BS Refuses SDB Request
a. The PDSN sends packet data to the PCF on an existing A10 connection associated with a specific MS. This data may have an attribute in its GRE payload indicating its suitability for SDB transmission.
b. The PCF sends the packet data to the BS in the A9-Short Data Delivery message and sets timer Tsdd9. The data is sent in SDB format as specified in [21] and is encapsulated in the ADDS user part element. The PCF buffers the data sent.
c. The BS makes the determination, based on its internal algorithm, the data count field in the A9-Short Data Delivery, or any other factors, not to send a short data burst to the MS. The BS sends an A9-Short Data Ack message to the PCF with an indication that a short data burst is not to be sent to the MS by setting the cause value to ‘Initiate re-activation of packet data call’.
d. The PCF stops timer Tsdd9 and initiates a reactivation of the packet data service. Refer to section 3.17.4.11.1.
e Once the PDSI is active, the PCF sends the data buffered earlier for the MS to the BS which forwards the data on to the MS.
205 Section 3
3GPP2 A.S0013-D v2.0
3.17.7 Support for Common Channel Packet Data (CCPD) 1
2
3
This section describes support for Common Channel Packet Data (CCPD) mode of packet data service.
3.17.7.1 Mobile Originated CCPD Mode Packet Data Call Setup Request 4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
A CCPD capable MS requests CCPD Mode from the network by sending an Origination Message to the BS with the SDB_DESIRED_ONLY and DRS bits set to ‘1’. If the BS agrees to support an MS’s request for CCPD Mode, the MS is first authenticated and registered via the ADDS Transfer procedure. Upon successful authentication of the MS, the PCF is informed that CCPD Mode is to be used for the call. PPP connection setup and Mobile IP Registration (if required) are performed using Short Data Bursts over Common Channels to exchange the messages. Messages and data between the BS and PCF are passed over the A9 signaling channel; an A8 bearer connection is not required. Upon successful completion of these procedures, the PDSI transitions from the Null to Dormant State.
The following messages are used to support a Mobile Originated CCPD Mode Request:
ADDS Transfer
ADDS Transfer Ack
A9-Setup-A8
A9-Release-A8 Complete
A9-Short Data Delivery
A9-Short Data Ack
A11-Registration Request
A11-Registration Reply
The following call flow describes an MS initiated Common Channel Packet Data call.
Section 3 206
3GPP2 A.S0013-D v2.0
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
i
j
T60
TA8-setup
Data Burst (SDB)
Packet Data
(Establish PPP
time
Null / Inactive State
Dormant / PPP Connected
Packet Data
A11-Registration Request
A11-Registration Reply
l
m
BS Ack Order
n
o
A9-Release-A8 Complete
p
Tregreq
A9-Short Data Delivery
Data Burst (SDB)
A9-Short Data Delivery
Packet Data
(Establish PPP
Layer 2 Ack
Data Burst (SDB)
BS Ack Order
q
r
s
t u
v
w
A9-Short Data Ack
k
Tsdd9
Release Order
h
A11-Registration Request
A11-Registration Reply Tregreq
x 1
2 Figure 3.17.7.1-1 MS Initiated CCPD Mode Setup and Data Transfer
207 Section 3
3GPP2 A.S0013-D v2.0
a. An MS transmits an Origination Message to the BS over the Access Channel of the air interface with Layer 2 Ack required to request packet data service. The MS indicates its desire for CCPD Mode to the network by setting the SDB_DESIRED_ONLY bit in the message to ‘1’ and DRS bit set to ‘1’.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
b. The BS acknowledges receipt of the Origination Message by sending a Base Station Acknowledgment Order to the MS.
c. The BS sends an ADDS Transfer message to the MSC containing the authentication parameters received from the MS, the BS computed authentication data element, and the Data Burst Type field of the ADDS User Part element set to Short Data Burst. The BS starts timer T60. If the BS decides not to support the MS’s request for CCPD Mode, the BS may reject the call or treat the call as a normal mobile originated packet data call by assigning a traffic channel (refer to section 3.17.4.2 for the call flow).
d. The MSC sends the result of authentication for the MS back to the BS in the ADDS Transfer Ack message. The BS stops timer T60.
e. The BS sends an A9-Setup-A8 message to the PCF to initiate an A8 connection setup. The BS sets the CCPD Mode bit in the message to 1 to indicate to the PCF that this is a CCPD call and that an A8 connection is not required. The BS starts timer TA8-setup.
f. If the PCF recognizes that no A10 connection associated with this MS is available then the PCF selects a PDSN. The PCF sends an A11-Registration Request message with non-zero Lifetime value to the selected PDSN. The PCF starts timer Tregreq.
g. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and the Lifetime field set to the configured Trp value. The PCF stops timer Tregreq.
h. The PCF sends an A9-Release-A8 Complete message to the BS with a “Packet call going dormant” cause value. The BS stops timer TA8-setup.
i. The BS sends a Release Order without a rejection of the service option to the MS. This Release Order serves as an acknowledge of the CCPD Mode request from the MS
j. The PDSN sends packet data (PPP connection establishment and MIP registration messages if supported) on the A10 connection to the PCF.
k. The PCF sends the packet data in SDB format in an A9-Short Data Delivery message with an indication that the data is for MS in CCPD Mode to the BS. The PCF starts timer Tsdd9.
l. The BS acknowledges the receipt of an A9-Short Data Delivery message from the PCF by sending an A9-Short Data Ack to the PCF. The PCF discards the buffered data and stops timer Tsdd9. This message may alternatively be sent after step ‘n’ with the cause value set to “SDB successfully delivered” or “SDB couldn’t be delivered” to indicate if the SDB was successfully delivered to the MS.
m. The BS sends the packet data in a Short Data Burst over the common channel to the MS.
n. The MS acknowledges receipt of the Short Data Burst from the BS by sending a Layer 2 Ack to the BS. If a Layer 2 Ack is not received from the MS, the BS may resend the SDB to the MS.
Section 3 208
3GPP2 A.S0013-D v2.0
o. The MS sends packet data (PPP connection establishment and MIP Registration if supported) in a SDB over the common channel to the BS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
p. The BS acknowledges receipt of the SDB from the MS by sending a BS Ack Order to the MS.
q. The BS sends an A9-Short Data Delivery message containing packet data from the MS in SDB format to the PCF.
r. The PCF sends the data to the PDSN as normal packet data on the A10 connection.
Note: Steps ‘j’ through ‘r’ are repeated until the PPP connection is established and MIP Registration (if supported) are completed.
s. The MS in CCPD Mode sends packet data in a SDB over the common channel to the BS.
t. The BS acknowledges receipt of the SDB from the MS by sending a BS Ack Order to the MS.
u. The BS sends an A9-Short Data Delivery message containing the packet data from the MS in SDB format to the PCF.
v. The PCF sends the data to the PDSN as normal packet data on the A10 connection.
w. The PCF sends an A11-Registration Request message with the SDB Airlink record for accounting to the PDSN. The PCF starts timer Tregreq.
x. The PDSN responds with an A11-Registration Reply message to the PCF. The PCF stops Tregreq.
3.17.7.2 Mobile Terminated Packet Data for CCPD 21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
The PCF was informed that the MS requested CCPD Mode at the time the MS initiated a CCPD Mode Request from the network. If the network has data to send, the PCF sends the data to the BS in the A9-Short Data Delivery message with an indication that the data is for a CCPD capable MS. The BS sends the data to the MS in a Short Data burst as specified in [21]. If the BS doesn’t receive an acknowledgement from the MS after sending the Short Data Burst to the MS, the BS may resend the data or invoke ADDS Procedures to deliver the data.
The following messages are used to support a Mobile Terminated Packet Data for CCPD:
A9-Short Data Delivery
A9-Short Data Ack
A9-Update-A8
A9-Update-Ack
A11-Registration Request
A11-Registration Reply
Refer to call flow 3.17.6.2.1 “Short Data Delivery from PDSN to MS” for mobile terminated packet data transfer for an MS in CCPD Mode.
3.17.7.3 CCPD Mode Packet Data Handoffs 38
39
40
41
The following calls flows describe dormant handoff for CCPD Capable MSs. Upon detection of a new PZID, SID, or NID, the MS sends an Origination Message to the BS with the SDB_DESIRED _ONLY bit set to ‘1’ and the DRS bit set to ‘0’. The PCF
209 Section 3
3GPP2 A.S0013-D v2.0
establishes an A10 connection with the PDSN. If the MS continues to be served by the same PDSN, the PDSN releases the A10 connection with the previous PCF. If as a result of the dormant mode handoff a new PDSN is selected for the call, a PPP connection is setup and Mobile IP Registration (if required) is performed using Short Data Bursts over Common channels.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
The BS may initiate CCPD Mode handoff for an MS that supports short data bursts even though the MS may not have explicitly requested CCPD Mode from the BS The BS may use this procedure to support dormant mode handoffs (e.g. if traffic channels are not available) in the event PPP connection establishment is required or PDSN has data to send. Upon detection of a new PZID, SID, or NID, the MS sends an Origination Message to the BS with the SDB_DESIRED_ONLY bit set to ‘0’, and the DRS bit set to ‘0’. Instead of initiating normal dormant mode handoff procedures, the BS initiates CCPD handoff by informing the PCF that CCPD Mode shall be used in the case that the PDSN has data to send as part of the dormant handoff. If the PDSN has data to send, the PCF will forward the data via the BS to the MS as Short Data bursts.
The following IOS messages are used to support a CCPD Mode dormant handoff:
ADDS Transfer
ADDS Transfer Ack
A9-Setup-A8
A9-Release-A8 Complete
A9-Short Data Delivery
A9-Short Data Ack.
3.17.7.3.1 CCPD MS Handoff (Inter-BS/Inter-PCF/Intra-PDSN) 23
24
25
26
27
28
29
30
31
32
33
34
35
36
The following call flow describes the procedure for a successful inter-PCF/intra-PDSN handoff of a CCPD MS. It is assumed that the PCF is uniquely identified by the CANID. On detection of a new PZID, NID or SID, the MS sends an Origination Message to the target BS with the packet data service option the SDB_DESIRED_ONLY bit set to ‘1’ and DRS bit set to ‘0’. The Origination Message includes the previous PZID, NID and SID when any of these parameters change during the dormant handoff. Based on the IDs (PZID, NID and/or SID) in the Origination Message, the target PCF sends the PANID of the source PCF and the CANID of the target PCF to the serving PDSN. The serving PDSN uses this information to determine if PPP re-negotiation is required. All messages using the SDB format in the call flow are as specified in [21]. If the PDSN has data, the PDSN returns the ‘Data Available Indicator’ in the CVSE within the Registration Reply message to the BS/PCF. The source PDSN releases the A10 connection with the source PCF.
Section 3 210
3GPP2 A.S0013-D v2.0
ADDS-TransferAck
time comment
a
b
c
d
e
f
g
h
Target PCF
ADDS-Transfer
Origination Message
A9-Setup-A8
A9-Release-A8 Complete
BS Ack Order
Packet Data Session Dormant, PPP connection is maintained
TA8-setup
T60
Release Order k
l
Packet Data Session Dormant, PPP connection is maintained
m
n
p
o Tregreq
A11-Registration Request
A11-RegistrationAcknowledge
A11-Registration Update
ADDS-TransferAck
i
j
Optional
A11-Registration Request
A11-RegistrationReply
A11-Registration Reply
Tregupd
MS Target BS MSC Source PCF PDSN
Tregreq
1
2
3
4
5
6
7
8
9
10
11
Figure 3.17.7.3.1-1 CCPD MS Handoff (Inter-BS/Inter-PCF/Intra-PDSN)
a. It is assumed that the MS has established a PPP connection with the PDSN and performed a MIP registration (if required) but the packet data session is now dormant. The MS does not have an active voice call in progress.
b. The CCPD MS detects a change of PZID, SID or NID while monitoring the broadcast channel and sends an Origination Message with the SDB_DESIRED_ONLY bit set to ‘1’ and DRS bit set to ‘0’. If the SDB_DESIRED_ONLY bit is set to ‘0’, the target BS may still initiate CCPD mode.
c. The target BS acknowledges receipt of the Origination Message with a Base Station Acknowledgement Order to the MS.
211 Section 3
3GPP2 A.S0013-D v2.0
d. The target BS sends an ADDS Transfer message to the MSC containing the authentication parameters received from the MS, the target BS computed authentication data element, and the Data Burst Type field of the ADDS User Part element set to Short Data Burst. The target BS starts timer T60.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
e. The MSC optionally sends an ADDS Transfer Ack message indicating concurrent authentication and packet data setup to the target BS. This allows the BS to proceed with step ‘f’. If the MSC does not send this message, steps ‘f’ through ‘i’ occur after step ‘j’. The target BS stops timer T60.
f. The target BS sends an A9-Setup-A8 message, with the Data Ready Indicator and Handoff Indicator bits set to ‘0’ to the target PCF. The target BS sets the CCPD Mode bit in the message to 1 to indicate to the PCF that an A8 connection is not required. The target BS starts timer TA8-setup.
g. The target PCF selects a PDSN and sends an A11-Registration Request message to the PDSN. The Registration Request message includes the Mobility Event Indicator within a CVSE. The PCF starts timer Tregreq.
h. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. If the PDSN has data to send, it includes the Data Available Indicator within a CVSE The A10 connection binding information at the PDSN is updated to point to the target PCF. The PCF stops timer Tregreq.
i. The target PCF sends an A9-Release-A8 Complete message to the target BS with a “Packet data going dormant” cause value. The target BS stops timer TA8-setup.
j. The MSC sends an ADDS Transfer Ack message to the MS indicating successful authentication of the MS. The BS stops timer T60.
k. The target BS sends a Release Order without a rejection of the service option to the MS. The Release Order serves as an acknowledgement to the CCPD Mode request from the MS.
Note: The packet data session is in Dormant State
l. The PDSN initiates release of the A10 connection with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
m. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
n. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The PCF starts timer Tregreq.
o. The PDSN sends the A11-Registration Reply message to the source PCF. The source PCF releases the A10 connection for the MS. The PCF stops timer Tregreq.
p. The packet data session remains dormant.
3.17.7.3.2 CCPD MS Dormant Handoff (Inter-BS/Inter-PCF/Inter-PDSN) 38
39
40
41
42
43
44
45
The following call flow describes the procedure for a successful inter-PCF/inter-PDSN handoff of a CCPD MS. On detection of a new PZID, SID, or NID, the MS sends an Origination Message to the target BS that includes the packet data service option and the SDB_DESIRED_ONLY bit set to ‘1’ and DRS bit set to ‘0’. The target PCF establishes an A10 connection with the target PDSN. The target PCF forwards the PANID of the source PCF and the CANID of the target PCF to the serving PDSN. PPP Connection Setup and Mobile IP Registration (if required) occur using Short Data Bursts over the
Section 3 212
3GPP2 A.S0013-D v2.0
common channels. The source PDSN releases the A10 connection with the source PCF on expiration of the Lifetime timer (Trp) or other events internal to the PDSN. The target PCF periodically re-registers with the PDSN by the use of the A11-Registration Request message before the A10 connection Lifetime expires.
1
2
3
4
5
6
7
8
This call flow may also be used if the network decides to initiate CCPD Mode for a dormant mode handoff without the MS having requested CCPD Mode. For this case, the MS sends an Origination Message with the SDB_DESIRED_ONLY and DRS bits set to ‘0’.
BS MS
Origination
BS ACK Order
MSC
ADDS Transfer
A9-Setup-A8
ADDS Transfer Ack
PCF PDSN
a
b
c
d
e
f
g
h
T60
TA8-Setup
A9-Release-A8 Complete
Time
Packet Data
(Establish PPP Connection)
A9-Short Data Delivery
Data Burst (SDB)
A9-Short Data Delivery
Packet Data
(Establish PPP Connection)
Layer 2 Ack
Data Burst (SDB)
BS Ack Order
i
j k
l
m
n
o
A11-Registration Request
A11-Registration Reply Tregreq
Release Order
A9-Short Data Ack Tsdd9
p
q
r
ADDS Transfer Ack
s
Optional
9
10
11
12
13
14
15
Figure 3.17.7.3.2-1 CCPD MS Dormant Handoff (Inter-BS/Inter-PCF/Inter-PDSN) - Mobile Served by Different PDSN
a. The CCPD MS detects a change of Packet Zone ID while monitoring the broadcast channel and sends an Origination Message with the SDB_DESIRED_ONLY bit set to ‘1’ and DRS bit set to ‘0’. If the SDB_DESIRED_ONLY bit is set to ‘0’, the BS may still initiate CCPD mode.
213 Section 3
3GPP2 A.S0013-D v2.0
b. The BS acknowledges receipt of the Origination Message with a Base Station Acknowledgement Order to the MS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
c. The BS sends an ADDS Transfer message to the MSC containing the authentication parameters received from the MS, the BS computed authentication data element, and the Data Burst Type field of the ADDS User Part element set to Short Data Burst. The BS starts timer T60.
d. The MSC optionally sends an ADDS Transfer Ack message indicating concurrent authentication and packet data setup to the target BS. This allows the BS to proceed with step ‘e’. If the MSC does not send this message, steps ‘e’ through ‘h’ occur after step ‘i’.
e. The BS sends an A9-Setup-A8 message, with Data Ready Indicator and Handoff Indicator bits set to ‘0’ to the target PCF. The BS sets the CCPD Mode bit in the message to 1 to indicate to the PCF that CCPD Mode is being used for the call and that an A8 connection is not required. The BS starts timer TA8-setup.
f. The target PCF selects a PDSN and sends an A11-Registration Request message to the PDSN. The Registration Request message includes the Mobility Event Indicator within a CVSE. The PCF starts timer Tregreq.
g. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. If the PDSN has data to send, it includes the Data Available Indicator within a CVSE The A10 connection binding information at the PDSN is updated to point to the target PCF. The PCF stops timer Tregreq
h. The PCF sends an A9-Release-A8 Complete message to the BS with a “Packet call going dormant” cause value. The BS stops timer TA8-setup.
i. The MSC sends an ADDS Transfer Ack message to the MS indicating successful authentication of the MS. The BS stops timer T60
j. The BS sends a Release Order without a rejection of service option to the MS. This Release Order serves as an acknowledge of the CCPD Mode request from the MS
k. The PDSN sends packet data (PPP connection establishment and MIP registration if supported) on the A10 connection to the PCF.
l. The PCF sends the packet data SDB format in an A9-Short Data Delivery message to the BS. The BS starts timer Tsdd9.
m. The BS acknowledges the receipt of an A9-Short Data Delivery message from the PCF by sending an A9-Short Data Ack to the PCF. The PCF discards the buffered data and stops timer Tsdd9. This message may alternatively be sent after step ‘n’ with the cause value set to “SDB successfully delivered” or “SDB couldn’t be delivered” to indicate if the SDB was successfully delivered to the MS.
n. The BS sends the packet data in a Short Data Burst over the common channel to the MS.
o. The MS acknowledges receipt of the Short Data Burst from the BS by sending a Layer 2 Ack to the BS. If a Layer 2 Ack is not received from the MS, the BS may resend the SDB to the MS.
p. The MS sends packet data (PPP connection establishment and MIP Registration if supported) in a SDB over the common channel to the BS
q. The BS acknowledges receipt of the SDB from the MS by sending a BS Ack Order to the MS
Section 3 214
3GPP2 A.S0013-D v2.0
r. The BS sends an A9-Short Data Delivery message containing the packet data (PPP establishment) from the MS in SDB format to the PCF.
1
2
3
4
5
6
7
s. The PCF sends the data to the PDSN as normal packet data (PPP establishment) on the A10 connection.
Note: The source PDSN will eventually release the A10 connection to the source PCF for the MS upon expiration of the PPP timer or other event internal to the source PDSN. Refer to steps ‘l’ through ‘o’ in Figure 3.17.4.14-1.
3.17.8 Packet Data Security Considerations 8
9 There are no call flows associated with this feature. Refer to [17] for more information.
3.17.9 Support for PDSN Initiated Packet Data Session Updates 10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
The PDSN may send parameters to the PCF that affect the behavior of the PCF or the BS or both. The parameters may be related to the packet data session or to individual PDSIs. If the parameters are available at the PDSN when a new A10 connection is established, the PDSN sends the parameters in a Session Parameters NVSE in the A11-Registration Reply message. The PCF may forward the parameters to the BS in the A9-Connect-A8 message. Refer to the call flows in section 3.17.4 involving setup of new A10 connections.
While the packet data session is dormant, the PDSN stores the parameters and sends them to the PCF upon reactivation of the packet data session in the A11-Registration Reply message. The PCF may forward the parameters to the BS in the A9-Connect-A8 message. Refer to the call flows in section 3.17.4 for packet data reactivation from Dormant State.
If the parameters become available at the PDSN or change while the packet data session is active, the PDSN may send a Session Parameters NVSE in the A11 Session Update message. The PCF may forward the parameters to the BS using the A9-Update-A8 message. The following call flow describes a PDSN initiated packet data session update procedure when the packet data session is active.
215 Section 3
3GPP2 A.S0013-D v2.0
MS BS PCF PDSN
time comment
Active Packet Data Session
A11-Session Update
A9-Update-A8
A9-Update-A8 Ack
Tsesupd
A11-Session Update Ack
Tupd9d
Active Packet Data Session
a
b
c
d
e
conditional
conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
Figure 3.17.9-1 PDSN Initiated Packet Data Session Update
a. The packet data session is in the Active State.
b. The PDSN initiates the transfer of a new or updated packet session parameter(s) by sending an A11-Session Update message to the PCF including the new or updated parameters in an NVSE. The PDSN starts timer Tsesupd.
c. For parameters that do not affect the BS behavior, steps ‘c’ and ‘d’ may be omitted. The PCF sends an A9-Update-A8 message to the BS with the new or updated packet session parameters. The PCF starts timer Tupd9.
d. The BS responds by sending an A9-Update-A8 Ack message to the PCF with the results of processing the session parameter(s) update. The PCF stops timer Tupd9.
e. The PCF sends an A11-Session Update Acknowledge message to the PDSN indicating the results of the session update procedure. The PDSN stops timer Tsesupd.
3.17.10 Flow Control 14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
The Flow Control procedure for GRE packets is enabled by the PDSN during the A10 setup procedure for a PDSI. The PDSN enables this feature by including an NVSE indicator in the first A11-Registration Reply message. If the PDSN indicates that it supports Flow Control for the corresponding A10 connection, the PCF may send flow control signals for the A10 connection to the PDSN by setting certain fields in the GRE packet frame. For a description of the GRE frame and the fields associated with flow control, refer to [12]. Note: a mobility event indication results in erasing an XOFF condition at the PDSN.
The PDSN should react to the XOFF indication by suspending transmission of packets towards the MS. If, after sending an XOFF indication to the PDSN, the PCF receives a GRE frame from the PDSN and user data can still not be delivered to the MS, the PCF shall resend an XOFF indication to the PDSN.
This feature utilizes the same call flows as for the A10/A11 interface (refer to section 3.17.4).
Section 3 216
3GPP2 A.S0013-D v2.0
3.18 Voice and Packet Concurrent Service 1
2
3
4
5
6
7
This section describes call flows associated with Concurrent Services. Concurrent service provides support for one voice call and one packet data session (which may be comprised of one or more PDSIs) simultaneously. Other service combinations may be supported by a future release.
Refer to [28] for further explanation of MSC operations and [8] for further explanation of PDSN operations.
3.18.1 Concurrent Service Examples - Mobile Origination 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
The following subsections describe the call flows for establishing one or more additional service option connection(s) through an MS originated action while the MS is already active with another service. Mobile originated concurrent service setup involves exchange of the following messages:
Additional Service Request
Assignment Request
Assignment Failure
Assignment Complete
A9-Setup-A8
A9-Connect-A8
A11-Registration Request
A11-Registration Reply
Bearer Update Request
Bearer Update Response.
3.18.1.1 Mobile Initiated Packet Data Service Connection, Packet Data Session is Null or Dormant, Voice Service is Already Active 24
25
26
27
28
29
30
31
This section describes the call flow associated with an MS initiated packet data service connection in the system for the case that the MS is engaged in an active voice call. The MS initiates a packet data service connection to setup its first or main PDSI, to set up an auxiliary service instance (while all other service instances are dormant), or to reactivate a dormant service instance. In the first case, the MS performs PPP negotiation over packet data connection / service instance before user data transfer. The call flow applies to all three cases.
217 Section 3
3GPP2 A.S0013-D v2.0
AssignmentRequest
BS 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
A10 Connection Establishment
procedure
T303
T10
TA8-setup
Concurrent Service Active
Establishing PPP connection j
Voice Active, Packet Data Session Null or Dormant
time
Service negotiation procedures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.18.1.1-1 Mobile Initiated Packet Data Service Connection, Packet Data Session Null or Dormant, Voice Service is Already Active
a. The MS transmits an Enhanced Origination Message, with layer 2 acknowledgment required, over the traffic channel of the air interface to the BS to request service.
b. The BS acknowledges the receipt of the Enhanced Origination Message with a Base Station Acknowledgment Order to the MS.
c. The BS constructs the Additional Service Request message, sends the message to the MSC, and starts timer T303.
d. The MSC sends an Assignment Request message to the BS to request assignment of radio resources and starts timer T10. For packet data service, an additional terrestrial circuit or A2p connection is not required. The BS stops timer T303 upon receipt of the Assignment Request message.
e. Service Negotiation procedures take place to associate the service instance with the traffic channel.
f. The BS transmits an A9-Setup-A8 message to the PCF to establish an A8 connection and starts timer TA8-setup.
g. Procedure for establishing an A10 connection is performed.
h. Upon establishment of the A10 connection, the PCF establishes an A8 connection and transmits an A9-Connect-A8 message. Upon receiving the A9-Connect-A8 message, the BS stops timer TA8-setup.
Section 3 218
3GPP2 A.S0013-D v2.0
i. The BS transmits an Assignment Complete message. The MSC stops timer T10. This step may occur any time after radio link establishment.
1
2
3
4
5
j. If the packet data connection is to enable the MS to set up its first service instance, PPP connection establishment procedures and Mobile IP Registration (if required) on the PPP connection are performed between the MS and PDSN.
3.18.1.2 Mobile Initiated Voice Service Connection, Packet Data Session is Already Active 6
7
8
9
10
This section describes the call flow associated with an MS initiated voice service connection in the system for the case that the MS is engaged in an active packet data session (at least one PDSI is active).
3.18.1.2.1 Mobile Initiated Voice Service Connection via a Circuit Switched MSC, Packet Data Session is Already Active 11
12
MS BS MSC time comment
Enhanced Origination Message
Base Station Ack Order
a
b
c
d
e
Additional Service Request
Assignment Request
f Assignment Complete
Ringback Tone
T10
Transparent to signaling
T303
g
Service negotiation procedures
Active packet data session
Concurrent Service active
13
14
15
16
17
18
19
20
Figure 3.18.1.2.1-1 Mobile Initiated Voice Service Connection via Circuit Switched MSC, Packet Data Session is Already Active.
a. The MS transmits an Enhanced Origination Message, with layer 2 acknowledgment required, over the traffic channel of the air interface to the BS to request voice service.
b. The BS acknowledges the receipt of the Enhanced Origination Message with a Base Station Acknowledgment Order to the MS.
219 Section 3
3GPP2 A.S0013-D v2.0
c. The BS constructs the Additional Service Request message, sends the message to the MSC, and starts timer T303. The BS may request the MSC to allocate a preferred terrestrial circuit.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
d. The MSC sends an Assignment Request message to the BS to request assignment of radio resources. This message includes information on the terrestrial circuit. The MSC then starts timer T10. If the BS requested a preferred terrestrial circuit in the Additional Service Request message and that terrestrial circuit is available (refer to [14]), the MSC shall use the same terrestrial circuit in the Assignment Request message. Otherwise, the MSC may assign a different terrestrial circuit. Upon receipt of the Assignment Request message from the MSC, the BS stops timer T303.
e. Service negotiation procedures take place to associate the new service instance with the traffic channel.
f. After the radio traffic channel and circuit have both been established and fully interconnected, the BS sends the Assignment Complete message to the MSC and considers the additional service to be in Conversation State. The MSC stops timer T10 upon receipt of the Assignment Complete message.
g. As call progress tone is applied in-band in this case, a ringback tone is available on the audio circuit path towards the MS. This step is only applicable to the additional voice service.
3.18.1.2.2 Mobile Initiated Voice Service Connection via an MSCe, Packet Data Session is Already Active 21
22
23
24
This section describes a call flow for initiating a voice service connection via an MSCe when a packet data session is already active. The BS sends the A2p bearer parameters to the MSC in the Additional Service Request message.
Section 3 220
3GPP2 A.S0013-D v2.0
1
MS BS MSCetime comment
Enhanced Origination Message
Base Station Ack Order
a
b
c
d
e
Additional Service Request
Assignment Request
f Assignment Complete
Progress Indicator
T10
Transparent to signaling
T303
Concurrent Service active
j
Service negotiation procedures
Active packet data session
Bearer Update ResponseTyyp
Bearer Update Request g
h
i
Service negotiation procedures
conditional
conditional
conditional
MGW
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Figure 3.18.1.2.2-1 Mobile Initiated Voice Service Connection via an MSCe, Packet Data Session is Already Active.
a. The MS transmits an Enhanced Origination Message, with layer 2 acknowledgment required, over the traffic channel of the air interface to the BS to request voice service.
b. The BS acknowledges the receipt of the Enhanced Origination Message with a Base Station Acknowledgment Order to the MS.
c. The BS constructs the Additional Service Request message, sends the message to the MSCe, and starts timer T303. The BS includes the A2p bearer parameters.
d. The MSCe sends an Assignment Request message to the BS to request assignment of radio resources. This message contains the A2p bearer parameters with the bearer format and transport address to be used.
The MSCe then starts timer T10. Upon receipt of the Assignment Request message from the MSC, the BS stops timer T303.
221 Section 3
3GPP2 A.S0013-D v2.0
e. Service negotiation procedures take place to associate the new service instance with the traffic channel.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
f. After the radio traffic channel and the BS transport facilities have been established and fully interconnected, the BS sends the Assignment Complete message to the MSCe and considers the additional service to be in Conversation State.
The MSCe stops timer T10 upon receipt of the Assignment Complete message.
g. If the MSCe determines that a change in the bearer format is required, then the MSCe sends a Bearer Update Request message. The MSCe starts timer Tyyp.
h. If the BS receives a Bearer Update Request message, the BS may need to change the traffic channel and/or the Service Option by repeating step ‘e’ as needed.
i. If a Bearer Update Request message is received, the BS sends a Bearer Update Response message to the MSCe, conveying any changes in the bearer or session address configuration for the call. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
j. As call progress tone is applied in-band in this case, ringback tones and/or audio announcements may be sent on the A2p audio path towards the MS. This step can happen anytime the A2p connection has been established. This step is only applicable to the additional voice service.
3.18.1.3 Mobile Initiated Packet Data Service Connection, Packet Data Session is Already Active, Voice Service is Already Active 20
21
22
23
24
25
26
27
This section describes the call flow associated with an MS initiated packet data service connection for the case where the MS already has an active packet data session (i.e. at least one PDSI is active) and it is also engaged in an active voice call. The MS initiates auxiliary packet data service connection to set up an auxiliary service instance or to reactivate a dormant auxiliary packet service instance.
This call flow procedure is identical to those in section 3.17.4.2.2 with the exception that voice service is already active in addition to the packet data session being active.
3.18.1.4 Mobile Initiated Voice Service Connection, Packet Data Session is Dormant 28
29
30
This call flow is identical to a regular MS initiated voice service connection. Refer to section 3.1.1.
3.18.2 Concurrent Service Examples - Mobile Termination 31
32
33
34
35
36
37
38
39
40
41
The following call flow illustrates the procedures for establishing a mobile terminated voice call while the MS is maintaining an active packet data session. Mobile terminated concurrent voice service setup involves exchange of the following A1 or A1p messages:
Additional Service Notification
Additional Service Request
Assignment Request
Assignment Failure
Assignment Complete
Connect
Bearer Update Request
Section 3 222
3GPP2 A.S0013-D v2.0
Bearer Update Response. 1
2 3.18.2.1 Mobile Termination via a Circuit Switched MSC for Voice Service, Packet Data Session is Already Active 3
4
Active Packet Data Session
Service negotiation procedures
Additional Service Request
Additional Service Notification
Assignment Request
Assignment Complete
T10
e
d
c
b
a
T301 Extended Alert
with Info
MS BS MSC time
f
g
h
i
j Connect
MS Ack Order
Connect Order
BS Ack Order
T314
T303
Concurrent Service active
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.18.2.1-1 Mobile Termination via a Circuit Switched MSC for Voice Service, Packet Data Session is Already Active
a. The MSC sends an Additional Service Notification message to the BS to initiate a voice service option connection. The MSC starts timer T314.
b. The BS constructs the Additional Service Request message, sends the message to the MSC, and starts timer T303. The BS may request the MSC to allocate a preferred terrestrial circuit. The MSC stops timer T314 upon receipt of the Additional Service Request message from the BS.
c. The MSC sends an Assignment Request message to the BS to request assignment of radio resources. This message includes information on the terrestrial circuit. The MSC starts timer T10.
If the BS requested a preferred terrestrial circuit in the Additional Service Request message and that terrestrial circuit is available (refer to [14]), the MSC shall use the same terrestrial circuit in the Assignment Request message. Otherwise, the MSC may assign a different terrestrial circuit. Upon receipt of the Assignment Request message from the MSC, the BS stops timer T303.
223 Section 3
3GPP2 A.S0013-D v2.0
d. Service negotiation procedures take place to associate the service instance with the traffic channel.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
e. After the radio traffic channel and circuit have both been established and fully interconnected, the BS sends the Assignment Complete message to the MSC. The MSC stops timer T10 upon receipt of the Assignment Complete message. The MSC starts timer T301.
f. The BS sends the Extended Alert with Information Message to the MS to cause ringing at the MS.
g. The MS acknowledges the reception of the Alert with Information Message by transmitting the Mobile Station Acknowledgment Order.
h. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted to the BS.
i. The BS acknowledges the Connect Order with the Base Station Acknowledgment Order over the forward traffic channel.
j. The BS sends a Connect message to the MSC to indicate that the call has been answered at the MS. At this point, the call is considered stable and in the Conversation State. The MSC stops timer T301 upon receipt of the Connect message from the BS.
3.18.2.2 Mobile Termination via an MSCe for Voice Service, Packet Data Session is Already Active 20
21
22
23
This section describes a call flow for terminating a voice service connection via an MSCe when a packet data session is already active. The BS sends the A2p bearer parameters to the MSC in the Additional Service Request message.
Section 3 224
3GPP2 A.S0013-D v2.0
Active Packet Data Session
Service negotiation procedures
BS MS MSCe time comment
c
d
e
i
j
k
l
Additional Service Request
Assignment Request
m
Assignment CompleteT10
Connect
b
a Additional Service Notification
Extended Alert with Info
MS Ack Order
BS Ack Order
T314
T303
Bearer Update ResponseTyyp
Bearer Update Request f
g
h
Service negotiation procedures
Connect Order
T301
conditional
conditional
conditional
Connected Concurrent Active
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.18.2.2-1 Mobile Termination via an MSCe for Voice Service, Packet Data Session is Already Active
a. The MSCe sends an Additional Service Notification message to the BS to initiate a voice service option connection. This message includes A2p bearer parameters. The MSCe starts timer T314.
b. The BS constructs the Additional Service Request message, sends the message to the MSCe, and starts timer T303. The BS includes the A2p bearer parameters in the Additional Service Request message. The MSCe stops timer T314 upon receipt of the Additional Service Request message from the BS.
c. The MSCe sends an Assignment Request message to the BS to request assignment of radio resources. This message contains the A2p bearer parameters with the bearer format and transport address to be used.
The MSC starts timer T10. Upon receipt of the Assignment Request message from the MSCe, the BS stops timer T303.
d. Service negotiation procedures take place to associate the service instance with the traffic channel.
225 Section 3
3GPP2 A.S0013-D v2.0
e. After the radio traffic channel and bearer connection have been established, the BS sends the Assignment Complete message to the MSCe. The MSCe stops timer T10 upon receipt of the Assignment Complete message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
The MSCe starts timer T301.
f. If the MSCe determines that a change in the bearer format is required, then the MSCe sends a Bearer Update Request message. The MSCe starts timer Tyyp.
g. If the BS receives a Bearer Update Request message, the BS may need to change the traffic channel and/or the Service Option by repeating step ‘d’ as needed.
h. If a Bearer Update Request message is received, the BS sends a Bearer Update Response message to the MSCe, conveying any changes in the bearer or session address configuration for the call. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
i. The BS sends the Extended Alert with Information Message to the MS to cause ringing at the MS. This step can occur anytime after the A2p bearer connection has been established.
j. The MS acknowledges the reception of the Extended Alert with Information Message by transmitting the Mobile Station Acknowledgment Order.
k. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted to the BS.
l. The BS acknowledges the Connect Order with the Base Station Acknowledgment Order over the forward traffic channel.
m. The BS sends a Connect message to the MSCe to indicate that the call has been answered at the MS. At this point, the call is considered stable and in the Conversation State. The MSCe stops timer T301 upon receipt of the Connect message from the BS.
3.18.3 Concurrent Service Examples - Network Initiated PDSI Re-Activation 27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
The following subsections describe the call flows for establishing a packet data connection (i.e. re-activating a PDSI) to an MS that already has an active voice call and may or may not have an active PDSI. The call flow is triggered by a request from the PDSN (through the PCF) to send data packets to the MS. Network initiated call setup for concurrent service involves exchange of the following messages:
Additional Service Request
Assignment Request
Assignment Failure
Assignment Complete
Additional Service Notification
A9-BS Service Request
A9-BS Service Response
A9-Setup-A8
A9-Connect-A8
A11-Registration Request
Section 3 226
3GPP2 A.S0013-D v2.0
A11-Registration Reply. 1
2 3.18.3.1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a Voice Service, Packet Data Session is Dormant: Case 1 3
4
5
6
7
8
9
The following call flow provides an illustration for a successful dormant packet data service reactivation procedure, when the MS is already active with voice service and the packet data session is dormant. In this call scenario it is assumed that the BS selected by the PCF is aware or can determine that the MS in question can support concurrent services. In this scenario, it is assumed that the PCF sends the A9-BS Service Request message to the BS that the voice call is currently anchored on.
MS time
a
b
c
d
e
f
g
j
A9-Setup-A8
A9-Connect-A8
Assignment Complete
TA8-setup
T10
Voice Active, Packet Dormant, PPP connection is maintained
Packet Data Traffic
A9-BS Service Request
Additional Service Request
Assignment Request
A9-BS Service Response
BS MSC / VLR PDSN PCF
Tbsreq9T303
Concurrent Service Active
i
Service negotiation procedures
A11 Accounting Procedures h
10
11
12
13
14
Figure 3.18.3.1-1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a Voice Service, Packet Data Session is Dormant, Case 1
a. The PDSN sends data packets to the PCF on an existing A10 connection associated with a specific MS for packet service.
227 Section 3
3GPP2 A.S0013-D v2.0
b. The PCF sends an A9-BS Service Request message containing the SR_ID of a dormant PDSI to the BS where it last registered the presence of the MS to request reactivation of that PDSI and starts timer Tbsreq9.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
c. The BS sends an Additional Service Request message to the MSC to reconnect the packet data service option connection and starts timer T303.
d. The MSC sends an Assignment Request message to the BS to request assignment of radio resources and the A8 (User Traffic) connection between the BS and the PCF. The MSC starts timer T10. Upon receipt of the Assignment Request message from the MSC, the BS stops timer T303.
e. The BS responds with an A9-BS Service Response message. The PCF stops timer Tbsreq9 upon receipt of the A9-BS Service Response message.
f. Service negotiation procedures take place to associate the service instance with the traffic channel.
g. The BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) connection between the BS and the PCF. The BS then starts timer TA8-setup.
h. A11 accounting procedures take place on the A11 interface.
i. The PCF responds with an A9-Connect-A8 message to complete the setup of the A8 (User Traffic) connection for this packet service request. Upon receipt of the A9-Connect-A8 message from the PCF, the BS stops timer TA8-setup.
j. The BS sends an Assignment Complete message to the MSC. The MSC stops timer T10. This step may occur anytime after step ‘f’.
3.18.3.2 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a Voice Service and the Packet Data Session is Dormant; Case 2 23
24
25
26
27
28
29
30
The following call flow provides an illustration of a successful PDSI reactivation procedure for the case where an MS is active with a voice service and has performed an inter-BS/intra-PCF voice call handoff, resulting in the MS communicating with a BS different from the BS selected by the PCF. The call flow also serves as an illustration of the case when the selected BS is communicating with the MS, but the BS is unaware if the MS supports concurrent services. In the latter case the selected BS and controlling BS are identical.
Section 3 228
3GPP2 A.S0013-D v2.0
k
MS time
ab
c
d
e
f
g
h
i
A9-Setup-A8
A9-Connect-A8
Assignment Complete
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
Selected BS MSC / VLR PDSN PCF
Tbsreq9T311
Concurrent Service Active
Controlling BS
Additional Service Notification
Additional Service Request
Assignment Request
T314 T303
l
j
Service negotiation procedures
A11 Accounting Procedures
m
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.18.3.2-1 Network Initiated PDSI Re-Activation from Dormant State, MS is Active with a Voice Service and the Packet Data Session is Dormant; Case 2
a. The PDSN sends data packets to the PCF on an existing PPP connection and A10 connection associated with a specific MS and PDSI.
b. The PCF sends an A9-BS Service Request message containing the SR_ID of a dormant PDSI to the selected BS where it last registered the presence of the MS to request reactivation of that PDSI, and starts timer Tbsreq9.
c. The selected BS sends a BS Service Request message to the MSC and starts timer T311. The BS Service Request message contains the SR_ID of the service instance to be reactivated.
Note: Because the MS was involved in an intra-PCF voice call handoff, the selected BS does not have control of the MS and thus it sends a BS Service Request message to the MSC, to initiate an MS terminated call setup. Alternatively, if the MS is under the control of the selected BS, but the selected BS is not aware of the MS’s concurrent services capabilities or subscription, it may also send a BS Service Request to the MSC. Refer to section 3.17.4.12.
d. The MSC recognizes that the MS has performed a voice call hand off to the controlling BS and sends a BS Service Response message to the selected BS. The selected BS stops timer T311 upon receipt of the BS Service Response message from the MSC.
229 Section 3
3GPP2 A.S0013-D v2.0
e. The selected BS responds with A9-BS Service Response message to the PCF. The PCF stops timer Tbsreq9 upon receipt of the A9-BS Service Response message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
f. The MSC sends an Additional Service Notification message to the controlling BS (i.e., the BS which is communicating with the MS) to initiate an additional service option connection and starts timer T314.
g. The controlling BS sends an Additional Service Request message to the MSC and starts timer T303. The MSC stops timer T314 upon receipt of the Additional Service Request message from the controlling BS.
h. The MSC sends an Assignment Request message to the controlling BS to request assignment of radio resources. The Assignment Request message contains the SR_ID of the PDSI to be reactivated. The MSC starts timer T10.
Upon receipt of the Assignment Request message from the MSC, the controlling BS stops timer T303.
i. Service negotiation procedures take place to associate the service instance with the traffic channel.
j. The controlling BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) connection between controlling BS and the PCF. The controlling BS starts timer TA8-setup.
k. A11 accounting procedures takes place on the A11 interface
l. The PCF responds with an A9-Connect-A8 message to complete the setup of the A8 (User Traffic) connection for the PDSI reactivation request. Upon receipt of the A9-Connect-A8 message from the PCF, the controlling BS stops timer TA8-setup.
m. After the radio link and the A8 connection have been established, the controlling BS sends an Assignment Complete message to the MSC. The MSC stops timer T10.
3.18.3.3 Network Initiated Service Instance Reactivation When There is Another Active PDSI and MS is Already Active with a Voice Service 26
27
28
29
30
31
This section describes the call flow for network initiated reactivation of a PDSI from the Dormant State when the MS already has an active packet data service session and is engaged in an active voice call.
The steps of this call flow are essentially the same as the call flow in section 3.17.4.11.2 with the exception that voice service is active.
3.18.4 Concurrent Services: Call Clearing Examples 32
3.18.4.1 Call Clear via Service Release – MS Initiated 33
34
35
36
37
38
39
40
41
This section describes the call flow associated with a single service instance release initiated by the MS when a voice or circuit data service option connection and one or more active PDSI s exist in the system.
When the MS initiates a normal clearing of a single service that is not the only service connected, the MS sends one of the Service Request Message (SRQM), Resource Release Request Message (RRRM) or Resource Release Request Mini Message (RRRMM). The BS shall send a Service Release message to the MSC and start timer T308 to wait for the Service Release Complete message from the MSC.
Section 3 230
3GPP2 A.S0013-D v2.0
MS MSC time comment
SreqM/RRRM/RRRMM a
b
c
d
Service Release
Service Release Complete
T308
BS
Concurrent Service active
Service negotiation procedures
Conditional
Conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.18.4.1-1 Releasing a Service That Is Not the Only One Connected (MS Initiated)
a. The MS sends either the Service Request Message, Resource Release Request Message or Resource Release Request Mini Message (RRRMM) to release either the voice service option or an active packet data service option. If a packet data service option is being released, the MS uses the Purge Indicator in the Resource Release Request Message / Mini Message to indicate whether the associated PDSI is being released to the Null State or to the Dormant State.
b. If either the voice service instance or the last active PDSI is being released, the BS sends a Service Release message to the MSC to clear the call control transaction associated with the service. The BS starts timer T308.
c. If the BS sent a Service Release message in step ‘b’, upon receiving the Service Release Message from the BS, the MSC releases the service option connection identifier, the A2p connection or terrestrial circuit (if allocated for the associated service), and sends a Service Release Complete Message to the BS. Upon receipt of the Service Release Complete Message, the BS stops timer T308.
d. If the BS sent a Service Release message in step ‘b’, it shall wait for the associated Service Release Complete message (step ‘c’), before it proceeds with this step. Service negotiation procedures take place to dissociate the service instance from the traffic channel. In the case of a PDSI release, refer to section 3.17.4.6.2 (release to Dormant State) or 3.17.4.22.2 (release to Null State) for the procedures associated with the release of this service.
3.18.4.2 Call Clear via Service Release - MSC Initiated 23
24
25
26
27
28
This section describes the call flow associated with a voice or a packet data service option connection release initiated by the MSC when a voice service option connection and one or more active PDSIs exist in the system. If the MSC releases a packet data service option connection, the BS releases the associated packet data session to the Null/Inactive State.
231 Section 3
3GPP2 A.S0013-D v2.0
MS MSC time
a
b
c
Service Release
Service ReleaseComplete
T308
BS
Concurrent Service active
Service Negotiation
PCF PDSN
A9-Release-A8
A9-Release-A8Complete
A10 Connection Release
procedures
Trel9 d
e
f 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Figure 3.18.4.2-1 Releasing a Service That Is Not the Only One Connected (MSC Initiated)
a. The MSC sends a Service Release message to the BS to instruct the BS to release the call control transaction associated with either the voice service option or with the packet data service option and starts timer T308. In the case of packet data service option release the packet data session is released to Null State (i.e. all PDSIs are released).
b. The MS and the BS perform service negotiation procedures.
In the case of a voice service option connection release, the following three steps (steps ‘c’, ‘d’, and ‘e’) are skipped and the call flow continues with step ‘f’.
c. The BS sends an A9-Release-A8 message with a cause value set to “Packet data session release” to the PCF to instruct the PCF to release the dedicated resources associated with all PDSIs (both active and dormant) of the MS, and to release the associated A10 connection(s). The BS uses the SR_ID of any one of the active PDSIs in the A9-Release-A8 message. The BS starts timer Trel9.
d. The PCF initiates the procedure for releasing all A10 connections. Refer to section 3.17.4.7 for details.
e. The PCF sends an A9-Release-A8 Complete message to the BS. The BS stops timer Trel9. The BS and PCF release all A8 connections for the MS.
f. The BS releases the service option connection identifier, the A2p connection or terrestrial circuit (if allocated for the associated service), and sends a Service Release Complete message to the MSC. Upon receipt of the Service Release Complete, the MSC stops timer T308.
Section 3 232
3GPP2 A.S0013-D v2.0
3.18.4.3 PDSN Initiated Service Instance Release, Voice Service is Active 1
2
3
4
5
6
7
8
9
10
11
12
This section describes the call flows associated with a PDSN initiated packet service instance release to Null State while the MS is engaged in a voice call. The section considers the cases when:
i. Service instance to be released is dormant
ii. Service instance to be released is active and there is at least one other active PDSI
iii. Service instance to be released is the only active PDSI.
The case ‘i’ call flow is the same as that in section 3.17.4.8.1 with the exception that the voice service is active at the beginning and end of the call flow.
The case ‘ii’ call flow is the same as that in section 3.17.4.8.2 with the exception that the voice service is active at the beginning and end of the call flow.
The case ‘iii’ call flow is shown in this section.
3.18.4.3.1 PDSN Initiated Release of Last Active PDSI, Voice Service is Active 13
=
Service ReleaseComplete
Service Release
MS BS MSC/VLR PCF PDSN time
A9-Disconnect-A8 a
b
c
e
f
g
A9-Release-A8
A9-Release-A8 Complete
Tdiscon9
Trel9
T300
Service Negotiation
One Active Packet Data Service Instance, Voice Service Active
Dormant or Null Packet Data Session, Voice Service Active
d
A10 Connection
Release Procedure
14
15
16
Figure 3.18.4.3.1-1 PDSN Initiated Service Release of the Last Active PDSI – Voice Service Active
233 Section 3
3GPP2 A.S0013-D v2.0
a. The PDSN releases the A10 connection for the active PDSI. Refer to section 3.17.4.8. If the packet data session transitions to the dormant state, the PCF sends the ‘All-Dormant Indicator’ to the PDSN that is part of this release procedure.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
b. When the PCF recognizes that the A10 connection has been released, the PCF sends an A9-Disconnect-A8 message to the BS and starts timer Tdiscon9.
c. The BS initiates release of the A8 connection by transmitting an A9-Release-A8 message and starts timer Trel9. The PCF stops timer Tdiscon9.
d. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete. The BS stops timer Trel9.
e. The BS the sends a Service Release message to the MSC and starts timer T300. This message contains the cause value “packet call going dormant” if the BS is aware of other dormant PDSIs. If no other dormant service instances exist the message contains a cause element indicating “PPP session closed by MS”.
f. The MSC sends a Service Release Complete message to the BS to instruct the BS to release the associated dedicated resources. The BS stops timer T300.
g. Service negotiation procedures take place.
3.18.4.4 BS Initiated Release to Dormant State of a PDSI, Voice Service is Active 17
18
19
20
21
22
23
24
25
26
This section describes the call flow associated with a BS initiated packet service instance deactivation (Active-to-Dormant State transition) while a voice service is active. This section considers the cases where:
i. There are two or more active PDSIs
ii. There is only one active PDSI.
The case ‘i’ call flow is the same as in section 3.17.4.5.2 with the exception that there exists a voice service.
The case ‘ii’ call flow is shown in this section.
3.18.4.4.1 BS Initiated Release to Dormant State of Last Active PDSI, Voice Service is Active 27
28
29
For this example, it is assumed that the PDSI(s) is/are not in inter-BS soft/softer handoff prior to deactivation.
Section 3 234
3GPP2 A.S0013-D v2.0
Service Release
A9-Release-A8
Service Release Complete
A9-Release-A8 Complete
MS BS MSC/VLR PCF PDSN time
a
b
c
d
e
g
h
T308
Trel9
Service Negotiation
A11 Accounting
Update Procedures
f
Dormant Packet Data Session, Voice Service Active
Active Packet Data Session, Voice Service Active
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.18.4.4.1-1 BS Initiated Service Instance Release to Dormant State of Last Active PDSI, Voice Service Active
a. The MS has an active packet data session and a voice call.
b. If the packet data inactivity timer expires, the BS should renegotiate the Traffic Channel. The BS sends a Service Release message to the MSC to initiate the call clear transaction and starts timer T308.
c. The MSC sends a Service Release Complete message to the BS to instruct the BS to release the associated dedicated resources. The BS stops timer T308.
d. The BS initiates service negotiation to release the active PDSI.
e. The BS then sends an A9-Release-A8 message to the PCF to instruct the PCF to release the associated dedicated resources, and starts timer Trel9. Note that in this scenario the A10 connection is not released.
f The PCF sends an A11-Registration Request message with an Active Stop airlink accounting record for the released service instance and an ‘All Dormant’ indicator, which the PDSN acknowledges with an A11-Registration Reply message.
g. The PCF acknowledges the A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
h. At this point, the packet data session is considered to be in the Dormant State.
235 Section 3
3GPP2 A.S0013-D v2.0
3.18.5 Concurrent Service - Handoff 1
2 This section describes the handoff call flows for concurrent service.
3.18.5.1 Concurrent Service (Active Voice and Packet Data Services) - Hard Handoff 3
4
5
6
7
8
9
10
This section describes call flows for the successful hard handoff of an MS that is engaged in active voice and packet data calls simultaneously.
If the target MSC is an MSCe, the Handoff Request message sent by it may contain A2p bearer addresses and the corresponding the Handoff Request Ack message contains A2p bearer parameters for the voice call. Also, in this scenario, a pair of Bearer Update Request and Bearer Update Response messages may be exchanged between the MSCe and the BS after the Handoff Request Ack, as shown in section 3.19.3.1.2.
3.18.5.1.1 Successful Inter-BS Hard Handoff Call Flows (Within the Same PCF) 11
12
13
14
15
16
The call flows in this section are identical to the call flows described in section 3.17.4.18, except that in this case an active voice call is also present and the target BS sends the Handoff Complete message after acquiring the MS, rather than after receiving the A9-AL Connected Ack message from the PCF.
3.18.5.1.2 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by the Same PDSN) 17
18
19
20
21
The call flows in this section are identical to the call flows described in section 3.17.4.19, except that in this case an active voice call is also present and the target BS sends the Handoff Complete message after acquiring the MS, rather than after receiving the A9-AL Connected Ack message from the PCF.
3.18.5.1.3 Successful Inter-PCF Hard Handoff Call Flows (Mobile Served by New PDSN) 22
23
24
25
26
The call flows in this section are identical to the call flows described in section 3.17.4.21, except that in this case an active voice call is also present and the target BS sends the Handoff Complete message after acquiring the MS, rather than after receiving the A9-AL Connected Ack message from the PCF.
3.18.5.2 Concurrent Service (Active Voice and Dormant Packet Data Services) - Handoff 27
28
29
This section describes call flows for the successful handoff of an MS that is engaged in an active voice call and has a dormant packet data session.
3.18.5.2.1 Successful Inter-PCF Handoff Call Flows (Mobile Served by the Same PDSN) 30
31
32
33
34
35
This section describes the call flows for the successful handoff between PCFs being served by the same PDSN of an MS that is engaged in an active voice call and has a dormant packet data session. It is assumed that the PCFs are in different packet zones, and that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no A3 connections need to be removed.
Section 3 236
3GPP2 A.S0013-D v2.0
Active Voice Session, Dormant Packet Data Session
Active Voice Service
Handoff b
a
time MS Source BS Target BS
Source PCF PDSN
TargetPCF
MSC
d
e
f
g
h
i PDSN Dormant HO Procedures
j
k
l
Enhanced Origination Message
BS Ack Order Additional Service
Request
Assignment Request T303
A9-Setup-A8
TA8-setup
Assignment Failure
A9-Release-A8 Complete
T10
Service Release
Service Release Complete
T20
T308 m
n Active Voice Session, Dormant Packet Data Session
c
In Traffic System Parameter Message
1
2
3
4
5
6
7
8
9
Figure 3.18.5.2.1-1 Successful Inter-PCF Handoff (Mobile Served by the Same PDSN)
a. The MS currently has a voice call active and a packet data session that is dormant. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS.
b. The voice service is handed off as shown in section 3.19.3.1.
c. The target BS, upon detecting that the MS has arrived from a different packet zone, sends an In-Traffic System Parameter Message to the MS indicating the current
237 Section 3
3GPP2 A.S0013-D v2.0
packet zone (CANID). The MS may acknowledge the In-Traffic System Parameter Message by sending an MS Ack Order to the target BS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
d. The MS detects a change in packet zone and sends an Enhanced Origination Message to the target BS with DRS bit set to ‘0’ for each of its dormant PDSIs. Steps ‘d’ through ‘m’ are repeated for each dormant PDSI.
e. The target BS acknowledges receipt of each Enhanced Origination Message by sending a BS Ack Order to the MS.
f. The target BS sends an Additional Service Request message to the MSC and starts timer T303. Note this step only occurs if there is no active PDSI at the time the BS receives the Enhanced Origination Message.
g. The MSC sends an Assignment Request message to the target BS and starts timer T10. Upon receipt of the Assignment Request message, the target BS stops timer T303.
h. For each service instance, the target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the PCF and starts an associated timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
i. For each service instance, the target PCF establishes an A10 link and the PDSN disconnects the old A10 link (refer to procedure in section 3.17.4.19). (If the PDSN has data for the MS on an A10 connection, it responds to the PCF with an A11-Registration Reply message with the Data Available Indicator in the CVSE.)
j. For each service instance, the PCF responds to the BS with an A9-Release-A8 Complete message. The BS stops the associated timer TA8-setup.
If the PDSN responds to the PCF with a Data Available Indicator for any of the service instances, the PCF responds to the BS with an A9-Connect-A8 message with cause element set to ‘Data ready to send’. Note: The target BS and MS engage in over the air service negotiation to connect the packet data service instances for which the PDSN indicated data available. In this case, the remaining steps in this scenario are ignored.
k. The BS sends an Assignment Failure message to the MSC with cause value indicating ‘Packet call going dormant’ and starts associated timer T20. The MSC stops timer T10 associated with the transaction.
l. The MSC sends a Service Release message to the target BS with cause value set to ‘Packet call going dormant’ and starts timer T308.
m. The target BS sends a Service Release Complete message to the MSC. Upon receipt of the Service Release Complete message, the MSC stops timer T308.
n. The voice call is now active, and the packet data session is dormant.
3.18.5.2.2 Successful Inter-PCF Handoff Call Flow (Mobile Served by New PDSN) 37
38
39
40
41
42
This section describes the call flows for the successful handoff between PCFs being served by different PDSNs of an MS that is engaged in an active voice call and has a dormant packet data session. It is assumed that the PCFs are in different packet zones, and that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no A3 connections need to be removed.
Section 3 238
3GPP2 A.S0013-D v2.0
Active voice service, dormant packet data session
Active voice service handoff
a
b
time Target BS
c
d
ef
g
h
i A10 Connection Establishment
j
k
l
MS Source BS MSCSourcePCF
TargetPCF PDSN
Enhanced Origination Message
BS Ack Order Additional Service Request
Assignment Request T303
A9-Setup-A8
TA8-setup
A9-Connect-A8
T10
Assignment Complete
Service Negotiation
Establish PPP connection m
In Traffic System Parameter Message
1
2
3
4
5
6
7
8
9
Figure 3.18.5.2.2-1 Successful Inter-PCF Handoff (Mobile Served by New PDSN)
a. The MS currently has a voice call active and a packet data session that is dormant. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS.
b. The voice service is handed off as shown in section 3.19.3.1.
c. The target BS, upon detecting that the MS has arrived from a different packet zone, sends an In-Traffic System Parameter Message to the MS indicating the current
239 Section 3
3GPP2 A.S0013-D v2.0
packet zone (CANID). The MS may acknowledge the In-Traffic System Parameter Message by sending an MS Ack Order to the target BS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
d. The MS detects a change in packet zone and sends an Enhanced Origination Message to the target BS with DRS bit set to ‘0’.
e. The target BS acknowledges receipt of the Enhanced Origination Message by sending a BS Ack Order to the MS.
f. The target BS sends an Additional Service Request message to the MSC and starts timer T303.
g. The MSC sends an Assignment Request message to the target BS and starts timer T10. Upon receipt or the Assignment Request message, the target BS stops timer T303.
h. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the PCF and starts an associated timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
i. The target PCF establishes an A10 link with the new PDSN (refer to procedure in section 3.17.4.21). The PDSN responds to the PCF with an A11-Registration Reply message with the Data Available Indicator in the CVSE.
j. The target PCF sends an A9-Connect-A8 message with Traffic Channel Required indicator set to the target BS.
k. The target BS and the MS engage in over the air service negotiation to connect the PDSIs.
l. Upon establishment of the A8 and A10 connections and service negotiation, the target BS sends an Assignment Complete message to the MSC. The MSC stops timer T10.
m. Establishment of the PPP connection between the MS and PDSN is now possible over the main service instance. Mobile IP Registration may be performed once the PPP link has been established. Following MIP registration (if required), if neither the MS nor the PDSN has data to send, the PDSI may again transition to dormant (refer to section 3.17.4.6).
3.18.5.3 Concurrent Service - Soft / Softer Handoff 30
31 The same procedures as in section 3.19.2 apply for this scenario.
3.19 Handoff 32
33
34
35
36
37
38
Inter-BS hard handoffs are discussed in section 3.19.1.2 (Inter-BS Hard Handoff), and intra-BS handoffs are discussed in section 3.19.1.5 (Intra-BS Handoff). Inter-BS soft/softer handoff is discussed in section 3.19.2 (Handoff via Direct BS-to-BS Signaling). Call flows for each of these procedures can be found in section 3.19.3 (Handoff Call Flows). Message formats and definitions of timers used within this chapter can be found in the associated interface documents.
Section 3 240
3GPP2 A.S0013-D v2.0
3.19.1 Handoff via MSC 1
3.19.1.1 Introduction 2
3
4
This section describes handoff via the MSC procedures; refer to section 2.19.1 and [28] for more information.
3.19.1.1.1 Recognition That a Handoff is Required by a BS 5
6
7
8
9
10
The BS shall be able to generate an indication to the MSC that a hard handoff may be required using the protocols defined.
No additional guidance is given within this specification concerning the algorithm within the BS that generates either an intra-BS handoff, or an indication to the MSC that an inter-BS hard handoff is required.
3.19.1.1.2 Recognition That a Handoff is Required by the MSC 11
12 For this version of the standard, the MSC may not autonomously precipitate a handoff.
3.19.1.1.3 Concept of “Designated Cell” 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
A “designated cell” is a cell identifier (cell + sector) that is chosen by the BS to represent the MS’s location. The initial cell identifier associated with the MS’s activity (origination, termination, etc.) is by definition the first “designated cell”. When the air interface only supports connection of the MS to a single sector at a time, the “designated cell” is the currently connected sector. When the air interface supports connection of an MS to multiple sectors (possibly on different cells) simultaneously, e.g., CDMA soft/softer handoff, a single “designated cell” is to be identified to the MSC.
As long as the original cell identifier that was provided to the MSC to identify the initial “designated cell” remains on the call, it may remain the “designated cell”. When the sector identified as the “designated cell” is removed from the call, the BS currently serving as the source BS for the call chooses a new “designated cell” from the set of sectors serving the call and shall provide the appropriate cell identifier to the MSC. The source BS may choose a new “designated cell” at any time from the set of cells currently serving the call. The technique for choosing a “designated cell” is an operator/manufacturer concern.
The notification to the MSC can be implicit through the use of the inter-BS handoff procedure (Handoff Required, Handoff Request, Handoff Request Acknowledge, Handoff Command messages), or explicit through the use of the Handoff Performed message. The implicit notification occurs when the handoff type is a hard handoff. The change of designated cell occurs upon receipt of the Handoff Complete message.
3.19.1.2 Inter-BS Hard Handoff 34
35
36
37
38
39
40
This section discusses the protocol to support hard handoff transitions where the source and target cells are under the domain of different BSs. For this version of the standard, it is assumed that the only CDMA traffic channels that may be transferred via inter-BS hard handoff are the Fundamental and Dedicated Control Channels (FCH and DCCH, resp.). Hard handoff of the Supplemental Channels and the Packet Data Channels is not supported in this version of the standard.
241 Section 3
3GPP2 A.S0013-D v2.0
For an MS operating on the CDMA traffic channel, an inter-BS hard handoff may occur while the MS is in the Conversation State or Waiting for Answer State. All connected services that are handed off shall be handed off together to the same BS.
1
2
3
3.19.1.2.1 Triggering Phase 4
5 Hard handoff triggering is initiated by the MS or the source BS.
3.19.1.2.2 Target Determination Phase 6
7
8
9
10
11
12
Having received an indication from a BS that an inter-BS hard handoff is required, the decision of when and whether an inter-BS hard handoff is to take place shall be made by the MSC. Inter-BS soft/softer handoff decisions can be made by the source and target BSs involved; refer to section 3.19.2 (Handoff via Direct BS-to-BS Signaling).
The Handoff Required message is used for this phase of the handoff; refer to [14] for procedure descriptions of this message.
3.19.1.2.3 Resource Establishment 13
14
15
16
17
18
19
When the MSC has decided that an inter-BS hard handoff shall take place, the MSC requests the resources (both bearer and radio) to complete the handoff.
The following A1/A1p interface messages are used for this phase of the handoff:
Handoff Request
Handoff Request Acknowledge
Refer to [14] for procedure descriptions of these messages.
3.19.1.2.4 Execution Phase 20
21
22
23
24
25
26
27
28
When the MSC receives information that resources have been established to complete the handoff, the MSC requests the source BS to execute the handoff. The MSC receives information from the target BS when the handoff is completed.
The following A1/A1p interface messages are used for this phase of the handoff:
Handoff Command
Handoff Commenced
Handoff Complete
Refer to [14] for procedure descriptions of these messages.
3.19.1.3 Call Clearing 29
30
31
32
33
34
The call clearing procedure is described in section 3.2. It is used in hard handoff scenarios to release the source RF channel and terrestrial resource after either the MS has been acquired by the target BS or the call is dropped.
The MSC may use call clearing to tear down either the source channel, the target channel, or both in the event of a failure in the handoff process.
Section 3 242
3GPP2 A.S0013-D v2.0
The Clear Command message shall contain a cause field to inform the source or target cell of the success or failure of the handoff procedure. This indication can be used for statistics purposes.
1
2
3
3.19.1.4 Handoff Failure Handling 4
5
6
7
8
There are two messages that indicate a failure in the handoff process: the Handoff Required Reject and the Handoff Failure messages. These messages are defined in [14]. Also, refer to section 3.19.3.1.7 (Hard Handoff With Return On Failure).
When a traffic channel is not available at the target BS, several options are available:
Option 1 The target can allocate an AMPS channel 9
Option 2 The target can indicate a failure to the MSC, and the MSC can attempt to allocate an AMPS channel.
10
11
Option 3 The target can indicate a failure and the MSC can pass this information to the source BS and let the source BS decide.
12
13
14
15
16
17
18
19
20
Option 3 shall be supported.
NOTE: This standard does not specify the messaging required for Option 1. Support and implementation of this option is a vendor concern.
Handoff Failure Handling utilizes the following interface messages:
Handoff Required Reject
Handoff Failure
Refer to [14] for procedure descriptions of these messages.
3.19.1.5 Intra-BS Handoff 21
22
23
The BS uses the Handoff Performed message to inform the MSC of handoff operations. Refer to [14] for procedure descriptions of this message.
3.19.2 Handoff via Direct BS-to-BS Signaling 24
25 This section describes handoff via direct BS-to-BS signaling.
3.19.2.1 A3 Interface Messages 26
27
28
29
30
31
32
33
34
35
36
This section lists the messages that are used to support handoff on the A3 interface. The A3 messages are organized into three categories:
A3 Interface Setup Messages,
A3-Connect
A3-Connect Ack
A3 Interface Operational Messages,
A3-Physical Transition Directive
A3-Physical Transition Directive Ack
A3-Propagation Delay Measurement Report
A3-IS-95 FCH Forward
243 Section 3
3GPP2 A.S0013-D v2.0
A3-IS-95 FCH Reverse 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
A3-Traffic Channel Status
A3-IS-2000 FCH Forward
A3-IS-2000 FCH Reverse
A3-IS-2000 DCCH Forward
A3-IS-2000 DCCH Reverse
A3-IS-2000 SCH Forward
A3-IS-2000 SCH Reverse
A3-FCH Forward Traffic Frame
A3-FCH Reverse Traffic Frame
A3-DCCH Forward Traffic Frame
A3-DCCH Reverse Traffic Frame
A3-SCH Reverse Traffic Frame
A3 Interface Clearing Messages,
A3-Remove
A3-Remove Ack
A3-Drop
For descriptions of the messages and their procedures, refer to [15].
3.19.2.2 A7 Interface Messages 19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
This section describes the messages used between base stations on an A7 connection to support direct BS to BS soft/softer handoff, access handoff, access probe handoff, and channel assignment into soft/softer handoff. These messages are:
A7-Handoff Request
A7-Handoff Request Ack
A7-Drop Target
A7-Drop Target Ack
A7-Target Removal Request
A7-Target Removal Response
A7-Paging Channel Message Transfer
A7-Paging Channel Message Transfer Ack
A7-Access Channel Message Transfer
A7-Access Channel Message Transfer Ack
A7-Burst Request
A7-Burst Response
A7-Burst Commit
A7-Burst Release
For descriptions of the messages and their procedures, refer to [15].
Section 3 244
3GPP2 A.S0013-D v2.0
3.19.2.3 Soft/Softer Handoff Addition 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
The source BS decides what cells are to be added to a call in soft/softer handoff. An A7-Handoff Request message is sent directly to the target BS across the A7 connection between the source and target BSs to request the addition of those cells to the call. The target BS allocates and connects the appropriate resources and responds directly to the source BS using an A7-Handoff Request Ack message once all expected A3-Connect Ack messages have been received.
The A3-Connect message is used by the target BS to both create new A3 connections for a call and to add cells to existing A3 connections. In either case, information on all cells attached to the A3 connection shall be included in the A3 Connect Information IE, and there shall be an indication as to which cells were already existing and which cells were newly associated with the A3 connection.
The A3-Connect message can be used to establish multiple A3 connections. To support this capability, multiple sets of cell information may be included. A single A3-Connect Ack message is used to respond to an A3-Connect message, regardless of the number of A3 connections being established via the A3-Connect message. The A3-Connect Ack message is returned to the address from which the A3-Connect message was sent.
In response to an A7-Handoff Request message that includes multiple cells to be added to the call association in soft or softer handoff, the target BS may send a single A3-Connect message including information for multiple connections, or it may send multiple A3-Connect messages where each message includes information for a single connection only. However, the target BS shall not send multiple A3-Connect messages that each includes multiple connection information, nor any combination of such messages and A3-Connect messages that include information for a single connection.
The A3-Connect Ack and A3-Traffic Channel Status messages support the ability of the source BS to request that the target BS send a notification that the target BS transmitter(s) and receiver(s) are turned on.
3.19.2.4 Soft/Softer Handoff Removal 28
29
30
31
32
Removal of cells in soft/softer handoff involves the sending by the source BS of an A7-Drop Target message to the target BS. The target BS removes the indicated cells and responds with an A7-Drop Target Ack message. If the last cell(s) attached to a particular A3 connection are removed, the target BS also initiates removal of that A3 connection.
3.19.2.5 Cell Removal by a Target BS 33
34
35
36
37
38
39
40
41
For a variety of reasons, a target BS may need to request that one or more of its cells be removed from a call. This request can be for reasons of internal resource management, OA&M, internal BS error situations, etc. The target BS, in these cases, sends an A7-Target Removal Request message to the source BS with appropriate information to indicate what cells need to be removed from the call, and for what reason(s). The source BS takes the appropriate actions and responds with an A7-Target Removal Response message; the source BS may also indicate to the target BS that the target cell(s) are to remain in the call.
3.19.2.6 Call Clearing 42
43
44
Call clearing for calls using packet based soft/softer handoff is always accomplished via the source BS. If the call clearing is initiated by either the MS or source BS, a Clear
245 Section 3
3GPP2 A.S0013-D v2.0
Request message is sent to the MSC to request call clearing. If the MSC initiates the call clearing, it sends a Clear Command message to the source BS. Clear Command messages are not sent to target BSs involved in the call. Instead, the source BS is responsible for using the A7 interface drop target procedure to remove all target BSs from the call.
1
2
3
4
5
6
7
8
When the A7 interface drop target procedure is used during call release scenarios, the A7 Drop Target message shall contain the cell identify list with no cells included. In this case, the source should wait some period of time to allow any in progress adds or drops to complete prior to sending the A7 Drop Target message.
3.19.2.7 Handoff Performed 9
10
11
12
The source BS is responsible for sending Handoff Performed messages to the MSC to keep it informed of the identity of the cells currently involved in supporting the call.
Refer to section 3.19.1.1.3 “Concept of ‘Designated Cell’” and [14].
3.19.2.8 Access Handoff and Channel Assignment into Soft Handoff 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
In addition to setting up soft handoff legs during a call, the soft handoff legs can also be set up during the establishment of the call. This procedure is required to support access probe handoff, access handoff, and channel assignment into soft/softer handoff.
The source BS decides what cells are to be set up in soft/softer handoff during the establishment of the call and the A7-Handoff Request procedure is used. That is, an A7-Handoff Request message is sent directly to the target BSs across the A7 connection between the source and target BSs to request the setup of those cells to the call. Each target BS allocates and connects the appropriate resources and responds directly to the source BS using an A7-Handoff Request Ack message once all expected A3-Connect Ack messages have been received.
Cells that are likely candidates for access probe handoff and access handoff by the MS are included in the ACCESS_HO_LIST.
For each message received on one of its Access Channels, the BS shall analyze the PILOT_RECORD if such a record is included in the message. If the BS does not correspond to the first attempted pilot in the record (i.e., is not the source BS), then it shall forward the Access Channel message on an inter-BS (i.e., A7) link corresponding to the first attempted pilot in the record. If the Access Channel message is an Origination or Page Response, the BS shall forward the message as indicated above and shall not send the corresponding CM Service Request message or Paging Response message to the MSC.
The source BS sends A7-Paging Channel Message Transfer messages carrying appropriate channel assignment information to selected BSs, usually chosen from those contained in the ACCESS_HO_LIST and OTHER_REPORTED_LIST, requesting that they send the Channel Assignment Message on specific cells. The Channel Assignment Message is used to assign the forward channel(s) to the MS.
The set of BSs to which the source BS sends the A7-Paging Channel Message Transfer message may be different from the set of BSs that are set up in soft handoff.
Refer to section 3.1.2.2 for an example scenario showing access probe handoff, access handoff and channel assignment into soft/softer handoff.
Section 3 246
3GPP2 A.S0013-D v2.0
Also refer to [15] for information on the A7-Paging Channel Message Transfer, A7-Paging Channel Message Transfer Ack, A7-Access Channel Message Transfer, and A7-Access Channel Message Transfer Ack messages.
1
2
3
3.19.2.9 Soft/Softer Handoff of High Speed Packet Data 4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Support of high speed packet data (i.e., speeds greater than 14.4 kbps) may be accomplished through the use of multiple physical channels. These physical channels are supported in the infrastructure using A3 traffic connections during soft/softer handoff. Setup of an A3 connection for a traffic burst is accomplished using A7-Burst Request, A7-Burst Response, A7-Burst Commit, and A7-Burst Release messages. Establishment of the A3 connection for the Supplemental Channel (SCH) is accomplished via the A7-Handoff Request, A7-Handoff Request Ack, A3-Connect and A3-Connect Ack messages.
In this version of this standard, it is assumed that any leg for a Supplemental Channel is established on a cell that already supports a leg for the Fundamental Channel (FCH) or the Dedicated Control Channel (DCCH) for the same MS. To minimize the time required to establish a traffic burst, the A3 connection for an SCH is established on the target BS at the transmission of the first data burst. When a leg is established for an SCH, only the terrestrial resources are allocated, i.e., the A3 connection. This involves choosing the traffic circuit to be used and establishing context between the target BS and the source BS/SDU function. Allocation of radio resources for the SCH is made each time that a traffic burst is set up.
When the source BS realizes that it is necessary to allocate radio resources for a traffic burst in either the forward or reverse direction or both, it sends an A7-Burst Request message to each target BS to request reservation of specific radio resources. Each target BS responds with A7-Burst Response message(s) to indicate radio resource reservations for the requested cells. Once the source BS has received the A7-Burst Response messages, it sends either A7-Burst Commit or A7-Burst Release message(s) to each target BS to indicate the set of radio resources to be used. A burst time that requires the message to be pending for more than 7/8 of the modulo window in the future from its time of arrival shall be considered late and the message shall be processed immediately. End time shall still be calculated from the specified start time and duration. Each target BS receiving an A7-Burst Commit message prepares the indicated cell, connects it to the pre-established A3 connection, and then participates in the burst. Each target BS receiving an A7-Burst Release message then releases the resources reserved at the indicated cell(s). Both cases are shown in examples in section 3.19.3.2.
3.19.2.9.1 Soft/Softer Handoff of Forward Link Bursts of Data 35
36
37
38
39
40
41
42
43
44
45
46
When a traffic burst is scheduled to begin, the SDU function begins to transmit forward link frames carrying user traffic on the A3 connection for the SCH. At the termination of a traffic burst in the forward direction, the SDU function ceases transmitting frames on the SCH A3 connection. The SDU function may begin to send idle frames on the forward A3 connection prior to the beginning of the burst to allow synchronization of the A3 connection. If the target BS receives forward idle frames and is not receiving reverse frames from the MS, it shall send reverse idle frames to the SDU function to allow packet arrival time error adjustments to occur.
The SDU function shall send no more than 9144 bits (i.e., 3 frames of data for a burst at 153.6 KBPS) to the target BS prior to the beginning of a traffic burst in the forward direction.
247 Section 3
3GPP2 A.S0013-D v2.0
When a new traffic burst is initiated on an A3 connection for a SCH, the target BS shall wait for the first forward link frame before transmitting any reverse link frames. If the target BS receives a forward link Idle Frame, it shall calculate the packet arrival time error and transmit that information on the reverse link in an Idle Frame if it has no user traffic to transmit in a non-idle frame. The target BS shall not transmit any air interface frame when receiving a forward link Idle Frame. In this way, the SDU function can control precisely the beginning of forward link traffic bursts on physical channels.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
The source BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Forward message with Forward Layer 3 Data elements containing Null or Idle frame contents. Refer to [15] (IS-2000 Frame Content) for source and target operations with Null and Idle frames.
The target BS may suppress (i.e., not transmit) an A3-IS-2000 SCH Reverse message with Reverse Layer 3 Data information elements containing Null or Idle frame contents if, and only if, an A3-IS-2000 SCH Forward message was not received in the previous air-frame period. Refer to [15] (IS-2000 Frame Content) for source and target operations with Null and Idle frames.
3.19.2.9.2 Soft/Softer Handoff of Reverse Link Bursts of SCH Data 16
17
18
19
20
21
22
23
24
25
26
When a traffic burst is expected by a target BS, the target BS shall wait for the first forward link frame so that the packet arrival time error can be correctly calculated. Following the reception of each forward link frame at the target BS, the target BS shall transmit a reverse link frame. Reverse link frames may contain user traffic (i.e., packet data), Idle Frames, Null Frames, Re-Acquiring Frames, or Erasure Frames. Reverse link frames containing user traffic, Re-Acquiring Frames, or Erasure frames (i.e., decoded from the air interface) may be sent without prior reception of forward link frames.
The target BS shall decide whether Erasure Frames, Re-Acquired Frames, or Null Frames should be sent to the SDU in the source BS in the cases of Discontinuous Transmission (DTX) or loss of finger lock.
3.19.3 Handoff Call Flows 27
28
29
30
Note: In the following call flows, the box marked “MSC” may represent one or two MSCs. In the case of inter-MSC handoff, inter-MSC signaling is not specified. This section assumes that there is no packet data session.
3.19.3.1 Hard Handoff via MSC Call Flows 31
32
33
34
The following call flows provide an illustration for a successful hard handoff event. It is assumed that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no A3 connections need to be removed.
3.19.3.1.1 Successful Hard Handoff via the A1 and A2 Interfaces 35
36
37
This call flow assumes that the source BS and the target BS are under the control of a circuit switched MSC.
Section 3 248
3GPP2 A.S0013-D v2.0
MS Source BS MSC time
a
b
c
e
f
g
Handoff Required
Handoff Request
Handoff Command
MS Ack Order
Handoff Commenced h
j
i
k
l
m
n
Reverse Traffic Channel Frames or Traffic Channel Preamble
Clear Command
BS Ack Order
Handoff CompleteT306
T315
Twaitho
T8
TargetBS
x
Handoff Direction Message
Handoff Completion Message
Clear Complete
T9
T7
Null forward traffic channel frames T11
Handoff RequestAck
d
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.19.3.1.1-1 Successful Hard Handoff via the A1 and A2 Interfaces
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7.
b. The MSC sends a Handoff Request message to the target BS with the IS-95 Channel Identity element or the IS-2000 Channel Identity element present, based on if the MSC proceeds with a CDMA-CDMA handoff attempt and the corresponding IS-2000 or IS-95 Channel Identity element was present in the Handoff Required message. The MSC starts timer T11.
In the case of hard handoff for an async data/fax call, the Circuit Identity Code Extension element in the Handoff Request message indicates the Circuit Identity Code of the circuit to be connected to the SDU function at the target BS to support the A5 connection to the IWF.
c. Upon receipt of the Handoff Request message from the MSC, the target BS allocates appropriate radio resources as specified in the message and connects the call. As the Handoff Request message can have multiple cell(s) specified, the target BS can also choose to set up multiple cell(s) for the handoff request. The target BS sends null forward traffic channel frames to the MS.
d. The target BS sends a Handoff Request Acknowledge message to the MSC and starts timer T9 to wait for arrival of the MS on its radio channel. The MSC stops timer T11 upon the receipt of this message. The first cell in the cell identifier list element of the message is treated as the new designated cell by the MSC. The change of designated cell occurs upon receipt of the Handoff Complete message. If the service option received in the Handoff Request message is not available at the target BS and the
249 Section 3
3GPP2 A.S0013-D v2.0
target BS selected a different service option for the handoff then the target BS shall include the service option it selected in the service configuration records.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
e. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The source BS stops timer T7. The MSC shall include in the Handoff Command message the service configuration records it received in the Handoff Request Ack message.
f. The source BS sends the handoff direction message14 to the MS and starts timer T8. If the MS is allowed to return to the source BS, timer Twaitho is also started by the source BS.
g. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message.
If the handoff direction message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
h. The source BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the target BS channel. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been started, the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
i. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell(s).
j. The MS sends a Handoff Completion Message to the target BS. The target BS stops timer T9.
k. The target BS sends the BS Ack Order to the MS over the air interface.
l. The target BS sends a Handoff Complete message to the MSC to notify it that the MS has successfully completed the hard handoff.
m. The MSC sends a Clear Command message to the source BS and starts timer T315. The source BS stops timer T306.
n. The source BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315.
3.19.3.1.2 Successful Hard Handoff via the A1p and A2p Interfaces 30
31
32
This call flow assumes that the source BS and the target BS are under the control of an MSCe.
14 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.
Section 3 250
3GPP2 A.S0013-D v2.0
Bearer Update Response
Handoff Complete
MS Source BS MSCe 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 T306
T315
Twaitho
x
T11
T8
p
Bearer Update Request
o
Tyyp optional
conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.19.3.1.2-1 Successful Hard Handoff via the A1p and A2p Interfaces
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSCe and starts timer T7.
b. The MSCe sends a Handoff Request message to the target BS with the IS-95 Channel Identity element or the IS-2000 Channel Identity element present, based on if the MSCe proceeds with a CDMA-CDMA handoff attempt and the corresponding IS-2000 or IS-95 Channel Identity element was present in the Handoff Required message. The Handoff Request message may also include the A2p bearer parameters, containing the MGW address. The MSCe starts timer T11.
c. Upon receipt of the Handoff Request message from the MSCe, the target BS allocates appropriate radio resources as specified in the message and connects the call. As the Handoff Request message can have multiple cell(s) specified, the target BS can also choose to set up multiple cell(s) for the handoff request. The target BS sends null forward traffic channel frames to the MS.
d. The target BS sends a Handoff Request Acknowledge message to the MSCe with the A2p bearer parameters containing the reserved bearer format(s) and the bearer address of the BS.
The BS starts timer T9 to wait for arrival of the MS on its radio channel. The MSCe stops timer T11 upon the receipt of this message. The first cell in the cell identifier list element of the message is treated as the new designated cell by the MSCe. The change of designated cell occurs upon receipt of the Handoff Complete message. If the service option received in the Handoff Request message is not available at the target BS and the target BS selected a different service option for the handoff then
251 Section 3
3GPP2 A.S0013-D v2.0
the target BS shall include the service option it selected in the service configuration records.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
e. The MSCe may send a Bearer Update Request message to the target BS. The Bearer Update Request message includes the A2p bearer parameters, which may contain the selected bearer format(s) and/or the MGW address. The MSCe starts timer Tyyp.
f. If a Bearer Update Request message was received, the target BS sends a Bearer Update Response message to the MSCe. Upon receipt of the Bearer Update Response message, the MSCe stops timer Tyyp.
g. The MSCe prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The Handoff Command message is sent only after the A2p bearer connection has been established with the target BS. The source BS stops timer T7. The MSCe shall include in the Handoff Command message the service configuration records it received in the Handoff Request Ack message.
h. The source BS sends the handoff direction message15 to the MS and starts timer T8. If the MS is allowed to return to the source BS, timer Twaitho is also started by the source BS.
i. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message.
If the handoff direction message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
j. The source BS sends a Handoff Commenced message to the MSCe to notify it that the MS has been ordered to move to the target BS channel. The source BS starts timer T306 to await the Clear Command message from the MSCe. If timer Twaitho has been started, the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
k. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell(s).
l. The MS sends a Handoff Completion Message to the target BS. The target BS stops timer T9.
m. The target BS sends the BS Ack Order to the MS over the air interface.
n. The target BS sends a Handoff Complete message to the MSCe to notify it that the MS has successfully completed the hard handoff.
o. The MSCe sends a Clear Command message to the source BS and starts timer T315. The source BS stops timer T306.
p. The source BS sends a Clear Complete message to the MSCe to notify it that clearing has been accomplished. The MSCe stops timer T315.
3.19.3.1.3 Successful Hard Handoff From a Circuit Switched MSC to an MSCe 38
39
40
This scenario assumes that the source BS is under the control of a circuit switched MSC and the target BS is under the control of an MSCe. Signaling for this scenario is identical
15 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.
Section 3 252
3GPP2 A.S0013-D v2.0
to the signaling shown in call flow 3.19.3.1.2-1, except that the source BS is connected to a circuit-switched MSC.
1
2
3.19.3.1.4 Successful Hard Handoff From an MSCe to a Circuit Switched MSC 3
4
5
6
7
This call flow assumes that the source BS is under the control of an MSCe and the target BS is under the control of a circuit switched MSC. The messaging for this call flow is the same as shown in section 3.19.3.1.1, Successful Hard Handoff via the A1 and A2 Interfaces.
3.19.3.1.5 Successful Hard Handoff to ANSI/TIA/EIA-553-A Systems 8
9
10
11
12
13
14
For the purpose of this specification, the single MSC in the following figure represents the source and the target MSC connected by [9]. The message flows and timers between the target MSC and the target BS in the figure are outside the scope of this standard. This section assumes that the target MSC is a circuit-switched MSC.
The following call flow provides an illustration for a successful hard handoff event to an analog [18] system.
MS MSC time
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
Source BS
Target BS
T11
15
16
17
18
19
20
21
22
23
24
25
26
Figure 3.19.3.1.5-1 Successful Hard Handoff to an ANSI/TIA/EIA-553-A System
a. Based on an MS report that it has crossed a network specified threshold for signal strength, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the Cell Identifier List to the source MSC to find a target with available resources and starts timer T7. The source BS indicates a response requirement by including the Response Request element.
b. The target MSC sends the equivalent of a Handoff Request message to the target BS without the IS-95 Channel Identity or the IS-2000 Channel Identity element present, since this is a CDMA to Analog hard handoff request. The MSC starts the equivalent of timer T11.
253 Section 3
3GPP2 A.S0013-D v2.0
c. The target BS determines that appropriate resources are available, sends the equivalent of a Handoff Request Acknowledge message to the target MSC, and starts the equivalent of timer T9. The MSC stops the equivalent of T11 upon receipt of this message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
d. The source MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS to convey information from the target BS. The source BS stops timer T7 upon receipt of this message.
e. The source BS transmits the Analog Handoff Direction Message to the MS and may request a Layer 2 Ack.
f. The MS returns an MS Ack Order to the source BS to confirm receipt of the Analog Handoff Direction Message.
If the handoff direction message is sent using quick repeats the source BS might not request an acknowledgement from the MS.
g. The source BS sends a Handoff Commenced message to the source MSC to notify it that the MS has been ordered to move to the target BS channel. The source BS starts timer T306 to await the Clear Command message from the source MSC.
h. The MS tunes to the target BS and initiates transmission of the transponded Supervisory Audio Tone (SAT). The target BS stops the equivalent of timer T9.
i. Upon reception of the correct MS transponded SAT, the target BS sends the equivalent of a Handoff Complete message to the target MSC to indicate that the MS has successfully accessed the target BS.
j. The source MSC instructs the source BS to release its radio resources by sending a Clear Command message to the source BS with the cause element set to “Handoff successful”. The source MSC starts timer T315. The source BS stops timer T306 when the Clear Command message is received.
k. The source BS releases its source channel, clears any terrestrial resources, and returns a Clear Complete message to the source MSC to indicate that the transition is complete. The source MSC stops timer T315 when the Clear Complete message is received.
3.19.3.1.6 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A Alternative Rejected 31
32
33
34
35
36
37
38
For the purpose of this specification, the single MSC in the following figure represents the source and the target MSC connected by TIA/EIA IS-41. The message flows between the target MSC and the target BS in the figure are informative and are not required. This section assumes that the target MSC is a circuit-switched MSC.
The following call flow provides an illustration of an unsuccessful hard handoff. In this example, the source BS determines that an ANSI/TIA/EIA-553-A alternative is not acceptable, rejects the Handoff Command and maintains the MS.
Section 3 254
3GPP2 A.S0013-D v2.0
MS MSC
time
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
Source BS
Target BS
T11
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Figure 3.19.3.1.6-1 Unsuccessful Hard Handoff to ANSI/EIA/TIA-553: ANSI/TIA/EIA-553-A Alternative Rejected
a. Based on an MS report that it has crossed a network specified threshold for signal strength, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the Cell Identifier List to the source MSC to find a target with available resources and starts timer T7. The source BS indicates a response requirement by including the Response Request element.
b. The target MSC sends the equivalent of a Handoff Request message to the target BS without the IS-95 Channel Identity or the IS-2000 Channel Identity element present, since this is a CDMA to Analog hard handoff request. The MSC starts the equivalent of timer T11.
c. The target BS determines that a channel resource is not available and reserves or allocates an ANSI/TIA/EIA-553-A channel. The target BS sends the equivalent of a Handoff Request Acknowledge message to the target MSC informing it of the availability of the ANSI/TIA/EIA-553-A channel and starts the equivalent of timer T9. The MSC stops timer T11.
d. The source MSC sends a Handoff Command message to the source BS to convey information from the target BS to the source BS. The source BS stops timer T7 upon receipt of this message.
e. Upon receipt of the Handoff Command message from the source MSC, the source BS recognizes that an analog [18] channel has been supplied and decides to reject the assignment. The source BS keeps the MS and sends a Handoff Failure message to the source MSC with the cause element set to “Alternate signaling type reject”.
f. The target MSC releases the terrestrial circuit to the target BS, instructs the target BS to release its radio resources by sending the equivalent a Clear Command message, and starts the equivalent of timer T315. The target BS stops the equivalent of timer T9 upon receipt of this message.
g. The target BS sends the equivalent of a Clear Complete message to the target MSC to indicate that the resource release operation is complete. The MSC stops the equivalent of timer T315 upon receipt of this message.
255 Section 3
3GPP2 A.S0013-D v2.0
3.19.3.1.7 Hard Handoff with Return On Failure 1
2
3
4
5
6
7
8
9
10
The following call flow provides an illustration for a hard handoff event. In this scenario, the MS successfully returns to the source BS after hard handoff fails. It is assumed that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no inter-BS connections need to be removed.
If the target MSC is an MSCe, the Handoff Request message sent by it may contain A2p bearer addresses and the corresponding the Handoff Request Ack message contains A2p bearer parameters for the voice call. Also, in this scenario, a pair of Bearer Update Request and Bearer Update Response messages may be exchanged between the MSCe and the BS after the Handoff Request Ack, as shown in section 3.19.3.1.2.
MS Source
BS MSC time
a
b
c
g
Handoff Required
Handoff Request
Handoff Command
MS Ack Order
Target BS
T7
T9
h
i
j
k
Clear Command
Handoff Failure
Clear CompleteT315
Twaitho
T8
Null forward traffic channel frames
handoff direction message
CF Search Report Message
Handoff RequestAck
T11
d e
f
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Figure 3.19.3.1.7-1 Hard Handoff with Return On Failure
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7.
b. The MSC sends a Handoff Request message to the target BS with the IS-95 Channel Identity element or the IS-2000 Channel Identity element present, based on if the MSC proceeds with a CDMA-CDMA handoff attempt and the corresponding IS-2000 or IS-95 Channel Identity element was present in the Handoff Required message. The MSC starts timer T11.
In the case of hard handoff for an async data/fax call via the A1 interface, the Circuit Identity Code Extension element in the Handoff Request message indicates the Circuit Identity Code of the circuit to be connected to the SDU function at the target BS to support the A5 connection to the IWF.
c. Upon receipt of the Handoff Request message from the MSC, the target BS allocates appropriate radio resources as specified in the message. The target BS sends null forward traffic channel frames to the MS.
Section 3 256
3GPP2 A.S0013-D v2.0
d. The target BS sends a Handoff Request Acknowledgment message to the MSC and starts timer T9 to wait for arrival of the MS on its radio channel. The MSC stops timer T11 upon receipt of this message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
e. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The source BS stops timer T7.
f. The source BS sends the handoff direction message16 to the MS and starts timer T8. The source BS indicates in the message that the MS is permitted to return to the source BS if handoff to the target fails. The source BS starts timer Twaitho.
g. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message.
If the handoff direction message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
h. The MS sends a Candidate Frequency (CF) Search Report Message to the source BS after handoff to the target has failed. The source BS stops timer Twaitho.
i. Upon receipt of the CF Search Report Message from the MS the source BS realizes that the MS did not successfully access the target BS cell and sends a Handoff Failure message to the MSC with the cause element set to “Reversion to old channel”.
j. The MSC sends a Clear Command message to the target BS and starts timer T315. The target BS stops timer T9 upon receipt of this message.
k. The target BS releases and de-allocates the radio and terrestrial resources. The target BS sends a Clear Complete message to the MSC to indicate that the resource release operation is complete. The MSC stops timer T315 upon receipt of this message.
3.19.3.1.8 Hard Handoff Failure 24
25
26
27
28
The following call flow provides an illustration for a hard handoff failure event. In this scenario, the target BS notifies the MSC that the handoff has failed by sending a Handoff Failure Message. It is assumed that the call is not in inter-BS soft/softer handoff prior to the hard handoff, and thus no inter-BS connections need to be removed.
16 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.
257 Section 3
3GPP2 A.S0013-D v2.0
Source BS MSC Time Comment
a
b
c
d
Handoff Required
Handoff Request
Handoff Required Reject
Target BS
Handoff FailureFail
T7 T11
e
f
Clear Command
Clear Complete T315
T306
Conditional
Conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Figure 3.19.3.1.8-1 Hard Handoff Failure
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7.
b. The MSC sends a Handoff Request message to the target BS with the IS-95 Channel Identity element or the IS-2000 Channel Identity element present, based on if the MSC proceeds with a CDMA-CDMA handoff attempt and the corresponding IS-2000 or IS-95 Channel Identity element was present in the Handoff Required message. The MSC starts timer T11.
In the case of hard handoff for an asynchronous data/fax call via A1 interface, the Circuit Identity Code Extension element in the Handoff Request message indicates the Circuit Identity Code of the circuit to be connected to the SDU function at the target BS to support the A5 connection to the IWF.
c. The target BS receives the Handoff Request message but is unable to accommodate the handoff request. The target BS then sends a Handoff Failure message to the MSC. If an underlying transport connection has been established between the MSC and the target BS, the target BS starts timer T306, otherwise the call flow ends after step ‘d’.
d. Upon receipt of the Handoff Failure message, the MSC stops timer T11. The MSC then sends a Handoff Required Reject message to the source BS. Upon receipt of the Handoff Required Reject message, the source BS stops timer T7. A new handoff procedure may be initiated if the condition of the call connection warrants immediate action.
e. The MSC sends a Clear Command message to the target BS to instruct the BS to release dedicated resources associated with the call and starts timer T315. Upon receipt of this message, the BS stops timer T306.
f. The BS clears allocated resources and sends the Clear Complete message to the MSC. Upon receipt of this message, the MSC stops timer T315.
Section 3 258
3GPP2 A.S0013-D v2.0
3.19.3.2 Soft/Softer Handoff via Direct BS-to-BS Signaling Call Flows 1
2
3.19.3.2.1 Soft/Softer Handoff Addition 3
4
5
6
7
8
9
Soft/softer handoff addition occurs as shown in the following diagram. Soft/softer handoff addition includes both the creation of new A3 traffic connections and the addition of cells to existing A3 traffic connections. In this section, “A3-CEData Forward/Reverse” messages represent “A3-IS-95 FCH Forward/Reverse”, “A3-IS-2000 FCH Forward/Reverse”, or “A3-IS-2000 DCCH Forward/Reverse” messages. For SCH soft/softer handoff addition, refer to sections 3.19.3.2.4 and 3.19.3.2.5.
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
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) Tchanstat
T8
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.19.3.2.1-1 Soft/Softer Handoff Addition
a. The source BS decides that one or more cells at the target BS are needed to support the call in soft/softer handoff. The source BS sends an A7-Handoff Request message to the target BS and starts timer Thoreq.
b. The target BS initiates an A3 traffic connection (or adds to an existing one) by sending an A3-Connect message to the source BS and starting timer Tconn3. Note that a single A7-Handoff Request message may result in multiple A3 traffic connections being established, each using a separate A3-Connect message. This example shows only a single A3 traffic connection being established.
c. The source BS replies with an A3-Connect Ack message to complete the A3 connection or to acknowledge the addition of cells to an existing A3 connection. The
259 Section 3
3GPP2 A.S0013-D v2.0
target BS stops timer Tconn3. If the source BS requested notification of transmission start at the target BS, the source BS starts timer Tchanstat.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
d. The source BS begins to send forward frames to the target BS.
e. The target BS begins to send reverse idle frames as soon as the first forward frame is received from the source BS. The reverse frames contain the timing adjustment information necessary to achieve synchronization.
f. The target BS begins to transmit the forward frames over the air as soon as synchronization has occurred.
g. The target BS sends an A7-Handoff Request Ack message to the source BS to indicate the success of the cell addition(s). The source BS stops timer Thoreq.
h. If the source BS has chosen to be notified of the start of transmission and reception at the target BS, when its SDU function and the target BS have synchronized the A3 traffic subchannel, the target BS replies with an A3-Traffic Channel Status message. Refer to [15] “A3-Connect Ack”. Note that this step may occur any time after step ‘d’. The source BS stops timer Tchanstat if it was started.
i. The source BS sends a handoff direction message17 to the MS to add the new cell(s) to the active set.
j. The MS acknowledges receipt of the handoff direction message with an MS Ack Order.
k. The MS indicates successful results of processing the handoff direction message by sending a Handoff Completion Message.
l. The source BS acknowledges receipt of the Handoff Completion Message by sending a BS Ack Order.
m. The source BS may send a Handoff Performed message to the MSC. Refer to section 3.19.1.1.3 “(Concept of ‘Designated Cell’)”. The Handoff Performed message may be sent any time after the Handoff Completion Message is received by the BS.
3.19.3.2.2 Soft/Softer Handoff Removal 27
28
29
30
31
Soft/softer handoff removal occurs as shown in the following diagram. In this section, “A3-CEData Forward/Reverse” messages represent “A3-IS-95 FCH Forward/Reverse”, “A3-IS-2000 FCH Forward/Reverse”, or “A3-IS-2000 DCCH Forward/Reverse” messages.
17 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.
Section 3 260
3GPP2 A.S0013-D v2.0
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
Tdrptgt Tdiscon3
A3-CEData Forward (HO Dir. Msg.)
A3-CEData Reverse (MS Ack Order)
a
d
T8
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.19.3.2.2-1 Soft/Softer Handoff Removal
a. The source BS sends a handoff direction message18 in an A3-CEData Forward message to the target BS to be sent to the MS to drop one or more cell(s) from the active set.
b. The source BS and target BS transmit the handoff direction message to the MS.
c. The MS acknowledges receipt of the handoff direction message with an MS Ack Order transmitted to both the source and target BSs.
d. The target BS relays the MS Ack Order to the source BS in an A3-CEData Reverse message.
e. The MS indicates the successful processing of the handoff direction message by sending a Handoff Completion Message.
f. The source BS acknowledges receipt of the Handoff Completion Message by sending a BS Ack Order.
g. The source BS sends an A7-Drop Target message to the target BS to request that the specified cells be removed from the call. The source BS starts timer Tdrptgt.
h. The target BS, upon receipt of the A7-Drop Target message, deallocates internal resources related to the specified cells. The target BS sends an A3-Remove message to the SDU function of the source BS and starts timer Tdiscon3.
i. The SDU function of the source BS replies with an A3-Remove Ack message and deallocates internal resources. The target BS stop timer Tdiscon3.
18 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.
261 Section 3
3GPP2 A.S0013-D v2.0
j. The target BS sends an A7-Drop Target Ack message to the source BS to acknowledge the removal of the specified cells. The source BS stops timer Tdrptgt.
1
2
3
4
5
k. The source BS may send a Handoff Performed message to the MSC. Refer to section 3.19.1.1.3 “Concept of ‘Designated Cell’”. The Handoff Performed message may be sent any time after the Handoff Completion Message is received by the BS.
3.19.3.2.3 Cell Removal by a Target BS 6
7
8
9
10
11
12
The example below shows a Target Removal initiated by a target BS, where the last cell attached to an A3 call leg is removed, thus causing the A3 call leg connections to be torn down. As can be seen in the example, the A7-Target Removal Request message initiates normal call leg removal, that is, the normal A7 interface call leg removal procedure is used between the A7-Target Removal Request and A7-Target Removal Response messages.
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
A7-Target Removal Request a
A7-Target Removal Response k
Ttgtrmv
Tdrptgt
Tdiscon3
T8
13
14
15
16
17
18
19
20
21
Figure 3.19.3.2.3-1 Cell Removal Initiated by the Target BS
a. The target BS decides that one or more of its cells can no longer be involved in the soft/softer handoff and sends an A7-Target Removal Request message to the source BS. The target BS starts timer Ttgtrmv.
b. The source BS sends a handoff direction message19 to the MS to drop the cell(s) from the active set.
c. The MS acknowledges receipt of the handoff direction message with an MS Ack Order.
19 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.
Section 3 262
3GPP2 A.S0013-D v2.0
d. The MS indicates the successful processing of the handoff direction message by sending a Handoff Completion Message.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
e. The source BS acknowledges receipt of the Handoff Completion Message by sending a BS Ack Order.
f. The source BS sends an A7-Drop Target message to the target BS to request that the specified cells be removed from the call. The source BS starts timer Tdrptgt.
g. The target BS, upon receipt of the A7-Drop Target message, deallocates internal resources related to the specified cells. In this example, it is assumed that all cells attached to an A3 connection are removed from the call. The target BS sends an A3-Remove message to the SDU function of the source BS and starts timer Tdiscon3.
h. The SDU function of the source BS replies with an A3-Remove Ack message and deallocates internal resources. The target BS stop timer Tdiscon3.
i. The target BS sends an A7-Drop Target Ack message to the source BS to acknowledge the removal of the specified cells. The source BS stops timer Tdrptgt.
j. The source BS may send a Handoff Performed message to the MSC. Refer to section 3.19.1.1.3 “Concept of ‘Designated Cell’”. The Handoff Performed message may be sent any time after the Handoff Completion Message is received by the BS.
k. The source BS responds to the target BS with an A7-Target Removal Response message. The target BS stops timer Ttgtrmv.
3.19.3.2.4 Initial Traffic Burst Example – A3 Connection Not Yet Established 20
21
22
23
24
25
26
27
28
29
30
31
The following example describes the support of an initial traffic burst when the A3 connection has not yet been established.
In this version of this standard, it is assumed that any leg for a Supplemental Channel is established on a cell that also supports a leg for the Fundamental Channel (FCH) or the Dedicated Control Channel (DCCH) for the same MS. To minimize the time required to establish a traffic burst, the A3 connection for the SCH is established on the target BS at the transmission of the first data burst. When a leg is established for a SCH, only the terrestrial resources are allocated, i.e., the A3 connection. This involves choosing the traffic circuit to be used and establishing context between the target BS and the source BS/SDU function. Allocation of radio resources for the SCH is made each time that a traffic burst is set up.
263 Section 3
3GPP2 A.S0013-D v2.0
i
A3-Physical Transition Directive
Tconn3A3-Connect Ack
A3-Connect
A7-Burst Request
Thoreq
A7-Handoff Request Ack
A7-Handoff Request
Source BS
Target BS
MS
b
c
d
time
Tbstcom
e
A7-Burst Response
f
g
A7-Burst Commit
Forward and/or reverse traffic burst
j i
ESCAM message
Layer 2 Ack
Tbstreq
SCRM Msg
PDSN
(data to be sent) a
h
l
A7-Burst Release
m
A3-Physical Transition Directive Ack n
Tphysical
Tbstcom
k
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Figure 3.19.3.2.4-1 Initial Traffic Burst Example
a. Either the source BS receives an indication from the MS (via a Supplemental Channel Request Message (SCRM)) or from the network (via data being received from the PDSN) that data needs to be sent to/from the MS. The source BS decides a traffic burst on one or more new cells at a target BS is required in support of a service instance in soft/softer handoff. This example assumes that a Fundamental Channel (FCH) or Dedicated Control Channel (DCCH) leg already exists on the selected cell(s) at the target BS. For simplicity, only one SCH is shown.
b. The source BS assigns an A7-Originating ID value and sends an A7 Handoff Request message to the target BS to establish an A3 traffic connection to support a Supplemental Channel (SCH) for the call. This example shows only a single A3 connection being established. The source BS is not required to assign a physical Frame Selector at this time. The source BS starts timer Thoreq.
c. The target BS assigns a traffic circuit and optionally a Channel Element ID (CE ID) for each A3 traffic connection and sends an A3-Connect message to the source BS indicating the Traffic Circuit ID, optional A3 Originating ID and CE ID to be associated with the specified cell. The source BS and target BS save the association of CE ID, Traffic Circuit ID, with Cell ID(s). The source BS also saves the A3 Originating ID value, to be included in subsequent A3 messages to the target BS. The target BS starts timer Tconn3. This is only done at the initial burst.
d. The source BS responds with an A3-Connect Ack message to complete the A3 connection. This may include an A3 Originating ID value assigned by the source BS,
Section 3 264
3GPP2 A.S0013-D v2.0
which is included by the target BS in subsequent A3 messages to the source BS. The target BS stops timer Tconn3.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
e. The target BS sends an A7-Handoff Request Ack message to the source BS to complete the A3 traffic circuit connection setup procedure for the specified set of cells. This may include an A7 Originating ID value assigned by the target BS, which is included by the source BS in subsequent A7 messages to the target BS for this call association. Upon receipt of the A7-Handoff Request Ack message, the source BS stops timer Thoreq.
f. The source BS sends an A7-Burst Request message to the target BS to request the reservation of the needed radio resources at one or more cells for the Supplemental Channel. The source BS starts timer Tbstreq. Note that the source BS may send an A7-Burst Request message to the target BS at any time after receiving the A3-Connect message in step ‘c’, and that the set of cells may be a subset of the cells assigned in steps ‘a’ through ‘e’.
g. The target BS determines that it can reserve part or all of the requested resources at some of the cells and sends A7-Burst Response message(s) to the source BS indicating the resources that have been reserved and committed to the traffic burst, and the cause value for any uncommitted cells. Each A7-Burst Response message can contain up to one committed cell and multiple uncommitted cells. Each reservation includes a physical Channel Element. Note that the physical Channel Element may be allocated any time after step ‘b’. The target BS starts an instance of timer Tbstcom for each committed cell.
h. The source BS makes a final decision on the resources using the information received from the target BSs in the A7-Burst Response messages, associates a frame selector with the physical channel, and sends A7-Burst Commit messages to each target BS for each cell chosen to support the traffic burst, indicating the cell resources to be used for the traffic burst. In this scenario, the source BS decides to use the resources reserved by the target BS. Upon receipt of the A7-Burst Commit message for a given cell, the target BS stops the corresponding timer Tbstcom and sets up the burst. Note that the source BS may allocate the frame selector any time after step ‘b’.
Note that the source BS is not required to wait for all A7-Burst Responses before committing the burst, but it shall not send an A7-Burst Commit message for a given cell until after receiving the corresponding A7-Burst Response for that cell.
i. The source BS sends A7-Burst Release message(s) to the target BS(s) for cells that reserved resources but are not required to support the burst. The target BS frees the reserved resources.
Note that the source BS is not required to wait for all A7-Burst Response messages before committing the burst, but it shall not send an A7-Burst Release message for a given cell until after receiving the corresponding A7-Burst Response message for that cell. Upon receipt of the A7-Burst Release message for a given cell, the target BS stops the corresponding timer Tbstcom.
Refer to the call flow in section 3.19.3.2.6 for procedures to release any reserved resources that are not used for the traffic burst.
j. The source BS commands the MS to prepare for the traffic burst via an Extended Supplemental Channel Assignment Message (ESCAM).
k. The MS acknowledges the command from the source BS with a Layer 2 Ack.
If the ESCAM is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
265 Section 3
3GPP2 A.S0013-D v2.0
l. The network and MS exchange forward and/or reverse traffic burst information for the specified duration, or until the source BS or target BS terminates or extends the traffic burst.
1
2
3
4
5
6
7
8
m. The source BS sends an A3-Physical Transition Directive message if the previous Power Control Mode is to be restored when the burst ends. This step may occur anytime after step ‘h’. The source BS starts timer Tphysical.
n. The target BS sends an A3-Physical Transition Directive Ack message. Upon receipt of this message, source BS stops timer Tphysical.
3.19.3.2.5 Subsequent Traffic Burst Example 9
10
11
12
13
The following example describes the support of a traffic burst when the A3 connection for the Supplemental Channel (SCH) has already been established. Note that this could be the initial data burst if the A3 connection for the SCH was established previously via the A7-Handoff Request procedure.
Source BS
Target BS
MS
A7-Burst Request
A7-Burst Commit
b
c
d
time
Tbstcom
e
f
g
Forward and/or reverse traffic burst
ESCAM message
Layer 2 Ack
SCRM Msg
PDSN
(data to be sent) a
A7-Burst Response
A7-Burst Response Tbstreq
Tbstcom A7-Burst Release
h
i 14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Figure 3.19.3.2.5-1 Subsequent Traffic Burst Example
a. Either the source BS receives an indication from the MS (via a Supplemental Channel Request Message (SCRM)) or from the network (via data being received from the PDSN) that data needs to be sent to/from the MS.
b. The source BS decides a traffic burst is required on one or more cells for which an A3 connection already exists in support of a Supplemental Channel. The source BS sends an A7-Burst Request message to the target BS to request the reservation of the needed radio resources for the Supplemental Channel. The source BS starts timer Tbstreq.
c. The target BS determines that it can reserve part or all of the requested resources at some of the cells and sends A7-Burst Response message(s) to the source BS indicating the resources that have been reserved and committed to the traffic burst, and the cause value for any uncommitted cells. Each A7-Burst Response message can contain up to one committed cell and multiple uncommitted cells. Each reservation includes a physical Channel Element. Note that the physical Channel Element may be allocated any time after step ‘b’. The target BS starts an instance of timer Tbstcom for each committed cell.
Section 3 266
3GPP2 A.S0013-D v2.0
d. Upon receipt of the last A7-Burst Response message accounting for all requested cells, the source BS stops timer Tbstreq.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
e. The source BS makes a final decision on the resources using the information received from the target BSs in the A7-Burst Response messages, associates a frame selector with the physical channel, and sends A7-Burst Commit messages to each target BS for each cell chosen to support the traffic burst, indicating the cell resources to be used for the traffic burst. In this scenario, the source BS decides to use the resources reserved by the target BS. Upon receipt of the A7-Burst Commit message for a given cell, the target BS stops the corresponding timer Tbstcom and sets up the burst. Note that the source BS may allocate the frame selector any time after step ‘b’.
Note that the source BS is not required to wait for all A7-Burst Response messages before committing the burst, but it shall not send an A7-Burst Commit message for a given cell until after receiving the corresponding A7-Burst Response message for that cell.
f. The source BS sends A7-Burst Release message(s) to the target BS(s) for cells that reserved resources but are not required to support the burst. Upon receipt of an A7-Burst Release message for a given cell, the target BS stops the corresponding timer Tbstcom. The target BS frees the reserved resources.
Note that the source BS is not required to wait for all A7-Burst Response messages before committing the burst, but it shall not send an A7-Burst Release message for a given cell until after receiving the corresponding A7-Burst Response message for that cell.
Refer to the call flow in section 3.19.3.2.6 for procedures to release any reserved resources that are not used for the traffic burst.
g. The source BS commands the MS to prepare for the traffic burst via an Extended Supplemental Channel Assignment Message (ESCAM).
h. The MS acknowledges the command from the source BS with a Layer 2 Ack.
If the ESCAM is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
i. The network and MS exchange forward and/or reverse traffic burst information for the specified duration, or until the source BS or target BS terminates or extends the traffic burst.
3.19.3.2.6 Source BS Releases Reserved Resources 34
35
36
The following example describes how the source BS releases resources reserved at the target BS for a cell that is not required to support the burst.
267 Section 3
3GPP2 A.S0013-D v2.0
Source BS
Target BS
A7-Burst Request
A7-Burst Response
A7-Burst Release
b
c
time comment
Tbstreq
Tbstcom
a
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Figure 3.19.3.2.6-1 Source BS Releases Reserved Resources
a. The source BS sends an A7-Burst Request message to the target BS to request the reservation of the needed radio resources for the Supplemental Channel. The source BS starts timer Tbstreq.
b. The target BS determines that it can reserve part or all of the requested resources and sends A7-Burst Response message(s) to the source BS indicating the resources that have been reserved and committed to the traffic burst, and the cause value for any uncommitted cells. The target BS starts a timer Tbstcom for each A7-Burst Response message sent. Upon receipt of the last A7-Burst Response message, the source BS stops timer Tbstreq.
c. In this scenario, the source BS decides not to use the resources reserved by the target BS. The source BS sends A7-Burst Release message(s) for the reserved cell(s) that are not used for the traffic burst. Upon receipt of each A7-Burst Release message, the target BS stops the timer Tbstcom corresponding to the indicated cell(s) and releases its resources.
3.19.3.2.7 Early Burst Termination Initiated by Source BS 17
18 The following example describes how the source BS terminates a burst in progress.
Source BS
Target BS
A7-Burst Commit
A7-Burst Release
b
c
time comment
a
Forward and/or reverse traffic burst
MS
19
20
21
22
23
24
25
26
27
28
Figure 3.19.3.2.7-1 Early Burst Termination Initiated by Source BS
a. The source BS sends A7-Burst Commit messages to all target BSs indicating the set of committed resources that are actually used for the traffic burst. The target BS sets up the burst.
b. The network and MS exchange forward and/or reverse traffic burst information.
c. While the burst is in progress, the source BS decides to terminate the burst early at one or more cells. The source BS sends an A7-Burst Release message to the cells which are to terminate the burst. The target BS releases all resources associated with the burst.
Section 3 268
3GPP2 A.S0013-D v2.0
3.19.3.2.8 Early Burst Termination Initiated by Target BS 1
2 The following example describes how the target BS terminates a burst in progress.
Source BS
Target BS
A7-Burst Releaseb
time comment
a Forward and/or reverse traffic burst
MS
3
4
5
6
7
8
9
10
Figure 3.19.3.2.8-1 Early Burst Termination Initiated by Target BS
a. The network and MS exchange forward and/or reverse traffic burst information.
b. While the burst is in progress, the target BS decides to terminate the burst early at one or more cells. The target BS sends A7-Burst Release message(s) for the cells which are being removed from the burst. The source BS releases all resources associated with the cells that are being removed from the burst. If there are other cells supporting the SCH, then the burst continues on those cells.
3.19.4 Fast Handoff Call Flows 11
12
13
This section describes call flows for fast handoff. Refer to section 2.19.4 for more information on this feature.
3.19.4.1 Anchor PDSN Reachable from Target PCF 14
15
16
17
This call flow shows the case of an initial fast handoff (source PDSN is the same as the anchor PDSN) where the target BS/PCF is able to reach the anchor PDSN because the target BS/PCF is in the same PDSN selection domain as the anchor PDSN.
269 Section 3
3GPP2 A.S0013-D v2.0
w
Source BS
Handoff Required
Handoff Request
Source PCF
Handoff Request Ack
Handoff Command
GHDM/ UHDM
Handoff Commenced
Handoff Completion
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
l
k
j
A11-Registration Request
A11-Registration Reply
m
n
o
p
r
q
v
w
A11-Registration Update A11-Registration Acknowledge
A11-Registration Request A11-Registration Reply
A11-Registration Request
A11-Registration Reply
x
x Twaitho
MS Target BS MSC Anchor PDSN
A9-Connect-A8
Active packet data session
A9-Setup-A8
A9-AL Connected
y
Active packet data session
Active packet data session
T7
T11
TA8-setup
T9
Twaitho9
T315
T306
A9-Release-A8Complete
s
u
t A11-Registration
Request
A11-Registration Reply
A9-Setup-A8
TA8-setup
A9-AL ConnectedAck
z
aa
Handoff Complete
Taldak
Talc9
T8
time
1
2 Figure 3.19.4.1-1 Anchor PDSN Reachable From Target PCF
Section 3 270
3GPP2 A.S0013-D v2.0
a. User data flow is active using a PPP session between the MS and the source/anchor PDSN. During the setup of the A10 connection(s), the source/anchor PDSN returned its Anchor P-P Address in the A11-Registration Reply message to the source PCF. The source PCF in turn relayed both the anchor PDSN address and the anchor P-P address to the source BS. Note that if the source PDSN was not the same as the anchor PDSN, then a P-P connection would exist between the source PDSN and the anchor PDSN. The PCF shall then also return the source PDSN address to the BS after the setup of the A10 connection.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
b. Based on an MS report that it crossed a network specified threshold for signal strength, changes to a different ANID, or for other reasons, the source BS recommends cdma2000 to cdma2000 hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7. The source BS includes the ANID information of the source PCF in the Handoff Required message. It also includes the source PDSN address, anchor PDSN Address, and Anchor P-P Address information elements. The Service Configuration Record in this message identifies the active service instances. The Service Option List information element identifies the dormant and active service instances.
c. The MSC sends a Handoff Request message (which includes the PANID information previously communicated to the MSC via the Handoff Required message) to the target BS. In this message the MSC also relays the source PDSN, anchor PDSN and Anchor P-P Addresses. The Service Configuration Record in this message identifies the active service instances. The Service Option List information element identifies the active and dormant service instances. The MSC starts timer T11.
d. The target BS sends an A9-Setup-A8 message to the target PCF to establish the A8 connection for each active service instance and sets timer TA8-setup. In this case, the handoff indicator field of the A9-Setup-A8 message is set to ‘0’ (during handoff). The target BS includes the PDSN Address (set to the address of the source PDSN), anchor PDSN and Anchor P-P Addresses.
e. Upon receipt of the A9-Setup-A8 message(s) from the target BS, the target PCF recognizes the presence of the Anchor P-P Address and establishes an A10 connection with the anchor PDSN for each active service instance using the anchor PDSN Address. The lifetime field in the A11-Registration Request message is set to Tpresetup, the ‘S’ bit is set to ‘1’ indicating simultaneous binding and the P-P address NVSE is attached (indicating fast handoff request). The A11-Registration Request message also contains the A10 Connection Setup Airlink Record. The PCF starts a timer Tregreq associated with each active service instance for which an A11-Registration Request message is sent. The PDSN accepts the connection and indicates that the fast handoff is accepted by returning the A11-Registration Reply message with the same Anchor P-P Address. The PCF stops the associated timer Tregreq when it receives an A11-Registration Reply message. Note that if the source PDSN was not the same as the anchor PDSN, and the anchor PDSN was not reachable from the target BS/PCF, then the target PCF connects to the source PDSN, and the existing P-P connection(s) would be reused for the new A10 connection(s).
f. The target PCF returns an A9-Connect-A8 message for each active service instance that includes the PDSN Address (set to the address of the target PDSN), the anchor PDSN, and the Anchor P-P Addresses to indicate that the fast handoff was accepted and starts timer Twaitho9. When the target BS receives the A9-Connect-A8 message(s) it stops timer TA8-setup.
Note: The target BS stores the anchor PDSN and Anchor P-P Addresses for use in the event that this fast handoff is superseded by another fast handoff.
271 Section 3
3GPP2 A.S0013-D v2.0
g. The target BS sends a Handoff Request Acknowledgment message to the MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio channel. The MSC stops timer T11.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
h. At this point in time, PDSN continues to forward packet data to the source BS via source PCF. It also forwards user data to the target PCF, which at this time discards the data.
i. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The source BS stops timer T7.
j. The source BS sends an A9-AL Disconnected message to the source PCF. The BS starts an associated timer Tald9. The source PCF stops packet transmission to the source BS. The source PCF sends A9-AL Disconnected Ack message in response to the A9-AL Disconnected message and starts timer Taldak. The source BS stops associated timer Tald9.
k. The source BS sends the General Handoff Direction Message or Universal Handoff Direction Message to the MS. If the BS requests an acknowledgement it starts T8. If the MS is allowed to return to the source BS, then timer Twaitho is started by the source BS.
l. The MS may acknowledge the General Handoff Direction Message or Universal Handoff Direction Message by sending an MS Ack Order to the source BS. If the BS has started timer T8, it stops it. If the General Handoff Direction Message or Universal Handoff Direction Message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
m. The source BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the target BS. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been started (i.e., return on failure was requested), the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
n. The MS sends a Handoff Completion Message to the target BS. The target BS detects that the MS has successfully accessed the target BS and stops timer T9. If timer T9 had expired the BS shall send Handoff Failure message to the MSC. Refer to [14] for detail procedures.
o. The target BS sends the BS Ack Order to the MS.
p. The target BS sends an A9-AL (Air Link) Connected message to the target PCF and starts an associated timer Talc9. The target PCF stops timer Twaitho9.
q. The target PCF sends an Active Start Airlink Record to the anchor PDSN in an A11-Registration Request message for each active service instance. The A11-Registration Request message contains Trp as lifetime and the S bit is cleared. The target PCF starts an associated timer Tregreq. The PDSN sends an A11-Registration Reply message to the target PCF in response to each A11-Registration Request message. The target PCF stops associated timer Tregreq. Note: before receipt of the Active Start Airlink Record the PDSN is still transmitting the user data stream to the source BS/PCF and the target BS/PCF via the pre-setup A10 connection(s). On receipt of the Active Start Airlink Record, the PDSN stops sending user data to the source PCF.
r. The target PCF sends an A9-AL (Air Link) Connected Ack message in response to the A9-AL (Air Link) Connected message and stops timer Talc9.
Section 3 272
3GPP2 A.S0013-D v2.0
s. The target BS sends a Handoff Complete message to the MSC to notify it that the MS has successfully completed the hard handoff.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
t. The target BS sends an A9-Setup-A8 message to the target PCF for each dormant service instance of the MS; the A9-Setup-A8 message has the Data Ready Indicator set to ‘0’. Steps ‘t’ through ‘y’ may occur anytime after step ‘n’.
u. The target PCF determines the MS is in fast handoff. The target PCF sends an A11-Registration Request to the same PDSN used for the pre-setup A10 connection(s) to initiate A10 connection establishment for each dormant service instance. The target PCF starts an associated timer Tregreq for each message sent. Each A11-Registration Request message contains Trp as lifetime, zero S bit value, the Mobility Event Indicator and Accounting Data (R-P Session Setup Airlink Record). The PDSN determines the MS is in fast handoff. The PDSN returns an A11-Registration Reply message to the target PCF for each A11-Registration Request message (for each service dormant instance) received. The A11-Registration Reply message(s) do not contain the Data Availability Indicator. The target PCF stops the associated timer(s) Tregreq.
v. The target PCF returns an A9-Release-A8 Complete message for each A9-Setup-A8 message sent by the target BS
w. The PDSN initiates termination of the A10 connection to the source PCF for each service instance (both active and dormant) established via the target PCF as follows: The PDSN sends an A11-Registration Update message to the source PCF to disconnect each A10 connection. The PDSN starts associated timer(s) Tregupd. The source PCF sends an A11-Registration Acknowledge message to the PDSN for each A11-Registration Update message received. The PDSN stops the associated timer(s) Tregupd. The source PCF sends an A11-Registration Request message to the PDSN with lifetime zero to clear each A10 connection. The source PCF starts the associated timer(s) Tregreq. The PDSN sends an A11-Registration Reply message to the source PCF for each A11-Registration Request message received. The A10 connection(s) are now released. The source PCF stops the associated timer(s) Tregreq.
x. Data flows between the anchor PDSN and target PCF.
y. The MSC sends a Clear Command to the source BS. The source BS stops timer T306. The MSC starts timer T315. Note this step may occur any time after step ‘s’.
z. For each active service instance the source BS sends an A9-Release-A8 message to the source PCF to release the A8 connection and starts timer Tre19. Upon the receipt of the A9-Release-A8 message from the source BS, the source PCF releases the A8 connection, stops timer Taldak, and responds with an A9-Release-A8 Complete message. When the source BS receives the A9-Release-A8 Complete message it stops timer Tre19. The source BS releases the traffic channel.
aa. The source BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315. This may occur any time after the traffic channel is released. At this point the fast handoff is completed.
3.19.4.2 Anchor PDSN Not Reachable from Target PCF 42
43
44
45
46
This call flow shows the case of an initial fast handoff (source PDSN is the same as the anchor PDSN) from the source BS/PCF to a target BS/PCF where the target BS/PCF is not able to reach the anchor PDSN because the target BS/PCF is in a different PDSN selection domain than the anchor PDSN.
273 Section 3
3GPP2 A.S0013-D v2.0
A11-Registration Request
A11-Registration Reply
MS Source BS
MSC
Handoff Required
Handoff Request
Source PCF
HandoffRequest Ack
Handoff Command
GHDM/ UHDM
Handoff Commenced
A9-AL-Connected Ack
A9-AL Disconnected
A9-AL Disconnected Ack
a
b
d
e
c
f
g
h
l
k
j
i
A11-Registration Request
A11-Registration Reply
m
n
o
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
Active packet data session
Active packet data session
A9-ALConnected
t
x
y
T7
TA8-setup
T11
T9
Twaitho9
T306
Talc
A9-Release-A8 Complete
A11-Registration Request
A11-Registration Reply
u
v
A9-Setup-A8
w
TA8-setup
p
Handoff Complete
Taldak
T8
time
Handoff Completion
BS Ack Order
MS Ack Order
1
2 Figure 3.19.4.2-1 Anchor PDSN Not Reachable From Target PCF
Section 3 274
3GPP2 A.S0013-D v2.0
T306
MS Source BS
MSCSource PCF
cc
Target BS
Target PCF
Anchor PDSN
Target PDSN
Active packet data session
Clear Command
A9-Release-A8
A9-Release-A8 Complete
Clear Complete
z
aa
bb
T315
Taldak
time
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Figure 3.19.4.2-1 (Cont.) Anchor PDSN Not Reachable From Target PCF
a. User data flow is active using a PPP session between the MS and the source/anchor PDSN. During the setup of the A10 connection(s), the source/anchor PDSN returned its P-P address in the A11-Registration Reply message(s). The source PCF in turn relayed both the anchor PDSN and Anchor P-P Addresses to the source BS. Note that if the source PDSN was not the same as the anchor PDSN, then a P-P connection would exist between the source PDSN and the anchor PDSN, and the PCF would also return the source PDSN address to the BS during the setup of the A10 connection.
b. Based on an MS report that it crossed a network specified threshold for signal strength, changes to a different ANID, or for other reasons, the source BS recommends a cdma2000 to cdma2000 hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7. The source BS includes the ANID information of the source PCF in the Handoff Required message. It also includes the Source PDSN Address, Anchor PDSN Address, and Anchor P-P Address information elements to request fast handoff. The Service Configuration Record in this message identifies the active service instances. The Service Option List information element identifies the dormant service instances, if any exist.
c. The MSC sends a Handoff Request message (which includes the ANID information previously communicated to the MSC via the Handoff Required message) to the target BS. This message contains the source PDSN Address, anchor PDSN Address, and Anchor P–P Address information elements. The Service Configuration Record in this message identifies the active service instances. The Service Option List information element identifies the dormant service instances if any exist. The MSC starts timer T11.
d. The target BS sends an A9-Setup-A8 message to the target PCF to establish the A8 connection for each active service instance and sets an associated timer TA8-setup. The handoff indicator field of the A9-Setup-A8 message is set to ‘0’ (during handoff). The target BS includes the PDSN Address (set to the address of the source PDSN), anchor PDSN, the Anchor P-P Address, and the ANID received in the Handoff Request message.
e. The target PCF determines it cannot establish A10 connection(s) with the anchor PDSN or with the source PDSN and selects another PDSN, the target PDSN. The target PCF establishes an A10 connection for each active service instance to be handed off. The lifetime field in each A11-Registration Request message is set to Tpresetup, the ‘S’ bit is set to ‘1’ indicating simultaneous binding, and the Anchor P-P
275 Section 3
3GPP2 A.S0013-D v2.0
Address NVSE is included to indicate a fast handoff operation. Each A11-Registration Request message also includes the A10 Connection Setup Airlink Record. The target PCF starts the associated timer(s) Tregreq. The target PDSN accepts the connection(s) and the fast handoff request by returning A11-Registration Reply message(s) with the same Anchor P-P Address it received in the A11-Registration Request message(s). The target PDSN buffers the airlink records as it will need these for accounting purposes after the fast handoff completes (assuming the target PDSN becomes the anchor PDSN at that point in time). The target PDSN also maintains a copy of the airlink records, which may be needed for accounting purposes after the fast handoff completes (if the target PDSN becomes the anchor PDSN). The target PCF stops the associated timer(s) Tregreq. Note that if the target PDSN rejects the fast handoff request, this becomes an ordinary hard handoff. If the target PDSN supports fast handoff, the target PDSN becomes the new anchor PDSN and includes its own P-P address in the A11-Registration Reply message. If the target PDSN does not support fast handoff, then it does not include a P-P address in the A11-Registration Reply message. At this point the call flow in Figure 3.17.4.21-1 starting at step ‘d’ applies.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
f. The target PCF sends A9-Connect-A8 message(s) to the target BS. The target PCF indicates acceptance of the fast handoff by including the PDSN Address (set to the address of the target PDSN), anchor PDSN, and Anchor P-P Addresses. When the target BS receives an A9-Connect-A8 message it stops associated timer TA8-setup. The BS starts timer Twaitho9. Note that the target BS stores the anchor PDSN and Anchor P-P Addresses for use in the event that this fast handoff is superseded by another fast handoff.
g. The target PDSN establishes a P-P connection with the anchor PDSN for each active A10 connection that was set up. P-P establishment may begin as soon as the PDSN receives the fast handoff request in step ‘e’, and may occur in parallel with subsequent RAN procedures. The anchor PDSN indicates the PPP service instance to the target PDSN in the PPP Link Indicator extension. Refer to [8]. Note that if the target PDSN determines that the P-P connection attempt has failed, this becomes an ordinary hard handoff. The target PDSN becomes the new anchor PDSN. At this point the call flow in Figure 3.17.4.21-1 starting at step ‘d’ applies. In step ‘m’ of that call flow, the target PDSN includes its own P-P address to inform the PCF that it has become the anchor PDSN.
h. The target BS sends a Handoff Request Acknowledgment message to the MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio channel. The MSC stops timer T11.
i. The anchor PDSN forwards packet data to the source BS via the source PCF. It also forwards the data over the P-P connection(s) to the target PDSN which, in turn, forwards the data to the target BS via the target PCF. The target PCF discards the data received at this time.
j. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The source BS stops timer T7.
k. The source BS sends an A9-AL Disconnected message to the source PCF. The BS starts an associated timer Tald9. The PCF stops packet transmission to the source BS. The PCF sends A9-AL Disconnected Ack message in response to the A9-AL Disconnected message and starts timer Taldak. The BS stops associated timer Tald9.
l. The source BS sends the General Handoff Direction Message or Universal Handoff Direction Message to the MS across the air interface and starts timer T8. If the MS is allowed to return to the source BS, then timer Twaitho is started by the source BS.
Section 3 276
3GPP2 A.S0013-D v2.0
m. The MS may acknowledge the General Handoff Direction Message or Universal Handoff Direction Message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message. If the General Handoff Direction Message or Universal Handoff Direction Message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
n. The source BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the target BS. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been started (i.e., return on failure was requested), the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
o. The MS sends a Handoff Completion message to the target BS. The target BS detects that the MS has successfully accessed the target BS and stops timer T9. If timer T9 had expired, the BS shall send Handoff Failure message to the MSC. Refer to [14] for detailed procedures.
p. The target BS sends the BS Ack Order to the MS over the air interface.
q. The target BS sends an A9-AL (Air Link) Connected message to the target PCF and starts an associated timer Talc9. The target PCF stops timer Twaitho9.
r. The target PCF stops discarding the user data it is receiving from the PDSN for each active service instance upon receipt of the A9-AL (Air Link) Connected message and begins forwarding the data to the target BS. For each such service instance, the target PCF sends an A11-Registration Request message, containing an Active Start Airlink Record, the Trp as Lifetime, and the ‘S’ bit cleared. The PDSN sends an A11-Registration Reply message to the target PCF in response to each A11-Registration Request message received.
s. The target PCF sends A9-AL (Air Link) Connected Ack message in response to the A9-AL (Air Link) Connected message and stops associated timer Talc9.
t. The target BS sends a Handoff Complete message to the MSC to notify it that the MS has successfully completed the hard handoff.
u. The target BS sends an A9-Setup-A8 message to the target PCF for each dormant service instance of the MS; the A9-Setup-A8 message has the Data Ready Indicator set to ‘0’. Steps ‘u’ through ‘w’ may occur anytime after step ‘o’. The target BS starts an associated timer TA8-setup after each message is sent.
v. The target PCF determines the MS is in fast handoff. The target PCF sends an A11-Registration Request message to the same PDSN used for pre-set up A10 connection(s) to initiate A10 connection establishment for each dormant service instance. The target PCF starts an associated timer Tregreq for each message sent. The A11-Registration Request message contains Trp as lifetime, zero S bit value, the Mobility Event Indicator and Accounting Data (R-P Session Setup Airlink Record). The PDSN determines the MS is in fast handoff. The PDSN returns an A11-Registration Reply message to the target PCF. The A11-Registration Reply message does not contain the Data Availability Indicator. The target PCF stops timer Tregreq.
w. The target PCF returns A9-Release-A8 Complete message for each A9-Setup-A8 message sent by the target BS. The target BS stops the associated timer TA8-setup for each A9-Release-A8 Complete message received.
x. For active service instances, P-P connections already exist between the target PDSN and anchor PDSN. Upon receiving the A11-Registration Request message(s) from the target PCF for the active service instance(s), the target PDSN forwards the Active Start Airlink Record(s) to the anchor PDSN in P-P Registration Request
277 Section 3
3GPP2 A.S0013-D v2.0
message(s) that has/have the ‘S’ bit clear. The anchor PDSN acknowledges this to the target PDSN with a P-P Registration Reply. For dormant service instances no P-P connection exists between the target PDSN and anchor PDSN. On receiving the A11-Registration Request message(s) from the target PCF for the dormant service instance(s), the target PDSN establishes the P-P connection(s) with the anchor PDSN for each such service instance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
y. The anchor PDSN requests the source PCF to disconnect the A10 connection(s) (for both active and dormant service instances) upon receipt of the P-P Registration Request by sending A11-Registration Update message(s). The anchor PDSN starts associated timer(s) Tregupd. The source PCF sends A11-Registration Acknowledge message(s) to the anchor PDSN. The anchor PDSN stops the associated timer(s) Tregupd. The source PCF sends A11-Registration Request message(s) with Lifetime value set to ‘0’ in response. The message(s) contain(s) a final Active Stop Airlink Record in the case of active service instance(s). The source PCF starts timer Tregreq. The anchor PDSN acknowledges with the receipt of each A11- Registration Request message with a A11-Registration Reply message. The source PCF stops associated timer(s) Tregreq.
z. The MSC sends a Clear Command message to the source BS. The source BS stops timer T306. The MSC starts timer T315. This step can happen any time after step ‘t’.
aa. The source BS sends an A9-Release-A8 message to the source PCF to release the A8 connection for each active service instance and starts an associated timer Tre19. Upon the receipt of the A9-Release-A8 message from the source BS, the source PCF releases the A8 connection, stops timer Taldak, and responds with an A9-Release-A8 Complete message. When the source BS receives the A9-Release-A8 Complete message it stops the associated timer Tre19. The traffic channel is released at this point.
bb. The source BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315. This may occur any time after the traffic channel is released.
cc. Data now flows bidirectionally from the anchor PDSN to the target PDSN to the target PCF and the target BS. From the RAN perspective, the fast handoff is completed when the packet data session transitions to the Dormant State (refer to section 3.17.4.6.1) or when a subsequent fast handoff takes place (refer to section 3.19.4.3). Note that if the P-P connection fails before the fast handoff is completed, the target PDSN becomes the new anchor PDSN. It sends an A11-Session Update message including its own P-P address to the target PCF, after which it initiates PPP with the MS.
3.19.4.3 Fast Handoff Superseded by Another Fast Handoff 38
39
40
41
42
43
44
45
46
47
This call flow shows the case where the MS has performed a fast handoff that has not yet completed when a subsequent fast handoff occurs (i.e., source PDSN is not identical to the anchor PDSN). The target PDSN of the previous fast handoff becomes the source PDSN in this handoff.
In this call flow it is assumed that the target PCF cannot reach the anchor PDSN or the source PDSN.
The case where the target PCF can reach the anchor PDSN has a similar call flow, where the target PDSN and the anchor PDSN are collapsed into one node and no messages are exchanged between them. The fast handoff is complete in step ‘nn’.
Section 3 278
3GPP2 A.S0013-D v2.0
The case where the target PCF cannot reach the anchor PDSN but can reach the source PDSN has a similar call flow, where the source PDSN and the target PDSN are collapsed into one node. Bicasting occurs at the source/target PDSN and not at the anchor PDSN (steps ‘j’ and ‘t’). Existing P-P connections are not released (step ‘ee’) and new P-P connections are not set up (steps ‘f’, ‘v’, and ‘bb’). In lieu thereof, accounting information is forwarded to the anchor PDSN according to procedures specified in
1
2
3
4
5
6 [8].
MS Source BS MSC
Handoff Required
Handoff Request
Source PCF
Handoff Request Ack
Handoff Command
GHDM / UHDM
Handoff Commenced
Handoff Completion
MS Ack Order
BS Ack Order
x T waitho
Target BS Target PCF
Source PDSN
Target PDSN
A9 - AL Connected
T 7
T11
T 9
Twaitho9
Anchor PDSN
MS Ack Order
A11-Registration Request
A9 -Setup-A8
A9-Connect-A8
T A8 - setup
a
Time
b
i
a
e
h
j
k
l
n
o
p
q
r
s
t
c
d
T alc9
T 306
P-P Connection Pre- setup
Procedures
A11-Registration Reply
Tregreq
Packet Data Session Active, Data Flow via Source BS, Data Flow Bicast to Target PCF
Packet Data Session Active, Data Flow via Target BS, Data Flow Bicast to Source PCF
Packet Data Session Active, Data Flow via Source BS
f
g
A9 - AL Disconnected
A9 - AL Disconnected Ack m T ald9
T aldak T8
7
8 Figure 3.19.4.3-1 Fast Handoff Superseded by Another Fast Handoff
279 Section 3
3GPP2 A.S0013-D v2.0
MS Source BS MSC Source
PCF
Target BS Target PCF
Source PDSN
Target PDSN
Anchor PDSN
jj
Time
kk
mm
nn
Clear Command
Clear Complete
T315
A9-AL-Connected Ack
A9 - Setup-A8
T A8 - setup
T 306 T alc9
x
z
dd
ee
A9-Release-A8 Complete
A11-Registration Request u
P-P Connection Refresh
Procedures
A11-Registration Reply
Tregreq v
w
A11-Registration Request aa
P-P Connection Setup Procedures
A11-Registration Reply
Tregreq bb
cc
P-P Connection
Release Procedures
A11 - Registration Acknowledge
A11-Registration Reply
A11 - Registration Request
A11-Registration Update
Packet Data Session Active, Data Flow via Target BS
ff
gg
hh
ii
A9 - Release - A8
A9 - Release - A8 Complete T rel9
T aldak
ll
Tregupd
T regreq
Handoff Complete y
1
2
3
4
5
Figure 3.19.4.3-1 (Cont.) Fast Handoff Superseded by Another Fast Handoff
a. User data flow is active using a PPP session between the MS and the anchor PDSN. During the setup of the A10 connection(s), the anchor PDSN returned its P-P address in the A11-Registration Reply message(s). The source PCF in turn relayed both the
Section 3 280
3GPP2 A.S0013-D v2.0
Anchor PDSN and Anchor P-P Addresses to the source BS. The PCF also returned the source PDSN Address to the BS during the setup of the A10 connection.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
b. Based on an MS report that the MS crossed a network specified threshold for signal strength, changes to a different ANID, or for other reasons, the source BS recommends a cdma2000 to cdma2000 hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7. The source BS includes the PANID information in the Handoff Required message. It also includes the Source PDSN, Anchor PDSN, and Anchor P-P addresses to request fast handoff. The Service Configuration Record in this message identifies the active service instances. The Service Option List information element identifies all dormant and active service instances.
c. The MSC sends a Handoff Request message (which includes the PANID information previously communicated to the MSC via the Handoff Required message) to the target BS. In this message it relays the Source PDSN, Anchor PDSN, and Anchor P-P addresses. The Service Configuration Record in this message identifies the active service instances. The Service Option List information element identifies all dormant and active service instances. The MSC starts timer T11.
d. The target BS sends an A9-Setup-A8 message to the target PCF to establish the A8-Connection for each active service instance and starts an associated timer TA8-setup. The handoff indicator field of the A9-Setup-A8 message is set to ‘0’ (during handoff). The target BS includes the PDSN Address (set to the address of the source PDSN), Anchor PDSN Address, and Anchor P-P Address.
e. The target PCF determines it cannot establish A10 connection(s) with the anchor PDSN or with the source PDSN and selects another PDSN, the target PDSN. The target PCF sends an A11-Registration Request to the target PDSN for each active service instance to be handed off. The lifetime field in each A11-Registration Request message is set to Tpresetup, the ‘S’ bit is set to ‘1’ indicating simultaneous binding, and the Anchor P-P Address NVSE is included to indicate a fast handoff operation. Each A11-Registration Request message also includes the A10 Connection Setup Airlink Record. The target PCF starts the associated timer(s) Tregreq. Note that if the target PDSN rejects the fast handoff request, this becomes an ordinary hard handoff. If the target PDSN supports fast handoff, the target PDSN becomes the new anchor PDSN and includes its own P-P address in the A11-Registration Reply message. If the target PDSN does not support fast handoff, then it does not include a P-P address in the A11-Registration Reply message. At this point the call flow in Figure 3.17.4.21-1 starting at step ‘d’ applies. Note that if the anchor PDSN had been reachable, then the target PCF shall select the anchor PDSN to be the target PDSN; if the anchor PDSN Address is not reachable, the PCF shall try the source PDSN; if the source PDSN is reachable, the target PCF shall select the source PDSN to be the target PDSN. At this point, the call flow in Figure 3.19.4.1-1 starting at step ‘e’ applies and the fast handoff is completed. In the case when the anchor PDSN is selected, the P-P connection(s) are released and no new ones are created. In the case when the source PDSN is selected, the P-P connections between anchor PDSN and source PDSN are kept and no new ones are created.
f. The target PDSN establishes a P-P connection with the anchor PDSN for each A11-Registration Request received in step ‘e’ and forwards the associated airlink records to the anchor PDSN according to procedures specified in [8]. The target PDSN also maintains a copy of the airlink records, which may be needed for accounting purposes after the fast handoff completes (if the target PDSN becomes the anchor PDSN). P-P connection establishment may begin as soon as the PDSN receives the fast handoff request in step ‘e’, and may occur in parallel with subsequent RAN
281 Section 3
3GPP2 A.S0013-D v2.0
procedures. Note that if the target PDSN determines that the P-P connection attempt has failed, this becomes an ordinary hard handoff. The target PDSN becomes the new anchor PDSN. At this point the call flow in Figure 3.17.4.21-1 starting at step ‘d’ applies. In step ‘m’ of that call flow, the target PDSN includes its own P-P address to inform the PCF that it has become the anchor PDSN.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
g. The target PDSN accepts the connection(s) and the fast handoff request by returning A11-Registration Reply message(s) with the same Anchor P-P Address it received in the A11-Registration Request message(s). The target PCF stops the associated timer(s) Tregreq.
h. The target PCF sends A9-Connect-A8 message(s) to the target BS. The target PCF indicates acceptance of the fast handoff by including the PDSN Address (set to the address of the Target PDSN), Anchor PDSN, and Anchor P-P Addresses. When the target BS receives an A9-Connect-A8 message it stops the associated timer TA8-setup. The BS starts timer Twaitho9. Note that the target BS stores the Anchor PDSN and Anchor P-P Addresses for use in the event that this fast handoff is superseded by another fast handoff.
i. The target BS sends a Handoff Request Acknowledgment message to the MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio channel. The MSC stops timer T11.
j. The anchor PDSN forwards packet data to the source BS via the source PDSN and the source PCF. It also forwards the data over the P-P connection(s) to the target PDSN, which, in turn, forwards it to the target PCF. The target PCF discards the data at this time.
k. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The source BS stops timer T7.
l. The source BS sends an A9-AL Disconnected message to the source PCF. The BS starts an associated timer Tald9. The PCF stops packet transmission to the source BS.
m. The PCF sends A9-AL Disconnected Ack message in response to the A9-AL Disconnected message and starts timer Taldak. The BS stops associated timer Tald9.
n. The source BS sends the General Handoff Direction Message or Universal Handoff Direction Message to the MS and starts timer T8. If the MS is allowed to return to the source BS, then timer Twaitho is started by the source BS.
o. The MS may acknowledge the General Handoff Direction Message or Universal Handoff Direction Message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message. If the General Handoff Direction Message or Universal Handoff Direction Message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
p. The source BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the target BS. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been started (i.e., return on failure was requested), the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
q. The MS sends a Handoff Completion message to the target BS. The target BS detects that the MS has successfully accessed the target BS and stops timer T9.
r. The target BS sends the BS Ack Order to the MS over the air interface.
Section 3 282
3GPP2 A.S0013-D v2.0
s. Upon the receipt of the Handoff Completion message from MS, the target BS sends an A9-AL (Air Link) Connected message to the target PCF and starts timer Talc9. The target PCF stops timer Twaitho9.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
t. The target PCF stops discarding the user data it is receiving from the PDSN for each active service instance upon receipt of the A9-AL (Air Link) Connected message and begins forwarding the data to the target BS. At this point, data flows bidirectionally between the MS and the anchor PDSN. Data is still forwarded to the source PCF, which discards the data.
u. For each active service instance, the target PCF sends an A11-Registration Request message, containing an Active Start Airlink Record, Trp as lifetime and the ‘S’ bit cleared. The target PCF starts Tregreq.
v. The A11 procedures in steps ‘u’ and ‘w’ are replicated on the P-P interface according to procedures specified in [8]. This step may occur concurrently with subsequent RAN procedures.
w. The PDSN sends an A11-Registration Reply message in response to each A11-Registration Request message received in step ‘u’ to the target PCF. The target PCF stops each associated timer Tregreq.
x. The target PCF sends an A9-AL (Air Link) Connected Ack message as response to the A9-AL (Air Link) Connected message and stops timer Talc9.
y. The target BS sends a Handoff Complete message to the MSC to notify it that the MS has successfully completed the hard handoff. Refer to [14] for detailed procedures.
z. The target BS sends an A9-Setup-A8 message to target PCF for each dormant service instance of the MS – the A9-Setup-A8 has the Data Ready Indicator set to zero. Steps ‘z’ through ‘dd’ may occur anytime after step ‘q’. The target BS starts an associated timer TA8-setup after each message is sent.
aa. The target PCF determines the MS is in fast handoff. The target PCF sends an A11-Registration Request message to the same PDSN used for pre-setup A10 connection(s) to initiate A10 connection establishment for each dormant service instance. The target PCF starts an associated timer Tregreq for each message sent. The A11-Registration Request message contains Trp as lifetime, zero S bit value, the Mobility Event Indicator and Accounting Data (R-P Session Setup Airlink Record).
bb. The A11 procedures in steps ‘aa’ and ‘cc’ are replicated on the P-P interface according to procedures specified in [8]. This step may occur concurrently with subsequent RAN procedures.
cc. The PDSN determines the MS is in fast handoff. The PDSN returns an A11-Registration Reply message in reply to each A11-Registration Request message received in step ‘aa’ to the target PCF. The A11-Registration Reply message does not contain the Data Availability Indicator. The target PCF stops each associated timer Tregreq.
dd. The target PCF returns A9-Release-A8 Complete message for each A9-Setup-A8 message sent by the target BS. The target BS stops the associated timer(s) TA8-setup.
ee. The anchor PDSN initiates teardown of the P-P connections to the source PDSN according to procedures specified in [8]. The accounting records received in step ‘hh’ are forwarded to the anchor PDSN.
283 Section 3
3GPP2 A.S0013-D v2.0
ff. The source PDSN requests the source PCF to disconnect the A10 connection(s) (for both active and dormant service instances) by sending A11-Registration Update message(s). The source PDSN starts the associated timer(s) Tregupd.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
gg. The source PCF sends A11-Registration Acknowledge message(s) to the source PDSN. The anchor PDSN stops the associated timer(s) Tregupd.
hh. The source PCF sends A11-Registration Request message(s) with Lifetime value set to ‘0’ in response. The message(s) contain(s) a final Active Stop Airlink Record in the case of active service instance(s). The source PCF starts timer Tregreq
ii. The source PDSN acknowledges this with A11-Registration Reply message(s). The source PCF stops associated timer(s) Tregreq.
jj. Upon receiving the Handoff Complete message from the target BS (in step ‘y’), the MSC sends a Clear Command to the source BS. The source BS stops timer T306. The MSC starts timer T315.
kk. The source BS sends an A9-Release-A8 message to the source PCF to release the A8–connection for each active service instance and starts an associated timer Tre19. The source PCF stops Taldak.
ll. Upon the receipt of the A9-Release-A8 message from the source BS, the source PCF releases the A8 connection and responds with an A9-Release-A8 Complete message. When the source BS receives the A9-Release-A8 Complete message it stops associated timer Tre19. The traffic channel is released at this point.
mm. The source BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315. Clear Complete may occur any time after the traffic channel is released.
nn. The fast handoff is completed after the packet data session transitions to the Dormant State (refer to section 3.17.4.6.1) or when a subsequent fast handoff takes place. Meanwhile, the anchor PDSN continues to serve the MS via P-P connections to the target PDSN. Note that if the P-P connection fails before the fast handoff is completed, the target PDSN becomes the new anchor PDSN. It sends an A11-Session Update message including its own P-P address to the target PCF, after which it initiates PPP with the MS.
3.19.5 Intergeneration Packet Data Handoff 31
32
33
34
35
36
Throughout this section it is assumed that that MS is capable of supporting both 3G and 2G packet data services (refer to [21]) and both air interfaces as defined in [1]~[6] and [10]. The message flows and timers between the MSC and the 2G BS in the figure are outside the scope of this standard. For simplicity, timers on the 2G network are not shown in the following call flows.
3.19.5.1 Hard Handoff from 2G System to 3G System 37
38
39
40
41
42
43
44
The MS is engaged in a 2G packet call on the 2G system. The packet data call needs to be re-established on the 3G side, since 2G packet data service is not supported on the 3G system. It is assumed that the 2G BS instructs the MS to reconnect the packet data service upon completion of handoff (refer to [21]). After the MS has been acquired on the 3G BS, the service option is negotiated and changed to 3G packet data service. In this call flow, the box marked “MSC” may represent one or two MSCs. In the case of inter-MSC handoff, inter-MSC signaling is not specified.
Section 3 284
3GPP2 A.S0013-D v2.0
MS 2G BS time
(Handoff Required)
Handoff Request
a
b
c
e
f Handoff
Request Ack g
h
Handoff Complete
i
k
l
j
PCF
PPP
m
n
p
r
o
q
(Handoff Command) (Handoff Direction Message)
(MS Ack Order)
(Handoff Commenced)
Handoff Completion Message Message
(Clear Complete)
(Clear Command)
T9
MSC
BS Ack Order
3G BS
User Data Transmission
s
PDSN
A9-Setup-A8
A9-Connect-A8 TA8-setup
A9-AL Connected
A9-AL Connected Ack
t
Talc9
(Service Option Control Message)
Service Negotiation
u
v
T11
A11-Registration Request
A11-Registration Reply
w
Tregreqq
Null ForwardTraffic Channel frames d
(T8)
1
2
3
4
5
6
7
Figure 3.19.5.1-1 Hard Handoff from 2G System to 3G System
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the 2G BS sends the equivalent of a Handoff Required message to the MSC with a preferred list of target cells.
b. The 2G BS requires the MS to reconnect the packet data service upon successful completion of the hard handoff (refer to [21]).
285 Section 3
3GPP2 A.S0013-D v2.0
c. The MSC tries each of the elements in the preferred cell list until one cell is found that has an available radio channel. The MSC sends a Handoff Request message to the 3G BS, with a Service Option set to 2G packet data. The MSC starts timer T11.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
d. Upon receipt of the Handoff Request message, the 3G BS allocates suitable idle (radio) resources. The 3G BS starts transmitting null TCH data on the forward traffic channel for the MS.
e. The 3G BS sends an A9-Setup-A8 message to the PCF with the Handoff indicator in the A9 Indicators information element set to ‘1’, and starts timer TA8-setup. The 3G BS sets the SO value to ‘21H (3G Packet Data)’, because that is the value that will be used after the call is set up on the target side. The 3G BS assigns an SR_ID to the PDSI at this point, and will use this value when it re-negotiates the SO in step ‘n’.
f. Upon receipt of the A9-Setup-A8 message, the PCF sends an A9-Connect-A8 message to the 3G BS. Upon receipt of the A9-Connect-A8 message, the 3G BS stops timer TA8-setup.
g. The 3G BS returns a Handoff Request Acknowledge message to the MSC with appropriate RF channel information and an IS-2000 service configuration record containing a 2G packet data service option to allow the MS to be instructed to tune to the new RF channel. The MSC stops timer T11. The 3G BS starts timer T9 to wait for the MS to arrive on the radio channel.
h. Upon receipt of the Handoff Request Acknowledge message from the 3G BS, the MSC prepares to switch the MS from the 2G BS to the 3G BS. The MSC sends the equivalent of a Handoff Command message to the 2G BS containing appropriate RF channel information from the 3G BS.
i. The 2G BS instructs the MS to handoff by sending a handoff direction message and starts the equivalent of timer T8.
j. The MS acknowledges receipt of the handoff direction message. The 2G BS stops the equivalent of timer T8 upon receipt of this message.
k. Upon receipt of confirmation from the MS, the 2G BS sends the equivalent of a Handoff Commenced message to the MSC.
l. Upon synchronization of the traffic channel, the MS sends a Handoff Completion Message to the 3G BS. The 3G BS stops timer T9.
m. The 3G BS acknowledges receipt of the Handoff Completion Message by sending a BS Ack Order to the MS.
n. The MS attempts to reconnect the 2G-packet data service option. The 3G BS uses service negotiation to instruct the MS to use the 3G packet data service.
o. The 3G BS sends an A9-AL Connected message to the PCF and starts timer Talc9.
p. The PCF sends an A11-Registration Request message with a non-zero Lifetime value and with a Mobility Event Indicator within CVSE to the PDSN. The message includes Accounting Data (R-P Session Setup Airlink). The PCF starts timer Tregreq.
q. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. If the PDSN has data for the MS, it responds to the PCF with an A11-Registration Reply message with the Data Available Indicator in the CVSE. The target PCF stops timer Tregreq.
r. The PCF sends an A9-AL Connected Ack message to the 3G BS. The 3G BS stops timer Talc9.
Section 3 286
3GPP2 A.S0013-D v2.0
s. The 3G BS sends a Handoff Complete message to the MSC indicating successful completion of hard handoff and that the 3G packet data service option has been connected.
1
2
3
4
5
6
7
8
9
10
11
12
t. The PPP connection between the MS and the PDSN is established and the MS performs MIP registration (if required) with the packet network.
u. User data is exchanged between the MS and the correspondent node over this A10 connection.
v. Upon receipt of a Handoff Complete message, the MSC initiates release of the MSC resources used in the handoff. MSC sends the equivalent of a Clear Command message to the 2G BS, informing it of the success of the hard handoff.
w. The 2G BS sends the equivalent of a Clear Complete message to the MSC acknowledging success of the handoff.
3.19.5.2 Hard Handoff from 3G System to 2G System, PCF not used in the 2G system 13
14
15
16
17
The MS is engaged in a 3G packet call on the 3G system. The packet data call needs to be re- negotiated to 2G on the 3G side, since 3G packet data service is not supported on the 2G system. In this call flow, the box marked “MSC” may represent one or two MSCs. In the case of inter-MSC handoff, ANSI-41 signaling is not specified.
287 Section 3
3GPP2 A.S0013-D v2.0
Twaitho
MS 3G BS time
Handoff Requireda
b
c
d
e
f
(Handoff Complete)
g
i
k
h
PCF
l
m
o
n
p
Handoff Command
T7
Handoff Direction Message
MS Ack Order
Handoff Commencedj
(Handoff Completion Message)
Clear Complete
Clear Command
T315
T306
MSC
(BS Ack Order)
2G BS PDSN
A9-AL Disconnected
A9-AL Disconnected AckTald9
A9-Release A8
A9-Release A8 CompleteTrel9
q
(HandoffRequest Ack)
(Handoff Request)
x
A11-Registration Update
A11-Registration Acknowledge
A11-Registration Request
A11-Registration Reply
Tregupd
Tregreq
r
s
t
Null forward traffic channels frames
u
Taldak
T8
1
2
3
4
5
Figure 3.19.5.2-1 Hard Handoff from 3G System to 2G System
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the 3G BS sends a Handoff Required message to the MSC with a preferred list of target cells and starts timer T7.
Section 3 288
3GPP2 A.S0013-D v2.0
b. The MSC tries each of the elements in the preferred cell list until one cell is found that has an available radio channel. The MSC sends the equivalent of a Handoff Request message to the 2G BS with a 2G packet data service option.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
c. Upon receipt of the equivalent Handoff Request message, the 2G BS allocates suitable idle (radio) resources. The BS starts transmitting null TCH data on the forward traffic channel for the MS.
d. The 2G BS returns the equivalent of a Handoff Request Acknowledge message to the MSC with appropriate RF channel information to allow the MS to be instructed to tune to the new RF channel.
e. The MSC prepares to switch the MS from the 3G BS to the 2G BS. The MSC sends a Handoff Command message to the 3G BS containing appropriate RF channel information and a IS-2000 service configuration record containing a 2G packet data service option received from the 2G BS. The 3G BS stops timer T7.
f. The 3G BS sends an A9-AL Disconnected message to the PCF. The 3G BS starts timer Tald9.
g. The PCF sends an A9-AL Disconnected Ack message to the 3G BS and starts timer Taldak. The 3G BS stops timer Tald9.
h. BS sends the Handoff Direction Message to the MS and starts timer T8. The message instructs the MS to handoff and change to the 2G packet data service option. If the MS is allowed to return to the 3G BS, the 3G BS starts timer Twaitho.
i. The MS may acknowledge receipt of the handoff direction message by sending an MS Ack Order message to 3G BS. The 3G BS stops timer T8 upon receipt of this message.
j. The 3G BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the 2G BS channel. The 3G BS starts timer T306. If timer Twaitho has been started, the 3G BS shall wait for that timer to expire before sending the Handoff Commenced message.
k. Upon synchronization of the traffic channel, the MS sends the equivalent of a Handoff Completion Message to the 2G BS.
l. The 2G BS sends the equivalent of a BS Ack Order to the MS.
m. The 2G BS sends the equivalent of a Handoff Complete message to the MSC indicating successful completion of the hard handoff and that the 2G packet data service has been connected.
n. The MSC initiates release of the MSC resources used in the handoff. The MSC sends a Clear Command message to the 3G BS, informing it of the success of the hard handoff, and starts timer T315. The 3G BS stops timer T306 upon receipt of this message.
o. The 3G BS sends an A9-Release A8 message to the PCF and starts timer Trel9. The PCF stops timer Taldak upon receipt of this message.
p. The PCF sends an A9-Release A8 Complete message to the 3G BS; the 3G BS stops timer Trel9.
q. The 3G BS sends a Clear Complete message to the MSC acknowledging success of the handoff. The MSC stops timer T315 on receipt of the Clear Complete message.
289 Section 3
3GPP2 A.S0013-D v2.0
r. At the expiration of the PPP timer or other internal event, the PDSN initiates release of the A10 connection with the PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
1
2
3
4
5
6
7
8
9
s. The PCF responds with an A11-Registration Acknowledge message to PDSN. The PDSN stops timer Tregupd.
t. The PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The PCF starts timer Tregreq.
u. The PDSN sends the A11-Registration Reply message with an accept indication to the PCF. The PCF releases the A10 connection.
3.19.5.3 Intra-PCF Hard Handoff from 3G BS to 2G BS 10
11
12
The MS is engaged in a 3G packet call on the 3G BS. The 3G BS and the 2G BS are both connected to the same PCF.
Section 3 290
3GPP2 A.S0013-D v2.0
MS 3G BS PCF time
a
b
c
d
e
f
Handoff Required
(Handoff Request)
2G BS
g
i
h
j
k
l
m
T306
T315
Twaitho x
MSC
(A9-Setup-A8)
(A9-Connect-A8)
(Handoff Request Ack)
Handoff Command
Handoff DirectionMessage
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) n
o
p
q
A9-AL Disconnected
r
A9-AL Disconnected Ack
s
Tald9
Tre19 t
Null forward traffic channels frames
u
T8
Taldak
1
2
3
4
5
6
7
8
Figure 3.19.5.3-1 Intra-PCF Hard Handoff from 3G BS to 2G BS
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the 3G BS recommends a hard handoff to one or more cells in the domain of the 2G BS. The 3G BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7.
b. The MSC sends the equivalent of a Handoff Request message to the 2G BS with a 2G packet data service option.
291 Section 3
3GPP2 A.S0013-D v2.0
c. Upon receipt of the equivalent Handoff Request message, the 2G BS allocates suitable idle (radio) resources. The BS starts transmitting null TCH data on the forward traffic channel for the MS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
d. The 2G BS sends the equivalent of an A9-Setup-A8 message to the PCF to establish the A8-Connection. In this case, the handoff indicator field of the equivalent A9-Setup-A8 message is set to ‘1’ (during handoff).
The establishment of the A10 connection is not performed because the handoff indicator field of the equivalent A9-Setup-A8 message is set to ‘1’ (during handoff).
e. The PCF establishes the A8 connection, and continues to forward packet data received from PDSN to the 3G BS (i.e., the 2G BS doesn’t receive packet data from the PCF). The PCF sends the equivalent of an A9-Connect-A8 message to the 2G BS.
f. The 2G BS sends the equivalent of a Handoff Request Acknowledge message to the MSC with appropriate RF channel information to allow the MS to be instructed to tune to the new RF channel.
g. The MSC prepares to switch the MS from the 3G BS to the 2G BS. The MSC sends a Handoff Command message to the 3G BS containing appropriate RF channel information and a IS-2000 service configuration record containing a 2G packet data service option received from the 2G BS. The 3G BS stops timer T7.
h. The PCF stops packet transmission to the 3G BS upon receipt of A9-AL (Air Link) Disconnected message from the 3G BS. The 3G BS starts timer Tald9.
i. The PCF sends an A9-AL (Air Link) Disconnected Ack message in response to the A9-AL Disconnected message. The PCF starts timer Taldak. The 3G BS stops timer Tald9.
j. The 3G BS sends the handoff direction message to the MS and starts timer T8. The message instructs the MS to handoff and change to 2G packet data service option. If the MS is allowed to return to the 3G BS, then the 3G BS starts timer Twaitho.
k. The MS may acknowledge the Handoff Direction Message by sending an MS Ack Order to the source BS. The source BS stops timer T8 upon receipt of this message.
l. The 3G BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the 2G BS channel. The 3G BS starts timer T306. If timer Twaitho has been started, the 3G BS shall wait for that timer to expire before sending the Handoff Commenced message.
m. Upon synchronization of the traffic channel the MS sends the equivalent of a Handoff Completion message to the 2G BS.
n. The 2G BS sends the equivalent of a BS Ack Order to the MS over the air interface.
o. The 2G BS sends the equivalent of an A9-AL (Air Link) Connected message to the PCF. The PCF restarts packet data transmission to the 2G BS.
p. The PCF sends the equivalent of an A9-AL Connected Ack message to the 2G BS.
q. The 2G BS sends the equivalent of a Handoff Complete message to the MSC to notify it that the MS has successfully completed the hard handoff and that the 2G packet data service has been connected.
r. The MSC sends a Clear Command message to the 3G BS and starts timer T315. The 3G BS stops timer T306 upon receipt of this message.
Section 3 292
3GPP2 A.S0013-D v2.0
s. The 3G BS sends an A9-Release-A8 message to the PCF to release the A8 connection and starts timer Tre19. The PCF stops timer Taldak.
1
2
3
4
5
6
7
t. Upon the receipt of the A9-Release-A8 message from the 3G BS, the PCF releases the A8 connection and responds with an A9-Release-A8 Complete message. Upon receiving A9-Release-A8 message the 3G BS stops timer Tre19.
u. The 3G BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315.
3.19.5.4 Dormant Handoff from 2G System to 3G System 8
9
10
11
12
The MS is engaged in a 2G packet call on the 2G system and is dormant. The packet data call needs to be re-established on the 3G side, since 2G packet data service is not supported on the 3G system. The call flow is identical to the call flow shown in 3.17.4.14. Dormant Handoff (Inter-BS/Inter-PCF) - Mobile served by a different PDSN.
3.19.5.5 Dormant Handoff from 3G System to 2G System 13
14
15
16
17
If a dormant MS roams to a 2G system, the procedures on the 3G system simply allow for the A10 link to be torn down when the PPP timer expires. Refer to section 3.17.4.14 Inter-PCF Dormant Handoff – Mobile Served by a New Target PDSN. Step ‘l’ through ‘o’.
3.19.6 Alternate Dormant Handoff 18
19
20
21
22
23
24
25
This section contains call flows for the Alternate Dormant Handoff feature.
To perform dormant handoff of a packet data session, the MS initiates the dormant handoff of each of its dormant PDSIs. The packet data session may become active as a result of the dormant handoff of one PDSI (i.e. PDSN has data to send to MS over that PDSI) in which case the dormant handoff of the remaining PDSIs occur as given in section 3.17.4.13.2.
3.19.6.1 Intra-PDSN Alternate Dormant Handoff of a PDSI, While the Packet Data Session is Dormant 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
The following call flow provides an illustration for a successful handoff of a dormant PDSI during the Dormant State of the packet data session from source PCF to target PCF. It is assumed that the PCF is uniquely identified by the CANID. On detection of a new PZID, NID or SID, the MS sends an Origination Message to the target BS that includes the packet data service option and the DRS bit set to ‘0’. The Origination Message includes the previous PZID, NID and SID when any of these parameters change during the dormant handoff. The MS sends an Origination or Enhanced Origination message for each of its dormant PDSIs. Based on the IDs (PZID, NID and/or SID) in the Origination Message, the target PCF sends the PANID of the source PCF and the CANID of the target PCF to the serving PDSN. The serving PDSN uses this information to determine whether or not PPP re-negotiation is required over the main PDSI.
The BS does not establish a traffic channel when it receives an origination message with DRS set to ‘0’; a traffic channel may be established after the completion of setup of the A8 and A10 bearer connections if the PDSN has data for the MS. The following call flow shows the case where MS uses Origination Message to handoff a PDSI. Refer to section 3.17.4.13.2 for the case where MS uses Enhanced Origination to handoff a PDSI. Since
293 Section 3
3GPP2 A.S0013-D v2.0
the PDSN already has a PPP session for this MS, PPP negotiation is not required and the traffic channel is not needed in this scenario.
1
2
ADDS-TransferAck
time comment
a
b
c
d
e
f
g
h
Target PCF
ADDS-Transfer
Origination Message
A9-Setup-A8
A9-Release-A8 Complete
BS Ack Order
Packet Data Session Dormant, PPP connection is maintained
TA8-setup
T60
Release Order k
l
Packet Data Session Dormant, PPP connection is maintained
m
n
p
o Tregreq
A11-Registration Request
A11-RegistrationAcknowledge
A11-Registration Update
ADDS-TransferAck
i
j
Optional
A11-Registration Request
A11-RegistrationReply
A11-Registration Reply
Tregupd
MS Target BS MSC Source PCF PDSN
3
4
5
6
7
8
9
10
11
12
Figure 3.19.6.1-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by Same PDSN, Packet Data Session Dormant
a. It is assumed that the MS has established a PPP connection with the PDSN and performed a MIP registration (if required) but the packet data session is now dormant. The MS does not have an active voice call in progress.
b. The dormant MS detects a change of PZID, SID or NID and initiates an origination with the DRS bit set to ‘0’.
c. Target BS acknowledges the receipt of the Origination Message with a Base Station Ack Order to the MS.
Section 3 294
3GPP2 A.S0013-D v2.0
d. The target BS sends an ADDS Transfer message to the MSC with the Data Burst Type field of the ADDS User Part element set to Asynchronous Data Services, the authentication parameters received from the MS, and the BS computed authentication data element included in the message. The BS starts timer T60.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
e. The MSC optionally sends an ADDS Transfer Ack message indicating concurrent authentication and packet data setup to the target BS. This allows the BS to proceed with step ‘f’. If the MSC does not send this message, steps ‘f’ through ‘i’ occur after step ‘j’.
f. The target BS sends an A9-Setup-A8 message, with Data Ready Indicator set to ‘0’, to the target PCF and starts timer TA8-setup. The handoff indicator of the A9 Indicators IE shall be set to ‘0’.
g. The target PCF sends an A11-Registration Request message to the PDSN. The Registration Request message includes the Mobility Event Indicator within a CVSE and a non-zero Lifetime. This message also includes Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information (PANID/CANID). The PCF starts timer Tregreq.
h. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. If the PDSN supports fast handoff the Anchor P-P Address is included. If the PCF does not support fast handoff it ignores the Anchor P-P Address. If the PDSN has data to send, it includes the Data Available Indicator within a CVSE. The A10 connection binding information at the PDSN is updated to point to the target PCF. The PCF stops timer Tregreq.
i. The PCF responds to the BS with an A9-Release-A8 Complete message. The BS stops timer TA8-setup.
If the PDSN responds to the PCF with a Data Available Indicator in step ‘h’, the PCF responds to the BS with an A9-Connect-A8 message with Cause element set to ‘Data ready to send’. In this case, the BS establishes a traffic channel as described in Figure 3.19.6.2-1 steps ‘i’ through ‘p’ and the following two steps are skipped.
j The MSC sends an ADDS Transfer Ack message to the MS indicating successful authentication of the MS. The BS stops timer T60.
k. The target BS may send a Release Order to the MS. This allows the MS to send Origination Messages for remaining PDSIs sooner.
l. The PDSN initiates release of the A10 connection with the source PCF by sending an A11-Registration Update message. The PDSN starts timer Tregupd.
m. The source PCF responds with an A11-Registration Acknowledge message. The PDSN stops timer Tregupd.
n. The source PCF sends an A11-Registration Request message with Lifetime set to zero, to the PDSN. The PCF starts timer Tregreq.
o. The PDSN sends the A11-Registration Reply message with an accept indication to the source PCF. The source PCF releases the A10 connection for the MS. The PCF stops timer Tregreq. If the MS sends an Origination Message with DRS = 0 for additional dormant service instances (this may occur any time after step ‘k’ or when timer T42m expires for the last dormant service instance handed off), this procedure is repeated for each such service instance.
p. The packet data session remains dormant.
295 Section 3
3GPP2 A.S0013-D v2.0
3.19.6.2 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a Different PDSN
1
2
3
4
5
This section provides call flows for the case where an MS with a packet data session in Dormant State moves into a different packet zone and ends up being connected to a different PDSN.
Section 3 296
3GPP2 A.S0013-D v2.0
Origination
BS ACK Order
CM Service Request
A9-Setup-A8
Assignment Request
A9-Connect-A8
Assignment Complete
a
b
h
i
e
f
g
k
T303
T10
TA8-setup
A9-Update-A8
A9-Update-A8 Ack
Tupd9
l
m
TCH Establishment
procedure
time
n
o
q
ADDS Transfer
ADDS Transfer Ack
c
d T60
Tregreq
A11-RegistrationRequest
A11-RegistrationReply
Tregreq
A11-RegistrationRequest
A11-RegistrationReply
r
s
Tregreq
A11-Registration Update
A11-Registration Acknowledge
t
u
Tregreq
A11-Registration Request
A11-Registration Reply
j
p
MS Target
BS MSC
Target PCF
Target PDSN
Source PCF
Source PDSN
Establishing PPP connection
1
2
3
4
5
6
7
Figure 3.19.6.2-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - Mobile Served by a Different PDSN
a. The MS with a dormant packet data session detects a change of PZID, SID or NID and initiates an origination with the DRS bit set to ‘0’.
b. The target BS acknowledges the receipt of the Origination Message with a Base Station Acknowledgment Order to the MS.
297 Section 3
3GPP2 A.S0013-D v2.0
c. The target BS sends an ADDS Transfer message to the MSC with the Data Burst Type field of the ADDS User Part element set to ‘Asynchronous Data Services’, the authentication parameters received from the MS, and the target BS computed authentication data element included in the message. The target BS starts timer T60.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
d. The MSC sends an ADDS Transfer Ack message indicating successful authentication of the MS to the target BS. The target BS stops timer T60. Alternately, the MSC sends an ADDS Transfer Ack message indicating concurrent authentication of the MS to the target BS. In this case the target BS does not stop timer T60.
e. The target BS transmits an A9-Setup-A8 message to the target PCF, with DRS=‘0’, to establish an A8 connection and starts timer TA8-setup. The Handoff Indicator of the A9 Indicators IE shall be set to ‘0’.
f. The target PCF initiates establishment of the A10 connection by sending an A11-Registration Request message with non-zero Lifetime value to the target PDSN. The message includes the Mobility Event Indicator within a CVSE and a non-zero Lifetime. This message also includes Accounting Data (A10 Connection Setup Airlink Record) as well as ANID information (CANID/PANID). The target PCF starts timer Tregreq.
g. The A11-Registration Request message is validated and the target PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication and Data Available Indicator within a CVSE. If the target PDSN supports fast handoff the Anchor P-P Address is included. If the target PCF does not support fast handoff it ignores the Anchor P-P Address. The target PCF stops timer Tregreq.
h. Upon establishment of the A10 connection, the target PCF establishes an A8 connection and transmits an A9-Connect-A8 message with Cause set to ‘Data ready to send’. If fast handoff is supported, the target PCF passes the Anchor P-P Address and the Target PDSN IP Address to the target BS as part of this message. Upon reception of the A9-Connect-A8 message, the target BS stops the timer TA8-setup.
i. The target BS constructs the CM Service Request message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303. The message includes the Authentication Event information element indicating that authentication was recently requested. The target BS stops the timer T60 if it is still running.
j. The MSC sends an Assignment Request message to the target BS to request assignment of radio resources and starts timer T10. The target BS stops timer T303.
k. The target BS initiates the establishment of a radio traffic channel.
l. After the radio link is established, the target BS sends an Assignment Complete message to the MSC. The MSC stops timer T10.
m. The target BS sends an A9-Update-A8 message to the target PCF to pass Accounting Parameters. The target BS starts timer Tupd9.
n. The target PCF sends an A11-Registration Request message containing an Airlink Start accounting record. The target PCF starts timer Tregreq.
o. The target PDSN updates the accounting data and returns an A11-Registration Reply message with an accept indication back to the PCF. The target PCF stops timer Tregreq.
Section 3 298
3GPP2 A.S0013-D v2.0
p. The target PCF, upon receipt of the A9-Update-A8 message, responds with an A9-Update-A8 Ack message. Upon receipt of this message, the target BS stops timer Tupd9.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
q. PPP connection establishment procedure and Mobile IP Registration (if required) on the PPP connection (over main PDSI) are performed between the MS and PDSN. Refer to section 3.17.4.13.2 for the handoff of the additional PDSIs.
r. On expiration of the PPP timer or other events internal to the source PDSN, the source PDSN initiates release of the A10 connection with the source PCF by sending a Registration Update message. The PDSN starts timer Tregupd.
s. The source PCF responds with an A11-Registration Acknowledge message. The source PDSN stops timer Tregupd.
t. The source PCF sends an A11-Registration Request message with Lifetime set to zero. The source PCF starts timer Tregreq.
u. The source PDSN stores the accounting related information for further processing before returning A11-Registration Reply message with an accept indication. The source PCF releases the A10 connection for the MS. The source PCF stops timer Tregreq.
3.19.6.3 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) - with Concurrent Authentication Mobile Served by Same PDSN, Failed Authentication in MSC Following session establishment (PDSN Does Not Have Data to Send) 20
21
22
23
24
25
26
27
28
29
30
This scenario is similar to the one in section 3.17.4.16, except that the Alternate Dormant Handoff feature is used. The MSC sends the ADDS Transfer Ack message indicating concurrent authentication of the MS to the BS. If authentication of the MS later fails, the MSC sends a second ADDS Transfer Ack message to the BS with the “Authentication failure” cause value and the same TAG value as was received in the ADDS Transfer message from the BS. The BS then uses the A9-Update-A8 message to alert the PCF that it should tear down the A10 connection for that MS. Note: Authentication of the MS shall also be considered to have failed if timer T60 expires prior to reception of the authentication results in the second ADDS Transfer Ack message from the MSC after a configurable number of retries.
299 Section 3
3GPP2 A.S0013-D v2.0
MSC SourcePCF time
a
PDSN Target PCF MS
Packet Data Session Dormant, PPP connection is maintained
Target BS
Release Order
d ADDS Transfer Ack
T60
e
i Packet Data Session Null/Inactive
MS authentication failure c
A9-Update-A8
A9-Update-A8 Ack
Tupd9
A10 Release Procedures
f
g
h
Intra-PDSN Dormant Handoff Procedures b
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.19.6.3-1 Alternate Dormant Handoff of a PDSI (Inter-BS/Inter-PCF) with Concurrent Authentication - Mobile Served by Same PDSN, Failed Authentication in MSC
Following Session Establishment (PDSN Does Not Have Data to Send)
a. It is assumed that the MS has performed a MIP registration (if required) and established a PPP connection with the PDSN but is now dormant.
b. The MS with a dormant packet data session detects a change of PZID, SID or NID and initiates a dormant handoff, which results in the MS being served by the same PDSN. Refer to Figure 3.19.6.1-1, steps ‘b’ through ‘i’. During this step, the MSC requests the BS to proceed with the handoff before it has authenticated the MS. Timer T60 is still running.
c. The MSC receives authentication results from the authentication center indicating that authentication has failed.
d. The MSC sends the ADDS Transfer Ack message to the BS indicating that authentication has failed. The BS stops timer T60.
e. The target BS sends a Release Order to the MS indicating “Service Option Rejected”.
f. The target BS informs the target PCF via an A9-Update-A8 message containing an update reason parameter indicating “Authentication failed”. The target BS starts timer Tupd9. The BS uses the SR_ID of any of the dormant service instances in the A9-Update-A8 message.
Section 3 300
3GPP2 A.S0013-D v2.0
g. The target PCF initiates release of all A10 connections associated with the MS by sending an A11-Registration Request message with Lifetime value is set to ‘0’ to the PDSN for each PDSI.
1
2
3
4
5
6
h. At response from the PDSN, the target PCF sends an A9-Update-A8 Ack message back to the BS. The target BS stops timer Tupd9.
i. The packet data session is in the Null/Inactive State.
3.20 Security Features 7
8 This chapter discusses security features supported by the IOS.
3.20.1 Authentication and Privacy 9
10
11
12
13
14
The following table indicates the requirements for Authentication and Privacy while the MS is idle, during registration, during origination, during termination, and during a call. The table further illustrates whether the authentication is required for the Paging/Access Channel and/or the traffic channel.
Table 3.20.1-1 Authentication and Voice Privacy Requirements
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
301 Section 3
3GPP2 A.S0013-D v2.0
Table 3.20.1-1 (Cont.) Authentication and Voice Privacy Requirements 1
STATE On PAGING/ACCESS On TRAFFIC
During ORIGINATION
Global Challenge Required N/A
Unique Challenge N/A (Refer to: During Call)
SSD Update N/A (Refer to: During Call)
Parameter Update (Count) N/A (Refer to: 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 (Refer to: During Call)
SSD Update N/A (Refer to: During Call)
Parameter Update (Count) N/A (Refer to: 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
The assumptions in this specification are: 2
3
4
5
6
7
8
9
the BS shall be able to generate the RAND parameter
the MSC shall support BS generated RAND authentication
The SSD update procedure involves the exchange of the following messages:
SSD Update Request
Base Station Challenge
Base Station Challenge Response
SSD Update Response
3.20.1.1 SSD Update Procedure - Successful Case 10
11
12
The call flow in Figure 3.20.1.1-1 provides an illustration of a Shared Secret Data (SSD) Update procedure.
Section 3 302
3GPP2 A.S0013-D v2.0
MS BS MSC time
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Figure 3.20.1.1-1 SSD Update - Successful Case
a. The MSC sends an SSD Update Request message to the BS to indicate that the Shared Secret Data at the MS needs updating. The update information is in the form of a random number (RANDSSD) that is used by the MS to calculate the new SSD. The MSC starts timer T3270.
b. Based on the SSD Update Request message from the MSC, the BS sends the SSD Update message to indicate to the MS that it should update its SSD.
c. Upon receipt of the SSD Update message from the BS, the MS uses the RANDSSD as input to the algorithm to generate the new SSD. The MS then selects a 32 bit random number (RANDBS) and sends it to the BS in a Base Station Challenge Order message.
d. The BS forwards the Base Station Challenge message to the MSC to verify the new SSD calculated at the MS is the same as the SSD calculated by the network. The MSC stops timer T3270.
e. Upon reception of the Base Station Challenge message, the MSC uses the new SSD as input to the algorithm to generate the authentication response signature (AUTHBS). The MSC then sends the authentication response signature (AUTHBS) to the BS in the Base Station Challenge Response message. The MSC starts timer T3271.
f. Upon receipt of the Base Station Challenge Response message from the MSC, the BS transmits this information in a Base Station Challenge Confirmation Order message to the MS.
g. If the AUTHBS from the MSC is valid, the MS returns an SSD Update Confirmation Order message to the BS.
If the AUTHBS from the MSC is invalid, the MS returns an SSD Update Rejection Order message to the BS.
303 Section 3
3GPP2 A.S0013-D v2.0
h. The BS forwards the information in the SSD Update Response message to the MSC. The MSC stops timer T3271.
1
2
3.20.1.2 2G Terminal Authentication 3
4
5
This procedure is performed when the MSC wants to initiate an authentication check (a unique challenge) on a specified MS.
MS BS MSC time
Authentication Challenge Response
Authentication Challenge
a
b
c
d Authentication Response
T3260
Authentication Request
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.20.1.2-1 Terminal Authentication
a. The MSC sends the Authentication Request to the BS and starts timer T3260.
b. The BS forwards the information (RANDU) to the MS in an Authentication Challenge Message over the air interface.
c. The MS computes the result AUTHU based on the specified RANDU and the MS’s SSD. It then returns an Authentication Challenge Response Message to the BS with the enclosed AUTHU.
d. The BS forwards the AUTHU information to the MSC using the Authentication Response message.
Upon receipt of the Authentication Response message from the BS the MSC stops timer T3260.
3.20.1.3 Parameter Update 18
19
20
This procedure is performed when the MSC is instructed to update the call history count (COUNT) at the MS.
Section 3 304
3GPP2 A.S0013-D v2.0
T3220 a
b
c
d
MS BS MSC
Parameter Update Request
Parameter Update Order
Parameter Update Confirmation Order
Parameter Update Confirm
time
1
2
3
4
5
6
7
8
9
10
Figure 3.20.1.3-1 Parameter Update
a. The MSC sends the Parameter Update Request message to request that the MS update its call history count. The MSC starts timer T3220.
b. The BS sends a Parameter Update Order to the MS.
c. The MS increments its call history count and returns a Parameter Update Confirmation Order to acknowledge that the update was successful.
d. The BS sends the Parameter Update Confirm message to the MSC indicating that the MS incremented its call history count. Upon receipt of this message the MSC updates the call history count and stops timer T3220.
3.20.1.4 Privacy Mode Procedure 11
12
13
14
15
16
This section describes the call flow associated with voice privacy activation.
If broadcast challenge is not active in the system, then voice privacy cannot be invoked.
The privacy mode procedure should be completed either before handoff is initiated or after a handoff operation is complete.
Voice Privacy is shown here being invoked during an established call.
MS BS MSC time
d Privacy Mode Complete
a Privacy Mode Command
Mobile Order
Mobile Response
b
c
T3280
17
18 Figure 3.20.1.4-1 Privacy Mode Procedure
305 Section 3
3GPP2 A.S0013-D v2.0
a. The MSC at any point during the call following the receipt of the Assignment Complete message may send the Privacy Mode Command message to the BS to specify that privacy is to be provided for traffic information. The MSC starts timer T3280.
1
2
3
4
5
6
7
8
9
10
11
b. After the radio traffic channel has been acquired, voice privacy can be established when the BS transmits a voice privacy request order to the MS.
c. The MS performs the required privacy mode procedures and acknowledges the BS with a voice privacy response order.
d. The BS returns the Privacy Mode Complete message to the MSC to indicate successful receipt of the Privacy Mode Command message. The MSC stops timer T3280 upon receipt of the Privacy Mode Complete message.
3.20.1.5 BS Initiated Terminal Authentication 12
13
MS BS MSC time comment
a
b
c
BS Authentication Request
T3273
BS Authentication Request Ack
Terminal Authentication (section 3.20.1.2)
14
15
16
17
18
19
20
21
Figure 3.20.1.5-1 BS Initiated Terminal Authentication
a. The BS sends the BS Authentication Request to the MSC and starts timer T3273.
b. The MSC may send the BS Authentication Request Ack message to the BS. Upon receipt of the BS Authentication Request Ack message from the MSC, the BS stops timer T3273.
c. Upon receipt of the BS Authentication Request message, the MSC also performs the Terminal Authentication Procedure in section 3.20.1.2.
3.20.1.6 3G Authentication and Message Integrity 22
23
24
25
These procedures are performed when the MSC chooses to perform authentication and message integrity. In these scenarios, it is assumed that the P_REV_IN_USE is greater or equal to 10 and the MSC and BS support AKA.
3.20.1.6.1 3G Authentication 26
27 The MSC may perform this procedure to initiate 3G authentication.
Section 3 306
3GPP2 A.S0013-D v2.0
MS BS MSC time comment
a
b
Authentication Request
T3260
Authentication Response c
AKA procdure - success
conditional
1
2
3
4
5
6
7
8
9
10
Figure 3.20.1.6.1-1 3G Authentication
a. The MSC sends an Authentication Request message to the BS with authentication information (RANDA and AUTN) and starts timer T3260.
b. The BS initiates mutual authentication with the MS as defined in [5]. The MS provides a successful authentication response.
Note: If the (MAC) BS validation fails, the MS does not respond and the call flow ends.
c. If the BS received an AKA response from the MS, the BS forwards the results to the MSC. The MSC stops timer T3260.
3.20.1.6.2 3G Authentication with Resync of Authentication Vector Information 11
12
13
The call flow in this section provides an illustration of a synch failure when an authentication request is sent to the BS.
MS BS MSC time comment
a
b
Authentication Request
T3260
Tar
Authentication Report
Authentication Report Response
Authentication Response
c
d
f
conditional
conditional
e AKA procdure - success
AKA procdure - failure
14
15
16
17
18
19
20
Figure 3.20.1.6.2-1 3G Authentication with Synch Failure
a. The MSC sends an Authentication Request message to the BS with authentication information (RANDA and AUTN) and starts timer T3260.
b. The BS initiates mutual authentication with the MS as defined in [5]. If the Authentication Vector (AV) sequence number is out of synch, the MS indicates a sync failure by sending an Authentication Resynchronization Message.
307 Section 3
3GPP2 A.S0013-D v2.0
Note: If the (MAC) BS validation fails, the MS does not respond and the call flow ends.
1
2
3
4
5
6
7
8
9
c. The BS forwards the indication of a sync failure (i.e. MAC_S and CON_MS_SQN (AUTS)) to the MSC in an Authentication Report message and starts timer Tar. Refer to [33] for MSC/HLR authentication and resynchronization.
d. The MSC provides new authentication vector information in the Authentication Report Response message. The BS stops timer Tar.
e. The MS provides a successful authentication response.
f. The BS forwards the results to the MSC. The MSC stops timer T3260.
3.20.1.6.3 Encryption and Message Integrity Info Update 10
11
12
The MSC may perform this procedure to update the encryption and/or message integrity information (e.g., keys or algorithms) at the BS.
MS BS MSC time comment
a
b
Security Mode Request
Tsm
Security Mode Response
c
Security Mode Command
Security Mode Completion Order
d
13
14
15
16
17
18
19
20
21
Figure 3.20.1.6.3-1 Encryption and Integrity Info Update
a. The MSC sends a Security Mode Request message to the BS with updated encryption and/or integrity information and starts timer Tsm.
b. The BS sends a Security Mode Command message to the MS to update encryption and/or integrity information and may also enable signaling encryption.
c. The MS respond with a Security Mode Completion Order.
d. The BS responds to the MSC with a Security Mode Response message. The MSC stops timer Tsm.
3.20.1.6.4 BS Initiated Encryption and Message Integrity Info Update 22
23
24
The BS may request that the MSC provide encryption and/or message integrity information for an MS that has performed and idle handoff to the BS.
Section 3 308
3GPP2 A.S0013-D v2.0
MS BS MSC time comment
a
b Security Mode Request
Tsm
Security Mode Response
c
f
BS Security Mode Request
Tbsm
Idle handoff
Security Mode Command
Security Mode Completion Order
d
e
optional
conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.20.1.6.4-1 BS Initiated Encryption and Integrity Info Update
a. The MS performs an idle handoff to the BS. This may be a Power Strength Measurement Message or other message terminating at the BS, for which the BS requires integrity information for the MS.
b. The BS sends a BS Security Mode Request message to the MSC to initiate receipt of encryption and/or message integrity information for the MS, and starts timer Tbsm.
c. The MSC sends a Security Mode Request message to the BS with encryption and/or integrity information and starts timer Tsm. The BS stops timer Tbsm.
d. If the MSC responds in the Security Mode Request message with an update to the encryption and/or integrity information provided by the MS, the BS sends a Security Mode Command message to the MS to update encryption and/or integrity information and may also enable signaling encryption.
e. The MS respond with a Security Mode Completion Order.
f. The BS responds to the MSC with a Security Mode Response message. The MSC stops timer Tsm.
3.20.1.6.5 Mobile Originated and Mobile Terminated Call Setup with Authentication and Message Integrity 18
19
20
21
22
This procedure may be performed when a mobile originated or mobile terminated call is initiated and the MSC chooses to perform authentication. This call flow starts with MSC sending an Assignment Request message in response to the mobile originated or mobile terminated call being requested by the BS.
309 Section 3
3GPP2 A.S0013-D v2.0
MS BS MSC time comment
a
b
c
d
e
Assignment Request
channel assignment
Tch Preamble
f
g
BS Ack Order
MS Ack Order
Service Connect Message
Assignment Complete
i
k
T10
Service Connect Completion
j
AKA procdure
h
Tar
Security Mode Command
Security Mode Completion Order
l
m
optional
conditional
conditional
conditional conditional
optional
Authentication Report Response
Authentication Report
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Figure 3.20.1.6.5-1 3G Authentication for Mobile Originated and Mobile Terminated Scenarios
a. The MSC sends an Assignment Request message to the BS, in response to a CM Service Request or Paging Response message, and starts timer T10. The MSC may include authentication and integrity information in the Assignment Request message.
b. The BS sends a channel assignment message20 to the MS to initiate establishment of a radio traffic channel, if the MS is not already on a traffic channel.
c. The MS begins sending the traffic channel preamble (TCH Preamble) over the designated reverse traffic channel.
d. Once the BS acquires the reverse traffic channel, it sends the Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
e. The MS acknowledges the reception of the BS Ack Order by transmitting the Mobile Station Acknowledgment Order.
f. When the Assignment Request message includes authentication vector information, the BS shall initiate mutual authentication with the MS as defined in [5]. Note that this step can occur any time after step ‘a’.
g. The BS forwards the results to the MSC in an Authentication Report message and starts timer Tar.
20 This may be a Channel Assignment Message or Extended Channel Assignment Message.
Section 3 310
3GPP2 A.S0013-D v2.0
h. The MSC responds with an Authentication Report Response message. The BS stops timer Tar.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
i. The BS may send a Security Mode Command message to the MS to enable signaling encryption. This step may occur any time after step ‘f’.
j. The MS respond with a Security Mode Completion Order.
k. The BS sends the Service Connect Message / Service Option Response Order to the MS specifying the service configuration for the call. The MS begins processing traffic in accordance with the specified service configuration.
l. On receipt of the Service Connect Message, the MS responds with a Service Connect Completion Message.
m. The BS sends an Assignment Complete message to the MSC. The MSC stops timer T10.
Normal mobile originated or mobile terminated call processing continues. Refer to sections 3.1.1 or 3.1.2 for specific details.
3.20.1.6.6 MSC Resynchronization of Authentication Vector Information 15
16
17
The call flow in this section provides an illustration of a synch failure when the authentication vector information is being sent to the MS.
Authentication Report Response
Authentication Report
MS BS MSC time
a
b
c
d
e
Tar
Registration, Origination or Paging procedure
AKA procdure - fail
AKA procdure - success
f Authentication Report
optional
conditional
Authentication Report Response Targ
conditional
conditional
conditional
conditional
18
19
20
21
22
23
24
Figure 3.20.1.6.6-1 Resync of Authentication Vector Information
a. The MS and the network perform registration, origination or paging procedures. The MSC includes the authentication information in the Location Updating Accept or Assignment Request message.
b. If the MS and AV sequence number is out of synch, the MS indicates a sync failure by sending an Authentication Resynchronization Message.
311 Section 3
3GPP2 A.S0013-D v2.0
Note: If the (MAC) BS validation fails, the MS does not respond and the call flow ends.
1
2
3
4
5
6
7
8
9
10
11
12
c. The BS forwards the indication of a sync failure (i.e. MAC_S and CON_MS_SQN (AUTS)) to the MSC in an Authentication Report message and starts timer Tar. Refer to [33] for MSC/HLR authentication and resynchronization.
d. The MSC provides new authentication vector information in the Authentication Report Response message. The BS stops timer Tar.
e. The MS provides a successful authentication response.
f. The BS forwards the results to the MSC in an Authentication Report message and starts timer Tar.
g. The MSC sends an Authentication Report Response message to the BS. The BS stops timer Tar.
3.21 Flex Rate 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
This section describes the procedures to support soft handoff when Flex Rate is in use.
For forward bursts, the assigned Flex Rate is transmitted to the target base stations by sending the FOR_SCH_NUM_BITS_IDX in the Forward Supplemental Channel Rate field of the Forward Burst Radio Info element in the A7-Burst Request and A7-Burst Commit messages. For reverse bursts, the assigned Flex Rate is transmitted to the target base stations by sending the REV_SCH_NUM_BITS_IDX in the Reverse Supplemental Channel Rate field of the Reverse Burst Radio Info element in the A7-Burst Request and A7-Burst Commit messages.
User data traffic frames sent on the A3 link use the Frame Content field to indicate either the data rate that the frame is to be transmitted at (Forward Link) or the data rate that the frame was received at (Reverse Link). For Flex Rate, the four least significant bits of this field are used to indicate either REV_SCH_NUM_BITS_IDX or FOR_SCH_NUM_BITS_IDX.
This feature utilizes the same call flows as soft/softer handoff using direct BS-to-BS signaling. Refer to section 3.19.3.2.
3.22 Status Inquiry 29
30 This section describes the call flow associated with Status Inquiry.
3.22.1 Status Inquiry Example 31
32 The following call flow provides an illustration of the status inquiry procedure.
Section 3 312
3GPP2 A.S0013-D v2.0
MS BS MSC time
a
c
Status Request
Status Response
Status Response Message
Status Request Message
b
d
T3272
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.22.1-1 Status Inquiry
a. The MSC sends a Status Request message to the BS to request certain MS capabilities and starts timer T3272. The type of capability information requested is included in the Information Record Requested element.
b. The BS forwards the request for information to the MS in one of the following CDMA air interface messages:
1. the Status Request Order on the traffic channel,
2. the Status Request Message on the traffic channel or the Paging Channel.
c. The MS returns the requested information to the BS in one of the following CDMA air interface messages:
1. the Status Message on the traffic channel,
2. the Status Response Message on the traffic channel or the Access Channel.
d. The BS returns the requested information in the MS Information Records element of the Status Response message. The MSC stops timer T3272.
3.23 3X Multi-Carrier Operation 18
19
20
This section describes how 3X Multi-Carrier operation can be implemented using existing messages and information elements.
3.23.1 Hard Handoff Support 21
22
23
24
25
26
27
28
The following messages are impacted:
Handoff Request: The IS-2000 Channel Identity 3X information element is sent in place of the IS-2000 Channel Identity information element.
Handoff Request Acknowledge: The IS-2000 Channel Identity 3X information element is sent in place of the IS-2000 Channel Identity information element.
Handoff Command: The IS-2000 Channel Identity 3X information element is sent in place of the IS-2000 Channel Identity information element.
313 Section 3
3GPP2 A.S0013-D v2.0
3.23.2 Soft Handoff Support 1
2
3
4
5
6
7
8
9
10
11
12
13
14
The following messages are impacted:
A7 Handoff Request: In the Physical Channel Info information element, the AFRCN field refers to the center 3X frequency. Indication of the use of 3X Multi-Carrier is contained in the IS-2000 Service Configuration Record.
A7 Burst Response: In the Forward Burst Radio Info information element, the SR3 Incl bit should be set to ‘1’, and the proper QOF Mask and Forward Code Channel information coded for all three carriers.
A7 Burst Commit: In the Forward Burst Radio Info information element, the SR3 Incl bit should be set to ‘1’, and the proper QOF Mask and Forward Code Channel information coded for all three carriers.
A3 Connect: In the A3 Connect Information information element, for each cell record, the SR3 Incl bit should be set to ‘1’ and the proper QOF Mask and Forward Code Channel information coded for all three carriers.
3.24 5 ms Messaging 15
16 This section outlines how 5 ms messaging is supported in the IOS.
3.24.1 Forward Link 17
18
19
20
21
22
23
24
25
26
When a 5 ms message is to be sent to an MS that is in soft handoff, the source BS includes the message in either an A3-FCH Forward Traffic Frame or an A3-DCCH Forward Traffic frame, depending on which physical channel the message is being sent. The Air Interval Content Mask field of the FCH/DCCH Forward Air Interval Control information element indicates in which 5 ms slot the message is to be sent. The source BS may send up to four 5 ms messages in one traffic frame. The source BS may also include a 20 ms data frame in the traffic frame. If this data frame is included, the 5 ms message(s) is (are) punctured into the correct 5 ms slot(s) during the 20 ms frame transmission.
3.24.2 Reverse Link 27
28
29
30
31
32
33
34
35
When a 5 ms message is received from an MS that is in soft handoff, the target BS includes the message in either an A3-FCH Reverse Traffic Frame or an A3-DCCH Reverse Traffic frame, depending on which physical channel the message was received. The Air Interval Content Mask field of the FCH/DCCH Reverse Air Interval Control information element indicates in which 5 ms slot the message was received. The target BS may receive up to four 5 ms messages in one traffic frame. The target BS shall also include a 20 ms data frame in the traffic frame, if this traffic was received in addition to the 5 ms message(s) during the 20 ms interval.
3.25 Enhanced Rate Adaptation Mode (ERAM) 36
37
38
This feature utilizes the same call flows as soft/softer handoff using direct BS-to-BS signaling. Refer to section 3.19.3.2.
Section 3 314
3GPP2 A.S0013-D v2.0
3.26 Code Combining Soft Handoff (CCSH) 1
2
3
This feature utilizes the same call flows as soft/softer handoff using direct BS-to-BS signaling. Refer to section 3.19.3.2.
3.27 Rescue Channel 4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
This section describes call flows for the Rescue Channel feature.
Upon reception of a pre-determined number of frames of insufficient quality (refer to [2]), an MS disables its transmitter. After a configurable period of time, the MS autonomously promotes one or more eligible rescue cells from its neighbor set to its active set, re-enables it transmitter, and starts sending reverse traffic frames and an Extended Pilot Strength Measurement Message (EPSMM) flagging the newly promoted pilot(s).
Upon recognition that the MS has stopped transmitting, the source BS selects a rescue cell candidate(s) based on the MS’s neighbor list, last reported EPSMM, and possibly other factors, and initiates soft handoff addition procedures to prepare the target rescue cell(s) to acquire the MS. This scenario assumes that at least one A3 connection has been provisioned between the source and target BSs for rescue channel use. The rescue A3 connection is activated when the A7-Handoff Request message is received at the target. The message indicates that a call rescue procedure is requested and that the target BS shall not transmit forward frames until the MS is acquired. The target BS indicates with the A7-Handoff Request Ack message if the rescue procedure can be supported. In this case, the target base station begins listening for the MS on the frequency indicated in the A7-Handoff Request message. When the MS re-enables its transmitter and sends an EPSMM, the source BS examines the EPSMM to determine if any of the rescue cell(s) it selected matches the cell(s) the MS autonomously promoted into the active set.
If the EPSMM indicates that none of the rescue cells selected by the source BS was autonomously promoted into the active set by the MS, the source BS adds a soft handoff leg(s) to the target BS for the cell that was promoted by the MS, and releases the handoff leg(s) for the previously added rescue cell(s). The target rescue cell is instructed to begin transmitting forward frames immediately since the MS is already listening for its transmission.
Once the MS is successfully recovered, the call shall be moved from the rescue channel on to a normal traffic channel on the rescue cell to make the rescue channel available for other rescue attempts. Soft handoff legs to any other potentially strong neighbors may also be added, while any weak cells may be removed. If, despite rescue attempts from the network, a call fails to be recovered, normal call failure processing shall occur. The following call flows describe these rescue channel procedures.
3.27.1 Rescue Channel – Network and MS Select the Same Rescue Cell(s) 38
39
40
41
In this call flow, the source BS correctly selected at least one rescue cell autonomously promoted to the active set by the MS. Note: forward/reverse frames between the source and target BS in the call flow represent A3-IS-2000 FCH Forward/Reverse messages.
315 Section 3
3GPP2 A.S0013-D v2.0
M S Target BS
tim e com m ent
b
c
a
d
Source BS
Active Voice Call
ENLUM M essage
Reverse Traffic Fram es/EPSM M
e
f
g
h
i
j
k
Forward Traffic Fram es
A7 Handoff Request
A7 Handoff Request Ack
Handoff Direction M sg
A7-Drop Target Ack
Reverse Traffic Fram es/EPSM M
A3-IS-2000 FCH Forward (Handoff Direction)
M S Ack Order
Handoff Com pletion M sg
BS Ack Order
M SC
Reverse Fram es
Handoff Perform ed
Forward Traffic Fram es
l
m
n
o
p
q
r
s
Soft/Softer Handoff Addition Procedure
Reverse Traffic Fram es
A7-Drop Target
M S stopsTransm it-
ting
Tdrptgt
A7-Drop Target Ack
A7-Drop Target
Tdrptgt
t
u
Thoreq
1
2
3
4
5
6
7
8
9
10
Figure 3.27.1-1 Rescue Channel – Network and MS Select the Same Rescue Cell(s)
a. The MS is engaged in an active voice call with the network.
b. The source BS sends an Extended Neighbor List Update Message (ENLUM) to the MS, which includes the rescue channel parameters. Note: if the MS has not yet received an ENLUM, the MS uses the rescue channel parameters received in the Universal Neighbor List Message (UNLM), General Neighbor List Message (GNLM), or Extended Neighbor List Message (ENLM).
c. The MS receives a predetermined number of frames of insufficient signal quality and disables its transmitter.
Section 3 316
3GPP2 A.S0013-D v2.0
d. The source BS detects a loss of transmission from the MS. The source BS selects one or more rescue cell candidates for the MS based on the MS’s neighbor list, current active set, and possibly other factors. The source BS sends an A7-Handoff Request message to the target BS indicating that a rescue cell is required. The message includes the cell ID(s) of one or more rescue cell candidates selected by the source BS and the Rescue Request Info IE. The transmit flag in the element is set to ‘0’ instructing the target BS not to transmit forward frames until the MS is acquired. The source BS starts timer Thoreq.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
e. The source BS begins sending forward traffic frames to the target BS to synchronize the A3 rescue link.
f. The target BS begins sending reverse idle frames to the source BS as soon as the first forward frame is received to synchronize the A3 rescue link. The target BS sends reverse traffic frames if it has already acquired the MS.
g. The target BS sends an A7-Handoff Request Ack message to the source BS to acknowledge if a rescue procedure can be supported. If the target BS can support the rescue procedure, it attempts to acquire the MS on the selected rescue cell(s).The source BS stops timer Thoreq.
h. After a configurable period of time (as specified in the ENLUM/UNLM/GNLM/ENLM), the MS re-enables its transmitter. The target BS begins receiving reverse frames from the MS.
i. The target BS starts transmitting forward traffic frames to the MS over the rescue channel(s) as soon as the MS is acquired.
j. The target BS sends reverse traffic frames and EPSMMs to the source BS. The EPSMMs indicates that at least one rescue cell selected by the source BS was autonomously promoted by the MS to the active set.
k. For any rescue cells that were both successfully selected by the source BS and autonomously promoted into the active set by the MS, the source BS performs soft/softer handoff addition procedure(s) to add a normal traffic channel onto each of those rescue cells (rescue A3 connections and rescue channels remain active); refer to section 3.19.3.2.1-1 steps ‘a’ through ‘h’. For any cell(s) that the MS autonomously promoted into the active set that the source BS did not select, the source BS performs soft handoff addition procedures using normal traffic channels in order sync up with the current active set.
l. For any rescue cell(s) selected by the source BS that was not autonomously promoted into the active set by the MS, the source BS sends an A7-Drop Target message to the target BS to indicate that the rescue channel is no longer needed. The target BS deactivates the A3 rescue channel, but the A3 traffic connection remains connected for future rescue attempts. The source BS starts timer Tdrptgt.
m. The target BS sends an A7-Drop Target Ack message to the source BS to acknowledge release of the specified cell. The source BS stops timer Tdrptgt.
n. The source BS sends a handoff direction message in the A3-IS-2000 FCH Forward message to the target BS.
o. The target BS sends the handoff direction message to the MS to sync up the active sets and move the MS off the rescue channel.
p. The MS acknowledges receipt of the message with an MS Ack Order.
q. The MS indicates successful results of processing the handoff direction message by responding with a Handoff Completion message.
r. The target BS responds with a BS Ack Order.
317 Section 3
3GPP2 A.S0013-D v2.0
s. The source BS may send a Handoff Performed message to the MSC (refer to section 3.19.1.1.3). The Handoff Performed message may be sent at any time after the Handoff Completion message is received at the BS.
1
2
3
4
5
6
7
8
9
10
t. The source BS sends an A7-Drop Target message to the target BS(s) to request release of the rescue channel(s) used to recover the call. The source BS starts timer Tdrptgt. Note: Rescue A3 traffic connections remain connected for future rescue attempts.
u. The target BS sends an A7-Drop Target Ack message to the source BS to acknowledge release of the specified channel(s). The source BS stops timer Tdrptgt.
3.27.2 Rescue Channel – Network and MS Selected Different Rescue Cell(s) 11
12
13
14
15
16
17
18
19
20
The MS has disabled its transmitter due to poor quality of forward frames received from the network. The network detects a loss of transmission from the MS, which triggers selection and setup of rescue cell candidates. The MS autonomously promotes one or more rescue cells to its active set, re-enables its transmitter, and starts sending reverse traffic frames and an EPSMM reflecting the newly promoted pilots. The EPSMM indicates that none of the rescue cells selected by the source BS match those autonomously promoted to the active set by the MS. The MS selected a rescue cell(s) from the target BS2. Note: forward/reverse frames between the source and target BS in the calls flow represent the A3-IS-2000 FCH Forward/Reverse messages.
Section 3 318
3GPP2 A.S0013-D v2.0
M S T-BS1 tim e com m ent
b
c
a
d
S-BS
Rescue Channel Setup
Reverse Traffic Fram es/EPSM M
e
f
g
h
i
j
k
Reverse Traffic Fram es
M SC
Forward Traffic Fram es
l
m
n
Rescue Channel Release
Reverse Traffic Fram es
Forward Traffic Fram es
A7 Handoff Request
A7 Handoff Request Ack
Reverse Fram es
T-BS2
A7-Drop Target
A7-Drop Target Ack
Reverse Traffic Fram es/EPSM M
A3-Traffic Channel Status
M S stopsTransm itting
o
Forward Traffic Fram es
Tdrptgt
Thoreq
X
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.27.2-1 Rescue Channel – Network and MS Selected Different Rescue Cells
a. The MS receives a predetermined number of frames of insufficient signal quality and disables its transmitter.
b. The source BS initiates a rescue channel procedure with the target BS1 as described in section 3.27.1, steps ‘d’ through ‘g’. The target BS1 is listening for the MS, but the MS has not resumed transmission at this point.
c. After a configurable period of time (as specified in the ENLUM/UNLM/GNLM/ENLM), the MS re-enables its transmitter. The source BS and/or target BS1 begin receiving reverse frames from the MS.
d. The target BS1 starts transmitting forward traffic frames to the MS over the rescue channel(s) as soon as the MS is acquired.
e. The target BS1 sends reverse traffic frames and EPSMMs to the source BS. The EPSMMs indicate that no rescue cell(s) selected by the source BS matched a cell(s) autonomously promoted to the active set by the MS. The MS promoted a rescue cell(s) from the target BS2.
f. The source BS sends an A7-Handoff Request messages to the target BS2, indicating that a rescue cell is required and starts timer Thoreq. The message includes the cell ID of one more rescue cell autonomously promoted to the active set by the MS as reported in the EPSMM message. The message also includes the Rescue Request Info IE with the transmit flag set to ‘1’ instructing the target BS2 to begin
319 Section 3
3GPP2 A.S0013-D v2.0
transmitting forward frames to the MS on the rescue channel(s) as soon as synchronization with the source BS is achieved.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
g. The source BS begins sending forward traffic frames to the target BS2 to synchronize the A3 rescue link.
h. The target BS2 begins sending reverse idle frames to the source BS as soon as the first forward frame is received to synchronize the A3 rescue link. Reverse traffic frames are sent if the target BS2 has acquired the MS.
i. The target BS2 sends an A7-Handoff Request Ack message to the source BS to acknowledge if the rescue procedure can be supported. If the target BS2 can support the rescue procedure, it attempts to acquire the MS on the rescue cell(s). The source BS stops timer Thoreq.
j. The target BS2 begins transmitting forward frames to the MS as soon as synchronization with the source BS has occurred.
k. If the source BS has chosen to be notified of the start of transmission and reception at the target BS2 when its SDU function and the target BS2 have synchronized the A3 rescue link, the target BS2 replies with an A3-Traffic Channel Status message. Note: this step may occur any time after step ‘f’.
l. After acquiring the MS, the target BS2 begins to send reverse traffic frames to the source BS.
m. The source BS sends an A7-Drop Target message to the target BS1 to request release of any rescue cell(s) previously added in step ‘b’ that was not autonomously promoted by the MS. Rescue A3 traffic connection is deactivated but remains connected. The source BS starts timer Tdrptgt. Note: this step may occur anytime after step ‘e’.
n. The target BS1 sends an A7-Drop Target Ack message to the source BS to acknowledge release of the specified cell(s). The source BS stops timer Tdrptgt. Note: Rescue A3 traffic connections remain connected for future rescue attempts.
o. Rescue channel cleanup procedure occurs – the source BS attempts to sync up the active sets, moves the MS off the rescue channel, and sends a handoff direction message to the MS. Refer to section 3.27.1 steps ‘k’ through ‘u’ for the remainder of the call flow.
3.28 Terrestrial Resource Management 32
33
34
35
36
37
The following sections describe those procedures involved with the management of terrestrial resources on the A2, A2p, A5, and A3 interfaces.
The A2 interface utilizes circuit resources which are controlled by a circuit-switched MSC. The A2p interface utilizes packet resources, which are controlled separately by both the MSCe and the BS.
3.28.1 Terrestrial Resource Management for the A2/A2p/A5 Interfaces 38
39
40
41
42
This section describes terrestrial resource management for the A2, A2p, and A5 interfaces. Section 3.28.1.1 describes terrestrial circuit allocation and deallocation. Section 3.28.1.2 describes blocking and unblocking of terrestrial circuits. Section 3.28.1.3 describes resetting of circuits. Section 3.28.1.4 describes global system reset.
Section 3 320
3GPP2 A.S0013-D v2.0
3.28.1.1 A2/A5 Terrestrial Circuit Allocation 1
2
3
4
The circuit-switched MSC chooses the terrestrial circuit to be used as specified in 1.4.1.1.
The Terrestrial Circuit allocation procedure is described in [14].
NOTE: There is at least one single logical trunk group serving the BS.
3.28.1.2 A2/A5 Terrestrial Circuit Blocking/Unblocking 5
6
7
8
9
10
11
12
13
14
The circuit-switched MSC needs to be informed of any A2/A5 terrestrial circuits that are out of service or that return to service at the BS. The Block or Unblock message is sent by the BS as a connectionless mode message for terrestrial circuits that are out of service or that return to service. Upon receiving a Block or Unblock message, the circuit-switched MSC marks or unmarks the identified circuits as blocked at the BS and acknowledges the action to the BS. The circuit-switched MSC may locally block a circuit by not choosing it. No information flow across the interface concerning this type of blocking is needed.
The following sections describe the operation of blocking and unblocking procedures.
3.28.1.2.1 Block Procedure Scenario Diagram 15
16 Figure 3.28.1.2.1-1 below shows the Block procedure.
time
a
b
BS
Circuit-Switched
MSC
Block Acknowledge
Block
T1
comment
17
18
19
20
21
22
23
Figure 3.28.1.2.1-1 Block Procedure
a. The BS sends the Block message to the circuit-switched MSC with information on the circuits to be blocked. The BS starts timer T1.
b. In response to the Block message, the circuit-switched MSC returns a Block Acknowledge message, indicating the involved circuit(s) has been marked as blocked. The BS stops timer T1.
3.28.1.2.2 Unblock Procedure Scenario Diagram 24
25 The diagram in Figure 3.28.1.2.2-1 shows the Unblock procedure.
321 Section 3
3GPP2 A.S0013-D v2.0
time
a
b
BS
Circuit- Switched
MSC
Unblock Acknowledge
Unblock
T1
comment
1
2
3
4
5
6
7
Figure 3.28.1.2.2-1 Unblock Procedure
a. The BS sends the Unblock message to the circuit-switched MSC in a request to unblock circuits. The BS starts timer T1.
b. The circuit-switched MSC removes any marks that indicated that the circuits were blocked at the BS and sends the Unblock Acknowledge message to the BS. The BS stops timer T1.
3.28.1.3 A2/A5 Reset Circuit Procedure 8
9
10
11
12
13
14
15
The reset circuit procedure is needed to initialize information in the circuit-switched MSC/BS when a failure has occurred affecting only a small part of the equipment and in which the SCCP connection has been released. If the circuit-switched MSC/BS detects that one or more circuits need to be reset due to abnormal SCCP connection release, a Reset Circuit message is sent. Upon receipt of the Reset Circuit message, the receiver resets the indicated circuits and returns an acknowledgment.
The following sections describe the operation of the reset circuit procedures.
3.28.1.3.1 Reset Procedure at the BS Scenario Diagram 16
17 The diagram in Figure 3.28.1.3.1-1 shows the Reset Circuit procedure.
time
a
b
BS
Circuit- Swtched
MSC
Reset Circuit Acknowledge
Reset Circuit
T12
comment
18
19
20
21
22
23
24
25
Figure 3.28.1.3.1-1 A1 Reset Circuit Procedure at the BS
a. Once the BS detects that one or more circuits need to be reset, it sends a Reset Circuit message to the circuit-switched MSC with information on the circuit identities and the cause of the reset. The BS starts timer T12 after sending the Reset Circuit message.
b. Upon receipt of the Reset Circuit message, the circuit-switched MSC resets the circuits, removes any marks that indicated that the circuits were blocked at the BS,
Section 3 322
3GPP2 A.S0013-D v2.0
and returns a Reset Circuit Acknowledge message to indicate that the circuits have been reset. The BS stops timer T12.
1
2
3.28.1.3.2 Reset Circuit Procedure at the Circuit-Switched MSC 3
4
5
The diagram in Figure 3.28.1.3.2-1 shows a simple reset circuit procedure initiated by the circuit-switched MSC.
time
a
b
BS
Circuit-Switched
MSC
Reset Circuit Acknowledge
Reset Circuit
T12
comment
6
7
8
9
10
11
12
13
14
Figure 3.28.1.3.2-1 Reset Circuit Procedure at the Circuit-Switched MSC
a. Once the circuit-switched MSC detects that one or more circuits need to be reset, it resets the circuits and sends a Reset Circuit message to the BS with information on the circuits and the cause of the reset. The circuit-switched MSC starts timer T12.
b. Upon receipt of the Reset Circuit message, the BS resets the circuits and returns a Reset Circuit Acknowledge message to indicate that the circuits have been reset. The circuit-switched MSC removes any marks that indicated that the circuits were blocked at the BS and stops timer T12.
3.28.1.3.3 Reset Circuit Procedure at the Circuit-Switched MSC with BS Block Response 15
16
17
The diagram in Figure 3.28.1.3.3-1 shows a reset circuits procedure initiated by the circuit-switched MSC that is responded to from the BS by a Block message.
time
a
b
BS
Circuit-Switched
MSC
Block
Reset Circuit
T12
comment
cBlock AcknowledgeT1
18
19
20
21
22
23
24
25
26
Figure 3.28.1.3.3-1 Reset Circuit Procedure at the Circuit-Switched MSC with BS Block Response
a. Once the circuit-switched MSC detects that one or more circuits need to be reset, it resets the circuits, and sends a Reset Circuit message to the BS with information on the circuit identities and the cause of the reset. The circuit-switched MSC starts timer T12.
b. If the BS cannot reset a circuit, it sends the Block message to the circuit-switched MSC with information on the blocked circuit identities and the cause of the blocking.
323 Section 3
3GPP2 A.S0013-D v2.0
The BS starts timer T1. The circuit-switched MSC stops timer T12 upon receipt of the Block message. The circuit-switched MSC marks the circuits identified in the Block message as blocked at the BS, and unmarks the remaining circuits identified in the Reset Circuit message.
1
2
3
4
5
6
7
c. In response to the Block message, the circuit-switched MSC returns a Block Acknowledge message, indicating the involved circuits that have been marked as blocked. The BS stops timer T1 upon receipt of this message.
3.28.1.4 A2/A2p/A5 Global System Reset 8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
The purpose of the global system reset procedure is to cause the initialization of the MSC or BS in the event of a global failure by its counterpart. Since this type of failure is global, the messages of the procedure are sent as connectionless messages on the A1 or A1p interface.
Global system reset applies to A2, A5, and A2p. In the context of A2 and A5, a global system reset causes the MSC to release all circuit resources. In the context of A2p, a global system reset causes the MSCe to release all of its packet resources, and causes the BS to release all of its packet resources.
Upon detection of a global failure or as a result of an initialization, the BS or MSC sends a Reset message to its counterpart. The counterpart then performs all necessary initialization functions such as: releasing of affected calls and references, idling and/or blocking of circuits if applicable, and ensuring as necessary that all MSs previously involved in a call are no longer transmitting. After a guard period sufficient to allow all necessary initialization to occur, the counterpart acknowledges the Reset message.
The following sections describe the call flows involved in the reset procedures. The message structures and the information elements in these messages are described in [14].
3.28.1.4.1 Successful Reset at the MSC 25
26 This example shows a successful reset procedure when the MSC (re-)initializes.
time
a
b
BS MSC
Reset Acknowledge
Reset
T16
comment
BS blocks circuits as necessary using the blocking procedure.
c
T13
x
27
28 Figure 3.28.1.4.1-1 Successful Reset at the MSC
Section 3 324
3GPP2 A.S0013-D v2.0
a. When the MSC (re-)initializes, it sends a Reset message to the BS to notify the BS of the reset procedure it is undertaking. The MSC starts timer T16. The BS starts timer T13.
1
2
3
4
5
6
7
8
9
b. If the BS is connected to a circuit-switched MSC, the BS may use the circuit blocking procedure to block circuits, as necessary, between itself and the circuit-switched MSC.
c. Upon expiration of timer T13, the BS returns a Reset Acknowledge message. The MSC stops timer T16. Both the MSC and BS begin normal operations relative to each other.
3.28.1.4.2 Successful Reset at the BS 10
11 This example shows a successful reset procedure when the BS (re-) initializes.
time
a
b
BS MSC
Reset Acknowledge
Reset
T2
comment
BS blocks circuits as necessary using the blocking procedure.
c
T4
x
12
13
14
15
16
17
18
19
20
21
22
Figure 3.28.1.4.2-1 Successful Reset at the BS
a. When the BS (re-) initializes, it sends a Reset message to the MSC to notify the MSC of the reset procedure it is undertaking. The MSC starts timer T2. The BS starts timer T4.
b. If the BS is connected to a circuit-switched MSC, the BS may use the circuit blocking procedure to block circuits, as necessary, between itself and the circuit-switched MSC.
c. Upon expiration of timer T2, the MSC returns a Reset Acknowledge message. The BS stops timer T4. Both the MSC and BS begin normal operations relative to each other.
3.28.1.4.3 Reset Glare Noted at the MSC 23
24
25
26
27
28
This example shows parallel reset procedures at the BS and MSC. In this case, the MSC notes that a timing condition has occurred since the Reset message from the BS arrives after the Reset message is sent from the MSC. The MSC shall assume that the Reset message it has sent has been lost. As a result the MSC cancels the reset procedure that it initiated and continues with the reset procedure initiated by the BS.
325 Section 3
3GPP2 A.S0013-D v2.0
time
b
c
BS MSC
Reset Acknowledge
Reset
T2
comment
BS blocks circuits as necessary using the blocking procedure.
d
T4
x
aReset
T16
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Figure 3.28.1.4.3-1 Reset Glare Noted at the MSC
a. When the MSC (re-) initializes, it sends a Reset message to the BS to notify the BS of the reset procedure it is undertaking. The MSC starts timer T16. In this example, the Reset message is lost or cannot be successfully processed by the BS.
b. When the BS (re-) initializes, it sends a Reset message to the MSC to notify the MSC of the reset procedure it is undertaking. The MSC stops timer T16 and starts timer T2. The BS starts timer T4.
c. If the BS is connected to a circuit-switched MSC, the BS may use the circuit blocking procedure to block circuits, as necessary, between itself and the circuit-switched MSC.
d. Upon expiration of timer T2, the MSC returns a Reset Acknowledge message. The BS stops timer T4. Both the MSC and BS begin normal operations relative to each other.
3.28.1.4.4 Reset Glare Noted at the BS 15
16
17
18
19
20
This example shows parallel reset procedures at the BS and MSC. In this case, the BS notes that a timing condition has occurred since the Reset message from the MSC arrives after the Reset message is sent from the BS. The BS shall assume that the Reset message it has sent has been lost. As a result the BS cancels the reset procedure that it initiated and continues with the reset procedure initiated by the MSC.
Section 3 326
3GPP2 A.S0013-D v2.0
time
b
c
BS MSC
Reset Acknowledge
Reset
T16
comment
BS blocks circuits as necessary using the blocking procedure.
d
T13
x
aReset
T4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Figure 3.28.1.4.4-1 Reset Glare Noted at the BS
a. When the BS (re-) initializes, it sends a Reset message to the MSC to notify the MSC of the reset procedure it is undertaking. The BS starts timer T4. In this example, the Reset message is lost or cannot be successfully processed by the MSC.
b. When the MSC (re-) initializes, it sends a Reset message to the BS to notify the BS of the reset procedure it is undertaking. The BS stops timer T4 and starts timer T16. The BS starts timer T13.
c. If the BS is connected to a circuit-switched MSC, the BS uses the circuit blocking procedure to block circuits, as necessary, between itself and the circuit-switched MSC.
d. Upon expiration of timer T13, the BS returns a Reset Acknowledge message. The MSC stops timer T16. Both the MSC and BS begin normal operations relative to each other.
3.28.1.4.5 Reset Glare Noted at Both the MSC and the BS 15
16
17
18
19
20
21
22
23
24
25
This example shows parallel reset procedures at the BS and MSC. In this case, the Reset messages pass each other en route and are both received. The BS notes that a timing condition has occurred since the Reset message from the MSC arrives after the Reset message is sent from the BS. The BS shall assume that the Reset message it has sent has been lost. As a result, the BS shall act as though it is not also performing a reset procedure. Similarly, the MSC notes that a timing condition has occurred since the Reset message from the BS arrives after the Reset message is sent from the MSC. The MSC shall assume that the Reset message it has sent has been lost. As a result the MSC cancels the reset procedure that it initiated and continues with the reset procedure initiated by the BS.
327 Section 3
3GPP2 A.S0013-D v2.0
time
b
c
BS MSC
Reset Acknowledge
Reset
T16
comment
BS blocks circuits as necessary using the blocking procedure.
d
T13
x
aReset
T4
T2
Reset Acknowledge x e
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.28.1.4.5-1 Reset Glare Noted at Both the MSC and the BS
a. When the BS (re-) initializes, it sends a Reset message to the MSC to notify the MSC of the reset procedure it is undertaking. The BS starts timer T4. In this example, the MSC also sends a Reset message due to (re-) initialization and starts timer T16.
b. When the BS receives the Reset message, it stops timer T4 and starts timer T13. When the MSC receives the Reset message, it stops timer T16 and starts timer T2.
c. If the BS is connected to a circuit-switched MSC, the BS uses the circuit blocking procedure to block circuits, as necessary, between itself and the circuit-switched MSC.
d. Upon expiration of timer T13, the BS returns a Reset Acknowledge message. The MSC discards the message as an unexpected message. The BS begins normal operations relative to the MSC.
e. Upon expiration of timer T2, the MSC returns a Reset Acknowledge message. The BS discards the message as an unexpected message. The MSC begins normal operations relative to the BS.
NOTE: Steps ‘d’ and ‘e’ could occur in the reverse order.
3.28.2 Terrestrial Circuit Management for the A3 Interface 18
19
20
This section contains examples of the A7-Reset procedure, including glare situations. Refer to section 2.28.2 for more information.
Section 3 328
3GPP2 A.S0013-D v2.0
3.28.2.1 Successful Reset at a BS 1
2 This example shows a successful A7-Reset procedure when a BS (re)-initializes.
time
a
b
Second BS
First BS
A7-Reset Acknowledge
A7-Reset
comment
x
T2 T4
3
4
5
6
7
8
9
10
Figure 3.28.2.1-1 Successful A7-Reset at a BS
a. When the first BS (re-) initializes, it sends an A7-Reset message to another (second) BS to notify the second BS of the reset procedure it is undertaking. The second BS starts timer T2. The first BS starts timer T4.
b. Upon expiration of timer T2, the second BS returns an A7-Reset Acknowledge message. The first BS stops timer T4. Both BSs begin normal operations relative to each other.
3.28.2.2 A7-Reset Glare Noted at the First BS 11
12
13
14
15
16
17
This example shows parallel reset procedures at two BSs. In this case, the first BS notes that a timing condition has occurred since the A7-Reset message from the other (second) BS arrives after the A7-Reset message is sent from the first BS. The first BS shall assume that the A7-Reset message it has sent has been lost. As a result the first BS cancels the reset procedure that it initiated and continues with the reset procedure initiated by the second BS.
329 Section 3
3GPP2 A.S0013-D v2.0
time
b
c
Second BS First BS
A7-Reset Acknowledge
A7-Reset
T2
comment
T4
x
aA7-Reset
T4
1
2
3
4
5
6
7
8
9
10
11
12
Figure 3.28.2.2-1 A7-Reset Glare Noted at the First BS
a. When a (first) BS (re-) initializes, it sends an A7-Reset message to another (second) BS to notify the second BS of the A7-Reset procedure it is undertaking. The first BS starts timer T4. In this example, the A7-Reset message is lost or cannot be successfully processed by the second BS, which is itself (re)-initializing.
b. When the second BS (re-) initializes, it sends an A7-Reset message to the first BS to notify the first BS of the A7-Reset procedure it is undertaking. The first BS stops timer T4 and starts timer T2. The second BS starts timer T4.
c. Upon expiration of timer T2, the first BS returns an A7-Reset Acknowledge message. The second BS stops timer T4. Both the first BS and second BS begin normal operations relative to each other.
3.28.2.3 A7-Reset Glare Noted at Both BSs 13
14
15
16
17
18
19
20
21
22
23
This example shows parallel A7 reset procedures at two BSs. In this case, the A7-Reset messages pass each other en route and are both received. The first BS notes that a timing condition has occurred since the A7-Reset message from the second BS arrives after the A7-Reset message is sent from the first BS. The first BS shall assume that the A7-Reset message it has sent has been lost. As a result, the first BS shall act as though it is not also performing a reset procedure. Similarly, the second BS notes that a timing condition has occurred since the A7-Reset message from the first BS arrives after the A7-Reset message is sent from the second BS. The second BS shall assume that the A7-Reset message it has sent has been lost. As a result the second BS cancels the reset procedure that it initiated and continues with the reset procedure initiated by the first BS.
Section 3 330
3GPP2 A.S0013-D v2.0
time
b
c
First BS
A7-Reset Acknowledge
A7-Reset
T4
comment
d
T2
x
aA7-Reset
T4
T2
A7-Reset Acknowledge x
Second BS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Figure 3.28.2.3-1 A7-Reset Glare Noted at Both BSs
a. When the first BS (re-) initializes, it sends an A7-Reset message to the second BS to notify the second BS of the reset procedure it is undertaking. The first BS starts timer T4. In this example, the second BS also sends an A7-Reset message due to (re-) initialization and starts timer T4.
b. When the first BS receives the A7-Reset message, it stops timer T4 and starts timer T2. When the second BS receives the A7-Reset message, it stops timer T4 and starts timer T2.
c. Upon expiration of timer T2, the first BS returns an A7-Reset Acknowledge message. The second BS discards the message as an unexpected message. The first BS begins normal operations relative to the second BS.
d. Upon expiration of timer T2, the second BS returns an A7-Reset Acknowledge message. The first BS discards the message as an unexpected message. The second BS begins normal operations relative to the first BS.
NOTE: Steps ‘c’ and ‘d’ could occur in the reverse order.
3.29 Vocoder Support 17
18
19
This section describes the IOS messaging required to support vocoder assignment by the BS. This section pre-supposes the assumptions listed in section 1.0 of this document.
3.29.1 Mobile Originated Calls 20
21
22
23
The following call flow demonstrates the general sequence for vocoder selection for a circuit switched mobile originated call. For originating TrFO/RTO calls refer to section 3.1.1.1.2 and 3.1.1.1.3.
331 Section 3
3GPP2 A.S0013-D v2.0
MS BS MSC time
Origination
CM Service Request
Assignment Request
Channel Assignment,Service Negotiation
Assignment Complete
a
b
c
d
e
T303
T10
fRingback Tone
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Figure 3.29.1-1 Vocoder Selection – Mobile Originated Case
a. The MS originates the call by sending an Origination Message to the BS. This message contains the voice service option that the MS prefers (13K, EVRC, SMV, EVRC-B, EVRC-WB, EVRC-NW or Wideband Speech Codec).
b. The BS sends a CM Service Request message to the MSC, containing the service option that was requested by the MS. The BS starts timer T303.
c. Upon receipt of the CM Service Request message, the MSC sends an Assignment Request message to the BS containing the same service option that was received in the CM Service Request message. The BS stops timer T303 upon receipt of this message. The MSC starts timer T10.
d. Upon receipt of the Assignment Request message, the BS assigns a traffic channel to the MS (if one has not yet been assigned). Once the traffic channel has been established, the BS and MS negotiate the service option for the voice service. Refer to “Circuit mode voice service assumptions”: in section 1.1.
e. The BS sends an Assignment Complete message to the MSC indicating the service option for the voice call. Upon receipt of the Assignment Complete message, the MSC stops timer T10.
f. As call progress tone is applied in-band in this case, ringback tone is available on the audio circuit path towards the MS.
Section 3 332
3GPP2 A.S0013-D v2.0
3.29.2 Mobile Terminated Calls 1
2
3
4
The following call flow demonstrates the general sequence for vocoder selection for a mobile terminated call. For terminating TrFO/RTO calls refer to sections 3.1.2.1.2 and 3.1.2.1.3.
MS BS MSC time
Page
Paging Response
Paging Request
Channel Assignment,Service Negotiation
Assignment Complete
a
b
c
d
e
Page Response
Assignment Request
f
g
MS Rings, User Answers
Connect
T3113
T303
T10
T301h
i
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Figure 3.29.2-1 Vocoder Selection – Mobile Terminated Case
a. The MSC initiates a mobile terminated call by sending a Paging Request message to the BS. This message contains either the 13K, EVRC, SMV, EVRC-B, EVRC-WB, EVRC-NW or Wideband Speech Codec voice service option. The MSC starts timer T3113.
b. The BS pages the MS with the same service option it received in the Paging Request message.
c. The MS responds with a Page Response message. This message contains the voice service option (either 13K, EVRC, SMV, EVRC-B, EVRC-WB, EVRC-NW or Wideband Speech Codec) that the MS prefers.
d. The BS sends a Paging Response message to the MSC. The BS starts timer T303.
e. Upon receipt of the Paging Response message the MSC stops timer T3113. The MSC sends an Assignment Request message to the BS, containing the same service option that was included in the Paging Response message. The MSC starts timer T10.
f. Upon receipt of the Assignment Request message, the BS stops timer T303 and assigns a traffic channel to the MS (if one has not yet been assigned). Once the
333 Section 3
3GPP2 A.S0013-D v2.0
traffic channel has been established, the BS and MS negotiate the service option for the voice service. Refer to “Circuit mode voice service assumptions”: in section 1.1.
1
2
3
4
5
6
7
8
g. The BS sends an Assignment Complete message to the MSC indicating the service option for the voice call. Upon receipt of the Assignment Complete message, the MSC stops timer T10 and starts timer T301.
h. The BS alerts the MS to ring.
i. When the user answers the MS, the BS sends a Connect message to the MSC. The MSC stops timer T301.
3.29.3 Service Option Change During Handoff 9
10
11
12
This section describes the scenario for changing vocoder types during a hard handoff. It is assumed that the target BS does not support the vocoder type that the MS is currently using. For the hard handoff of TrFO/RTO calls, refer to section 3.19.3.1.2.
MS Source
BS MSC
Handoff RequiredHandoff Request
Handoff Command
Handoff Direction Message
MS Ack Order
Target BS
Null forward traffic channel framesHandoff 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 CompleteT306
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
13
14
15
16
17
18
19
20
21
22
Figure 3.29.3-1 Vocoder Selection – Handoff Case
a. Based on an MS report that it crossed a network specified threshold for signal strength or for other reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS sends a Handoff Required message with the list of cells to the MSC and starts timer T7. The message contains the service option for one of the vocoder types supported by the target BS.
b. The MSC sends a Handoff Request message to the target BS with the IS-95 Channel Identity element or the IS-2000 Channel Identity element present, based on if the MSC proceeds with a CDMA-CDMA handoff attempt and the corresponding IS-
Section 3 334
3GPP2 A.S0013-D v2.0
2000 or IS-95 Channel Identity element was present in the Handoff Required message The MSC starts timer T11.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
c. Upon receipt of the Handoff Request message from the MSC, the target BS allocates appropriate radio resources as specified in the message and connects the call. As the Handoff Request message can have multiple cell(s) specified, the target BS can also choose to set up multiple cell(s) for the handoff request. The target BS sends null forward traffic channel frames to the MS.
d. The target BS sends a Handoff Request Acknowledge message to the MSC. The target BS starts timer T9 to wait for arrival of the MS on its radio channel. The first cell in the cell identifier list element of the message is treated as the new designated cell by the MSC. The change of designated cell occurs upon receipt of the Handoff Complete message. If the service option received in the Handoff Request message is not available at the target BS and the target BS selected a different service option for the handoff then the target BS shall include the service option it selected in the IS-2000 Service Configuration Record IE.
e. Upon receipt of the Handoff Request Acknowledge message the MSC stops timer T11. The MSC prepares to switch the MS from the source BS to the target BS and sends a Handoff Command message to the source BS. The MSC shall include the service option it received from the Handoff Request Acknowledgement message in the Handoff Command message. The source BS stops timer T7.
f. The source BS sends a Service Connect Message to the MS indicating the new service option for the call. Note this step is only necessary for IS-95-A MSs; for IS-95-B and cdma2000 MSs, the service option can be included in the General or Universal Handoff Direction Message.
g. The source BS sends the handoff direction message to the MS. The action time is set to the same action time as the Service Connect Message (step ‘f’). If the MS is allowed to return to the source BS, timer Twaitho is also started by the source BS.
h. The MS may acknowledge the handoff direction message by sending an MS Ack Order to the source BS.
If the handoff direction message is sent using quick repeats, the source BS might not request an acknowledgment from the MS.
i. The source BS sends a Handoff Commenced message to the MSC to notify it that the MS has been ordered to move to the target BS channel. The source BS starts timer T306 to await the Clear Command message from the MSC. If timer Twaitho has been started, the source BS shall wait for that timer to expire before sending the Handoff Commenced message.
j. The MS sends reverse traffic channel frames or the traffic channel preamble to the target cell(s).
k. The MS sends a Handoff Completion Message to the target BS. The target BS stops timer T9.
l. The MS sends a Service Connect Completion message to the target BS to complete the change to the new service option.
m. The target BS sends the BS Ack Order to the MS over the air interface.
n. The target BS sends a Handoff Complete message to the MSC to notify it that the MS has successfully completed the hard handoff. The target BS stops timer T9.
o. The MSC sends a Clear Command message to the source BS and starts timer T315. The source BS stops timer T306.
335 Section 3
3GPP2 A.S0013-D v2.0
p. The source BS sends a Clear Complete message to the MSC to notify it that clearing has been accomplished. The MSC stops timer T315.
1
2
3.30 Reverse FCH Gating 3
4 This feature is supported using existing handoff call flows.
3.31 Voice over IP (VoIP) 5
6 This feature is supported using 3G packet data services call flows. Refer to section 3.17.
3.32 Network Directed System Selection (NDSS) 7
8
9
10
11
12
13
14
This section contains examples showing the use of the appropriate messages for service redirection.
In cdma2000 1x systems, there are three types of service redirection messages; SRM (Service Redirection Message), GSRM (Global Service Redirection Message) to redirect only those MSs with MOB_P_REV less than six, and EGSRM (Extended Global Service Redirection Message) to redirect only those MSs with MOB_P_REV equal to or greater than six.
3.32.1 Redirection During Mobile Origination 15
16
17
18
The following call flow shows a mobile originated call prior to registration. For simplicity authentication procedures are not addressed. For authentication procedures, refer to section 3.20.1.
Section 3 336
3GPP2 A.S0013-D v2.0
MS BS-2 MSC-2 time
Origination Messagea
b
c
d
e
f
BS-1 MSC-1
CM Service Request
EGSRDM/GSRDM/SRDM Origination
Message
CM ServiceRequest
Service Redirection
T303
g
Normal call setup
BS Ack Order
h
i
BS Ack Order
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Figure 3.32.1-1 Service Redirection During Mobile Origination
a. The MS scans, finds a serving system and sends an Origination Message to BS-1.
b. BS-1 acknowledges the receipt of the Origination Message with a Base Station Acknowledgement Order to the MS.
c. BS-1 sends a CM Service Request message to MSC-1 and starts timer T303.
d. MSC-1 determines that another system is preferable for the MS and sends a Service Redirection message to BS-1. BS-1 stops timer T303.
e. BS-1 conveys the redirection information received in the Service Redirection message by sending an EGSRDM (Extended Global Service Redirection Message) to the MS with P_REV equal to or greater than six, a GRSDM (Global Service Redirection Message) to the MS with P_REV less than six, or a Service Redirection message to the MS.
f. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified preferred system, and sends an Origination Message to BS-2.
g. BS-2 acknowledges the receipt of the Origination Message with a Base Station Acknowledgement Order to the MS.
h. BS-2 sends a CM Service Request message to MSC-2.
i. The normal call procedures are used between MSC-2 and BS-2 to establish the call. Refer to section 3.1.1.
337 Section 3
3GPP2 A.S0013-D v2.0
3.32.2 Redirection During Mobile Registration 1
2 The following call flow illustrates redirection during registration.
MS BS-2 MSC-2 time
Registration Message a
b
c
f
g
h
BS-1 MSC-1
Location Updating Request
EGSRDM/GSRDM/SRDM RegistrationMessage Location Updating
Request
d
e
Registration Accepted
Service Redirection
T3210
Location Updating Accept
T3210
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Figure 3.32.2-1 Service Redirection During Mobile Registration
a. MS scans, finds a serving system and sends a Registration Message to the BS-1.
b. The BS-1 sends a Location Updating Request message to MSC-1 and starts timer T3210.
c. MSC-1 determines that another system is preferable for the MS, and sends a Service Redirection message to BS-1. BS-1 stops timer T3210 upon receipt of this message.
d. BS-1 conveys the redirection information received in the Service Redirection message by sending a EGSRDM to the MS with P_REV equal to or greater than six, GRSDM to the MS with P_REV less than six, or Service Redirection message to the MS.
e. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified preferred system, and sends a Registration Message to BS-2.
f. BS-2 sends the Location Updating Request message to MSC-2 and starts timer T3210.
g. MSC-2 sends a Location Updating Accept message to BS-2 to indicate that the Location Updating Request message has been processed. BS-2 stops timer T3210.
h. BS-2 sends a Registration Accepted Order to the MS.
Section 3 338
3GPP2 A.S0013-D v2.0
3.32.3 Re-Origination Upon Failed Re-Direction 1
2
3
The following call flow shows a mobile re-origination as a return to the first system upon failure to obtain service from the redirected system.
MS BS-2 MSC-2 time
Origination Messagea
b c
d
e
f
BS-1 MSC-1
CM Service Request
EGSRDM/GSRDM/SRDM Origination
Message
Origination Message
g
h
Normal call setup
CM Service Request
Release Orderi
Clear Command
j
k
l
T315
Clear Complete
Service Redirection
T303
T303
CM Service Request
m
BS Ack Order
BS Ack Order
BS Ack Order
n
o
4
5
6
7
8
9
10
11
12
13
14
Figure 3.32.3-1 Re-Origination Upon Failed Re-Direction
a. The MS scans, finds a serving system and sends an Origination Message to BS-1.
b. BS-1 acknowledges the receipt of the Origination Message with a Base Station Acknowledgement Order to the MS.
c. BS-1 sends a CM Service Request message to MSC-1 and starts timer T303.
d. MSC-1 determines that another system is preferable for the MS and sends a Service Redirection message including an indication that the MS shall return if the redirections fails to BS-1. BS-1 stops timer T303.
e. BS-1 conveys the redirection information received in the Service Redirection message by sending an EGSRDM to the MS with P_REV equal to or greater than
339 Section 3
3GPP2 A.S0013-D v2.0
six, GRSDM to the MS with P_REV less than six, or Service Redirection message to the MS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
f. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified preferred system, and sends an Origination Message to BS-2.
g. BS-2 acknowledges the receipt of the Origination Message with a Base Station Acknowledgement Order to the MS
h. BS-2 sends a CM Service Request message to MSC-2 and starts timer T303.
i. MSC-2 does not accept the CM Service Request message (e.g. because of a protocol mismatch or registration reject). MSC-2 initiates call clearing by sending a Clear Command message to BS-2 to instruct BS-2 to release the associated dedicated resource. BS-2 stops timer T303 and starts timer T315.
j. BS-2 initiates call clearing over the air interface by transmitting a Release Order to the MS.
k. BS-2 returns a Clear Complete message to MSC-2. MSC-2 stops timer T315 and releases the underlying transport connection.
l. The MS sends an Origination Message with a return cause as specified in [5] to BS-1 to indicate this is a re-origination due to redirection failed.
m. BS-1 acknowledges the receipt of the Origination Message with a Base Station Acknowledgement Order to the MS.
n. BS-1 sends a CM Service Request with an indication that the redirection failed to MSC-1.
o. The normal call procedures are used between MSC-1 and BS-1 to establish the call. Refer to section 3.1.1.
Section 3 340
3GPP2 A.S0013-D v2.0
3.32.4 Re-Registration Upon Failed Re-Direction 1
2
3
The following call flow shows a mobile re-registration as a return to the first system upon failure to register to the redirected system.
MS BS-2 MSC-2 time
Registration Message a
b
c
f
g
h
BS-1 MSC-1
Location Updating Request
EGSRDM/GSRDM/SRDM
Registration Message
Location Updating Request
d
e
Location Updating Reject
Registration Rejected Order
Registration Message
Location Updating Request
Location Updating Accept
i
j
k
Service Redirection
T3210
T3210
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Figure 3.32.4-1 Re-Registration Upon Failed Re-Direction
a. The MS scans, finds a serving system and sends a Registration Message to BS-1.
b. BS-1 sends a Location Updating Request message to MSC-1. BS-1 starts timer T3210.
c. MSC-1 determines that another system is preferable for the MS and sends a Service Redirection message to BS-1 including an indication that the MS shall return to this system if the redirections fails. BS-1 stops timer T3210.
d. BS-1 conveys the redirection information from the Service Redirection message by sending an EGSRDM to the MS with P_REV equal to or greater than six, GRSDM to the MS with P_REV less than six, or Service Redirection message.
e. Upon receipt of the EGRDSM/GRSDM/SRDM, the MS scans, finds the specified preferred system, and sends a Registration Message to BS-2.
f. BS-2 sends the Location Updating Request message to MSC-2 and starts timer T3210.
g. MSC-2 sends a Location Updating Reject message to BS-2 to indicate that the registration failed.
341 Section 3
3GPP2 A.S0013-D v2.0
h. BS-2 sends a Registration Rejected Order to the MS. 1
2
3
4
5
6
i. The MS sends a Registration Message with return cause as specified in [5] to BS-1.
j. BS-1 sends a Location Updating Request message with an indication that redirection failed to MSC-1. BS-1 starts timer T3210.
k. MSC-1 sends a Location Updating Accept message to BS-1 to indicate that the Location Updating Request message has been processed. BS-1 stops timer T3210.
3.33 Transcoder Free Operation (TrFO) 7
8 This feature is supported using existing call flows in section 3.1.
3.34 Remote Transcoder Operation (RTO) 9
10 This feature is supported using existing call flows in section 3.1.
3.35 Voice Preference Over Packet (VPOP) 11
12
13
14
The following call flow illustrates the case where the MS has an active packet data session when an incoming voice call needs to be delivered to the MS. It is assumed that the mobile user is subscribed to and has activated the VPOP feature.
Section 3 342
3GPP2 A.S0013-D v2.0
MS BS MSC
Active Packet Data Session
Clear Command
TCH Release
Mobile Terminated Call Setup Procedure
Dormant Packet Data Session
A9-Release-A8
A9-Release-A8 Complete
Clear Complete
PCF PDSN
a
b
c
d
e
f
g
h
T315
Trel9A10/A11 Accounting Procedures
Active Voice Call, Dormant Packet Data Sessioni
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Figure 3.35-1 Voice Call Preemption of a Traffic Channel
a. The MSC receives indication of an incoming voice call. The MSC determines that the MS is on an active packet data call. The MSC determines that the user has subscribed to and activated the VPOP feature and sends a Clear Command message to the BS with Cause IE set to ‘10H packet call going dormant’, instructing the BS to release the associated dedicated resource. The MSC starts timer T315.
b. Upon receiving the Clear Command message with Cause IE set to ‘10H Packet Call going Dormant’ the BS signals to the MS to remain in the Dormant State after the traffic channel is released (e.g., by using the Service Option Control Message or Retry Order; refer to [5] and [21]) and initiates traffic channel release.
c. For each active PDSI the BS sends an associated A9-Release-A8 message, with a cause value set to “Packet call going dormant”, to the PCF to instruct the PCF to release the associated dedicated resources, and starts timer Trel9. Note that in this scenario the A10 connection is not released. If the network attempts to reactivate the
343 Section 3
3GPP2 A.S0013-D v2.0
packet data session, normal procedures for network initiated packet data reactivation attempt while the MS is busy take place.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
d. The A11 accounting update procedures take place. The PCF sends the ‘All Dormant Indicator’ to the PDSN. Any P-P connections that may exist to an anchor PDSN (refer to section 3.19.4.2) are released according to procedures specified in [8].
e. The PCF acknowledges each A9-Release-A8 message by returning an A9-Release-A8 Complete message. The BS stops timer Trel9.
f. The BS returns a Clear Complete message to the MSC. The MSC releases the underlying transport connection and stops timer T315. This step may occur any time after the traffic channel is released.
g. At this point the packet data session is considered to be in the Dormant State.
h. The MSC uses normal mobile termination call setup procedure for delivering the call to the MS; refer to section 3.1.2.
i. At this point the voice call is active and the packet data session is in Dormant State.
3.36 Circuit Switched Video Conferencing Calls 16
17 There are no call flows associated with this feature.
3.37 Fast Call Setup 18
19
3.37.1 Direct Channel Assignment (DCA) 20
21
22
23
24
25
26
27
28
29
30
31
The Direct Channel Assignment feature is a mobile termination call setup procedure where the BS sends an ECAM (extended channel assignment message) directly to the MS by either bypassing the paging procedure completely, or sending the ECAM after paging the MS but before receiving a page response message. This feature facilitates faster mobile terminated call setups. Radio Environment Reporting (RER) mode may be used to assist the BS with DCA. Upon receipt of the Paging Request message from the MSC, if the BS assigns the traffic channel using direct traffic channel assignment procedures, it informs the MSC by including the authentication event indicating direct channel assignment in the Paging Response message. If authentication is not performed as part of direct channel assignment procedures, the BS may request the MSC to initiate unique challenge procedures by sending a BS Authentication Request message.
3.37.1.1 Mobile Termination with Direct Channel Assignment 32
33
34
35
36
37
38
39
This section describes the call flow associated with an MS call termination in the system using direct channel assignment when the BS is connected to a circuit-switched MSC. The call flow for mobile termination with direct channel assignment when the BS is connected to an MSCe would be similar to that of 3.37.1.1-1, with Bearer Update Request/Response messages exchanged between the MSCe and the BS to specify the bearer format and address to be used with the MGW (refer to 3.1.2.1.3-1 and 3.1.2.1.3-2 for use of Bearer Update Request/Response messages).
Section 3 344
3GPP2 A.S0013-D v2.0
BS Ack Order
MS BS MSCtime
c
d
e
f
g
h
i
j
Complete L3 Info: Paging Response
Assignment Request
Tch Preamble
k
m
MS Ack Order
T10
Connect
ECAMb
aPaging Request
n
Alert with Info
MS Ack Order
Connect Order
BS Ack Order
T301
T3113
T303
l
Service Negotiation Procedures
Assignment Complete
optional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.37.1.1-1 Mobile Termination Support with Direct Channel Assignment
a. The MSC determines that an incoming call terminates to an MS within its serving region and sends a Paging Request message to the BS to initiate a mobile terminated call setup scenario. The MSC then starts timer T3113.
b. The BS initiates a direct channel assignment procedure by sending an ECAM message to the MS. The BS may optionally page the MS first to put it in unslotted mode. The MS may optionally respond with a Page Response to the ECAM message if requested to by the BS (DCA with unassured page response mode).
c. The MS begins to transmit the traffic channel preamble (TCH preamble) over the designated reverse traffic channel.
d. Once the BS acquires the MS, the BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, sends the message to the MSC, and starts timer T303. The BS may include an indication that direct channel assignment was used for the call in the authentication event. The BS may request the MSC to allocate a preferred terrestrial circuit. The MSC stops timer T3113 upon receipt of the Paging Response message from the BS.
345 Section 3
3GPP2 A.S0013-D v2.0
e. The BS sends a Base Station Acknowledgment Order, with Layer 2 Ack required, to the MS over the forward traffic channel.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
f. The MS acknowledges the reception of the BS order by transmitting the Mobile Station Acknowledgment Order.
g. The MSC sends an Assignment Request message to the BS. This message also includes a terrestrial circuit if one is to be used between the MSC and the BS. The MSC then starts timer T10.
h. The BS and MS perform service negotiation procedures over the air (this step may not occur if a SYNC_ID was included in the ECAM and accepted by the MS).
i. The BS sends the Assignment Complete message to the MSC. The MSC stops timer T10 upon receipt of the Assignment Complete message from the BS, and starts timer T301.
j. The BS sends the Alert with Information Message to the MS to cause ringing at the MS.
k. The MS acknowledges the reception of the Alert with Information Message by transmitting the Mobile Station Acknowledgment Order.
l. When the call is answered at the MS, a Connect Order, with acknowledgment required, is transmitted to the BS.
m. The BS acknowledges the Connect Order with the Base Station Acknowledgment Order over the forward traffic channel.
n. The BS sends a Connect message to the MSC to indicate that the call has been answered at the MS. The MSC stops timer T301 upon receipt of the Connect message from the BS. At this point, the call is considered stable and in the Conversation State.
3.37.1.2 Network Initiated PDSI Reactivation via Direct Channel Assignment (Dormant Packet Data Session, SCCP connection maintained) 25
26
27
28
29
30
31
32
33
This section describes the call flow associated with a network initiated packet data service instance reactivation for a dormant packet data session using direct channel assignment. When the packet data session transitions to the Dormant State, the BS may postpone releasing the SCCP/SUA and A8 connections. For instance, the SCCP/SUA and A8 connections may be maintained while the MS operates in RER mode, until an associated timer expires, or until some other event internal to the BS triggers the BS to release the connection. In the example illustrated by this call flow, the SCCP connection is maintained while the MS is operating in RER mode.
Section 3 346
3GPP2 A.S0013-D v2.0
MS
time
a
b
c
d
e
f
g
h
i
A9-Setup-A8
IS-2000 TCH Setup
TA8-Setup
Packet Data Traffic
A9-BS Service Request
-A9-BS Service Response
ECAM
BS MSC / VLR PDSN PCF
Tbsreq9
Dormant Packet Data Session, RER Mode, SCCP connection with MSC maintained
BS Authentication Request
A11-Registration Request
A11-Registration Reply
j
k
A9-Connect-A8
lTerminal Authentication
REM
T3273
Tregreq
optional
optional
Active Packet Data Session
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Figure 3.37.1.2-1 Network Initiated PDSI Reactivation via Direct Channel Assignment (Dormant Packet Data Session, SCCP connection maintained)
a. The MS periodically sends a Radio Environment message to the BS to report its location and pilot strength measurements.
b. The PDSN sends data packets to the PCF on an existing PPP connection and A10 connection associated with a specific MS and dormant packet data service instance.
c. If an A8 connection is not present, the PCF sends an A9-BS Service Request message containing the SR_ID identifying the packet data service instance to the BS to request reactivation of packet data service instance, and starts timer Tbsreq9. Note: steps c, d, g, and j only occur if an A8 connection is not available.
d. The BS responds with an A9-BS Service Response message to the PCF. The PCF stops timer Tbsreq9 upon receipt of the A9-BS Service Response message.
e. The BS initiates a direct channel assignment procedure by sending an Extended Channel Assignment message to the MS.
347 Section 3
3GPP2 A.S0013-D v2.0
f. The BS and the MS continue with the DCA radio resources setup procedure. The BS uses the SR_ID to identify the packet data service instance to be re-activated.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
g. The BS sends an A9-Setup-A8 message to the PCF to establish an A8 (User Traffic) connection between the BS and the PCF if it doesn’t currently exist. The BS starts timer TA8-setup.
h. The PCF sends an A11-Registration Request message to the PDSN. This message includes an Active Start Airlink Record accounting data. The PCF starts timer Tregreq.
i. The PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The PCF stops timer Tregreq.
j. The PCF responds with an A9-Connect-A8 message to the BS to complete the setup of an A8 (User Traffic) connection for this packet service request. Upon receipt of the A9-Connect-A8 message from the PCF, the BS stops timer TA8-setup.
k. The BS may initiate the terminal authentication procedure over the traffic channel by sending a BS Authentication Request message to the MSC. The BS starts timer T3273.
l. The MSC responds by initiating the terminal authentication procedure described in section 3.20.1.2. The BS sends a RANDU to the MS in the Authentication Request message. The BS sends the MS computed AUTHU in the Authentication Response message from the BS. Note: if the MSC rejects the BS initiated terminal authentication procedure, it responds by sending a BS Authentication Request Ack message to the BS with a failure cause value. Upon receipt of an Authentication Request or BS Authentication Request Ack message from the MSC, the BS stops timer T3273.
3.38 Event Notification 25
26
27
28
This section provides two examples of the Event Notification Feature. In these examples, the MSC sends a message to the BS to cease call processing for a particular MS before the SCCP link has been established for the call.
3.38.1 Event Notification – Multiple Pages 29
30
31
32
In this example, the MSC attempts to page the MS on multiple BSs. When it receives a Page Response from one BS, it alerts the other BSs that the MS has been found, and therefore current paging procedures may cease.
Section 3 348
3GPP2 A.S0013-D v2.0
BS-2 BS-3 time comment
a
MSCMS BS-1
d
T3113
e
c
b
Paging Request
Page Message
Paging ResponsePage Response Message
Event Notification
f
Event Notification Ack Tevent
Tevent optional
conditionalt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Figure 3.38.1-1 Event Notification for Multiple Page Scenario
a. The MSC pages the MS on several base stations by sending Paging Request messages. The MSC starts timer T3113.
b. BS-1, BS-2 and BS-3 begin to page the MS over the air, awaiting a response.
c. The MS receives the Page Message from BS-2, but no others, and responds with a Page Response message.
d. BS-2 sends a Paging Response message to the MSC to indicate that it has heard from the MS. The MSC stops timer T3113.
e. The MSC may send an Event Notification message to BS-1 and BS-3, indicating that these bases stations can stop the current paging procedures for the MS. The MSC starts an instance of timer Tevent for each Event Notification message sent.
f. BS-1 and BS-3 reply with Event Notification Ack messages. The MSC stops the Tevent timers.
3.38.2 Event Notification – Early Traffic Channel Assignment 15
16
17
In this example, the MSC pages the MS and the BS provides early traffic channel assignment. For reasons of security or otherwise, the MSC decides to terminate the call.
349 Section 3
3GPP2 A.S0013-D v2.0
Section 3 350
time comment
a
MSCMS BS-1
d
T3113
e
c
b
Paging Request
Page Message
Paging ResponsePage Response Message
Event Notification
f
Event Notification Ack Tevent
optional
conditional
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Figure 3.38.2-1 Event Notification for Early Traffic Channel Assignment
a. The MSC pages the MS by sending a Paging Request message to the BS. The MSC starts timer T3113.
b. The BS sends a Page Message to the MS.
c. The MS receives the Page Message and responds with a Page Response message.
d. The BS sends a Paging Response message to the MSC and indicates that it has assigned resources to the MS by setting the Alloc bit in the Radio Environment and Resources IE to ‘1’. The MSC stops timer T3113.
e. The MSC may send an Event Notification message to the BS, indicating that the call processing procedures for the MS should be stopped and the radio resources released. The MSC starts timer Tevent.
f. The BS replies with an Event Notification Ack message. The MSC stops timer Tevent.