Interoperability Specification for cdma2000 Air Interface · 3GPP2 C.S0044-D v1.0 Revision History Revision Description of Changes Date Rev 0 v1.0 Initial Publication October, 2004

© 2014 3GPP2

3GPP2 and its Organizational Partners claim copyright in this document and individual

Organizational Partners may copyright and issue documents or standards publications in

individual Organizational Partner’s name based on this document. Requests for

reproduction of this document should be directed to the 3GPP2 Secretariat at

[email protected]. Requests to reproduce individual Organizational Partner’s

documents should be directed to that Organizational Partner. See www.3gpp2.org for

more information.

3GPP2 C.S0044-D v1.0

July 2014

Interoperability Specification for cdma2000 Air Interface

mailto:[email protected]

http://www.3gpp2.org/

3GPP2 C.S0044-D v1.0

Revision History

Revision Description of Changes Date

Rev 0 v1.0 Initial Publication October, 2004

Rev A v1.0 Revision Augest, 2007

Rev B v1.0 Revision July, 2011

Rev C v1.0 Revision Augest, 2012

Rev C v1.0 Republication to clarify Annex normative or informative issue

October, 2012

Rev D v1.0 Add 1x Rev.F releated tests March, 2014

Rev D v1.0 Re-published to address some pdf generate bugs July, 2014

3GPP2 C.S0044-D v1.0

i

CONTENTS 1

FOREWORD .................................................................................................................................. xv 2

Introduction ................................................................................................................................. xv 3

Testing Objective ........................................................................................................................ xv 4

Execution Strategy ...................................................................................................................... xv 5

Supplementary Terms and Definitions ....................................................................................... xvi 6

Tolerances ............................................................................................................................... xxxi 7

References ............................................................................................................................... xxxi 8

1 Miscellaneous Air Interface Tests ........................................................................................ 1-1 9

1.1 Call Setup under Various PSIST Settings ....................................................................... 1-1 10

1.2 Registration Attempts with Different PSIST Settings....................................................... 1-6 11

1.3 Short Message Service with Different PSIST Settings .................................................... 1-8 12

1.4 Quick Paging Channel CCI ............................................................................................ 1-10 13

1.5 Mobile Station Response to Status Request Message ................................................. 1-12 14

1.6 SYNC Channel Support for Mobile Stations not capable of TD, or not capable of QPCH 15

or RC>2 ................................................................................................................................... 1-14 16

1.7 Sync Channel support for Mobile Stations not capable of TD, but capable of QPCH or 17

RC>2 1-16 18

1.8 Sync Channel Support for Mobile Stations capable of TD and QPCH or RC>2 ........... 1-17 19

1.9 Hashing F-CCCH, F-CCCH slot .................................................................................... 1-20 20

1.10 CDMA Channel Hashing on F-PCH for Mobile Stations not capable of QPCH or RC>221

1-21 22

1.11 CDMA Channel Hashing on F-PCH for Mobile Stations capable of QPCH or RC>2 1-22 23

1.12 CDMA Channel Hashing on F-BCCH; Mobile Station not capable of either TD or 24

QPCH (RC>2) ......................................................................................................................... 1-24 25

1.13 CDMA Channel Hashing on F-BCCH; Mobile Station not capable of TD (STS) but 26

capable of QPCH (RC>2) ....................................................................................................... 1-25 27

1.14 CDMA Channel Hashing on F-BCCH; Mobile Station capable of both TD (STS) and 28

QPCH (RC>2) ......................................................................................................................... 1-27 29

1.15 F-CCCH SUPPORT .................................................................................................. 1-28 30

1.16 Paging Indicator on the Quick Paging Channel ........................................................ 1-29 31

1.17 M2M Capability Support ............................................................................................ 1-31 32

1.18 Data Burst sent on the REACH. ................................................................................ 1-31 33

1.19 Skip Overhead Read ................................................................................................. 1-32 34

3GPP2 C.S0044-D v1.0

ii

1.20 Bundling R-SCH Request with Origination Message ................................................ 1-33 1

2 Basic Call Processing Tests ................................................................................................ 2-1 2

2.1 Mobile Originated Voice Calls ......................................................................................... 2-1 3

2.2 Mobile Station Terminated Voice Calls ........................................................................... 2-4 4

2.3 Busy Tone ........................................................................................................................ 2-8 5

2.4 Mobile Station Origination Call with Inter Band Channel Assignment ............................. 2-8 6

2.5 Mobile Station Terminated Call with Inter Band Channel Assignment ............................ 2-9 7

2.6 DTMF ............................................................................................................................. 2-10 8

2.7 Slot Cycle Index ............................................................................................................. 2-12 9

2.8 Reverse Radio Link Failure ........................................................................................... 2-13 10

2.9 Channel Assignment from CDMA to Analog ................................................................. 2-15 11

2.10 Network Busy ............................................................................................................ 2-16 12

2.11 Release Order on the Access Channel ..................................................................... 2-16 13

2.12 True IMSI Support, Land Party to Mobile Station Call, Matching MCC and IMSI_11_12, 14

True IMSI addressing supported by the base station and mobile station ............................... 2-17 15


True IMSI addressing supported by the base station with MIN-based addressing supported by 17

the mobile station. ................................................................................................................... 2-18 18


True IMSI addressing not supported by the base station ....................................................... 2-19 20

2.15 True IMSI Support, Land Party to Mobile Station Call, Different MCC and IMSI_11_1221

2-20 22

2.16 PACA Origination, User Terminates While Still In Queue ........................................ 2-21 23

2.17 PACA Origination, Idle Handoff While in Queue ....................................................... 2-22 24

2.18 PACA Origination, Traffic Channel Becomes Available ............................................ 2-23 25

2.19 PACA Origination, Features Interaction .................................................................... 2-24 26

2.20 PACA Origination, Permanent Invocation ................................................................. 2-25 27

2.21 PACA Origination, PACA Disabled for Mobile Station .............................................. 2-27 28

2.22 Service Configuration and Negotiation without SYNC_ID ........................................ 2-28 29

2.23 Service Configuration and Negotiation with SYNC_ID ............................................. 2-32 30

2.24 Intra-Band Channel Assignment ............................................................................... 2-35 31

2.25 Silent-Retry ................................................................................................................ 2-36 32

2.26 MSID, MCC, and IMSI ............................................................................................... 2-38 33

2.27 RL RC 8 / FL RC 11 Parameter Change using RCPM ............................................. 2-41 34

3GPP2 C.S0044-D v1.0

iii

2.28 RL RC 8 / FL RC 11 Parameter Change using GEM ................................................ 2-43 1

2.29 Forward Link Error with RC11/RC12......................................................................... 2-45 2

2.30 Traffic Channel Assignment in QoF .......................................................................... 2-47 3

2.31 Call recovery Request Message ............................................................................... 2-48 4

2.32 General Overhead Information Message .................................................................. 2-50 5

2.33 SO 33 call set-up with RC 11 and RC 8 .................................................................... 2-51 6

2.34 SO 33 Fast Connection Setup .................................................................................. 2-53 7

2.35 Direct Channel Assignment ....................................................................................... 2-55 8

2.36 Extended Slot Cycle Index ........................................................................................ 2-55 9

3 Handoff Tests ....................................................................................................................... 3-1 10

3.1 Soft Handoff with Dynamic Threshold ............................................................................. 3-1 11

3.2 Soft Handoff without Dynamic Threshold ........................................................................ 3-6 12

3.3 Hard Handoff Between Frequencies in the Same Band Class ..................................... 3-11 13

3.4 Hard Handoff from CDMA to Analog ............................................................................. 3-13 14

3.5 Soft Handoff in Fading ................................................................................................... 3-14 15

3.6 Hard Handoff in Fading ................................................................................................. 3-18 16

3.7 Hard Handoff Between Different Band Classes ............................................................ 3-21 17

3.8 Hard Handoff with and without Return on Failure ......................................................... 3-22 18

3.9 Search Window Size and Offset (Traffic State) ............................................................. 3-24 19

3.10 Search Window Size and Offset (Idle State) ............................................................. 3-33 20

3.11 Channel Assignment into Soft Handoff (CASHO) ..................................................... 3-41 21

3.12 Traffic Channel Preamble during Hard Handoff Between Frequencies in same band . 3-22

42 23

3.13 Hopping Pilot Beacon ................................................................................................ 3-44 24

3.14 Hard Handoff between Frequencies with Different Radio Configurations ................ 3-45 25

3.15 Handoff on Same Frequency with Different Radio Configurations ........................... 3-47 26

3.16 Hard Handoff while in the Waiting for Mobile Station Answer Substate ................... 3-49 27

3.17 Mobile Assisted Inter-Frequency Hard Handoff (CDMA to CDMA) .......................... 3-51 28

3.18 Mobile Assisted Inter-Frequency Hard Handoff (CDMA to Analog) .......................... 3-53 29

3.19 Hard Handoff between Frequencies with Different Protocol Revisions .................... 3-55 30

4 Power Control ...................................................................................................................... 4-1 31

4.1 Forward Traffic Channel Power Control .......................................................................... 4-1 32

4.2 Fast Forward Power Control (FFPC) ............................................................................... 4-4 33

3GPP2 C.S0044-D v1.0

iv

4.3 Lowest Rate Reverse Fundamental Channel Gating .................................................... 4-52 1

4.4 R-FCH Gating during Soft Handoff ................................................................................ 4-54 2

5 Registrations ........................................................................................................................ 5-1 3

5.1 Power-Up Registration .................................................................................................... 5-1 4

5.2 Power - Down Registration .............................................................................................. 5-3 5

5.3 Distance-Based Registration ........................................................................................... 5-5 6

5.4 Timer-Based Registration ................................................................................................ 5-8 7

5.5 Parameter-Change Registration ...................................................................................... 5-9 8

5.6 Zone-Based Registration ............................................................................................... 5-11 9

6 Authentication ...................................................................................................................... 6-1 10

6.1 Shared Secret Data (SSD) Initialized when A-Key is Changed ...................................... 6-1 11

6.2 Shared Secret Data Update ............................................................................................ 6-2 12

6.3 Mismatched A-Keys ......................................................................................................... 6-4 13

6.4 Activating Voice Privacy on Call Setup ........................................................................... 6-5 14

6.5 Activating Voice Privacy at the Mobile Station When a Call Is Active ............................. 6-6 15

6.6 Signaling Message Encryption on Forward Traffic Channel ........................................... 6-7 16

6.7 Signaling Message Encryption on Reverse Traffic Channel ........................................... 6-8 17

6.8 Hard Handoffs between Base Stations with Signaling Message Encryption Active ..... 6-10 18

6.9 Authentication upon Originations .................................................................................. 6-11 19

6.10 Hard Handoff from CDMA to Analog with Signaling Message Encryption Active ..... 6-12 20

7 Service Redirection test cases ............................................................................................ 7-1 21

7.1 Global Service Redirection between Band Classes ........................................................ 7-1 22

7.2 Global Service Redirection between CDMA and a Non-CDMA System ......................... 7-2 23

7.3 Global Service Redirection between Channels in the Same Band Class ....................... 7-4 24

7.4 Service Redirection between Band Classes ................................................................... 7-5 25

7.5 Service Redirection between CDMA and a Non-CDMA System .................................... 7-7 26

7.6 Service Redirection between Channels in the Same Band Class ................................... 7-8 27

7.7 Extended Global Service Redirection between Band Classes ...................................... 7-10 28

7.8 Extended Global Service Redirection between CDMA and a Non-CDMA System ....... 7-11 29

7.9 Extended Global Service Redirection between Channels in the Same Band Class ..... 7-13 30

8 Short Message Service ........................................................................................................ 8-1 31

8.1 Mobile Station Terminated SMS Tests ............................................................................ 8-1 32

3GPP2 C.S0044-D v1.0

v

8.2 Mobile Station Originated SMS Tests ............................................................................. 8-8 1

8.3 Broadcast SMS Delivery on the Common Channel ...................................................... 8-14 2

8.4 Mobile Station Terminated Enhanced Messaging Services [EMS] Tests: .................... 8-16 3

8.5 Mobile Station Originated Enhanced Messaging Services [EMS] Tests: ...................... 8-25 4

9 Subscriber Calling Features................................................................................................. 9-1 5

9.1 Call Forwarding Unconditional (CFU) .............................................................................. 9-1 6

9.2 Call Forwarding Busy (CFB) ............................................................................................ 9-1 7

9.3 Call Forwarding Default (CFD) ........................................................................................ 9-2 8

9.4 Call Forwarding No Answer (CFNA) ............................................................................... 9-3 9

9.5 Three-Way Calling ........................................................................................................... 9-4 10

9.6 Call Alerting ..................................................................................................................... 9-5 11

9.7 Calling Party Number for Mobile station Terminated Call Setup ..................................... 9-6 12

9.8 Calling Party Number for Call Waiting ............................................................................. 9-7 13

9.9 Call Waiting ...................................................................................................................... 9-8 14

9.10 Voice Mail Message Waiting Notification from the Idle State ..................................... 9-9 15

9.11 Voice Mail Message Waiting Notification from the Conversation State .................... 9-10 16

9.12 Calling Party Name Presentation during Call Setup ................................................. 9-11 17

9.13 Calling Name Presentation (CNAP) during Conversation State ............................... 9-12 18

9.14 Display Records sent in the Feature Notification Message. ..................................... 9-13 19

9.15 Display Records Sent in the Flash With Information Message ................................. 9-14 20

9.16 Display Records Sent in the Alert with Information Message ................................... 9-15 21

9.17 TTY/TDD ................................................................................................................... 9-16 22

9.18 WLL Call Waiting Indicator Support .......................................................................... 9-18 23

9.19 Answer Holding ......................................................................................................... 9-20 24

9.20 User Selective Call Forwarding ................................................................................. 9-22 25

10 Asynchronous Data and Fax Services ............................................................................... 10-1 26

10.1 Send/Receive Fax ..................................................................................................... 10-1 27

10.2 Upload/Download Binary File .................................................................................... 10-3 28

10.3 Simultaneous Two-way File Transfer/Carrier Detect ................................................ 10-4 29

10.4 Compound AT Command, Initialization and Connection Delay ................................ 10-6 30

10.5 Escaping to Command Mode .................................................................................... 10-7 31

10.6 Air Interface Data Compression ................................................................................ 10-8 32

3GPP2 C.S0044-D v1.0

vi

10.7 RLP Operation in a Poor RF Environment .............................................................. 10-10 1

10.8 RLP Abort and TCP Retransmit Test ...................................................................... 10-11 2

10.9 Internet Control Message Protocol (ICMP) Requests/Replies ................................ 10-13 3

10.10 Reflection of AT Command Parameters ................................................................. 10-14 4

11 Low Speed Packet Data .................................................................................................... 11-1 5

11.1 Forward File Transfer ................................................................................................ 11-1 6

11.2 Reverse File Transfer ................................................................................................ 11-1 7

11.3 Bi-directional File Transfer ........................................................................................ 11-2 8

11.4 Mobile Station Packet Data Inactivity Timer ............................................................. 11-3 9

12 Medium Speed Packet Data .............................................................................................. 12-1 10

12.1 Forward File Transfer with Fundamental and Supplemental Code Channels .......... 12-1 11

12.2 Forward File Transfer with Variable Supplemental Code Channels ......................... 12-2 12

12.3 MSPD Call Setup, No Negotiation ............................................................................ 12-3 13

12.4 MSPD Call Setup, Negotiation to a Different MSPD Service Option ........................ 12-4 14

12.5 MSPD Call Setup, Negotiation to LSPD ................................................................... 12-5 15

12.6 MSPD Call Setup, Mobile Station Maximum Multiplex Option Less than Base Station 16

Maximum Multiplex Option ...................................................................................................... 12-7 17

12.7 MSPD Call Setup, Mobile station Maximum Multiplex Option Greater than Base 18

Station Maximum Multiplex Option ......................................................................................... 12-8 19

12.8 Allocation/De-allocation of Supplemental Code Channels ....................................... 12-9 20

12.9 No Transmission on Supplemental Code Channels ............................................... 12-11 21

12.10 Soft Handoff with Supplemental Code Channels .................................................... 12-12 22

12.11 Adding Supplemental Code Channels during Soft Handoff .................................... 12-13 23

12.12 Hard Handoff to an MSPD-Capable System ........................................................... 12-15 24

12.13 Bi-Directional File Transfers with Forward Supplemental Code Channels ............. 12-17 25

12.14 Rм Interface Flow Control ........................................................................................ 12-18 26

12.15 Dormant Timer ........................................................................................................ 12-19 27

12.16 Packet Zone ID ........................................................................................................ 12-20 28

13 High Speed Packet Data .................................................................................................... 13-1 29



13.3 Bi-directional File Transfer ........................................................................................ 13-3 32

13.4 Service Option Control Message Processing ........................................................... 13-5 33

3GPP2 C.S0044-D v1.0

vii

13.5 Changing Encoding Type on Supplemental Channel during Hard Handoff ............. 13-7 1

13.6 Control Hold Mode Transitions ................................................................................ 13-10 2

13.7 Soft Handoff of Fundamental Channel/Dedicated Control Channel and Supplemental 3

Channels ............................................................................................................................... 13-15 4

13.8 Soft Handoff of Fundamental Channel or Dedicated Control Channel only ........... 13-18 5

13.9 Adding Supplemental Channels during Soft Handoff .............................................. 13-20 6

13.10 Hard Handoff during Data Transfer ......................................................................... 13-21 7

13.11 Hard Handoff to a different Radio Configuration ..................................................... 13-23 8

13.12 Mobile Station Packet Data Inactivity Timer ........................................................... 13-25 9

13.13 Mobile Station and Base Station Operating in Different States .............................. 13-26 10

13.14 RLP Operation in Rayleigh Fading Environment .................................................... 13-29 11

13.15 Release Order Processing ...................................................................................... 13-30 12

13.16 Hysteresis Activation Timer ..................................................................................... 13-32 13

13.17 Hysteresis Timer ..................................................................................................... 13-33 14

14 Over-The-Air Services ....................................................................................................... 14-1 15

14.1 OTASP Download Request Processing .................................................................... 14-1 16

14.2 OTASP PUZL Download Request Processing ......................................................... 14-4 17

14.3 OTASP 3GPD Download Request Processing ......................................................... 14-6 18

14.4 OTASP SSPR Download Request Processing ....................................................... 14-10 19

14.5 OTASP For System Selection and Preferred Roaming - Oversize PRL ................. 14-12 20

14.6 OTAPA Download Request Processing .................................................................. 14-14 21

14.7 Call Origination during an OTAPA Download Session ........................................... 14-17 22

15 Position Determination Tests ............................................................................................. 15-1 23

15.1 Position Determination Tests for GPS, AFLT and Hybrid ......................................... 15-1 24

16 Concurrent Services .......................................................................................................... 16-1 25

16.1 Setup Mobile Station Originated Data Call while Voice Call or Teleservice Call is in 26

Progress .................................................................................................................................. 16-1 27

16.2 Setup Mobile Station terminated Data Call while Voice Call or Teleservice Call is in 28

Progress .................................................................................................................................. 16-5 29

16.3 Setup Mobile Station Originated Voice Call while Data Call or Teleservice Call is in 30

Progress .................................................................................................................................. 16-7 31

16.4 Setup Mobile Station terminated Voice Call while Data Call or Teleservice Call is in 32

Progress ................................................................................................................................ 16-11 33

3GPP2 C.S0044-D v1.0

viii

16.5 Mobile Station Release of a Single Call While Voice and Data Calls are in Progress 16-1

13 2

16.6 Base Station Release of a Single Call While Voice and Data Calls are in Progress .. 16-3

15 4

16.7 Correct Handling of Call Control Signaling ............................................................. 16-17 5

16.8 Analog Handoff Direction Message Terminates All Calls Except One ................... 16-21 6

16.9 Release A Mobile Station in Concurrent Calls with a Release A Base Station Hands off 7

to Pre-Release A Base Station ............................................................................................. 16-22 8

16.10 Release A Mobile Station Hands off between Release A Base Station with Change in 9

Concurrent Calls Support ...................................................................................................... 16-23 10

17 Emergency Calls ................................................................................................................ 17-1 11

17.1 Global Emergency Call Support When Mobile Station is in Idle State ...................... 17-1 12

17.2 Global Emergency Call Support When Mobile Station is in Voice Call. .................... 17-1 13

17.3 Global Emergency Call Support When Mobile Station is in a Data Call ................... 17-2 14

17.4 Emergency Call on a System that is Negative on PRL or SID List ........................... 17-3 15

17.5 Optional Emergency Calls ......................................................................................... 17-4 16

18 HRPD ................................................................................................................................. 18-1 17

18.1 HRPD Acquisition and Idle Mode Operation ............................................................. 18-1 18

18.2 HRPD Session Establishment ................................................................................... 18-1 19

18.3 HRPD Session Configuration and Management with Subnet change ...................... 18-2 20

18.4 AT Color Code and UATI24 ...................................................................................... 18-3 21

18.5 HRPD Connection Setup ......................................................................................... 18-3 22

18.6 AN Packet Data Inactivity Timer ............................................................................... 18-4 23



18.9 Bidirectional File Transfer ......................................................................................... 18-8 26

18.10 RLP Operation in Severely Degraded Channel ........................................................ 18-8 27

18.11 Softer and Soft Handoff – Active HRPD Mode ......................................................... 18-9 28

18.12 HRPD Control Channel Monitoring and Overhead Message Updates ................... 18-11 29

18.13 Control Channel Rate .............................................................................................. 18-11 30

18.14 HRPD ConnectionDeny .......................................................................................... 18-12 31

18.15 HRPD Keep Alive Mechanism ................................................................................ 18-13 32

18.16 Intra-band HRPD-HRPD System Re-Selection (Connected State) ........................ 18-14 33

3GPP2 C.S0044-D v1.0

ix

18.17 Inter-band HRPD-HRPD System Re-Selection (Connected State) ........................ 18-15 1

18.18 Intra-band HRPD-HRPD System Re-selection (Idle State) .................................... 18-16 2

18.19 Inter-band HRPD-HRPD System Re-selection (Idle State) .................................... 18-16 3

18.20 HRPD Terminal Authentication ............................................................................... 18-17 4

18.21 PPP Session in Adverse Conditions - Disconnect cable between AT and PC. ...... 18-18 5

18.22 Unicast ReverseRateLimit ....................................................................................... 18-19 6

18.23 HRPD Location Update Protocol Tests ................................................................... 18-20 7

18.24 Idle State Channel Hashing .................................................................................... 18-20 8

18.25 Inter-frequency Active Handoff ................................................................................ 18-21 9

18.26 Typical HRPD Rev-A Session Configuration .......................................................... 18-23 10

18.27 Multiple Reservations bound to one RLP ................................................................ 18-24 11

18.28 Maximum Open Reservations, Activated RLP and MAC flows .............................. 18-26 12

18.29 QoS Release upon PDSN initiated LCP termination .............................................. 18-27 13

18.30 QoS Release upon AT Initiated PPP Termination .................................................. 18-29 14

18.31 Access Persistence Vector ..................................................................................... 18-30 15

18.32 AT Data Over Signaling Message Transmission .................................................... 18-31 16

18.33 AN Data Over Signaling Message Transmission .................................................... 18-32 17

18.34 Voice Origination in HRPD Idle Mode ..................................................................... 18-34 18

18.35 Voice Termination in HRPD Idle Mode ................................................................... 18-35 19

18.36 SMS Origination in HRPD Idle Mode ...................................................................... 18-36 20

18.37 SMS Termination in HRPD Idle Mode .................................................................... 18-37 21

18.38 Voice Origination in HRPD Active Mode ................................................................. 18-37 22

18.39 Voice Termination in HRPD Active Mode ............................................................... 18-38 23

18.40 SMS Origination in HRPD Active Mode .................................................................. 18-40 24

18.41 SMS Termination in HRPD Active Mode ................................................................ 18-41 25

18.42 Voice Origination in HRPD Dormant Mode ............................................................. 18-42 26

18.43 Voice Termination in HRPD Dormant Mode ........................................................... 18-43 27

18.44 SMS Origination in HRPD Dormant Mode .............................................................. 18-44 28

18.45 SMS Termination in HRPD Dormant Mode ............................................................ 18-45 29

18.46 Inter Revision Handoffs - Dormant HRPD Rev A to HRPD Rev 0 .......................... 18-46 30

18.47 Inter Revision Handoffs - Active HRPD Rev A to HRPD Rev 0 .............................. 18-47 31

18.48 Inter Revision Handoffs – Dormant HRPD Rev 0 to HRPD Rev A ......................... 18-49 32

3GPP2 C.S0044-D v1.0

x

18.49 Inter Revision Handoffs – Active HRPD Rev 0 to HRPD Rev A ............................. 18-51 1

18.50 Inter Technology Switching – Dormant HRPD to cdma2000 1x ............................. 18-52 2

18.51 Inter Technology Switching – Active HRPD to cdma2000 1x ................................. 18-54 3

18.52 Inter Technology Switching – Dormant cdma2000 1x to HRPD ............................. 18-55 4

18.53 Inter RNC Dormant Hand-off (Rev A to Rev A) ...................................................... 18-56 5

18.54 Inter RNC Active Hand-off (Rev A to Rev A) .......................................................... 18-57 6

18.55 Inter RNC Dormant Hand-off (Rev A to Rev 0) ....................................................... 18-58 7

18.56 Inter RNC Active Hand-off (Rev A to Rev 0) ........................................................... 18-59 8

18.57 Inter RNC Dormant Hand-off (Rev 0 to Rev A) ....................................................... 18-60 9

18.58 Inter RNC Active Hand-off (Rev 0 to Rev A) ........................................................... 18-61 10

18.59 Inter-Band Active Hand-off ...................................................................................... 18-62 11

18.60 RLP Activation ......................................................................................................... 18-64 12

18.61 QoS Set Up ............................................................................................................. 18-65 13

18.62 Successful negotiation of Enhanced Idle State Protocol ........................................ 18-68 14

18.63 Unsuccessful Enhanced Idle State Protocol due to AN rejection ........................... 18-69 15

18.64 SlottedMode Attribute Negotiation for Enhanced Idle State Protocol ..................... 18-70 16

18.65 Channel Hashing during Enhanced Idle State Protocol .......................................... 18-72 17

18.66 Channel Hashing during Enhanced Idle State Protocol - Hashing to AN 2 Only .... 18-73 18

18.67 QoS Signaling upon PPP resynchronization ........................................................... 18-74 19

18.68 AT behavior upon Rejection of Reservation Request by AN .................................. 18-76 20

18.69 AT behavior upon Receiving ProfileType set to NULL............................................ 18-77 21

18.70 ReservationKKIdleStateFwd and ReservationKKIdleStateRev set to 0 ................. 18-78 22

18.71 ReservationKKIdleState set to 1 ............................................................................. 18-79 23


18.73 DRC Supervision Failure ......................................................................................... 18-83 25

18.74 Soft Handoff during DRC Supervision Timeout State ............................................. 18-84 26

18.75 DRC Supervision with MultiUserPacketsEnabled ................................................... 18-85 27

18.76 DRCTranslationOffset Verification .......................................................................... 18-86 28

18.77 DSC and DRC compliance during Soft handoff ...................................................... 18-87 29

18.78 DRC Compliance During Softer Handoff ................................................................ 18-88 30

18.79 MUP and Non Canonical SUP decoding by AT ...................................................... 18-89 31

18.80 Enhanced Control Channel Short MAC Packet ...................................................... 18-90 32

3GPP2 C.S0044-D v1.0

xi

18.81 Enhanced Access Channel Probe Transmission .................................................... 18-92 1

18.82 RTC Interlace re-ordering with Subtype 3 RTCMAC .............................................. 18-95 2

18.83 Configuration of non-default attributes for Subtype 3 RTCMAC ............................. 18-96 3

18.84 MultiATPage message .......................................................................................... 18-108 4

18.85 LoadInformation message ..................................................................................... 18-109 5

18.86 Single Carrier Multi-Link ........................................................................................ 18-110 6

19 xHRPD ............................................................................................................................... 19-1 7

19.1 xHRPD Acquisition and Idle Mode Operation ........................................................... 19-1 8

19.2 xHRPD Session Establishment ................................................................................. 19-1 9

19.3 xHRPD Session Configuration and Management with Subnet change .................... 19-1 10

19.4 AT Color Code and UATI24 ...................................................................................... 19-1 11

19.5 xHRPD Connection Setup ........................................................................................ 19-1 12

19.6 AN Packet Data Inactivity Timer ............................................................................... 19-1 13

19.7 Reserved ................................................................................................................... 19-2 14

19.8 Reserved ................................................................................................................... 19-2 15

19.9 Reserved ................................................................................................................... 19-2 16

19.10 RLP Operation in Severely Degraded Channel ........................................................ 19-2 17

19.11 Reserved ................................................................................................................... 19-3 18

19.12 xHRPD Control Channel Monitoring and Overhead Message Updates ................... 19-3 19

19.13 Control Channel Rate ................................................................................................ 19-3 20

19.14 xHRPD ConnectionDeny ........................................................................................... 19-3 21

19.15 xHRPD Keep Alive Mechanism ................................................................................. 19-3 22

19.16 Reserved ................................................................................................................... 19-3 23

19.17 Reserved ................................................................................................................... 19-3 24

19.18 Intra-band xHRPD-xHRPD System Re-selection (Idle State) ................................... 19-3 25

19.19 Inter-band xHRPD-xHRPD System Re-selection (Idle State) ................................... 19-4 26

19.20 xHRPD Terminal Authentication ............................................................................... 19-4 27

19.21 PPP Session in Adverse Conditions - Disconnect cable between AT and PC. ........ 19-4 28

19.22 Reserved ................................................................................................................... 19-5 29

19.23 Reserved ................................................................................................................... 19-5 30

19.24 Idle State Channel Hashing ...................................................................................... 19-5 31

19.25 Reserved ................................................................................................................... 19-6 32

3GPP2 C.S0044-D v1.0

xii

19.26 Typical xHRPD Session Configuration...................................................................... 19-6 1

19.27 Multiple Reservations bound to one RLP .................................................................. 19-7 2

19.28 Maximum Open Reservations, Activated RLP and MAC flows ................................ 19-9 3

19.29 QoS Release upon PDSN initiated LCP termination .............................................. 19-10 4

19.30 QoS Release upon AT Initiated PPP Termination .................................................. 19-11 5

19.31 Reserved ................................................................................................................. 19-12 6

19.32 AT Data Over Signaling Message Transmission .................................................... 19-12 7

19.33 AN Data Over Signaling Message Transmission .................................................... 19-14 8

19.34 Voice Origination in xHRPD Idle Mode ................................................................... 19-15 9

19.35 Voice Termination in xHRPD Idle Mode ................................................................. 19-16 10

19.36 Reserved ................................................................................................................. 19-17 11

19.37 Reserved ................................................................................................................. 19-17 12

19.38 Voice Origination in xHRPD Active Mode ............................................................... 19-17 13

19.39 Voice Termination in xHRPD Active Mode ............................................................. 19-19 14

19.40 Reserved ................................................................................................................. 19-21 15

19.41 Reserved ................................................................................................................. 19-21 16

19.42 Reserved ................................................................................................................. 19-21 17

19.43 Reserved ................................................................................................................. 19-21 18

19.44 Reserved ................................................................................................................. 19-21 19

19.45 Reserved ................................................................................................................. 19-21 20

19.46 Reserved ................................................................................................................. 19-21 21

19.47 Reserved ................................................................................................................. 19-21 22

19.48 Reserved ................................................................................................................. 19-21 23

19.49 Reserved ................................................................................................................. 19-21 24

19.50 Reserved ................................................................................................................. 19-21 25

19.51 Reserved ................................................................................................................. 19-21 26

19.52 Reserved ................................................................................................................. 19-21 27

19.53 Inter RNC Dormant Hand-off (xHRPD to xHRPD) .................................................. 19-21 28

19.54 Reserved ................................................................................................................. 19-22 29

19.55 Reserved ................................................................................................................. 19-22 30

19.56 Reserved ................................................................................................................. 19-22 31

19.57 Reserved ................................................................................................................. 19-22 32

3GPP2 C.S0044-D v1.0

xiii

19.58 Reserved ................................................................................................................. 19-22 1

19.59 Reserved ................................................................................................................. 19-22 2

19.60 RLP Activation ......................................................................................................... 19-22 3

19.61 QoS Set Up ............................................................................................................. 19-24 4

19.62 Reserved ................................................................................................................. 19-27 5

19.63 Reserved ................................................................................................................. 19-27 6

19.64 Reserved ................................................................................................................. 19-27 7

19.65 Reserved ................................................................................................................. 19-27 8

19.66 Reserved ................................................................................................................. 19-27 9

19.67 QoS Signaling upon PPP resynchronization ........................................................... 19-27 10

19.68 AT behavior upon Rejection of Reservation Request by AN .................................. 19-28 11

19.69 AT behavior upon Receiving ProfileType set to NULL............................................ 19-29 12

19.70 ReservationKKIdleStateFwd and ReservationKKIdleStateRev set to 0 ................. 19-30 13



19.73 CQI Supervision Failure .......................................................................................... 19-34 16

19.74 Reserved ................................................................................................................. 19-36 17

19.75 Reserved ................................................................................................................. 19-36 18

19.76 Reserved ................................................................................................................. 19-36 19

19.77 Reserved ................................................................................................................. 19-36 20

19.78 Reserved ................................................................................................................. 19-36 21

19.79 Reserved ................................................................................................................. 19-36 22

19.80 Enhanced Control Channel Short MAC Packet ...................................................... 19-36 23

19.81 Access Channel Probe Transmission ..................................................................... 19-38 24

19.82 Reserved ................................................................................................................. 19-40 25

19.83 Reserved ................................................................................................................. 19-40 26

19.84 Reserved ................................................................................................................. 19-40 27

19.85 Reserved ................................................................................................................. 19-40 28

19.86 Reserved ................................................................................................................. 19-40 29

19.87 Inter Technology Switching in Idle Mode – xHRPD to LTE .................................... 19-40 30

19.88 Inter Technology Switching in Idle Mode – xHRPD to HRPD ................................. 19-41 31

19.89 Concurrent Voice and Data Service ........................................................................ 19-43 32

3GPP2 C.S0044-D v1.0

xiv

19.90 CALEA Requirement in Idle State ........................................................................... 19-44 1

20 Annex A – Figures (Normative) ......................................................................................... 20-1 2

21 Annex B (Normative) .......................................................................................................... 21-1 3

21.1 Annex B.1 Power Ratios for Common and Traffic Channels .................................... 21-1 4

21.2 Annex B.2 CDMA Equations ..................................................................................... 21-5 5

21.3 Annex B.3 Message Parameter Values .................................................................... 21-8 6

22 Annex C - Protocol Capability Response Message Feature Identifiers (Normative) ......... 22-1 7

23 Annex D Data Services Tests (Informative) ....................................................................... 23-1 8

23.1 Data Services Annex D.1: References .................................................................... 23-1 9

23.2 Data Services Annex D.2: Description of Compressible Test Data Files ................ 23-1 10

23.3 Data Services Annex D.3: Standard ITU Fax Pages ............................................... 23-1 11

23.4 Data Services Annex D.4: Test Files ....................................................................... 23-2 12

24 Annex E: TTY/TDD Test Examples (Informative) .............................................................. 24-1 13

14

3GPP2 C.S0044-D v1.0

xv

FOREWORD 1

Introduction 2

This foreword is not part of this document. This specification defines air interface interoperability 3 tests for CDMA/HRPD/xHRPD mobile stations/access terminals. It is applicable to 4 P_REV_IN_USE equal to or less than seven and/or access terminals supporting revision A of [24] 5

In this document, ‘mobile station’ or ‘access terminal’ (AT) refers to a subscriber terminal, 6 handset, PDA, wireless local loop unit, or any other CDMA/HRPD/xHRPD subscriber terminal 7 that communicates with the base station at the air interface. ‘Base station’ or ‘access network’ 8 refers to the composite functionality of the base station and connected network elements. A 9 cabled connection is typically used for the air interface connection between the mobile station and 10 base station. 11

Testing Objective 12

The objective of these tests is to demonstrate mobile station interoperability with base station 13 equipment compliant to the cdma2000

®1 family of standards. References to the applicable 14

standard functionality are listed in the traceability section of each test case. 15

Execution Strategy 16

All features supported by the base station, such as Signaling Message Encryption, 17 Authentication, Voice Privacy, etc. should be enabled. 18

All applicable tests should be executed for all supported Band Classes and Radio Configurations. 19

The following general comments apply to all tests: 20

a. Whenever common channels and/or traffic channels are required to perform a test, and 21

their power ratios are not specified in the test, the power ratios specified in Annex B 22

should be used. Adjust the Orthogonal Channel Noise Simulator (OCNS) gain such that 23

power ratios (Ec/Ior) of all specified forward channels add up to one. If OCNS is not 24

available, the levels of code channels and attenuators should be adjusted to maintain 25

proper test parameters. 26

b. During handoff tests between sectors of the same cell, Channel 2 from the beta sector 27

shall have a maximum relative offset of 1 µs from Channel 1 of the alpha sector at the 28

mobile station antenna connector. 29

c. During soft and intersector handoff tests, the neighbor list of the base station in the test 30

shall include PN offsets of the other base station in the test. 31

1 cdma2000

® is the trademark for the technical nomenclature for certain specifications and

standards of the Organizational Partners (OP’s) of 3GPP2. Geographically (and as of the date of

publication), cdma2000® is a registered trademark of the Telecommunications Industry

Association (TIA-USA) in the United States.

3GPP2 C.S0044-D v1.0

xvi

d. Pilot PN sequence offsets are denoted by Pi (i=1, 2, 3...). The following are assumed 1

unless otherwise specified: 2

• 0 <= Pi <= 511 3

• Pi not equal to Pj if i not equal to j 4

• Pi mod PILOT_INC = 0 5

e. Base stations should be configured for normal operation as specified in [2] unless 6

otherwise specified in a specific test. 7

f. Unless otherwise specified, the Reverse Traffic Channel should be operated at a 8

sufficiently high Eb/No to ensure insignificant (for example, less than 1%) frame error 9

rate (FER). 10

g. Overhead message fields should be those required for normal operation of the base 11

station unless otherwise specified in Annex B tables or in a specific test. 12

h. Values of time limits and other constants should be as specified in Annex B. 13

Supplementary Terms and Definitions 14

15 AC - See Authentication Center. 16

ACCOLC – Access Overload Class 17

Access Attempt - A sequence of one or more access probe sequences on the Access Channel 18 containing the same message. See also Access Probe and Access Probe Sequence. 19

Access Channel - A Reverse CDMA Channel used by mobile stations for communicating to the 20 base station. The Access Channel is used for short signaling message exchanges such as call 21 originations, responses to pages, and registrations. The Access Channel is a slotted random 22 access channel. 23

Access Channel Message - The information part of an access probe consisting of the message 24 body, length field, and CRC. 25

Access Channel Response Message - A message on the Access Channel generated to reply to 26 a message received from the base station. 27

Acknowledgment - A Layer 2 response by the mobile station or the base station confirming that 28 a signaling message was received correctly. 29

Action Time - The time at which the action implied by a message should take effect. 30

Active Set - The set of pilots associated with the CDMA Channels containing Forward Traffic 31 Channels assigned to a particular mobile station. 32

Advanced Forward Link Trilateration (AFLT) - A geolocation technique that utilizes the mobile 33 station’s measured time-difference-of-arrival of radio signals from the base stations (and, 34 possibly, other terrestrial measurements). 35

A-key - A secret, 64-bit pattern stored in the mobile station and HLR/AC. It is used to 36 generate/update the mobile station’s Shared Secret Data. 37

AMPS – Advanced Mobile Phone Service 38

AN- Access Network 39

3GPP2 C.S0044-D v1.0

xvii

Assured Mode - Mode of delivery that guarantees (if a loss of channel is not declared) that a 1 PDU will be delivered to the peer. A PDU sent in assured mode is retransmitted by the LAC 2 sublayer, up to a maximum number of retransmissions, until the LAC entity at the sender receives 3 an acknowledgement for the PDU. See also Confirmation of Delivery. 4

AT – 1. Attention (condition in modem control). 2. Access Terminal 5

Authentication - A procedure used by a base station to validate a mobile station’s identity. 6

Authentication Center (AC) - An entity that manages the authentication information related to 7 the mobile station. 8

Autonomous Registration - A method of registration in which the mobile station registers 9 without an explicit command from the base station. 10

AWGN - Additive White Gaussian Noise. 11

Band Class - A set of frequency channels and a numbering scheme for these channels. 12

Base Station - A fixed station used for communicating with mobile stations. In this document, the 13 term base station refers to the entire cellular system infrastructure including transceiver 14 equipment and Mobile Switching Center. 15

bps - Bits per second. 16

BS – See base station. 17

Candidate Frequency - The frequency for which the base station specifies a search set, when 18 searching on other frequencies while performing mobile-assisted handoffs. 19

Candidate Set - The set of pilots that have been received with sufficient strength by the mobile 20 station to be successfully demodulated, but have not been placed in the Active Set by the base 21 station. See also Active Set, Neighbor Set, and Remaining Set. 22

CC – Channel Configuration 23

CCI – Base station Configuration Change Indicator (sent on QPCH) 24

CDMA - See Code Division Multiple Access. 25

Candidate Frequency - The Candidate Frequency specified for a search of CDMA pilots. 26

CDMA Channel - The set of channels transmitted between the base station and the mobile 27 stations within a given CDMA frequency assignment. See also Forward CDMA Channel and 28 Reverse CDMA Channel. 29

CFNA – Call Forwarding No Answer 30

Chip - See PN Chip. 31

CMT – Cellular Messaging Teleservice 32

CAN – Calling Party Name 33

CNAP – Calling Name Presentation 34

CNI – Calling Number Identification 35

Code Channel - A subchannel of a Forward CDMA Channel. A Forward CDMA Channel contains 36 64 code channels. Code channel zero is assigned to the Forward pilot channel. Code channels 1 37 through 7 may be assigned either to the Paging Channels or to the Traffic Channels. Code 38 channel 32 may be assigned either to a Sync Channel or to a Traffic Channel. The remaining 39 code channels may be assigned to Traffic Channels. 40

Code Division Multiple Access (CDMA) - A technique for spread-spectrum multiple-access 41 digital communications that creates channels through the use of unique code sequences. 42

3GPP2 C.S0044-D v1.0

xviii

Configuration Change Indicator - A one-bit datum sent on the Quick Paging Channel. 1 Appearance of the Configuration Change Indicator in the Quick Paging Channel serves to alert a 2 slotted mode mobile station, operating in the idle state, that, after performing an idle handoff, it 3 should monitor the Paging Channel, in order to determine if it should update its stored 4 parameters. 5

Confirmation of Delivery - A notification sent by the LAC sublayer to Layer 3 at the sender, 6 when the LAC entity at the sender receives the acknowledgment for a specific PDU sent in 7 assured mode. 8

CPN – Calling Party Number 9

CPT – Cellular Paging Teleservice 10

CRC - See Cyclic Redundancy Code. 11

Cyclic Redundancy Code (CRC) - A class of linear error detecting codes which generate parity 12 check bits by finding the remainder of a polynomial division. 13

dBm - A measure of power expressed in terms of its ratio to one milliwatt. 14

Dedicated Control Channel - A portion of a Traffic Channel (Forward or Reverse) that carries a 15 combination of user data, signaling, and power control information. 16

Distance-Based Registration - An autonomous registration method in which the mobile station 17 registers whenever it enters a cell whose distance from the cell in which the mobile station last 18 registered exceeds a given threshold. 19

DTMF - See Dual-Tone Multifrequency 20

Dual-Tone Multifrequency (DTMF) - Signaling by the simultaneous transmission of two tones, 21 one from a group of low frequencies and another from a group of high frequencies. Each group of 22 frequencies consists of four frequencies. 23

Eb - Average energy per information bit for the Sync Channel, Paging Channel, or Forward Traffic 24

Channel at the mobile station antenna connector. 25

Eb/No - Energy-per-bit-to noise-per-hertz ratio. 26

Eb/N

t - The ratio of the combined received energy per bit to the effective noise power spectral 27

density for the Sync Channel, Paging Channel, or Forward Traffic Channel at the mobile station 28 antenna connector. 29

Ec - Average energy per PN chip for the Forward pilot channel, Sync Channel, Paging Channel, 30

Forward Traffic Channel, power control subchannel, or OCNS. 31

Ec/Io - A notation used to represent a dimensionless ratio of the average power of some code-32 distinguished CDMA signal channel, typically a pilot, to the total power comprised of signal plus 33 interference, within the signal bandwidth. It is usually expressed in dB units. 34

Ec/Ior

- The ratio of the average transmit energy per PN chip for the Forward pilot channel, Sync 35

Channel, Paging Channel, Forward Traffic Channel, power control subchannel, or OCNS to the 36 total transmit power spectral density. 37

Erasure Indicator Bit (EIB)- A bit used in the Rate Set 2 Reverse Traffic Channel frame 38 structure to indicate an erased Forward Fundamental Code Channel or Forward Dedicated 39 Control Channel frame. 40

ESN - Electronic Serial Number 41

f-csch - Forward common signaling logical channel. 42

f-dsch - Forward dedicated signaling logical channel. 43

3GPP2 C.S0044-D v1.0

xix

FER - Frame Error Rate of Forward Traffic Channel. The value of FER may be estimated by 1 using Service Option 2, 9, 30, or 31 (see TIA/EIA-126-C). 2

FFPC – Fast Forward Power Control 3

Flash - An indication sent on the CDMA Channel indicating that the receiver is to invoke special 4 processing. 5

Forward CDMA Channel - A CDMA Channel from a base station to mobile stations. The 6 Forward CDMA Channel contains one or more code channels that are transmitted on a CDMA 7 frequency assignment using a particular pilot PN offset. The code channels are associated with 8 the Forward pilot channel, Sync Channel, Paging Channels, and Traffic Channels. The Forward 9 CDMA Channel always carries a Forward pilot channel and may carry up to one Sync Channel, 10 up to seven Paging Channels, and up to 63 Traffic Channels, as long as the total number of 11 channels, including the Forward pilot channel, is no greater than 64. 12

F-CCCH - Forward Common Control Channel 13

Forward Dedicated Control Channel (F-DCCH) - A portion of a Forward Traffic Channel that 14 can carry a combination of primary data, secondary data, signaling, and power control 15 information. 16

Forward Fundamental Channel (F-FCH) - A portion of a Forward Traffic Channel that can carry 17 a combination of primary data, secondary data, signaling, and power control information. 18

Forward Pilot Channel (F-PICH) - A non-data-bearing direct-sequence spread spectrum signal 19 transmitted continuously by each CDMA base station. The Forward Pilot Channel allows a mobile 20 station to acquire the timing of the Forward CDMA Channel, provides a phase reference for 21 coherent demodulation, and provides a means for signal strength comparisons between base 22 stations for determining when to handoff. Different base stations are identified by different pilot 23 PN sequence time phases. See also Pilot PN Sequence, Pilot PN Sequence Offset. 24

Forward Supplemental Channel (F-SCH) - An optional portion of a Forward Traffic Channel 25 (Radio Configurations 3 and above) that operates in conjunction with a Fundamental Channel 26 and or the Dedicated Control Channel in that Traffic Channel, and (optionally) with other 27 Supplemental Channels to provide higher data rate services. 28

Forward Supplemental Code Channel (F-SCCH) - An optional portion of a Forward Traffic 29 Channel (Radio Configurations 1 and 2) that operates in conjunction with a Fundamental Channel 30 in that Traffic Channel, and (optionally) with other Supplemental Code Channels to provide higher 31 data rate services. 32

Forward Traffic Channel - A code channel used to transport user and signaling traffic from a 33 base station to a mobile station. 34

FPC – Forward Power Control 35

Frame - A basic timing interval in the system. For the Access Channel and Paging Channel a 36 frame is 20 ms long. For the Traffic Channel, the frame may be 20 ms or 5 ms long. For the Sync 37 Channel, a frame is 26.666... ms long. 38

Frame Offset - A time skewing of Traffic Channel frames from System Time in integer multiples 39 of 1.25 ms. The maximum frame offset is 18.75 ms. 40

FTP- File Transfer Protocol 41

GHz - Gigahertz (109 Hertz). 42

Global Positioning System (GPS) - A US government satellite system that provides location 43 and time information to users. See Navstar GPS Space Segment / Navigation User Interfaces 44 ICD-GPS-200 for specifications. 45

Good Frames - Frames not classified as bad frames. See also Bad Frames. 46

3GPP2 C.S0044-D v1.0

xx

Good Message - A received message is declared a good message if it is received with a correct 1 CRC. 2

GPS - Global Positioning System 3

Handoff - The act of transferring communication with a mobile station from one base station to 4 another. 5

Hard Handoff - A handoff characterized by a temporary disconnection of the Traffic Channel. 6 Hard handoffs occur when the mobile station is transferred between disjoint Active Sets, the 7 CDMA frequency assignment changes, the frame offset changes, or the mobile station is directed 8 from a CDMA Traffic Channel to an AMPS voice channel. See also Soft Handoff. 9

Hash Function - A function used by the mobile station to select one out of N available resources. 10 The hash function distributes the available resources uniformly among a random sample of 11 mobile stations. 12

Hopping Pilot Beacon - A pilot beacon that changes CDMA Frequency periodically to simulate 13 multiple base stations operating on different frequencies. The transmission of the hopping pilot 14 beacon is discontinuous on any CDMA Channel. 15

HRPD – High Rate Packet Data 16

HSPD – High Speed Packet Data 17

Idle Handoff - The act of transferring reception of the Paging Channel from one base station to 18 another, when the mobile station is in the Mobile Station Idle State. 19

IMSI - See International Mobile Station Identity 20

IMSI_M - MIN-based IMSI using the lower 10 digits to store the MIN. 21

IMSI_O - Operational value of IMSI used by the mobile station for operation with the base station. 22

IMSI_T - True IMSI not associated with MIN. This could be 15 digits or fewer. 23

IMSI_T_S – Supplement of MIN-based IMSI 24

International Mobile Station Identity (IMSI) - A method of identifying stations in the land mobile 25 service as specified in ITU-T Recommendation E.212. 26

Io - The total received power spectral density, including signal and interference, as measured at 27

the mobile station antenna connector. 28

Ioc

- The power spectral density of a band-limited white noise source (simulating interference from 29

other cells) as measured at the mobile station antenna connector. 30

Ior

- The total transmit power spectral density of the Forward CDMA Channel at the base station 31

antenna connector. 32

Îor

- The received power spectral density of the Forward CDMA Channel as measured at the 33

mobile station antenna connector. 34

ITU – International Telecommunication Union 35

IWF – Inter-Working Function 36

LAC – Link Access Control 37

Layering - A method of organization for communication protocols in which the transmitted or 38 received information is transferred in pipeline fashion, within each station, in well-defined 39 encapsulated data units between otherwise decoupled processing entities (“layers”). A layer is 40 defined in terms of its communication protocol to a peer layer in another entity and the services it 41 offers to the next higher layer in its own entity. 42

3GPP2 C.S0044-D v1.0

xxi

Layer 1 - Layer 1 provides for the transmission and reception of radio signals between the base 1 station and the mobile station. Also see Physical Layer. 2

Layer 2 - Layer 2 provides for the correct transmission and reception of signaling messages, 3 including partial duplicate detection. Layer 2 makes use of the services provided by Layer 1. 4

Layer 3 - Layer 3 provides the control messaging for the cellular or PCS telephone system. Layer 5 3 originates and terminates signaling messages according to the semantics and timing of the 6 communication protocol between the base station and the mobile station. Layer 3 makes use of 7 the services provided by Layer 2. 8

Long Code - A PN sequence with period (242

) - 1 that is used for scrambling on the Forward 9 CDMA Channel and spreading on the Reverse CDMA Channel. The long code uniquely identifies 10 a mobile station on both the Reverse Traffic Channel and the Forward Traffic Channel. The long 11 code provides limited privacy. The long code also separates multiple Access Channels on the 12 same CDMA Channel. See also Public Long Code and Private Long Code. 13

Long Code Mask - A 42-bit binary number that creates the unique identity of the long code. See 14 also Public Long Code, Private Long Code, Public Long Code Mask, and Private Long Code 15 Mask. 16

LSPD – Low Speed Packet Data 17

MAC – Medium Access Control 18

MC – Message Center 19

MCC - See Mobile Country Code 20

MCSB - See Message Control and Status Block 21

MDR – Medium Data Rate 22

Mean Input Power - The total received calorimetric power measured in a specified bandwidth at 23 the antenna connector, including all internal and external signal and noise sources. 24

MHz - Megahertz (106 Hertz). 25

MIN/MSIN - See Mobile Identification Number 26

MNC - See Mobile Network Code 27

MO – Multiplex Option 28

MOB_P_REV – Protocol revision number supported by a mobile station 29

Mobile Country Code (MCC) - A part of the E.212 IMSI identifying the home country. See ITU-T 30 Recommendation E.212. 31

Mobile Directory Number - A dialable directory number that is not necessarily the same as the 32 mobile station’s air interface identification, i.e., MIN, IMSI_M or IMSI_T. 33

Mobile Identification Number (MIN) - The 34-bit number that is a digital representation of the 34 10-digit number assigned to a mobile station. 35

Mobile Network Code (MNC) - A part of the E.212 IMSI identifying the home network within the 36 home country. See ITU-T Recommendation E.212. 37

Mobile Station (MS) - A station that communicates with a base station while in motion or during 38 halts at unspecified points. 39

Mobile Station Identification Number (MSIN) - A part of the E.212 IMSI identifying the mobile 40 station within its home network. See ITU-T Recommendation E.212. 41

Mobile Station Originated Call - A call originating from a mobile station. 42

3GPP2 C.S0044-D v1.0

xxii

Mobile Station Terminated Call - A call received by a mobile station (not to be confused with a 1 disconnect or call release). 2

MS – Mobile Station 3

MSC - See Mobile Switching Center 4

MSIN - See Mobile Station Identification Number 5

MSPD – Medium Speed Packet Data 6

Mobile Switching Center (MSC) - A configuration of equipment that provides radiotelephone 7 service. Also called the Mobile Telephone Switching Office (MTSO). 8

Multiplex Sublayer - One of the conceptual layers of the system that multiplexes and 9 demultiplexes signaling traffic and various connected user traffic. 10

MWI – Message Waiting Indicator 11

NAK- Negative Acknowledgement 12

NAM - See Number Assignment Module 13

National Mobile Station Identity (NMSI) - A part of the E.212 IMSI identifying the mobile station 14 within its home country. The NMSI consists of the MNC and the MSIN. See ITU-T 15 Recommendation E.212. 16

NDSS - See Network Directed System Selection. 17

Neighbor Set - The set of pilots associated with the CDMA Channels that are probable 18 candidates for handoff. Normally, the Neighbor Set consists of the pilots associated with CDMA 19 Channels that cover geographical areas near the mobile station. See also Active Set, Candidate 20 Set, Remaining Set, and Private Neighbor Set. 21

Network - A network is a subset of a cellular or PCS system, such as an area-wide cellular 22 network, a private group of base stations, or a group of base stations set up to handle a special 23 requirement. A network can be as small or as large as needed, as long as it is fully contained 24 within a system. See also System. 25

Network Directed System Selection (NDSS) - A feature that allows the mobile station to 26 automatically register with a preferred system while roaming, or to be automatically directed by a 27 service provider, typically the home service provider, to a suggested system, regardless of the 28 frequency band class, cellular band, or PCS frequency block. 29

Network Identification (NID) - A number that uniquely identifies a network within a cellular or 30 PCS system. See also System Identification. 31

NID - See Network Identification 32

NMSI - See National Mobile Station Identity 33

NNSCR – Non-negotiable Service Configuration Record 34

Non-Slotted Mode - An operation mode of the mobile station in which the mobile station 35 continuously monitors the Paging Channel. 36

ns - Nanosecond (10-9

second). 37

Nt - The effective noise power spectral density at the mobile station antenna connector. 38

NULL - Any value that is not in the specified range of a field. 39

Number Assignment Module (NAM) - A set of MIN/IMSI-related parameters stored in the 40 mobile station. 41

OA&M – Operation, Administration and Maintenance 42

OCNS – See Orthogonal Channel Noise Simulator 43

3GPP2 C.S0044-D v1.0

xxiii

OCNS Ec - Average energy per PN chip for the OCNS. 1

Ior

Ec OCNS - The ratio of the average transmit energy per PN chip for the OCNS to the total 2

transmit power spectral density. 3

OLPC – Outer Loop Power Control 4

OOK – On/Off keying 5

Order - A type of message that contains control codes for either the mobile station or the base 6 station. 7

Orthogonal Channel Noise Simulator (OCNS) - A hardware mechanism used to simulate the 8 users on the other orthogonal channels of a Forward CDMA Channel. 9

Orthogonal Transmit Diversity (OTD) - An optional method of transmission of the Forward 10 CDMA Channel that uses two antennas, each transmitting a fraction of the code symbols. It can 11 be used to enhance performance in the presence of multipath fading radio propagation. 12

OTAF – Over-the-air Function 13

OTAPA – Over-the-air Parameter Administration 14

OTASP – Over-the-air Service Programming 15

OTD - See Orthogonal Transmit Diversity 16

OUNS – Other User Noise Simulator Overhead Message - A message sent by the base station 17 on the Paging Channel to communicate base-station-specific and system-wide information to 18 mobile stations. 19

P_REV – Protocol revision level supported by a base station 20

P_REV_IN_USE – Protocol revision level currently in use by a mobile station 21

PACA - Priority Access and Channel Assignment. See PACA Call. 22

PACA Call - A priority mobile station originated call for which no traffic channel or voice channel 23 was immediately available, and which has been queued for a priority access channel assignment. 24

Packet - The unit of information exchanged between the service option applications of the base 25 station and the mobile station. 26

Paging - The act of seeking a mobile station when a call has been placed to that mobile station. 27

Paging Channel - A code channel in a CDMA channel used for transmission of control 28 information and pages from a base station to a mobile station. 29

Paging Channel Slot - An 80 ms interval on the Paging Channel. Mobile stations operating in the 30 slotted mode are assigned specific slots in which they monitor messages from the base station. 31

Paging Ec - Average energy per PN chip for the Paging Channel 32

Ior

Ec Paging - The ratio of the average transmit energy per PN chip for the Paging Channel to the 33

total transmit power spectral density. 34

Paging Indicator - A one-bit datum sent on the Quick Paging Channel. Quick paging indicators 35 are associated with mobile stations, in pairs, via a hashing algorithm. Appearance of both of its 36 indicators in its assigned Quick Paging Channel slot serves to alert a slotted mode mobile station, 37 operating in the idle state, that it should monitor the Paging Channel starting in the next slot. See 38 also Quick Paging Channel. 39

3GPP2 C.S0044-D v1.0

xxiv

Parameter-Change Registration - A registration method in which the mobile station registers 1 when certain of its stored parameters change. 2

PCF – Packet Control Function 3

PCS - See Personal Communications Services 4

PCS System - See Personal Communications Services System 5

PDU - See Protocol Data Unit 6

Personal Communications Services (PCS) - A family of mobile and portable radio 7 communications services for individuals and businesses that may be integrated with a variety of 8 competing networks. Broadcasting is prohibited and fixed operations are to be ancillary to mobile 9 operations. 10

Personal Communication Services System - A configuration of equipment that provides PCS 11 radiotelephone services 12

Personal Communications Switching Center (PCSC) - See Mobile Switching Center (MSC) 13

Physical Channel - A communication path between stations, described in terms of the RF 14 characteristics such as coding, power control policies, etc. 15

Physical Layer - The part of the communication protocol between the mobile station and the 16 base station that is responsible for the transmission and reception of data. The physical layer in 17 the transmitting station is presented a frame by the multiplex sublayer and transforms it into an 18 over-the-air waveform. The physical layer in the receiving station transforms the waveform back 19 into a frame and presents it to the multiplex sublayer above it. 20

PI – See Paging Indicator 21

Pilot Beacon - A transmit-only base station that broadcasts a Forward pilot channel, a Sync 22 Channel, optionally a Paging Channel, but no Forward Traffic Channels. The mobile station 23 measures the pilot beacon to assist in CDMA hard handoffs and inter-frequency idle-mode 24 handoffs. 25

Pilot Ec - Average energy per PN chip for the Forward pilot channel 26

Pilot Io

Ec - The ratio of the combined pilot energy per chip, Ec, to the total received power 27

spectral density (noise and signals), Io, of at most K usable multipath components at the mobile 28

station antenna connector (see 1.4). K is the number of demodulating elements supported by the 29 mobile station. 30

Ior

Ec Pilot - The ratio of the average transmit energy per PN chip for the Forward pilot channel to 31

the total transmit power spectral density. 32

Pilot PN Sequence - A pair of modified maximal length PN sequences with period 215

PN chips 33 used to spread the Forward CDMA Channel and the Reverse CDMA Channel. Different base 34 stations are identified by different pilot PN sequence offsets. 35

Pilot PN Sequence Offset - The time offset of a Forward Pilot Channel from CDMA System time, 36 as transmitted by the base station, expressed modulo the pilot period. 37

Pilot PN Sequence Offset Index - The pilot PN sequence offset in units of 64 PN chips of a 38 Forward Pilot Channel, relative to the zero offset pilot PN sequence. 39

Pilot Strength - The ratio of pilot power to total power in the signal bandwidth of a CDMA 40 Forward or Reverse Channel. See also Ec/Io. 41

PM – Privacy Mode 42

3GPP2 C.S0044-D v1.0

xxv

PN - Pseudonoise 1

PN Chip - One bit in a PN sequence, or the time duration of such a bit. It corresponds to the 2 smallest modulation interval in a CDMA system. 3

PN Sequence – Pseudo-random noise sequence. A deterministic, periodic binary sequence 4 having limited statistical similarity to a Bernoulli (coin-tossing). 5

Power Control Bit - A bit sent in every 1.25 ms interval on the Forward Traffic Channel that 6 signals the mobile station to increase or decrease its transmit power. 7

Power Control Ec - Average energy per PN chip for the power control subchannel. For the case 8

when the power control sub-channel is assumed to be transmitted at the same power level that is 9 used for the 9600 bps or 14400 bps data rate, the following equations apply: For Rate Set 1, it is 10

equal to v11

v

x (total Forward Traffic Channel energy per PN chip), where v equals 1 for 9600 11

bps, v equals 2 for 4800 bps, v equals 4 for 2400 bps, and v equals 8 for 1200 bps traffic data 12

rate. For Rate Set 2, it is equal to v23

v

x (total Forward Traffic Channel energy per PN chip), 13

where v equals 1 for 14400 bps, v equals 2 for 7200 bps, v equals 4 for 3600 bps, and v equals 8 14 for 1800 bps traffic data rate. The total Forward Traffic Channel is comprised of traffic data and a 15 power control sub-channel. 16

v23

v

- The ratio of the average transmit energy per PN chip for the power control subchannel 17

to the total transmit power spectral density. 18

Power Control Group - A 1.25 ms interval on the Forward Traffic Channel and the Reverse 19 Traffic Channel. See also Power Control Bit. 20

Power-Down Registration - An autonomous registration method in which the mobile station 21 registers on power-down. 22

Power-Up Registration - An autonomous registration method in which the mobile station 23 registers on power-up. 24

PPP – Point-to-Point Protocol 25

Preamble - See Access Channel Preamble and Traffic Channel Preamble 26

Primary Traffic - The main traffic stream carried between the mobile station and the base station 27 on the Traffic Channel. See also Secondary Traffic and Signaling Traffic. 28

Private Long Code - The long code characterized by the private long code mask. See also Long 29 Code. 30

Private Long Code Mask - The long code mask used to form the private long code. See also 31 Public Long Code Mask and Long Code. 32

Private Neighbor Set - The set of pilots associated with the private system base stations that are 33 probable candidates for idle handoff. See also Active Set, Neighbor Set, Remaining Set, and 34 CDMA Tiered Services. 35

Protocol Data Unit - Encapsulated data communicated between peer layers on the mobile 36 station and base station. Unless specified otherwise, in this document PDU refers to the Layer 3 37 protocol data unit transferred at the interface between layer 3 and layer 2. 38

Protocol Stack - Conceptual model of the layered architecture for communication protocols (see 39 Layering) in which layers within a station are represented in the order of their numeric designation 40 and requiring that transferred data be processed sequentially by each layer, in the order of their 41

3GPP2 C.S0044-D v1.0

xxvi

representation. Graphically, the “stack” is drawn vertically, with the layer having the lowest 1 numeric designation at the base. 2

PSIST – Persistence Delay 3

Public Long Code - The long code characterized by the public long code mask. 4

Public Long Code Mask – The long code mask used to form the public long code. The mask 5 contains a permutation of the bits of the ESN, and also includes the channel number when used 6 for a Supplemental Code Channel. See also Private Long Code Mask and Long Code. 7

Public Safety Answering Point (PSAP) - A dispatch office that receives emergency calls from 8 the public. 9

PSTN – Public Switching Telephone Network 10

QPCH – See Quick Paging Channel 11

Quick Paging - A feature that permits mobile stations to further conserve battery power beyond 12 the savings achieved by slotted mode operation. See also Paging Indicator and Configuration 13 Change Indicator. 14

Quick Paging Channel (QPCH)- An uncoded, on-off-keyed (OOK) spread spectrum signal sent 15 by base stations to inform slotted mode mobile stations, operating in the idle state, whether to 16 monitor the Paging Channel. See also Quick Paging, Paging Indicator, and Configuration Change 17 Indicator. 18

Quick Paging Channel Slot - An 80 ms interval on the Quick Paging Channel. See also Paging 19 Indicator and Configuration Change Indicator. 20

r-csch - Reverse common signaling logical channel 21

r-dsch - Reverse dedicated signaling logical channel 22

Radio Configuration (RC) - A set of Forward Traffic Channel and Reverse Traffic Channel 23 transmission formats that are characterized by physical layer parameters such as transmission 24 rates, modulation characteristics and spreading rate. 25

RC - See Radio configuration. 26

Registration - The process by which a mobile station identifies its location and parameters to a 27 base station. 28

Registration Zone - A collection of one or more base stations treated as a unit when determining 29 whether a mobile station should perform zone-based registration. See also User Zone, with which 30 it should not be confused. 31

Release - A process that the mobile station and base station use to inform each other of call 32 disconnect. 33

Remaining Set - The set of all allowable pilot offsets as determined by PILOT_INC, excluding the 34 pilot offsets of the pilots in the Active Set, Candidate Set, and Neighbor Set. See also Active Set, 35 Candidate Set, and Neighbor Set. 36

Request - A layer 3 message generated by either the mobile station or the base station to 37 retrieve information, ask for service, or command an action. 38

Reservation - Air interface resources set up by the access network to carry a higher layer 39

flow. A Reservation is identified by its ReservationLabel. ReservationLabels are bound to 40

RLP Flows that carry higher layer flows. A Reservation can be either in the Open or Close 41

state. 42

Response - A layer 3 message generated as a result of another message, typically a request. 43

3GPP2 C.S0044-D v1.0

xxvii

Reverse CDMA Channel - The CDMA Channel from the mobile station to the base station. From 1 the base station’s perspective, the Reverse CDMA Channel is the sum of all mobile station 2 transmissions on a CDMA frequency assignment. 3

Reverse Dedicated Control Channel (R-DCCH) - A portion of a Reverse Traffic Channel that 4 can carry a combination of primary data, secondary data, signaling, and power control 5 information. 6

Reverse Fundamental Channel (R-FCH) - A portion of a Reverse Traffic Channel that can carry 7 a combination of primary data, secondary data, signaling, and power control information. 8

Reverse Pilot Channel (R-PICH) - A non-data-bearing direct-sequence spread spectrum signal 9 transmitted by each CDMA mobile station whenever the Enhanced Access Channel, Reverse 10 Common Control Channel, or Reverse Traffic Channel is enabled. The Reverse Pilot Channel 11 allows a base station to acquire the timing of the Reverse CDMA Channel and provides a phase 12 reference for coherent demodulation. The Reverse Pilot Channel may be transmitted either 13 continuously or in gated mode. 14

Reverse Supplemental Channel (R-SCH) - An optional portion of a Reverse Traffic Channel 15 (Radio Configurations 3 and above) that operates in conjunction with a Fundamental Channel 16 and or the Dedicated Control Channel in that Traffic Channel, and (optionally) with other 17 Supplemental Channels to provide higher data rate services. 18

Reverse Supplemental Code Channel (R-SCCH) - An optional portion of a Reverse Traffic 19 Channel (Radio Configurations 1 and 2) that operates in conjunction with a Fundamental Channel 20 in that Traffic Channel, and (optionally) with other Supplemental Code Channels to provide higher 21 data rate services. 22

RF – Radio Frequency 23

RLP – Radio Link Protocol 24

SCCLT – Supplemental Code Channel List Table 25

SCR – Service Configuration Record 26

SDU - See Service Data Unit 27

Search Window - The range of PN sequence offsets that a mobile station searches for a pilot. 28

Search Window Offset - PN sequence offset used by the mobile station to position the search 29 window when searching for a pilot. 30

Secondary Traffic - An additional traffic stream that can be carried between the mobile station 31 and the base station on the Traffic Channel. See also Primary Traffic and Signaling Traffic. 32

Service Configuration - The common attributes used by the mobile station and the base station 33 to build and interpret Traffic Channel frames. A service configuration consists of Forward and 34 Reverse Traffic Channel multiplex options, Forward and Reverse Traffic Channel transmission 35 rates, and service option connections. Service Configuration is signaled via the Service 36 Configuration information record and the Non-Negotiable Service Configuration information 37 record. 38

Service Negotiation - The procedures used by the mobile station and base station to establish a 39 service configuration. See also Service Option Negotiation. 40

Service Option - A service compatibility of the system. Service options may be applications such 41 as voice, data, or facsimile. See (17). 42

Service Option Connection - A particular instance or session in which the service defined by a 43 service option is used. Associated with a service option connection are a reference, which is used 44 for uniquely identifying the service option connection, a service option, which specifies the 45 particular type of service in use, a Forward Traffic Channel traffic type, which specifies what type 46 of Forward Traffic Channel traffic is used to support the service option connection, and a Reverse 47

3GPP2 C.S0044-D v1.0

xxviii

Traffic Channel traffic type, which specifies what type of Reverse Traffic Channel traffic is used by 1 the service option connection. 2

Service Option Negotiation - The procedures used by the mobile station and base station to 3 establish a service configuration. Service option negotiation is similar to service negotiation, but 4 allows less flexibility for specifying the attributes of the service configuration. See also Service 5 Negotiation. 6

Service Redirection - The process by which the base station alters the system selection made 7 by a mobile station. It can be used temporarily during maintenance and testing to divert 8 subscribers to an alternate system. 9

Serving Frequency - The CDMA frequency on which a mobile station is currently communicating 10 with one or more base stations. 11

Shared Secret Data (SSD) - A 128-bit pattern stored in the mobile station (in semi-permanent 12 memory) and known by the base station. SSD is a concatenation of two 64-bit subsets: SSD_A, 13 which is used to support the authentication procedures, and SSD_B, which serves as one of the 14 inputs to the process generating the encryption mask and private long code. 15

Short Message Services (SMS) - A suite of services such as SMS Text Delivery, Digital Paging 16 (i.e., Call Back Number - CBN), and Voice Mail Notification (VMN). 17

SID - See System Identification 18

Signaling Traffic - Control messages that are carried between the mobile station and the base 19 station on the Traffic Channel. See also Primary Traffic and Secondary Traffic. 20

Slotted Mode - An operation mode of the mobile station in which the mobile station monitors only 21 selected slots on the Paging Channel. 22

SME – Signaling Message Encryption 23

SO – Service Option 24

Soft Handoff - A handoff occurring while the mobile station is in the Mobile Station Control on the 25 Traffic Channel State. This handoff is characterized by commencing communications with a new 26 base station on the same CDMA frequency assignment before terminating communications with 27 the old base station. See Hard Handoff. 28

SPC - Service Programming Code 29

Space Time Spreading (STS) - A forward link transmission method which transmits all forward 30 link channel symbols on multiple antennas and spreads the symbols with complementary Walsh 31 or quasi-orthogonal functions. 32

SSD - See Shared Secret Data 33

STS – See Space Time Spreading 34

Supplemental Code Channel (SCCH)- An optional portion of a Traffic Channel (Forward or 35 Reverse) which operates in conjunction with a Fundamental Channel in that Traffic Channel, and 36 (optionally) with other Supplemental Code Channels to provide higher data rate services. On this 37 channel a combination of primary data, secondary data, or both (but never signaling information) 38 are transmitted. 39

Supplemental Ec - Average energy per PN chip for one Forward Supplemental Code Channel. 40

Supplemental Ior

Ec- The ratio of the average transmit energy per PN chip for one Forward 41

Supplemental to the total transmit power spectral density. 42

Sync Channel - Code channel 32 in the Forward CDMA Channel, which transports the 43 synchronization message to the mobile station. 44

3GPP2 C.S0044-D v1.0

xxix

Sync_Chip_Bit - Number of PN chips per Sync Channel bit, equal to 1024. 1

Sync Ec - Average energy per PN chip for the Sync Channel. 2

Ior

Ec Sync - The ratio of the average transmit energy per PN chip for the Sync Channel to the 3

total transmit power spectral density. 4

System - A system is a cellular telephone service or personal communications service that 5 covers a geographic area such as a city, metropolitan region, county, or group of counties. See 6 also Network. 7

System Identification (SID) - A number uniquely identifying a cellular or PCS system 8

System Time - The time reference used by the system. System Time is synchronous to UTC 9 time (except for leap seconds) and uses the same time origin as GPS time. All base stations use 10 the same System Time (within a small error). Mobile stations use the same System Time, offset 11 by the propagation delay from the base station to the mobile station. See also Universal 12 Coordinated Time. 13

Target Frequency - The CDMA frequency assignment to which the base station directs a mobile 14 station in a handoff using an Extended Handoff Direction Message, a General Handoff Direction 15 Message, or a Universal Handoff Direction Message. 16

TCP – Transmission Control Protocol 17

Temporary Mobile Station Identity (TMSI) - A temporary mobile station identification assigned 18 by the base station. 19

TD – Transmit Diversity. See Orthogonal Transmit Diversity and Space Time Spreading. 20

TDSO – Test Data Service Option 21

TE – Terminal Equipment 22

TE2L – Terminal Equipment at land connection 23

TE2M – Terminal Equipment at mobile connection 24

Timer-Based Registration - A registration method in which the mobile station registers 25 whenever a counter reaches a predetermined value. The counter is incremented an average of 26 once per 80 ms period. 27

Time Reference - A reference established by the mobile station that is synchronous with the 28 earliest arriving multipath component used for demodulation. 29

TMSI - See Temporary Mobile Station Identity 30

TMSI Zone - The administrative zone that allows the TMSI to be reused. The TMSI_CODE has to 31 be unique within a TMSI zone but may be reused in a different TMSI zone. The TMSI zone is 32 identified by the field TMSI_ZONE. 33

Traffic Channel - A communication path between a mobile station and a base station used for 34 user and signaling traffic. The term Traffic Channel implies a Forward Traffic Channel and 35 Reverse Traffic Channel pair. See also Forward Traffic Channel and Reverse Traffic Channel. 36

Traffic Channel Preamble - A sequence of all-zero frames that is sent by the mobile station on 37 the Reverse Traffic Channel as an aid to Traffic Channel acquisition. 38

Traffic Ec - Average energy per PN chip for the Forward Fundamental Channel. For the case 39

when the power control sub-channel is assumed to be transmitted at the same power level used 40 for the 9600 bps or 14400 bps data rate, the following equations apply: For Rate Set 1, it is equal 41

to v11

11

x (total Forward Fundamental Channel energy per PN chip), where v equals 1 for 9600 42

3GPP2 C.S0044-D v1.0

xxx

bps, v equals 2 for 4800 bps, v equals 4 for 2400 bps, and v equals 8 for 1200 bps traffic data 1

rate. For Rate Set 2, it is equal to v23

23 x (total Forward Fundamental Channel energy per PN 2

chip), where v equals 1 for 14400 bps, v equals 2 for 7200 bps, v equals 4 for 3600 bps, and v 3 equals 8 for 1800 bps traffic data rate. The total Forward Fundamental Channel is comprised of 4 traffic data and a power control sub-channel. 5

Ior

Ec Traffic - The ratio of the average transmit energy per PN chip for the Forward Traffic 6

Channel to the total transmit power spectral density. 7

TSB – Technical Service Bulletin 8

Unique Challenge-Response Procedure - An exchange of information between a mobile station 9 and a base station for the purpose of confirming the mobile station’s identity. The procedure is 10 initiated by the base station and is characterized by the use of a challenge- specific random 11 number (i.e., RANDU) instead of the random variable broadcast globally (RAND). 12

Universal Coordinated Time (UTC) - An internationally agreed-upon time scale maintained by 13 the Bureau International de l’Heure (BIH) used as the time reference by nearly all commonly 14 available time and frequency distribution systems i.e., WWV, WWVH, LORAN-C, Transit, Omega, 15 and GPS. 16

User Zone - An area within which CDMA Tiered Services may be provided. It may correspond to 17 an RF coverage area, or it may be established independent of RF topology. User Zones are 18 classified as broadcast versus mobile-specific, and as active versus passive. See: Broadcast 19 User Zone, Mobile-Specific User Zone, Active User Zone, and Passive User Zone. See also 20 Registration Zone, with which it should not be confused. 21

UTC - Universal Temps Coordiné. See Universal Coordinated Time 22

V.42 – ITU-T Recommended error correction protocol 23

VJ – Van Jacobson compression 24

VMN – Voice Mail Notification 25

VMNI – Voice Mail Notification Indicator 26

Voice Privacy - The process by which user voice transmitted over a CDMA Traffic Channel is 27 afforded a modest degree of protection against eavesdropping over the air. 28

Walsh Chip - The shortest identifiable component of a Walsh function. There are 2N Walsh chips 29 in one Walsh function where N is the order of the Walsh function. On the Forward CDMA 30 Channel, one Walsh chip equals 1/1.2288 MHz, or 813.802 ns. On the Reverse CDMA Channel, 31 one Walsh chip equals 4/1.2288 MHz, or 3.255 µs. 32

Walsh Function - One of 2N time orthogonal binary functions (note that the functions are 33 orthogonal after mapping ‘0’ to 1 and ‘1’ to -1). 34

WLL – Wireless Local Loop 35

Zone-Based Registration - An autonomous registration method in which the mobile station 36 registers whenever it enters a zone that is not in the mobile station’s zone list. See also User 37 Zone Registration, with which it should not be confused. 38

Zone Timer - A timer used by the mobile station to remove outdated entries from its list of zones 39 in which it has previously registered. 40

µs - Microsecond (10-6

second). 41

3GPP2 C.S0044-D v1.0

xxxi

Tolerances 1

CDMA System Parameter Tolerances 2

CDMA parameters are specified in Annex B. All parameters indicated are exact unless otherwise 3 specified. 4

Measurement Tolerances 5

Unless otherwise specified, a measurement tolerance, including the tolerance of the 6 measurement equipment, of ±10% is assumed. 7

Unless otherwise specified, the Ior/Ioc value shall be within ±0.1 dB of the value specified, and 8

the Ioc value shall be within ±5 dB of the value specified. 9

References 10

The following documents contain provisions, which through reference in this text, constitute 11 provisions of this document. At the time of publication, the editions indicated were valid. All 12 standards are subject to revision, and parties to agreements based on this Standard are 13 encouraged to investigate the possibility of applying the most recent editions of the standards 14 indicated below. ANSI and TIA maintain registers of currently valid national standards published 15 by them. Unless otherwise noted, references are considered normative. 16

3GPP2 C.S0044-D v1.0

xxxii

Normative Reference

1. 3GPP2 C.S0002-F v1,0, Physical Layer Standard for cdma2000 Spread Spectrum Systems,

December 2012.

2. 3GPP2 C.S0003-F v1.0, Medium Access Control (MAC) Standard for cdma2000 Spread

Spectrum Systems, December 2012.

3. 3GPP2 C.S0004-F, v1.0, Signaling Link Access Control (LAC) Standard for cdma2000 Spread


4. 3GPP2 C.S0005-F, v1.0, Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread


5. 3GPP2 C.S0010-E v2.0, Recommended Minimum Performance Standards for cdma2000 Spread

Spectrum Base Stations, March 2014.

6. 3GPP2 C.S0011-E v2.0, Recommended Minimum Performance Standards for cdma2000 Spread

Spectrum Mobile Stations, March 2014.

7. 3GPP2 C. S0026-A v2.0, Test Data Service Option (TDSO) for cdma2000 Spread Spectrum

Systems, Feburary 2005.

8. 3GPP2 C. S0025-A v1.0, Markov Service Option (MSO) for cdma2000 Spread Spectrum

Systems, June 2012.

9. 3GPP2 C.S0013-B v1.0, Loopback Service Options (LSO) for cdma2000 Spread Spectrum

Systems January 2011.

10. 3GPP2 X.S0011-001-E v1.0, cdma2000 Wireless IP Network Standard: Introduction, November

2009.

11. 3GPP2 A.S0008-D v1.0, Interoperability Specification (IOS) for High Rate Packet Data (HRPD)

Radio Access Network Interfaces with Session Control in the Access Network, March 2013.

12. 3GPP2 C.S0063-B v1.0, cdma2000 High Rate Packet Data Supplemental Services, May 2010.

13. 3GPP2 C.S0015-C v1.0, Short Message Service (SMS) for Wideband Spread Spectrum Systems, November 2012

14. 3GPP2 C.S0016-D v2.0, Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Systems, April 2012.

15. 3GPP2 C.S0017-0, Data Service Options for Wideband Spread Spectrum Systems

16. Reserved

17. Reserved

18 3GPP2 C.S0014-E v1.0, Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband

Spread Spectrum Digital Systems, December 2011.

19 3GPP2 C.S0020-A v1.0, High Rate Speech Service Option 17 for Wideband Spread Spectrum

Communications Systems, May 2004.

3GPP2 C.S0044-D v1.0

xxxiii

20 TTY Forum. Seeking Solutions to TTY/TDD Through Wireless Digital Systems. TTY/TDD

FORUM-13. Final.

21 3GPP2 C.S0006-D v1.0, Analog Signaling Standard for cdma2000 Spread Spectrum Systems,

Augest, 2004.

22 3GPP2 S.R0006, Wireless Features Description

23 IETF RFC-792, Internet Control Message Protocol

24 3GPP2 C.S0024-200-C v2.0, Physical Layer for cdma2000 High Rate Packet Data Air Interface

Specification, December 2011.

25 3GPP2 C.S0022-B v2.0, Position Determination Service Standards for Dual Mode Spread

Spectrum Systems, April 2012.

26 3GPP2 A.S0009-D v1.0, Interoperability Specification (IOS) for High Rate Packet Data (HRPD)

Radio Access Network Interfaces with Session Control in the Packet Control Function, March

2013.

27 3GPP2 C.S0029-B v1.0, Test Application Specification (TAS) for High Rate Packet Data Air

Interface, March 2008.

28 3GPP2 X.S0011-002-E v1.0, cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP

Access Services, November 2009.

29 3GPP2 C.S0075-0 v1.0, Interworking Specification for cdma2000 1x and High Rate Packet Data

Systems, March 2006.

30 3GPP2 S.R0108-0 v2.0, HRPD-cdma2000 1x Interoperability for Voice and Data System

Requirements, June 2007.

31 3GPP2 C.S0098-100-0 v1.0, Introduction to cdma2000 Extended Cell High Rate Packet Data

(xHRPD) Air Interface Specification, January 2011.

32 3GPP2 C.S0098-200-0 v1.0, Physical Layer for Extended Cell cdma2000 High Rate Packet Data

Air Interface Specification, September 2011.

33 3GPP2 C.S0098-300-0 v1.0, Upper Layers for Extended Cell cdma2000 High Rate Packet Data

Air Interface Specification, March 2011.

1

Informative Reference

34 3GPP2 C.R1001-I v2.0, Administration of Parameter Value Assignment for TIA/EIA Spread Spectrum Standards, January 2014

2

3GPP2 C.S0044-D v1.0

xxxiv

This page intentionally left blank.1

3GPP2 C.S0044-D v1.0

1-1

1 MISCELLANEOUS AIR INTERFACE TESTS 1

1.1 Call Setup under Various PSIST Settings 2

1.1.1 Definition 3

This test verifies mobile station processing of the PSIST values. The persistence delay is a 4 function of the variable P in the following equations. 5

• If the type of the SDU is a request other than a registration or a message transmission, 6

and the SDU is not for an emergency call or emergency message transmission, P shall 7

be computed by 8

9

P =

otherwise 0

63 PSIST if 2 s

/4sPSIST

ACCOLCp = 0, 1, ..., 9 10

11

P =

otherwise 0

7 PSIST if 2 ssPSIST

ACCOLCp = 10, 11, ..., 15 12

13

• If the type of the SDU is a request for an emergency call or for an emergency message 14

transmission, and the mobile station has an ACCOLCp value between 0 and 9 inclusive, 15

P shall be computed by 16

P =

otherwise 0

7 PSIST_EMG if 2 sEMG_PSIST s

ACCOLCp = 0, 1, …, 9 17

If P is equal to 0, the mobile station shall end the access attempt, shall declare an access attempt 18 failure, and send an indication to Layer 3 that the system access is denied. 19

1.1.2 Traceability 20

(See[4]) 21

2.6.2.2.2 Access Parameters Message 22

2.6.2.2.15 Enhanced Access Parameters Message 23

2.7.1.3.2.4 Origination Message 24

2.7.1.3.2.5 Page Response Message 25

3.7.2.3.2.2 Access Parameters Message 26

3.7.2.3.2.33 Enhanced Access Parameters Message 27

(See[3]) 28

2.1.1.2.2.2 Requirements for Transmission and Retransmission Procedures 29

3GPP2 C.S0044-D v1.0

1-2

1.1.3 Call Flow Example(s) 1

None 2

1.1.4 Method of Measurement 3

1.1.4.1 Persistence Delay for Mobile Station in using ACCOLCP between 0 and 9 4

a. Connect the base station and mobile station as shown in Figure A-3. 5

b. Set ACCOLCP to any value between 0 and 9 in the mobile station. 6

c. Instruct the base station to send an Access Parameters Message or an Enhanced 7

Access Parameters Message in Table 1.1.4-1or Table 1.1.4-2 respectively: 8

9

Table 1.1.4-1 Access Parameters Message Settings 10

Field Value

PSIST(0-9) ‘000000’

PSIST(11) ‘000’

PSIST_EMG_INCL ‘0’

11

Table 1.1.4-2 Enhanced Access Parameters Message Settings 12

Field Value

PSIST_PARMS_INCL ‘1’

PSIST_PARMS_LEN As required

PSIST(0-9)_EACH ‘000000’

PSIST_11_EACH ‘000’

PSIST_EMG ’000’

13

d. Setup a mobile station originated call. 14

e. Verify the mobile station does not delay sending the Origination Message. 15

f. Verify the call completes and there is user traffic in both directions. 16

g. Setup a mobile station terminated call and verify the mobile station does not delay 17

sending the Page Response Message. 18

3GPP2 C.S0044-D v1.0

1-3

h. Change PSIST(0-9) or PSIST(0-9)_EACH in the Access Parameters Message or 1

Enhanced Access Parameters Message to ‘111111’. 2

i. Attempt to setup a mobile station originated call. 3

j. Verify the mobile station does not send an Origination Message. 4

k. Set PSIST(0_9) = ‘011000’ or PSIST(0-9)_EACH in the Access Parameters Message or 5

Enhanced Access Parameters Message. 6

l. Setup a mobile station originated call. 7

m. Verify the mobile station does delay sending the Origination Message according to the 8

equations in 1.1.12. 9

n. End the call. 10

o. Setup a mobile station terminated call. 11

p. Verify the mobile station does not delay sending the Page Response Message to the 12

base station. 13

1.1.4.2 Persistence Delay ACCOLCP greater than 9 14


b. Set ACCOLCP = 11 in the mobile station. 16


Access Parameters Message in Table 1.1.4-3 or Table 1.1.4-4respectively: 18

19


Field Value

PSIST(0-9) ‘000000’

PSIST(11) ‘000’


21

2 For PSIST test cases, test may need to be repeated, since MS may not delay sending a

message every time. For PSIST testing, it may be necessary to monitor access probe output to

verify that the access attempts are delayed.

3GPP2 C.S0044-D v1.0

1-4


Field Value



PSIST(0-9)_EACH ‘000000’


PSIST_EMG ’000’

2


e. Verify the mobile station does not delay sending the Origination Message. 4

f. Verify the call completes and there is user traffic in both directions. 5

g. Setup a mobile station terminated call and verify the mobile station does not delay 6

sending the Page Response Message. 7

h. Change PSIST(11) or PSIST_11_EACH in the Access Parameters Message or 8


i. Attempt to setup a mobile station originated call. 10

j. Verify the mobile station does not send an Origination Message. 11

k. Change PSIST(11) or PSIST_11_EACH in the Access Parameters Message or 12


l. Setup a mobile station originated call. 14

m. Verify the mobile station does delay sending the Origination Message according to the 15

equations in 1.1.13. 16

n. End the call. 17


p. Verify the mobile station does not delay sending the Page Response Message to the 19

base station. 20

1.1.4.3 Emergency Call Attempts 21


3 For PSIST test cases, test may need to be repeated, since MS may not delay sending a

message every time. For PSIST testing, it may be necessary to monitor access probe output to

verify that the access attempts are delayed.

3GPP2 C.S0044-D v1.0

1-5

b. Instruct the base station to send an Access Parameters Message or an Enhanced 1

Access Parameters Message in Table 1.1.4-5or Table 1.1.4-2 respectively: 2

3


Field Value

PSIST(0-9) ‘0’


PSIST_EMG ‘111’

5


Field Value



PSIST(0-9)_EACH ‘000000’


PSIST_EMG ’111’

c. Set ACCOLCP = 0-9 in the mobile station. 7

d. Attempt to setup an emergency call. 8

e. Verify the mobile station does not send an Origination Message to the base station. 9

f. End the call. 10

g. Repeat step d after changing PSIST_EMG = ‘110’ in the Access Parameters Message 11

or the Enhanced Access Parameters Message. 12

h. Verify the mobile station delays sending the Origination Message for the emergency 13

call. 14

i. Repeat step d, changing the PSIST_EMG = ‘000’ in the Access Parameters Message 15

or Enhanced Access Parameters Message. 16

j. Verify the mobile station does not delay sending the Origination Message to the base 17

station for the emergency call. 18

3GPP2 C.S0044-D v1.0

1-6

1.1.5 Minimum Standard 1

1.1.5.1 Persistence Delay for Mobile Station in using ACCOLCP between 0 and 9 2

The mobile station shall comply with steps e, f, g, j, m, and p. 3

1.1.5.2 Persistence Delay ACCOLCP greater than 9 4

The mobile station shall comply with steps e, f, g, j, m, and p. 5

1.1.5.3 Emergency Call Attempts 6

The mobile station shall comply with steps e, h, and j. 7

1.2 Registration Attempts with Different PSIST Settings 8

1.2.1 Definition 9

This test verifies mobile station processing of the PSIST values. The persistence delay is a 10 function of the variable P in the following equations. 11

If the type of the SDU is a request and a registration, P shall be computed by 12

P =

otherwise 0

63 PSIST if 22 s

_/4 ss PSISTREGPSIST

ACCOLCp = 0, 1, ..., 9 13

14

P =

otherwise 0

7 PSIST if 22 s

_ ss PSISTREGPSIST

ACCOLCp = 10, 11, ..., 15 15


(See[4]) 17







(See[3]) 24



None 27

3GPP2 C.S0044-D v1.0

1-7



b. Set ACCOLCP to any value between 0 and 9 in the Mobile Station. 3

c. Instruct the base station to send the Access Parameters Message or Enhanced Access 4

Parameters Message with the following values. 5


Field Value

PSIST(0-9) ‘000000’

REG_PSIST ‘000’

7


Field Value



PSIST(0-9)_EACH ‘000000’

REG_PSIST_EACH ‘000’

d. Set the value of REG_PRD to 29 in the System Parameters Message. 9

e. Verify timer-based registration occurs at the interval specified by REG_PRD. 10

f. Set REG_PSIST or REG_PSIST_EACH = ‘110’ or in the Access Parameters Message 11

or Enhanced Access Parameters Message. 12

g. Verify timer-based registration occurs at longer intervals than specified by REG_PRD. 13

h. Set REG_PSIST or REG_PSIST_EACH = ‘111’ and set PSIST(0-9) and PSIST(11) or 14

PSIST(0-9)_EACH and PSIST(11)_EACH to ‘111111’ and ‘111’ respectively in the 15

Access Parameters Message or Enhanced Access Parameters Message. 16

i. Verify the mobile station does not send a Registration Message. 17

j. Set ACCOLCP = 11 in the mobile station and repeat steps c through i. 18


The mobile station shall comply with steps e, g, and i. 20

3GPP2 C.S0044-D v1.0

1-8

1.3 Short Message Service with Different PSIST Settings 1

1.3.1 Definition 2

This test verifies mobile station processing of the PSIST values. The persistence delay is a 3

function of the variable P in the following equations. 4

If the type of the SDU is a request and a message transmission, except in the case of an 5

emergency message transmission from a mobile station having an ACCOLCp value 6

between 0 and 9 inclusive, P shall be computed by 7

P =

otherwise 0

63 PSIST if 22 s

_/4 ss PSISTMSGPSIST

ACCOLCp = 0, 1, ..., 9 8

9

P =

otherwise 0

7 PSIST if 22 s

_ ss PSISTMSGPSIST

ACCOLCp = 10, 11, ..., 15 10

11


None 13


(See[4]) 15







(See[3]) 22




b. Set ACCOLCP to any value between 0 and 9 in the Mobile Station. 26


Access Parameters Message with the following parameters: 28

3GPP2 C.S0044-D v1.0

1-9


Field Value

PSIST(0-9) ‘000000’

MSG_PSIST ‘000’

2


Field Value



PSIST(0-9)_EACH ‘000000’

MSG_PSIST_EACH ‘000’

4

d. Create a short message at the mobile station, of a length smaller than the maximum 5

message length allowed on the Access Channel, and instruct the mobile station to send 6

the short message to the network. 7

e. Verify the mobile station does not delay sending the Data Burst Message. 8

f. Set MSG_PSIST or MSG_PSIST_EACH = ‘110’ in the Access Parameters Message or 9

the Enhanced Access Parameters Message. 10

g. Create a short message at the mobile station, of a length smaller than the maximum 11

message length allowed on the access channel, and instruct the mobile station to send 12


h. Verify the mobile station delays sending the Data Burst Message to the base station 14

over the access channel. 15

i. Set MSG_PSIST or MSG_PSIST_EACH = ‘111’ and set PSIST(0-9) or PSIST(0-16

9)_EACH to ‘111111’ in the Access Parameters Message or Enhanced Access 17

Parameters Message. 18

j. Create a short message at the mobile station, of a length smaller than the maximum 19

message length allowed on the access channel, and instruct the mobile station to send 20


k. Verify the mobile station does not send the Data Burst Message. 22

l. Set ACCOLCP = 11 in the mobile station and repeat steps c through k. 23

3GPP2 C.S0044-D v1.0

1-10


The mobile station shall comply with steps e, h, and k. 2

1.4 Quick Paging Channel CCI 3

1.4.1 Definition 4

For mobile stations that support the Quick Paging Channel, this test will verify the following: A 5 mobile station using the Quick Paging Channel ‘configuration change indicator’ (CCI) will update 6 its overhead information when the CCI bit is set to on. 7


(See[4]) 9

2.6.2.1.1.3 Slotted Mode Requirements 10

2.6.2.1.2 Quick Paging Channel Monitoring Procedures 11

2.6.2.1.4 Idle Handoff 12

2.6.7.1 Hash Function 13

3.6.2.5 Quick Paging Channel Processing 14

3.7.2.3.2.13 Extended System Parameters Message 15

3.7.2.3.2.14 Extended Neighbor List Message 16


None 18


a. Connect two base stations to the mobile station, with the ability to transition either base 20

station power Ior 5 dB above the other, to induce idle handoff from one to the other and 21

back again. 22

1. The Forward Channel from base station 1 has an arbitrary pilot PN offset index 23

P1 and is called Channel 1. 24


P2 and called Channel 2. 26

b. Set the Extended System Parameter Message in both base stations as specified in 27

Table 1.4.4-1. 28

29

3GPP2 C.S0044-D v1.0

1-11

Table 1.4.4-1 Test Parameters for Extended System Parameters Message 1

Field Values

QPCH_SUPPORTED '1' (QPCH is supported)

NUM_QPCH '01' (Number of the QPCH)

QPCH_RATE (indicator rate) '0' (QPCH indicator rate is 4800 bps)

QPCH_POWER_LEVEL_PAGE '101' (same as forward pilot channel)

QPCH_CCI_SUPPORTED '1' [configuration change indicators supported]

QPCH_POWER_LEVEL_CONFIG '101' (same as forward pilot channel)

2

c. Set NGHBR_PN for the Extended Neighbor List Message, Neighbor List Message or 3

General Neighbor List Message in both base stations to include the other base station 4

PN. 5

d. Set the Paging Channel data rate for Channels 1 and 2 to 4800 bps. 6

e. Setup Channel 1 and Channel 2 per Table 1.4.4-2. 7

Table 1.4.4-2 Test Parameters for Slotted Mode Idle Handoff 8

Parameter Unit Channel 1 Channel 2

Îor/Ioc dB 0 -5

Ior

EPilot C

dB -7 -7

Ior

EcPagingQuick

dB -7 -7

Ioc dBm/1.23 MHz -75

9

f. Slowly (over a period of several seconds, but not more than T31m = 600 seconds round 10

trip) transpose power levels of channel 1 and 2. That is, raise Channel 2 power by 5 dB 11

(to Îor/Ioc = 0 dB), and lower Channel 1 power by 5 dB (to Îor/Ioc = -5 dB). This should 12

cause an idle handoff from Channel 1 to Channel 2. 13

g. Verify the mobile station has performed an idle handoff to Channel 2. 14

h. While the mobile station is idle on Channel 2, instruct the base station 1 to modify an 15

overhead message, thus causing the CCI bits on Channel 1 Quick Paging Channel to 16

be set to ON. 17

i. Cause an idle handoff from Channel 2 to Channel 1. 18

3GPP2 C.S0044-D v1.0

1-12

j. Verify that the mobile station does not go to slotted mode until it has updated its 1

overhead configuration. 2

k. Repeat steps a through j with the QPCH_RATE (indicator rate) set to 1 (9600 rate). 3


The mobile station shall comply with the requirement in steps g and j. 5

1.5 Mobile Station Response to Status Request Message 6

1.5.1 Definition 7

This test verifies that that mobile station responds to the Status Request Message correctly. 8


(See[4]) 10

2.6.3.5 Mobile Station Origination Attempt Substate 11

2.6.4.1.2 Service Configuration and Negotiation 12

2.6.4.1.14 Processing the Service Configuration Record 13

2.6.4.1.15 Processing the Non-Negotiable Service Configuration Record 14

2.6.4.2 Traffic Channel Initialization Substate 15



2.7.1.3.2.10 Extended Status Response Message 18

2.7.2.3.2.14 Service Connect Completion Message 19

2.7.2.3.2.16 Status Response Message 20

2.7.4 Information Records 21

3.6.3.5 Response to Origination Message 22


3.7.2.3.2.15 Status Request Message 24

3.7.2.3.2.21 Extended Channel Assignment Message 25

3.7.3.3.2.20 Service Connect Message 26

3.7.5.7 Service Configuration 27

3.7.5.20 Non-Negotiable Service Configuration 28


None 30


a. Ensure the mobile station is operating in the Idle State. 32

3GPP2 C.S0044-D v1.0

1-13

b. Instruct the base station to send a Status Request Message on the f-csch to request 1

one or more of the information records listed in section 2.7.4 of [4]. Verify that 2

QUAL_INFO_TYPE, QUAL_INFO_LEN and Type-specific fields in Status Request 3

Message are set to appropriate values. 4

c. Verify the following: 5

1. If P_REV_IN_USE is greater than 3: 6

a. The mobile station sends an Extended Status Response Message with 7

the QUAL_INFO_TYPE, QUAL_INFO_LEN, Type-specific fields set to 8

appropriate value, and requested information record(s) included; or 9

b. The mobile station sends a Mobile Station Reject Order with ORDQ = 10

6 if the mobile station does not support the band class and/or operating 11

mode specified in the Status Request Message; or 12

c. The mobile station sends a Mobile Station Reject Order with ORDQ = 13

8 if the information record would exceed the allowable length; or 14

d. The mobile station sends a Mobile Station Reject Order with ORDQ = 15

9 if the information record is not supported for the specified band class 16

and operating mode. 17

2. If P_REV_IN_USE is less than or equal to 3: 18

a. The mobile station sends a Status Response Message with the 19

appropriate QUAL_INFO_TYPE, QUAL_INFO_LEN, Type-specific 20

fields set to appropriate value, and requested information record(s) 21

included; or 22

b. The mobile station sends a Mobile Station Reject Order with ORDQ = 23

6 if the mobile station does not support the band class and/or operating 24

mode specified in the Status Request Message; or 25

c. The mobile station sends a Mobile Station Reject Order with ORDQ = 26

8 if the information record would exceed the allowable length; or 27

d. The mobile station sends a Mobile Station Reject Order with ORDQ = 28

9 if the information record is not supported for the specified band class 29

and operating mode. 30

d. Set up a mobile originated call. 31

e. Instruct the base station to send a Status Request Message on the f-dsch to request 32

one or more of the information records listed in section 2.7.4 of [4]. 33

f. Verify the following: 34

1. The mobile station sends a Status Response Message with the appropriate band 35

class, operating mode, and information record; or 36

2. The mobile station sends a Mobile Station Reject Order with ORDQ = 6 if the 37

mobile station does not support the band class and/or operating mode specified 38

in the Status Request Message; or 39

3GPP2 C.S0044-D v1.0

1-14

3. The mobile station sends a Mobile Station Reject Order with ORDQ = 9 if the 1

information record is not supported for the specified band class and operating 2

mode. 3


The mobile station shall comply with steps c and f. 5

1.6 SYNC Channel Support for Mobile Stations not capable of TD, or not capable of 6

QPCH or RC>2 7

1.6.1 Definition 8

This test verifies that the mobile station is able to respond correctly to the new fields of Sync 9 Channel Message sent by the base station if any, tune to appropriate CDMA channel and acquire 10 the system successfully. 11


(See[4]) 13

2.6.1.3 Sync Channel Acquisition Substate 14

3.7.2.3.2.26 Sync Channel Message 15


None 17


1.6.4.1 Base Station capable of Non-TD BCCH but not TD (Case 1) 19

20

Table 1.6.4-1 Frequency Allocation 21

Case 1 Case 2 Case 3

CDMA_FREQ 1 1 1

EXT_CDMA_FREQ 2 2 2

SR1_CDMA_FREQ_NON_TD 3 N/A 3

SR1_CDMA_FREQ_TD N/A 4 4

a. Connect the base station to the mobile station as shown in Figure A-4. Set PILOT_INC 22

to 1. 23

b. At the base station, Set Pilot PN offset to a certain value. 24

c. Verify that the mobile station acquires the Forward pilot channel correctly. 25

d. Verify the mobile station receives a Sync Channel Message with frequency allocation 26

according to Table 1.6.4-1. 27

3GPP2 C.S0044-D v1.0

1-15

e. Verify that the mobile station tunes to CDMA Channel 3. 1

f. Make a Mobile-Originated voice call and verify audio in both directions. 2

g. End the call. 3

1.6.4.2 Base Station capable of TD but not Non-TD BCCH (Case 2) 4


to 1. 6



d. Verify the mobile station receives a Sync Channel Message frequency allocation 9




g. End the call. 13

1.6.4.3 Base Station capable of Non-TD BCCH and TD (Case 3) 14


to 1. 16







g. End the call. 23



The mobile station shall comply with steps c, e, and f. 26





3GPP2 C.S0044-D v1.0

1-16

1.7 Sync Channel support for Mobile Stations not capable of TD, but capable of QPCH 1

or RC>2 2

1.7.1 Definition 3



(See[4]) 8




None 12



15


Case 1 Case 2 Case 3

CDMA_FREQ 1 1 1

EXT_CDMA_FREQ 2 2 2

SR1_CDMA_FREQ_NON_TD 3 N/A 3

SR1_CDMA_FREQ_TD N/A 4 4

17


to 1. 19







g. End the call. 26

3GPP2 C.S0044-D v1.0

1-17



to 1. 3







g. End the call. 10



to 1. 13







g. End the call. 20








1.8 Sync Channel Support for Mobile Stations capable of TD and QPCH or RC>2 28

1.8.1 Definition 29


3GPP2 C.S0044-D v1.0

1-18


(see [4]) 2




None 6




Case 1 Case 2 Case 3 Case 4 Case 5

CDMA_FREQ 1 1 1 14 1

EXT_CDMA_FREQ 2 2 2 2 2

SR1_CDMA_FREQ_NON_TD 3 N/A N/A 3 3

SR1_CDMA_FREQ_TD N/A 4 4 4 4


to 1. 11







g. End the call. 18

1.8.4.2 Base Station capable of TD with the same TD mode as Mobile Station but not 19

Non-TD BCCH (Case 2) 20


to 1. 22



4 This is a pseudo frequency, no corresponding channel elements are needed.

3GPP2 C.S0044-D v1.0

1-19





g. End the call. 5

1.8.4.3 Base Station capable of TD with different TD mode as Mobile Station but not 6



to 1. 9







g. End the call. 16

1.8.4.4 Base Station capable of Non-TD BCCH and TD with the same TD mode as 17

Mobile Station (Case 4) 18


to 1. 20







g. End the call. 27

1.8.4.5 Base Station capable of Non-TD BCCH and TD with a different TD mode as 28



to 1. 31



3GPP2 C.S0044-D v1.0

1-20





g. End the call. 5




1.8.5.2 Base Station capable of TD with the same TD mode as Mobile Station but not 9



1.8.5.3 Base Station capable of TD with different TD mode as Mobile Station but not 12



1.8.5.4 Base Station capable of Non-TD BCCH and TD with the same TD mode as 15



1.8.5.5 Base Station capable of Non-TD BCCH and TD with a different TD mode as 18



1.9 Hashing F-CCCH, F-CCCH slot 21

1.9.1 Definition 22

This test checks the ability to set and detect hashed F-CCCH’s and F-CCCH Slots. The IMSI’s 23 effect on hashed F-CCCH and Slot is also checked. 24

1.9.2 Traceability: 25

(See[4]) 26


3.6.2.1.2 Common Channel Determination 28

3.6.2.1.3 Paging Slot Determination 29


None 31

3GPP2 C.S0044-D v1.0

1-21

1.9.4 Methods of Measurement 1

1.9.4.1 F-CCCH Number Hashing 2


b. Configure the base station system with multiple F-CCCH’s (maximum seven) in MC-RR 4


c. Make a mobile terminated call, and verify audio in both directions. 6

1.9.4.2 F-CCCH Slot Number Hashing 7


b. Configure the base station system with slotted mode capability. 9

c. Make a mobile terminated call, and verify audio in both directions. 10


1.9.5.1 F-CCCH Number Hashing 12

The mobile station shall comply with step c. 13

1.9.5.2 F-CCCH Slot Number Hashing 14

The mobile station shall comply with step c. 15

1.10 CDMA Channel Hashing on F-PCH for Mobile Stations not capable of QPCH or RC>2 16

1.10.1 Definition 17

This test checks the mobile station’s ability to do CDMA Channel hashing based on different 18 capability sets to select appropriate CDMA Channel and associated PCH. 19


(see [4]) 21

2.6.2.2 Response to Overhead Information Operation 22

2.6.2.2.12.1 Extended CDMA Channel List Message on Paging Channel 23


3.6.2.1.1 CDMA Channel Determination 25

3.7.2.3.2.28 Extended CDMA Channel List Message 26


None 28

3GPP2 C.S0044-D v1.0

1-22

1.10.4 Methods of Measurement 1

1.10.4.1 Base Station incapable of BCCH and QPCH or RC>2 (Case 1) 2

a. Turn off all forms of autonomous registration at the base station. 3

b. Connect the base station and mobile station as shown in Figure A-4, and configure the 4

base station with 1 Paging Channel on each of the 2 CDMA channels. 5

c. Verify that the base station sends an Extended CDMA Channel List Message with 6

RC_QPCH_SEL_INCL=’0’, TD_SEL_INCL=’0’ and NUM_FREQ=’0010’ or a CDMA 7

Channel List Message from the base station. 8

d. Make a mobile terminated call, and verify audio in both directions. 9

1.10.4.2 Base Station incapable of BCCH, capable of QPCH or RC>2 with Extended 10

CDMA Channel List Message sent (Case 2) 11




c. Send an Extended CDMA Channel List Message with RC_QPCH_SEL_INCL=’1’, 15

TD_SEL_INCL=’0’ and NUM_FREQ=’0010’ from the base station and make sure 16

RC_QPCH_HASH_IND is set to ‘1’ for freq 1 and 2. 17



1.10.5.1 Base Station incapable of BCCH and QPCH or RC>2 (Case 1) 20

The mobile station shall comply with step d. 21




1.11 CDMA Channel Hashing on F-PCH for Mobile Stations capable of QPCH or RC>2 25


This test checks the mobile station’s ability to do CDMA Channel hashing based on different 27 capability sets to select appropriate CDMA Channel and associated PCH. 28


(see [4]) 30


2.6.2.2.12.1 Extended CDMA Channel List Message on Paging Channel 32


3GPP2 C.S0044-D v1.0

1-23




None 4


1.11.4.1 Base Station incapable of BCCH and QPCH or RC>2 with Extended CDMA 6

Channel List Message sent (Case 1) 7





TD_SEL_INCL=’0’ and NUM_FREQ=’0010’ from the base station. 12












1.11.5.1 Base Station incapable of BCCH and QPCH or RC>2 with Extended CDMA 24

Channel List Message sent (Case 1) 25





3GPP2 C.S0044-D v1.0

1-24

1.12 CDMA Channel Hashing on F-BCCH; Mobile Station not capable of either TD or 1

QPCH (RC>2) 2

1.12.1 Definition 3

This test checks the mobile station’s ability to do CDMA Channel (frequency) hashing based on 4 different capability sets to select appropriate CDMA Channels and associated primary BCCHs. 5


(see [4]) 7

2.6.2.1.5 Primary Broadcast Control Channel Monitoring 8


2.6.2.2.12.2 Extended CDMA Channel List Message On Primary Broadcast Control Channel 10





None 15


1.12.4.1 Base station operates without TD and QPCH, RC>2 (Case 1) 17



base station with 1 primary BCCH on each of the 2 CDMA channels. 20




1.12.4.2 Base Station operates without TD (STS) but with QPCH (RC>2), (Case 2) 24






RC_QPCH_HASH_IND is set to ‘1’ for freq 1 and 2 30


1.12.4.3 Base Station operates with TD (STS) and QPCH (RC>2) (Case 3) 32


3GPP2 C.S0044-D v1.0

1-25





TD_HASH_IND is set to ‘1’ for frequency 1 and RC_QPCH_HASH_IND is set to ‘1’ for 5

frequency 1 and 2. 6



1.12.5.1 Base station operates without TD and QPCH, RC>2 (Case 1) 9


1.12.5.2 Base Station operates without TD (STS) but with QPCH (RC>2), (Case 2) 11




1.13 CDMA Channel Hashing on F-BCCH; Mobile Station not capable of TD (STS) but 15

capable of QPCH (RC>2) 16


This test checks the mobile station’s ability to do CDMA Channel (frequency) hashing based on 18 different capability sets to select appropriate CDMA Channels and associated primary BCCH’s. 19


(see [4]) 21





CDMA Channel Determination 26



None 29

3GPP2 C.S0044-D v1.0

1-26


1.13.4.1 Base Station operates without TD (STS) and QPCH (RC>2) (Case 1) 2







1.13.4.2 Base Station operates without TD (STS) but with QPCH (RC>2) (Case 2) 9














TD_HASH_IND is set to ‘1’ for frequency 1 and RC_QPCH_HASH_IND is set to ‘1’ for 23

frequencies 1 and 2. 24



1.13.6 Base Station operates without TD (STS) and QPCH (RC>2) (Case 1) 27


1.13.7 Base Station operates without TD (STS) but with QPCH (RC>2) (Case 2) 29


1.13.8 Base Station operates with TD (STS) and QPCH (RC>2) (Case 3) 31


3GPP2 C.S0044-D v1.0

1-27

1.14 CDMA Channel Hashing on F-BCCH; Mobile Station capable of both TD (STS) and 1

QPCH (RC>2) 2

1.14.1 Definition 3

This test checks the mobile station’s ability to do CDMA Channel (frequency) hashing based on 4

different capability sets to select appropriate CDMA Channels and associated primary BCCH’s. 5


(see [4]) 7








None 15


None 17














RC_QPCH_HASH_IND is set to ‘1’ for frequency 1 and 2. 31


3GPP2 C.S0044-D v1.0

1-28







TD_HASH_IND is set to ‘1’ for frequency 1 and 2, RC_QPCH_HASH_IND is set to ‘1’ 7

for all the frequencies. 8









1.15 F-CCCH SUPPORT 17


This test checks the mobile station’s ability to process messages (L2 ACK, Extended Channel 19 Assignment Message) sent over F-CCCH correctly. 20


(see [4]) 22

2.6.2.1.1 Forward Channel Monitoring Procedures 23

2.6.2.1.1.4 Common Channel Supervision 24

2.6.3.1.8 Paging Channel and Forward Common Control Channel Monitoring 25


None 27



b. Instruct the mobile station originate a voice call. 30

c. Verify the base station respond with a Layer 2 ACK and Extended Channel Assignment 31

Message over F-CCCH. 32

3GPP2 C.S0044-D v1.0

1-29

d. Verify the mobile station can set up the traffic channel for this voice call correctly. 1



1.16 Paging Indicator on the Quick Paging Channel 4

1.16.1 Definition 5

For mobile stations that support the Quick Paging Channel, this test will verify the following: 6

The mobile station shall hash to the correct paging indicator positions. The mobile station shall 7 monitor its assigned Paging Channel or F-CCCH slot immediately following its assigned Quick 8 Paging Channel slot if the mobile station does not detect that at least one of the paging indicators 9 is set to “OFF”. Therefore, if the mobile station detects zero, one or two “ON” in the hashed 10 paging indicators without detecting an “OFF”, the mobile station will monitor its assigned Paging 11 Channel or F-CCCH slot

5. It is assumed that if the mobile station hashes to the wrong paging 12

indicator positions and detected an “OFF”, the mobile station would likely miss the assigned 13 Paging Channel or the F-CCCH slot. 14


(See[4]) 16

2.6.2.1.2 Quick Paging Channel Monitoring Procedures. 17


2.7.1.3.2.1 Registration Message 19

3.6.2.5 Quick Paging Channel Processing 20


3.7.2.3.2.31 MC-RR-Parameters Message 22


24

5 Although the mobile station will monitor the Paging Channel or the F-CCCH when the paging

indicator is detected as “ON” (without detecting an “OFF”), there are other reasons the mobile

station may monitor the Paging Channel or the F-CCCH even if the mobile station does not detect

an “ON” for the paging indicators. For example, the mobile station may not operate the QPCH

properly such that neither “ON” nor “OFF” is detected or the mobile station’s threshold for

detecting the paging indicators is set too high. Even if the mobile station hashes to the wrong

paging indicator positions and detected an “OFF” there is no requirement that the mobile station

shall not monitor the Paging Channel or the F-CCCH.

3GPP2 C.S0044-D v1.0

1-30

Registration Request order

BS

Common

Channels

MS

Common

Channels

Turn on/off PI on Quick Paging Channel

for the MS assigned QPCH Slot

The MS hash to QPI

positions and detect its

QPI on in the Assigned

QPCH Slot. Then the MS

start receiving on its

assigned F-PCH or

F-CCCH slots

Registration Message

1 2


a. Connect the mobile station to the base station as shown in Figure A-3. 4

b. Set the values in the Extended System Parameters Message or MC-Parameters 5

Message as follows: 6

7

Fields Values

QPCH_SUPPORTED '1' (QPCH is supported)

NUM_QPCH '01' (Number of the QPCH)

QPCH_RATE '0' (4800 bps QPCH data rate)

QPCH_POWER_LEVEL_PAGE '101' (same as pilot channel)

c. Allow the mobile station to begin monitoring the QPCH. 8

d. Instruct the base station to send a mobile station directed message (i. e. General Page 9

Message or Registration Request Order) in the mobile station’s assigned Paging 10

Channel or F-CCCH slot. 11

e. Verify that the base station sets the paging indicator positions associated with the 12

mobile station to “ON” in the Quick Paging Channel slot corresponding to the Paging 13

Channel or F-CCCH slot in which the mobile station directed message is sent in step d. 14

Ensure the base station sets the other paging indicator positions to “OFF”. 15

f. Verify the mobile station correctly responds to the message directed to it in step d. 16

g. Repeat steps b through f with the QPCH_RATE set to ‘1’ (9600 bps). 17


The mobile station shall comply with step f. The base station shall comply with step e. 19

20

3GPP2 C.S0044-D v1.0

1-31

1.17 M2M Capability Support 1

1.17.1 Definition 2

This test verifies the mobile station’s M2M capability information exchange between the mobile 3 station and the base station. 4

1.17.2 Traceability (See [4]) 5

2.7.1.3.2.18 General Extension Message with record_type 2. 6

3.7.2.3.2.1 System Parameters Message 7



3.7.2.3.2.17 General Page Message 10



None 13


a. Connect the mobile station to the base station as shown in Annex A Figure A-1. 15

b. Enable CAPABILITY_GEM_ALLOWED = 1 in System Parameters Message. 16

c. Power on the mobile station and verify that the mobile station acquires base station. 17

d. Verify that power up registration occurs and General Extension Message with record 18

type 2 is bundled with Registration Message with reg_type = 1 19

e. Instruct the mobile station to originate SO33 call. 20

f. Verify that General Extension Message with record_type 2 is bundled with Origination 21

Message. 22

g. Wait for the mobile station to go to dormant state 23

h. Instruct the base station to send General Page Message with SO33 call. 24

i. Verify that General Extension Message with record_type=2 is bundled with Page 25

Response Message. 26

j. End Call 27


Mobile station should comply with steps d, f, and i. 29

1.18 Data Burst sent on the REACH. 30


This test verifies that the mobile station sends Short Data Burst on REACH for small data 32 transfers when it is configured to do so. 33

3GPP2 C.S0044-D v1.0

1-32


2.7.1.3.2.18 General Extension Message with record_type 2. 2


3.7.2.3.2.47 Generic Access Parameter Message 4

3.7.2.3.2.13 Extended System Parameter Message 5

3.7.2.3.2.1 System Parameter Message 6

3.7.3.3.2.4 Data Burst Message 7


None 9



b. Instruct the mobile station to originate SO33 call. 12

c. Verify that the mobile station uses REACH channel to send General Extension Message 13

bundled with Origination Message. 14

d. Wait until the mobile station goes to dormant state. 15

e. Set the mobile station to use data over signaling feature and start ping with data < 255 16

bytes. 17

f. Verify that the mobile station sends Data Burst Message with data packed. 18

g. End Call. 19


The mobile station shall comply with steps c and f. 21

1.19 Skip Overhead Read 22


This test verifies that the mobile station supporting the skip overhead read feature can use the 24 stored overhead information across idle handoffs. 25

26




None 30

3GPP2 C.S0044-D v1.0

1-33



b. Power on the mobile station and verify that the mobile station acquires 3

Sector1(PN_EXT1). 4

c. Verify that the mobile station reads complete overheads on powering up on a new sector 5

for the first time. 6

d. Instruct the mobile station to originate SO33 data call. 7

e. Wait until the mobile station goes to dormant state 8

f. Perform idle handoff to Sector2 by reducing IOR of Sector1 and increasing IOR of 9

Sector2. 10

g. Verify that the mobile station reads complete overhead on Sector2 as its acquired for the 11

first time. 12

h. Start pings for 30 secs. 13

i. Wait until configured T31 timer expires. 14

j. Perform idle handoff to Sector 1 15

k. Verify that the mobile station skip reads of complete overhead on Sector1 and uses stored 16

overheads 17

l. Start pings for 30secs 18

m. End call 19


The mobile station shall comply with steps c, g, and k. 21

1.20 Bundling R-SCH Request with Origination Message 22


If the base station supports the R-SCH request bundling with ORM in GEM and the mobile station 24

uses the bundling, it will lead to different procedures for call set up. This test verifies the mobile 25

station follows the corresponding call flows depending on whether the R-SCH request bundling 26

with ORM in GEM is used or not. 27

28



3.7.2.3.2.44 General Extension Message 31



3GPP2 C.S0044-D v1.0

1-34

1.20.3 Call Flow Examples 1

2

MS

GEM(ORM+RSCHBlob+DC(SO33_DEFAULT=1))

BS

BSAck()

ECAM(SO33_ACCEPTED=1)

NULLFrame()

TrafficChannelPreamble()

BSAck()

MSAck()

ESCAM()

BSAck()

ECAM(SO33_ACCEPTED=1)

NULLFrame()

TrafficChannelPreamble()

BSAck()

MSAck()

ESCAM()

Assumption -

R_SCH_GEM_ALLOWED =1 in

SystemParameters message

indicating BS supports RSCHBlob in

GEM

3

Figure 1.20.3-1. Mobile originated call flow if R-SCH Request Bundling with ORM is used 4

5

3GPP2 C.S0044-D v1.0

1-35

MS

GEM(ORM+DC(SO33_DEFAULT=1))

BS

GEM(ORM+DC(SO33_DEFAULT=1))

BSAck()

ECAM(S033_ACCEPTED=1)

NULLFrane()

message_0()

BSAck()

MSAck()

SupplementalChannelRequest(RSCHReq)

SupplementalChannelAssignment()

BSAck()

ECAM(S033_ACCEPTED=1)

NULLFrane()

message_0()

BSAck()

MSAck()

SupplementalChannelRequest(RSCHReq)

SupplementalChannelAssignment()

1

Figure 1.20.3-2. Mobile originated call flow if R-SCH Request Bundling with ORM is not used 2

3


a. Connect the mobile station to the base station as shown in Annex A Figure A-1. Set 5

the flag R_SCH_GEM_ALLOWED to 1 in the System Parameters Message. 6

b. Instruct the mobile station to originate SO33 call 7

c. Verify that R-SCH request and SO33_DEFAULT=1 is sent along with Origination 8

Message in General Extension Message. 9

d. Instruct the base station to send Extended Channel Assignment Message with 10

SO33_ACCEPTED set to 1 11

e. Verify that the mobile station skips R-SCH request 12

f. Instruct the base station to send Extended Supplemental Channel Assignment 13

Message 14

g. Verify that the mobile station and base station are able to send and receive IP 15

packets. 16

h. End the call. 17

i. Connect the mobile station to the base station as shown in Annex A Figure A-1. Set 18

the flag R_SCH_GEM_ALLOWED to 0 in the System Parameters Message. 19

3GPP2 C.S0044-D v1.0

1-36

j. Instruct the mobile station to originate SO33 call 1

k. Verify that the mobile station sends SO33_DEFAULT=1 along with Origination 2

Message in General Extension Message without R-SCH request. 3

l. Instruct the base station to send Extended Channel Assignment Message with 4

SO33_ACCEPTED set to 1. 5

m. Verify that the mobile station sends R-SCH request 6

n. Instruct the base station to send Supplemental Channel Assignment Message 7

o. Verify that the mobile station and base station are able to send and receive IP 8

packets. 9

p. End the call. 10


The mobile station shall comply with the requirement in steps c, e, and g if the mobile station 12

uses R-SCH request bundling with ORM; otherwise the mobile station shall comply with k, m and 13

o. 14

15

3GPP2 C.S0044-D v1.0

2-1

2 BASIC CALL PROCESSING TESTS 1

2.1 Mobile Originated Voice Calls 2

2.1.1 Definition 3

This tests voice service negotiation and call completion of mobile originated voice calls, for radio 4 configurations and voice service options supported by the mobile and base station. 5


(see[4]) 7

2.2.6.2.5 Mobile Station Origination Operation 8


2.6.4 Mobile Station Control on the Traffic Channel State 10


2.7.2.3.2.15 Service Option Control Message 12


3.6.4 Traffic Channel Processing 14


3.7.3.3.2.3 Alert With Information Message 16


2.7.2.3.2.12 Service Request Message 18

2.7.2.3.2.13 Service Response Message 19


2.7.4.18 Service Configuration Record 21

3GPP2 C.S0044-D v1.0

2-2


Service Connect Message

Service Configuration Record (SO, RCs)

Extended Channel Assignment Message

(DEFAULT_CONFIG, GRANTED_MODE, RCs)

possible service negotiation

Order Message (acknowledgement from base station)

Origination Message (SO, RCs proposed)

release order messages

Voice Traffic

Service Connect Completion Message

MS BS

common

channels

dedicated

channels

common

channels

initial service

configuration

possible new

service

configuration

2


a. Configure the base station for desired voice service negotiation listed in Table 2.1.4-2. 4

b. Allow the mobile to come to the idle state on the base station. 5

c. Make a mobile originated voice call, and record the call setup messages listed in Table 6

2.1.4-1. 7

3GPP2 C.S0044-D v1.0

2-3

Table 2.1.4-1 Messages in Mobile Originated Call Setup 1

Item Message

1 Origination Message

2 Extended Channel Assignment Message

3 Status Request Message

4 Status Response Message

5 Service Request Message

6 Service Response Message

7 Service Connect Message

8 Service Connect Complete Message

2

d. Verify SERVICE_OPTION, FOR_RC_PREF, and REV_RC_PREF proposed in the 3

Origination Message correspond to the mobile configuration settings. If the 4

RC_BITMAP_CAPABILITY_EXT_ALLOWED in the System Parameters Message is set 5

to ‘0’ or is not included, verify that the mobile station does not include RL RC 8 in the 6

REV_FCH_RC_MAP and FL RC 11 or 12 in the FOR_FCH_RC_MAP in the FCH 7

Capability Information record that is included in the Origination Message. If the 8


to ‘1’, verify that the mobile station includes RL RC 8 in the REV_FCH_RC_MAP and 10

FL RC 11 /12 in the FOR_FCH_RC_MAP in the FCH Capability Information record that 11

is included in the Origination Message. Note inclusion of SO 73 depends on the value 12

of MAX_NUM_ALT_SO field of the Extended System Parameters Message. 13

e. Verify DEFAULT_CONFIG, GRANTED_MODE, FOR_RC, and REV_ RC in the 14

Extended Channel Assignment Message corresponds to the base station configuration 15

for service negotiation. 16

f. Verify service negotiation used in Service Request Message, Service Response 17

Message, and Service Connect Message proceed as desired. 18

g. If the base station sends a Status Request Message querying Capability Information 19

Record from the mobile station, verify the following: 20

1. If the RC_BITMAP_CAPABILITY_EXT_ALLOWED in the System Parameters 21

Message is set to ‘0’ or is not included, verify that the mobile station does not 22

include fields in the Capability Information Record that are not defined according 23

to the P_REV_IN_USE, 24


Message is set to ‘1’, verify that the mobile station includes the Capability 26

Information Record according to P_REV 12, 27

3GPP2 C.S0044-D v1.0

2-4

h. Verify the SERVICE_OPTION, FOR_FCH_RC, and REV_FCH_RC in the last Service 1

Configuration Record corresponds to the desired outcome of the base station service 2

negotiation configuration, and the call completes successfully. Note if the mobile station 3

indicated support for reverse link RC 8 or forward link RC 11 or 12 then the base station 4

may assign SO 73 even if this SO was not included by the mobile station in the 5

Origination Message. 6

i. End the call. 7

j. Repeat steps a through h for all supported configurations of mobile originated voice 8

service negotiation as supported by the mobile station and base station. This may 9

include call completion with the service configurations in Table 2.1.4-2. 10

Table 2.1.4-2 Service Configurations for Mobile Originated Voice Calls 11

Voice Service Option

RC_BITMAP_CAPABILITY_EXT_ALLOWED

Forward Radio Configuration

Reverse Radio Configuration

3 Not included or included

and set to ‘0’

1 1

17 or 32768 Not included or included

and set to ‘0’

2 2

3 Not included or included and

set to ‘0’

3 3

3 Not included or included and set to ‘0’

4 3

17 or 32768 Not included or included and set to ‘0’

5 4

3 or 68 or 73 Not included or included and set to ‘0’

3 3

3 or 68 or 73 Set to ‘1’ 11 8

12


The mobile station and the base station shall comply with step d, e, f, g h, and j.. 14

2.2 Mobile Station Terminated Voice Calls 15

2.2.1 Definition 16

This tests voice service negotiation and call completion of mobile station terminated voice calls, 17 for radio configurations and voice service options supported by the mobile station and base 18 station. 19

3GPP2 C.S0044-D v1.0

2-5


(see[4]) 2








2.7.2.3.2.12 Service Request Message 10



2.7.4.18 Service Configuration Record 13



Service Configuration Record (SO, RCs)


(DEFAULT_CONFIG, GRANTED_MODE, RCs)


Page Response Message (SO, RCs proposed)

General Page Message (SO proposed)

Release Order Messages

Voice Traffic


MS BS

common

channels

dedicated

channels

common

channels

initial service

configuration

possible new

service

configuration

15

3GPP2 C.S0044-D v1.0

2-6


a. Configure the base station for desired SERVICE_OPTION for the General Page 2

Message or Universal Page Message, and desired service negotiation listed in Table 3

2.2.4-2. 4

b. Allow the mobile station to come to the idle state on the base station. 5

c. Make a mobile station terminated voice call, and record the call setup messages listed 6

in Table 2.2.4-1. 7

Table 2.2.4-1 Messages in Mobile Station Terminated Call 8

Item Message

1 General Page Message or Universal Page Message

2 Page Response Message

3 Extended Channel Assignment Message

4 Status Request Message

5 Status Response Message

6 Service Request Message

7 Service Response Message

8 Service Connect Message

9 Service Connect Complete Message

9

d. Verify the SERVICE_OPTION proposed in the General Page Message corresponds to 10

the base station configuration setting. 11

e. Verify SERVICE_OPTION, FOR_RC_PREF, and REV_RC_PREF proposed in the 12

Page Response Message correspond to the mobile station configuration settings. If the 13


to ‘0’ or is not included, verify that the mobile station does not include RL RC 8 in the 15

REV_FCH_RC_MAP and FL RC 11 or 12 in the FOR_FCH_RC_MAP in the FCH 16

Capability Information record that is included in the Page Response Message. If the 17


to ‘1’, verify that the mobile station includes RL RC 8 in the REV_FCH_RC_MAP and 19

FL RC 11 /12 in the FOR_FCH_RC_MAP in the FCH Capability Information record that 20

is included in the Page Response Message. Note inclusion of SO 73 depends on the 21

value of MAX_NUM_ALT_SO field of the Extended System Parameters Message. 22

f. Verify DEFAULT_CONFIG, GRANTED_MODE, FOR_RC, and REV_RC in the 23

Extended Channel Assignment Message correspond to the base station configuration. 24

3GPP2 C.S0044-D v1.0

2-7

g. Verify that service negotiation using in Service Request Message, Service Response 1

Message, and Service Connect Message proceed as desired. 2

h. If the base station sends a Status Request Message querying Capability Information 3

Record from the mobile station, verify the following: 4


Message is set to ‘0’ or is not included, verify that the mobile station does not 6

include fields in the Capability Information Record that are not defined according 7

to the P_REV_IN_USE, 8


Message is set to ‘1’, verify that the mobile station includes the Capability 10

Information Record according to P_REV 12, 11

i. Verify the SERVICE_OPTION, FOR_FCH_RC, and REV_FCH_RC in the last Service 12

Configuration Record corresponds to the desired outcome of the base station service 13

negotiation configuration, and the call completes successfully. Note if the mobile station 14

indicated support for reverse link RC 8 or forward link RC 11 or 12 then the base station 15

may assign SO 73 even if this SO was not included by the mobile station in the Page 16


j. End the call. 18

k. Repeat steps a through i for all supported configurations of mobile station terminated 19

voice service negotiation as supported by the mobile station and base station. This 20

may include call completion with the service configurations in Table 2.2.4-2. 21

Table 2.2.4-2 Minimum Service Combinations for Mobile station Terminated Voice Calls 22

Service Option RC_BITMAP_CAPABILITY_EXT_ALLOWED

Forward Radio Configuration

Reverse Radio Configuration


1 1


2 2


3 3


4 3


5 4

3 or 68 or 73 Not included or included and set to ‘0’

3 3

3 or 68 or 73 Set to ‘1’ 11 8

23

3GPP2 C.S0044-D v1.0

2-8


The mobile station and the base station shall comply with steps d, e, f, g, h, i and k. 2

2.3 Busy Tone 3

2.3.1 Definition 4

This tests the mobile station response to a called-party-busy notification from a base station. 5


(see[4]) 7

2.6.4.4 Release Substate 8

3.6.4.3 Traffic Channel Substate 9


Table 3.7.5.5-3 Tone Signals 11


None 13


a. Allow the mobile station to come to the idle state on the base station. 15

b. Ensure the called party has no call-waiting or automatic voice mail enabled, and tie up 16

the line so that the mobile station will get a busy signal when it calls. 17

c. Attempt a mobile station originated call to the party. 18

d. Verify the mobile station plays a called-party-busy indication. 19


The mobile station shall comply with the requirement in steps d. 21

2.4 Mobile Station Origination Call with Inter Band Channel Assignment 22

2.4.1 Definition 23

This test verifies that the mobile station can initiate a call to a land party on aone band class and 24 then re-originate and completes the call the target band class after receiving a Channel 25 Assignment Message or Extended Channel Assignment Message with ASSIGN_MODE = ‘101’ 26 or ‘001’ respectively. 27


(See[4]) 29

2.6.2.4 Mobile Station Order and Message Processing Operation 30


3GPP2 C.S0044-D v1.0

2-9


3.7.2.3.2.8 Channel Assignment Message 2



None 5


a. Connect the mobile station and base stations as shown in Figure A-2. Base station 1 7

operates in a band class that is different from base station 2. 8

b. Ensure the mobile station acquires base station 1. 9

c. Configure Base station 1 so that Inter Band Channel Assignment is enabled. 10

d. Setup mobile station originated voice call. 11

e. Verify the mobile station originates on the serving base station and receives a Channel 12

Assignment Message with ASSIGN MODE=‘101’ or an Extended Channel Assignment 13

Message with ASSIGN MODE=’001’. Verify that the Channel Assignment Message or 14

Extended Channel Assignment Message contains assignment for paging channel on 15

base station 2, and RESPOND=1. 16

f. Verify the mobile station re-sends a second Origination Message to base station 2 and 17

the call completes successfully. 18

g. Verify user data in both directions. 19

h. End the call. 20

i. Repeat Steps d through g, but provision Base station 2 to be Inter Band Channel 21

Assignment enabled. The mobile station will originate on base station 2 and then re-22

originate on base station 1 after receiving the Channel Assignment Message or 23

Extended Channel Assignment Message. 24


The mobile station and base station shall comply with steps e, f, g, and i. 26

2.5 Mobile Station Terminated Call with Inter Band Channel Assignment 27

2.5.1 Definition 28

This test verifies that the mobile station can receive a call from a land party on one band class 29 and then resends the Page Response Message autonomously and completes the call on the 30 target band class after receiving a Channel Assignment Message or Extended Channel 31 Assignment Message with ASSIGN_MODE = ‘101’ or ‘001’ respectively. 32


(See[4]) 34

3GPP2 C.S0044-D v1.0

2-10

2.6.2.3 Mobile Station Page Match Operation 1

2.6.3.3 Page Response Substate 2





None 7



operates in a band class that is different from base station 2. 10

b. Ensure the mobile station acquires base station 1. 11

c. Configure base station 1 so that Inter Band Channel Assignment is enabled. 12

d. Setup mobile station terminated voice call. 13

e. Verify that the mobile station receives a Channel Assignment Message with ASSIGN 14

MODE=‘101’ or an Extended Channel Assignment Message with ASSIGN 15

MODE=’001’. Verify that the Channel Assignment Message or Extended Channel 16

Assignment Message contains assignment for paging channel on base station 2, and 17

RESPOND = ‘1’. 18

f. Verify the mobile station sends a second Page Response Message on the target base 19

station and the call completes. 20


h. End the call. 22

i. Repeat Steps d through g, but provision Base station 2 to be Inter Band Channel 23

Assignment enabled. The mobile station will send the Page Response Message on 24

base station 2 and then re-send the Page Response Message on base station 1 after 25

receiving the Channel Assignment Message or Extended Channel Assignment 26

Message. 27


The mobile station and the base station shall comply with steps e, f, g, and i. 29

2.6 DTMF 30

2.6.1 Definition 31

This is a test for Dual-Tone Multi-frequency (DTMF), sent by the mobile station in a Send Burst 32 DTMF Message or a Continuous DTMF Tone Order. It verifies that sequencing and tone duration 33 of the Send Burst DTMF Message and the Continuous DTMF Tone Order are preserved. 34

3GPP2 C.S0044-D v1.0

2-11


(see [4]) 2

2.7.2.3.2.7 Send Burst DTMF Message 3

2.7.2.3.2.1 Continuous DTMF Tone Order 4


Table 2.7.1.3.2.4-4 Representation of DTMF Digits 6

Table 2.7.2.3.2.7-1 Recommended DTMF Pulse Width 7

Table 2.7.2.3.2.7-2 Recommended Minimum Inter-digit Interval 8

Table 3.7.4-1 Order and Order Qual Codes Used on the f-csch and the f-dsch 9

Table 2.7.2.3-1 Messages on r-dsch 10


None 12


a. Equip a landline with a DTMF decoder that can verify DTMF digits received and DTMF 14

tone duration. 15

b. Configure the mobile station to send short DTMF tones. 16

c. Allow the mobile station to come to the idle state on the base station, and set up a voice 17

call to the equipped land party. 18

d. Press the keys 1234567890*#. 19

e. Verify the mobile station sends a Send Burst DTMF Message for each key press. 20

f. Verify DTMF tones are received correctly. 21

g. End the call. 22

h. Configure the mobile station to use long DTMF tones. 23

i. Setup a mobile station originated call. 24

j. Direct the mobile station to perform the following steps in. 25

1. Press and hold any number key on the keypad for approximately 5 seconds. 26

2. Verify the mobile station sends a Continuous DTMF Tone Order with the 27

appropriate ORDQ value to start and stop the DTMF tone. 28

3. Direct the mobile station to send characters 0123456789 * as one or more Send 29

Burst DTMF Message(s). 30

4. Press and hold any number key on the keypad for approximately 5 seconds. 31

5. Again press and hold any number key on the keypad for approximately 5 32

seconds. 33

3GPP2 C.S0044-D v1.0

2-12

k. Verify all DTMF digits are decoded correctly and in the right order at the land party 1

DTMF decoder. 2

l. Verify the three 5-second key presses produce DTMF tones approximately 5 seconds in 3

duration. 4


The mobile station shall comply with requirements in steps e, f, k and l. 6

2.7 Slot Cycle Index 7

2.7.1 Definition 8

If the mobile station supports slotted operation, this test verifies the mobile station response to the 9 base station MAX_SLOT_CYCLE_INDEX setting for various settings of mobile station 10 SLOT_CYCLE_INDEX. 11


(see [4]) 13



3.6.2.3 Mobile Station Directed Messages 16




2.7.4.7 Terminal Information 20


None 22


a. Configure the mobile station internal setting of SLOT_CYCLE_INDEXP and also base 24

station System Parameter Message or MC-RR Parameters Message setting of 25

MAX_SLOT_CYCLE_INDEX in the first row in Table 2.7.4-1. 26

3GPP2 C.S0044-D v1.0

2-13

Table 2.7.4-1 Mobile station and Base Station Settings for Slot Cycle Index Test 1

Test_ID MAX_SLOT_CYCLE_INDEX (base

station)

SLOT_CYCLE _INDEXP (mobile station)

Slot Cycle Index Used

Slot Cycle Length, seconds

1 2 0 0 1.28

2 2 1 1 2.56

3 2 2 2 5.12

4 2 3 2 5.12

5 3 3 3 10.14

b. Allow the mobile station to come to the idle state in slotted mode on the base station. 2

c. Examine that the mobile station wakes up in the assigned slots to read the Paging 3

Channel at the interval of the Slot Cycle Length in Table 2.7.4-1. 4

d. Make a mobile station terminated call, verify the base station pages the mobile station 5

in the appropriate slot. 6

e. Verify the call completes successfully. 7

f. Repeat steps a through d for each of the other row Test ID combinations in Table 8

2.7.4-1. 9


The mobile station and the base station shall comply with requirements in steps c, d, e and f. 11

2.8 Reverse Radio Link Failure 12

2.8.1 Definition 13

This tests mobile station’s response to a 15 second loss of the reverse RF link in the conversation 14 state when Call Recovery Request Message is not supported by the mobile station or the base 15 station. 16


(see [6]) 18

3.7 Supervision 19

(see [3]) 20

Table 2.2.1.1.3-1 Accumulated ARQ Statistics for Regular PDU’s 21


3GPP2 C.S0044-D v1.0

2-14






Origination Message

Voice Traffic

Service Connect Complete Message

MS BS

common

channels

dedicated

channels

initial service

configuration

possible new

service

configuration

2


a. Configure a test setup with a connection of a single base station and the mobile station 4

to allow the reverse radio link to be abruptly attenuated or interfered-with, enough to 5

cause continuous loss of all reverse frames as exemplified in Figure 2-1 6

base station 1

AWGN

MobileDiagnostic and Control Tool

CDMA Analyzer

Fixed Atten Vari Atten

Reverse Link

Forward Link

DuplexerDuplexer

7

Figure 2-1 Test Setup for Radio Link Failure 8

b. Configure the setup for good RF links as specified in ANNEX B. 9

c. Allow the mobile station to come to the idle state on the base station. 10

d. Attempt a mobile station originated call. 11

e. Abruptly cause loss of the reverse RF link after voice call is established. 12

3GPP2 C.S0044-D v1.0

2-15

f. Restore the normal RF link after a minimum of 15 seconds. . Note, if the base station 1

indicates support for Call Recovery Request Message by setting the CRRM_MSG_IND 2

bit in the System Parameters Message to ‘1’ then the RF link should be restored after a 3

minimum of 20 seconds. 4

g. Verify the call is released. 5

h. Verify the mobile station returns to the idle state on the base station. 6


The mobile station shall comply with the requirements in steps g and h. 8

2.9 Channel Assignment from CDMA to Analog 9

2.9.1 Definition 10

This test will verify that a base station assigns a mobile station to analog (e.g. AMPS) when no 11 CDMA traffic channels are available. 12


(see [4]) 14

2.6.1.1.2 System Selection Using Current Redirection Criteria 15



None 18


a. Connect the base station and mobile station as shown in Annex A Figure A - 5. 20

b. Take all CDMA traffic channel radio resources out of service or configure the base 21

station to behave in a similar fashion. Configure the base station to assign analog 22

channel. 23

c. Setup a mobile station originated call. 24

d. Verify that the base station sends a Channel Assignment Message or Extended 25

Channel Assignment Message with ASSIGN_MODE=‘011’ to assign the mobile station 26

an analog voice channel or with ASSIGN_MODE=‘010’ to acquire the analog system. 27

e. Verify the mobile station acquires the analog system. 28

f. Verify user data in both directions. 29

g. End call. 30


The mobile station and the base station shall comply with the requirements in steps d, e, and f. 32

3GPP2 C.S0044-D v1.0

2-16

2.10 Network Busy 1

2.10.1 Definition 2

This tests mobile station response to a base station blocking condition during mobile station call 3 origination. 4


(see [4]) 6

Table 3.7.4-1 Order and Order Qualification Codes 7

3.6.2.3 Mobile Station Directed Messages, Reorder Order 8

Table 3.7.5.5-3 Tone Signals 9




None 13



b. Take all traffic channel resources out of service or configure the base station to behave 16

in a similar fashion. Configure the base station to send a network-busy indication. 17

c. Attempt a mobile station originated call. 18

d. Instruct the base station to send a Reorder Order to the mobile station. 19

e. Verify the mobile station indicates a call failure due to network-busy, (e.g. For voice 20

service options, the mobile station will play a reorder tone ). Note any anomalies in the 21

mobile station behavior due to receiving the Reorder Order.. 22

f. Steps a through e may be repeated for different service options supported such as 23

service option 33. 24


The mobile station shall comply with the requirements in step e for all tested service options. 26

2.11 Release Order on the Access Channel 27


This test verifies the mobile station can send a Release Order on the Access Channel during call 29 origination before switching to dedicated channel transmission. 30


(see [4]) 32

3GPP2 C.S0044-D v1.0

2-17

3.6.3 Access Channel Processing 1

3.6.3.4 Response to Orders 2

2.6.3 System Access State 3

2.6.3.1.4 System Access State Exit Procedures 4


2.1.1.2.2.1 Overview of Transmission and Retransmission Procedures (see [3]) 6


BSMSOrigination Message

Common

ChannelsRelease Order

Order

Ack Order

8



b. Attempt a mobile station originated call. 11

c. Shortly after the mobile station has received acknowledgement of its Origination 12

Message, terminate the call attempt from the mobile station side, e. g. press the mobile 13

station END key, before the mobile station switches to dedicated channel transmission. 14

d. Verify the mobile station sends a Release Order (normal release) on the Access 15

Channel in assured mode requiring confirmation of delivery, aborts the call attempt, and 16

returns to the idle state on the base station. 17


The mobile station shall comply with the requirements in step d. 19


True IMSI addressing supported by the base station and mobile station 21


This test verifies that the base station pages the mobile station with True IMSI addressing 23 supported by the base station and mobile station when the MCC and IMSI_11_12 of the mobile 24 station match those sent by the base station in the Extended System Parameters Message or 25 ANSI-41 System Parameters Message. 26


(See[4]) 28

3GPP2 C.S0044-D v1.0

2-18

2.3.1.1 Encoding of IMSI_M_S and IMSI_T_S 1

2.3.1 Mobile Station Identification Number 2

2.3.1.3 Encoding of the MCC_M and MCC_T 3

2.6.2.2.5 Extended System Parameters Message 4

2.7.4.24 IMSI_T 5



None 8



b. Ensure the mobile station is programmed with the same values of MCC and 11

IMSI_11_12 used in the base station. Do not use MCC (wild card) value in the base 12

station. 13

c. Configure the base station to send the Extended System Parameters Message or 14

ANSI-41 System Parameters Message with the value IMSI_T_SUPPORTED=1. 15

d. Enable power-up registration. 16

e. Enable authentication. Configure the base station to disallow mobile station terminated 17

calls if authentication fails. 18

f. Power on the mobile station and wait for power-up registration to occur. 19

g. Initiate a land party to mobile station call. 20

h. Verify user data in both directions and end call at the mobile station. 21


The mobile station shall comply with step h. 23


True IMSI addressing supported by the base station with MIN-based addressing 25

supported by the mobile station. 26


This test verifies that the base station pages the mobile station with True IMSI addressing 28 supported by the base station and MIN-based addressing supported by the mobile station when 29 the MCC and IMSI_11_12 of the mobile station match those sent by the base station in the 30 Extended System Parameter Message or ANSI-41 System Parameters Message. 31


(see [4]) 33

3GPP2 C.S0044-D v1.0

2-19





2.7.4.24 IMSI_T 5



None 8





station. 13



d. Enable power on registration. 16




g. Initiate a land party call to the mobile station. 20

h. Verify user data and end call at the mobile station. 21




True IMSI addressing not supported by the base station 25


This test will verify the base station pages the mobile station when the base station does not 27 support True IMSI addressing, when the MCC and IMSI_11_12 of the mobile station match those 28 sent by the base station in the Extended System Parameters Message or ANSI-41 System 29 Parameters Message. 30


(see [4]) 32


3GPP2 C.S0044-D v1.0

2-20




2.7.4.24 IMSI_T 4



None 7





station. 12











2.15 True IMSI Support, Land Party to Mobile Station Call, Different MCC and IMSI_11_12 23


This test verifies the base station selects one of the valid forms of paging channel address when 25 neither the MCC nor the IMSI_11_12 of the mobile station being addressed match those being 26 sent by the base station in the Extended System Parameters Message or ANSI-41 System 27 Parameters Message. 28


(see [4]) 30




3GPP2 C.S0044-D v1.0

2-21


2.7.4.24 IMSI_T 2



None 5



b. Ensure the mobile station is programmed with different values of MCC and IMSI_11_12 8

than those used in the base station. Do not use MCC (wild card) value in the base 9

station. 10











2.16 PACA Origination, User Terminates While Still In Queue 21


This test verifies that a PACA-capable mobile station, upon failure to originate a call due to lack of 23 available voice/traffic channels, shall re-attempt the origination using the PACA feature code. It 24 verifies that a currently queued mobile station properly informs the base station when a user 25 aborts waiting for traffic channel. 26


(see [4]) 28

2.6.2 Mobile Station Idle State 29

2.6.2.8 Mobile Station PACA Cancel Operation 30



2.7.1.3.2.9 PACA Cancel Message 33

3GPP2 C.S0044-D v1.0

2-22

3.7.2.3.2.20 PACA Message 1


None 3



b. At the base station, enable PACA feature for the mobile station, assign a PACA priority 6

level to the mobile station, and disable Permanent Invocation PACA for the mobile 7

station. 8

c. If the mobile station is capable of Slotted Mode, verify that the mobile station is 9

operating in the Slotted Mode. 10

d. Ensure PACA is enabled on base station. 11

e. Configure the base station to make all traffic channels busy. 12

f. Setup a mobile station originated call. 13

g. Verify the following: 14

1. Mobile station originates call with PACA_REORIG bit='0' in Origination Message. 15

2. Base station replies with Reorder Order. 16

3. Mobile station retries the origination with the PACA_REORIG bit='1' in the 17


4. Base station sends PACA Message with PURPOSE='0000' and the mobile 19

station’s Queue Position (Q_POS). 20

5. Mobile station acknowledges PACA Message. 21

h. The mobile station user interface should indicate the origination has been successfully 22

queued. 23

i. Verify the mobile station remains in non-slotted mode. 24

j. End call to terminate queued origination. Verify that the mobile station sends a PACA 25

Cancel Message to the base station. 26

k. Verify the mobile station enters slotted mode if applicable. 27


The mobile station shall comply with the requirements in steps c, g, i, j, and k. 29

2.17 PACA Origination, Idle Handoff While in Queue 30


This test verifies that a PACA-capable mobile station already in a PACA queue shall re-originate 32 the PACA request when the mobile station performs an idle handoff. 33

3GPP2 C.S0044-D v1.0

2-23


(see [4]) 2








None 10




level to mobile station, and disable Permanent Invocation PACA for mobile station. 14

c. Ensure PACA is enabled on both base stations. 15

d. Configure both base stations to make all traffic channels busy. 16

e. Setup a mobile station originated call. 17

f. The mobile station user interface should indicate origination successfully queued. 18

g. Force an idle handoff from base station 1 to base station 2. 19

h. Verify the mobile station re-originates the PACA request with PACA_REORIG='1'. 20

i. Verify a PACA Message is received from base station 2 indicating the mobile station’s 21

position in the PACA queue of base station 2. 22

j. On the mobile station, originate a new call while still queued. 23

k. The mobile station user interface should indicate to the user that the first PACA call has 24

been cancelled. 25


The mobile station shall comply with the requirements in steps h, i and k. 27

2.18 PACA Origination, Traffic Channel Becomes Available 28


This test verifies that a currently PACA queued mobile station, when notified by the base station 30 of an available traffic channel, should properly alert the user that the origination can now be 31 completed. 32

3GPP2 C.S0044-D v1.0

2-24


(see [4]) 2








None 10





station. 15

c. Ensure PACA is enabled on the base station. 16

d. Configure the base station to make all traffic channels busy. 17


f. If supported by the mobile station, verify that the mobile station user interface indicates 19

that an origination has been successfully queued. 20

g. Make at least one traffic channel available on the base station. 21

h. The base station shall page the mobile station, and the mobile station should indicate to 22

the user that the PACA call is proceeding. 23

i. Verify the call is completed and audio is present in both directions. 24

j. End call. 25


The mobile station shall comply with the requirements in steps f and i. 27

2.19 PACA Origination, Features Interaction 28


This test verifies that specific paging channel features, such as SMS and MWI, are delivered to 30 the mobile station while the mobile station is currently in a PACA queue. 31

3GPP2 C.S0044-D v1.0

2-25


(see [4]) 2








None 10





station. 15




f. Verify the mobile station user interface indicates that an origination has been 19

successfully queued. 20

g. Send an SMS message over the Paging Channel to the mobile station. Verify the 21

message is properly received by the mobile station. 22

h. Configure base station to send MWI to the mobile station. Verify MWI is displayed by 23

the mobile station. 24

i. End call. 25


The mobile station shall comply with the requirements in steps f, g, and h. 27

2.20 PACA Origination, Permanent Invocation 28


This test verifies that a PACA-capable mobile station with Permanent Invocation feature enabled 30 shall be placed in PACA queue even if PACA is not requested in Origination Message. 31


(see [4]) 33

3GPP2 C.S0044-D v1.0

2-26








None 8




level to the mobile station, and enabled Permanent Invocation PACA for the mobile 12

station. 13





1. Mobile station originates call with PACA_REORIG bit='0' in Origination Message. 18

2. Due to Permanent Invocation, base station sends PACA Message with 19

PURPOSE='0000' and the mobile station's Queue Position (Q_POS). 20

3. Mobile station acknowledges PACA Message. 21

4. The mobile station user interface should indicate origination successfully queued. 22

g. Make at least one traffic channel available on the base station. 23

h. The base station shall page the mobile station, and the mobile station should indicate to 24

the user that the PACA call is proceeding. 25

i. Verify call completes and audio is present in both directions. 26

j. End call. 27


The mobile station shall comply with the requirements in steps f and j. 29

3GPP2 C.S0044-D v1.0

2-27

2.21 PACA Origination, PACA Disabled for Mobile Station 1

2.21.1 Definition 2

This test verifies that when a mobile station disabled for PACA attempts a PACA Origination, the 3 call shall fail. 4


(see [4]) 6






3.7.2.3.2.20 PACA Message 12


None 14



b. Ensure PACA is enabled on the base station. 17

c. At the base station, disable PACA feature for the mobile station. 18




1. Mobile station originates call with PACA_REORIG bit=0 in Origination Message. 22

2. Due to lack of available channels, base station replies with a Reorder Order. 23

3. Mobile station retries the origination with the PACA_REORIG bit = '1' in the 24


4. A second call re-origination attempt is denied by the base station and a reorder 26

tone is generated at the mobile station. 27


The mobile station shall comply with the requirements in step f. 29

3GPP2 C.S0044-D v1.0

2-28

2.22 Service Configuration and Negotiation without SYNC_ID 1

2.22.1 Definition 2

This test verifies that the initial service configuration in effect is according to the value specified 3 via the GRANTED_MODE field of the Extended Channel Assignment Message. This test also 4 verifies that after service negotiation, the service configuration in use is the one specified by SCR 5 and NN-SCR agreed upon during service negotiation. 6


(see [4]) 8

2.6.4.1.2 Mobile Station Service Configuration and Negotiation procedures 9






2.7.2.3.2.12 (Mobile Station) Service Request Message 15

2.7.2.3.2.13 (Mobile Station) Service Response Message 16

2.7.2.3.2.14 (Mobile Station) Service Connect Completion Message 17

2.7.4.18 Service Configuration information record 18

3.6.4.1.2 Base Station Service Configuration and Negotiation procedures 19


3.7.3.3.2.18 (Base Station) Service Request Message 21

3.7.3.3.2.19 (Base Station) Service Response Message 22

3.7.3.3.2.20 (Base Station) Service Connect Message 23

3.7.3.3.2.31 General Handoff Direction Message 24

3.7.3.3.2.36 Universal Handoff Direction Message 25

3.7.5.7 (Base Station) Service Configuration information record 26

3.7.5.20 (Base Station) Non-Negotiable Service Configuration information record 27

3GPP2 C.S0044-D v1.0

2-29

2.22.3 Reference Call Flow 1

BS

Dedicated

Channels

MS

Dedicated

Channels

Service Connect Message/

General Handoff Direction Message/

Universal Handoff Direction Message

(SCR_new, NN-SCR_new)

New service

configuration

takes effect

Common

Channels

Common

Channels

Origination Message /

Page Response Message

(SO)


(GRANTED_MODE)

Initial service

configuration

in effect

Service Connect Completion Message/

Extended Handoff Completion Message

Optional Service Negotiation Message Exchange

(Service Negotiation ends with two message below)

2

Figure 2-2 Reference Call Flow for Service Configuration and Negotiation without SYNC_ID 3


Note – In this test case, it shall be ensured that mobile station does not include SYNC_ID field in 5 the Origination Message/Page Response Message. This can be done by selecting type of call for 6 which corresponding service configuration is not stored in mobile station. Note that the mobile 7 station needs to store service configuration per SID, NID. Hence changing SID or NID or CDMA 8 channel may be useful in ensuring that mobile station does not include SYNC_ID field in the 9 Origination Message/Page Response Message. 10


b. If the mobile station supports voice call, initiate a mobile station originated voice call. 12

Otherwise go to step f. 13

c. After the base station sends an Extended Channel Assignment Message to the mobile 14

station, the service negotiation shall occur between base station and mobile station. 15

The service negotiation ends when base station sends Service Connect 16

Message/General Handoff Direction Message/Universal Handoff Direction Message 17

with SCR and NN-SCR to the mobile station and mobile station accepts the service 18

configuration by sending Service Connect Completion Message/Extended Handoff 19

Completion Message. 20

d. Verify the following: 21

1. If the base station sends Extended Channel Assignment Message with 22

GRANTED_MODE field set to ‘00’ in step c above 23

3GPP2 C.S0044-D v1.0

2-30

a. Prior to the new service configuration sent in the Service Connect 1

Message/General Handoff Direction Message/Universal Handoff 2

Direction Message takes effect, verify the following: 3

1. The service configuration in use is the one jointly specified by the 4

DEFAULT_CONFIG value sent in the Extended Channel 5

Assignment Message and the default Non-Negotiable part of the 6

service configuration parameters specified in the Traffic Channel 7

Initialization substate. 8

b. When the new service configuration sent in the Service Connect 9



1. The service configuration in use is the one specified by SCR and 12

NN-SCR in the Service Connect Message/General Handoff 13

Direction Message/Universal Handoff Direction Message sent by 14

the base station. 15

2. Verify user traffic on both directions. 16

3. The base station receives a Service Connect Completion 17

Message (if base station sends Service Connect Message) or an 18

Extended Handoff Completion Message (if base station sends 19

General Handoff Direction Message/Universal Handoff Direction 20

Message) from the mobile station. 21

2. If base station sends Extended Channel Assignment Message with 22






default multiplex option that is derived from the radio 28

configuration corresponding to Table 3.7.2.3.2.21-7 of [4] and the 29

default Non-Negotiable part of the service configuration 30

parameters specified in the Traffic Channel Initialization 31

substate. 32





NN-SCR in the Service Connect Message sent by the base 37

station. 38

2. Verify user traffic in both directions. 39



3GPP2 C.S0044-D v1.0

2-31




3. If base station sends Extended Channel Assignment Message with 4






default multiplex option that is derived from the radio 10

configuration corresponding to Table 3.7.2.3.2.21-7 of [4] and the 11

default Non-Negotiable part of the service configuration 12

parameters specified in the Traffic Channel Initialization 13

Substate. 14






station. 20

2. Verify user traffic on both directions. 21






4. The mobile station does not send a Service Request Message to 27

the base station prior to the Service Connect Message/General 28

Handoff Direction Message/Universal Handoff Direction 29

Message is received from the base station. 30

e. Repeat steps a through d for mobile station terminated calls. In this case, Page 31

Response Message replaces Origination Message. 32

f. If mobile station supports data calls, repeat steps a to e above but with following 33

modification – In step b initiate data call in place of voice call. 34



3GPP2 C.S0044-D v1.0

2-32

2.23 Service Configuration and Negotiation with SYNC_ID 1

2.23.1 Definition 2

This test verifies that the mobile station can propose to use stored service configuration using 3 SYNC_ID in the Service Configuration and Negotiation process. 4

Note – This test assumes that the mobile station stores old service configuration with 5 corresponding SYNC_ID and uses SYNC_ID during call setup. If the mobile station does not use 6 SYNC_ID in call setup, then skip this test. This test also assumes that the base station sets 7 USE_SYNC_ID field to ‘1’ in Extended System Parameters Message and/or MC-RR Parameters 8 Message. If the base station is unable to do this, then skip this test. 9


(see [4]) 11


2.6.2.2.14.1 Stored Parameters 13

2.6.2.5 Mobile Station Origination Operation 14



2.6.4.1.2 (Mobile Station) Service Configuration and Negotiation (procedures) 17





2.6.6.2.5 Handoff Messages 22

2.6.6.2.5.1 Processing of Forward Traffic Channel Handoff Messages 23



2.7.2.3.2.12 (Mobile Station) Service Request Message 26

2.7.2.3.2.13 (Mobile Station) Service Response Message 27

2.7.2.3.2.14 (Mobile Station) Service Connect Completion Message 28

2.7.4.18 (Mobile Station) Service Configuration (information record) 29

3.6.4.1.2 (Base Station) Service Configuration and Negotiation (procedures) 30



3.7.2.3.2.31 MC-RR Parameters Message 33

3.7.3.3.2.18 (Base Station) Service Request Message 34

3GPP2 C.S0044-D v1.0

2-33

3.7.3.3.2.19 (Base Station) Service Response Message 1

3.7.3.3.2.20 (Base Station) Service Connect Message 2



3.7.5.7 (Base Station) Service Configuration (information record) 5

3.7.5.20 (Base Station) Non-Negotiable Service Configuration (information record) 6

2.23.3 Reference Call Flow 7

BS

Dedicated

Channels

MS

Dedicated

Channels


(USE_OLD_SERV_CONFIG,

SCR_new, NN-SCR_new)

New service

configuration

takes effect

Common

Channels

Common

Channels



(SYNC_ID)


(GRANTED_MODE)

Initial service

configuration

in effect


Optional Service Negotiation Message Exchange

(Service Negotiation ends with two messages below)

8

Figure 2-3 Reference Call Flow for Service Configuration and Negotiation with SYNC_ID 9


a. Connect the mobile station to the base station as shown in Annex A Figure A-1. Verify 11

that the base station sets USE_SYNC_ID field to ‘1’ in Extended System Parameters 12

Message and/or MC-RR Parameters Message. 13

b. Identify a type of call for which the base station would send the SYNC_ID with SCR and 14

NN_SCR and the mobile station would use SYNC_ID when the same type of call is 15

originated again. Initiate a mobile station originated call with this call type. Verify that 16

the base station includes SYNC_ID field in the Service Connect Message/General 17

Handoff Direction Message/Universal Handoff Direction Message sent to the mobile 18

station. Once the service configuration sent in the Service Connect Message/General 19

Handoff Direction Message/Universal Handoff Direction Message has taken effect, 20

disconnect the call. 21

3GPP2 C.S0044-D v1.0

2-34

c. Initiate a mobile station originated call with same call type as above. Verify that mobile 1

station includes SYNC_ID field in the Origination Message. 2

d. The service negotiation ends when base station sends Service Connect Message to the 3

mobile station and mobile station accepts the service configuration by sending Service 4

Connect Completion Message. 5

e. Verify the following: 6

1. If the base station sends Service Connect Message with 7

USE_OLD_SERV_CONFIG field set to ‘00’ 8

a. When the Service Connect Message takes effect, verify the following: 9



station. 12

2. Verify user traffic (e.g. SO 33) on both directions. 13


Message from the mobile station. 15



a. When the new service configuration specified in the Service Connect 18

Message takes effect, verify the following: 19

1. The mobile station uses the stored service configuration. 20






a. When the Service Connect Message takes effect, verify the following: 26

1. The mobile station uses the stored service configuration. 27




f. Repeat steps a through d for mobile station terminated calls. In this case, Origination 31

Message is replaced by Page Response Message. 32


The mobile station shall comply with step e. 34

3GPP2 C.S0044-D v1.0

2-35

2.24 Intra-Band Channel Assignment 1

2.24.1 Definition 2

This test verifies that the mobile station originating a call can be assigned a different frequency 3 within the same band class using the (Extended) Channel Assignment Message. 4


(See[4]) 6








None 14



and base station 2 are operating the same band class with different frequencies. 17

b. Ensure the mobile station is operating in the Idle State on base station 1. 18


d. Ensure that the base station sends a Channel Assignment Message or Extended 20

Channel Assignment Message with the following settings: 21

22

Table 2.24.4-1 Channel Assignment Message Settings 23

Field Value

ASSIGN_MODE ‘100’

FREQ_INCL ‘1’

BAND_CLASS Target Band Class (same

as base station 1)

CDMA_FREQ Target Frequency for base

station 2

24

3GPP2 C.S0044-D v1.0

2-36

Table 2.24.4-2 Extended Channel Assignment Message Settings 1

Field Value

ASSIGN_MODE ‘000’ or ‘100’

FREQ_INCL ‘1’

BAND_CLASS Target Band Class (same

as base station 1)

CDMA_FREQ Target Frequency for base

station 2

2

e. Verify the mobile station tunes to the new frequency and completes the call on base 3

station 2. 4


g. End the call. 6

h. Setup a mobile station terminated call and repeat steps d through g. 7

i. If the base station supports General Extension Message repeat steps d through h by 8

sending the Extended Channel Assignment Message included in a General Extension 9

Message. 10


The mobile station shall comply with steps e, f, and h. 12

2.25 Silent-Retry 13


This test verifies the mobile station silent-retry functionality and the proper setting of ARQ fields. 15 Silent-retry is an autonomous access re-attempt that is made to re-originate the call, without user 16 interaction, that is due to the mobile station receiving an access attempt failure from the ARQ 17 Sublayer. 18


2.7.1.3.2.4 Origination Message (see [4]) 20

(see [2]) 21

2.2.1.1.2.1.5 Access Channel Procedures 22

(see [3]) 23

2.1.1.2.1.2 Requirements for Setting the ARQ Fields 24

2.1.1.2.2.1 Overview of Transmission and Retransmission Procedures 25

26

3GPP2 C.S0044-D v1.0

2-37


None 2


a. Connect the base station as shown in Figure A-3. Disable the reverse link to the base 4

station. 5

b. Attempt to setup a mobile station originated call. Note the MSG_SEQ value in the 6


c. Allow the mobile station to exhaust NUM_STEP or EACH_NUM_STEP and 8

MAX_REQ_SEQ as defined in the Access Parameters Message or Enhanced Access 9


d. Enable the reverse link to the base station. 11


1. If the P_REV_IN_USE is less than or equal to six verify; 13

a. The mobile station sends a new Origination Message. 14

b. The MSG_SEQ value in the Origination Message is different than the 15

value recorded in step b. 16

2. Otherwise, verify; 17

a. The mobile station sends a new Origination Message with the following 18

values: 19

20

FIELD VALUE

ORIG_REASON ‘1’

ORIG_COUNT Number of consecutive silent-

retry. If the value is greater than

three, the mobile station shall

set this value to ‘11’.

b. The MSG_SEQ value in the Origination Message is different than the 21

value recorded in step b. 22

f. Verify the call completes and user traffic is present in both directions (i.e. audio). 23


The mobile station shall comply with steps e and f. 25

26

3GPP2 C.S0044-D v1.0

2-38

2.26 MSID, MCC, and IMSI 1

2.26.1 Definition 2

These tests verify some protocol of the Mobile Station IDentifier number (MSID or MSIN), Mobile 3 Country Code (MCC), and International Mobile Station Identity (IMSI). Mobile station response to 4 three instances of base station PREF_MSID_TYPE are checked when the MCC and IMSI_11_12 5 of the mobile station and base station match do not match or are wildcard values. 6


(see [4]) 8



2.6.2.3 Mobile Station Page Match Operation 11


2.3.1.1 Encoding of IMSI_M_S and IMSI_T_S 11 13

Table 3.7.2.3.2.13-1 Preferred MSID Types 14

3.6.2.2 Overhead Information 15

(see [3]) 16

2.1.1.3.1.1 Addressing 17

2.1.1.2.1.3 IMSI Class 18

2.26.2.1.1 Call Flow Diagram 19

None 20


For each step below with IMSI_CLASS = 0, set USE_TMSI = ‘0’ in the base station Extended 22 System Parameters Message or ANSI-41 System Parameters Message. Also program either the 23 mobile station or the base station for the values of MCC and IMSI_11_12, to achieve the 24 matching or non-matching conditions indicated. 25

a. PREF_MSID_TYPE = ‘00’. Configure the base station Extended System Parameters 26

Message with PREF_MSID_TYPE = ‘00’. Make a mobile station originated call and a 27

mobile station terminated call. Verify the mobile station sets MSID_TYPE = ’000’ and 28

sends IMSI_S and ESN in the Origination Message and Page Response Message. 29

b. PREF_MSID_TYPE = ‘10’, matching MCC and matching IMSI_11_12. Configure the 30

base station Extended System Parameters Message with PREF_MSID_TYPE = ‘10’. 31

Verify the values of both MCC and IMSI_11_12 are the same (match) in the mobile 32

station and base station. Make a mobile station originated call and a mobile station 33

terminated call. Verify the mobile station sets MSID_TYPE = ‘010’ and sends IMSI_S 34

(does not send MCC and IMSI_11_12) in the Origination Message and Page Response 35

Message. 36

3GPP2 C.S0044-D v1.0

2-39

c. PREF_MSID_TYPE = ‘10’, non-matching MCC and matching IMSI_11_12. Configure the 1


Verify the values of IMSI_11_12 are the same (match) in the mobile station and base 3

station, but the values of MCC are different (don’t match). Make a mobile station 4

originated call and a mobile station terminated call. Verify the mobile station sets 5

MSID_TYPE = ‘010’ and sends MCC and IMSI_S (does not send IMSI_11_12) in the 6

Origination Message and Page Response Message. 7

d. PREF_MSID_TYPE = ‘10’, matching MCC and non-matching IMSI_11_12. Configure the 8


Verify the values of MCC are the same (match) in the mobile station and base station, but 10

the values of IMSI_11_12 are different (don’t match). Make a mobile station originated 11

call and a mobile station terminated call. Verify the mobile station sets MSID_TYPE = 12

‘010’ and sends IMSI_11_12 and IMSI_S (does not send MCC) in the Origination 13

Message and Page Response Message. 14

e. PREF_MSID_TYPE = ‘10’, non-matching MCC and non-matching IMSI_11_12. 15

Configure the base station Extended System Parameters Message with 16

PREF_MSID_TYPE = ‘10’. Verify the values of both MCC and IMSI_11_12 are different 17

in the mobile station and base station (neither matches). Make a mobile station originated 18


‘010’ and sends MCC, IMSI_11_12 and IMSI_S in the Origination Message and Page 20


f. PREF_MSID_TYPE = ‘10’, wildcard MCC and wildcard IMSI_11_12. Configure the base 22

station Extended System Parameters Message with the following fields. 23

24

Field Value

PREF_MSID_TYPE ‘10’

MCC ‘1111111111’ (wildcard)

IMSI_11_12 ‘1111111’ (wildcard)

g. Make a mobile station originated call and a mobile station terminated call. Verify the 25

mobile station sets MSID_TYPE = ‘010’ and sends IMSI_S (but does not send MCC and 26

IMSI_11_12) in the Origination Message and Page Response Message. 27

h. PREF_MSID_TYPE = ‘11’, matching MCC and matching IMSI_11_12. Configure the 28


Verify the values of both MCC and IMSI_11_12 are the same in the mobile station and 30

base station (both match). Make a mobile station originated call and a mobile station 31

terminated call. Verify the mobile station sets MSID_TYPE = ‘011’ and sends IMSI_S 32

and ESN (does not send MCC and IMSI_11_12) in the Origination Message or Page 33


3GPP2 C.S0044-D v1.0

2-40

i. PREF_MSID_TYPE = ‘11’, non-matching MCC and matching IMSI_11_12. Configure the 1


Verify the values of IMSI_11_12 are the same in the mobile station and base station 3

(match), but the values of MCC are different (don’t match). Make a mobile station 4

originated call and a mobile station terminated call. Verify the mobile station sets 5

MSID_TYPE = ‘011’ and sends MCC, IMSI_S and ESN (does not send IMSI_11_12) in 6

the Origination Message and Page Response Message. 7

j. PREF_MSID_TYPE = ‘11’, matching MCC and non-matching IMSI_11_12. Configure the 8


Verify the values of MCC are the same in the mobile station and base station (match), but 10

the values of IMSI_11_12 are different (don’t match). Make a mobile station originated 11


‘011’ and sends IMSI_11_12, IMSI_S and ESN (does not send MCC) in the Origination 13

Message and Page Response Message. 14

k. PREF_MSID_TYPE = ‘11’, non-matching MCC and non-matching IMSI_11_12. 15

Configure the base station Extended System Parameters Message with 16

PREF_MSID_TYPE = ‘11’. Verify the values of both MCC and IMSI_11_12 are different 17

in the mobile station and base station. Make a mobile station originated call and a mobile 18

station terminated call. Verify the mobile station sets MSID_TYPE = ‘011’ and sends 19

MCC, IMSI_11_12, IMSI_S, and ESN in the Origination Message and Page Response 20

Message. 21

l. PREF_MSID_TYPE = ‘11’, wildcard MCC and wildcard IMSI_11_12. Configure the base 22

station Extended System Parameters Message with the following fields. 23

24

Field Value

PREF_MSID_TYPE ‘11’

MCC ‘1111111111’ (wildcard)

IMSI_11_12 ‘1111111’ (wildcard)

25

m. Make a mobile station originated call and a mobile station terminated call. Verify the 26

mobile station sets MSID_TYPE = ‘011’ and sends IMSI_S and ESN (but does not send 27

MCC and IMSI_11_12) in the Origination Message and Page Response Message. 28


All calls shall complete normally. The mobile station shall comply with requirements in steps b 30 through m. 31

3GPP2 C.S0044-D v1.0

2-41

2.27 RL RC 8 / FL RC 11 Parameter Change using RCPM 1

2.27.1 Definition 2

This test verifies that the mobile station and base station can use Radio Configuration 3 Parameters Message for changing Reverse Link RC 8 and/or Forward Link RC 11 or RC 12 4 parameters. 5


(See[4]) 7

2.7.1.3.2.2 Order Message 8


2.7.1.3.2.2.4 Origination Message 10






3.7.3.3.2.51 Radio Configuration Parameters Message 16


18

3GPP2 C.S0044-D v1.0

2-42



(RC bitmap, Alt SO)

Order Message

(acknowledgement from base station)


(FWD_FCH_RC = 11, REV_FCH_RC = 8)

Common

Channels


Initial service

configuration Dedicated

Channels

Possible

new service

configuration

Voice Traffic

MS BS

Traffic Channel Initialization

Service Connect

Completion Message

Radio Configuration

Parameters Message

Order Message

(acknowledgement from Mobile Station)

1 2


a. Configure the base station for desired voice service negotiation (RL RC 8, FL RC 11, 4

SO 3,/68/73) and to include RC_BITMAP_CAPABILITY_EXT_ALLOWED in the SPM 5

and set it to 1. Ensure that the base station needs to change at least one of the default 6

values of RL RC 8 or FL RC 11. 7


c. Make a mobile originated voice call. 9

d. Ensure SERVICE_OPTION, FOR_RC_PREF, and REV_RC_PREF proposed in the 10

Origination Message correspond to the mobile configuration settings. 11

e. Ensure DEFAULT_CONFIG, GRANTED_MODE, FOR_RC, and REV_ RC in the 12



f. Verify that after the traffic channel initialization base station sends the Radio 15

Configuration Parameters Message and the mobile station sends a Order Message 16

acknowledging the receipt of Radio Configuration Parameters Message. 17

g. Ensure that service negotiation used in Service Request Message, Service Response 18

Message, and Service Connect Message proceeds as desired. 19

3GPP2 C.S0044-D v1.0

2-43

h. Ensure that the SERVICE_OPTION, FOR_FCH_RC, and REV_FCH_RC in the last 1

Service Configuration Record corresponds to the desired outcome of the base station 2

service negotiation configuration, and the call completes successfully. 3

i. End the call. 4

j. Setup a mobile station terminated call and repeat steps d through g. 5


The mobile station shall comply with steps f and h. 7

2.28 RL RC 8 / FL RC 11 Parameter Change using GEM 8

2.28.1 Definition 9

This test verifies that the mobile station and base station can use General Extension Message for 10 changing Reverse Link RC 8 and/or Forward Link RC 11 or RC 12 parameters during call 11 establishment. Implementation of General Extension Message is optional for the base station. 12


(See[4]) 14











25

3GPP2 C.S0044-D v1.0

2-44



(RC bitmap, Alt SO)

Order Message

(acknowledgement from base station)

General Extension Message

{ Extended Channel Assignment Message

(FWD_FCH_RC = 11, REV_FCH_RC = 8) +

Radio Configuration Parameters Record }

Common

Channels


Initial service

configuration Dedicated

Channels

Possible

new service

configuration

Voice Traffic

MS BS

Traffic Channel Initialization

Service Connect

Completion Message

Order Message

(acknowledgement from Mobile Station)

1 2



SO 3/68/73) and to include RC_BITMAP_CAPABILITY_EXT_ALLOWED in the SPM 5

and set it to 1. Ensure that the base station needs to change at least one of the default 6

values of RL RC 8 or FL RC 11 and that the base station is configured to use General 7

Extension Message for this purpose. 8


c. Make a mobile originated voice call. 10

d. Ensure SERVICE_OPTION, FOR_RC_PREF, and REV_RC_PREF proposed in the 11

Origination Message correspond to the mobile configuration settings. 12

e. Verify that the base station sends an Extended Channel Assignment Message and 13

Radio Configuration Parameters Record in a General Extension Message and that 14



f. Verify that after the traffic channel initialization mobile station sends an Order Message 17

acknowledging the receipt of General Extension Message. 18

g. Ensure that service negotiation used in Service Request Message, Service Response 19

Message, and Service Connect Message proceeds as desired. 20

3GPP2 C.S0044-D v1.0

2-45

h. Ensure that the SERVICE_OPTION, FOR_FCH_RC, and REV_FCH_RC fields in the 1

last Service Configuration Record corresponds to the desired outcome of the base 2

station service negotiation configuration, and the call completes successfully. 3

i. End the call. 4

j. Setup a mobile station terminated call and repeat steps d through g. 5


The mobile station shall comply with steps f and h. 7

2.29 Forward Link Error with RC11/RC12 8

2.29.1 Definition 9

This test verifies forward link error trigger functionality in the mobile station for different smart 10 blanking options for the RC11/RC12 assignment on the forward link that are supported by the 11 base station. In the method of measurement below base station should perform procedures only 12 for the FOR_FCH_BLANKING_DUTYCYCLE and FOR_N2M_IND values supported by the base 13 station. 14


(See[4]) 16


2.6.4.1.8 Forward Traffic Channel Supervision 18

2.6.4.1.8.1.1 Triggers 19


None. 21



SO 3/68/73). 24

b. Allow the mobile station to come to the idle state on the base station. 25

c. Attempt a mobile station originated or terminated call. 26

d. Instruct the base station to assign RC11/RC12 on the forward fundamental channel and 27

to assign a value of ‘010’ for ‘FOR_FCH_BLANKING_DUTYCYCLE and ‘011’ for 28

FOR_N2M_IND using the Radio Configuration Parameters Message or the Radio 29

Configuration Parameters Record. Other values specified later in the test can be used if 30

these values are not supported. 31

e. Instruct the base station to transmit only guaranteed physical layer frames. This can be 32

achieved by using of SO 74 or by muting the mobile station other end in case of a 33

mobile to mobile call. 34

3GPP2 C.S0044-D v1.0

2-46

f. Abruptly cause loss of the forward RF link beginning in for a period greater than 1

FOR_N2M_IND guaranteed frames ( i.e. > (FOR_N2M_IND + 1) * 2

FOR_FCH_BLANKING_DUTYCYCLE * 20 ms) and less than 5 seconds. Note that 3

FOR_N2M_IND and FOR_FCH_BLANKING_DUTYCYCLE values are in number of 4

frames and not the actual attribute values. FOR_FCH_BLANKING_DUTYCYCLE value 5

of ‘000’, ‘001’ and ‘010’ correspond to 0, 4 and 8 frames respectively. FOR_N2M_IND 6

value of ‘000’, ‘001’, ‘010’, and ‘011’ correspond to 2, 4, 6 and 8 frames respectively. 7

g. Verify that the mobile station disables its reverse link transmitter after it receives 8

FOR_N2M_IND consecutive guaranteed FL frames with insufficient signal quality. 9

h. Verify that the mobile station starts its transmitter after receiving N3m (2) consecutive 10

guaranteed frames from on the forward link or if the mobile station receives the forward 11

fundamental channel with sufficient signal quality for a period of N3m × 20ms (= 40 ms). 12

i. Terminate the call. 13

j. Repeat steps c-g with the exception that the base station is continuously transmitting 14

frames to the mobile station. This can be achieved for example by using SO 74 and 15

generating critical 1/8th rate frames. 16

k. Verify that the mobile station starts its transmitter after receiving N3m (2) consecutive 17

frames from on the forward link or if the mobile station receives the forward 18


l. Repeat steps c-e. 20

m. Abruptly cause loss of the forward RF link beginning in for a period equal to 21

FOR_N2M_IND * FOR_FCH_BLANKING_DUTYCYCLE * 20 ms – 20 ms such that less 22

than FOR_N2M_IND guaranteed frames are lost. Note that 23

FOR_FCH_BLANKING_DUTYCYCLE and FOR_N2M_IND values are in number of 24

frames and not the actual attribute values. 25

n. Verify that the mobile station does not disable its reverse link transmitter. 26

o. Terminate the call. 27

p. Repeat steps c-o for FOR_N2M_IND attribute values of ‘000’, 001’ and ‘010’. 28

q. Repeat steps c-p for FOR_FCH_BLANKING_DUTYCYCLE attribute value of ‘001’. 29

r. Repeat steps c-e with FOR_FCH_BLANKING_DUTYCYCLE attribute value of ‘000’ and 30

configure the base station to continuously transmit frames to the mobile station. This 31

can be achieved for example by using SO 74 and generating critical 1/8th rate frames. 32

s. Abruptly cause loss of the forward RF link beginning in for a period greater than N2M 33

frames and less than 5 seconds. 34

t. Verify that the mobile station disables its reverse link transmitter after it receives N2M 35

consecutive FL frames with insufficient signal quality. 36

u. Verify that the mobile station starts its transmitter after receiving N3m (2) consecutive 37

frames from on the forward link or if the mobile station receives the forward 38


3GPP2 C.S0044-D v1.0

2-47

v. Terminate the call. 1

w. Repeat step c-e with FOR_FCH_BLANKING_DUTYCYCLE attribute value of ‘000’ and 2

configure the base station is continuously transmitting frames to the mobile station. This 3

can be achieved for example by using SO 74 and generating critical 1/8th rate frames.. 4

x. Abruptly cause loss of the forward RF link beginning in for a period less than N2M 5

frames. 6

y. Verify that the mobile station does not disable its reverse link transmitter. 7

z. Repeat steps r-y for FOR_N2M_IND attribute values of ‘000’, 001’ and ‘010’. Note, 8

FOR_N2M_IND value is not used when FOR_FCH_BLANKING_DUTYCYCLE attribute 9

value of ‘000’ is used. 10

aa. Repeat steps a-z with REV_FCH_BLANKING_DUTYCYCLE set to ‘000’. 11


The mobile station shall comply with steps g, h, k, n, t, u, and y. 13

2.30 Traffic Channel Assignment in QoF 14


This test verifies a call set-up with a QoF assignment instead of walsh channel. 16


(See[4]) 18











None. 29



SO 3/68/73) ), include RC_BITMAP_CAPABILITY_EXT_ALLOWED in the SPM 32

and sets it to 1, and to assign QoF instead of a walsh code in the Extended Channel 33

3GPP2 C.S0044-D v1.0

2-48

Assignment Message. Ensure that the base station needs to change at least one of the 1

default values of RL RC 8 or FL RC 11. 2

b. Attempt a mobile station originated or terminated call. 3

c. Ensure that the mobile station includes support for RC 11 in FOR_FCH_RC_MAP and 4

RC 8 in REV_FCH_RC_MAP in the Origination Message. 5

d. Ensure that the mobile station includes SO 74 in the SO or ALT_SO or SO_BITMAP 6

field in the origination message. 7

e. Instruct the base station to send an Extended Channel Assignment Message with 8

FOR_FCH_RC / FOR_RC set to 11 and REV_FCH_RC / FOR_RC set to 8 and to set 9

the QOF_MASK_ID_FCH set to ‘11’. 10

f. Ensure that the mobile station initializes the traffic channel. 11

g. Ensure that the base station to transmit Service Connect Message specifying the SO 12

73/68/3 in the SERVICE_OPTION field. 13

h. Ensure that the mobile station transmits Service Connect Completion Message to the 14

base station. 15

i. Instruct the base station to send a Radio Configuration Parameters Message with 16

QOF_SET_IN_USE set to ‘111’. 17

j. Verify that the mobile station starts transmitting and receiving frames for voice traffic. 18

k. Repeat the test by using General Extension Message containing with Extended 19

Channel Assignment Message and Radio Configuration Parameters Record. 20


The mobile station shall comply with step j. 22

2.31 Call recovery Request Message 23


This test verifies the Call Recovery Request Message functionality at the mobile station. 25


(See[4]) 27


2.6.4.1.8 Forward Traffic Channel Supervision 29

2.7.1.3.2.17 Call Recovery 1 Request Message 30

2.6.4.1.8.1.1 Triggers 31

3GPP2 C.S0044-D v1.0

2-49


Dedicated

Channels

MS BS

Voice Traffic

T5M

CRRM

allowed

Common

ChannelsCRRM

2 3


a. Configure a test setup with a connection of a single base station and the mobile station 5

to allow the reverse radio link to be abruptly attenuated or interfered-with, enough to 6

cause continuous loss of all reverse frames as exemplified in Figure 2-1. 7

b. Configure the setup for good RF links. 8

c. Allow the mobile station to come to the idle state on the base station. 9

d. Instruct the base station to set the value of CRRM_MSG_IND to ‘1’ in the overhead 10

messages. 11

e. Attempt a mobile station originated call. 12

f. Ensure that the mobile and base station are sending and receiving voice frames. 13

g. Abruptly cause loss of the forward RF link beginning in for a period greater than T5m (5 14

seconds) and less than 20 seconds. 15

h. Ensure that the RF conditions are restored. 16

i. Verify that the mobile station transmits the Call Recovery Request Message to the base 17

station. 18

3GPP2 C.S0044-D v1.0

2-50

j. Ensure that the base station assigns a new traffic channel to the mobile station. 1

k. Verify that the mobile station reestablishes the original voice call. 2

l. Terminate the call. 3

m. Repeat steps c-f. 4

n. Abruptly cause loss of the forward RF link beginning in for a period greater than 20 5

seconds. 6

o. Ensure that the RF conditions are restored. 7

p. Verify that the mobile station does not transmit Call Recovery Request Message to the 8

base station. 9

q. Terminate the call. 10

r. Instruct the base station to set the value of CRRM_MSG_IND to ‘0’ in the overhead 11

messages. 12

s. Repeat steps c-h. 13

t. Verify that the mobile station does not transmit Call Recovery Request Message to the 14

base station. 15


The mobile station shall comply with step i, k, p, t. 17

2.32 General Overhead Information Message 18


This test verifies the General Overhead Information Message processing at the mobile station. 20


(See[4]) 22

2.6.2.2.22 General Overhead Information Message 23

3.7.2.3.2.42 General Overhead Information Message 24

3.7.2.3.2.31 MC-1 RR Parameters Message 25



None. 28


a. Configure the base station to transmit General Overhead Information Message. 30

b. Instruct the base station to set the value of GEN_OVHD_INF_IND to ‘1’ and 31

GEN_OVHD_CYCLE_INDEX to ‘101’ in the overhead messages. 32

3GPP2 C.S0044-D v1.0

2-51

c. Allow the mobile station to become idle. 1

d. Attempt a mobile station originated call before the General Overhead Information 2


e. Verify that the mobile station transmits an Origination Message. 4

f. Terminate the call. 5

g. Allow the mobile station to become idle. 6

h. Attempt a mobile station terminated call before the General Overhead Information 7


i. Verify that the mobile station transmits a Page Response Message. 9

j. Terminate the call. 10


The mobile station shall comply with steps e and i. 12

2.33 SO 33 call set-up with RC 11 and RC 8 13


This test verifies SO 33 call set-up with FL RC 11 and RL RC 8 assignment. It also verifies 15 various power control mode assignments though Radio Configuration Parameters Message. This 16 test should be conducted for all FPC_MODE, RPC_MODE, and 17 REV_FCH_BLANKING_DUTYCYCLE supported by the base station and the mobile station. 18 Note, in the procedure below, FPC_MODE can also be changed through Radio Configuration 19 Parameters Message or a General Extension Message that carries Radio Configuration 20 Parameters Record. 21


See [1]) 23

2.1.3.1.11 Reverse Power Control Subchannel 24

(See [4]) 25

2.6.6.2.5.1, 3.6.6.2.2.12, 3.7.3.3.2.37 Extended Supplemental Channel Assignment Message 26

2.6.2.4, 2.6.3.3, 2.6.3.5, 3.6.3.3, 3.6.3.5, 3.7.2.3.2.21 Extended Channel Assignment Message 27

2.6.4.1.2, 2.6.4.1.2.2, 3.7.3.3.2.20, 3.7.5, 3.7.5.7, 3.7.5.20 Service Connect Message 28


None. 30


a. Configure the base station for desired service negotiation and to include 32

RC_BITMAP_CAPABILITY_EXT_ALLOWED in the SPM and sets it to 1. 33

b. Set up a mobile station originated call using Service Option 33. 34

3GPP2 C.S0044-D v1.0

2-52

c. Configure the base station to send the Extended Channel Assignment Message with the 1

parameters set as follows: 2

3

ASSIGN_MODE = '100' GRANTED_MODE = '10'

FOR_RC = '01011' (RC 11) REV_RC = '01000' (RC 8)

CH_IND = '01' FPC_FCH_INIT_SETPT = '01000000' (8 dB)

FPC_FCH_FER = '00010' (1%) FPC_FCH_MIN_SETPT = '00010000' (2 dB)

FPC_FCH_MAX_SETPT = '10000000' (16 dB)

4

d. Configure the base station to send and to send a Radio Configuration Parameters 5

Message with REV_FCH_BLANKING_DUTYCYCLE set to ‘000’ and to send the 6

Service Connect Message with the parameters set as follows: 7

FPC_INCL = ‘0’ FPC_OLPC_FCH_INCL = ‘0’

FPC_PRI_CHAN = ‘0’ GATING_RATE_INCL = ‘0’

FPC_MODE = not included

e. Configure the base station to download SCH configuration and assign a Forward 8

Supplemental Channel by using the Extended Supplemental Channel Assignment 9

Message and set the power control related fields as stated in follows: 10

11

FPC_INCL = ‘0’ FPC_SCH_INIT_SETPT = ‘01000000’ (8 dB)

FPC_SCH_INIT_SETPT_OP = ‘0’ FPC_SCH_MAX_SETPT = ‘10000000’ (16 dB)

FPC_SCH_FER = ‘01010’ (5%) FPC_SCH_MIN_SETPT = ‘00010000’ (2 dB)

f. Verify that the mobile station and base station are able to send and receive IP packets. 12

g. Repeat steps a-f with the exception that FPC_MODE is set to ‘010’. 13

h. Repeat steps a-f with the exception that RPC_MODE is set to ‘01’ and FPC_MODE is 14

set to ‘011’. 15

i. Repeat steps a-f with the exception that RPC_MODE is set to ‘01’ and FPC_MODE is 16

set to ‘010’. 17

j. Repeat steps a-f with the exception that REV_FCH_BLANKING_DUTYCYCLE is set to 18

the default value, RPC_MODE is set to ‘01’ and FPC_MODE is set to ‘010’. 19

k. Repeat steps a-f with the exception that REV_FCH_BLANKING_DUTYCYCLE is set to 20

the default value, RPC_MODE is set to ‘01’ and FPC_MODE is set to ‘011’. 21

l. Repeat steps a-f with the exception that REV_FCH_BLANKING_DUTYCYCLE is set to 22

the default value, RPC_MODE is set to default value of ‘00’ and FPC_MODE is set to 23

‘010’. 24

3GPP2 C.S0044-D v1.0

2-53

i. Repeat steps a and b, with the base station either not including 1

RC_BITMAP_CAPABILITY_EXT_ALLOWED in the SPM or including it and setting it to 2

0. 3

j. Instruct the base station to query REV_SCH Type-Specific Fields record and 4

FOR_SCH Type-Specific Fields record from the mobile station using Status Request 5

Message. 6

m. Verify that the mobile station does not include the RL RC 8 and FL RC 11 or 12 in the 7

REV_SCH_RC_MAP and FOR_SCH_RC_MAP fields respectively. 8


The mobile station shall comply with the requirement in step f for all cases and step o. 10

2.34 SO 33 Fast Connection Setup 11


This Test verifies the mobile station can perform fast SO33 connection setup by skipping Service 13 negotiation handshake. 14






2.34.3 Call Flow Examples 20

Mobile originated call flow: 21

22

3GPP2 C.S0044-D v1.0

2-54

Mobile terminated call flow: 1

MS BS

ECAM with SO33_default

Null frames

Traffic channel preamble(parallel transmission)

BS Ack

MS Ack

ESCAM

2


n. Connect the mobile station to the base station as shown in Annex A Figure A-1. 4

o. Instruct the mobile station to originate SO33 call 5

p. Verify that SO33_DEFAULT flag in DEVICE_CHAC is set to 1 in General Extension 6

Message. 7

q. Instruct the base station to send Extended Channel Assignment Message with 8


r. Verify that the mobile station skips Service negotiation handshake during mobile 10

originated call. 11

s. Wait until the mobile station goes to dormant state. 12

t. Instruct the base station to start mobile terminated call either by sending General Page 13

Message or sending Extended Channel Assignment Message directly with 14


u. Verify that the mobile station skips Service negotiation handshake during mobile 16

terminated call. 17

v. End the call.. 18


The mobile station shall comply with the requirement in steps c, e, and h. 20

21

3GPP2 C.S0044-D v1.0

2-55

2.35 Direct Channel Assignment 1

2.35.1 Definition 2

This test verifies that the mobile station sets up mobile terminated SO33 call upon receiving 3 Extended Channel Assignment Message in idle state. 4





2.35.3 Call Flow Diagram 9

None. 10


w. Connect the mobile station to the base station as shown in Annex A Figure A-1. 12

x. Instruct the mobile station to originate SO33 call. 13

y. Verify that DCA_SUPPORTED flag in DEVICE CAPABILITY is set to 1. 14

z. Wait until the mobile station goes to dormant state. 15

aa. Instruct the base station to send Extended Channel Assignment Message directly while 16

the mobile station is in idle state with SO33_ACCEPTED = 1. 17

bb. Verify the mobile station goes to traffic upon receiving Extended Channel Assignment 18

Message. 19

cc. End the call. 20


The mobile station shall comply with the requirements in steps c and f. 22

23

2.36 Extended Slot Cycle Index 24


This test verifies the mobile station response to the base station 26 MAX_EXT_SLOT_CYCLE_INDEX setting for various settings of mobile station 27 EXT_SLOT_CYCLE_INDEXp. 28





3GPP2 C.S0044-D v1.0

2-56




2.7.4.7 Terminal Information 4


None 6


a. Configure the mobile station internal setting of EXT_SLOT_CYCLE_INDEXp and also 8

base station System Parameter Message setting MAX_EXT_SCI_INCL=1 and 9

MAX_EXT_SCI in the first row in table 2.36.4-1. 10

Table 2.36.4-1 – Mobile and Base Station Settings for Extended Slot Cycle Index Test 11

Test_ID MAX_EXT_SLOT_CYCLE_INDEX (base station)

EXT_SLOT_CYCLE_INDEXp (mobile station)

Extended Slot Cycle Index Used

Extended Slot Cycle Length, seconds

1 7 2 2 5.12

2 7 3 3 10.24

3 7 4 4 20.48

4 7 5 5 40.96

5 7 6 6 81.92

6 7 7 7 163.84

12

b. Allow the mobile station to come to the idle state in slotted mode on the base station. 13

c. Examine the occasions when the mobile station briefly wakes up to read the Paging 14

Channel, and verify that it occurs on the interval of the Extended Slot Cycle Length in 15

table 2.36.4-1. This can be done using a diagnostic monitor, which logs (timestamps) 16

Paging Channel messages in the waking moments, or with a battery current monitor that 17

indicates the awakened state by increased draw. 18

d. Make a mobile station terminated call by paging the mobile station in the appropriate 19

paging slot, and verify that it completes successfully. 20

e. Repeat steps a through d for each of the Test ID combinations in Table 2.36.4-1. 21


The mobile station shall comply with requirements in steps c and d. 23

3GPP2 C.S0044-D v1.0

3-1

3 HANDOFF TESTS 1

3.1 Soft Handoff with Dynamic Threshold 2

3.1.1 Definition 3

This test verifies the mobile station and base station perform soft handoff. Soft handoff with and 4 without dynamic thresholds is verified. This test verifies both adding pilot to and dropping pilot 5 from the soft handoff Active Set. Tests 1 through 4 apply to cases when SOFT_SLOPE is not 6 equal to ‘000000’ (dynamic threshold enabled). 7


(See[4]) 9


2.6.4.1.4 Processing the In-Traffic System Parameters Message 11

2.6.6.2.3 Handoff Drop Timer 12


2.6.6.2.5.2 Processing of Reverse Traffic Channel Handoff Messages 14

2.6.6.2.6.2 Maintenance of the Candidate Set 15

2.6.6.2.6.3 Maintenance of the Neighbor Set 16

2.6.6.2.8.2.1 Restoring the Configuration 17

2.6.6.3 Examples 18

2.7.2.3.2.5 Pilot Strength Measurement Message 19

3.6.6.2.1.1 System Parameters 20


3.7.3.3.2.7 In-Traffic System Parameters Message 22

3.7.3.3.2.17 Extended Handoff Direction Message 23




None 27


a. Setup test as shown in Figure A-4. 29

1. The Forward Channel from sector of base station 1 has an arbitrary pilot PN 30

offset index P1 and is called Channel 1. 31

3GPP2 C.S0044-D v1.0

3-2

2. The Forward Channel from sector ß of base station 1 has an arbitrary pilot PN 1




b. Set the test parameters for Test 1 as specified in Table 3.1.4-1and Table 3.1.4-2. 5

Table 3.1.4-1 6

Field Value

SOFT_SLOPE ‘010000’ (2)6

ADD_INTERCEPT ‘000110’ (3 dB)7

DROP_INTERCEPT ‘000010’ (1 dB)8

T_ADD ‘100000’ (-16 dB)

T_DROP ‘100100’ (-18 dB)

T_TDROP ‘0011’ (4s)

7

Table 3.1.4-2 8

Parameter Unit Channel 1 Channel 2 Channel 3

Îor/Ioc dB 7 -20 -20

Pilot Ec/Ior dB -5 -5 -5

Traffic Ec/Ior dB -7 -7 -7


Pilot Ec/Io dB -5.8 -33 -33

9

6 SOFT_SLOPE=16/8=2

7 ADD_INTERCEPT=6/2=3dB

8 DROP_INTERCEPT=2/2=1dB

3GPP2 C.S0044-D v1.0

3-3

Table 3.1.4-3 1


Îor/Ioc dB 7 7 -20




Pilot Ec/Io dB -8.4 -8.4 -35

2

c. Reverse link attenuation should be set to balance the forward and reverse links 3

(approximately 90 dB). 4


e. Verify user data in both directions. Verify only Channel 1 is in the Active Set. 6

f. Raise the level of Channel 2 in steps of 1 dB with a dwell time of five seconds after 7

each step until the mobile station has generated the Pilot Strength Measurement 8

Message. Record the level of Pilot Ec/Io in the Pilot Strength Measurement Message. 9

g. Verify the following 10

1. The mobile station generates a Pilot Strength Measurement Message when the 11

level of channel 2 is at a Pilot Ec/Io level between –10 dB and –13 dB. 12

2. If the RC used on the forward fundamental channel is < 10, the base station 13

sends an Extended Handoff Direction Message, General Handoff Direction 14

Message, or Universal Handoff Direction Message to the mobile station to allow 15

soft handoff between Channel 1 and Channel 2. For RC11/RC12 assignment on 16

the forward fundamental channel, instruct the base station to: 17

a. Send an Extended Handoff Direction Message, General Handoff 18

Direction Message, or Universal Handoff Direction Message followed 19

by a Radio Configuration Parameters Message to the mobile station. 20

OR 21

b. To send a General Extension Message, containing Extended Handoff 22

Direction Message, General Handoff Direction Message, or Universal 23

Handoff Direction Message and Radio Configuration Parameters 24

record. 25

3. The mobile station sends a Handoff Completion Message or an Extended 26

Handoff Completion Message as a response to handoff message. 27

4. The mobile station is in soft handoff between Channel 1 and Channel 2. 28

h. Set test parameters for Test 2 as specified in Table 3.1.4-3 while Channel 1 and 29

Channel 2 are in soft handoff. Raise the level of Channel 3 in steps of 1 dB with a dwell 30

time of five seconds after each step until the mobile station has generated the Pilot 31

3GPP2 C.S0044-D v1.0

3-4

Strength Measurement Message. Record the level of Pilot Ec/Io in the Pilot Strength 1

Measurement Message. 2

i. Verify the following: 3


level of channel 3 is at a level between –10 dB and –13 dB. 5




soft handoff between Channel 1, Channel 2 and Channel 3. For RC11/RC12 9

assignment on the forward fundamental channel, instruct the base station to: 10




OR 14




record. 18



4. The mobile station is in soft handoff among Channel 1, Channel 2 and Channel 21

3. 22

j. Set the test parameters for Test 3 in Table 3.1.4-4 while Channel 1, Channel 2, and 23

Channel 3 are in soft handoff. Lower the level of Channel 3 in steps of 1 dB with a dwell 24

time of 30 seconds until the mobile station has generated the Pilot Strength 25

Measurement Message. Record the level of Pilot Ec/Io in the Pilot Strength 26


28

Table 3.1.4-4 29


Îor/Ioc dB 7 7 7




Pilot Ec/Io dB -10.1 -10.1 -10.1

k. Verify the following: 30

3GPP2 C.S0044-D v1.0

3-5


level of channel 3 is at a level between –12 dB and –16 dB for a period of 2

T_TDROP. 3




soft handoff between Channel 1 and Channel 2. 7



4. The mobile station is in soft handoff between Channel 1 and Channel 2. For 10

RC11/RC12 assignment on the forward fundamental channel, instruct the base 11

station to 12




OR 16




record. 20

l. Set test parameters for Test 4 as specified in Table 3.1.4-5. Lower level of Channel 2 in 21

steps of 1 dB with a dwell time of 30 seconds after each step until the mobile station 22

has generated the Pilot Strength Measurement Message. Record the level of Pilot Ec/Io 23

in the Pilot Strength Measurement Message. 24

Table 3.1.4-5 25


Îor/Ioc dB 7 7 -20




Pilot Ec/Io dB -8.4 -8.4 -35

m. Verify the following: 26

1. The mobile station shall generate a Pilot Strength Measurement Message when 27

the level of channel 2 is at a level of –11 dB and –14 dB for a period of 28

T_TDROP. 29



Message, or Universal Handoff Direction Message to the mobile station with only 32

3GPP2 C.S0044-D v1.0

3-6

Channel 1 listed in the Active Set. For RC11/RC12 assignment on the forward 1

fundamental channel, instruct the base station to: 2




OR 6




record. 10



4. Channel 1 is the only Active Set for the mobile station. 13


Verify steps g, i, k and m. 15

3.2 Soft Handoff without Dynamic Threshold 16

3.2.1 Definition 17

This test verifies the proper operation of mobile station soft handoff. Soft handoff without dynamic 18 thresholds is verified. This test verifies both adding pilot to and dropping pilot from the soft 19 handoff Active Set. Tests 1 through 4 apply to cases when SOFT_SLOPE is equal to ‘000000’ 20 (dynamic threshold disabled). 21


(See[4]) 23


2.6.4.1.4 Processing the In-Traffic System Parameters Message 25

2.6.6.2.3 Handoff Drop Timer 26



2.6.6.2.6.2 Maintenance of the Candidate Set 29

2.6.6.2.6.3 Maintenance of the Neighbor Set 30


2.6.6.3 Examples 32


3.6.6.2.1.1 System Parameters 34


3GPP2 C.S0044-D v1.0

3-7

3.7.3.3.2.7 In-Traffic System Parameters Message 1





None 6


a. Setup test as shown in Figure A-4. Start with Test 1 to Test 4 with dynamic threshold 8

disabled. 9







b. Set the test parameters for Test 1 as specified in Table 3.2.4-1 and Table 3.2.3-2. 16

Table 3.2.4-1 17

Parameter Tests 1-4

SOFT_SLOPE ‘000000’ (0)

ADD_INTERCEPT ‘000000’ (0 dB)

DROP_INTERCEPT ‘000000’ (0 dB)

T_ADD ‘011100’ (-14 dB)

T_DROP ‘100000’ (-16 dB)

T_TDROP ‘0011’ (4s)

18

3GPP2 C.S0044-D v1.0

3-8

Table 3.2.4-2 1






Pilot Ec/Io dB -5.8 -33 -33

2

Table 3.2.4-3 3


Îor/Ioc dB 7 7 -20




Pilot Ec/Io dB -8.4 -8.4 -35

4




e. Verify user data in both directions. Verify only Channel 1 is in the Active Set. 8

f. Raise the level of Channel 2 in steps of 1 dB with a dwell time of five seconds after 9


Message. Record the level of Pilot Ec/Io in the Pilot Strength Measurement Message. 11

g. Verify the following: 12


level of channel 2 is at a level between T_ADD and T_ADD +2 dB. 14

2. 2. If the RC used on the forward fundamental channel is < 10, the base 15

station sends an Extended Handoff Direction Message, General Handoff 16

Direction Message, or Universal Handoff Direction Message to the mobile station 17

to allow soft handoff between Channel 1 and Channel 2. For RC11/RC12 18

assignment on the forward fundamental channel, instruct the base station to 19



3GPP2 C.S0044-D v1.0

3-9


OR 2




record. 6



4. The mobile station is in softer handoff between Channel 1 and Channel 2. 9

h. Set test parameters for Test 2 as specified in Table 3.2.4-3 while Channel 1 and 10

Channel 2 are in soft handoff. Raise the level of Channel 3 in steps of 1 dB with a dwell 11

time of five seconds after each step until the mobile station has generated the Pilot 12

Strength Measurement Message. Record the level of Pilot Ec/Io in the Pilot Strength 13




level of channel 3 is at a level between T_ADD and T_ADD +3 dB. 17




softer handoff between Channel 1, Channel 2 and Channel 3. For RC11/RC12 21

assignment on the forward fundamental channel, instruct the base station to: 22




OR 26




record. 30



4. The mobile station is in softer handoff among Channel 1, Channel 2 and Channel 33

3. 34

j. Set the test parameters for Test 3 in Table 3.2.4-4 while Channel 1, Channel 2, and 35

Channel 3 are in soft handoff. Lower the level of Channel 3 in steps of 1 dB with a dwell 36

time of 30 seconds until the mobile station has generated the Pilot Strength 37

Measurement Message. Record the level of Pilot Ec/Io in the Pilot Strength 38


3GPP2 C.S0044-D v1.0

3-10

Table 3.2.4-4 1


Îor/Ioc dB 7 7 7




Pilot Ec/Io dB -10.1 -10.1 -10.1

2



level of channel 3 is at a level between T_DROP and T_DROP + 4 dB for a 5

period of T_TDROP. 6




softer handoff between Channel 1 and Channel 2. For RC11/RC12 assignment 10

on the forward fundamental channel, instruct the base station to: 11




OR 15


Direction Message or General Handoff Direction Message, or 17

Universal Handoff Direction Message and Radio Configuration 18

Parameters record. 19



4. The mobile station is in softer handoff between Channel 1 and Channel 2. 22

l. Set test parameters for Test 4 as specified in Table 3.2.4-5. Lower level of Channel 2 in 23

steps of 1 dB with a dwell time of 30 seconds after each step until the mobile station 24

has generated the Pilot Strength Measurement Message. Record the level of Pilot Ec/Io 25

in the Pilot Strength Measurement Message. 26

3GPP2 C.S0044-D v1.0

3-11

Table 3.2.4-5 1


Îor/Ioc dB 7 7 -20




Pilot Ec/Io dB -8.4 -8.4 -35


1. The mobile station shall generate a Pilot Strength Measurement Message when 3

the level of channel 2 is at a level of T_DROP and T_DROP –3 dB for a period of 4

T_TDROP. 5



Message, or Universal Handoff Direction Message to the mobile station with only 8

Channel 1 listed in the Active Set. For RC11/RC12 assignment on the forward 9

fundamental channel, instruct the base station to: 10




OR 14




record. 18



4. Channel 1 is the only Active Set for the mobile station. 21


Verify steps g, i, k, and m. 23

3.3 Hard Handoff Between Frequencies in the Same Band Class 24

3.3.1 Definition 25

This test verifies the mobile station and base station perform hard handoff between different 26 CDMA channels in the same band class. 27

3GPP2 C.S0044-D v1.0

3-12


(See[4]) 2

2.6.6.1.1 Types of Handoff 3


2.6.6.2.8 CDMA-to-CDMA Hard Handoff 5


3.6.6.2.2 Call Processing During Handoff 7





None 12





2. Setup base station 2 to be on a different CDMA channel than base station 1, but 17

within the same band class. The Forward Channel from base station 2 has an 18

arbitrary pilot PN offset index P2 and is called Channel 2. 19

3. The AWGN source should be on the frequency of Channel 2. (It is advisable to 20

achieve the maximum possible difference in frequency separation between 21

Channel 1 and Channel 2). 22

b. Set the test parameters as shown in Table 3.3.4-1. 23

Table 3.3.4-1 24


Îor/Ioc dBm N/A -5

Pilot Ec/Ior dB -7 -7

Traffic Ec/Ior dB -7 -7

Ioc dBm/1.23 MHz N/A -75

Pilot Ec/Io dB -7 -13.2

25

c. Set reverse link attenuation to balance forward and reverse links (approximately 90 dB). 26

d. Setup a mobile station originated call on Channel 1. 27

3GPP2 C.S0044-D v1.0

3-13

e. Verify user data in both directions. 1

f. Initiate handoff from Channel 1 to Channel 2. Verify that base station 1 initiates handoff 2

from Channel 1 to Channel 2 by sending a General Handoff Direction Message, 3

Universal Handoff Direction Message, or an Extended Handoff Direction Message with 4

proper parameters (refer to tables in Annex B) to initiate handoff from Channel 1 to 5

Channel 2. 6

g. One second or more after base station 1 sends a General Handoff Direction Message, 7

a Universal Handoff Direction Message, or an Extended Handoff Direction Message 8

disconnect or attenuate the forward link of Channel 1. 9

h. Verify user data in both directions. 10

i. Monitor calls and record the length of any audio dropouts present. 11

j. Steps b through g may be repeated for the case where it is a hard handoff to soft 12

handoff on the same frequency with the following setup (see Figure A-4: one base 13

station configured with two sectors active): 14







k. The expected results for steps h and i should be the same as the previous test. 21


In step h, the mobile station and base stations shall successfully execute the hard handoff. 23

3.4 Hard Handoff from CDMA to Analog 24

3.4.1 Definition 25

This test verifies the mobile station and base station perform hard hand off from a CDMA system 26 to an analog system. 27


(See[4]) 29


2.6.6.2.9 CDMA-to-Analog Handoff 31



3.7.3.3.2.6 Analog Handoff Direction Message 34

3GPP2 C.S0044-D v1.0

3-14


None 2


a. Connect two base stations and an AWGN source to the mobile station as shown in 4

Figure A-5. For the purpose of this test, Channel 1 is CDMA and Channel 2 is analog. 5

b. Set the test parameters as shown in Table 3.3.4-1 and Table 3.4.4-2. 6

Table 3.4.4-2 7

Analog Parameter Unit Channel 2

Voice Channel dBm -73

Co-Channel Interference dB -18

8





f. Initiate handoff to analog. Verify the CDMA base station sends an Analog Handoff 13

Direction Message with proper parameters (refer to tables in Annex B) to initiate 14

handoff to analog. 15

g. One second or more after base station 1 sends an Analog Handoff Direction Message 16

disconnect or attenuate the forward link of Channel 1. 17

h. Verify user data in both directions in the Analog system. 18

i. Monitor calls and record the length of any audio dropouts present on handoff. 19


In step h, the mobile station handoff to the Analog system shall be completed successfully 21

3.5 Soft Handoff in Fading 22

3.5.1 Definition 23

This test verifies soft handoff under various fading conditions: 24

a. 1 Ray Rayleigh fading at 30 km/hr 25

b. 3 Ray Rayleigh fading at 100 km/hr 26

c. 1 Ray Rayleigh fading at 3 km/hr 27


(See[4]) 29

3GPP2 C.S0044-D v1.0

3-15



2.6.6.2.7 Soft Handoff 3





None 8


a. Setup test as shown in A-2. 10





b. Set up the test parameters as shown in Table 3.5.4-1. 15

Table 3.5.4-1 16


Îor/Ioc dB 0 -10



Ioc dBm/1.23 MHz -75 -75

Pilot Ec/Io dB -10.2 -20.2

17



d. Set both channel simulators to one Ray Rayleigh, 30 km/hr. 20

e. Setup a mobile station originated call on Channel 1. Monitor two-way audio and note 21

anomalies throughout the test. 22

f. Raise the level of Channel 2 in steps of 1 dB with a dwell time of 5 seconds after each 23

step until the mobile station has generated the Pilot Strength Measurement Message. 24

Verify the following: 25

1. Pilot Strength Measurement Message is generated when the channel 2 Pilot Ec/Io 26

is at a level above T_ADD. 27

3GPP2 C.S0044-D v1.0

3-16

2. Base station sends an Extended Handoff Direction Message, General Handoff 1

Direction Message, or Universal Handoff Direction Message to the mobile 2

station. 3

3. Channel 1 and Channel 2 are in the Active Set at the action time of the message. 4

g. Mobile station sends a Handoff Completion Message or an Extended Handoff 5

Completion Message to the base station. 6

h. Set the test parameters as specified in Table 3.5.4-2 without dropping the call. 7

Table 3.5.4-2 8


Îor/Ioc dB 0 0



Ioc dBm/1.23 MHz -75 -75


9

i. Lower the level of Channel 1 in steps of 1 dB with a dwell time of 8 seconds after each 10



1. Pilot Strength Measurement Message is generated when Channel 1 is at a Pilot 13

Ec/Io level below T_DROP for a period of TT_DROP. 14



station. 17

3. Only Channel 2 is in the Active Set at the action time of the message. 18

4. Mobile station sends a Handoff Completion Message or an Extended Handoff 19


j. Set the levels as specified in Table 3.5.4-3. 21

3GPP2 C.S0044-D v1.0

3-17

Table 3.5.4-3 1


Îor/Ioc dB -10 0



Ioc dBm/1.23 MHz -75 -75


2

k. Raise the level of Channel 1 in steps of 1 dB with a dwell time of 5 seconds after each 3



6

1. Pilot Strength Measurement Message is generated when the channel 1 Pilot Ec/Io 7

is at a level above T_ADD. 8



station. 11

3. Channel 1 and Channel 2 are in the Active Set at the action time of the message. 12



l. Set the levels as specified in Table 3.5.4-4. 15

3GPP2 C.S0044-D v1.0

3-18

Table 3.5.4-4 1

Parameter Unit Value

Vehicle Speed km/hr 100

Number of Paths 3

Path 2 Power

(Relative to Path 1)

dB 0

Path 3 Power

(Relative to Path 1)

dB -3

Delay from Path 1 to Input µs 0

Delay from Path 2 to Input µs 2

Delay from Path 3 to Input µs 14.5

m. Lower the level of Channel 2 in steps of 1 dB with a dwell time of 8 seconds after each 2



1. Pilot Strength Measurement Message is generated when the Channel 2 is at a 5

Pilot Ec/Io level below T_DROP for a period of TT_DROP. 6



station. 9




n. Repeat steps a through l under 3 Ray Rayleigh fading at 100 km/hr fading condition as 13

specified in Table 3.5.4-4. 14

o. Repeat steps a through l under 1 Ray Rayleigh fading at 3 km/hr fading condition. 15


The mobile station shall generate the Pilot Strength Measurement Message at the appropriate 17 time as specified in steps f, h, j, and l and the handoff shall be completed successfully. 18

3.6 Hard Handoff in Fading 19

3.6.1 Definition 20

This test verifies hard handoff under various fading conditions: 21

a. 1 Ray Rayleigh fading at 30 km/hr 22

b. 3 Ray Rayleigh fading at 100 km/hr 23

3GPP2 C.S0044-D v1.0

3-19

c. 1 Ray Rayleigh fading at 3 km/hr 1

Under various deployment scenarios: 2

a. Between frequencies 3

b. On the same frequency 4


(See[4]) 6







None 13



1. The Forward Channel from base station 1 on frequency F1 has an arbitrary pilot 16

PN offset index P1 and is called Channel 1. 17

2. The Forward Channel from base station 2 on frequency F2 has an arbitrary pilot 18

PN offset index P2 and is called Channel 2. 19


Table 3.6.4-1 21


Îor/Ioc dB 0 0



Ioc dBm/1.23 MHz -75 -75

Pilot Ec/Io dB -10 -10

22

c. Set reverse link attenuation to balance forward and reverse links (approx. 90 dB). 23

d. Set the channel simulators for 1 Ray Rayleigh fading, 30 km/hr. 24

e. Setup a mobile station originated call on Channel 1. 25


3GPP2 C.S0044-D v1.0

3-20

g. Initiate handoff from Channel 1 to Channel 2. Verify that base station 1 initiates a 1

handoff from Channel 1 to Channel 2 by sending a General Handoff Direction Message, 2

Universal Handoff Direction Message, or an Extended Handoff Direction Message. 3

h. Upon receiving an Extended Handoff Direction Message, General Handoff Direction 4

Message, or Universal Handoff Direction Message at the mobile station, verify the 5

following: 6



Handoff Completion Message to the base station. 9

i. Repeat steps a through h, with the channel simulators set to 3 Ray Rayleigh at 100 10

km/hr in step d. Use the setup shown in Table 3.5.4-4. The expected results are as 11

given above for the previous test. 12

Table 3.6.4-2 13


Îor/Ioc dB 0 0



Ioc dBm/1.23 MHz -75 -75


14

j. Repeat steps a through h, with the channel simulators set to 1 Ray Rayleigh at 3 km/hr 15

in step d. The expected results are as given above for the previous test. 16

k. Repeat steps c through j for the scenario where the hard handoff is performed between 17

two CDMA channels on the same frequency, with the setup test as shown in Figure A-18

5: 19

1. Forward Channel from base station 1 has an arbitrary pilot PN offset index P1 20

and is called Channel 1. 21

2. Forward Channel from base station 2 has an arbitrary pilot PN offset index P2 22

and is called Channel 2. 23

3. Test parameters set as shown in Table 3.6.4-2. 24

l. Note that in this case a hard handoff can be forced by excluding P1 from the Active Set. 25



3GPP2 C.S0044-D v1.0

3-21

3.7 Hard Handoff Between Different Band Classes 1

3.7.1 Definition 2

This test verifies hard handoff between two different band classes. Both band classes are 3 supported by the mobile station and base station. 4


(see[4]) 6









(see [1]) 15

2.1.1.1 Channel Spacing and Designation 16


None 18



1. The Forward Channel from the base station 1 in Band Class X has an arbitrary 21

pilot PN offset index P1 and is called Channel 1. 22

2. The Forward Channel from the base station 2 in Band Class Y has an arbitrary 23

pilot PN offset index P2 and is called Channel 2. 24

b. Set the test parameters as shown in Table 3.7.4-1 25

3GPP2 C.S0044-D v1.0

3-22

Table 3.7.4-1 1

Parameter Unit Band Class X Band Class Y

Îor/Ioc dB -5 -5



Ioc dBm/1.23 MHz -75 -75


2


d. Setup a call in Channel 1. 4


f. Initiate handoff from base station 1 to base station 2. Verify the base station sends a 6

General Handoff Direction Message, Universal Handoff Direction Message, or an 7

Extended Handoff Direction Message with proper parameters (refer to tables in Annex 8

B) to initiate handoff. 9

g. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 10

Completion Message and the handoff is completed successfully. 11

h. Reconnect Channel 1 to base station 1 with parameters listed in Table 3.5.4-1. 12

i. Initiate handoff from base station 1 to base station 2. Verify that base station 1 sends a 13

General Handoff Direction Message, Universal Handoff Direction Message, or an 14

Extended Handoff Direction Message with proper parameters (refer to tables in Annex 15

B) to initiate handoff. 16

j. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 17

Completion Message and the handoff is completed successfully. 18

k. This test can be repeated for hard handoffs between other band classes. 19


The mobile station shall comply with steps g and k. 21

3.8 Hard Handoff with and without Return on Failure 22

3.8.1 Definition 23

This test verifies the mobile station behavior when hard handoff fails and: 24

return on failure is allowed. 25

return on failure is disallowed. 26

3GPP2 C.S0044-D v1.0

3-23

3.8.2 Traceability (See[4]) 1




2.6.6.2.8.2 Hard Handoff With Return On Failure 5


3.6.6.1 Overview 7





None 12








Table 3.8.4-1 20


Îor/Ioc dB -5 -5


Traffic Ec/Ior dB -7 <-20 (or none)

Ioc dBm/1.23 MHz -75 -75

Pilot Ec/Io dB -13.2 -12

21





3GPP2 C.S0044-D v1.0

3-24

f. For Test 1, instruct the base station to initiate a handoff to Channel 2 and allow for 1

return on failure. Verify that the base station sends a General Handoff Direction 2

Message or a Universal Handoff Direction Message with the 3

RETURN_IF_HANDOFF_FAIL = ‘1’. 4

g. Due to the low traffic gain level on Channel 2 (refer to Table 3.6.4-1), the mobile station 5

will attempt the hard handoff as directed by the base station, but not complete it, and 6

declare a hard handoff failure. 7

h. Verify the mobile station returns to Channel 1 and verify user data in both directions. 8

i. For Test 2, instruct the base station to initiate a handoff to Channel 2 and disallow for 9

return on failure. Verify that the base station sends a General Handoff Direction 10

Message or a Universal Handoff Direction Message with RETURN_IF_HANDOFF_FAIL 11

= ‘0’ 12

j. Due to the low traffic gain level on Channel 2 (refer to Table 3.6.4-1), the mobile station 13

will attempt the hard handoff as directed by the base station, but not complete it, and 14

declare a hard handoff failure. 15

k. Verify the mobile station does not restore to the previous configuration and does not 16

return to Channel 1. 17

3.9 Search Window Size and Offset (Traffic State) 18

3.9.1 Definition 19

A CDMA call is established on sector of sectored base station 1. Delay is applied to sector ß 20

and base station 2. The level of sector ß is raised sufficiently high to ensure intersector handoff is 21 possible. The level of base station 2 is raised sufficiently high to ensure soft handoff is possible. 22

In section 3.9.3.1, the pilot strength measurements of base station 2 and sector ß are checked 23 against the search window size and search window offset settings for each of the neighbor pilots. 24 If the delay is greater than the search window size for the neighbor pilot then the mobile station 25 shall not send a Pilot Strength Measurement Message. 26

In section 3.9.3.2, the pilot strength measurements of base station 2 and sector ß are checked 27 against a common search window size (i.e. SRCH_WIN_N). If the delay is greater than the 28 search window size for the neighbor pilot then the mobile station shall not send a Pilot Strength 29 Measurement Message. 30

3.9.2 Formulas 31

Pilot_PN_sel = nearest Pilot PN in the neighbor set not to exceed the integer of 32 PILOT_PN_PHASE/64. 33

Neighbor_Chip_Offset = PILOT_PN_PHASE-(Pilot_PN_sel*64) 34

Num_Chips = Set_Chip_Offset - Sim_Chip_Offset 35

Chip_Delay (µs) = s300m/

244m x Num_chip 36

PILOT_PN_PHASE is the pilot PN phase obtained from the mobile station log file in units of 37 chips. PILOT_PN_PHASE is referenced to the zero offset Pilot PN sequence. Pilot_PN_sel 38 selects the closest neighbor’s Pilot PN and the value is subtracted from the PILOT_PN_PHASE 39

3GPP2 C.S0044-D v1.0

3-25

to determine the residual chip delay (i.e. Neighbor_Chip_Offset). Set_Chip_Offset is the desired 1 number of chip offsets for a particular test case. Sim_Chip_Offset is the inherent delay for a pilot 2 due to the time alignment/calibration of the equipment. Chip_Delay is the actual delay in usec the 3 tester should vary with the test equipment (e.g. fader) to achieve the proper Set_Chip_Offset (this 4 includes the inherent delay measured for Sim_Chip_Offset. When properly adjusted, the 5 Set_Chip_Offset should equal to the Neighbor_Chip_Offset. 6


(See[4]) 8

2.6.6 Handoff Procedures 9

2.6.6.2.1 Pilot Search 10

Table 2.6.6.2.1 Search Window Sizes 11

Table 2.6.6.2.1-2 Search Window Offset 12



2.7.2.3.2.34 Extended Pilot Strength Measurement Message 15



3.7.2.3.2.22 General Neighbor List Message 18

3.7.2.3.2.34 Universal Neighbor List Message 19


None 21


3.9.5.1 Method of Measurement with NGHBR_SRCH_MODE = ‘10’ (search window size 23

per neighbor 24

25

3GPP2 C.S0044-D v1.0

3-26

Table 3.9.5-1 Test Cases for NGHBR_SRCH_MODE=’10’ (Traffic State) 1

Test Case

P2 win size

P2 win offset

P2 Set_Chip_Offset

P3 win size

P3 win offset

P3 Set_Chip_Offset

1 7 0 P3 win/4

+P3 offset

9 0 P3 win/4

+P3 offset

2 7 0 P3 win/2

+P3 offset

9 0 P3 win/2

+P3 offset

3 7 0 P3 win/2

+P3 offset

+10 chips

9 0 P3 win/2

+P3 offset

+10 chips

4 7 0 P3 win/2

+P3 offset

7 1 P3 win/2

+P3 offset

5 7 0 P3 win/2 7 4 P3 win/2

2








b. Set the test parameters as specified in Table 3.9.5-2. 10

c. The Reverse Link attenuation should be set to balance the forward and reverse links 11


13

3GPP2 C.S0044-D v1.0

3-27

Table 3.9.5-2 Test Parameters for Search Window per Neighbor (Traffic State) 1





Ioc dBm/1.23 MHz -75 -75 -75

Pilot Ec/Io dB –9.6 -30.6 -30.6

2 Note: The Pilot Ec/I0 value is calculated from the parameters set in the table. It is not a settable 3

parameter itself. 4

d. Set the following values in the General Neighbor List Message (GNLM) or the Universal 5

Neighbor List Message (UNLM): 6

7

Field Value

NGHBR_CONFIG_PN_INCL 1 (for GNLM only)

NGHBR_SRCH_MODE ‘10’

SRCH_OFFSET_INCL 1

8

Neighbor Setting for P2

NGHBR_PN P2

SRCH_WIN_NGHBR 7 (40 chips)

SRCH_OFFSET_NGHBR 0 (no offset)

9


NGHBR_PN P3



10

3GPP2 C.S0044-D v1.0

3-28

e. Determine the inherent delay of the channel simulator (i.e. Sim_Chip_Offset). 1

f. For Test 1, set the delay on both Channel 2 and on Channel 3 to a Chip_Delay such 2

that Set_Chip_Offset =(SRCH_WIN_NGHBR of P3)/4 + SRCH_OFFSET_NGHBR of 3

P3 (i.e Set_Chip_Offset of P2 is equal to Set_Chip_Offset of P3). 4

g. Setup a mobile station originated call. 5

h. Raise the level of Channel 2 to Îor/Ioc = +1 dB without dropping the call. 6

i. Raise the level of Channel 3 to Îor/Ioc = +1 dB without dropping the call. 7

j. End the call. 8

k. Reset the test parameters as specified in Table 3.9.5-2. 9

l. Verify the following: 10

1. The mobile station shall generate a Pilot Strength Measurement Message or an 11

Extended Pilot Strength Measurement Message when the Channel 2 pilot 12

strength is raised up to the same pilot strength as Channel 1 (Îor/Ioc=1dB). 13

2. The neighbor_Chip_Offset of P2 calculated from PILOT_PN_PHASE of the Pilot 14

Strength Measurement Message or the Extended Pilot Strength Measurement 15

Message generated in step h shall equal the Set_Chip_Offset of P2. 16

3. The mobile station shall also generate a Pilot Strength Measurement Message or 17

an Extended Pilot Strength Measurement Message when the Channel 3 pilot 18

strength is raised up to the same pilot strength as Channel 1 (Îor/Ioc=1 dB). 19



Message generated in step i shall equal the Set_Chip_Offset of P3. 22

m. For Test 2, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such that 23

Set_Chip_Offset = (SRCH_WIN_NGHBR of P3)/2 + SRCH_OFFSET_NGHBR of P3. 24

n. Repeat steps g to k. 25

o. Verify the following: 26

1. The mobile station shall not generate a Pilot Strength Measurement Message or 27









p. For Test 3, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such that 36

Set_Chip_Offset = (SRCH_WIN_NGHBR of P3)/2 + SRCH_OFFSET_NGHBR of P3 + 37

10 chips. 38

3GPP2 C.S0044-D v1.0

3-29

q. Repeat steps g to k. 1

r. Verify that the mobile station does not generate a Pilot Strength Measurement Message 2

or an Extended Pilot Strength Measurement Message when either the Channel 2 or 3

Channel 3 pilot strength is raised up to the same pilot strength as Channel 1 (Îor/Ioc=1 4

dB). 5

s. Set the following values in the General Neighbor List Message or the Universal 6

Neighbor List Message: 7

8

9

Field Value



SRCH_OFFSET_INCL 1

10


NGHBR_PN P2



11


NGHBR_PN P3


SRCH_OFFSET_NGHBR 1 (window_size/2)

12

t. For Test 4, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such that 13


u. Repeat steps g to k. 15

v. Verify the following: 16




3GPP2 C.S0044-D v1.0

3-30







w. Set the following values in the General Neighbor List Message or the Universal 7


9

Field Value



SRCH_OFFSET_INCL 1

10


NGHBR_PN P2



11


NGHBR_PN P3


SRCH_OFFSET_NGHBR 4 (-window_size/2)

12

x. For Test 5, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such that 13

Set_Chip_Offset =(SRCH_WIN_NGHBR of P3)/2. 14

y. Repeat steps g to k. 15

z. Verify the following: 16




3GPP2 C.S0044-D v1.0

3-31







3.9.5.2 Method of Measurement with NGHBR_SRCH_MODE = ‘00’ (same search 7

window size for all neighbor) 8

9

Table 3.9.5-3 Test Cases for NGHBR_SRCH_MODE=’00’ (Traffic State) 10

Test Case

Neighbor Message

P2 win size

P2 Set_Chip_Offset

P3 win size

P3 Set_Chip_Offset

1 GNLM 7 SRCH_Win_N/2 7 SRCH_WIN_N/4

2 GNLM 7 SRCH_Win_N/2 + 10 chips

7 SRCH_WIN_N/4 + 10 chips

3 UNLM 7 SRCH_Win_N/2 7 SRCH_WIN_N/4

4 UNLM 7 SRCH_Win_N/2 + 10 chips


11

a. Setup test as shown in A-4 12







b. Set the test parameters as specified in Table 3.9.5-3. 19



d. Set the following value in the System Parameters Message: 22

23

Field Value

SRCH_WIN_N 7 (40 chips)

24

3GPP2 C.S0044-D v1.0

3-32

e. Set the following values in the General Neighbor List Message: 1

2

Field Value


3

f. For Tests 1 and 3, set the delay on Channel 2 to a Chip_Delay such that 4

Set_Chip_Offset of P2 =SRCH_WIN_N/2, and set the delay on Channel 3 to a 5

Chip_Delay such that Set_Chip_Offset=SRCH_WIN_N/4. 6


h. Raise the level of Channel 2 to Îor/Ioc = +1 dB without dropping the call. 8

i. Raise the level of Channel 3 to Îor/Ioc = +1 dB without dropping the call. 9

j. End the call. 10

k. Reset the test parameters as specified in Table 3.9.5-3. 11








3. The mobile station shall also generate a Pilot Strength Measurement Message or 19






m. For Tests 2 and 4, set the delay on Channel 2 to a Chip_Delay such that 25

Set_Chip_Offset of P2 =(SRCH_WIN_N/2)+10 chips, and set the delay on Channel 3 to 26

a Chip_Delay such that Set_Chip_Offset=(SRCH_WIN_N/4)+10 chips. 27

n. Repeat steps g to k. 28

o. Verify the following: 29




3GPP2 C.S0044-D v1.0

3-33







p. Set the following values in the Universal Neighbor List Message: 7

8

Field Value


SRCH_WIN_N 7 (40 Chips)

9

q. For Tests 3 and 4 repeat steps b to o using parameter values in step t sent over the 10

Universal Neighbor List Message instead of the General Neighbor List Message. 11


3.9.6.1 For section 3.9.4.1: 13

Verify steps l, o, r, v and z for Tests 1 to 5. 14

3.9.6.2 For section 3.9.4.2: 15

Verify step l for Tests 1 and 3. 16

Verify step o for Tests 2 and 4. 17

3.10 Search Window Size and Offset (Idle State) 18


The mobile station is operating in idle state and monitoring sector of base station 1. Delay is 20

applied to both sector ß of base station 1 and base station 2. The level of neighbor pilots are 21 raised sufficiently high to ensure idle handoff is possible. 22

In section 3.9.3.1, the pilot strength measurements of base station 2 and sector ß of base station 23 1 are checked against the search window size and search window offset settings for each of the 24 neighbor pilots. If the delay is greater than the search window size for the neighbor pilot then the 25 mobile station shall not idle handoff to that neighbor pilot. 26

In section 3.9.3.2, the pilot strength measurements of base station 2 and sector ß of base station 27 1are checked against a common search window size (i.e. SRCH_WIN_N). If the delay is greater 28 than the search window size for the neighbor pilot then the mobile station shall not idle handoff to 29 that neighbor pilot. 30

Formulas 31

Num_Chips = Set_Chip_Offset - Sim_Chip_Offset 32

3GPP2 C.S0044-D v1.0

3-34

Chip_Delay (µs) = s300m/

244m x Num_chip 1

Set_Chip_Offset is the desired number of chip offsets for a particular test case. Sim_Chip_Offset 2 is the inherent delay for a pilot due to the time alignment/calibration of the equipment. Chip_Delay 3 is the actual delay in usec the tester should vary with the test equipment (e.g. fader) to achieve 4 the proper Set_Chip_Offset (this includes the inherent delay measured for Sim_Chip_Offset. 5 When properly adjusted, the Set_Chip_Offset should equal to the neighbor pilot’s chip offset from 6 zero chip delay. 7


(See[4]); 9


2.6.6.2.1 Pilot Search 11

Table 2.6.6.2.1 Search Window Sizes 12

Table 2.6.6.2.1-2 Search Window Offset 13


3.7.2.3.2 System Parameters Message 15


3.7.2.3.2.34 Universal Neighbor List Message 17


None 19


3.10.4.1 Method of Measurement with NGHBR_SRCH_MODE = ‘10’ (search window size 21

per neighbor) 22

23

3GPP2 C.S0044-D v1.0

3-35

Table 3.10.4-1 Test Cases for NGHBR_SRCH_MODE=’10’ (Idle State) 1

Test Case

P2 win size

P2 win offset

P2 Set_Chip_Offset

P3 win size

P3 win offset

P3 Set_Chip_Offset

1 7 0 P3 win/4

+P3 offset

9 0 P3 win/4

+P3 offset

2 7 0 P3 win/2

+P3 offset

9 0 P3 win/2

+P3 offset

3 7 0 P3 win/2

+P3 offset

+10 chips

9 0 P3 win/2

+P3 offset

+10 chips

4 7 0 P3 win/2

+P3 offset

7 1 P3 win/2

+P3 offset

5 7 0 P3 win/2 7 4 P3 win/2

2








b. The Reverse Link attenuation should be set to balance the forward and reverse links 10


c. Set the following values in the General Neighbor List Message (GNLM) or the Universal 12


14

Field Value



SRCH_OFFSET_INCL 1

15

3GPP2 C.S0044-D v1.0

3-36


NGHBR_PN P2



1


NGHBR_PN P3



2

d. Determine the inherent delay of the channel simulator (i.e. Sim_Chip_Offset). 3

e. For Test 1, set the delay on both Channel 2 and on Channel 3 to a Chip_Delay such 4

that Set_Chip_Offset =(SRCH_WIN_NGHBR of P3)/4 + SRCH_OFFSET_NGHBR of 5

P3 (i.e. Set_Chip_Offset of P2 is equal to Set_Chip_Offset of P3). 6

f. Set the test parameters as specified in Table 3.10.4-12 for state S1 in all 3 channels. 7

8

Table 3.10.4-2 Test Parameters for Search Window per Neighbor (Idle State) 9


Îor/Ioc dB 1 (S1 and S2) -20 for S1

5 for S2

-20 for S1

5 for S2



Ioc dBm/1.23 MHz -75 -75 -75

Pilot Ec/Io dB –9.6 for S1

-13.3 for S2

-30.6 for S1

-9.3 for S2

-30.6 for S1

-9.3 for S2

10 Note: The Pilot Ec/I0 value is calculated from the parameters set in the table. It is not a settable 11

parameter itself. 12

g. Allow the mobile station to monitor Channel 1 while in idle state. 13

3GPP2 C.S0044-D v1.0

3-37

h. Raise the level of Channel 2 to Îor/Ioc = +5 dB (State S2 for Channel 2 in Table 1

3.10.4-2). 2

i. Reset the test parameter as specified in Table 3.10.4-2for state S1 in all 3 channels. 3

j. Raise the level of Channel 3 to Îor/Ioc = +5 dB (State S2 for Channel 3 in Table 4

3.10.4-2). 5


1. The mobile station shall perform an idle handoff to Channel 2 in step h. 7

2. The mobile station shall perform an idle handoff to Channel 3 in step j. 8

3. For Test 2, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such 9

that Set_Chip_Offset = (SRCH_WIN_NGHBR of P3)/2 + 10

SRCH_OFFSET_NGHBR of P3. 11

l. Repeat steps f to j. 12


1. The mobile station shall not perform an idle handoff to Channel 2 in step h. 14


3. For Test 3, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such 16

that Set_Chip_Offset = (SRCH_WIN_NGHBR of P3)/2 + 17

SRCH_OFFSET_NGHBR of P3 + 10 chips. 18

n. Repeat steps f to j. 19

o. Verify that the mobile station does not perform idle handoff(s) in either step h or j. 20

p. Set the following values in the General Neighbor List Message or the Universal 21


23

Field Value



SRCH_OFFSET_INCL 1

24


NGHBR_PN P2



3GPP2 C.S0044-D v1.0

3-38

1


NGHBR_PN P3


SRCH_OFFSET_NGHBR 1 (window_size/2)

2

q. For Test 4, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such that 3


r. Repeat steps g to k. 5

s. Verify the following: 6



t. Set the following values in the General Neighbor List Message or the Universal 9


11

Field Value



SRCH_OFFSET_INCL 1

12


NGHBR_PN P2



13


NGHBR_PN P3


SRCH_OFFSET_NGHBR 4 (-window_size/2)

3GPP2 C.S0044-D v1.0

3-39

1

u. For Test 5, set the delay on both Channel 2 and Channel 3 to a Chip_Delay such that 2

Set_Chip_Offset = (SRCH_WIN_NGHBR of P3)/2. 3

v. Repeat steps g to k. 4

w. Verify the following: 5


2. The mobile station shall not perform an idle handoff to Channel 3 in step j. 7

3.10.4.2 Method of Measurement with NGHBR_SRCH_MODE = ‘00’ (same search 8

window size for all neighbor) 9

Table 3.10.4-3 Test Cases for NGHBR_SRCH_MODE=’00’ (Idle State) 10

Test Case

Neighbor Message

P2 win size

P2 Set_Chip_Offset

P3 win size

P3 Set_Chip_Offset

1 GNLM 7 SRCH_Win_N/2

7 SRCH_WIN_N/4

2 GNLM 7 SRCH_Win_N/2 + 10 chips


3 UNLM 7 SRCH_Win_N/2

7 SRCH_WIN_N/4

4 UNLM 7 SRCH_Win_N/2 + 10 chips


11








b. The Reverse Link attenuation should be set to balance the forward and reverse links 19


c. Set the following value in the System Parameters Message: 21

Field Value


3GPP2 C.S0044-D v1.0

3-40

d. Set the following values in the General Neighbor List Message: 1

Field Value


e. For Tests 1 and 3, set the delay on Channel 2 to a Chip_Delay such that 2

Set_Chip_Offset of P2 =SRCH_WIN_N/2, and set the delay on Channel 3 to a 3

Chip_Delay such that Set_Chip_Offset=SRCH_WIN_N/4. 4

f. Set the test parameters as specified in Table 3.10.4-2 for state S1 in all 3 channels. 5

g. Allow the mobile station to monitor Channel 1 while in idle state. 6

h. Raise the level of Channel 2 to Îor/Ioc = +5 dB (State S2 for Channel 2 in Table 7

3.10.4-2). 8

i. Reset the test parameter as specified in Table 3.10.4-2 for state S1 in all 3 channels. 9

j. Raise the level of Channel 3 to Îor/Ioc = +5 dB (State S2 for Channel 3 in Table 10

3.10.4-2). 11




3. For Tests 2 and 4, set the delay on Channel 2 to a Chip_Delay such that 15

Set_Chip_Offset of P2 =(SRCH_WIN_N/2)+10 chips, and set the delay on 16

Channel 3 to a Chip_Delay such that Set_Chip_Offset=(SRCH_WIN_N/4)+10 17

chips. 18

l. Repeat steps f to j. 19




n. Set the following values in the Universal Neighbor List Message: 23

24

Field Value


SRCH_WIN_N 7 (40 Chips)

25

o. For Tests 3 and 4, repeat steps b to n using parameter values in step t sent over the 26

Universal Neighbor List Message instead of the General Neighbor List Message. 27

3GPP2 C.S0044-D v1.0

3-41


3.10.5.1 For section 3.9.3.1: 2

Verify steps k, n and q for Tests 1 to 3, Tests 6 to 20 and Tests 23 to 34. Verify steps u and y for 3 Tests 4 to 5 and Tests 21 to 22. 4

3.10.5.2 For section 3.9.3.2: 5

Verify step k for Tests 1 and 3. 6

Verify step n for Tests 2 and 4. 7

3.11 Channel Assignment into Soft Handoff (CASHO) 8

3.11.1 Definition 9

This tests for mobile operation of Channel Assignment into Soft Handoff (CASHO). CASHO 10 allows multiple pilots to be assigned in the Extended Channel Assignment Message from the 11 pilots reported in the Origination Message or Page Response Message. 12


(see [4]) 14


2.6.3.1.7 Monitoring Pilots 16



None 19


a. Connect the mobile station as shown in Figure A-5. Ensure both pilot Ec/Io values are 21

well above T_ADD. 22

b. Allow the mobile station to come to the idle state on one of the base stations. 23

c. Make a mobile station originated call. 24

d. Verify both base station pilots are reported in the Origination Message. 25

e. Verify the mobile station receives an Extended Channel Assignment Message 26

assigning both pilots and calls complete normally. 27

f. Repeat steps c-e for a mobile station terminated call with the exception that in step d 28

the Page Response Message is used instead of the Origination Message. 29


The mobile station shall comply with the requirements in steps d, e and f. 31

3GPP2 C.S0044-D v1.0

3-42

3.12 Traffic Channel Preamble during Hard Handoff Between Frequencies in same band 1

3.12.1 Definition 2

The mobile station is transitioned between base stations with different CDMA frequency (channel) 3 assignments in the same band. The Traffic Channel Preamble is a sequence of all-zero frames 4 that is sent by the mobile station on the Reverse Traffic Channel as an aid to Traffic Channel 5 acquisition. 6


(See[4]) 8






(See[2]) 14

2.1.3.2.4 Reverse Pilot Channel Operation during RTC Preamble 15

2.1.3.6.2.3 Reverse Traffic Channel Preamble 16


None 18









Channel 1 and Channel 2) 27


29

3GPP2 C.S0044-D v1.0

3-43

Table 3.12.4-1 1


Îor/Ioc dBm N/A -5






d. Configure base station 1 and base station 2 for RC1 or RC2. 3



g. Initiate handoff from Channel 1 to Channel 2. 6

h. Verify that the base station 1 sends the General Handoff Direction Message, Universal 7

Handoff Direction Message, or Extended Handoff Direction Message with correct 8

NUM_PREAMBLE value. Verify the Reverse Traffic Channel preamble length. 9

i. Wait 20 seconds then initiate handoff from Channel 2 to Channel 1. 10

j. Verify that the base station 2 sends the General Handoff Direction Message, Universal 11

Handoff Direction Message, or Extended Handoff Direction Message correct 12

NUM_PREAMBLE value. Verify the Reverse Traffic Channel preamble length. 13

k. Configure base station 1 and base station 2 for RC3 or RC5. 14

l. Repeat steps e through j. 15


The mobile station shall comply with steps h, j, and l. 17

18

NUM_PREAMBLE RC1, RC2

Preamble Length in 20 ms Increments: (Total Time)

RC>2

Preamble Length in 1.25 ms Increments: (Total Time)

0 0 (0 ms) 0 (0 ms)

4 4 (80 ms) 8 (10 ms)

19

3GPP2 C.S0044-D v1.0

3-44

3.13 Hopping Pilot Beacon 1

3.13.1 Definition 2

The mobile station is transitioned between base stations with different CDMA frequency (channel) 3 assignments in the same band. 4

The Hopping Pilot Beacon is a pilot beacon that changes CDMA Frequency periodically to 5 simulate multiple base stations operating on different frequencies. The transmission of the 6 hopping pilot beacon is discontinuous on any CDMA Channel. 7


(See[4]) 9




2.7.4.25 Capability Information 13

3.6.1.2 Pilot Channel Operation 14





(See[1]) 19

3.1.3.2.5 Hopping Pilot Beacon 20


None 22


a. Configure base station 1 and 2 for hopping pilot beacon. 24

b. Setup test as shown in A-2. 25








c. Set the test parameters as shown in Table 3.13.4-1. 33

34

3GPP2 C.S0044-D v1.0

3-45

Table 3.13.4-1 1


Îor/Ioc dBm N/A -5





2

d. Set reverse link attenuation to balance forward and reverse links (approx. 90 dB). 3



g. Verify hopping pilot beacon settings in the General Neighbor List Message or Extended 6

Neighbor List Message. Initiate handoff from Channel 1 to Channel 2. Verify that the 7

base station 1 sends a General Handoff Direction Message, Universal Handoff 8

Direction Message, or an Extended Handoff Direction Message with proper parameters 9

(refer tables in Annex B). 10

h. Verify the handoff is successful 11

i. Verify hopping pilot beacon settings in the General Neighbor List Message or Extended 12

Neighbor List Message. Wait 20 seconds then initiate handoff from Channel 2 to 13

Channel 1. Verify that the base station 2 sends a General Handoff Direction Message, 14

Universal Handoff Direction Message, or an Extended Handoff Direction Message with 15

the proper parameters (refer to tables in Annex B). 16


The mobile station shall comply with steps h and i 18

3.14 Hard Handoff between Frequencies with Different Radio Configurations 19


The mobile station is transitioned between base stations with different CDMA frequency (channel) 21 assignments in the same band and different radio configurations. 22


(See[4]) 24



3GPP2 C.S0044-D v1.0

3-46

2.6.6.2.8 DMA-to-CDMA Hard Handoff 1



(See[1]) 4

2.1.3.1 Reverse CDMA Channel Signals 5

3.1.3.1 Forward CDMA Channel Signals 6


None 8


a. Configure base station 1 for RC3 or RC5. Configure base station 2 for RC1 or RC2. 10

b. Setup test as shown in A-5. 11









20

Table 3.14.4-1 21


Îor/Ioc dBm N/A -5





22




3GPP2 C.S0044-D v1.0

3-47

g. Initiate handoff from Channel 1 to Channel 2. Verify that the base station 1 sends a 1

General Handoff Direction Message, or Universal Handoff Direction Message with 2

proper parameters (refer to tables in Annex B) 3

h. Wait 20 seconds then initiate handoff from Channel 2 to Channel 1. Verify that the base 4

station 2 sends a General Handoff Direction Message, or Universal Handoff Direction 5

Message with the proper parameters (refer to tables in Annex B). 6

i. Configure base station 1 for RC1 or RC2. Configure base station 2 for RC3 or RC5 and 7

repeat steps b through h. 8

j. Configure base station 1 for RC3. Configure base station 2 for RC4 and repeat steps b 9

through h. 10

k. Configure base station 1 for RL RC8 and FL RC11. Configure base station 2 for RC3 or 11

RC5 and repeat steps b through h. 12


The mobile station shall comply with steps g, h, I, j and k. 14

3.15 Handoff on Same Frequency with Different Radio Configurations 15


The mobile station is transitioned between base stations with the same CDMA frequency 17 (channel) assignments in the same band and different radio configurations. 18

When the active set membership before and after the handoff are disjoint, the handoff is 19 performed as a hard handoff; when the active set membership before and after handoff are not 20 disjoint, except for the value of the radio configuration, the handoff is performed as a soft handoff. 21


(See[4]) 23






(See[1]) 29

2.1.3.1 Reverse CDMA Channel Signals 30

3.1.3.1 Forward CDMA Channel Signals 31


None 33

3GPP2 C.S0044-D v1.0

3-48


a. Configure base station 1 for RC4 or RC5. Configure base station 2 for RC1 or RC2. 2

b. Setup test as shown in Figure A-2 3





3. The AWGN source should be added to both Channels. 8


10

Table 3.15.4-1 Hard Handoff Test Parameters 11


Îor/Ioc dBm N/A -5





12




g. Initiate handoff from Channel 1 to Channel 2. Verify that the base station 1 sends a 16

General Handoff Direction Message, or Universal Handoff Direction Message with 17

proper parameters (refer to tables in Annex B) 18

h. Wait 20 seconds then initiate handoff from Channel 2 to Channel 1. Verify that the base 19

station 2 sends a General Handoff Direction Message, or Universal Handoff Direction 20

Message with the proper parameters (refer to tables in Annex B). Note the base station 21

may send the handoff message encapsulated in a General Extension Message if RL 22

RC 8 and FL RC 11 are assigned to the mobile station. 23

i. Configure base station 1 for RC1 or RC2. Configure base station 2 for RC4 or RC5 and 24

repeat steps b through h. 25

j. Configure base station 1 for RC3. Configure base station 2 for RC4 and repeat steps b 26

through h. 27

3GPP2 C.S0044-D v1.0

3-49

k. Configure base station 1 for RL RC8 and FL RC11. Configure base station 2 for RC3, 1

RC 4 or RC5 and repeat steps b through h. 2

l. Repeat steps a through j but with the following exception: Only base station 1 is used 3

for this test. The handoff messages are sent from base station 1 without changing the 4

active set, but changing the radio configuration. Thus the handoff messages simply 5

assign a new radio configuration from the same base station. 6

m. Verify that the handoff is performed as a soft handoff. 7


The mobile station shall comply with steps g, h, i, j, k and m. 9

3.16 Hard Handoff while in the Waiting for Mobile Station Answer Substate 10


This test verifies that if a hard handoff occurs while the mobile station is in the Waiting for Mobile 12 Station Answer Substate, the hard handoff will be completed successfully and the mobile station 13 shall enter the Conversation Substate on the new channel. 14


(see [4]) 16


2.6.4.3.2 Waiting for Mobile Station Answer Substate 18

2.6.4.4 Conversation Substate 19

2.6.6.2.5.1 Processing of the Forward Traffic Channel Handoff Messages 20

2.6.6.2.8 CDMA to CDMA Hard Handoff 21

3.6.4.3.1 Waiting for Order Substate 22

3.6.6.2.2 Call Processing during Handoff 23




Table D-1 Time Constants 27

(see [34]) 28

3.1 Standard Service Option Number Assignments 29

3.2 Proprietary Service Option Number Assignments 30


None 32

3GPP2 C.S0044-D v1.0

3-50


a. Connect the mobile station to the base station as shown in Figure A-5 and set the test 2

parameters as specified in Table 3.2.4-1. 3

1. Base station 1 is a CDMA base station with frequency F1, PN offset P1 and is 4

referred to as Channel 1. 5

2. Base station 2 is a CDMA base station with frequency F2, PN offset P2 and is 6

referred to as Channel 2. 7

b. Ensure the mobile station is operating in the Idle State on Channel 1. 8

c. Page the mobile station with a supported service option. 9

d. After receiving the Page Response Message, instruct the base station to send an 10

Extended Channel Assignment Message with the following parameters: 11

12

Field Value

ASSIGN_MODE '000' or '100'

BYPASS_ALERT_ANSWER '0'

13

e. While the mobile station is in the Waiting for Mobile Station Answer Substate (i.e. 14

ringing), instruct the base station to send an Extended Handoff Direction Message, 15

General Handoff Direction Message, or Universal Handoff Direction Message directing 16

the mobile station to Channel 2. Note the base station may send the handoff message 17

encapsulated in a General Extension Message if RL RC 8 and FL RC 11 are assigned 18

to the mobile station. 19

f. If the base station sends a second (Extended) Alert with Information Message from 20

base station 2, verify the mobile station resets T53m (65 seconds) and the information 21

record(s) included override the first (Extended) Alert with Information Message. The 22

mobile station should not prompt the user to answer the call twice or indicate a “missed 23

call.” 24

g. After the hard handoff has been completed and before T53m (65 seconds), has expired 25

direct the user to answer the call. 26

h. Verify the mobile station enters the Conversation Substate and user traffic is present in 27

both directions (i.e. audio). 28

i. End the call. 29

j. Repeat steps b through j using different service options and radio configurations 30

supported by the mobile station and base station. 31

k. Repeat steps b through j, changing Channel 2 to a band class that is different from 32

Channel 1 but is supported by the mobile station. 33

3GPP2 C.S0044-D v1.0

3-51


The mobile station shall comply with steps h and j. 2

3.17 Mobile Assisted Inter-Frequency Hard Handoff (CDMA to CDMA) 3

3.17.1 Definition 4

In an Inter-Frequency Hard Handoff test (also known as the Mobile Assisted Hard Handoff test), 5 when the mobile station is directed by the base station to perform a search on a Candidate 6 Frequency, the mobile station will search for a pilot in the Candidate Frequency Neighbor Set. 7 The mobile station will report back to the base station any pilot detected in the Candidate 8 Frequency Neighbor Set with a pilot Ec/Io above the value defined by CF_T_ADD. The base 9 station should then direct the mobile station to the Candidate Frequency and completes the hard 10 handoff. 11


(see [4]) 13



2.7.2.3.2.20 Candidate Frequency Search Report Message 16


3.7.7.3.3.2.27 Candidate Frequency Search Request Message 18


None 20



1. The Forward Channel from base station 1 has a CDMA frequency assignment F1 23

(any valid value), an arbitrary pilot PN offset index P1 and is called Channel 1. 24


(any valid value other than f1 in the same band class), an arbitrary pilot PN offset 26

index P2 and is called Channel 2. 27

28

3GPP2 C.S0044-D v1.0

3-52


Îor/Ioc dB 2.9 2.9

or

c

I

EPilot

dB -7 -7

Ior

EcTraffic

dB -7 N/A


0

c

I

EPilot

dB -11.0 -11.0

1

b. Reverse Link attenuation should be set to balance the forward and reverse links. 2

c. Set up a mobile station originated call on Channel 1. 3

d. Send from base station 1 a Candidate Frequency Search Request Message to the 4

mobile station to set an explicit action time with the following parameters: 5

6

Field Value (Decimal)

USE_TIME 1 (use action time)

SEARCH_TYPE 1 (single search)

SEARCH_MODE 0 (CDMA)

CDMA_FREQ F2

SF_TOTAL_EC_THRESH 31 (disabled)

SF_TOTAL_EC_IO_THRESH 31 (disabled)

CF_SRCH_WIN_N 8 (60 chips)

CF_T_ADD 28 (-14 dB)

NUM_PILOTS 1 (1 pilot)

CF_NGHBR_SRCH_MODE 0 (no search priorities or search windows specified)

NGHBR_PN P2

3GPP2 C.S0044-D v1.0

3-53

1

e. Verify that the mobile station responds with a Candidate Frequency Search Report 2

Message. 3

f. Verify that base station 1 sends a General Handoff Direction Message, an Extended 4

Handoff Direction Message or a Universal Handoff Direction Message to initiate handoff 5

from base station 1 to base station 2. Note the base station may send the handoff 6

message encapsulated in a General Extension Message if RL RC 8 and FL RC 11 are 7

assigned to the mobile station. 8



The mobile station shall comply with steps e and g. 11

3.18 Mobile Assisted Inter-Frequency Hard Handoff (CDMA to Analog) 12


In an Inter-Frequency Hard Handoff test (also known as the Mobile Assisted Hard Handoff test), 14 when the mobile station is directed by the base station to perform a search on a Candidate 15 Frequency, the mobile station will search for an analog channel in the Candidate Frequency 16 Analog Search Set and shall measure the mean input power on the analog frequency. The mobile 17 station will report back to the base station the signal strength of the analog channel searched. 18 The base station should then direct the mobile station to the Analog Channel and completes the 19 hard handoff. 20


(see [4]) 22



2.6.6.10.2 Candidate Frequency Analog Search Set 25

2.7.2.3.2.21 Candidate Frequency Search Report Message 26


3.7.7.3.3.2.27 Candidate Frequency Search Request Message 28


None 30




(any valid value), an arbitrary pilot PN offset index P1 and is called Channel 1. 34

3GPP2 C.S0044-D v1.0

3-54

2. The Forward Channel from base station 2 uses an analog frequency called 1

Channel 2. 2

b. Set the test parameters as specified in Table 3.15.4-1 and Table 3.18.4-2 3

4

Table 3.18.4-1 Test Parameters for Inter-Frequency Hard Handoff (Channel 1) 5

CDMA Parameter Unit Channel 1

Îor/Ioc dB 0

Pilot Ec/Ior dB -7

Traffic Ec/Ior dB -7


Pilot Ec/Io dB -10

6

7

Table 3.18.4-2 Test Parameter for Inter-Frequency Handoff (Channel 2) 8

Analog Parameter Unit Channel 2

Voice Channel dBm -73

Co-Channel Interference dB -18

c. Reverse Link attenuation should be set to balance the forward and reverse links. 9

d. Set up a mobile station originated voice call on Channel 1. 10

e. Send from base station 1 a Candidate Frequency Search Request Message to the 11

mobile station to set an explicit action time with the following parameters: 12

13


USE_TIME 1 (use action time)

SEARCH_TYPE 1 (single search)

SEARCH_MODE 1 (search for analog channels)

SF_TOTAL_EC_THRESH 31 (disabled)

SF_TOTAL_EC_IO_THRESH 31 (disabled)

3GPP2 C.S0044-D v1.0

3-55

NUM_ANALOG_FREQS 1

ANALOG_FREQ Channel 2

1

f. Verify that the mobile station responds with a Candidate Frequency Search Report 2

Message. 3

g. Verify that base station 1 sends an Analog Handoff Direction Message to initiate 4

handoff from base station 1 to base station 2. 5

h. Verify audio in both directions. 6


The mobile stations shall comply with steps f and h. 8

3.19 Hard Handoff between Frequencies with Different Protocol Revisions 9


This test verifies the mobile station is able perform a hard handoff between base stations 11 supporting using different protocol revisions (P_REV). 12


(See[4]) 14










None 24


a. Configure base station one and base station two with different protocol revisions. 26

b. Verify the mobile station supports the protocol revisions on each base station. 27

c. Setup test as shown in Figure A-5. 28

3GPP2 C.S0044-D v1.0

3-56

1. The Forward Channel from base station one has an arbitrary pilot PN offset index 1


2. The Forward Channel from base station two has an arbitrary pilot PN offset index 3





d. Set the test parameters as shown in Table 3.19.4-1. 8

9

Table 3.19.4-1 Hard Handoff Test Parameters 10


Îor/Ioc dBm N/A -5





11

e. Set reverse link attenuation to balance forward and reverse links (approx. 90 dB). 12

f. Setup a mobile station originated call on Channel 1. 13

g. Verify user traffic in both directions. 14

h. Initiate handoff from Channel 1 to Channel 2. 15

i. Verify that the base station 1 sends General Handoff Direction Message, Universal 16

Handoff Direction Message, or Extended Handoff Direction Message with the P_REV 17

field value equal to the P_REV of base station two. Note the base station may send the 18

handoff message encapsulated in a General Extension Message if RL RC 8 and FL 19

RC 11 are assigned to the mobile station. 20

j. Verify the handoff is successful and user traffic is present in both directions. 21


The mobile station shall comply with step j. 23

24

3GPP2 C.S0044-D v1.0

4-1

4 POWER CONTROL 1

4.1 Forward Traffic Channel Power Control 2

4.1.1 Definition 3

This test verifies that the mobile station reports frame error rate statistics at specified intervals if 4 the base station enables periodic reporting, and verifies that the mobile station reports frame error 5 rate statistics when the frame error rate reaches a specified threshold if the base station enables 6 threshold reporting. 7


(See[4]) 9

2.6.4.1.1 Forward Traffic Channel Power Control 10

2.7.2.3.2.6 Power Measurement Report Message 11


3.7.3.3.2.10 Power Control Parameters Message 13

Applicability: Forward Link: RC 1 through RC 5, RC 11; Reverse Link: RC 1 through RC 4, RC 8 14


None 16


a. Setup test as shown in Annex A Figure A-6. 18

b. Setup a mobile station originated call using the test parameters for Test 1 as specified 19

in Table 4.1.4-1. 20

c. Set the AWGN source power so the forward link average FER is between 0.5 and 21

1.0%. 22

d. Instruct the base station to send the Power Control Parameters Message to enable the 23

threshold reporting and disable the periodic reporting according to the base station 24

manufacturer's forward power control algorithm. 25

26

PWR_THRESH_ENABLE ‘1’ (Enable threshold reporting)

PWR_PERIOD_ENABLE ‘0’ (Disable periodic reporting)

27

e. Using Attenuator 1, alternately increase and decrease AWGN source output power by 5 28

dB from the original power set in step c. 29

f. Monitor forward traffic channel Ec/Ior and ensure power increases and decreases 30

corresponding to noise power from the AWGN source. 31

3GPP2 C.S0044-D v1.0

4-2

g. Monitor forward link FER at the mobile station. 1

2

Table 4.1.4-1 Test Parameters for Forward Power Control Tests 3

Test Number

Forward RC

Reverse RC

Threshold/Periodic

Service Option Channels Forward Link Power [dBm/ 1.23 MHz]

1 1 1 Threshold 2, 54, 55, or 32798

F-FCH -65

2 1 1 Periodic 2, 54, 55, or 32798

F-FCH -65

3 2 2 Threshold 9, 54, 55, or 32799

F-FCH -62

4 2 2 Periodic 9, 54, 55, or 32799

F-FCH -62

5 3 3 Threshold 54, or 55 F-FCH -65

6 3 3 Periodic 54, or 55 F-FCH -65

Reserved

Reserved



Reserved

Reserved



Reserved

Reserved

Reserved

Reserved

Reserved

Reserved

3GPP2 C.S0044-D v1.0

4-3

Test Number

Forward RC

Reverse RC

Threshold/Periodic

Service Option Channels Forward Link Power [dBm/ 1.23 MHz]

Reserved

22 5 4 N/A 54, or 55 F-DCCH/F-SCH

-62

23 11 8 Threshold 74 F-FCH -65

24 11 8 Periodic 74 F-FCH -65

Note: All tests for RC other than FL RC 11 or RL RC 8 should be performed at full data rate or 1 at a variable rate. All tests for FL RC 11 and RL RC 8 should use non-critical Rate 1/8th frames 2 and ‘FOR_FCH_BLANKING_DUTYCYCLE value of ‘010’ (i.e. only one out of eight frames is 3 transmitted). Tests involving the Forward Supplemental Channels should only include 1 Forward 4 Supplemental Channel. 5

6

h. Verify MS sends the Power Measurement Report Message when the bad frames 7

received by the mobile station reaches the specified threshold. 8

i. End the call. 9

j. Setup a mobile station originated call using the test parameters for Test 2 as specified 10

in Table 4.1.4-1. 11

k. Instruct the base station to send the Power Control Parameters Message to enable the 12

periodic reporting and disable the threshold reporting according to the base station 13

manufacturer's forward power control algorithm. 14

15

PWR_THRESH_ENABLE ‘0’ (Disable threshold reporting)

PWR_PERIOD_ENABLE ‘1’ (Enable periodic reporting)

16

l. Repeat the steps e through g. 17

m. Verify the mobile station sends the Power Measurement Report Message when the 18

total frames received by the mobile station reach the specified report period. 19

n. End the call. 20

o. Repeat steps b through n except for using the test parameters for Tests 3 to 16 as 21


p. Repeat steps b through c except for using the test parameters for Test 17 to Test 22 as 23


3GPP2 C.S0044-D v1.0

4-4

q. Instruct the base station to send the Extended Supplemental Channel Assignment 1

Message including a Forward Supplemental Channel assignment and setting 2

FOR_SCH_FER_REP to ‘1’. 3

r. Repeat the steps e through g. 4

s. Verify the mobile station sends the Power Measurement Report Message at the end of 5

the burst. 6

t. End the call. 7


The mobile station shall comply with steps h, l, m, o, p, r and s. 9

The base station should alternately increase and decrease the forward traffic channel power 10 according to the base station manufacturer's forward power control algorithm. Forward link FER 11 measured at the mobile station should be within the target value and the mobile station shall 12 report frame error rate statistics. There shall not be any dropped calls. 13

4.2 Fast Forward Power Control (FFPC) 14

4.2.1 FFPC using different values of FPC_MODE (FPC_MODE = ‘000’, ‘001’, ‘010’) and 15

FPC_MODE (FPC_MODE = ‘000’, ‘011’, ‘010’) with RC 8 16

4.2.1.1 Definition 17

The mobile station accomplishes fast forward power control by transmitting the Reverse Power 18 Control Subchannel to the base station on the Reverse Pilot Channel. The mobile station 19 determines the information to be sent to the base station through inner and outer loop 20 estimations. In outer loop estimation, the mobile station adjusts the Eb/Nt setpoint to the Eb/Nt 21 value necessary to achieve the target FER on the Forward Traffic Channel. In inner loop 22 estimation, the mobile station compares the received Eb/Nt to the setpoint and determines the 23 value of the power control bit to be sent to the base station. There are 16 Power Control Groups 24 every 20 ms on the Reverse Power Control Subchannel. This test verifies that the mobile station 25 can process the various parameters in the Extended Channel Assignment Message, the 26 Extended Supplemental Channel Assignment Message, and the Service Connect Message. 27 Note, FPC_MODE may be changed using the Radio Configuration Parameters Message in the 28 tests for RC 8. 29

4.2.1.2 Traceability: 30

(See[1]) 31


(See[4]) 33


3.6.6.2.2.12 Processing of Extended Supplemental Channel Assignment Message 35

3.7.3.3.2.37 Extended Supplemental Channel Assignment Message 36



3GPP2 C.S0044-D v1.0

4-5


3.6.3.3 Response to Page Response Message 2




2.6.4.1.2.2 Service Subfunctions 6




3.7.5.20 Non negotiable System Configuration 10

11

Applicability: Forward Link: RC 1 through RC 5; Reverse Link: RC 1 through RC 4 12

FPC_MODE Information 13

Table 4.2.1-1 Reverse Power Control Subchannel Configurations for RL RC1 through RC4 14

Reverse Power Control Subchannel Allocations

(Power Control Group Numbers)

FPC_MODE Primary Reverse Power Control Subchannel

Secondary Reverse Power Control Subchannel

‘000’ 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 Not supported

‘001’ 0,2,4,6,8,10,12,14 1,3,5,7,9,11,13,15

‘010’ 1,5,9,13 0,2,3,4,6,7,8,10,11,12,14,15

15

Table 4.2.1-2 Reverse Power Control Subchannel Configurations for RL RC8 16

Reverse Power Control Subchannel Allocations

(Power Control Group Numbers 0-15)

FPC_MODE Primary Reverse Power Control Subchannel

Secondary Reverse Power Control Subchannel

‘000’ 1,3,5,7,9,11,13,15 Not supported

‘011’ 3,7,11,15 Not Supported

‘010’ 3,7,11,15 1,5,9,13

All other values Reserved Reserved

3GPP2 C.S0044-D v1.0

4-6

4.2.1.3 Call Flow Example(s) 1

None 2

4.2.1.4 Method of Measurement 3

4.2.1.4.1 FPC_MODE ‘000’; F-FCH Only 4

a. Connect base station and mobile station as shown in Annex A Figure A-6. 5

b. Set power levels as stated in Table 4.2.1-3: 6

Table 4.2.1-3 Test Parameters for Fast Forward Power Control 7


or

c

I

EPilot

dB

-7


Ior/Ioc dB 10

8

c. Setup a mobile station originated call using Service Option 55 (Loopback Service 9

Option) or Service Option 54 (Markov Service Option). 10

d. Instruct the base station to send the Extended Channel Assignment Message with the 11


13


FOR_RC = '00011' (RC 3) REV_RC = '00011' (RC 3)




14

e. Ensure the base station sends the Service Connect Message with FPC_INCL set to ‘0’. 15

f. Monitor the forward link FER at the mobile station. 16

3GPP2 C.S0044-D v1.0

4-7

g. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 15 dBm/1.23 MHz at 1

the AWGN source and then decrease Ioc in 1 dBm/1.23 MHz steps every second for a 2

total of 20 dBm/1.23 MHz at the AWGN source. 3

h. Monitor traffic channel Ec/Ior and ensure the power changes corresponding to noise 4

power from the AWGN source. The power increases if the noise power increases and 5

decreases if the noise power decreases. 6

i. Verify that the forward link FER on the FCH remains at approximately the target value 7

(i.e. 1%). 8

j. End the call at the mobile station. 9

k. Repeat steps a through j above except that FOR_RC is set to RC4 and REV_RC is set 10

to RC3 in step d. 11

l. Repeat steps a through j above except that FOR_RC is set to RC5 and REV_RC is set 12


m. Repeat steps a through j above except that FOR_RC is set to RC11 and REV_RC is 14

set to RC8 in step d. 15

4.2.1.4.2 FPC_MODE ‘000’; F-DCCH only 16





or

c

I

EPilot

dB

-7


Ior/Ioc dB 10

20

c. Setup a mobile station originated call using Service Option 32 (Test Data Service 21

Option). 22



25

3GPP2 C.S0044-D v1.0

4-8

ASSIGN_MODE = ‘100’ GRANTED_MODE = ‘10’

FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)

CH_IND = ‘10’ FPC_DCCH_INIT_SETPT = ‘01000000’ (8 dB)

FPC_DCCH_FER = ‘00010’ (1%) FPC_DCCH_MIN_SETPT = ‘00010000’ (2 dB)

FPC_DCCH_MAX_SETPT = ‘10000000’ (16 dB)

1

e. Ensure the base station sends the Service Connect Message with FPC_INCL set to ‘0’. 2





h. Monitor traffic channel Ec/Ior and ensure power changes corresponding to noise power 7

from the AWGN source. The power increases if the noise power increases and 8


i. Verify that the forward link FER on DCCH remains at approximately the target value 10

(1%). 11

j. End the call at the mobile station. 12

k. Repeat steps a through i above except for setting FOR_RC to RC4 and REV_RC to 13

RC3 in step d. 14

l. Repeat steps a through i above except for setting FOR_RC to RC5 and REV_RC to 15

RC4 in step d. 16

4.2.1.4.3 FPC_MODE ‘001’; F-FCH and F-SCH 17



3GPP2 C.S0044-D v1.0

4-9



or

c

I

EPilot

dB

-7


Ior/Ioc dB 10

2


Option). 4



7


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)

CH_IND = ‘01’ FPC_FCH_INIT_SETPT = ‘01000000’ (8 dB)

FPC_FCH_FER = ‘00010’ (1%) FPC_FCH_MIN_SETPT = ‘00010000’ (2 dB)

FPC_FCH_MAX_SETPT = ‘10000000’ (16 dB)

8

e. Instruct the base station to send the Service Connect Message with the parameters set 9

as follows: 10

11



FPC_MODE = ‘001’

12

f. Instruct the base station to download SCH configuration and assign a Forward 13



16

3GPP2 C.S0044-D v1.0

4-10


FPC_MODE_SCH = ‘001’ FPC_SCH_MAX_SETPT = ‘10000000’ (16 dB)

FPC_SCH_INIT_SETPT_OP = ‘0’ FPC_SCH_MIN_SETPT = ‘00010000’ (2 dB)

FPC_SCH_FER = ‘01010’ (5%)

1

g. Monitor the forward link FER on FCH and SCH (during the burst assignment) at the 2

mobile station. 3

h. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 15 dBm/1.23 MHz at 4



i. Monitor traffic channel Ec/Ior and ensure power changes corresponding to noise power 7



j. Verify that the forward link FER on FCH and SCH (during SCH assignment) remain at 10

approximately the target values. 11

k. End the call at the mobile station. 12

l. Repeat steps a through k above except that FOR_RC is set to RC4 and REV_RC is set 13


m. Repeat steps h through k above except that FOR_RC is set to RC5 and REV_RC is set 15


4.2.1.4.4 FPC_MODE ‘000’ without F-SCH Active and FPC_MODE ‘001’ with F-SCH 17

Active; F-DCCH and F-SCH 18





or

c

I

EPilot

dB

-7


Ior/Ioc dB 10

3GPP2 C.S0044-D v1.0

4-11

1


Option). 3



6


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




7

e. Instruct the base station to send the Service Connect Message with FPC_INCL set to 8

‘0’. 9

f. Instruct the base station to download the SCH configuration and assign a Forward 10

Supplemental Channel using the Extended Supplemental Channel Assignment 11

Message and set the power control related information as follows: 12

13




FPC_SCH_FER = ‘01010’ (5%)

14

g. Monitor the forward link FER on both F-DCCH and F-SCH (during SCH assignment) at 15





3GPP2 C.S0044-D v1.0

4-12




j. Verify that the forward link FER on DCCH and SCH (during SCH assignment) remains 4

at approximately the target value. 5


l. Repeat steps a through k above except that FOR_RC is set to RC4 and REV_RC is set 7

to RC3 in step d. 8

m. Repeat steps a through k above except that the FOR_RC is set to RC5 and REV_RC is 9

set to RC4 in step d. 10


Active; F-FCH and F-SCH 12





or

c

I

EPilot

dB

-7


Ior/Ioc dB 10


Option). 17




FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




3GPP2 C.S0044-D v1.0

4-13


‘0’. 2



Message with power control related parameters set as follows: 5

6




FPC_SCH_FER = ‘01010’ (5%)

g. Monitor the forward link FER on both FCH and SCH (during the SCH assignment) at 7








j. Verify that the forward link FER on FCH and SCH (during SCH assignment) remain at 15

approximately the target values. 16


l. Repeat steps a through k above except for step d to set FOR_RC to RC4 and REV_RC 18

to RC3. 19

m. Repeat steps a through k above except for step d to set FOR_RC to RC5 and REV_RC 20

to RC4. 21

4.2.1.4.6 FPC_MODE ‘010’; F-DCCH and F-SCH 22



3GPP2 C.S0044-D v1.0

4-14



or

c

I

EPilot

dB

-7


Ior/Ioc dB 10

2


Option). 4


parameters set as follows. 6

7


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




8


as follows: 10

11




12

f. Instruct the base station to send SCH configuration and assign a Forward Supplemental 13

Channel by using the Extended Supplemental Channel Assignment Message with 14

power control related parameters set as follows: 15

16

3GPP2 C.S0044-D v1.0

4-15




FPC_SCH_FER = ‘01010’ (5%)

1

g. Monitor forward link FER on both F-DCCH and F-SCH (during SCH burst assignment) 2

at the mobile station. 3







j. Verify that the forward link FER on the DCCH and SCH (during SCH assignment) 10

remain at approximately the target values. 11


l. Repeat steps a through k above except for step d to set FOR_RC to RC4 and REV_RC 13

to 3. 14

m. Repeat steps a through k above except for step d to set FOR_RC to RC5 and REV_RC 15

to 4. 16

4.2.1.4.7 FPC_MODE ‘000’ or ‘011’; F-FCH only, RC 8 17


b. Set power levels as stated in Table 1.2.1 7. 19


Option). 21



3GPP2 C.S0044-D v1.0

4-16


FOR_RC = '01011' (RC 11) REV_RC = '01000' (RC 8)





‘0’ and to send a Radio Configuration Parameters Mesasge with 2

REV_FCH_BLANKING_DUTYCYCLE set to ‘000’. Ensure that the RPC_MODE is set 3

to the default value of ‘00’. 4


g. Verify that the forward link FER on the FCH remains at approximately the target value. 6

h. End the call at the mobile station. 7

i. Repeat the steps a-h with the exception that RPC_MODE is set to ‘01’ in the Radio 8

Configuration Parameters Message and FPC_INCL set to ‘1’ and FPC_MODE set to 9

‘011’ in the Service Connect Message in step e. 10

j. Repeat the steps a-h with the exception that REV_FCH_BLANKING_DUTYCYCLE is 11

set to the default value (or not included), RPC_MODE is set to ’00’ (or not included in 12

the Radio Configuration Parameters Message and FPC_INCL set to ‘1’ and 13

FPC_MODE set to ‘011’ in the Service Connect Message in step e. 14

k. Repeat the steps a-h with the exception that REV_FCH_BLANKING_DUTYCYCLE is 15

set to the default value (or not included), RPC_MODE is set to ’01’ in the Radio 16

Configuration Parameters Message and FPC_INCL set to ‘1’ and FPC_MODE set to 17

‘011’ in the Service Connect Message in step e. 18

l. Repeat the steps a-h with the exception that REV_FCH_BLANKING_DUTYCYCLE is 19

set to ‘000’, FOR_FCH_BLANKING_DUTYCYCLE is set to ‘010’, RPC_MODE is set to 20

’00’ (or not included) in the Radio Configuration Parameters Message and FPC_MODE 21

set to ‘000’ (or not included) in the Service Connect Message in step e. 22

4.2.1.4.8 FPC_MODE ‘010’; F-FCH and F-SCH, RC 8 23


b. Set power levels as stated in Table 1.2.1 7. 25

c. Set up a mobile station originated call using Service Option 32 (TDSO). 26



3GPP2 C.S0044-D v1.0

4-17


FOR_RC = '01011' (RC 11) REV_RC = '01000' (RC 8)




e. Instruct the base station to send and to send a Radio Configuration Parameters 1

Mesasge with REV_FCH_BLANKING_DUTYCYCLE set to ‘000’ and to send the 2

Service Connect Message with the parameters set as follows: 3










FPC_SCH_FER = ‘01010’ (5%)

g. Monitor the forward link FER on FCH and SCH (during the burst assignment) at the 7

mobile station. 8

h. Verify that the forward link FERs on FCH and SCH (during SCH assignment and when 9

SCH is directly power controlled) remains at approximately the target value. 10

i. End the call at the mobile station. 11

j. Repeat the steps a-h with the exception that FPC_MODE is set to ‘010’ in the Service 12

Connect Message and FPC_MODE_SCH set to ‘010’ in the Extended Supplemental 13

Channel Assignment Message. 14

k. Repeat the steps a-h with the exception that RPC_MODE is set to ’01’ in the Radio 15

Configuration Parameters Message FPC_MODE is set to ‘010’ in the Service Connect 16

Message and FPC_MODE_SCH set to ‘010’ in the Extended Supplemental Channel 17

Assignment Message. 18

l. Repeat the steps a-h with the exception that RPC_MODE is set to ’01’ in the Radio 19

Configuration Parameters Message FPC_MODE is set to ‘011’ in the Service Connect 20



3GPP2 C.S0044-D v1.0

4-18

m. Repeat the steps a-h with the exception that REV_FCH_BLANKING_DUTYCYCLE set 1

to its default value or not included and RPC_MODE is set to ’01’ in the Radio 2

Configuration Parameters Message, FPC_MODE is set to ‘011’ in the Service Connect 3



n. Repeat the steps a-h with the exception that REV_FCH_BLANKING_DUTYCYCLE set 6

to its default value or not included and RPC_MODE is set to ’00’ or not included in the 7

Radio Configuration Parameters Message, FPC_MODE is set to ‘011’ in the Service 8

Connect Message and FPC_MODE_SCH set to ‘011’ in the Extended Supplemental 9

Channel Assignment Message. 10

o. Repeat the steps a-h with the exception that REV_FCH_BLANKING_DUTYCYCLE is 11

set to ‘000’, FOR_FCH_BLANKING_DUTYCYCLE is set to ‘010’, RPC_MODE is set to 12

’01’ in the Radio Configuration Parameters Message and FPC_MODE_SCH set to ‘010’ 13

in the Extended Supplemental Channel Assignment Message. 14

4.2.1.5 Minimum Standard 15

4.2.1.5.1 FPC_MODE ‘000’; F-FCH Only 16

The mobile station shall comply with steps i, k, and l. 17

4.2.1.5.2 FPC_MODE ‘000’; F-DCCH only 18

The mobile station shall comply with steps i, k, and l. 19

4.2.1.5.3 FPC_MODE ‘001’; F-FCH and F-SCH 20

The mobile station shall comply with steps j, l, and m. 21


Active; F-DCCH and F-SCH 23



Active; F-FCH and F-SCH 26


4.2.1.5.6 FPC_MODE ‘010’; F-DCCH and F-SCH 28


4.2.1.5.7 FPC_MODE ‘000’ or ‘011’; F-FCH Only, RC 8 30

The mobile station shall comply with step g. 31

4.2.1.5.8 FPC_MODE ‘010’; F-FCH and F-SCH, RC 8 32


34

3GPP2 C.S0044-D v1.0

4-19

4.2.2 Outer Loop Report 1


This test verifies that the mobile station shall send the Outer Loop Report Message if the Outer 3 Loop Report Request Order is received. Note, FPC_MODE may be changed using the Radio 4 Configuration Parameters Message in the tests for RC 8. 5


(See[1]) 7


(See[4]) 9


3.6.6.2.212 Processing of Extended Supplemental Channel Assignment Message 11















2.7.2.3.2.22 Outer Loop Report Message 26

3.7.3.3.2.25 Power Control Message 27

28



None 31

3GPP2 C.S0044-D v1.0

4-20






or

c

I

EPilot

dB -7


Ior/Ioc dB 10

5


Option). 7



10


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




11


‘0’. 13



Message with power control related parameters set as follows: 16

17

3GPP2 C.S0044-D v1.0

4-21




FPC_SCH_FER = ‘01010’ (5%)

1

g. Monitor the forward link FER on both FCH and SCH (during the SCH assignment) at 2








j. During the F-SCH assignment, instruct the base station to send Outer Loop Report 10

Request Order. 11

k. Verify the mobile station sends the Outer Loop Report Message and this message 12

contains FPC_FCH_CURR_SETPT and FPC_SCH_CURR_SETPT. The FPC current 13

setpoint reported by the mobile station shall be in the range of the minimum setpoint 14

and the maximum setpoint 15

l. End the call at the mobile station. 16

m. Repeat steps a through l above except for the following steps: 17

n. Instruct the base station to send the Extended Channel Assignment Message with the 18


20


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




21

3GPP2 C.S0044-D v1.0

4-22

o. Monitor the forward link FER on both DCCH and SCH (during the SCH assignment at 1


p. Verify the mobile station sends the Outer Loop Report Message and this message 3

contains FPC_DCCH_CURR_SETPT and FPC_SCH_CURR_SETPT. The FPC current 4

setpoint reported by the mobile station shall be in the range of the minimum setpoint 5

and the maximum setpoint 6

q. Repeat steps a through l with FOR_RC = ‘01011’ (RC 11) and REV_RC = ‘01000’ (RC 7

8) and the following scenarios: 8

1. FPC_MODE is set to ‘010’ in the Service Connect Message and 9

FPC_MODE_SCH set to ‘010’ in the Extended Supplemental Channel 10


2. RPC_MODE is set to ’01’ in the Radio Configuration Parameters Message 12

FPC_MODE is set to ‘010’ in the Service Connect Message and 13







4. REV_FCH_BLANKING_DUTYCYCLE set to its default value or not included and 20

RPC_MODE is set to ’01’ in the Radio Configuration Parameters Message, 21





RPC_MODE is set to ’00’ or not included in the Radio Configuration Parameters 26

Message, FPC_MODE is set to ‘011’ in the Service Connect Message and 27




The mobile station shall comply with steps k, m, and p. 31

4.2.3 Fast Forward Power Control (FFPC) in Soft Handoff 32


The mobile station accomplishes fast forward power control by transmitting the Reverse Power 34 Control Subchannel to the base station on the Reverse Pilot Channel. The mobile station 35 determines the information to send to the base station through inner and outer closed loop 36 estimations. In outer loop estimation, the mobile station adjusts the Eb/Nt setpoints to the Eb/Nt 37 value necessary to achieve the target FER on the Forward Traffic Channel. In inner loop 38 estimation, the mobile station compares the received Eb/Nt to the setpoint and determines the 39 value of the power control bit to be sent to the base station. This test verifies that the mobile 40 station can perform FFPC while in soft handoff. This test also verifies that the mobile station can 41

3GPP2 C.S0044-D v1.0

4-23

process the various parameters in the Extended Channel Assignment Message, the Extended 1 Supplemental Channel Assignment Message, the Universal Handoff Direction Message, and the 2 Service Connect Message. 3


(See[1]) 5


(See[4]) 7
















23

Applicability: Forward Link: RC 1 through RC 5, RC 11; Reverse Link: RC 1 through RC 4, RC 11 24


None 26


4.2.3.4.1 F-FCH in SHO and F-SCH not in SHO; FPC_MODE = 001; FPC_MODE = 001, 28

FPC_MODE = 010 for RC 8 29

a. Setup the test as shown in Annex A Figure A-7. 30

b. Set power levels as stated in Table 4.2.3-1. 31

3GPP2 C.S0044-D v1.0

4-24


Parameter Unit Base station 1 Base station 2


Ioc dBm/1.23 MHz -75 -75

Ior/Ioc dB 10 10


2


Option) on base station 1. 4



7


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




8


as follows: 10

11




12



Message with the power control related parameters set as follows: 15

16

3GPP2 C.S0044-D v1.0

4-25




FPC_SCH_FER = ‘01010’ (5%)

1

g. Raise the level of base station 2 in steps of 1 dB with a dwell time of 5 seconds after 2


Message. 4

h. Instruct the base station to send the Universal Handoff Direction Message during F-5

SCH assignment with the parameters set as follows: 6

7

CH_IND = ‘101’ (FCH and Continuous Reverse Pilot)

NUM_PILOTS = ‘010’

For PILOT_PN = {base station 1} PILOT_INCL = ‘1’


8

i. Verify there are no forward supplemental channels transmitting on base station 2. 9

j. Set the test parameters as specified in Table 4.2.3-2without dropping the call. 10





Ioc dBm/1.23 MHz -75 -75


12

k. Monitor the forward link FER on both F-FCH and F-SCH (during F-SCH assignment) at 13


l. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 15 dBm/1.23 MHz at 15



3GPP2 C.S0044-D v1.0

4-26

m. Monitor traffic channel Ec/Ior and ensure power changes corresponding to noise power 1



n. Verify that the forward link FER on FCH and SCH (during SCH assignment) remain at 4

approximately in the target value. 5

o. End the call at the mobile station. 6

p. Repeat steps a through n with the following changes: 7

1. In step d use FOR_RC = ‘01011’ (RC 11) and REV_RC = ‘01000’ in the ECAM 8

and instruct the base station to send and to send a Radio Configuration 9

Parameters Mesasge with REV_FCH_BLANKING_DUTYCYCLE set to ‘000’ and 10

ensure that RPC_MODE is set to ‘00’. 11

2. In step e use FPC_INCL to ‘0’. 12

3. In step f to use FPC_MODE_SCH to ‘000’. 13

4. In step h the UHDM is sent in a General Extension Message along with the 14

Radio Configuration Parameters Record. 15

q. Repeat step p with the following changes: 16

1. FPC_MODE is set to ‘010’ in the Service Connect Message and 17












RPC_MODE is set to ’01’ in the Radio Configuration Parameters Message, 29





RPC_MODE is set to ’00’ or not included in the Radio Configuration Parameters 34

Message, FPC_MODE is set to ‘011’ in the Service Connect Message and 35



4.2.3.4.2 F-FCH in SHO and F-SCH not in SHO; FPC_MODE = ‘010’ 38


3GPP2 C.S0044-D v1.0

4-27



Option) with 100% frame activity on base station 1. 3



6


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




7


as follows: 9

10




11




15




FPC_SCH_FER = ‘01010’ (5%)

16

3GPP2 C.S0044-D v1.0

4-28



Message. 3


SCH assignment with parameters set as follows: 5

6





7

i. Verify there are no forward supplemental channels running on base station 2. 8


k. Monitor the forward link FER on both F-FCH and F-SCH (during F-SCH assignment) at 10








n. Verify that the forward link FER on FCH and SCH (during SCH assignment) remain at 18



4.2.3.4.3 F-DCCH in SHO and F-SCH not in SHO; FPC_MODE = ‘001’ 21







28

3GPP2 C.S0044-D v1.0

4-29


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




1


as follows: 3

4




5




9




FPC_SCH_FER = ‘01010’ (5%)

10



Message. 13



16

3GPP2 C.S0044-D v1.0

4-30





1



k. Monitor the forward link FER on both F-DCCH and F-SCH (during F-SCH assignment) 4








n. Verify that the forward link FER on DCCH and SCH (during SCH assignment) remain at 12










22

ASSIGN_MODE = ‘100’ GRANTED_MODE = 10

FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




3GPP2 C.S0044-D v1.0

4-31

1


as follows: 3

4




5




9




FPC_SCH_FER = ‘01010’ (5%)

10



Message. 13



16





17


j. Set the test parameters as specified in Table 4.2.3-2 without dropping the call. 19

3GPP2 C.S0044-D v1.0

4-32

k. Monitor the forward link FER on both F-DCCH and F-SCH (during F-SCH assignment) 1








n. Verify that the forward link FER on DCCH and SCH (during SCH assignment) remain at 9




4.2.3.5.1 F-FCH in SHO and F-SCH not in SHO; FPC_MODE = 001 13

The mobile station shall comply with steps i and n. 14

4.2.3.5.2 F-FCH in SHO and F-SCH not in SHO; FPC_MODE = ‘010’ 15






21

For all tests, the call shall not drop and the FER shall remain in the target value. 22

4.2.4 Change FPC_MODE During a Call 23


The mobile station accomplishes fast forward power control by transmitting the power control 25 subchannel to the base station on the R-PICH. The mobile station determines the information to 26 send to the base station through inner and outer closed loop estimations. In outer loop estimation, 27 the mobile station adjusts the Eb/Nt setpoints to the Eb/Nt value necessary to achieve the target 28 FER on the Forward Traffic Channel. 29

In inner loop estimation, the mobile station compares the received Eb/Nt to the setpoint and 30 determines the value of the power control bit to be sent to the base station. This test verifies that 31 the mobile station can process a change in FPC_MODE delivered by the Power Control 32 Message. 33


(see [1]) 35


3GPP2 C.S0044-D v1.0

4-33

(see [4]) 1

2.6.4.1.1.3 Processing the Power Control Message 2














Applicability: RC 3 and greater 16


None 18



b. Set power levels as stated in Table 4.2.1-2 21


Option) with 100% frame activity. 23



3GPP2 C.S0044-D v1.0

4-34


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




1


‘0’. 3

f. Monitor forward link FER at the mobile station. 4


the AWGN source. 6

h. Monitor traffic channel Ec/Ior and ensure power increases corresponding to noise 7

power from the AWGN source. 8

i. Instruct the base station send the Power Control Message with the parameters set as 9

follows: 10

11

FPC_INCL = ‘1’ FPC_MODE = ‘010’

FPC_PRI_CHAN = ‘0’ FPC_OLPC_FCH_INCL = ‘1’

FPC_FCH_FER = ‘00100’ (2%) PWR_CNTL_STEP = ‘000’ (1dB)‘

FPC_FCH_MIN_SETPT = ‘00010000’ (2 dB)


FPC_OLPC_DCCH_INCL = ‘0’

FPC_DCCH_MIN_SEPT = N/A FPC_DCCH_MAX_SEPT = N/A

FPC_OLPC_SCH_M_INCL = ‘1’ FPC_SCH_M_FER = ‘00010’ (1%)

FPC_MIN_SCH_M_SETPT = ‘00010000’ (2 dB)

FPC_MAX_SCH_M_SETPT = ‘10000000’ (16 dB)

NUM_SUP = 1

12

j. Monitor forward link FER at the mobile station. 13

3GPP2 C.S0044-D v1.0

4-35

k. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 5 dBm/1.23 MHz at 1



l. Monitor traffic channel Ec/Ior and ensure power changes corresponding to noise power 4



m. Verify that the forward link FER on FCH remains at approximately the target value. 7

n. End the call at the mobile station. 8


The mobile station shall comply with step m. 10

11

4.2.5 R-PICH in Gated Transmission Mode 12

4.2.5.1 Gating with the Reverse Dedicated Control Channel 13

4.2.5.1.1 Definition 14

The mobile station accomplishes fast forward power control by transmitting the power control 15 subchannel to the base station on the R-PICH. The power control subchannel can either be gated 16 (either at a rate of ½ or ¼) or not gated (a bit is transmitted on every PCG). Gating occurs only 17 when the Forward Dedicated Control Channel and the Reverse Dedicated Control Channel are 18 assigned and when there are no transmissions on the Reverse Dedicated Control Channel. This 19 test verifies that the mobile station can operate in the various gating transmission modes 20 specified in the Service Connect Message. 21

Figure 4.2.5.1.1-1 Reverse Pilot Gating with no Transmission 22 on the Reverse Dedicated Control Channel 23

3GPP2 C.S0044-D v1.0

4-36

1

Figure 4.2.5.1.1-2 Reverse Pilot Gating during 2 Reverse Dedicated Control Channel Transmission 3

4.2.5.1.2 Traceability: 4

(see [1]) 5


2.1.3.2 Reverse Pilot Channel 7

(see [4]) 8

3GPP2 C.S0044-D v1.0

4-37















15


4.2.5.1.3 Call Flow Example(s) 17

None 18

4.2.5.1.4 Method of Measurement 19

a. Connect base station and mobile station as shown in Annex A Figure A-6 20


c. Setup a mobile station originated data call using Service Option 33. 22

d. Instruct the base station to send the Extended Channel Assignment Message has the 23



FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




3GPP2 C.S0044-D v1.0

4-38

1

e. Instruct the base station to send the Service Connect Message has the parameters set 2

as follows: 3

4


FPC_PRI_CHAN = ‘1’ FPC_OLPC_DCCH_INCL = ‘0’


GATING_RATE_INCL = ‘1’ PILOT_GATE_RATE = ‘01’ (gating at ½)

5

f. Instruct the base station to send the Extended Release Message with CH_IND set to 6

‘100’. 7

g. Do not have any transmissions on the Reverse Dedicated Control Channel. 8

h. Instruct the base station to send a sufficient number of In-Traffic System Parameters 9

Messages with the same system configurations and without requiring the 10

acknowledgment on the reverse link DCCH so that the mobile station can measure 11

forward FER. 12

i. Monitor forward link FER at the mobile station. 13

j. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 5 dBm/1.23 MHz at 14



k. Monitor traffic channel Ec/Ior and ensure power changes corresponding to noise power 17



l. Verify that the reverse Pilot Channel is gated at the specified rate and the forward link 20

FER on DCCH remains at approximately the target value 21

m. Instruct the mobile station to send the Data Burst Message on the Reverse Dedicated 22

Control Channel. 23

n. Monitor the forward link FER at mobile station. 24

o. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 5 dBm/1.23 MHz at 25



p. Monitor traffic channel Ec/Ior and ensure power changes corresponding to noise power 28



3GPP2 C.S0044-D v1.0

4-39

q. Verify that the reverse Pilot Channel is gated at the target rate if no transmissions are 1

on the Reverse Dedicated Control Channel and the reverse Pilot Channel is not gated if 2

there are transmissions on the Reverse Dedicated Control Channel. 3

r. Verify that the forward link FER on DCCH remains at approximately the target value. 4

s. End the call at the mobile station. Repeat steps a through r above except for step e to 5

set PILOT_GATE_RATE to ‘10’ (gating at ¼). 6

4.2.5.1.5 Minimum Standard 7

Gating with the Reverse Dedicated Control Channel 8

The mobile station shall comply with steps l, q, and r. 9

4.2.5.2 Gating with the Reverse Fundamental Channel 10

4.2.5.2.1 Definition 11

The mobile station accomplishes fast forward power control by transmitting the power control 12 subchannel to the base station on the R-PICH. The power control subchannel can either be gated 13 or not gated. The R-FCH may be gated when no other Reverse Traffic Channel is assigned and 14 the data rate is 1500 bps for RC 3 and RC5 or 1800 bps for RC4. When the R-FCH is operated in 15 the gated mode and is at a data rate of 1500 bps for RC 3 and RC 5 or 1800bps for RC 4, the R-16 PICH shall have a transmission duty cycle of 50%. The R-PICH shall be transmitted in power 17 control groups 2, 3, 6, 7, 10, 11, 14, and 15, and shall not be transmitted in power control groups 18 0, 1, 4, 5, 8, 9, 12, and 13. 19

20

Figure 4.2.5.2.1-1 Gating with the R-FCH 21

4.2.5.2.2 Traceability: 22

(see [1]) 23


3GPP2 C.S0044-D v1.0

4-40

2.1.3.2 Reverse Pilot Channel 1

2.1.3.7.8 Reverse Fundamental Channel 2

(see [4]) 3





Extended Supplemental Channel Assignment Message 8













Applicability: RC 3 and greater 21

4.2.5.2.3 Call Flow Example(s) 22

None 23

4.2.5.2.4 Method of Measurement 24




Option) with rate 1500 bps only and set the REV_FCH_GATING_REQ field to ‘1’ in the 28


d. Instruct the base station to send the Extended Channel Assignment Message has the 30

parameters set as follows and set the REV_PWR_CNTL_DELAY field according to the 31

base station’s implementation. 32

33

3GPP2 C.S0044-D v1.0

4-41


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




REV_FCH_GATING_MODE = ‘1’

REV_PWR_CNTL_DELAY_INCL = ‘1’

1


‘0’. 3

f. Ensure the Reverse Fundamental Channel is transmitted at 1/8 rate. 4

g. Monitor forward link FER at the mobile station. 5







j. Verify the Reverse Fundamental Channel is in gated mode and the Reverse Pilot 12

Channel has a transmission duty cycle of 50%. 13

k. Verify that the forward link FER on FCH is remaining in the target value. 14

l. End the call at the mobile station. 15

m. Repeat steps a through l except for the step d to set FOR_RC to 4 and REV_RC to 3. 16

4.2.5.2.5 Minimum Standard 17

The mobile station shall comply with steps j, k and m. 18

4.2.6 Forward Power Control With EIB and QIB While Transmitting Frames on the Forward 19

Fundamental Channel (FPC_MODE = ‘011’ or ‘100’) 20


This test shall be performed on the Forward Fundamental Channel with FPC_MODE equal to 22 ‘011’ and ‘100’. In this test, QIB is same as EIB. The mobile station shall set the EIB or QIB to 23 ‘0’on the Reverse Power Control Subchannel in the second transmitted frame following the 24 detection of a good 20ms frame or the detection of at least one good 5ms frame without the 25 detection of any bad 5 ms frames within 20ms (if the mobile station support 5ms frame size) on 26

3GPP2 C.S0044-D v1.0

4-42

the Forward Fundamental Channel. Otherwise the mobile station shall set the EIBor QIB to ‘1’ in 1 the second transmitted 20 ms frame. 2

4.2.6.2 Traceability 3

(see [1]) 4

2.1.3.1.10.1 Reverse Power Control Subchannel Structure 5

2.2.2.2 Erasure Indicator Bit and Quality Indicator Bit 6

(see [4]) 7




None 11



b. Set power ratios and levels as specified in Table 4.2.6-1. 14

Table 4.2.6-1 Test Parameters for EIB/QIB test 15

Parameter Unit Channel 1

Îor/Ioc dB 0

Pilot Ec/Ior dB -7

Traffic Ec/Ior dB -7


16




e. Instruct the base station to send an Extended Channel Assignment Message with the 20


22

ASSIGN_MODE = ‘000’ or ‘100’ GRANTED_MODE = ‘10’

FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)

CH_IND = ‘01’

3GPP2 C.S0044-D v1.0

4-43

1

f. Instruct the base station to send a Service Connect Message with the parameters set 2

as follows: 3

4




5

g. From the base station, send a sequence of at least 10 good frames and at least 10 bad 6

frames to the mobile station on the Dedicated Control Channel. 7

h. Verify that the mobile station Reverse Power Control Subchannel bit pattern follows the 8

frame pattern sent from the base station to the mobile station (i.e. a ‘0’ for a good frame 9

and a ‘1’ for a bad frame). 10

i. End the call. 11

j. Repeat steps a through j except for the step e to set REV_RC to 3 and FOR_RC to 4. 12

k. Repeat steps a through j except for the step e to set REV_RC to 4 and FOR_RC to 5. 13


The mobile station shall comply with steps h. 15

4.2.7 Forward Power Control With EIB While Transmitting Frames on the Forward 16

Dedicated Control Channel (FPC_MODE = ‘011’) 17


This test shall be performed on the Forward Dedicated Control Channel with FPC_MODE equal 19 to ‘011’. The mobile station shall set the EIB to ‘0’ on the Reverse Power Control Subchannel in 20 the second transmitted 20ms frame following the detection of a good 20ms frame or the detection 21 of at least one good 5ms frame without the detection of any bad 5 ms frames within 20ms on the 22 Forward Dedicated Control Channel. Otherwise, the mobile station shall set the EIB to ‘1’ in the 23 second transmitted 20 ms frame. 24


(see [1]) 26



(see [4]) 29



3GPP2 C.S0044-D v1.0

4-44


None 2






d. Setup a mobile station originated data call by using SO33. 8



11

ASSIGN_MODE = ‘000’ or ‘100’ GRANTED_MODE = ‘10’

FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)

CH_IND = ‘10’

12


as follows: 14

15



FPC_MODE = ‘011’ DCCH_FRAME_SIZE = ‘11’

16

g. From the base station, send a sequence of at least 10 good frames and at least 10 bad 17

frames to the mobile station on the Forward Fundamental Channel. 18

h. Verify that the mobile station Reverse Power Control Subchannel bit pattern follows the 19

frame pattern sent from the base station to the mobile station (i.e. a ‘0’ for a good frame 20

and a ‘1’ for a bad frame). 21

i. End the call. 22

j. Repeat steps d through i except for step e to set REV_RC to 3 and FOR_RC to 4. 23

k. Repeat steps d through i except for step e to set REV_RC to 4 and FOR_RC to 5. 24



3GPP2 C.S0044-D v1.0

4-45

4.2.8 Forward Power Control With QIB on the Forward Dedicated Control Channel 1

(FPC_MODE = ‘100’) 2


This test shall be performed on the Forward Dedicated Control Channel with FPC_MODE equal 4 to ‘100’. The mobile station shall set the QIB to ‘0’ on the Reverse Power Control Subchannel in 5 the second transmitted frame following the detection of a 20ms period with sufficient signal quality 6 on the Forward Dedicated Control Channel. The mobile station shall set the QIB to ‘1’ on the 7 Reverse Power Control Subchannel in the second transmitted frame following the detection of a 8 20ms period with insufficient signal quality on the Forward Dedicated Control Channel. When 9 transmitting active frames on the Forward Dedicated Control Channel only, the QIB will be the 10 same as the EIB When the frame is inactive (i.e. only the power control bits are transmitted in a 11 frame), the Quality Indicator Bit indicates the channel quality. 12


(see [1]) 14



(see [4]) 17





None 22






d. Setup a mobile station originated data call by using Service Option 33. 28



31


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)

CH_IND = ‘10’

32

3GPP2 C.S0044-D v1.0

4-46


as follows: 2

3



FPC_MODE = ‘100’ FPC_OLPC_DCCH_INCL = ‘0’

g. Instruct the base station to send a sequence of at least 10 good frames and at least 10 4

bad frames to the mobile station on the Forward Dedicated Control Channel. 5

h. Verify the mobile station QIB bit pattern follows the frame pattern sent from the base 6

station to the mobile station (i.e. a ‘0’ for a good frame and a ‘1’ for a bad frame) 7

i. End the call. 8

j. Repeat steps d through j except for step e to set REV_RC to 3 and FOR_RC to 4. 9

k. Repeat steps d through j except for step e to set REV_RC to 4 and FOR_RC to 5. 10


The mobile station shall comply with steps h. 12

4.2.9 Forward Power Control With QIB derived from the Forward Fundamental Channel or 13

Dedicated Control Channel and EIB derived from Supplemental Channel (FPC_MODE = 14

‘101’) 15


This test shall be performed with FPC_MODE equal to ‘101’. The mobile station shall transmit 17 QIB derived from the Forward Fundamental Channel or Forward Dedicated Control Channel on 18 the Primary Reverse Power Control Subchannel and shall transmit EIB derived from Forward 19 Supplemental Channel on the Secondary Reverse Power Control Subchannel. The transmission 20 of the QIB and EIB shall start at the second 20 ms frame of the Reverse Traffic Channel following 21 the corresponding Forward Traffic Channel frame in which QIB or EIB is determined. 22


(see [1]) 24



(see [4]) 27




3GPP2 C.S0044-D v1.0

4-47


None 2









11


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)

CH_IND = ‘01’

12


as follows: 14

15



FPC_MODE = ‘101’ FCH_FRAME_SIZE = ‘1’

g. Instruct the base station to download SCH configuration and assign a Forward 16

Supplemental Channel with an infinite duration by using the Extended Supplemental 17

Channel Assignment Message with the power control related parameters set as follows: 18

19

FPC_INCL = ‘1’ FPC_SEC_CHAN = ‘0’

FPC_MODE_SCH = ‘101’ NUM_SUP = ‘00’

h. Instruct the base station to send a sequence of at least 10 good frames at least 10 bad 20

frames to the mobile station on the Forward Fundamental Channel. Instruct the base 21

station to send a sequence of alternating at least 10 good frames and at least 10 bad 22

frames on the Forward Supplemental Channel. 23

i. Verify the mobile station QIB bit pattern on Primary Reverse Power Control Channel 24

follows the frame pattern sent from the base station to the mobile station on Forward 25

3GPP2 C.S0044-D v1.0

4-48

Fundamental Channel (i.e. a ‘0’ for a good frame and a ‘1’ for a bad frame). Verify the 1

mobile station EIB bit pattern on Secondary Reverse Power Control Subchannel follows 2

the frame pattern sent from the base station to the mobile station on Forward 3

Supplemental Channel (i.e. a ‘0’ for a good frame and a ‘1’ for a bad frame). 4

j. End the call. 5

k. Repeat steps d through j except for step e to set REV_RC to 3 and FOR_RC to 4. 6

l. Repeat steps d through j except for step e to set REV_RC to 4 and FOR_RC to 5. 7

m. Repeat steps d through l except for the following steps: 8

1. Step e: Set CH_IND = ‘10’; 9

2. Step f: Set FPC_PRI_CHAN = ‘1’ and DCCH_FRAME_SIZE = ‘11’; 10

3. Step h: Instruct the base station to send a sequence of at least 10 good frames 11

and at least 10 bad frames on the Forward Dedicated Control Channel. Instruct 12

the base station to send a sequence of at least 10 good frames and at least 10 13

bad frames to the mobile station on the Forward Supplemental Channel. 14

4. Step i: Verify the mobile station QIB bit pattern on Primary Reverse Power 15

Control Channel follows the frame pattern sent from the base station to the 16

mobile station on Forward Dedicated Control Channel (i.e. a ‘0’ for a good frame 17

and a ‘1’ for a bad frame). Verify the mobile station EIB bit pattern on Secondary 18

Reverse Power Control Subchannel follows the frame pattern sent from the base 19

station to the mobile station on Forward Supplemental Channel (i.e. a ‘0’ for a 20

good frame and a ‘1’ for a bad frame). 21


The mobile station shall comply with step i. 23

4.2.10 Forward Power Control With 400 bps data rate on the Forward Fundamental Channel 24

or Forward Dedicated Control Channel and EIB derived from Supplemental Channel 25

(FPC_MODE = ‘110’) 26


This test shall be performed with FPC_MODE equal to ‘110’. The mobile station shall transmit the 28 Primary Reverse Power Control Subchannel at a 400 bps data rate based on the Forward 29 Fundamental Channel or Forward Dedicated Control Channel, and shall transmit EIB derived 30 from Forward Supplemental Channel on the Secondary Reverse Power Control Subchannel. 31 The transmission of the power control bits on the Primary Reverse Power Control Subchannel is 32 based on inner and outer closed loop estimations. The transmission of the EIB on the Secondary 33 Reverse Power Control Subchannel shall start at the second frame (20ms frame) of the Reverse 34 Traffic Channel following the end of the corresponding Forward Supplemental Channel frame 35 from which the EIB is derived. 36


(see [1]) 38


3GPP2 C.S0044-D v1.0

4-49


(see [4]) 2





None 7









16


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




17

f. Instruct the base station to send a Service Connect Message with the parameters set 18 as follows: 19

20



FPC_MODE = ‘110’ GATING_RATE_INCL = ‘0’

3GPP2 C.S0044-D v1.0

4-50

g. Instruct the base station to download SCH configuration and assign a Forward 1



4



h. Monitor the forward link FER on the Forward Fundamental Channel at the mobile 5

station. 6

i. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 15 dBm/1.23 MHz at 7



j. Monitor traffic channel Ec/Ior and ensure the power changes corresponding to noise 10



k. Verify that the forward link FER on the FCH remains at approximately the target value. 13

l. Instruct the base station to send a sequence of at least 10 good frames and at least 10 14


m. Verify the mobile station EIB bit pattern on Secondary Reverse Power Control 16

Subchannel follows the frame pattern sent from the base station to the mobile station 17

on Forward Supplemental Channel (i.e. a ‘0’ for a good frame and a ‘1’ for a bad frame) 18

n. End the call. 19

o. Repeat steps d through n except for step e to set REV_RC to 3 and FOR_RC to 4. 20

p. Repeat steps d through n except for step e to set REV_RC to 4 and FOR_RC to 5. 21

q. Setup a mobile station originated data call by using Service Option 33. 22

r. Instruct the base station to send an Extended Channel Assignment Message with the 23


25


FOR_RC = ‘00011’ (RC 3) REV_RC = ‘00011’ (RC 3)




3GPP2 C.S0044-D v1.0

4-51

1

s. Instruct the base station to send a Service Connect Message with the parameters set 2

as follows: 3

4



FPC_MODE = ‘110’ GATING_RATE_INCL = ‘0’

t. Instruct the base station to download SCH configuration and assign a Forward 5



8



u. Monitor the forward link FER on the Forward Dedicated Control Channel at the mobile 9

station. 10

v. Increase Ioc in 1 dBm/1.23 MHz steps every second for a total of 15 dBm/1.23 MHz at 11



w. Monitor traffic channel Ec/Ior and ensure the power changes corresponding to noise 14



x. Verify that the forward link FER on the DCCH remains at approximately the target value 17

y. Instruct the base station to send a sequence of at least 10 good frames and at least 10 18


z. Verify the mobile station EIB bit pattern on Secondary Reverse Power Control 20

Subchannel follows the frame pattern sent from the base station to the mobile station 21

on Forward Supplemental Channel (i.e. a ‘0’ for a good frame and a ‘1’ for a bad frame) 22

aa. End the call. 23

bb. Repeat steps q through aa except for step r to set REV_RC to 3 and FOR_RC to 4. 24

cc. Repeat steps q through aa except for step r to set REV_RC to 4 and FOR_RC to 5. 25


The mobile station shall comply with steps k, m, x, z. 27

3GPP2 C.S0044-D v1.0

4-52

4.3 Lowest Rate Reverse Fundamental Channel Gating 1

4.3.1 Definition 2

This test verifies the mobile station, instructed by the base station, transmits the reverse 3 fundamental channel, with radio configurations 3 or 4, in a duty cycle of 50% when using data 4 rates of 1500 bps for RC3 and 1800 bps for RC4. 5


(see [1]) 7

2.1.3.7.8 Reverse Fundamental Channel Gating 8

(see [4]) 9







2.7.3 Orders 16

3.6.3.5 Response to Origination Message 1 17





3.7.4 Orders 15 22

3.7.5.5 Signal 16 23


None 25


4.3.4.1 R-FCH Gating disabled at base station 27

a. Connect the mobile station to the base station as shown in Annex A Figure A-1and set 28

forward link parameters as specified in Table 4.3.4-1. 29

30

3GPP2 C.S0044-D v1.0

4-53

Table 4.3.4-1 Forward Link Parameters General Setup 1

Parameter Units Values

Forward Link Power Ior dBm/1.23MHz -75

Pilot Ec/Ior dB -7

2

b. Setup a mobile station originated call. 3

c. Cause the mobile station to send Origination Message with REV_FCH_GATING_REQ 4

= 1. 5

d. Instruct the base station to send an Extended Channel Assignment Message with 6

REV_FCH_GATING_MODE = 0. 7

e. Verify audio in both directions. 8

f. Release the call. 9

g. Repeat steps c through e for all supported radio configurations. 10

4.3.4.2 R-FCH Gating enabled at base station 11

a. Connect the mobile station to the base station as shown in Annex A Figure A-1and set 12

forward link parameters as specified in Table 4.3.4-1. 13


c. Cause the mobile station to send Origination Message with REV_FCH_GATING_REQ 15

= 1. 16

d. Instruct the base station, to send the Extended Channel Assignment Message with 17

REV_FCH_GATING_MODE = 1. 18

e. Verify audio in both directions. 19

f. Instruct the mobile station to transmit data at 1500 bps (for RC3) or 1800 bps (for RC4) 20

on reverse fundamental channel (i.e. by setting the mobile station to Mute). 21

g. Verify transmission is gated at 50% - transmission is turned on and off every 2.5ms, or 22

every 2 Power Control Groups (). 23

h. Release the call. 24

i. Repeat steps c through e for all supported radio configurations. 25

j. Release the call. 26


4.3.5.1 R-FCH Gating disabled at base station 28


3GPP2 C.S0044-D v1.0

4-54

4.3.5.2 R-FCH Gating enabled at base station 1

The mobile station shall comply with steps g and i. 2

4.4 R-FCH Gating during Soft Handoff 3

4.4.1 Definition 4

This test verifies the functionality of R-FCH gating during soft handoffs. 5


(see [1]) 7

2.1.3.7.8 Reverse Fundamental Channel Gating 8

(see [4]) 9







2.7.3 Orders 16

3.6.3.5 Response to Origination Message 10 17

3.6.4 Traffic Channel Processing 11 18

3.7.2.3.2.21 Extended Channel Assignment Message 12 19

3.7.3.3.2.3 Alert With Information Message 13 20

3.7.3.3.2.20 Service Connect Message 14 21

3.7.4 Orders 15 22

3.7.5.5 Signal 16 23


None 25


4.4.4.1 Sectors with Different Values of REV_PWR_CNTL_DELAY 27

28

a. Connect the mobile station to base stations 1 and 2 as shown in Annex A Figure A-2 29

and set forward link parameters as shown inTable 4.4.4-1. Configure a different Pilot 30

PN offset for each base station. 31

3GPP2 C.S0044-D v1.0

4-55

1

Table 4.4.4-1 Forward Link Parameters for R-FCH Test during Soft Handoff 2

Parameter Units Base Station 1 Base Station 2

Forward Link Power Ior

dBm/1.23MHz -75 -75


3

b. Configure base station 1 and base station 2 to be on different power control delay 4

regions: base station 1 = 2 PCGs and base station 2 = 3 PCGs. 5


d. Cause the mobile station to send Origination Message with REV_FCH_GATING_REQ 7

= 1. 8


REV_FCH_GATING_MODE = 1 and REV_PWR_CNTL_DELAY = 2. 10

f. Verify audio in both directions. 11

g. Instruct the mobile station to transmit data at 1500 bps (for RC3) or 1800 bps (for RC4) 12

on reverse fundamental channel (i.e. by setting the mobile station to Mute). 13

h. Verify transmission is gated at 50% - transmission is turned on and off every 2.5ms, or 14


i. Raise the level of base station 2 in steps of 1 dB with a dwell time of 1 sec until base 16

station 1 sends an Universal Handoff Direction Message or General Handoff Direction 17

Message with REV_FCH_GATING_MODE = 0. 18

j. Verify mobile station has both base stations on its active pilot set list. 19

k. Verify mobile station transmission of 1500 bps (for RC3) or 1800 bps (for RC4) frames 20

is not gated at 50% duty cycle. 21

l. Release the call. 22

m. Repeat steps b through l for all support radio configurations. 23

4.4.4.2 Sectors with Same Value of REV_PWR_CNTL_DELAY 24

a. Connect the mobile station to base stations 1 and 2 as shown in Annex A Figure A-2 25

and set forward link parameters as shown inTable 4.4.4-1. Configure a different Pilot 26

PN offset for each base station but with the same frequency. 27

b. Configure base station 1 and base station 2 to be on the same power control delay 28

region = 2 PCGs. 29


3GPP2 C.S0044-D v1.0

4-56

d. Verify the mobile station sends Origination Message with REV_FCH_GATING_REQ = 1

1. 2


REV_FCH_GATING_MODE = 1 and REV_PWR_CNTL_DELAY = 2. 4

f. Verify audio in both directions. 5

g. Instruct the mobile station to transmit data at 1500bps on reverse fundamental channel 6

(i.e. by setting the mobile station to Mute) 7

h. Verify transmission is gated at 50% - transmission is turned on and off every 2.5ms, or 8


i. Raise the level of base station 2 in steps of 1 dB with a dwell time of 1 sec until base 10


Message, REV_FCH_GATING_MODE = 1. 12

j. Verify mobile station has both base stations on its active pilot set list. 13

k. Verify mobile station transmission of 1500 bps (for RC3) or 1800 bps (for RC4) frames 14

is gated at 50% duty cycle. 15

l. Lower the level of base station 1 in steps of 1 dB with a dwell time of 1 sec until base 16


Message, with REV_FCH_GATING_MODE = 1 and REV_PWR_CNTL_DELAY = 2. 18

m. Verify mobile station has only base station 2 on its active pilot set list. 19

n. Verify mobile station transmission of 1500 bps (for RC3) or 1800 bps (for RC4) frames 20

is gated at 50% duty cycle. 21

o. Release the call. 22

p. Repeat steps b through o for all supported radio configurations. 23


4.4.5.1 Sectors with Same Value of REV_PWR_CNTL_DELAY 25

The mobile station shall comply with steps d, h, j, k and m. 26

4.4.5.2 Sectors with Different Values of REV_PWR_CNTL_DELAY 27

The mobile station shall comply with steps d, h, j, k, m, n, and p.. 28

3GPP2 C.S0044-D v1.0

5-1

5 REGISTRATIONS 1

5.1 Power-Up Registration 2

5.1.1 Definition 3

These tests verify proper power-up registration functionality. The mobile station registers when it 4 powers on, switches from using a different frequency block, switches from using a different band 5 class, switches from using an alternative operating mode, or switches from using the analog 6 system. 7


(see [4]) 9

2.6.5.1.1 Power-Up Registration 10

2.6.5.5.1.3 Entering the Mobile Station Idle State 11

2.6.5.5.2.1 Idle Registration Procedures 12


3.6.5 Registration 14


3.7.2.3.2.30 ANSI-41 System Parameters Message 16


None 18


5.1.4.1 Power-up Registration Disabled 20


b. Instruct the base station to set POWER_UP_REG = 0 in the System Parameters 22

Message or ANSI-41 System Parameters Message. 23

c. Power on the mobile station. 24

d. Verify the mobile station does not attempt power-up registration for at least 1 minute 25

after the mobile station enters the Mobile Station Idle State. 26

5.1.4.2 Power-up Registration Enabled 27


b. Instruct the base station to set POWER_UP_REG = 1 in the System Parameters 29

Message or ANSI-41 System Parameters Message 30


d. Verify the mobile station sends a Registration Message with REG_TYPE = ‘0001’ 32

3GPP2 C.S0044-D v1.0

5-2

5.1.4.3 Power-up Registration due to change in Operating Mode 1

a. Connect the base station and mobile station as shown in Figure A-5. (Base station 1 is 2

a CDMA base station and base station 2 is a non-CDMA base station. 3

b. Allow the mobile station to operate in the idle state on base station 2. 4

c. Configure base station 1 to set POWER_UP_REG = 1 in the System Parameters 5

Message or the ANSI-41 System Parameters Message. 6

d. Force the mobile station to acquire base station 1. 7

e. Verify the mobile station sends a Registration Message with REG_TYPE = ‘0001’ on 8

base station 1. 9

5.1.4.4 Power-up Registration entering into different Band Class 10

a. Connect the base station and mobile station as shown in Figure A-5. (Base station 1 11

and base station 2 are CDMA base stations using different band classes) 12

b. Instruct both base station 1 and base station 2 to set POWER_UP_REG = 1 in the 13

System Parameters Message or the ANSI-41 System Parameters Message. 14


d. Verify the mobile station sends a Registration Message with REG_TYPE = ‘0001’ on 16

base station 1. 17

e. Force the mobile station to acquire base station 2. 18

f. Verify the mobile station a Registration Message with REG_TYPE = ‘0001’ on base 19

station 2. 20

g. Force the mobile station to acquire base station 1. 21

h. Verify the mobile station performs power-up registration on base station 1. 22

5.1.4.5 Power-up Registration entering into Different Frequency Blocks 23


and base station 2 are CDMA base stations using the same band class with 25

frequencies assignments in a different serving system.) 26

b. Instruct both base station 1 and base station 2 to set POWER_UP_REG = 1 in the 27

System Parameters Message or the ANSI-41 System Parameters Message while 28

ensuring all other forms of registration are disabled. 29


d. Verify the mobile station sends a Registration Message with REG_TYPE = ‘0001’ on 31

base station 1. 32


f. Verify the mobile station sends a Registration Message with REG_TYPE = ‘0001’ on 34

base station 2. 35

3GPP2 C.S0044-D v1.0

5-3


5.1.5.1 Power-up Registration Disabled 2

The mobile station shall comply with step d. Power-up registration shall not occur. 3

5.1.5.2 Power-up Registration Enabled 4

The mobile station shall comply with step d. The mobile station shall perform the registration 5 process when it is powered on and after the power/initialization timer has expired. 6

5.1.5.3 Power-up Registration entering into different operating mode 7


5.1.5.4 Power-up Registration entering into different Band Class 9

The mobile station shall comply with steps d, f and h. 10

5.1.5.5 Power-up Registration entering into Different Frequency Blocks 11

The mobile station shall comply with steps d and f. 12

5.2 Power - Down Registration 13

5.2.1 Definition 14

These tests verify power-down registration functionality. The mobile station should be able to 15 recognize all base station registration settings. 16

The mobile station registers when it powers off if previously registered in the current serving 17 system. The mobile station should not perform power-down registration if it has not previously 18 registered in the system corresponding to its current SID and NID. 19


(see [4]) 21


2.6.5.1.2 Power-Down Registration 23

2.6.5.5.2.1 Idle Registration Procedures 24




3.7.2.3.2.30 ANSI - 41 System Parameters Message 28


None 30

3GPP2 C.S0044-D v1.0

5-4


5.2.4.1 Power-down Registration Disabled 2


b. Enable power-up registration (set POWER_UP_REG = 1 in the System Parameters 4

Message or ANSI - 41 System Parameter Message) while ensuring all other forms of 5

registration are disabled. 6


d. Verify the mobile station performs a power-up registration. 8

e. Power down the mobile station. 9

f. Verify power-down registration does not occur. 10

5.2.4.2 Power-down Registration of a Currently Registered Mobile Station 11


b. Enable power-up registration (set POWER_UP_REG = 1) and power-down registration 13

(set POWER_DOWN_REG = 1) in the System Parameters Message or ANSI - 41 14

System Parameter Message) while ensuring all other forms of registration are disabled. 15


d. Verify power-up registration occurs. 17

e. Power down the mobile station. 18

f. Verify the mobile station sends a Registration Message with REG_TYPE = ’0011’. 19

5.2.4.3 Power-down Registration of an Unregistered Mobile Station in New 20

System/Network 21


and base station 2 are CDMA base stations using a different SID/NID). 23

b. Instruct base station 1 to set POWER_ UP = 1 and both base station 1 and base station 24

2 to set POWER_DOWN = 1 in the System Parameters Message or ANSI - 41 System 25

Parameter Message, and turn off all other types of registration. 26


d. Verify power-up registration on base station 1. 28


f. Verify power-down registration does not occur on base station 2. 30


5.2.5.1 Power-down Registration Disabled 32

The mobile station shall comply with steps d and f. Power-down registration shall not occur. 33

3GPP2 C.S0044-D v1.0

5-5

5.2.5.2 Power-down Registration of a Currently Registered Mobile Station 1

The mobile station shall comply with steps d and f. The mobile station shall perform power-down 2 registration in a system/network where it is currently registered. 3

5.2.5.3 Power-down Registration of an Unregistered Mobile Station in a New 4

System/Network 5

The mobile station shall comply with steps d and g. Power-down registration shall not occur in a 6 system/network where the mobile station is not currently registered. 7

5.3 Distance-Based Registration 8

5.3.1 Definition 9

These tests verify proper distance-based registration functionality. 10

The mobile station should be able to recognize all base station registration settings. 11

The mobile station registers when the distance between the current base station and the base 12 station in which it last registered exceeds a threshold. 13


(see [4]) 15


2.6.5.1.4 Distance-Based Registration 17






None 23

5.3.4 Method of measurement 24

5.3.4.1 Distance-Based Registration Disabled 25

a. Connect the base station and mobile station as shown in Figure A-5. Use the 26

parameters in Table 5.3.4-1. 27

b. Configure base station 1 and base station 2 to send the System Parameters Message 28

or the ANSI - 41 System Parameters Message with REG_DIST, BASE_LAT and 29

BASE_LONG parameters as indicated in Table 5.3.4-2 (Test Case 1). 30

c. Instruct both base station 1 and base station 2 to set power-up registration (set 31

POWER_UP_REG = 1) in the System Parameters Message or the ANSI - 41 System 32


d. Power on the mobile station on base station 1. 34

3GPP2 C.S0044-D v1.0

5-6

e. Verify power-up registration occurs. 1

f. Force the mobile station to perform an idle handoff to base station 2 by reducing base 2

station 2 forward link attenuation, then increasing base station 1 forward link 3

attenuation. 4

g. Verify the mobile station does not perform distance-based registration. 5

6

Table 5.3.4-1 Forward Link Parameters for Distance-based Registration 7


Ior/Ioc dB 0 -10



Ioc dB/1.23 MHz -75 -75


8

9

Table 5.3.4-2 BTS Distance based LAT/LONG System Parameters Message or the ANSI - 41 10 System Parameters Message Configuration 11

12

Parameters Test Case 1 Test Case 2 Test Case 3

BTS 1 BASE_LAT (sec/4) 0X4 0X4 0X4

BTS 1 BASE_LONG (sec/4) 0X4 0X4 0X4

BTS 2 BASE_LAT (sec/4) 0X400 0X400 0X400

BTS 2 BASE_LONG (sec/4) 0X400 0X400 0X400

REG_DIST 0X0 0X50 0X10

13

5.3.4.2 Distance Threshold Not Exceeded 14





BASE_LONG parameters as indicated in Table 5.3.4 -2 (Test Case 2). 19

3GPP2 C.S0044-D v1.0

5-7




d. Power on the mobile station. 4


f. Force the mobile station to perform an idle handoff to base station 2 by reducing base 6

station 2 forward link attenuation, then increasing base station 1 forward link 7

attenuation. 8

g. Verify the mobile station does not perform distance-based registration. 9

5.3.4.3 Distance Threshold Exceeded 10





BASE_LONG parameters as indicated in Table 5.3.4-2 (Test Case 3). 15






f. Force mobile station to perform idle handoff to base station 2 by reducing base station 2 21

forward link attenuation, then increasing base station 1 forward link attenuation. 22

g. Verify the mobile station sends a Registration Message with REG_TYPE = ’0110’. 23


5.3.5.1 Distance-based Registration Disabled 25

The mobile station shall comply with step g. Distance-based registration shall not occur. 26

5.3.5.2 Distance Threshold Not Exceeded 27

The mobile station shall comply with step g. The mobile station shall not perform distance-based 28 registration when distance-based registration enabled and calculated value of DISTANCE is less 29 than REG_DIST. 30

5.3.5.3 Distance Threshold Exceeded 31

The mobile station shall comply with step g. The mobile station shall perform distance-based 32 registration when distance based registration is enabled and the calculated value of DISTANCE is 33 greater than REG_DIST. 34

3GPP2 C.S0044-D v1.0

5-8

5.4 Timer-Based Registration 1

5.4.1 Definition 2

These tests verify proper timer - based registration functionality. 3

The mobile station registers when a timer expires. 4

Timer-based registration is performed when the counter reaches a maximum value 5 (REG_COUNT_MAX) that is controlled by the base station via the REG_PRD field of the System 6 Parameters Message or ANSI-41 System Parameters Message. 7

The counter is reset when the mobile station powers on. The counter is reset after each 8 successful registration. 9

When longer timer based registration is supported, the counter reaches a maximum value that is 10 controlled by the base station via the EXT_REG_PRD field of the System Parameter Message. 11


(see [4]) 13

2.6.5.1.2 Power-Down Registration 14

2.6.5.1.3 Timer-Based Registration 15




3.7.2.3.2.30 ANSI- 41 System Parameters Message 19



None 22


5.4.4.1 Timer-based Registration Disabled 24


b. Instruct the base station to set POWER_UP_REG =1 and set REG_PRD = 0 in the 26

System Parameters Message or ANSI – 41 System Parameter Message. 27


d. Verify power-up registration occurs. 29

e. Verify the mobile station does not perform timer-based registration. 30

5.4.4.2 Mid-range Timer Value 31


3GPP2 C.S0044-D v1.0

5-9

b. Instruct the base station to set POWER_UP_REG =0 and set REG_PRD = 38 (57.93 1

seconds) in the System Parameters Message or ANSI –41 System Parameter 2

Message. 3


d. Verify timer-based registration occurs approximately every 58 seconds. 5

5.4.4.3 Longer Timer-Based Registration 6

a. Connect the base station and mobile station as shown in Annex A Figure A-1. 7

b. Instruct the base station to include EXT_REG_PRD in System Parameters Message. 8

c. Power on the mobile station and verify that the mobile station acquires 9

d. Wait until the mobile station performs power up registration 10

e. Verify that EXT_REG_PRD_USED is 1 in DEVICE_CAPABILITY record. 11

f. Wait for at least 2 * [ 2 EXT_REG_PRD] * 14 * 3600 seconds for the mobile station to 12

perform Timer Based Registration. At least 2 timer-based registrations shall be 13

observed. 14


5.4.5.1 Timer-based Registration Disabled 16

The mobile station shall comply with steps d and e. Timer-based registration shall not occur. 17

5.4.5.2 Mid-Range Timer Value 18

The mobile station shall comply with step d. The mobile station shall perform time-based 19 registration at the interval specified by the REG_PRD value. 20

5.4.5.3 Longer Timer-Based Registration 21


23

5.5 Parameter-Change Registration 24

5.5.1 Definition 25

These tests verify proper parameter-change registration functionality. 26

Parameter-change registration is performed when a mobile station modifies any of the following 27 stored parameters: 28

a. The mobile station’s SID_NID_LIST does not match the base station’s SID and NID. 29


(see [4]) 31

2.6.5.1.6 Parameter-Change Registration 32

3GPP2 C.S0044-D v1.0

5-10





None 5


5.5.4.1 Parameter-Change Registration Disabled 7

a. Connect the base station and mobile station as shown in Figure A-5. Base station 1 and 8

base station 2 are CDMA base station operating in the same band class and 9

frequencies with different SID values. 10

b. Instruct the base station to set PARAMETER_REG = ‘0’ and disable all other forms of 11

registration (set equal to 0) in the System Parameters Message or ANSI - 41 System 12


c. Power on the mobile station and allow time for the mobile station to acquire base 14

station 1. 15

d. Force the mobile station to acquire base station 2. 16

e. Verify the mobile station does not send a Registration Message. 17

5.5.4.2 Parameter-Based Registration per SID-NID List change 18


and base station 2 are CDMA base stations using different SID configurations). 20

b. Instruct both base station to set PARAMETER_REG = 1 while ensuring all other forms 21

of registration are disabled (set equal to 0) in the System Parameters Message or ANSI 22

- 41 System Parameters Message. 23

c. Power on the mobile station and allow time for the mobile station to acquire Base 24

Station 1. 25

d. Force the mobile station to acquire Base Station 2. 26

e. Verify the mobile station sends a Registration Message with REG_TYPE = ’0100’. 27

f. Repeat steps a through e with base station 1 and base station 2 using different NID 28

configurations. 29


5.5.5.1 Parameter-Change Registration Disabled 31

5.5.5.2 The mobile station shall comply with step e. Parameter-Based Registration per 32

SID-NID List change 33


3GPP2 C.S0044-D v1.0

5-11

5.6 Zone-Based Registration 1

5.6.1 Definition 2

These tests verify proper Zone-based registration functionality. 3

The mobile station registers when it enters a new zone that is not on its internally stored list of 4 visited registration zones. 5

The mobile station does not register when it performs an idle handoff into a zone that is on its 6 internally stored list of visited zones. 7

The mobile station should properly delete entries from its internally stored list of visited 8 registration zones. 9


(see [4]) 11


2.6.5.1.5 Zone-Based Registration 13



3.7.2.3.2.30 ANSI –41 System Parameters Message 16


None 18


5.6.4.1 Zone-Based Registration Disabled 20

21

Table 5.6.4-1 Parameters for Zone-base Reistration Tests 22

Parameters Test Case 1 Test Case 2 Test Case 3 Test Case 4

BTS 1 REG_ ZONE 0x1 0x1 0x1 0x1

BTS 2 REG_ZONE 0x2 0x2 0x2 0x2

ZONE_TIMER 0x0 0x0 0x0 0x1

TOTAL_ZONES 0x0 0x2 0x2 0x1


b. Configure the System Parameters Message or ANSI - 41 System Parameters Message 24

on base stations 1 and 2 with the REG_ZONE settings from Table 5.6.4-1, test case 1. 25

c. Enable power-up registration (set POWER_UP_REG = 1 in the System Parameters 26

Message or ANSI – 41 System Parameters Message). 27

3GPP2 C.S0044-D v1.0

5-12

d. Allow for the mobile station to perform a power up registration on base station 1. 1

e. Force the mobile station to perform an idle handoff to base station 2 by reducing the 2

base station 2 forward link attenuation, while at the same time increasing the base 3

station 1 forward link attenuation. 4

f. Verify zone-based registration does not occur. 5

5.6.4.2 Zone-Based Registration Enabled 6



on base stations 1 and 2 with the settings from Table 5.6.4-1, test case 2. 9



d. Power on the mobile station and allow it to perform a power up registration on base 12

station 1. (The mobile station should now be registered in zone 1 and the only entry in 13

the mobile station’s ZONE_LIST). 14




f. Verify the mobile station sends a Registration Message with REG_TYPE = ’0010’. (The 18

mobile station should now be registered in zone 2. Zone 1 and Zone 2 should be in the 19

mobile station’s ZONE_LIST). 20

g. Before the period of time specified by ZONE_TIMER has elapsed (one minute) and the 21

mobile station deletes zone 1 from it’s ZONE_LIST, force the mobile station to perform 22

an idle handoff back to base station 1. 23

h. Verify zone-based registration does not occur. (Zone 1 is still in the mobile station’s 24

ZONE_LIST). 25

5.6.4.3 Zone-Based Registration Timer 26












3GPP2 C.S0044-D v1.0

5-13

f. Verify zone-based registration occurs. (The mobile station should now be registered in 1

zone 2. Zone 1 and Zone 2 should be in the mobile station’s ZONE_LIST). 2

g. Wait for the period of time specified by ZONE_TIMER to elapse (one minute, after 3

which the mobile station should delete zone 1 from ZONE_LIST). 4

h. Force the mobile station to perform an idle handoff to base station 1. 5

i. Verify the mobile station sends a Registration Message with REG_TYPE = ’0010’. 6

5.6.4.4 Mobile Station ZONE_LIST Deletion 7












f. Verify the mobile station sends a Registration Message with REG_TYPE = ‘0010’. (The 19

mobile station is now registered in zone 2, and only zone 2 should be in mobile station’s 20

ZONE_LIST because the mobile station was forced to delete zone 1 from ZONE_LIST 21

to make room for zone 2). 22

g. Force the mobile station to perform an idle handoff back to base station 1. 23

h. Verify the mobile station sends a Registration Message with REG_TYPE = ’0010’. 24

(Zone 1 is not in ZONE_LIST). 25


5.6.5.1 Zone-Based Registration Disabled 27

The mobile station shall comply with step f. The mobile station shall not perform a zone-based 28 registration. 29

5.6.5.2 Zone-Based Registration Enabled 30

The mobile station shall comply with steps f, h. The mobile station performs a zone-based 31 registration. 32

5.6.5.3 Zone-Based Registration Timer 33

The mobile station shall comply with steps f, and i. The mobile station performs a zone-based 34 registration. 35

3GPP2 C.S0044-D v1.0

5-14

5.6.5.4 Mobile Station ZONE_LIST Deletion 1

The mobile station shall comply with steps f, h. The mobile station performs a zone-based 2 registration. 3

3GPP2 C.S0044-D v1.0

6-1

6 AUTHENTICATION 1

6.1 Shared Secret Data (SSD) Initialized when A-Key is Changed 2

6.1.1 Definition 3

This test verifies that when the A-Key is changed at both the base station and mobile station, 4 authentication of mobile station registrations, originations, and terminations and the Unique 5 Challenge-Response Procedure are successful. 6


(see [4]) 8

2.3.12.1 (MS) Authentication 9


3.3.1 (Base Station) Authentication 11


None 13



b. Power on the mobile station. 16

c. Initialize the A-Key to the same value in the mobile station and base station. 17

d. Ensure timer-based registration is enabled with the registration period (REG_PRD) set 18

to 29. 19

e. Verify the mobile station sends a Registration Message with REG_TYPE set to ‘0000’ 20

(i.e. timer-based registration) and which includes AUTHR, RANDC and COUNT. 21

f. Verify registration authentication is successful at the base station. 22



i. End the call. 25

j. Setup a mobile station terminated call. 26

k. Verify user data in both directions. 27

l. Instruct the base station to initiate a Unique Challenge-Response Procedure while on 28

the f/r-dsch. 29


1. The base station sends an Authentication Challenge Message, 31

3GPP2 C.S0044-D v1.0

6-2

2. Upon receiving this message, the mobile station sends an Authentication 1

Challenge Response Message, and 2

3. The Unique Challenge-Response Procedure is successful. 3

n. End the call. 4

o. Instruct the base station to initiate a Unique Challenge-Response Procedure while on 5

the f/r-csch. 6

p. Verify the following: 7


2. Upon receiving this message, the mobile station sends an Authentication 9


3. The Unique Challenge-Response Procedure is successful. 11


The mobile station shall comply with the following steps: e, h, k, m, p. 13

The base station shall comply with the following steps: f, h, k, m, p. 14

6.2 Shared Secret Data Update 15

6.2.1 Definition 16

This test verifies the mobile station and base station can perform a Shared Secret Data update on 17 the f/r-csch and f/r-dsch. 18


(see [4]) 20

2.3.12.1.4 Unique Challenge-Response Procedure 21

2.3.12.1.5 Updating the Shared Secret Data (SSD) 22


2.7.1.3.2.6 Authentication Challenge Response Message 24

3.7.2.3.2.1 System Parameters Message (f-csch) 25

3.7.2.3.2.10 Authentication Challenge Message (f-csch) 26


None 28




c. Initialize the A-Key to the same value in both the mobile station and base station. 32

3GPP2 C.S0044-D v1.0

6-3

d. Instruct the base station to initiate a Shared Secret Data update on the f/r-csch. 1


1. The base station sends a SSD Update Message, 3

2. The mobile station sends a Base Station Challenge Order, 4

3. The base station sends a Base Station Challenge Confirmation Order, 5

4. The mobile station sends a SSD Update Confirmation Order, and 6

5. That the SSD Update Procedure is successful. 7

f. Ensure timer-based registration is enabled with the registration period (REG_PRD) set 8

to 29. 9

g. Wait for the mobile station to send the Registration Message with REG_TYPE set to 10

‘0000’ (i.e. timer-based registration). 11

h. Verify the Registration Message includes AUTHR, COUNT and RANDC. 12

i. Verify registration authentication is successful at the base station. 13

j. Setup a mobile station originated call. 14

k. Verify user data in both directions. 15

l. Instruct the base station to initiate a Unique Challenge-Response Procedure on the f/r-16

dsch. 17



2. Upon receiving this message, the mobile station sends a Authentication 20


3. That the Unique Challenge-Response Procedure is successful. 22

n. End the call. 23

o. Instruct the base station to initiate a Unique Challenge-Response Procedure on the f/r-24

csch. 25

p. Verify the following: 26


2. Upon receiving this message, the mobile station sends a Authentication 28


3. That the Unique Challenge-Response Procedure is successful. 30

q. Repeat steps c through p but with the following exception: 31

1. In step d, setup a call and initiate a Shared Secret Data update on the f/r-dsch, 32

and then end the call. 33

3GPP2 C.S0044-D v1.0

6-4


The mobile station shall comply with the following steps: e, h, k, m, p, q. 2

The base station shall comply with the following steps: e, i, k, m, p, q. 3

6.3 Mismatched A-Keys 4

6.3.1 Definition 5

This test verifies that when there is an A_KEY mismatch, authentication of registrations, 6 originations, terminations, and Unique Challenge-Response procedures will fail. 7


(see [4]) 9

2.3.12.1.4 Unique Challenge-Response Procedure 10



2.7.2.3.2.2 Authentication Challenge Response Message (r-dsch) 13


3.7.2.3.2.1 SSD Update Message (f-csch) 15

3.7.3.3.2.2 Authentication Challenge Message (f-dsch) 16

3.7.3.3.2.13 SSD Update Message (f-dsch) 17


None 19




c. Initialize the A-Key to the same value in the mobile station and base station. 23




g. End the call. 27

h. Change the A-Key in the mobile station. 28

i. Ensure timer-based registration is enabled with the registration period (REG_PRD) set 29

to 29. 30

j. Wait for the mobile station to send a Registration Message with REG_TYPE set to 31

‘0000’ (i.e. timer-based registration). 32

3GPP2 C.S0044-D v1.0

6-5

k. Verify the Registration Message includes AUTHR, COUNT and RANDC. 1

l. Verify registration authentication fails at the base station due to an AUTHR mismatch. 2

m. Setup a mobile station originated call. 3

n. Verify that the call request was denied. 4


p. Verify the call fails due to an AUTHR mismatch. 6

q. Initiate at the base station a Shared Secret Data update on the f-csch. 7

r. Verify the SSD Update fails with an AUTHBS mismatch. 8

s. Initiate at the base station a Unique Challenge-Response Procedure on the f-csch. 9

t. Verify the Unique Challenge-Response Procedure fails with an AUTHU mismatch. 10


The mobile station shall comply with the following steps: f, k, n, p, r, t. 12

The base station shall comply with the following steps: f, l, p, r, t. 13

6.4 Activating Voice Privacy on Call Setup 14

6.4.1 Definition 15

This test verifies that Voice Privacy can be activated at call setup by the mobile station 16 subscriber. 17


(see [4]) 19

2.3.12.3 (MS) Voice Privacy 20

2.6.4.1.6 (MS) Long Code Transition Request Processing 21



2.7.3 (Mobile Station) Orders 24

3.3.3 (Base Station) Voice Privacy 25

3.6.4.1.5 (Base Station) Long Code Transition Request Processing 26



3.7.4 (Base Station) Orders 29


None 31

3GPP2 C.S0044-D v1.0

6-6



b. Ensure authentication is enabled. Verify the AUTH field of the Access Parameters 3

Message is set to ‘01’ or the ANSI-41 RAND Message is being transmitted. 4


d. Enable Voice Privacy in the mobile station and configure the base station to use voice 6

privacy. 7

e. Setup a mobile station originated call, and verify in the Origination Message the Voice 8

Privacy Mode Indicator (PM) is set to '1'. 9

f. Instruct the base station to send a Long Code Transition Request Order 10

(ORDQ='00000001') on the f-dsch. 11

g. Verify the mobile station responds with a Long Code Transition Response Order 12

(ORDQ='00000011') 13

h. If supported on the user interface, verify the mobile station indicates to the user that 14

Voice Privacy is active. 15

i. Verify that correct user data is received in both directions. 16

j. End the call. 17

k. Setup a mobile station terminated call, and verify in the Page Response Message the 18

voice privacy indicator (PM) is set to ‘1’ then repeat steps f through j. 19


The mobile station shall comply with the following steps: e, g, h, i, k. 21

The base station shall comply with the following steps: b, i. 22

6.5 Activating Voice Privacy at the Mobile Station When a Call Is Active 23

6.5.1 Definition 24

This test verifies that Voice Privacy can be activated at the mobile station when a call is active. 25


(see [4]) 27

2.3.12.3 (Mobile Station) Voice Privacy 28

2.6.4.1.6 Long Code Transition Request Processing 29



2.7.3 (Mobile Station) Orders 32

3.3.3 (Base Station) Voice Privacy 33

3GPP2 C.S0044-D v1.0

6-7

3.6.4.1.5 (Base Station) Long Code Transition Request Processing 1

3.6.4.3.1 Traffic Channel Substate 2


3.7.4 (Base Station) Orders 4


None 6



b. Configure the base station to use Voice Privacy. 9

c. Ensure authentication is enabled. Verify the AUTH field of the Access Parameters 10




f. Enable voice privacy at the mobile station. Verify the mobile station sends a Long Code 14

Transition Request Order with ORDQ set to ‘00000001’. 15

g. Verify the base station responds by sending a Long Code Transition Request Order 16

with ORDQ set to ‘00000001’. 17

h. Verify the mobile station responds with a Long Code Transition Response Order 18

(ORDQ='00000011'). 19

i. If supported on the user interface, verify the mobile station indicates Voice Privacy is 20

active. 21

j. Verify that correct user data is received in both directions. 22

k. End the call. 23


The mobile station shall comply with the following steps: f, h, i, j. 25

The base station shall comply with the following steps: c, g, j. 26

6.6 Signaling Message Encryption on Forward Traffic Channel 27

6.6.1 Definition 28

This test verifies that Signaling Message Encryption on f-dsch is performed correctly. 29


(see [4]) 31

2.3.12.2 (Mobile Station) Signaling Message Encryption 32

3GPP2 C.S0044-D v1.0

6-8

2.7.4.4 (Mobile Station) Calling Party Number 1

3.3.2 (Base Station) Encryption 2

3.7.2.3.2.8 Channel Assignment Message (f-csch) 3

3.7.3.3.2.3 Alert With Information Message (f-dsch) 4

3.7.5.3 (Base Station) Calling Party Number 5


None 7



b. Activate the Calling Party Number (CPN) feature for the mobile station subscriber. 10




e. Enable Signaling Message Encryption on the base station. 14

f. Setup a mobile station terminated call. 15

g. Verify the ENCRYPT_MODE field is set to '01' or ‘10’ in the transmitted Channel 16

Assignment Message or Extended Channel Assignment Message. 17

h. Verify the following: 18

1. Required fields in the appropriate messages are encrypted and can be correctly 19

decrypted. For example, certain fields of the Alert With Information Message will 20

be encrypted; but verification can be done on other messages as well. 21

2. The ENCRYPTION field in these messages is set to the same value as the 22

ENCRYPT_MODE field received in the Channel Assignment Message or 23


i. Verify the CPN is displayed on the mobile station during the alerting state. 25

j. Verify that correct user data is received in both directions. 26

k. End the call. 27


The mobile station shall comply with the following steps: h, i, j. 29

The base station shall comply with the following steps: c, g, h, j. 30

6.7 Signaling Message Encryption on Reverse Traffic Channel 31

6.7.1 Definition 32

This test verifies that Signaling Message Encryption on the r-dsch is performed correctly. 33

3GPP2 C.S0044-D v1.0

6-9


(see [4]) 2






None 8



b. Ensure authentication is enabled. Verify the AUTH field of the Access Parameters 11



d. Instruct the mobile station to send a Send Burst DTMF Message. 14

e. Enable Signaling Message Encryption on the base station. 15

f. Setup a mobile station call to a voice mail system or a paging system. 16

g. Verify the ENCRYPT_MODE field is set to '01' or ‘10’ in the transmitted Channel 17




decrypted. For example, certain fields of the Burst DTMF Message will be 21

encrypted; but verification can be done on other messages as well. 22




i. Enter the appropriate pin code as burst DTMF tones. 26

j. Verify that either the voice mail system recognizes the DTMF tones and plays the 27

message back, or that the paging system accepts the pin and sends out the page. 28

Alternative procedures may be used to verify correct behavior. 29

k. End the call. 30


The mobile station shall comply with the following step: h. 32

The base station shall comply with the following steps: b, g, h, j. 33

3GPP2 C.S0044-D v1.0

6-10

6.8 Hard Handoffs between Base Stations with Signaling Message Encryption Active 1

6.8.1 Definition 2

This test verifies that when Signaling Message Encryption is used, the new base station activates 3 correct encryption upon handoff. 4


(see [4]) 6



2.7.4.4 (Mobile Station) Calling Party Number. 9


3.6.6.2.2.2 Extended Handoff Direction Message (call processing) 11

3.6.6.2.2.10 General Handoff Direction Message (call processing) 12

3.6.6.2.2.11 Universal Handoff Direction Message (call processing) 13


3.7.3.3.2.14 Flash With Information Message (f-dsch) 15

3.7.3.3.2.17 Extended Handoff Direction Message (f-dsch) 16

3.7.3.3.2.31 General Handoff Direction Message (f-dsch) 17

3.7.3.3.2.36 Universal Handoff Direction Message (f-dsch) 18

3.7.5.3 (Base Station) Calling Party Number 19


None 21



b. Activate Call Waiting and Caller ID on base station 2. 24




e. Enable Signaling Message Encryption on both base stations. 28


g. Verify ENCRYPT_MODE field is set to '01' or ‘10’ in the transmitted Channel 30



3GPP2 C.S0044-D v1.0

6-11

i. Cause a hard handoff from base station 1 to base station 2. 1

j. Verify ENCRYPT_MODE field is set to '01’ or ‘10’ in the transmitted Extended Handoff 2

Direction Message, General Handoff Direction Message, or Universal Handoff Direction 3

Message. 4

k. Setup another call to the mobile station and listen for the Call Waiting tone. 5



decrypted. For example, certain fields of the Flash With Information Message will 8

be encrypted; but verification can be done on other messages as well. 9




m. Verify that Calling Party Number (CPN) information is displayed on the mobile station 13

during alerting state. 14

n. Verify user data in both directions. 15

o. End the call. 16


The mobile station shall comply with the following steps: h, l, m, n. 18

The base station shall comply with the following steps: c, g, h, j, l, n. 19

6.9 Authentication upon Originations 20

6.9.1 Definition 21

This test verifies the mobile station can successfully Authenticate upon an origination. 22


(see [4]) 24



2.7.2.3.2.2 Authentication Challenge Response Message (r-dsch) 27


3.7.2.3.2.11 SSD Update Message (f-csch) 29

3.7.3.3.2.2 Authentication Challenge Message (f-dsch) 30

3.7.3.3.2.13 SSD Update Message (f-dsch) 31


None 33

3GPP2 C.S0044-D v1.0

6-12




c. Initialize the A-Key to the same value in both the mobile station and base station. 4


e. Verify the SSD Update was successful. 6

f. Setup a mobile station originated call (seven digits). 7

g. Verify user data in both directions and that authentication is successful. 8

h. End the call. 9

i. Setup a mobile station originated call (three digits such as *73). 10

j. Verify user data in both directions and that authentication is successful. 11

k. End the call. 12

l. Setup a mobile station originated call (four digits such as *123). 13

m. Verify user data in both directions and that authentication is successful. 14

n. End the call. 15


The mobile station shall comply with the following steps: e, g, j, and m. 17

The base station shall comply with the following steps: e, g, j, and m. 18

6.10 Hard Handoff from CDMA to Analog with Signaling Message Encryption Active 19


This test verifies that when Signaling Message Encryption is used, the new base station activates 21 Analog Signaling Message Encryption upon handoff. 22


(see [4]) 24


2.6.6.2.9 CDMA-Analog HO 26

2.7.4.4 (Mobile Station) Calling Party Number 27




3.7.3.3.2.3 Alert with Information Message (f-dsch) 31

3GPP2 C.S0044-D v1.0

6-13


3.7.5.3 (Base Station) Calling Party Number. 2


None 4



b. Activate Call Waiting and Caller ID on Base station 2. 7




e. Enable Signaling Message Encryption on both base stations. 11


g. Verify ENCRYPT_MODE field is set to '01' or ‘10’ in the Channel Assignment Message 13

or Extended Channel Assignment Message transmitted. 14

h. Verify that correct user data is received in both directions. 15

i. Cause a CDMA to analog hard handoff from base station 1 to base station 2. 16

j. Verify ENCRYPT_MODE='01' and MEM=’1’ in the Analog Handoff Direction Message. 17

k. Setup another call to the mobile station, and listen for the Call Waiting tone. 18

l. Verify base station 2 sends an encrypted Alert with Information Message (analog). 19

m. Verify that the Calling Party Number (CPN) information is displayed on the mobile 20

station during the alerting state. 21

n. Verify that correct user data is received in both directions. 22

o. End the call. 23


The mobile station shall comply with the following steps: h, m, n. 25

The base station shall comply with the following steps: c, g, h, j, l, n. 26

27

3GPP2 C.S0044-D v1.0

6-14

This page intentionally left blank. 1

2

3GPP2 C.S0044-D v1.0

7-1

7 SERVICE REDIRECTION TEST CASES 1

7.1 Global Service Redirection between Band Classes 2

7.1.1 Definition 3

This test verifies that when a mobile station receives a Global Service Redirection Message 4 directing it to another band class, the mobile station acquires the appropriate system. 5

When testing Global Service Redirection, the base station must not broadcast an Extended 6 Global Service Redirection on any overhead channel. 7


(see [4]) 9



2.6.2.2.6 Global Service Redirection Message 12


3.7.2.3.2.18 Global Service Redirection Message 14


None 16


a. Connect the mobile station to the base station as shown in Figure A-5. For this test 18

case, base station 1 and base station 2 are in different band classes. 19

b. Verify the mobile station is operating in the Mobile Station Idle State on base station 1. 20

c. Ensure that the base station sends a Global Service Redirection Message with: 21

22

3GPP2 C.S0044-D v1.0

7-2

Field Value

REDIRECT_ACCOLC ACCOLCp

EXCL_P_REV_MS ‘0’

RECORD_TYPE ‘00000010’

BAND_CLASS Target Band Class

EXPECTED_SID Target SID

EXPECTED_NID Target NID

NUM_CHAN Number of Channels

CDMA_CHAN Target Channel(s)

d. Verify the mobile station enters the System Determination Substate of the Mobile 1

Station Initialization State and acquires the system to which it was redirected. 2

e. Setup a mobile station originated call. Verify user traffic in both directions. 3

f. End the call. 4

g. Repeat steps c through f with the mobile station operating in the Mobile Station Idle 5

State on base station 2. 6

h. Repeat steps b and c with the mobile station operating in the Mobile Station Idle State 7

on base station 1 setting EXCL_P_REV_MS = ‘1’ in the Global Service Redirection 8

Message. 9


1. If MOB_P_REV is less than six, verify the mobile station enters the System 11

Determination Substate of the Mobile Station Initialization State and acquires the 12

system to which it was redirected. 13

2. If MOB_P_REV is greater than or equal to six, verify the mobile station remains 14

in the Mobile Station Idle State on the current system. 15


The mobile station shall comply with steps d, e, and i. 17

7.2 Global Service Redirection between CDMA and a Non-CDMA System 18

7.2.1 Definition 19

This test verifies that when a mobile station receives a Global Service Redirection Message 20 directing it from CDMA to a Non-CDMA system, the mobile station acquires that system. The 21 mobile station should only be redirected to Non-CDMA systems it supports. An example would be 22 an analog system defined in [21]. 23


3GPP2 C.S0044-D v1.0

7-3


(see [4]) 2







None 9



case, base station 1 is a CDMA base station and base station 2 is a Non-CDMA base 12

station. 13

b. Ensure the mobile station is operating in the Mobile Station Idle State on base station 1. 14

c. Send a Global Service Redirection Message from the current base station directing the 15

mobile station to the non-CDMA base station with the following parameters: 16

Field Value



RECORD_TYPE '00000001' [North

American Amps]

'00000011' [TACS]

'00000100' [JTACS]

‘00000101’ (DS-41)

If RECORD_TYPE=’00000001’,

the base station shall include the

following fields


IGNORE_CDMA ‘0’

SYS_ORDERING ‘000’

MAX_REDIRECT_DELAY ‘00000’

17



3GPP2 C.S0044-D v1.0

7-4


f. End the call. 2

g. Repeat steps b and c with the mobile station operating in the Mobile Station Idle State 3


Message. 5








The mobile station shall comply with steps d, e, and h. 13

7.3 Global Service Redirection between Channels in the Same Band Class 14

7.3.1 Definition 15

This test verifies that when a mobile station receives a Global Service Redirection Message 16 directing it to a different channel in the same band class, the mobile station acquires the 17 appropriate system. 18



(see [4]) 22







None 29



case, base station 1 and base station 2 are in the same band class with different CDMA 32

channels. 33


3GPP2 C.S0044-D v1.0

7-5

c. Send a Global Service Redirection Message from the current base station with: 1

2

Field Value









3




f. End the call. 7

g. Remove the channel for base station 2 from the mobiles station’s preferred roaming list 8

and repeat steps b through f. 9

h. Repeat steps b and c with the mobile station operating in the Mobile Station Idle State 10


Message. 12








The mobile station shall comply with steps d, e, and i. 20

7.4 Service Redirection between Band Classes 21

7.4.1 Definition 22

This test verifies Network Directed System Selection (NDSS) functions correctly. This test verifies 23 that a mobile station is capable of being redirected between band classes when the Service 24

3GPP2 C.S0044-D v1.0

7-6

Redirection Message is sent on the f-csch or on the f-dsch prior to user traffic being transmitted 1 and the call completes on the new system without user interaction. 2


(see [4]) 4





3.7.2.3.2.16 Service Redirection Message {f-csch} 9

3.7.3.3.2.23 Service Redirection Message {f-dsch} 10


None 12





c. Instruct the mobile station to send an Origination Message to the base station. 17

d. Instruct the base station to send a Service Redirection Message with the following 18

information to the mobile station on the f-csch or on the f-dsch. 19

Field Value

REDIRECT_TYPE ‘1’ (NDSS redirection)







20

e. Verify the mobile station acquires the target base station and the call completes without 21

additional user interaction and user traffic is present. 22

f. End the call. 23

g. Repeat steps c through f with the mobile station operating in the Idle State on base 24

station 2. 25

3GPP2 C.S0044-D v1.0

7-7



7.5 Service Redirection between CDMA and a Non-CDMA System 3

7.5.1 Definition 4

This test verifies that a mobile station is capable of being redirected from a CDMA system to a 5 non-CDMA system when the Service Redirection Message is sent on the f-csch or on the f-dsch 6 prior to user traffic being transmitted, and the call completes on the new system without user 7 interaction. The mobile station should only be redirected to Non-CDMA systems it supports. An 8 example of a non-CDMA system is an analog system defined in [21]. 9


(see [4]) 11








None 19




station. 23





28

3GPP2 C.S0044-D v1.0

7-8

Field Value

RETURN_IF_FAIL ‘0’



American Amps]

'00000011' [TACS]

'00000100' [JTACS]

‘00000101’ (DS-41)



following fields


IGNORE_CDMA ‘0’


1



f. End the call. 4

g. For RECORD_TYPE=’00000001’, repeat steps a through e setting IGNORE_CDMA = 5

‘1’ in the Service Redirection Message: 6

h. Send the CDMA Capability Message from base station 2 indicating CDMA is available 7

(i. e. CDMA_AVAIL set to ‘1’). 8

i. End the call. 9

j. Verify the mobile station remains in the Idle State on the non-CDMA system and does 10

not attempt to re-acquire CDMA. 11


The mobile station shall comply with steps e, g and j. 13

7.6 Service Redirection between Channels in the Same Band Class 14

7.6.1 Definition 15

This test verifies Network Directed System Selection (NDSS) functions correctly. This test verifies 16 that a mobile station is capable of being redirected between channels in the same band class 17 when the Service Redirection Message is sent on the f-csch or on the f-dsch prior to user traffic 18 being transmitted and the call completes on the new system without additional user interaction. 19

3GPP2 C.S0044-D v1.0

7-9


(see [4]) 2








None 10



case, base station 1 and base station 2 have different CDMA channels in the same 13

band class. 14





Field Value

RETURN_IF_FAIL ‘0’









f. End the call. 21

g. Repeat steps c through f with the mobile station operating in the Idle State on base 22

station 2. 23

h. Repeat steps b through d ensuring the mobile station cannot re-acquire base station 2 24

and setting RETURN_IF_FAIL = ‘1’ in the Service Redirection Message: 25

3GPP2 C.S0044-D v1.0

7-10

i. Verify the mobile station returns to base station 1 after failing to acquire base station 2. 1

The call may or may not complete depending on infrastructure implementation. 2


The mobile station shall comply with steps e, g, and i. 4

7.7 Extended Global Service Redirection between Band Classes 5

7.7.1 Definition 6

This test verifies that when a mobile station receives an Extended Global Service Redirection 7 Message directing it to another band class, the mobile station acquires the appropriate system. 8


(see [4]) 10



2.6.2.2.11 Extended Global Service Redirection Message 13


3.7.2.3.2.27 Extended Global Service Redirection Message 15



None 18





c. Send an Extended Global Service Redirection Message from the current base station 23

with: 24

3GPP2 C.S0044-D v1.0

7-11

Field Value


REDIRECT_P_REV_INCL ‘0’










f. End the call. 4

g. Repeat steps c through f with the mobile station operating in the Mobile Station Idle 5

State on base station 2. 6


The mobile station shall comply with steps d, e and g. 8

7.8 Extended Global Service Redirection between CDMA and a Non-CDMA System 9

7.8.1 Definition 10

This test verifies that when a mobile station receives an Extended Global Service Redirection 11 Message directing it from CDMA to a Non-CDMA system, the mobile station acquires that 12 system. The mobile station should only be redirected to Non-CDMA systems it supports. An 13 example would be an analog system defined in [21]. 14


(see [4]) 16







3GPP2 C.S0044-D v1.0

7-12


None 2




station. 6



directing the mobile station to the non-CDMA base station with the following 9

parameters: 10

11

Field Value




American Amps]

'00000011' [TACS]

'00000100' [JTACS]

‘00000101’ (DS-41)



following fields


IGNORE_CDMA ‘0’


MAX_REDIRECT_DELAY ‘00000’




f. End the call. 15


The mobile station shall comply with steps d and e 17

3GPP2 C.S0044-D v1.0

7-13

7.9 Extended Global Service Redirection between Channels in the Same Band Class 1

7.9.1 Definition 2

This test verifies that when a mobile station receives an Extended Global Service Redirection 3 Message directing it to a different channel in the same band class, the mobile station acquires the 4 appropriate system. 5


(see [4]) 7








None 15



case, base station 1 and base station 2 are in the same band class with different CDMA 18

channels. 19



with: 22

Field Value











3GPP2 C.S0044-D v1.0

7-14

f. End the call. 1

g. Remove the channel for base station 2 from the mobile station’s preferred roaming list 2

and repeat steps b through f. 3


The mobile station shall comply with steps d and e. 5

6

3GPP2 C.S0044-D v1.0

8-1

8 SHORT MESSAGE SERVICE 1

8.1 Mobile Station Terminated SMS Tests 2

Unless otherwise noted, the following conditions apply for all tests in this section: 3

• Mobile station is capable of receiving short messages. 4

• The short message feature for the mobile station is activated. 5

• Base station has Power-up registration enabled by setting POWER-UP_REG = ‘1’ in the 6 System Parameters Message or the ANSI-41 System Parameters Message. 7

• Transport Layer messages shall include the Bearer Reply Option. 8

8.1.1 Common Channel SMS Delivery 9


This test verifies that a short message can be sent to a mobile station in the Mobile Station Idle 11 State. 12


(see [13]) 14

2.4.1.1.1.1 Mobile SMS Message Termination 15


None 17


a. Delete all outstanding short messages in the network for the mobile station. 19

b. Create a short message in the Message Center for the mobile station. Ensure that the 20

short message length is less than the maximum allowed size on the Paging Channel or 21

Forward Common Control Channel so that it can be sent to the mobile station using the 22

Paging Channel or Forward Common Control Channel9. 23

c. Power on the mobile station and wait until it is in the Mobile Station Idle State. 24

d. Instruct the network to send the short message to the mobile station. 25

e. Verify the base station sends a Data Burst Message to the mobile station with the 26

following field settings: 27

28

9 The max size for common channel SMS is base station implementation dependent.

3GPP2 C.S0044-D v1.0

8-2

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)

NUM_FIELDS Greater than 0

1

f. Upon receiving the Data Burst Message at the mobile station, verify the following: 2

1. The mobile station alerts the user for the incoming short message and 3

correctly displays the received short message, when selected. 4

2. The mobile station transmits Data Burst Message on the Access 5

Channel, Enhanced Access Channel or Reverse Common Control 6

Channel to acknowledge the short message, indicating no error (i.e. 7

contains a ‘Cause Codes’ parameter having ERROR_CLASS = ‘00’). 8



8.1.2 Traffic Channel SMS Delivery 11


This test verifies that a short message, with length exceeding the maximum allowable length 13 (configurable by the network) for Paging Channel or Forward Common Control Channel transport, 14 is delivered to the mobile station over the Traffic Channel. 15


(see [13]) 17


2.4.2.1.2 Base Station Traffic Channel Procedures 19


None 21



b. Create a short message in the Message Center for the mobile station. Ensure that the 24

short message length is greater than the maximum length supported on the Paging 25

Channel or Forward Common Control Channel . 26


3GPP2 C.S0044-D v1.0

8-3

d. Instruct the network to send the short message to the mobile station. Verify the 1

following: 2

1. The base station does not send a Data Burst Message to the mobile 3

station on the paging channel or Forward Common Control Channel. 4

2. The base station sends a General Page Message with either service 5

option 6 or service option 14. 6

3. After the mobile station enters the Conversation Substate, the base 7

station sends a Data Burst Message to the mobile station with the 8


10

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


e. Upon receiving the Data Burst Message at the mobile station, verify the following: 11



2. The mobile station transmits a Data Burst Message on the Reverse 14

Traffic Channel to acknowledge the short message, indicating no error 15

(i.e. contains a Cause Codes parameter having ERROR_CLASS = ‘00’). 16


The mobile station shall comply with step e. The base station shall comply with step d. 18

8.1.3 Traffic Channel SMS Delivery while in Conversation 19


This test verifies a short message can be sent to a mobile station when it is already in the 21 Conversation Substate. 22


(see [13]) 24



2.4.2.1.2.4 Mobile Station Message Termination in the Conversation Substate 27

3GPP2 C.S0044-D v1.0

8-4


None 2




c. While the mobile station is in the Conversation Substate, create a short message in the 6

Message Center for the mobile station. 7


e. Verify the base station sends a Data Burst Message to the mobile station, with the 9


11

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


f. Upon receiving the Data Burst Message at the mobile station, verify the following: 12




Traffic Channel to acknowledge the receipt of the short message and 16

indicating no error (i.e. contains a Cause Codes parameter having 17

ERROR_CLASS = ‘00’). 18



8.1.4 Delivery of Maximum Length Message 21


This test verifies the SMS transport layer capability to send to a mobile station a short message of 23 the maximum size – the maximum size is the lesser of the maximum allowable length of the 24 message center and the maximum length specified by the mobile station manufacturer. The test 25 verifies delivery of the maximum length short message on the Traffic Channel. 26


(see [13]) 28

3GPP2 C.S0044-D v1.0

8-5


3.4.2.1 SMS Point-to-Point Message 2

3.4.3.5 Bearer Reply Option 3


None 5


a. Clear all short messages stored in the mobile station. 7

b. Delete all outstanding short messages in the Network for the mobile station. 8

c. Create in the Message Center a maximum size short message for the mobile station. 9


e. Verify the base station sends a Data Burst Message to the mobile station on the traffic 11

channel, with the following field settings: 12

13

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


f. Upon receiving Data Burst Message at the mobile station, verify the following: 14




Traffic Channel to acknowledge receipt of the short message and 18

indicating no error (i.e. contains a Cause Codes parameter having 19



The mobile station shall comply with f. The base station shall comply with step e. 22

8.1.5 SMS Delivery Error - Mobile Station Short Message Buffer Full 23


This test verifies SMS transport layer acknowledgment capability by sending to the mobile station 25 short messages until the mobile station short message buffer is full. 26

3GPP2 C.S0044-D v1.0

8-6


(see [13]) 2


2.4.2.1.1 Common Channel Procedures 4


3.4.3.6 Cause Codes 6


None 8


a. Clear all short messages from the mobile station to ensure that the short message 10

buffer is empty. 11

b. Delete all outstanding short messages in the network for the mobile station. 12

c. Create in the Message Center a short message for the mobile station. 13


e. Verify the base station sends a Data Burst Message to the mobile station, with the 15


17

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


f. Upon receiving the Data Burst Message, the mobile station shall transmit a Data Burst 18

Message to acknowledge receipt of the short message and indicating no error (i.e. 19

contains a Cause Codes parameter having ERROR_CLASS = ‘00’). 20

g. Repeat steps c through f until the mobile station short message buffer is full. 21

h. Instruct the network to send one additional short message to the mobile station. 22

i. Verify the base station sends a Data Burst Message to the mobile station, with the 23


3GPP2 C.S0044-D v1.0

8-7

1

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


j. Upon receiving the Data Burst Message sent in step i, verify that the mobile station 2

transmits a Data Burst Message on the Access Channel, Enhanced Access Channel or 3

Reverse Common Control Channel to acknowledge the short message and indicating 4

temporary error (with ERROR_CLASS = ‘10’ and CAUSE_CODE=35. 5


The mobile station shall comply with step j. The base station shall comply with steps e and i. 7

8.1.6 Voice Mail Notification 8


Voice Mail Notification (VMN) notifies the subscriber of voice mail messages using the Voice Mail 10 Notification teleservice and Short Message Service protocol. Notification can be a tone, light, or 11 display, and is manufacturer dependent. 12


(see [13]) 14

4.3.5 Voice Mail Notification (VMN) 15

4.5.12 Number of Messages 16


None 18


a. Configure the system as shown in Figure A-3. 20

b. Power on the mobile station and wait until it is in the Mobile Station Idle State. 21

c. Instruct the network to send a Voice Mail Notification (corresponds to an SMS Point-to-22

Point message) to the mobile station. 23

d. Verify that the base station sends a Data Burst Message, with the BURST_TYPE field 24

set to ‘000011’, with the following parameters settings: 25

1. Teleservice Identifier parameter, IDENTIFIER = Voice Mail Notification 26

(0x1003). 27

3GPP2 C.S0044-D v1.0

8-8

2. Message Identifier sub-parameter, MESSAGE_TYPE = Deliver (0x1). 1

3. Number of Messages sub-parameter, MESSAGE_CT = 99. 2

e. Upon receiving the Data Burst Message, verify the following: 3

1. The mobile station transmits an SMS Acknowledge message via Data Burst 4

Message on the Access Channel, Enhanced Access Channel or Reverse 5

Common Control Channel to acknowledge the short message, indicating no error 6

(i.e. contains a Cause Codes parameter having ERROR_CLASS = ‘00’). 7

2. The mobile station indicates to the user the number of voice mail messages 8

available as indicated by the network. 9

f. Repeat step c and d, setting the MESSAGE_CT = 0. 10

g. Upon receiving the Data Burst Message, verify that the mobile station indicates to the 11

user no voice mail messages are available. 12


The mobile station shall comply with steps e and g. The base station shall comply with step d. 14

8.2 Mobile Station Originated SMS Tests 15

This section is to be performed on mobile stations that support mobile station originated short 16 messaging. 17

8.2.1 Common Channel SMS Delivery 18


This test verifies that a short message can be sent to the Message Center (MC) by a mobile 20 station using the Access Channel, Enhanced Access Channel or Reverse Common Control 21 Channel. The short message length chosen for this test is such that it doesn’t exceed the 22 maximum message length allowed on the Access Channel, Enhanced Access Channel or 23 Reverse Common Control Channel. 24


(see [13]) 26

2.4.1.1.1.2 Mobile station SMS Message Origination 27



None 30


a. Power on the mobile station and wait until it is in the Mobile Station Idle State. 32

3GPP2 C.S0044-D v1.0

8-9

b. Create a short message at the mobile station, of a length smaller than the maximum 1

message length allowed on the Access Channel, Enhanced Access Channel or 2

Reverse Common Control Channel10

. 3

c. Instruct the mobile station to send the short message to the network. 4

d. Verify the mobile station sends a Data Burst Message to the base station over the 5

Access Channel, Enhanced Access Channel or Reverse Common Control Channel with 6

the following field settings: 7

8

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


e. Verify that the base station receives the short message and sends a layer 2 9

acknowledgement to the mobile station. 10



8.2.2 Traffic Channel SMS Delivery 13


This test verifies a mobile station in the Mobile Station Idle State can originate a short message of 15 length larger than the maximum length allowed on the Access Channel, Enhanced Access 16 Channel or Reverse Common Control Channel and that the message is delivered to the Message 17 Center over the Traffic Channel. 18


(see [13]) 20

2.4.1.1.1.2 Mobile SMS Message Origination 21



None 24

10 The maximum allowed size is dependent on the current capsule size or duration signaled in the

overhead messages broadcasted by the base station and is also implementation dependent.

3GPP2 C.S0044-D v1.0

8-10



b. Create a short message at the mobile station, of a length larger than the maximum 3

message length allowed on the Access Channel, Enhanced Access Channel or 4

Reverse Common Control Channel. 5


d. Verify the following: 7

1. The mobile station does not send the Data Burst Message over the Access 8

Channel, Enhanced Access Channel or Reverse Common Control Channel 9

2. The mobile station sends an Origination Message to originate as SMS call with 10

the SERVICE_OPTION field set to either 6 or 14. 11

3. After entering the Conversation Substate, the mobile station sends a Data Burst 12

Message, with the following fields set as follows: 13

14

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


15

e. Verify the Message Center receives the short message. 16

f. Verify that upon sending the short message, the mobile station sends a Release Order 17

to release the dedicated channels. 18



8.2.3 Traffic Channel SMS Delivery while in Conversation 21


This test verifies that a short message can be sent by the mobile station when it is in the 23 Conversation Substate. 24


(see [13]) 26


3GPP2 C.S0044-D v1.0

8-11

2.4.1.1.2.4 Mobile station Station Message Origination in the Conversation Substate 1



None 4


a. Setup a mobile station originated call. 6

b. While mobile station is in the Conversation Substate, create a short message. 7


d. Verify the mobile station sends a Data Burst Message, with the following fields set as 9

follows: 10

11

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


12

e. Verify the Message Center receives the short message. 13

f. Verify that upon sending the short message, the mobile station does not attempt to 14

release the dedicated channels. 15



8.2.4 Unknown Destination Address 18


This test verifies the base station can process a mobile station originated short message with an 20 unknown destination address and will inform the mobile station regarding an unknown destination 21 address. 22


(see [13]) 24



3GPP2 C.S0044-D v1.0

8-12



None 3



b. Create a short message at the mobile station, but with an unknown address in the 6

destination address field and the Bearer Reply Option parameter set. 7

c. Instruct the mobile station to send the short message to the base station. 8

d. Verify the mobile station sends a Data Burst Message, with the following fields set as 9

follows: 10

11

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


e. Verify the Message Center receives the short message and the base station sends a 12

Data Burst Message to the mobile station indicating ‘an unknown address’ 13


The mobile station shall comply with step d. The base station shall comply with step e. 15

8.2.5 Mobile Station Originated SMS Disabled 16


This test verifies that when mobile station originated SMS is not activated in the network, the 18 base station can process a mobile station originated short message and inform the mobile station 19 that short message origination has been denied. 20


(see [13]) 22




3GPP2 C.S0044-D v1.0

8-13


None 2


a. Ensure the mobile station originated short message feature for the mobile station is not 4

activated in the network. 5


c. Create a short message at the mobile station, with the Bearer Reply Option parameter 7

set. 8

d. Instruct the mobile station to send the short message to the base station. 9

e. Verify the mobile station sends a Data Burst Message, with the following fields set as 10

follows: 11

12

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


f. Upon receiving the Data Burst Message at the base station, verify the following: 13

1. The base station sends a Data Burst Message to the mobile station, with 14

an indication that the short message origination has been denied. 15

2. The base station does not route the short message to the Message 16

Center. 17


The mobile station shall comply with step e. The base station shall comply with step f. 19

8.2.6 SMS Not Supported by Base Station 20


This test verifies the base station can process a mobile station originated short message, and 22 inform the mobile station that SMS is not supported by the base station. 23


(see [13]) 25



3GPP2 C.S0044-D v1.0

8-14



None 3


a. Ensure the base station is not capable of SMS or that SMS has been disabled for this 5

test. 6


c. Create a short message at the mobile station, with Bearer Reply Option parameter set. 8

d. Instruct the mobile station to send the short message to the network. 9

e. Verify the mobile station sends a Data Burst Message, with the following fields set as 10

follows: 11

12

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


13

f. Upon receiving the Data Burst Message at the base station, verify the following: 14

1. The base station sends a Data Burst Message to the mobile station, with an 15

indication that SMS is not supported by this base station. 16

2. The base station does not route the short message to the Message Center. 17


The base station shall comply with step f. 19

8.3 Broadcast SMS Delivery on the Common Channel 20

8.3.1 Definition 21

This test verifies that mobile stations are able to receive broadcast SMS messages sent by the 22 network addressed to any broadcast address that the mobile stations are configured to receive 23 based on the priority, service and language. 24


(see [13]) 26

3GPP2 C.S0044-D v1.0

8-15

2.4.1.2.1 Common Channel Procedures for Broadcast SMS 1

4.3.1.3 Broadcast Messaging Service 2


None 4


a. Connect the base station and mobile stations as shown in Figure A-8. 6

b. Ensure mobile station 1 is configured to receive broadcast SMS with normal priority 7

while mobile station 2 is configured to receive broadcast SMS with emergency priority. 8

Also, ensure that both mobile stations are configured to receive other filtering 9

categories (i.e. service and language) for this test. 10

c. Power on the mobile stations and wait until they are registered. 11

d. Clear any outstanding broadcast messages in the network. 12

e. Create broadcast message 1 shown in Table 8.3.4-1 13

f. Instruct the network to broadcast message 1. 14

g. Verify the base station sends a Data Burst Message, with the following fields set as 15

follows: 16

17

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


18

Table 8.3.4-1 19

Broadcast Message Broadcast Message Priority Priority Indicator Value

Message 1 Normal 00

Message 2 Emergency 11

20

h. Upon receiving the Data Burst Message, verify that mobile station 1 displays broadcast 21

message 1 (as a Normal message, if such display is supported) and mobile station 2 22

does not. 23

i. Create broadcast message 2 shown in Table 8.3.4-1. 24

3GPP2 C.S0044-D v1.0

8-16

j. Instruct the network to broadcast message 2. 1

k. Verify the base station sends a Data Burst Message, with the following fields set as 2

follows: 3

4

5

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


6

l. Upon receiving the Data Burst Message, verify both mobile stations display broadcast 7

message 2 (as an Emergency message, if such a display is supported) 8


The mobile station shall comply with steps h and l. The base station shall comply with steps g and 10 k. 11

8.4 Mobile Station Terminated Enhanced Messaging Services [EMS] Tests: 12

Unless otherwise noted, the following conditions apply for all tests in this section: 13

a. Mobile station is capable of receiving Enhanced Messaging Services [EMS] messages. 14

b. The EMS message feature for the mobile station is activated. 15

c. Base station has Power-up registration enabled by setting POWER-UP_REG = ‘1’ in 16

the System Parameters Message or the ANSI-41 System Parameters Message. 17

d. Transport Layer messages shall include the Bearer Reply Option. 18

e. SMS message carries Teleservice ID parameter is set to WEMT (0x1005),, and 19

HEAD_IND of Message Identifier subparameter is set to '1' 20

8.4.1 Multi-Segment EMS Message Delivery 21


This test verifies the mobile station’s ability to receive and properly display multi-segmented EMS 23 messages. 24


(see [13]) 26

4.3.7 Wireless Enhanced Messaging Teleservice 27

3GPP2 C.S0044-D v1.0

8-17

2.4.1.1.1.1 Mobile station SMS Message Termination 1


None 3


a. Delete all outstanding short messages in the network for the mobile station. Delete all 5

short messages in the mobile station. 6

b. Create an EMS message in the Message Center for the mobile station, consisting of (3) 7

three segments. 8

c. Instruct the Message Center to send the first segment of the EMS message to the 9

mobile station. 10

d. Verify that the base station sends the first Data Burst Message to the mobile station, 11

with the following fields set as follows: 12

13

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


e. Verify that the mobile station transmits a Data Burst Message to acknowledge the 14

received Data Burst Message, and indicates no error (i.e. containing Cause Codes 15

parameter having ERROR_CLASS = ‘00’). 16

f. Instruct the Message Center to send the remaining segments of the EMS message to 17


g. Verify that the base station sends the remaining Data Burst Messages to the mobile 19

station, with the following fields set as follows: 20

21

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


22

3GPP2 C.S0044-D v1.0

8-18

h. Verify that the mobile station transmits a Data Burst Message to acknowledge each 1

received Data Burst Message, containing a message segment, and indicates no error 2

(i.e. contains Cause Codes parameters having ERROR_CLASS = ‘00’). 3

i. Upon receiving all the Data Burst Messages at the mobile station, verify the following: 4

1. The mobile station alerts the user for the incoming EMS message and correctly 5

displays the received message, when selected. Verify that all the segments of 6

the EMS message segments sent are properly displayed in correct order. 7


The mobile station shall comply with steps e, h, and i. The base station shall comply with steps d 9 and g. 10

8.4.2 Delivery of Predefined Sound Elements 11


This test verifies mobile station’s ability to receive and properly play pre-defined EMS sound 13 elements. 14


(see [13]) 16


2.4.1.1.1.1 Mobile station SMS Message Termination 18


None 20




b. Create an EMS message in the Message Center for the mobile station. In the message 24

include (1) one predefined sound element. 25


d. Instruct the network to send the EMS message to the mobile station. 27


specified fields set as follow: 29

30

3GPP2 C.S0044-D v1.0

8-19

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)



1. The mobile station alerts the user for the incoming message and correctly 2

displays the received message (if chosen). 3

2. The mobile station properly plays the predefined sound, when selected. 4

3. The mobile station transmits a Data Burst Message to acknowledge the EMS 5

message, indicating no error (i.e. contains a Cause Codes parameter having 6




8.4.3 Delivery of Predefined Animation Elements 10


This test verifies mobile station’s ability to receive and properly play pre-defined EMS animation 12 elements. 13


(see [13]) 15




None 19





include (1) one pre-defined animation in a specific order. 24



3GPP2 C.S0044-D v1.0

8-20



3

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)





2. The mobile station properly plays the pre-defined animation, when selected. 7






8.4.4 Delivery of User Defined Sound Elements - MT 13


This test verifies mobile station’s ability to receive and properly play user defined (iMelody) EMS 15 sound elements. 16


(see [13]) 18




None 22





include (1) one iMelody sound object. 27

3GPP2 C.S0044-D v1.0

8-21





5

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)





2. The mobile station properly plays the iMelody sound object, when selected. 9

Verify that the iMelody being played is same as the one being transmitted. 10






8.4.5 Delivery of User Defined Animation Elements - MT 16


This test verifies mobile station’s ability to receive and properly play user defined EMS animation 18 elements. 19


(see [13]) 21




None 25

3GPP2 C.S0044-D v1.0

8-22





include one user-defined animation object. 5





10

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)





2. The mobile station properly plays the user-defined animation, when selected. 14






8.4.6 Delivery of User Defined Picture Elements - MT 20


This test verifies mobile station’s ability to receive and properly play user defined EMS picture 22 elements. 23


(see [13]) 25



3GPP2 C.S0044-D v1.0

8-23


None 2





include one user-defined picture object. 7





12

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)





2. The mobile station properly displays the user-defined picture, when selected. 16






8.4.7 Delivery of Formatted Text 22


This test verifies mobile station’s ability to receive and properly display formatted text embedded 24 in EMS messages. 25


(see [13]) 27

3GPP2 C.S0044-D v1.0

8-24




None 4




b. Create an EMS message in the Message Center for the mobile station. From the 8

following text, include the text with formatting that is supported by the mobile station in 9

the message: 10

11

12

13

14

15

16

17

18

19

20





25

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)





Normal Bold Italics Bold-Italics

Underlined Bold-Underlined Bold-Italics-Underlined

Left-Justified

Center-Justified

Right-Justified

3GPP2 C.S0044-D v1.0

8-25

2. The mobile station properly displays the text, including correct formatting of the 1

lines of text displayed. 2






8.5 Mobile Station Originated Enhanced Messaging Services [EMS] Tests: 8

8.5.1 Multi-Segment EMS Message Delivery 9


This test verifies mobile station’s ability to compose and send multi-segmented EMS messages. 11


(see [13]) 13


2.4.1.1.2 Mobile Station Traffic Channel Procedures 15



None 18


a. Power on the mobile station and wait until it is in the Mobile station Idle State. 20

b. Create an EMS message at the mobile station, consisting of three (3) segments. 21

c. Instruct the mobile station to send all the segments of the EMS message to the 22

Message Center. 23

d. Verify that the Message Center receives all the segments and sends an SMS 24

Acknowledgement for each segment to the mobile station. 25

e. Verify that upon sending the short message, the mobile station sends a Release Order 26

to release the dedicated channels. 27



3GPP2 C.S0044-D v1.0

8-26

8.5.2 Delivery of Predefined Sound Elements 1


This test verifies the mobile station’s ability to compose and send messages containing 3 predefined EMS sound elements. 4


(see [13]) 6




None 10



b. Create an EMS message at the mobile station. In the message include (1) one 13

predefined sound. 14

c. Instruct the mobile station to send the EMS message to the Message Center. 15

d. Verify the mobile station sends a Data Burst Message to the base station with the fields 16

set as follows: 17

18

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


19

e. Verify that the Message Center receives Data Burst Message and sends the SMS 20

Acknowledgement to the mobile station. 21

f. Verify that the EMS message sent from the test mobile station contains (1) one 22

predefined sound. 23



3GPP2 C.S0044-D v1.0

8-27

8.5.3 Delivery of Predefined Animation Elements 1


This test verifies the mobile station’s ability to compose and send messages containing 3 predefined EMS animation elements. 4


(see [13]) 6




None 10



b. Create an EMS message at the mobile station. In the message include (1) one 13

predefined animation object. 14



set as follows: 17

18

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


19



f. Verify that the EMS message sent from the test mobile station contains the predefined 22

animation object. 23


The mobile station shall comply with steps d and f. The base station shall comply with step e. 25

3GPP2 C.S0044-D v1.0

8-28

8.5.4 Delivery of User Defined Sound Elements 1


This test verifies the mobile’s ability to compose and send a message containing user defined 3 (iMelody) EMS sound elements. 4


(see [13]) 6




None 10



b. Create an EMS message at the mobile station. In the message include (1) one iMelody 13

sound object. 14



set as follows: 17

18

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


19



f. Verify that the EMS message sent from the test mobile station contains the iMelody 22

sound object sent. 23



3GPP2 C.S0044-D v1.0

8-29

8.5.5 Delivery of User Defined Animation Elements 1


This test verifies mobile station’s ability to compose and send a message containing user defined 3 EMS animation elements. 4


(see [13]) 6




None 10



b. Create an EMS message at the mobile station. In the message include one user-13

defined animation object. 14



set as follows: 17

18

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)




f. Verify that the EMS message sent from the test mobile station contains the user-21

defined animation object sent. 22



3GPP2 C.S0044-D v1.0

8-30

8.5.6 Delivery of User Defined Picture Elements 1


This test verifies mobile’s ability to send user-defined EMS picture elements. 3


(see [13]) 5




None 9



b. Create an EMS message at the mobile station. In the message include one user-12

defined picture object. 13



set as follows: 16

17

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


18



f. Verify that the EMS message sent from the test mobile station contains the user-21

defined picture object sent. 22



3GPP2 C.S0044-D v1.0

8-31

8.5.7 Delivery of Formatted Text 1


This test verifies mobile’s ability to compose and send formatted text embedded in EMS 3 messages. 4


(see [13]) 6




None 10



b. Create an EMS message in the mobile station under test. From the following text, 13

include the text with formatting that is supported by the mobile station in the message: 14

15

16

17

18

19

20

21

22

23

24



set as follows 27

28

Normal Bold Italics Bold-Italics

Underlined Bold-Underlined Bold-Italics-Underlined

Left-Justified

Center-Justified

Right-Justified

3GPP2 C.S0044-D v1.0

8-32

Field Value

MSG_NUMBER 1 (‘00000001’)

BURST_TYPE 3 (‘000011’)

NUM_MSGS 1 (‘00000001’)


1



f. Verify that the EMS message sent from the test mobile station contains the properly 4

formatted text information. 5



3GPP2 C.S0044-D v1.0

9-1

9 SUBSCRIBER CALLING FEATURES 1

9.1 Call Forwarding Unconditional (CFU) 2

9.1.1 Definition 3

CFU permits a called subscriber to send incoming calls addressed to the called subscriber’s 4 Directory Number to another Directory Number (forward-to number). If this feature is active, calls 5 are forwarded regardless of the condition of the termination. 6


(see [22]) 8

505 Call Forwarding—Unconditional 9


None 11


a. Power on the mobile station and wait until it reaches Mobile Station Idle State. 13

b. Dial the CFU feature activation code, followed by the forward-to number, followed by 14

SEND. Verify feature update confirmation at the mobile station (confirming audio tones 15

from the network). 16

c. Setup a call from a land party to the mobile station. Verify call is forwarded and that if 17

the Network directs the mobile station to “Ping Ring” it plays a single burst of 500 ms. 18

d. Answer the call on the forward-to line, and verify the audio path. 19

e. End the call. 20

f. Dial the CFU deactivation feature code followed by SEND. Verify feature update 21

confirmation at the mobile station. 22

g. Verify that CFU has been deactivated, by calling the mobile station under test and 23

verifying that the mobile station rings and completes the call when answered. 24


The mobile station and the base station shall comply with steps b, c, d, f and g. 26

9.2 Call Forwarding Busy (CFB) 27

9.2.1 Definition 28

CFB permits a called subscriber to have the system send incoming calls to another Directory 29 Number (forward-to number) when the subscriber is engaged in a call or service. 30


(see [22]) 32

3GPP2 C.S0044-D v1.0

9-2

502 Call Forwarding Busy 1


None 3



b. Dial the CFB activation feature code, followed by the forward-to-number, followed by 6



c. Place the mobile station under test in a voice call. 9

d. Attempt a second call from a land party to the mobile station under test. Verify the call is 10

forwarded to the forward-to-number, and that if the Network directs the mobile station to 11

“Ping Ring” it plays a single burst of 500 ms. 12

e. Answer the call on the forward-to line, and verify the audio path. 13

f. End all calls. 14

g. Dial the CFB deactivation feature code followed by SEND. Verify feature update 15


h. Verify that CFB has been deactivated, e.g. by calling the mobile station under test while 17

busy and verifying that the second call is not forwarded. 18



9.3 Call Forwarding Default (CFD) 21

9.3.1 Definition 22

CFD permits a called subscriber to have the system send incoming calls to another Directory 23 Number (forward-to-number) when the subscriber is engaged in a call, does not respond to 24 paging, does not answer the call within a specified period after being alerted or is otherwise 25 inaccessible. 26


(see [22]) 28

503 Call Forwarding—Default 29


None 31



3GPP2 C.S0044-D v1.0

9-3

b. Dial the CFD activation feature code, followed by the forward-to number, followed by 1



c. Attempt a call from a land party to the mobile station. Verify the call is forwarded and 4

that if the Network directs the mobile station to “Ping Ring” it plays a single burst of 500 5

ms. 6


e. End call. 8

f. Dial the CFD deactivation feature code followed by SEND. Verify feature update 9


g. Verify that CFD has been deactivated, by calling the mobile station under test and 11

verifying that the mobile station rings and does not forward. 12



9.4 Call Forwarding No Answer (CFNA) 15

9.4.1 Definition 16

CFNA permits a called subscriber to have the system send incoming calls addressed to the called 17 subscriber’s Directory Number to another Directory Number (forward-to number) when the 18 subscriber fails to answer. 19


(see [22]) 21

504 Call Forwarding—No Answer 22


None 24



b. Dial the CFNA activation feature code, followed by the forward-to number, followed by 27



c. Setup a call from a land party to the mobile station. Verify the mobile station rings, but 30

when not answered, the call is forwarded to the forward-to number. 31


e. End the call. 33

3GPP2 C.S0044-D v1.0

9-4

f. Dial the CFNA deactivation feature code followed by SEND. Verify feature update 1


g. Verify that CFNA has been deactivated, by calling the mobile station and verifying that 3

the mobile station rings and does not forward. 4



9.5 Three-Way Calling 7

9.5.1 Definition 8

This tests mobile station’s operation of Three-way Calling. In Three-way Calling, the base station 9 responds to Flash With Information Messages from the mobile station to connect a third party to 10 an established two-way call. 11


(see [22]) 13

522 Three Way Calling 14


16

BSMSVoice Traffic in 2-way call

Ack Order

Flash with Info Message

Ack Order


Ack Order


no records

3rd party

number

Connect 3-

way

17



b. Ensure the base station will allow the mobile station to perform Three-way calling via 20

subscriber profile or by dialing a feature activation code such as *31+ SEND. 21

c. Set up a normal two-way voice call with a second party. 22

d. Put the second party on hold using the prescribed method at the mobile station, e.g. 23

send a Flash With Information Message by pressing the SEND button. 24

3GPP2 C.S0044-D v1.0

9-5

e. Verify the second party is placed on hold and the mobile station alerts the user to 1

commence dialing the third party number, e. g. plays a dial tone. 2

f. Dial the third party number on the mobile station and send it out using the prescribed 3

method, e. g. send a Flash With Information Message containing the Keypad Facility 4

Information Record or the Called Party Number Information Record by pressing the 5

SEND button after entering dialed digits. 6

g. Verify the third party phone rings and answers with normal audio. 7

h. Connect all of the Three-Way Call parties, e. g. send a Flash With Information Message 8

by pressing the SEND button, and verify the three-way connection is established with 9

normal audio. 10

i. End the call. 11

j. Ensure the base station will not allow the mobile station to perform Three-way calling 12

via subscriber profile or by dialing a feature de-activation code such as *91+ SEND 13


The mobile station shall comply with the requirements in steps b, e, g, h, and j. 15

9.6 Call Alerting 16

9.6.1 Definition 17

This is a test for standard mobile station incoming call alerting (ringing). An incoming call alert is 18 played or displayed by the mobile station as a result of receiving an Alert With Information 19 Message or an Extended Alert with Information Message with a Signal information record. 20


(see [4]) 22

Table 3.7.5.5-1 Signal Type 23

Table 3.7.5.5-2 Alert Pitches 24

Table 3.7.5.5-3 Tone Signals (SIGNAL_TYPE = ‘00’) 25

Table 3.7.5.5-4 ISDN Alerting (SIGNAL_TYPE = ‘01’) 26

Table 3.7.5.5-5 IS-54B Alerting (SIGNAL_TYPE = ‘10’) 27

Table 3.7.5-1 Information Record Types (base station) 28


30

3GPP2 C.S0044-D v1.0

9-6





Page Message to mobile


Release Order Messages

Connect Order Message

Voice Traffic

Service Connect Complete Message

Alert with Info Message Message (ring for mobile)

MS BS

1


a. Allow the mobile station to come to the idle state on the base station, and make a 3

mobile station terminated call. 4

b. Verify the mobile station receives an Alert with Information Message or Extended Alert 5

with Information Message with a Signal Information record. The Alert with Information 6

Message may or may not contain a Calling Party Number Information record. 7

c. Verify the mobile station rings (plays an incoming call alert). 8

d. Answer the call, verify the call completes successfully, then end the call. 9

e. Steps a through d may be repeated using each variation of parameters in the Signal 10

Information record for SIGNAL_TYPE, ALERT_PITCH, and SIGNAL as supported by 11



The mobile station shall comply with the requirements in step c, d, and e. 14

9.7 Calling Party Number for Mobile station Terminated Call Setup 15

9.7.1 Definition 16

This tests the delivery and display of a Calling Party Number (CPN) during call setup. 17

3GPP2 C.S0044-D v1.0

9-7


(see [4]) 2

3.7.5.3 Calling Party Number 3

Table 2.7.1.3.2.4-2 Number Types 4

Table 2.7.1.3.2.4-3 Numbering Plan Identification 5

Table 2.7.4.4-1 Presentation Indicators 6



None 9


a. Configure the base station to send a Calling Party Number for mobile station terminated 11

calls. 12

b. Allow the mobile station to come to the idle state on the base station, and initiate a 13

mobile station terminated call. 14

c. Verify the mobile station displays the correct Calling Party Number before answering 15

the call and then answer the call. 16

d. Repeat steps b to c for all Calling Party Number base station configurations, e.g. 17

parameters PI = ‘01’ (Presentation Restricted) and PI = ‘10’ (Number not available or 18

Unavailable), as supported by the base station, and verify the correct outcome. 19


The mobile station shall comply with requirements in steps c and d. In step d, for PI = ‘01’ 21 (Presentation Restricted) and PI = ‘10’ (Number not available or Unavailable), the mobile station 22 shall NOT display the Calling Party Number, but may display ‘No Caller ID’ or something to that 23 effect. 24

9.8 Calling Party Number for Call Waiting 25

9.8.1 Definition 26

This tests the delivery and display of a Calling Party Number (CPN) for Call Waiting calls. 27


(see [4]) 29

3.7.5.3 Calling Party Number 30

3.7.5.22 Call Waiting Indicator 31

Table 3.7.5.16-2 Mandatory Control Tags and Display Text Tags 32

Table 2.7.1.3.2.4-2 Number Types 33

3GPP2 C.S0044-D v1.0

9-8

Table 2.7.1.3.2.4-3 Numbering Plan Identification 1




None 5


a. Configure the base station to send a Calling Party Number for Call Waiting calls. 7

b. Set up a mobile station terminated voice call. 8

c. While this voice call is in progress, attempt a second call to the mobile station. 9

d. Verify the mobile station displays the correct Calling Party Number of the Call Waiting 10

caller. 11

e. Repeat steps b to d for all Calling Party Number base station configurations, e. g. CPN 12

parameters PI = ‘01’ (Presentation Restricted) and PI = ‘10’ (Number not available or 13

Unavailable), as supported by the base station, and verify the correct outcome. 14


The mobile station shall comply with requirements in steps d and e. In step e, for PI = ‘01’ 16 (Presentation Restricted) and PI = ‘10’ (Number not available or Unavailable), the mobile station 17 shall NOT display the Caller ID, but may display ‘No Caller ID’ or something to that effect. 18

9.9 Call Waiting 19

9.9.1 Definition 20

This test verifies mobile station call-waiting notification, alerting, and connection with Flash with 21 Information Messages or Extended Flash with Information Messages. It also checks the mobile 22 station ability to activate and deactivate the call-waiting feature on the network. 23


(see [4]) 25

3.7.5.5 Signal 26

Table 2.7.4-1 Information Record Types (mobile station) 27


Table 3.7.5.5-5 IS-54B Alerting (SIGNAL_TYPE = ‘10’) 29



None 32

3GPP2 C.S0044-D v1.0

9-9



b. Activate call waiting, e.g. make a dedicated call *41-SEND, and verify that the mobile 3

station plays or displays a notification that call waiting has been activated, e.g. audio 4

confirmation tones in the earpiece. 5

c. Verify the call-waiting activation call ends without user interaction (Base Station 6

releases the call), and the mobile station returns to the idle state on the base station. 7

d. Set up a voice call with the mobile station. While the first call is in progress, attempt a 8

second mobile station terminated call, and verify that a call-waiting alert is played at the 9

mobile station, e.g. tones in the earpiece. 10

e. Cause the mobile station to accept the second call, e.g. press SEND, and verify the 11

connection to the second caller with normal audio. 12

f. Cause the mobile station to flash back to the first call, e.g. press SEND, and verify the 13

connection to the first caller with normal audio. 14

g. Press END on the mobile station to end the call. Note: in some implementations, if the 15

mobile station subscriber ends a call waiting call while the other party is still waiting, the 16

base station will initiate a mobile station terminated call to re-connect the waiting party. 17

If this is the case, answer the call, then end that call too. 18

h. Deactivate call waiting on the base station, e.g. make a dedicated call *410-SEND, and 19

verify the mobile station plays or displays a notification that call waiting has been 20

disabled, e.g. tones in the earpiece. 21

i. Set up a new call with the mobile station. While the call is in progress, attempt another 22

mobile station terminated call, and verify that no call-waiting alert is played at the mobile 23

station. 24


The mobile station shall comply with the requirements in steps b, c, d, e, f, h, and i. 26

9.10 Voice Mail Message Waiting Notification from the Idle State 27


This test verifies mobile station response to message waiting notification while the mobile station 29 is in the idle state. Notification can be a tone, light, or display and is manufacturer dependent. 30


(see [4]) 32

3.7.5.6 Message Waiting 33

3.7.2.3.2.12 Feature Notification Message 34

(see [22]) 35

5.1.3-A.1 Message Waiting Notification 36

3GPP2 C.S0044-D v1.0

9-10


None 2


a. Power on the mobile station and allow it to come to the idle state on the base station. 4

b. Instruct the base station to send a voice mail message waiting notification, setting the 5

number of voice mail messages waiting to a value less than the maximum number the 6

mobile station can display. 7

c. Verify that any indication on the mobile station of the number of messages waiting 8

reflects the correct value.. 9

d. The mobile station may give an indication of the change in message waiting status. 10

e. Repeat steps b through c for a larger number of voice mail messages waiting. 11

f. Repeat steps b through c for a smaller non-zero number of voice mail messages 12

waiting 13

g. Repeat steps b through c, except in step b, send notification for zero voice mail 14

messages waiting, e. g. to clear the mobile station’s voice mail waiting indicator on the 15

mobile station. 16


The mobile station shall comply with the requirement in step c and may comply with step d. 18

9.11 Voice Mail Message Waiting Notification from the Conversation State 19


This test verifies mobile station’s response to message waiting notification while the mobile 21 station is in the conversation state. 22


(see [4]) 24

3.7.5.6 Message Waiting 25

(see [22]) 26

5.1.3-A.1 Message Waiting Notification 27


None 29


a. Power on the mobile station and allow it to come to the idle state on the base station. 31

b. Set up a call with the mobile station. 32

3GPP2 C.S0044-D v1.0

9-11

c. Instruct the base station to send a voice mail message waiting notification, setting the 1

number of voice mail messages waiting to a value less than the maximum number the 2

mobile station can display. 3

d. Verify that any indication on the mobile station of the number of messages waiting 4

reflects the correct value. 5

e. The mobile station may give an indication of the change in message waiting status. 6

f. Instruct the base station to send a voice mail message waiting notification, setting the 7

number of messages waiting to a value that exceeds the maximum number that can be 8

displayed by the mobile station. 9

g. Verify that any indication on the mobile station of the number of messages waiting 10

displays reflects the maximum number of messages that it can display. 11


The mobile station shall comply with the requirements in steps d and g and may comply with step 13 e. 14

9.12 Calling Party Name Presentation during Call Setup 15


This test will verify that the mobile station in the mobile station idle state properly displays the 17 calling name information contained in an Extended Display Information record. This test is only 18 applicable to mobile stations capable of displaying information sent by the base station.. 19


(see [4]) 21

3.7.5.16 Extended Display, Calling Party Name 22

3.7.5.21 Multiple Character Extended Display 23






None 29


a. Ensure the mobile station has been configured to display Calling Party Name if it is 31

delivered and that the mobile station has not been pre-programmed with calling 32

name/number information (phone book). 33

b. Power on the mobile station and wait until it reaches Mobile Station Idle State. 34

3GPP2 C.S0044-D v1.0

9-12

c. Set up a mobile station terminated call. 1

d. Configure the base station to send a Feature Notification Message, Alert With 2

Information Message, or a Flash With Information Message with an Extended Display 3

information record with DISPLAY_TAG = ‘10001101’ (Calling Party Name) CPN. 4

e. Verify the mobile station receives and displays the information included in the Extended 5

Display Information Record. 6


g. End call. 8


The mobile station shall comply with steps e, and f. 10

9.13 Calling Name Presentation (CNAP) during Conversation State 11


This test will verify that the mobile station in Conversation Substate (with call waiting enabled) 13

properly displays the Calling Party Name. This test is only applicable to mobile stations capable 14 of displaying information sent by the base station.. 15


(see [4]) 17

3.7.5.16 Extended Display, Calling Party Name 18

3.7.5.21 Multiple Character Extended Display 19






None 25


a. Ensure mobile station is assigned Calling Party Name Presentation Class-of-Service, 27

and that the mobile station has not been pre-programmed with calling name/number 28

information (phone book). 29

b. Set up a mobile station originated call. 30

c. While the mobile station is in the Conversation Substate, set up another call to the 31

mobile station (i.e. call waiting). Configure the base station to send an Alert With 32

3GPP2 C.S0044-D v1.0

9-13

Information Message or Flash With Information Message with an Extended Display 1

Information Record with the DISPLAY_TAG = ‘10001101’ (Calling Party Name). 2

d. Verify the mobile station receives and displays the information included in the Extended 3

Display Information Record. 4

e. End both calls. 5



9.14 Display Records sent in the Feature Notification Message. 8

9.14.1 Definition 9

This test verifies that the mobile station displays Paging Channel and Forward Common Control 10 Channel Display Information Records, Extended Display Information Records and Multiple 11 Character Extended Display Records. This test also verifies that Display Information Records, 12 Extended Display Information Records and Multiple Character Extended Display Records do not 13 interfere with any other information records or features. This test is only applicable if the mobile 14 station has a display. 15


(see [4]) 17


2.6.10.1 Alerting 19


3.7.3.3.2.3 Alert with Information Message 21

3.7.3.3.2.14 Flash with Information Message 22



None 25


a. Verify the mobile station is in Idle State. 27

b. Instruct the base station to send a display record with no more than x characters where 28

x is the maximum number of characters supported by the mobile station’s display in a 29

Feature Notification Message on the Paging Channel or Forward Common Control 30

Channel. 31

c. Upon receiving the Feature Notification Message, verify the mobile station displays 32

characters as instructed in the Display Record contained in the Feature Notification 33

Message. 34

3GPP2 C.S0044-D v1.0

9-14

d. Instruct the base station to send a new Display Record of with no more than x 1

characters where x is the maximum number of characters supported by the mobile 2

station’s display in a Feature Notification Message. 3

e. Upon receiving the Feature Notification Message, verify the mobile station displays the 4

new characters as instructed in the Display Record and performs other information 5

records contained in the Feature Notification Message. 6

f. If supported by the mobile station and the base station, repeat steps b to e using the 7

Extended Display Record. 8

g. If supported by the mobile station and the base station, repeat steps b to e using the 9

Multiple Character Extended Display Record. 10


The mobile station shall comply with steps c, e, f and g. 12

9.15 Display Records Sent in the Flash With Information Message 13


This test verifies that the mobile station displays Traffic Channel Display Information Records, 15 Extended Display Information Records and Multiple Character Extended Display Records. This 16 test also verifies that Display Information Records, Extended Display Information Records and 17 Multiple Character Extended Display Records do not interfere with other information records or 18 features. This test is only applicable if the mobile station has a display. 19


(See [4]) 21







None 28


a. Setup a mobile station originated call. 30

b. Instruct the base station to send a Display Record with no more than x characters 31

where x is the maximum number of characters supported by the mobile station’s display 32

in a Flash With Information Message. 33

3GPP2 C.S0044-D v1.0

9-15

c. Upon receiving the Flash With Information Message, verify the mobile station displays 1

characters as instructed in the Display Record contained in the Flash with Information 2

Message. 3

d. Instruct the base station to send a new display record with no more than x characters 4

where x is the maximum number of characters supported by the mobile station’s display 5

contained in the Flash with Information Message. 6

e. Upon receiving the Flash With Information Message, verify the mobile station displays 7

the new characters as instructed in the Display Record. 8

f. If supported by the mobile station and the base station, repeat steps a to e using the 9


g. If supported by the mobile station and the base station, repeat steps a to e using the 11



The verifications in steps c and e in the traffic channel shall be successfully carried out for all 14 forms of display records supported. When various information records are sent to the mobile 15 station in the same message, the mobile station shall properly process all information records. If 16 display records are not supported in the mobile station, there shall be no negative impact on any 17 information records supported by the mobile station. There shall be no negative impact on any 18 supported feature or call processing when display records are sent to the mobile station in the 19 same message as other information records. 20

If supported by the mobile station, the most current display record shall be displayed on the 21 mobile station. 22

9.16 Display Records Sent in the Alert with Information Message 23


This test verifies the mobile station displays Display Information Records, Extended Display 25 Information Records and the Multiple Character Extended Display Record on the traffic channel. 26 This test also verifies that Display Information Records, Extended Display Information Records 27 and Multiple Character Extended Display Record do not interfere with other information records 28 or features. This is only applicable if the mobile station has a display. 29


(See [4]) 31







3GPP2 C.S0044-D v1.0

9-16


None 2


a. Setup a mobile station terminated call. 4

b. Instruct the base station to send in an Alert With Information Message, a Display 5

Record with no more than x characters where x is the maximum number of characters 6

supported by the mobile station’s display, and a Calling Party Number Record. 7

c. Upon receiving the Alert With Information Message, verify the mobile station displays 8

the characters as instructed in the display record or extended display record and 9

displays the Calling Party Number in the Alert With Information Message. 10

d. If supported by the mobile station and the base station, repeat steps a to c using the 11


e. If supported by the mobile station and the base station, repeat steps a to c using the 13



The verifications in step c in the traffic channel shall be successfully carried out for all forms of 16 display records supported. When various information records are sent to the mobile station in the 17 same message, the mobile station shall process all information records. If display records are not 18 supported in the mobile station, there shall be no negative impact on information records 19 supported by the mobile station. There shall be no negative impact on any supported feature, or 20 on call processing when display records are sent to the mobile station in the same message as 21 other information records. 22

If supported by the mobile station, the most current display record shall be displayed on the 23 mobile station. 24

9.17 TTY/TDD 25


This test verifies the system ability to transfer TTY/TDD information in the forward and reverse 27 link directions. 28


(see [18,19 and 20]) 30


None 32


9.17.4.1 Basic TTY/TDD Operation 34

a. Connect the mobile station as shown in Figure 9.18.4-1. 35

3GPP2 C.S0044-D v1.0

9-17

1

MS

TE2M

MTO

MT2Rn

Um BS/MSC

Ai

PSTN TE2LW

Specific Network Entity

Collective (Composite Entity)

Interface Reference Point

KEY

X

2

Figure 9.17.4-1 3

The base station (Base Station) in this model represents the entire system infrastructure. It 4 contains the transceiver equipment and Mobile Switching Center (MSC). 5

Terminal Equipment (TE2) is TTY/TDD equipment connected either directly or indirectly to the 6 Mobile Terminal (MT2) on the mobile station side of the connection. TE2 is TTY/TDD equipment 7 connected to the PSTN on the land side. Subscripts "M" and "L" are added as needed to indicate 8 mobile station side and land side TE2s, respectively. When combined in a single physical entity, 9 TE2 and MT2 functionality is labeled MT0. 10

b. Setup a mobile station originated TTY/TDD call. 11

c. Verify characters typed at TE2M can be viewed at TE2L. Verify characters typed at 12

TE2L can be viewed at TE2M. See Annex E: TTY/TDD Test Examples for Example 13

character text. See Annex E For Example character text. 14

d. Type a character sequence (“AB ”) repeatedly a minimum of 20 times at TE2L 15

e. Verify characters are properly viewed at TE2M. 16

f. Type a character sequence (“AB”) repeatedly a minimum of 20 times at TE2M 17

g. Verify characters are properly viewed at the TE2L. 18

h. Steps b through g may be repeated for all supported radio configurations. 19

i. Repeat steps c through h using mobile station terminated TTY/TDD calls. 20

j. Steps a through i may be repeated using all support baud rates. 21

9.17.4.2 TTY/TDD File Transfer Operation 22

a. Setup the mobile station for TTY/TDD file transfer. 23

b. Transfer the ASCII/Baudot file from TE2M to TE2L. 24

c. Verify the PCER, CCER, and TCER is less than 1%. 25

3GPP2 C.S0044-D v1.0

9-18

d. Transfer the ASCII/Baudot file from TE2L to TE2M. 1

e. Verify the PCER, CCER, and TCER is less than 1%. 2

f. End the TTY/TDD call. 3

g. Steps a through f may be repeated for all supported radio configurations. 4

h. Repeat steps b through g for mobile station terminated calls. 5

i. Steps a through h may be repeated using all support baud rates. 6

9.17.4.3 Voice Carry Over (VCO) and Hearing Carry Over (HCO) Operation 7

a. Configure TE2M for VCO. 8

b. Setup a mobile station originated TTY/TDD call. 9

c. Verify outgoing messages can be spoken and incoming responses can be viewed. 10

d. End the TTY/TDD call. 11

e. Configure TE2M for HCO. 12

f. Setup a mobile station originated TTY/TDD call. 13

g. Verify outgoing messages can be typed and incoming responses can be heard through 14

a TE2M accessory speaker. 15

h. Verify characters typed at TE2M can be viewed at TE2L. 16

i. End the TTY/TDD call. 17


9.17.5.1 Basic TTY/TDD Operation 19

The mobile station shall comply with steps e and g for all tested and supported radio 20 configurations and baud rates for mobile station originated and terminated calls. 21

9.17.5.2 TTY/TDD Operation File Transfer 22

The mobile station shall comply with steps c and e for all tested and supported radio 23 configurations and baud rates for mobile station originated and terminated calls. 24

9.17.5.3 Voice Carry Over (VCO) and Hearing Carry Over (HCO) Operation 25

The mobile station shall comply with steps c, g and h. 26

9.18 WLL Call Waiting Indicator Support 27


This test verifies that a mobile station in a two-way conversation, with call waiting enabled, will 29 receive indicator of waiting calls. This test will verify that the mobile station will send a flash 30 request to connect to the waiting call. This test case is applicable only if WLL is supported. 31

3GPP2 C.S0044-D v1.0

9-19


(see [4]) 2


3.7.5.5 Signal 4



None 7


a. Ensure call waiting is enabled. 9

b. Make a mobile station to land party 1 voice call. Verify audio in both directions. 10

c. Setup a voice call from land party 2 to the mobile station. 11

d. Verify the base station sends a Flash With Information Message or Extended Flash 12

With Information Message with the Call Waiting Indicator Information Record as follows: 13

1. CALL_WAITING_INDICATOR field set to ’1’. 14

e. Press the hook (or FLASH button if available) in the mobile station to put land party 1 15

on hold and to connect to land party 2. Verify that the mobile station sends a Flash With 16

Information Message or an Extended Flash With Information Message to the base 17

station. Verify that no dial tone is generated in the mobile station. 18

f. Verify that voice path is established between the mobile station and land party 2. 19

g. Press the hook (or FLASH button if available) again in the mobile station to put land 20

party 2 on hold, and reconnect the voice path to land party 1. 21

h. Verify the mobile station sends a Flash With Information Message or Extended Flash 22

With Information Message to the base station. 23

i. Verify that voice path is established between the mobile station and land party 1. 24

j. End the call from land party 1. 25

k. Press hook (or FLASH button if available) again in the mobile station. Verify that the 26

mobile station sends a Flash With Information Message or Extended Flash With 27

Information Message to the base station. 28

l. Verify voice path is established between the mobile station and land party 2. 29

m. End the call to land party 2. 30

n. Make a mobile station to land party 1 voice call. Verify audio path is established in both 31

directions. 32

o. Setup a voice call from land party 2 to the mobile station. 33

3GPP2 C.S0044-D v1.0

9-20

p. Verify the base station sends a Flash With Information Message or Extended Flash 1


CALL_WAITING_INDICATOR field set to ’1’. 3

q. Do not answer this call waiting call at the mobile station. 4

r. Disconnect call from land party 2. 5

s. Verify the base station sends a Flash With Information Message or Extended Flash 6


CALL_WAITING_INDICATOR field set to ’0’. 8

t. Press the hook (or FLASH button if available) of the mobile station and verify that a dial 9

tone is generated. 10

u. Press the hook (or FLASH button if available) again and verify that voice path between 11

the mobile station and land party 1 is established. 12

v. End the call to land party 1. 13


The mobile station shall comply with the requirements in the following steps: e, h, i, k, t and u. 15

The base station shall comply with the requirements in the following steps: d, f, j, i, p, s, t and u. 16

The base station shall send a Call Waiting Indicator to the mobile station during a two-way 17 conversation indicating another call is waiting. The mobile station shall be able to switch between 18 land party 1 and land party 2 by sending a flash request. 19

9.19 Answer Holding 20


These tests verify that the mobile station that supports Answer Holding feature can perform the 22 following: 23

a. Activate answer holding when the incoming call is ringing in the Waiting for Mobile 24

Station Answer Substate or in the Conversation Substate 25

b. Deactivate answer holding in the Conversation Substate 26


(see [4]) 28




2.7.2.3.2.33 Extended Flash with Information Message 32

2.7.4.2 Keypad Facility 33

3.6.8.1.2 Waiting for Answer Substate 34

3GPP2 C.S0044-D v1.0

9-21


2

MS BS

Extended Channel Assignment

Message

Service Connect

Message

AWI Message (ringing applied)

Connect

Order

Conversation

Release

Order

Release

Order

Initiate a call

Disconnect the call

Page Response

Message

General Page

Message

Instruct the MS to activiate

Answer Holding

Service Connect Completion

Message

(Extended) Flash with Info (Keypad Facility Info

Record)

Instruct the MS to deactivate

Answer Holding

FWI Message (Call Waiting)

Instruct the MS to activiate

Answer Holding

Instruct the MS to disconnect

the first call and deactivate

Answer Holding


Record)


Record)


Record)

3 4


a. Power on the mobile station and wait until it reaches Idle State. 6

b. Setup a mobile station terminated call from land party 1. 7

c. When the mobile station is ringing and ring back tone is applied to the audio path, 8

instruct the mobile station to answer hold the call. 9

d. Verify the mobile station sends a Flash With Information Message or an Extended Flash 10

With Information Message in assured mode with a Keypad Facility information record 11

with the CHARi field set to a pre-programmed feature code (i.e., Switch Control Code: 12

18*), which indicates Answer Holding. 13

3GPP2 C.S0044-D v1.0

9-22

e. Verify the mobile station sends a Connect Order in assured mode. 1

f. Instruct the mobile station to deactivate the answer holding. 2

g. Verify the mobile station sends a Flash With Information Message or an Extended Flash 3



18*), which indicates Answer Holding. 6



The mobile station shall comply with steps d, e, g and h. 9

9.20 User Selective Call Forwarding 10


These tests verify that the mobile station that supports User Selective Call Forwarding can 12 perform the following in both Waiting for Mobile Station Answer Substate and Conversation 13 Substate: 14

a. Forwarding incoming call to a pre-registered number 15

b. Forwarding incoming call to a number stored in the mobile station 16

c. Forwarding incoming call to network-based voice mail 17


(See [4]) 19




2.7.2.3.2.33 Extended Flash with Information Message 23

2.7.4.2 Keypad Facility 24

3.6.8.1.2 Waiting for Answer Substate 25


None 27


9.20.4.1 User Selective Call Forwarding in the Waiting for Mobile Station Answer Substate 29

a. Power on the mobile station and wait until it reaches Idle State. 30

b. Dial user selective call forwarding feature activation code, followed by the forward-to 31

number, followed by SEND. Verify feature update confirmation at the mobile station. 32

3GPP2 C.S0044-D v1.0

9-23

c. Setup a mobile station terminated call from land party. 1

d. When the mobile station is ringing and ring back tone is applied to the audio path, 2

instruct the mobile station to forward the incoming call to the pre-registered number. 3

e. Verify the mobile station sends a Flash With Information Message or an Extended Flash 4



0*), which indicates User Selective Call Forwarding to a pre-registered number. 7

f. Answer the call on the forwarded line, and verify the audio path. 8

g. End call. 9

h. Ensure the mobile station is in Idle State. 10

i. Setup a mobile station terminated call from land party. 11

j. When the mobile station is ringing and ring back tone is applied to the audio path, 12

instruct the mobile station to forward the incoming call to voice mail. 13

k. Verify the mobile station sends a Flash With Information Message or an Extended Flash 14


with the CHARi field set to a pre-programmed feature code (i.e. Switch Control Code: 16

17*) which indicates User Selective Call Forwarding to voice mail. 17

l. Verify the call is forwarded to voice mail. 18

m. Ensure the mobile station is in Idle State. 19

n. Program a forward-to-number in the mobile station. 20

o. Setup a mobile station terminated call from land party. 21

p. When the mobile station is ringing, and ring back tone is applied to the audio path, 22

instruct the mobile station to forward the incoming call to the number stored in the 23

mobile station. 24

q. Verify the mobile station sends a Flash With Information Message or an Extended Flash 25



16*) plus the forward-to-number stored in the mobile station. 28

r. Answer the call on the forwarded line, and verify the audio path. 29

9.20.4.2 User Selective Call Forwarding while in the Conversation Substate 30

a. Setup a call between mobile station and land party 1 and verify user data in both 31

directions. 32

b. Setup a call from land party 2 to the mobile station. Wait for ring back on land party 2 33

and the call waiting notification on the mobile station. 34

c. Instruct the mobile station to forward the incoming call to the pre-registered number. 35

d. Verify the mobile station sends a Flash With Information Message or an Extended Flash 36


3GPP2 C.S0044-D v1.0

9-24


0*), which indicates User Selective Call Forwarding to a pre-registered number. 2

e. Answer the call on the forwarded line, and verify the audio path. 3

f. End call. 4

g. Setup a call between mobile station and land party 1 and verify user data in both 5

directions. 6

h. Setup a call from land party 2 to the mobile station. Wait for ring back on land party 2 7


i. Instruct the mobile station to forward the incoming call to voice mail. 9

j. Verify the mobile station sends a Flash With Information Message or an Extended Flash 10



17*) which indicates User Selective Call Forwarding to voice mail. 13

k. Verify the call is forwarded to voice mail. 14

l. End call. 15

m. Setup a call between mobile station and land party 1 and verify user data in both 16

directions. 17

n. Setup a call from land party 2 to the mobile station. Wait for ring back on land party 2 18


o. Instruct the mobile station to forward the incoming call to the forward-to-number stored 20

in the mobile station. 21

p. Verify the mobile station sends a Flash With Information Message or an Extended Flash 22



16*) plus the forward-to-number stored in the mobile station. 25

q. Answer the call on the forwarded line, and verify the audio path. 26

r. End call. 27


9.20.5.1 User Selective Call Forwarding in the Waiting for Mobile Station Answer Substate 29

The mobile station shall comply with steps e, k, and q. 30

9.20.5.2 User Selective Call Forwarding while in the Conversation Substate 31

The mobile station shall comply with steps d, j, and p. 32

33

3GPP2 C.S0044-D v1.0

10-1

10 ASYNCHRONOUS DATA AND FAX SERVICES 1

10.1 Send/Receive Fax 2

10.1.1 Definition 3

These tests demonstrate cellular system ability to transmit and receive a medium size fax in a 4 timely manner. A fax call is originated by the mobile station and the test is then repeated using 5 land line origination. The mobile station will send and receive a digital and an analog Fax. 6


(see [15]) 8

A.3 Data Service Options for Spread Spectrum Systems: AT Command Processing and the 9

Rm Interface 10

2.2 Data Service Selection 11

2.2.1 Service Selection for Async Data and Fax Services 12

4.0 AT COMMAND PROCESSING FOR ASYNC DATA AND FAX SERVICES 13

4.3 Service Class 2.0 AT Commands 14

7.3 Facsimile Service Class 2.0 AT Commands 15

A.4 Data Service Options for Spread Spectrum Systems: Async Data and Fax Services 16

2.2 The Application Interface 17

2.5.5 Requirements for Async Data and Fax 18

3.1 Service Option Number 19

3.2 Multiplex Option Interface 20

3.3 Procedures Using Service Option Negotiation 21

3.3.1.1 Mobile Station Requirements 22

3.4.1 Mobile Station Requirements 23

4.1.1 Mobile Origination 24

4.1.2 Mobile Termination 25

4.1.3 Service Option Change to Group-3 Facsimile Service 26

4.2 Connection Release 27

A.7 Data Service Options for Spread Spectrum Systems: Analog Fax Service 28


None 30

3GPP2 C.S0044-D v1.0

10-2


10.1.4.1 Send/Receive Digital Fax 2

a. Prepare a file representing three different ITU standard fax pages for fax transfer. Data 3

Services Annex C lists standard fax pages to be used in the test. Ensure fax pages are 4

pre-scanned and pre-encoded. 5

b. Simultaneously start the transfer timer and the digital fax transfer from TE2M to TE2L. 6

c. At TE2L, wait for the fax call to be completed. Stop the transfer timer. 7

d. Record transfer time. Verify transfer time requirements per Data Services Annex C. 8

e. Repeat the test for the same fax sent from TE2L to TE2M. TE2M will receive a digital 9

fax. 10

f. Verify all faxes shall be successfully transferred. The received fax shall be of good 11

quality and complete. This can be verified by qualitative means (visually scanning the 12

received fax) or by quantitative means, for example, using ITU-T Recommendation 13

E.453 (08/94) Facsimile Image Quality as Corrupted by Transmission Induced Scan 14

Line Errors. 15

10.1.4.2 Send/Receive Analog Fax 16

a. Prepare a file representing three different ITU standard fax pages for fax transfer. Data 17

Services Annex C lists standard fax pages to be used in the test. Ensure fax pages are 18

pre-scanned and pre-encoded. 19

b. Attach an Analog Fax Machine to TE2M. 20

c. Simultaneously start the transfer timer and the analog fax transfer from TE2M to TE2L. 21

d. At TE2L, wait for the fax call to be completed. Stop the transfer timer. 22

e. Record transfer time. Verify transfer time requirements per Data Services Annex C. 23

f. Repeat test for the same fax sent from TE2L to TE2M. TE2M will receive an analog fax. 24

g. Verify all faxes shall be successfully transferred. The received fax shall be of good 25

quality and complete. This can be verified by qualitative means (visually scanning the 26

received fax) or by quantitative means, for example, using ITU-T Recommendation 27

E.453 (08/94) Facsimile Image Quality as Corrupted by Transmission Induced Scan 28

Line Errors. 29

h. Verify each analog fax transfer shall be completed within time denoted in Data Services 30

Annex C. 31


10.1.5.1 Send/Receive Digital Fax 33


3GPP2 C.S0044-D v1.0

10-3

10.1.5.2 Send/Receive Analog Fax 1

The mobile station shall comply with steps e, g, and h. 2

10.2 Upload/Download Binary File 3

10.2.1 Definition 4

This test demonstrates cellular system ability to upload and download an ITU standard fax binary 5 file in a timely manner. The asynchronous data call is originated first by the mobile station. The 6 test is then repeated using land line origination. 7


(see [15]) 9

A.3 Data Service Options for Spread Spectrum Systems: AT Command Processing and the Rm 10

Interface 11



















None 30

3GPP2 C.S0044-D v1.0

10-4


a. Prepare the RAND200.BIN 200,000 byte binary file for transfer (Data Services Annex 2

D). 3

b. Setup a data call from TE2M to TE2L. 4

c. Start transferring the binary file from TE2L to TE2M using Z-modem transfer protocol. 5

Start the transfer timer. 6

d. Stop the transfer timer when the confirmation of transfer completion is received from the 7

far end. 8

e. Record the transfer time. 9

1. Note: Transfer time should exclude call connection delay. 10

f. End the data call. 11

g. Setup a data call from TE2L to TE2M. 12

h. Repeat the test by transferring the file from TE2M to TE2L. 13

i. Verify: 14

1. All files shall be successfully transferred. 15

2. Received files shall be complete and identical in content to the original file. 16

3. Each file transfer shall be completed within time denoted in Data Services Annex 17

D. 18

4. Both the mobile station originated, and land line originated data calls shall be 19

established successfully. 20


The mobile station shall comply with step i. 22

10.3 Simultaneous Two-way File Transfer/Carrier Detect 23


This test demonstrates cellular system ability to simultaneously transfer data in the forward and 25 reverse link direction. This test verifies the base station can transmit changes in the status of 26 Carrier Detect and reflect its status on the Rm interface. 27

Note: Carrier Detect can be monitored by means of a hardware lead, or observed on the 28 application interface. 29


(see [15]) 31

A.3 Data Service Options for Spread Spectrum Systems: AT Command Processingand the 32

Rm Interface 33


3GPP2 C.S0044-D v1.0

10-5


















None 18


a. Prepare the RAND200.ASC 200,000 byte ASCII file for transfer (Data Services Annex 20

D). 21

b. Ensure the Carrier Detect indicator is enabled at TE2M. 22

c. From TE2M, issue the command “AT&C1”, which requests the real-time status of 23

Carrier Detect be maintained on the Rm interface. 24

d. Verify the Carrier Detect indicator is OFF. 25

e. Setup a data call from TE2M to TE2L. Verify that Carrier Detect indicator goes ON, 26

when the base station modem has successfully trained. 27

f. Verify characters typed at TE2M can be viewed at TE2L. Verify characters typed at 28

TE2L can be viewed at TE2M. 29

1. Note: Once the File Capture is turned on, do not type any more characters on 30

the TE2L or the TE2M prior to initiating the file transfer (this is to ensure the 31

captured file is not corrupted by user keystrokes). 32

g. Turn on the File Capture at TE2M. 33

h. Turn on the File Capture at TE2L. 34

3GPP2 C.S0044-D v1.0

10-6

i. Simultaneously start the reverse link transfer timer and at TE2M send the 1

RAND200.ASC file to TE2L by using Raw ASCII protocol. 2

j. While TE2M is sending the file to TE2L, simultaneously start the forward link transfer 3

timer and instruct TE2L to send the same ASCII file to TE2M using a Raw ASCII 4

protocol. 5

1. Note: It is critical these transfers shall substantially overlap. 6

k. As each transfer completes, stop corresponding transfer timer and record transfer time. 7

l. After both transfers are complete, turn off the File Capture at both TE2M and TE2L. 8

m. End call. 9

n. At TE2M, verify that Carrier Detect indicator goes OFF when the call is ended. 10

o. Verify: 11

1. The file shall be successfully transferred in each direction. 12

2. Log files shall be complete and identical in content to the original files. 13

3. Each file transfer shall be completed within time denoted in Data Services Annex 14

D. 15

4. The Carrier Detect generated by the base station shall be accurately depicted on 16

the Rm interface. 17


The mobile station shall comply with steps d, e, f, n, and o. 19

10.4 Compound AT Command, Initialization and Connection Delay 20


This test verifies the base station can properly process a compound command line containing 22 both local and remote commands. This test verifies the mobile station can initialize and connect 23 the service option when the data call is negotiated with the base station, as well as measures 24 connection delay. 25


(see [15]) 27

A.3 Data Service Options for Spread Spectrum Systems: AT Command Processing 28

and the Rm Interface 29

4.2.6 Basic Result Codes 30

Table 4.2.6-1. Result Code Sources 31

4.3.1.2.5 +FMI, +FMM, +FMR 32

4.4.1 General Requirements 33

Table 7.2-1 Extended AT Configuration Commands 34

3GPP2 C.S0044-D v1.0

10-7

Table 7.3.1-1 Fax Parameters 1


None 3


a. Ensure the call is down. 5

b. At TE2M, issue AT command 6

“AT+CXT=1;+FCLASS=2.0;+GMI;+CGMI;+GMM;+CGMM”. This command string 7

requests mobile station manufacturer information, base station modem manufacturer 8

information, mobile station manufacturer model, and base station modem manufacturer 9

model. 10

c. Start the connection delay timer. 11

d. When the result is returned to the mobile station, stop the connection timer. 12

e. Record connection delay time in the test report. 13

f. Verify the response shall be correct in that it contains the information requested in the 14

command, and is followed by result code “OK”. Delay should not exceed ten seconds. 15


The mobile station shall comply with step f. 17

10.5 Escaping to Command Mode 18


This test verifies: 20

a. The MT2 application interface escapes to online command state when the user (or the 21

communications application) issues an escape sequence (such as "+++" with the 22

appropriate guard time). 23

b. The base station returns to online state when the user (or the application) issues the 24

command "ATO". 25


(see [15]) 27

4.2.4 Call-Control Command Processing 28

4.4.2.1 Return to Online Command State 29


None 31

3GPP2 C.S0044-D v1.0

10-8


a. Setup a data call from TE2M to TE2L. 2

b. Verify characters typed at TE2M can be viewed at TE2L. Verify that characters typed at 3


c. From TE2M issue the escape sequence +++. 5

d. Verify “OK” is returned, signifying that the MT2 is in the online command state. 6

e. At TE2M,issue the command “AT+CGMI" which requests base station manufacturer 7

information. Verify the response is appropriate, with trailing “OK”. 8

f. At TE2M, issue the command “ATO”, which should cause the MT2 to transition from 9

online command state to online state. 10

g. Verify characters typed at TE2M can be viewed at TE2L. Verify characters typed at 11



The mobile station shall comply with steps b, d, e and g. 14

10.6 Air Interface Data Compression 15


This test verifies successful compression option negotiation and the transfer of compressible files 17 and/or faxes between the MT2 and Inter-Working Function (IWF). The aforementioned is verified 18 for both mobile station originated and mobile station terminated data and fax transmissions. 19

Note: Although the files are compressible, they will be compressed only when both the MT2 20 and IWF support the type of compression in question. Even if the MT2 or IWF do not support a 21 certain type of compression, the test in question may be performed to ensure MT2 and IWF still 22 interoperate correctly when the user requests this type of compression. 23


(see [15]) 25



Table 7.4.1-1 CDMA AT Parameter Commands 28

A.4 Data Service Options for Spread Spectrum Systems: Async Data and Fax 29

Services 30


Table 2.2-2 Compression Options 32

Table 2.2-3 Group 3 Fax Compression Options 33


None 35

3GPP2 C.S0044-D v1.0

10-9


a. Prepare the data file, COMPFILE.RAW (see Data Services Annex A), or the fax page, 2

FAX 1 (see Data Services Annex C) for transfer. 3

b. Configure the test setup for transfer of a data file or a fax file per Table 10.6.4-1. 4

V.42bis compression for data file transfers is controlled by the +CDS command. The 5

type of compression for fax file transfers is controlled by the +CFC command. When 6

V.42bis is selected for fax transfer, the parameters set in the +CDS command are used. 7

c. Setup a mobile station originated fax or async data call per Table 10.6.4-1. 8

Table 10.6.4-1 9

Test No.

File/Fax Compression Method

Direction of Transfer

Compression Enable

Fax Compression

Mode

1 Data File none BS to MS +CDS=0 N/A

2 Data File V.42bis BS to MS +CDS=2 N/A

3 Data File V.42bis MS to BS +CDS=1 N/A

4 Data File V.42bis MS to BS +CDS=3 N/A

5 Fax File none BS to MS N/A +CFC=0

6 Fax File V.42bis BS to MS +CDS=2 +CFC=1

7 Fax File V.42bis MS to BS +CDS=1 +CFC=1

8 Fax File V.42bis MS to BS +CDS=3 +CFC=1

9 Fax File MMR BS to MS N/A +CFC=2

10 Fax File MMR MS to BS N/A +CFC=2

10

d. Make a file or fax transfer in the direction as stated in Table 10.6.4-1. Time each 11

transfer and record in the test report. 12

e. Testing may be repeated for all test cases, 1 through 10. 13

f. Verify: 14

1. All faxes shall be successfully sent and received. 15

2. The received fax page shall be complete in content, and each transfer shall be 16

completed within the time stated in Data Services Annex C. 17

3. All data files shall be successfully transferred. 18

4. The received files shall be complete and identical in content to the original file. 19

Each file transfer shall be completed within the time stated in Data Services Annex 20

B. 21

3GPP2 C.S0044-D v1.0

10-10



10.7 RLP Operation in a Poor RF Environment 3

10.7.1 Definition 4

This test exercises the Radio Link Protocol (RLP) layer's negative acknowledgments (NAKs), re-5 transmits, RLP aborts, RLP Resets, and FCSs. 6

Test conditions are intended to impose one or more occurrences of the following. 7

a. Single, double, and triple NAK RLP retransmit events. 8

b. RLP Abort 9

c. RLP Reset 10

d. This test verifies that RLP recovers erased data frames in various channel conditions. 11


(see [15]) 13

A.2 Data Service Options for Spread Spectrum Systems: Radio Link Protocol 14

3.1 Non-Transparent RLP Procedures 15

3.1.1.1 Non-Encrypted Mode Initialization/Reset 16

3.1.2 Data Transfer 17

3.1.4 Segmentation of Retransmitted Data Frames 18


None 20


a. Setup the mobile station and base station as shown in Figure A-9with an AWGN 22

generator placed in the forward link. 23

b. Environment Test Parameters 24

c. Adjust the level of the AWGN Generator so that the downlink frame error rate is 25

measured to be 3±1%. 26

d. Restore the RF link to a normal operating condition, maintaining the target frame error 27

rate (1 % or less). 28

e. Prepare RAND200.ASC 200,000 byte ASCII file for transfer (Data Services Annex D). 29

f. Setup a data call from TE2M to TE2L. 30

g. Verify characters typed at TE2M can be viewed at TE2L. Verify characters typed at 31


h. Turn File Capture on. 33

3GPP2 C.S0044-D v1.0

10-11

i. Simultaneously start the forward link transfer timer and at TE2L send the 1

RAND200.ASC file to TE2M by using Raw ASCII protocol. 2

j. As soon as the file transfer has started (and is still in progress), set the channel 3

conditions as calibrated in step b. These channel conditions shall be maintained for the 4

duration of the file transfer. 5

k. Stop the transfer timer and record the transfer time. 6

l. Turn off the File Capture. 7

m. End call. 8

n. Setup a data call from TE2M to TE2L. 9

o. Repeat steps g and h. 10

p. Simultaneously start the reverse link transfer timer and at TE2M send the 11


q. Repeat steps i through m. 13

r. Verify: 14

1. The file shall be successfully transferred. 15

2. The log file shall be complete and identical in content to the original file. 16

3. The transfer rate shall be no less than 70% of rates measured in test 10.3. 17


The mobile station shall comply with steps g and r. 19

10.8 RLP Abort and TCP Retransmit Test 20


This test causes the RLP layer to abort and reset due to extremely severe CDMA channel 22 conditions, and forces the TCP layer to retransmit packets. Channel degradation consists of 23 forcing consecutive frame erasures for periods greater than 2.6 seconds. 24

Note: 2.6 seconds corresponds to 130 consecutive frame erasures, but less than the time that 25 would cause the call to drop (typically 5 seconds). 26


(see [15]) 28

A.2 Data Service Options for Spread Spectrum Systems: Radio Link Protocol 29

3.1 Non-Transparent RLP Procedures 30

3.1.1.1 Non-Encrypted Mode Initialization/Reset 31

3.1.2 Data Transfer 32

3.1.4 Segmentation of Retransmitted Data Frames 33

3GPP2 C.S0044-D v1.0

10-12


None 2


a. Setup the mobile station and base station as shown in Figures Annex A Figure A-7 and 4

Annex A Figure A-8 for the forward and the reverse link tests respectively, with 5

PWR_THRESH_ENABLE and PWR_PERIOD_ENABLE set to 0. Disable forward link 6

power control at the base station. 7

b. Calibrate the test setup so that: 8

c. There is sufficient isolation with the switch open, that a call drops if the switch is left 9

open for more than 5 seconds 10

1. When switch is open, the forward and reverse links are disabled at the receiver. 11

2. When switch is closed, the forward and reverse links are enabled at the receiver. 12

3. Set the RF link to normal operating condition, which maintains the target frame 13

erasure rate (1% or less). 14

d. Prepare the RAND200.ASC 200,000 byte ASCII file transfer (Data Services Annex D) 15

e. Setup a call from TE2M to TE2L. 16

f. Verify characters typed at TE2M can be viewed at TE2L. Verify that characters typed at 17


g. Turn File Capture on. 19

h. Simultaneously start the forward link transfer timer and at TE2L send the 20

RAND200.ASC file to TE2M by using Raw ASCII protocol. 21

i. Once the file transfer has started (and is still in progress), open and close the switch in 22

an alternating fashion, for periods of T1 and T2 where: 23

1. T1 is the period when the switch is open (RF link impaired), and it is anywhere 24

between 2.6 and 5.0 seconds. 25

2. T2 is the period when the switch is closed (RF link restored), and it is a minimum 26

of 10 seconds. 27

j. Repeat opening and closing switch exactly three times while data transfer is occurring. 28

k. Stop the transfer timer and record the transfer time. 29

l. Turn the File Capture off. 30

m. End call. 31

n. Setup a data call from TE2M to TE2L. 32

o. Repeat steps f and g. 33

p. Simultaneously start the reverse link transfer timer and at TE2M send the 34


3GPP2 C.S0044-D v1.0

10-13

q. Repeat steps i through l. 1

r. Verify: 2

1. The file shall be successfully transferred in each direction. 3

2. Log files shall be complete and identical in content to the original files. 4

3. Transfer rates shall be no less than 50% of rates measured in test 10.3. 5


The mobile station shall comply with steps f and r. 7

10.9 Internet Control Message Protocol (ICMP) Requests/Replies 8

10.9.1 Definition 9

This test verifies the mobile station is able to: 10

a. Generate an ICMP Echo Response Message after receiving an Echo Request 11

Message. 12

b. Generate an ICMP Info Response Message after receiving an Info Request Message. 13

c. Generate an ICMP Time Stamp Response Message after receiving a Time Stamp 14

Request Message. 15


(see [23]) 17

RFC-792 Internet Control Message Protocol 18


None 20


a. At TE2M, issue a remote query command such as “AT+CXT=1;+FCLASS=2.0;+FMI?”, 22

requesting base station modem manufacturer information. This will establish a link to 23


b. From the OA&M interface of the base station, issue the Echo Request Message by any 25

method specific to the base station manufacturer. 26

c. Optionally, step b may be repeated for Info Request/Response, or Time Stamp 27

Request/Response Messages. 28

d. Verify: 29

1. Echo response shall be received by base station as a response to Echo Request 30

Message. 31

2. If supported by mobile station, an Info response shall be received by base station 32

as a response to Info Request Message. 33

3GPP2 C.S0044-D v1.0

10-14

3. If supported by mobile station, a Time stamp response shall be received by base 1

station as a response to Time Stamp Request Message. 2



10.10 Reflection of AT Command Parameters 5


This test verifies a representative set of AT parameters can be setup in an IS-707-A call, 7 transferred to the base station at call origination, changed in the online command state, and have 8 their final values read at the mobile station after call completion. Commands tested are ATS10 9 and AT+CQD. 10


(see [15]) 12



4.2.4 Call-Control Command Processing 15

7.4.1 CDMA AT Parameters 16


None 18


a. Issue the following AT commands: ATS10=255 and AT+CQD=0” 20

b. Verify response is “OK” 21

c. Setup a data call from TE2M to TE2L. 22

d. After CONNECT is received, issue the escape sequence (such as ”+++”). 23

e. Verify the response is “OK” 24

f. Issue the following AT commands: ATS10? and AT+CQD?. 25

g. Verify response is: 26

1. 255 27

2. +CQD:0 28

3. OK 29

h. Issue the following AT commands: “ATS10=250 and AT+CQD=100” 30

i. Verify the response is “OK” 31

j. Issue the following AT commands: ATS10? and AT+CQD?. 32

3GPP2 C.S0044-D v1.0

10-15

k. Verify the response is: 1

1. 250 2

2. +CQD: 100 3

3. OK 4

l. Terminate the call via the “ATH0” command string. 5

m. Verify the response is “OK” and that the call ends. 6

n. Issue the following AT commands: ATS10? and AT+CQD 7

o. Verify response is: 8

1. 250 9

2. +CQD: 100 10

3. OK 11

p. Verify the “ERROR” response shall not be returned. 12


The mobile station shall comply with steps b, e, g, i, k, m, o, and p. 14

15

16

3GPP2 C.S0044-D v1.0

10-16


3GPP2 C.S0044-D v1.0

11-1

11 LOW SPEED PACKET DATA 1

11.1 Forward File Transfer 2

11.1.1 Definition 3

This test verifies that file transfer from remote host to mobile station can be successfully done 4 using the LSPD call. 5


(see [15]) 7

1.4.2.2 Mobile Station Packet Data Service States 8

2.2.2 Service and Call Control Procedures 9

2.2.3 Initialization and Connection of Packet Data Service Options 10


None 12



b. At the remote host prepare the RAND200.BIN 200,000 byte binary file for transfer (Data 15

Services Annex D). 16

c. Setup an FTP session using Service Option 7 for Rate Set 1 or Service Option 15 for 17

Rate Set 2 with the remote host. 18

d. Transfer the file from the remote host to the TE2M using the binary “get” command. 19

e. After the file transfer is completed, end the FTP session. Verify the file is successfully 20

transferred. 21

f. Steps b through e may be repeated for other data rates supported by both mobile 22

station and base station. 23



11.2 Reverse File Transfer 26


This test verifies that file transfer from mobile station to remote host can be successfully done 28 using the LSPD call. 29


(see [15]) 31

3GPP2 C.S0044-D v1.0

11-2





None 5



b. At the TE2M, prepare the RAND200.BIN 200,000 byte binary file for transfer (Data 8

Services Annex D). 9



d. Transfer the file from the TE2M to the remote host using the binary “put” command. 12

e. After the file transfer is completed, end the FTP session. Verify the file is successfully 13

transferred. 14

f. Steps b through e may be repeated for other data rates supported by both mobile 15

station and base station. 16



11.3 Bi-directional File Transfer 19


This test verifies that bi-directional file transfer can be successfully done using the LSPD call. 21


(see [15]) 23





None 28



3GPP2 C.S0044-D v1.0

11-3

b. Prepare the RAND200.BIN 200,000 byte binary file for transfer (Data Services Annex 1

D) at both the remote host and TE2M. 2



d. Transfer the file from the TE2M to the remote host. 5

e. Transfer the file from the Remote Host to the TE2M while the transfer in the reverse 6

direction is still proceeding. 7

f. After the file transfers are completed, end the FTP sessions. Verify the files are 8

successfully transferred. 9

g. Steps b through f may be repeated for different data rates that are supported by both 10

mobile station and base station. 11



11.4 Mobile Station Packet Data Inactivity Timer 14


This test is required for mobile stations that shall have a mobile station packet data inactivity 16 timer. This test verifies the mobile station releases the traffic channel after expiration of the 17 mobile station packet data inactivity timer. The test verifies the dormant link layer connection can 18 be re-activated. 19



None 22


a. Set the packet data inactivity timer at the MT2 to 20 seconds. 24

b. Ensure the base station packet data inactivity timer is disabled or set to a value of at 25

least 30 seconds. 26

c. Initiate a Telnet session to a remote host. 27

d. Record the IP address assigned to the mobile station. 28

e. Exit the Telnet session. 29

f. Wait for the mobile station packet data inactivity timer to expire. Verify the “in use” 30

indicator on the MT2 goes OFF. 31

g. Initiate a Telnet session to a remote host. 32

h. Record the IP address assigned to the mobile station. 33

3GPP2 C.S0044-D v1.0

11-4

i. Wait for the mobile station packet data inactivity timer to expire. Verify the “in use” 1


j. Issue a “ping” command from the remote host to the mobile station using the IP address 3

assigned to the mobile station. 4


The mobile station shall comply with steps f and i. 6

3GPP2 C.S0044-D v1.0

12-1

12 MEDIUM SPEED PACKET DATA 1

12.1 Forward File Transfer with Fundamental and Supplemental Code Channels 2

12.1.1 Definition 3

This test verifies the functionality of forward MSPD calls for various MUX options: 4

• No Supplemental Code Channels allocated (Test 1). 5

• One Supplemental Code Channel allocated (Test 2). 6

• N Supplemental Code Channels allocated, where N is the maximum number of 7

Supplemental Code Channels that can be supported by the system (Test 3). 8


(see [2]) 10

2.2.1.1.1.1.1 The Multiplex Sublayer 11

(see [4]) 12

3.6.6.2.2.9 Processing the Supplemental Channel Assignment Message 13

3.6.6.2.2.10 Processing the General Handoff Direction Message 14

(see [15]) 15

A-9; 2.2.2.1.1 Packet Data Service Control Procedures 16


None 18


a. Prepare a file at the remote host for file transfer (see Annex D). 20

b. Setup an FTP session using Service Option 22 with the remote host. From the base 21

station, generate a General Handoff Direction Message or a Supplemental Channel 22

Assignment Message to allocate Supplemental Code Channels to the mobile station 23

according to the following conditions: 24

1) For Test 1, the base station shall allocate no Supplemental Code 25

Channel to the mobile station (i.e. MUX Option = 1). 26

2) For Test 2, the base station shall allocate one Supplemental Code 27

Channel to the mobile station (i.e. MUX Option = 3). 28

3) For Test 3, the base station shall allocate N Supplemental Code 29

Channels to the mobile station (i.e. MUX Option = 2N+1). 30

c. Transfer the file from the remote host to the TE2M using the binary “get” command. 31

d. Verify the file is successfully transferred. 32

e. After the file transfer is completed, end the FTP session 33

3GPP2 C.S0044-D v1.0

12-2

f. Repeat steps b through e for Tests 2 and 3. 1

g. Repeat steps b through f for Tests 1, 2, and 3 with Service Option 25. 2


Verify step d for all test cases. 4

12.2 Forward File Transfer with Variable Supplemental Code Channels 5

12.2.1 Definition 6

This test verifies the capability to transfer files from a remote host using FTP, with a variable 7 number of Supplemental Code Channels. This test is intended to exercise bursty data transfer 8 with variable peak transfer rates. 9

This test may require the use of an OA&M interface on the base station, or any other method 10 specific to the base station manufacturer, in order to vary the number of allocated Supplemental 11 Code Channels. 12


(see [2]) 14

2.2.1.1.1 The Multiplex Sublayer 15

(see [4]) 16



(see [15]) 19

A-9; 2.2.2.1.1 Packet Data Service Control Procedures 20


None 22


a. Prepare a file at the remote host for file transfer (see Annex D). 24

b. Configure the mobile station’s maximum forward Supplemental Code Channels to N. 25

c. Configure the base station to support N Supplemental Code Channels. 26

d. Setup a mobile station originated call with Service Option 22, and establish an FTP 27

session. 28

e. From the base station, generate a General Handoff Direction Message to allocate N 29

Supplemental Code Channels to the mobile station. 30

f. Verify from the mobile station that N Supplemental Code Channels are being used. 31

g. Transfer the file from the remote host to TE2M using the binary “get” command. 32

3GPP2 C.S0044-D v1.0

12-3

h. During through the file transfer, configure the base station to generate a General 1

Handoff Direction Message or a Supplemental Channel Assignment Message to reduce 2

the number of Supplemental Code Channels allocated to the mobile station. 3

i. Verify the file is successfully transferred. 4

j. End FTP session. 5

k. Repeat steps d through j with Service Option 25. 6


Verify steps f and i for all test cases. 8

12.3 MSPD Call Setup, No Negotiation 9


This test verifies that the base station and the mobile station can successfully establish mobile 11 station-originated and mobile station-terminated calls using all combinations of supported Service 12 Option 22 and Service Option 25, using the default multiplex options. 13


(see [15]) 15

A9; 2.2.2.1.2.5 Dormant/Idle State 16

(see [2]) 17



None 20


a. Prepare a file at both the remote host and the TE2M (see Annex D). 22

b. Configure the mobile station’s forward MUX Option to (2N+1) where N is the maximum 23

number of Supplemental Code Channels. 24

c. Configure the base station’s MUX Option to a value equal to (2N+1). 25


session with the remote host. 27

e. Verify the call is completed with Service Option 22. 28

f. Verify that N Supplemental Code Channels are being used by the mobile station. 29

g. Transfer the file from remote host to TE2M using the binary “get” command and verify the 30

file is successfully transferred. 31

h. After the file transfer is completed in step f, transfer the file from the TE2M to the remote 32

host using the binary “put” command and verify the file is successfully transferred. 33

3GPP2 C.S0044-D v1.0

12-4

i. End FTP session. 1

j. Configure the base station’s MUX Option to a value equal to (2N+2). 2

k. Setup a mobile station originated call with Service Option 25, and establish an FTP 3


l. Verify the call is completed with Service Option 25. 5

m. Verify that N Supplemental Code Channels are being used by the mobile station. 6

n. Transfer the file from remote host to TE2M using the binary “get” command and verify the 7

file is successfully transferred. 8

o. After the file transfer is completed in step o, transfer the file from the TE2M to the remote 9


p. End the FTP session. 11


The mobile station shall comply with steps e, f, g, h, l, m, n and o. 13

12.4 MSPD Call Setup, Negotiation to a Different MSPD Service Option 14


This test verifies that the base station and the mobile station can successfully negotiate from 16 Service Option 22 to Service Option 25, and vice versa. 17


(see [15]) 19


(see [2]) 21



None 24



b. Configure the mobile station’s forward MUX Option to the default MUX Option. 27

c. Configure the base station’s Service Option to 25 and configure the base station’s MUX 28

Option to a value equal to or greater than the mobile station’s MUX Option number. 29

d. Setup a mobile station originated call using Service Option 22, and establish an FTP 30


e. Verify the call is negotiated to Service Option 25. 32

3GPP2 C.S0044-D v1.0

12-5

f. Transfer the file from the remote host to TE2M using the binary “get” command and verify 1

the file is successfully transferred. 2

g. After the file transfer is completed in step f, transfer the file from the TE2M to the remote 3


h. End FTP session. 5

i. Configure the base station’s Service Option to 22. 6

j. Setup a mobile station originated call using Service Option 25 and establish an FTP 7


k. Verify the call is negotiated to Service Option 22. 9

l. Transfer the file from the remote host to TE2M using the binary “get” command and verify 10


m. After the file transfer is completed in step l, transfer the file from the TE2M to the remote 12


n. End FTP session. 14


The mobile station shall comply with steps e, f, g, k, l and m. 16

12.5 MSPD Call Setup, Negotiation to LSPD 17


This test verifies that the base station and the mobile station can successfully negotiate from 19 MSPD to LSPD service options. 20


(see [15]) 22


(see [2]) 24



None 27


12.5.4.1 MSPD-Capable Mobile station 29


b. Configure the base station to Service Option 7. 31

c. Setup a mobile station originated call with Service Option 22, and establish an FTP 32


3GPP2 C.S0044-D v1.0

12-6

d. Verify the call is completed with Service Option 7. 1

e. Successively transfer files both directions and verify the files are successfully transferred. 2

f. End FTP session. 3

g. Configure the base station to Service Option 15. 4

h. Setup a mobile station originated call with Service Option 22, and establish an FTP 5


i. Verify the call is completed with Service Option 15. 7

j. Successively transfer files in both directions and verify the files are successfully 8

transferred. 9

k. End FTP session. 10

l. Configure the base station to Service Option 15. 11

m. Setup a mobile station originated call with Service Option 25, and establish an FTP 12


n. Verify the call is completed with Service Option 15. 14

o. Successively transfer files in both directions and verify the files are successfully 15

transferred. 16

p. End FTP session. 17

q. Configure the base station to Service Option 7 18

r. Setup a mobile station originated call with Service Option 25, and establish an FTP 19


s. Verify the call is completed with Service Option 7. 21

t. Successively transfer files in both directions and verify the files are successfully 22

transferred. 23

u. End FTP session. 24

12.5.4.2 Non MSPD-Capable Mobile station 25

a. Ensure the mobile station is not MDR capable. 26

b. Prepare a file at both the remote host and the TE2M. 27

c. Configure the mobile station with Service Option 15. This can be accomplished by issuing 28

the AT command AT+CMUX=2,2. 29

d. Configure the base station to page the mobile station with Service Option 22. 30

e. Set up a mobile station terminated call and establish an FTP session. 31

f. Verify the call is completed with Service Option 15. 32

g. Successively transfer files in both directions and verify the files are successfully 33

transferred. 34

3GPP2 C.S0044-D v1.0

12-7


i. Configure the base station Service Option to 25. 2

j. Set up a mobile station terminated call and establish an FTP session. 3

k. Verify the call is completed with Service Option 15. 4

l. Successively transfer files in both directions and verify the files are successfully 5

transferred. 6

m. End FTP session. 7


In section 12.5.3.1, the mobile station shall comply with steps d, e, i, j, n, o, s and t. 9

In section 12.5.3.2, the mobile station shall comply with steps f, g, k and l. 10

12.6 MSPD Call Setup, Mobile Station Maximum Multiplex Option Less than Base Station 11

Maximum Multiplex Option 12


This test verifies that an MSPD call can be successfully established when the maximum multiplex 14 option supported by the mobile station is less than the maximum multiplex option supported by 15 the base station. 16


(see [15]) 18


A3; 7.4.1 CDMA AT Parameters 20

(see [2]) 21



None 24



b. Configure the mobile station’s maximum forward MUX Option to (2n+1) where n is equal 27

to N or 6, whichever is smaller, where N is the maximum number of Supplemental Code 28

Channels supported by the mobile station (i.e. set AT+CMUX=2n+1,1) 29

c. Configure the base station’s MUX Option to a value equal to (2(n+1)+1). 30


session. 32

e. Verify the number of Supplemental Code Channels used to establish FTP session is n. 33

3GPP2 C.S0044-D v1.0

12-8




host using the binary “put” command verify the file is successfully transferred. 4


i. Repeat steps d through h with Service Option 25 by setting the maximum forward MUX 6

Option of the mobile station to (2n+2) and the MUX Option of the base station to 7

(2(n+1)+2). 8


The mobile station shall comply with steps e, f and g for all test cases. 10

12.7 MSPD Call Setup, Mobile station Maximum Multiplex Option Greater than Base 11

Station Maximum Multiplex Option 12


This test verifies that an MSPD call can be successfully established when the maximum multiplex 14 option supported by the mobile station is greater than the maximum multiplex option supported by 15 the base station. 16


(see [15]) 18



(see [2]) 21



None 24



b. Configure the mobile station’s maximum forward MUX Option to (2N+1) where N is the 27

maximum number of Supplemental Code Channels supported by the mobile station (i.e. 28

set AT+CMUX=2N+1,1) 29

c. Configure the base station’s MUX Option to a value equal to (2(N-1)+1). 30


session. 32

e. Verify the number of Supplemental Code Channels used in establishing the FTP session 33

is (N-1). 34

3GPP2 C.S0044-D v1.0

12-9






i. Repeat steps d through h with Service Option 25 by setting the maximum forward MUX 6

Option of the mobile station to (2N+2) and MUX Option of the base station to (2(N-1)+2). 7


The mobile station shall comply with steps e, f and g for all test cases. 9

12.8 Allocation/De-allocation of Supplemental Code Channels 10


This test verifies allocation and de-allocation of up to N Supplemental Code Channels using the 12 General Handoff Direction Message (GHDM), and Supplemental Code Channel Assignment 13 Message (SCAM). N is the maximum number of forward Supplemental Code Channels that can 14 be supported by the system. The first test uses n Supplemental Code Channels, where n is any 15 number greater than zero and less than the maximum N. The second test uses the maximum N 16 Supplemental Code Channels. This test also exercises all supported values of the 17 FOR_SUP_CONFIG and USE_FOR_DURATION fields. 18


(see [2]) 20


(see [4]) 22



(see [15]) 25

A9; 2.2.2.1.1 Packet Data Service Control Procedures 26


None 28


12.8.4.1 Allocation and De-Allocation of n Supplemental Code Channels using GHDM 30

a. Prepare a file at the remote host (see Annex D). 31




3GPP2 C.S0044-D v1.0

12-10


session. 2

d. Verify only the forward Fundamental Code Channel is used in establishing the FTP 3

session. 4

e. Configure the base station to send a General Handoff Direction Message with 5

FOR_INCLUDED=1, FOR_SUP_CONFIG=3, USE_FOR_DURATION=0 and assign n 6

forward Supplemental Code Channels (where n < N and n > 0) to the mobile station. 7

f. Verify that n Supplemental Code Channels are being used by the mobile station. 8

g. Transfer the file from the remote host to TE2M using the binary “get” command and verify 9


h. Configure the base station to send a General Handoff Direction Message with 11

FOR_INCLUDED=1, FOR_SUP_CONFIG=3, USE_FOR_DURATION=0 and assign 0 12

forward Supplemental Code Channels to the mobile station. 13

i. Verify that no Supplemental Code Channel is used by the mobile station. 14

j. Transfer the file from the remote host to TE2M using the binary “get” command and verify 15



l. Repeat steps c through k using Service Option 25. 18

12.8.4.2 Allocation and De-Allocation of N Supplemental Code Channels using SCAM 19

a. Prepare the RAND200.BIN byte binary file at the remote host. 20





session. 25

d. Verify that only the forward Fundamental Code Channel is used in establishing the FTP 26

session. 27

e. Configure the base station to send a Supplemental Code Channel Assignment Message 28

with FOR_INCLUDED=1, FOR_SUP_CONFIG=3, USE_FOR_DURATION=0, 29

USE_FOR_HDM_SEQ=0 and assign N forward Supplemental Code Channels to the 30

mobile station. 31

f. Verify that N Supplemental Code Channels are used by the mobile station. 32

g. Transfer the file from the remote host to TE2M using the binary “get” command and verify 33


h. Configure the base station to send a Supplemental Code Channel Assignment Message 35

with FOR_INCLUDED=1, FOR_SUP_CONFIG=3, USE_FOR_DURATION=0, 36

USE_FOR_HDM_SEQ=0 and assign 0 forward Supplemental Code Channels to the 37

mobile station. 38

3GPP2 C.S0044-D v1.0

12-11

i. Verify the number of Supplemental Code Channels used by the mobile station. 1

j. Transfer the file from the remote host to TE2M using the binary “get” command and verify 2



l. Repeat steps c through k using Service Option 25. 5


For section 12.8.3.1, the mobile station shall comply with steps d, f, g, I, j and l. 7

For section 12.8.3.2, the mobile station shall comply with steps d, f, g, I, j and l. 8

12.9 No Transmission on Supplemental Code Channels 9


This test verifies that data transfer is not interrupted if the base station stops transmitting on one 11 or more allocated Supplemental Code Channels. Note that if the base station does not allow a 12 Supplemental Code Channel to remain idle when there is no data to be transmitted on the 13 Supplemental Code Channel, this test may require the use of an OA&M interface on the base 14 station or some other method specific to the base-station manufacturer. 15


(see [2]) 17


(see [4]) 19



(see [15]) 22



None 25



b. Configure the mobile station’s maximum forward MUX Option to 5 or greater. 28


session. 30

d. Configure the base station to send a General Handoff Direction Message or a 31

Supplemental Code Channel Assignment Message with FOR_INCLUDED=1, 32

FOR_SUP_CONFIG=3, USE_FOR_DURATION=0, USE_FOR_HDM_SEQ=0 and assign 33

2 forward Supplemental Code Channels to the mobile station. 34

e. Verify the MUX Option used in establishing the FTP session. 35

3GPP2 C.S0044-D v1.0

12-12



g. Configure the base station to send data on the Fundamental Code Channel only while 3

the 2 Supplemental Code Channels are still active. 4

h. Transfer the file from the remote host to TE2M using the binary “get” command and verify 5


i. End FTP session. 7

j. Repeat steps c through i with Service Option 25. 8

9


The mobile station shall comply with steps e, f and h for all test cases. 11

12.10 Soft Handoff with Supplemental Code Channels 12


This test verifies that the fundamental and Supplemental Code Channels can be put in two-way 14 soft handoff during an MSPD call with N Supplemental Code Channels active, where N is the 15 maximum number of Forward Supplemental Code Channels that can be supported by the 16 system. This test includes the following cases: 17

Fundamental Code Channel and Supplemental Code Channels in handoff, two cells transmit 18 Supplemental Code Channels. 19

Fundamental Code Channel in handoff, only one cell transmits Supplemental Code Channels. 20


(see [2]) 22


(see [4]) 24



(see [15]) 27



None 30



3GPP2 C.S0044-D v1.0

12-13


maximum number of forward Supplemental Code Channels available for the mobile 2

station. 3

c. Configure each base station to support N Supplemental Code Channels. 4


session with base station 1. 6

e. Configure the base station to set up N Forward Supplemental Code Channels in traffic 7

state. 8

f. Begin transferring the file from the remote host to TE2M using the binary “get” command. 9

g. While the file is being transferred, adjust the signal strength of base station 2 until both 10

base stations have equal transmit power. 11

h. Generate a General Handoff Direction Message for two-way soft-handoff with base 12

station 2. In both test cases 1 and 2, generate the GHDM with FOR_INCLUDED=1, 13

FOR_SUP_CONFIG=3, NUM_FOR_SUP=N, and USE_FOR_DURATION=0. 14

i. For Test 1: In the GHDM, set the FOR_SUP_INCLUDED=1 for each pilot to be included 15

in handoff and configure both base stations to send data on all Supplemental Code 16

Channels. 17

j. For Test 2: In the GHDM, set the FOR_SUP_INCLUDED=1 for base station 1 and 18

FOR_SUP_INCLUDED=0 for base station 2. Configure base station 1 to transmit data on 19

all Supplemental Code Channels. Configure base station 2 to transmit data on the 20

Fundamental Code Channel only. 21

k. Verify the file transfer continues after the handoff and data is successfully transferred. 22

l. End FTP session. 23

m. Repeat steps d through l with Service Option 25. 24


The mobile station shall comply with step k for all test cases. 26

12.11 Adding Supplemental Code Channels during Soft Handoff 27


This test verifies that N Supplemental Code Channels can be added in an MSPD call while in 29 two-way soft handoff on the Fundamental Code Channel, where N is the maximum number of 30 Supplemental Code Channels that can be supported by the system. This test includes the 31 following cases: 32

• N Supplemental Code Channels added on all cells. 33

• N Supplemental Code Channels added on one cell only. 34

3GPP2 C.S0044-D v1.0

12-14


(see [2]) 2


(see [4]) 4



(see [15]) 7



None 10




c. Configure each base station to support N Supplemental Code Channels. 14


session with base station 1 on the Fundamental Code Channel only. 16

e. Adjust the signal strength of base station 2 until both base stations have equal transmit 17

power. 18

f. Verify the mobile station is in two-way handoff. 19

g. Begin transferring the file from the remote host to TE2M using the binary “get” command. 20

h. Generate a General Handoff Direction Message or a Supplemental Channel Assignment 21

Message with FOR_INCLUDED=1, FOR_SUP_CONFIG=3, NUM_FOR_SUP=N, and 22

USE_FOR_DURATION=0. 23

i. For Test Case 1: In the GHDM, set the FOR_SUP_INCLUDED=1 for each pilot to be 24

included in handoff and configure both base stations to send data on all Supplemental 25

Code Channels. 26

j. For Test Case 2: In the GHDM, set the FOR_SUP_INCLUDED=1 for base station 1 and 27

FOR_SUP_INCLUDED=0 for base station 2. Configure base station 1 to transmit data on 28

all Supplemental Code Channels. Configure base station 2 to transmit data on the 29

Fundamental Code Channel only. 30

k. Verify the file transfer continues after Supplemental Code Channel assignment during 31

handoff and the file is transferred successfully. 32



3GPP2 C.S0044-D v1.0

12-15


The mobile station shall comply with steps f and k for all test cases. 2

12.12 Hard Handoff to an MSPD-Capable System 3


This test verifies hard handoff within the same P_REV system as well as hard handoff to a higher 5 P_REV system. 6


(see [2]) 8


(see [4]) 10



(see [15]) 13



None 16


12.12.4.1 Hard Handoff to Same P_REV 18


b. Make sure the MOB_P_REV=4 or higher. 20

c. Base station 1 should be configured for P_REV=5 or higher. 21

d. Base station 2 should be configured for P_REV=5 or higher with a different frequency 22

channel from base station 1. 23

e. Configure the mobile station’s maximum forward Supplemental Code Channels to N. 24

f. Configure both base stations to support N Supplemental Code Channels. 25

g. Setup a mobile station originated call with Service Option 22 and establish an FTP 26

session with base station 1 with N Supplemental Code Channels. 27

h. Begin transferring the file from the remote host to TE2M using the binary “get” command. 28

i. While the file is being transferred, adjust the signal strength of base station 2 until both 29


j. At base station 1, setup a hard handoff to base station 2 using the Extended Handoff 31

Direction Message. 32

3GPP2 C.S0044-D v1.0

12-16

k. Verify the hard handoff is successful and that only the Fundamental Channel is active. 1

l. Verify that base station 2 generates a General Handoff Direction Message or a 2

Supplemental Channel Assignment Message to assign N Supplemental Code Channels 3

to the mobile station. 4

m. Verify at the base station that service negotiation is successful and that the mobile station 5

is using Service Option 22 with N Supplemental Code Channels. 6

n. Verify the file transfer continues after the hard handoff and the file is transferred 7

successfully. 8

o. End FTP session. 9

p. Repeat steps g through o with Service Option 25. 10

12.12.4.2 Hard Handoff to Higher P_REV 11


b. Make sure the MOB_P_REV=4 or higher. 13

c. Base station 1 should be configured for P_REV=3. 14

d. Base station 2 should be configured for P_REV=5 or higher with a different frequency 15

channel from base station 1. 16

e. Configure the mobile station’s maximum forward Supplemental Code Channels to N. 17

f. Configure base station 2 to support N Supplemental Code Channels. 18

g. Setup a mobile station originated call with Service Option 7 and establish an FTP session 19

with base station 1 20

h. Verify that Service Option 7 is in use and only the Fundamental Code Channel is active. 21

i. Begin transferring the file from the remote host to TE2M using the binary “get” command. 22

j. While the file is being transferred, adjust the signal strength of base station 2 until both 23


k. At base station 1, setup a hard handoff to base station 2 using the Extended Handoff 25

Direction Message. 26

l. Verify the hard handoff is successful. 27

m. Verify at the mobile station that Service Option 7 is still in use. 28

n. Verify the file transfer continues after the hard handoff and the file is transferred 29

successfully. 30


p. Repeat steps g through n with Service Option 15. 32


For section 12.12.3.1, the mobile station and the base station shall comply with steps k, l, m, n 34 and p. 35

3GPP2 C.S0044-D v1.0

12-17

For section 12.12.3.2, the mobile station and the base station shall comply with steps h, l, m, n 1 and p. 2

12.13 Bi-Directional File Transfers with Forward Supplemental Code Channels 3


This test verifies the capability to transfer files simultaneously on the Forward and Reverse Traffic 5 Channels between the mobile station and remote host using FTP, with forward Supplemental 6 Code Channels active. 7


(see [2]) 9


(see [4]) 11



(see [15]) 14



None 17





d. Setup a mobile station originated call with Service Option 22. 22

e. Establish two FTP sessions with the base station; one for the forward link and one for the 23

reverse link. 24

f. From the base station, generate a General Handoff Direction Message or a Supplemental 25

Channel Assignment Message to allocate N Supplemental Code Channels to the mobile 26

station. 27

g. Verify from the mobile station that N forward Supplemental Code Channels are being 28

used. The reverse link should be connected with the Fundamental Code Channel only. 29

h. Begin transferring the file from the remote host to TE2M using the binary “get” command. 30

i. While the file is being transferred on the forward link, begin transferring another file from 31

TE2M to the remote host on the reverse link using the binary “put” command. 32

j. Verify that both files are transferred successfully. 33

k. End two FTP sessions. 34

3GPP2 C.S0044-D v1.0

12-18

l. Repeat steps d through l with Service Option 25. 1


The mobile station and the base station shall comply with steps g and j for all test cases. 3

12.14 Rм Interface Flow Control 4


This test verifies flow control on the Rm Interface, when the Um interface data rate exceeds the Rm 6 interface baud rate. 7


(see [2]) 9


(see [4]) 11



(see [15]) 14



None 17



b. Configure the mobile station’s maximum forward Supplemental Code Channels to N (N > 20

4 for Service Option 22, N > 3 for Service Option 25). 21


d. Configure the RS-232 baud rate in the Rm interface to 4800 bps. 23

e. Setup a mobile station originated call with Service Option 22, and establish an FTP 24

session. 25



station. 28

g. Verify at the mobile station that N Supplemental Code Channels are in use. 29

h. Transfer the file from the remote host to TE2M using the binary “get” command. 30

i. Verify the file is transferred successfully. 31

j. End FTP session. 32

3GPP2 C.S0044-D v1.0

12-19

k. Repeat steps e through j with Service Option 25. 1


The mobile station shall comply with steps g and i for all test cases. 3

12.15 Dormant Timer 4


This test verifies the mobile station correctly processes the Service Option Control Message 6 which controls the Dormant Timer, and that the mobile station delays any attempt to send an 7 Origination Message requesting a MSPD service option until the Dormant Timer expires. 8


(see [4]) 10


(see [15]) 12




None 16




c. Configure the mobile station’s inactivity timer to 20 seconds by issuing the AT command 20

AT+CTA=20. 21

d. Configure the base station to support N Supplemental Code Channels. 22


session. 24



station. 27

g. From the base station, send the Service Option Control Message with the Packet Data 28

Dormant Timer set to 20 seconds. 29

h. Verify from the mobile station that N Supplemental Code Channels are being used. 30

i. Transfer the file from the remote host to TE2M using the binary “get” command and verify 31

the file is transferred successfully. 32

3GPP2 C.S0044-D v1.0

12-20

j. Wait for the packet data service call control function to enter the Dormant State due to 1

data inactivity (i.e. when the inactivity timer in the mobile station expires). 2

k. Setup a mobile station originated call with Service Option 22, and establish an FTP 3

session as soon as the packet data service call control function is in the Dormant State 4

mode. The time elapsed between the Release Order and the Origination Message should 5

be approximately 20 seconds. 6

l. After the call is re-established, transfer the file from the remote host to TE2M using the 7

binary “get” command and verify the file is transferred successfully. 8

m. End FTP session. 9

n. Repeat steps e through m with Service Option 25. 10


The mobile station shall comply with steps h, i and l. 12

12.16 Packet Zone ID 13


This test verifies the following: 15

When the mobile station detects a change in the Packet Zone ID in the Extended System 16 Parameters Message and the new Packet Zone ID is not in the Packet Zone ID List the mobile 17 station shall attempt to reconnect the packet data service option. 18

While the data is being transferred and the base station sends a new Packet Zone ID to the 19 mobile station in the Service Option Control Message, the mobile station shall continue to transfer 20 files in the new Packet Zone ID. 21

When the Dormant Timer is running and hasnot expired, the mobile station shall not re-originate a 22 data call. 23

24


(see [4]) 26


(see [15]) 28


A9; 2.2.2.1.2.6 Dormant/Traffic State 30


None 32


12.16.4.1 Mobile Station Idle State 34


3GPP2 C.S0044-D v1.0

12-21



d. Configure the mobile station’s inactivity timer to 20 seconds by issuing an AT command. 3


session 5



station. 8

g. Instruct the base station to send the Service Option Control Message to the mobile 9

station to enable the PACKET_ZONE_ID with a valid list of PACKET_ZONE_Ids. Specify 10

the number of packet data service identifiers that the mobile station is to retain in its 11

packet data zone identifiers list (the number shall be set to 2 or greater). Also set the 12

Packet Data Dormant Timer to 20 seconds. 13

h. Verify from the mobile station that N Supplemental Code Channels are being used. 14

i. Transfer the file from the remote host to TE2M using the binary “get” command. 15

j. Make sure there is no data to transmit for 20 seconds. 16

k. Verify the packet data service call control function enters the Dormant State and the 17

mobile station enters the Mobile Station Idle State due to data inactivity. 18

l. Change the PACKET_ZONE_ID of the serving system in the Extended System 19

Parameter Message. 20

m. Verify the mobile station reconnects to the same Service Option when it detects the new 21

PACKET_ZONE_ID. 22

n. After the call is re-established, transfer the file from the remote host to TE2M using the 23

binary “get” command and verify the file is transferred successfully. 24


p. Repeat steps e through o with Service Option 25. 26

q. Repeat steps a through f. 27

r. Instruct the base station to send the Service Option Control Message to the mobile 28

station to set the Dormant Timer to the maximum value. 29

s. Repeat steps j through k. 30

t. Attempt to initiate an ftp session to a server at the mobile station. 31

u. Verify the MS does not send an Origination Message before the Dormant Timer expires. 32

12.16.4.2 Traffic Channel State 33




3GPP2 C.S0044-D v1.0

12-22


session 2

e. From the base station, generate a General Handoff Direction Message or a 3

Supplemental Channel Assignment Message to allocate N Supplemental Code 4

Channels to the mobile station. 5

f. From the base station, send a Service Option Control Message to the mobile station to 6

enable the PACKET_ZONE_ID with a valid list of PACKET_ZONE_IDs. 7

g. Verify from the mobile station that N Supplemental Code Channels are being used. 8

h. Begin transferring the file from the remote host to TE2M using the binary “get” 9

command. 10

i. While the file is being transferred, send the Service Option Control Message to the 11

mobile station with a change in the PACKET_ZONE_ID. 12

j. Change the PACKET_ZONE_ID of the serving system in the In-Traffic System 13

Parameter Message. 14

k. Verify the mobile station continues file transfer on the new PACKET_ZONE_ID. 15




12.16.5.1 Mobile Station Idle State 19

The mobile station shall comply with steps h, k m, n and u 20

12.16.6 Traffic Channel State 21

For section 12.16.3.2, the mobile station shall comply with steps g and k for all test cases. 22

23

24

3GPP2 C.S0044-D v1.0

13-1

13 HIGH SPEED PACKET DATA 1


13.1.1 Definition 3

This test verifies that file transfer from remote host to mobile station can be successfully done 4 using the HSPD call. 5


(see [4]) 7

2.7.2.3.2.18 Supplemental Channel Request Message 8

2.7.2.3.2.28 Supplemental Channel Request Mini Message 9


3.7.3.3.2.24 Supplemental Channel Assignment Message 11

3.7.5.7.1 Channel Configuration for the Supplemental Channel 12

(see [15]) 13




2.2.7 High Speed Operation 17


None 19



b. At the remote host prepare appropriate file (see Annex D) for data transfer11

. 22

c. Setup an FTP session using Service Option 33 with the remote host12

. 23

d. If supplemental channel is assigned, verify the base station sends a Universal Handoff 24

Direction Message, an Extended Supplemental Channel Assignment Message, or a 25

Forward Supplemental Channel Assignment Mini Message. 26

e. Transfer the file from the remote host to the TE2M using the binary “get” command. 27

11 The large FTP file size, coupled with a full constant buffer, is intended to trigger use of the

maximum data rate assignment supported by both mobile station and base station.

12 Ensure that sufficient Walsh code resources are available.

3GPP2 C.S0044-D v1.0

13-2

f. After the file transfer is completed, end the FTP session. Make sure the file is 1


g. Steps b through f may be repeated for other data rates and different radio 3

configurations supported by both mobile station and base station. 4

5

Table 13.1.4-1 SCH Data Rate 6

Data Rate Granted (bps)

F-RC3, 4 / R-RC3

F-RC6, 7 /R-RC5

F-RC5 / R-RC4

F-RC8, 9 / R-RC6

9600 14400

19200 28800

38400 57600

76800 115200

153600 230400

307200 460800

614400 1036800

7


The mobile station shall comply with step f. The base station shall comply with step d. 9



This test verifies that file transfer from mobile station to remote host can be successfully done 12 using the HSPD call. 13


(see [4]) 15






(see [15]) 21

3GPP2 C.S0044-D v1.0

13-3






None 6



b. At the TE2M prepare a file for data transfer. 9

c. Setup an FTP session using Service Option 33 with the remote host. 10

d. Transfer the file from the TE2M to the remote host using the binary “put” command. 11

Ensure that the total amount of data to be transferred at the mobile station is more than 12

an implementation defined threshold, or otherwise cause the mobile station to send a 13

Supplemental Channel Request Message or a Supplemental Channel Request Mini 14

Message with DURATION field set to a non-zero value. 15

e. If supplemental channel is assigned, verify the base station sends a Universal Handoff 16

Direction Message, an Extended Supplemental Channel Assignment Message, or a 17

Reverse Supplemental Channel Assignment Mini Message. 18

f. After the file transfer is completed, end the FTP session. Make sure that file is 19


g. Steps b through f should be executed for the maximum data rates13

supported by both 21

mobile station and base station. 22

h. Steps b through f may be repeated for other data rates and radio configurations 23

supported by both mobile station and base station. 24



13.3 Bi-directional File Transfer 27


This test verifies that bi-directional file transfer can be successfully done using the HSPD call. 29


(see [4]) 31

13 Make sure that transmit power is not limiting factor for maximum data rate assignment.

3GPP2 C.S0044-D v1.0

13-4






(see [15]) 6






None 12



b. Prepare a file at both the remote host and TE2M for data transfer. 15

c. Setup an FTP session using Service Option 33 with the remote host. 16

d. Transfer the file from the TE2M to the remote host. Ensure that the total amount of data 17

to be transferred at the mobile station is more than an implementation defined 18

threshold, or otherwise cause the mobile station to send a Supplemental Channel 19

Request Message or a Supplemental Channel Request Mini Message with DURATION 20

field set to a non-zero value. 21

e. Transfer a file from the Remote Host to the TE2M while the transfer in the reverse 22

direction is still proceeding. 23

f. If forward supplemental channel is assigned, verify the base station sends a Universal 24

Handoff Direction Message, an Extended Supplemental Channel Assignment Message, 25

or a Forward Supplemental Channel Assignment Mini Message. 26

g. If reverse supplemental channel is assigned, verify the base station sends a Universal 27

Handoff Direction Message (can be same as one in step f), an Extended Supplemental 28

Channel Assignment Message (can be same as one in step f), or a Reverse 29

Supplemental Channel Assignment Mini Message. 30

h. Verify that files in both directions are successfully transferred and end the FTP session. 31

3GPP2 C.S0044-D v1.0

13-5

i. Steps c through f should be executed for the maximum forward14

and reverse15

data 1

rates that are supported by both mobile station and base station. 2

j. Steps c through f may be repeated for different data rates and radio configurations that 3

are supported by both mobile station and base station. 4


The mobile station shall comply with step h. The base station shall comply with steps f and g. 6

7

13.4 Service Option Control Message Processing 8

13.4.1 Definition 9

This test verifies the mobile station ability to process the Service Option Control Message. This 10 test also verifies the mobile station is able to establish a voice call while the packet data session 11 is dormant. 12

13.4.2 Traceabilities 13

(see [4]) 14




(see [15]) 18

2.2.2.1 Mobile Station Procedures 19

2.2.2.2 Base Station Procedures 20

2.2.4 Packet Data Dormant Timer Control 21

14 Make sure that conditions to trigger maximum forward data rate assignment are fulfilled; such

as large enough FTP file size, sufficient Walsh code resource etc.

15 Make sure that transmit power is not limiting factor for maximum reverse data rate assignment.

3GPP2 C.S0044-D v1.0

13-6


Service Option Control Message

General Page Msg with

voice service option

BSMS

Traffic Traffic

TrafficTraffic

Release OrderMS packet service is

dormant

Data Call in Progress

Voice

Call in Progress

Voice call ends

General Page Msg with

packet data service option

Data Call may

Resume

2


a. Connect the mobile station in Figure A-3. 4

b. Setup a mobile originated Service Option 33 call. 5

c. While the data call is active, instruct the base station to send a Service Option Control 6

Message with the following information: 7

8

3GPP2 C.S0044-D v1.0

13-7

Field Value

SERVICE_OPTION ‘0000000000100001’

DORM_CTRL ‘001’

FIELD_TYPE ‘011’

DORM_TIME ‘11111111’ (25.5 sec)

d. Instruct the base station to send a Release Order with ORDQ=’0’ to the mobile station. 1

e. Verify the mobile station releases the call and the packet data session is in the dormant 2

state. 3

f. Before the DORM_TIME expires, send a General Page to the mobile station with a 4

voice service option. 5

g. Verify the call completes and user traffic is present. 6

h. End the call before DORM_TIME expires. 7

i. Set up a mobile originated voice call. 8

j. Verify the call completes and user traffic is present. 9

k. End the call before DORM_TIME expires. 10

l. Insure the mobile station has sufficient data in its buffer. 11

m. Verify the mobile station does not send an Origination Message for packet data service 12

before the DORM_TIME expires. 13

n. After DORM_TIME has expired, page the mobile station with a packet data service or 14

otherwise cause the mobile station to send an Origination Message for a packet data 15

service. 16

o. Verify the call completes and user traffic is present. 17


The mobile station shall comply with steps e, g, j, m and o. 19

13.5 Changing Encoding Type on Supplemental Channel during Hard Handoff 20


This test verifies that the mobile station is capable of using turbo encoding and is capable of 22 changing to convolutional encoding. 23


(see [1]) 25

2.1.3.1.4 Forward Error Correction 26

3.1.3.1.4 Forward Error Correction 27

3GPP2 C.S0044-D v1.0

13-8

(see [4]) 1





None 6


13.5.4.1 R-SCH Turbo Encoding to Convolutional Encoding 8


b. Ensure the mobile station supports turbo encoding and convolutional encoding. 10

c. Setup a mobile originated Service Option 33 call. 11

d. Instruct the base station to send a Service Connect Message with CODING=‘1’ in the 12

Service Configuration Record for the F-SCH and R-SCH (as supported by the mobile 13

station). 14

e. Verify the mobile station sends a Service Connect Completion Message. 15

f. Initiate a data transfer from the mobile station and verify the mobile station sends a 16

Supplemental Channel Request Message requesting a reverse supplemental channel. 17

g. Instruct the base station to send an Extended Supplemental Channel Assignment 18

Message assigning a reverse supplemental channel to the mobile station. 19

h. While the data transfer is in progress, instruct the base station to send a Universal 20

Handoff Direction Message with CODING=’0’ and a reverse supplemental channel 21

burst assignment. 22

i. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 23


j. Verify the data transfer completes successfully using convolutional encoding. 25

k. End the call from the mobile station. 26

13.5.4.2 R-SCH Convolution Encoding to Turbo Encoding 27






station). 33


3GPP2 C.S0044-D v1.0

13-9

f. Initiate a data transfer from the mobile station and verify the mobile station sends a 1


g. Instruct the base station to send an Extended Supplemental Channel Assignment 3


h. While the data transfer is in progress, instruct the base station to send a Universal 5

Handoff Direction Message with CODING=’1’ and a reverse supplemental channel 6

burst assignment. 7

i. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 8


j. Verify the data transfer completes successfully using turbo encoding (if the block size 10

per frame is at least 360 bits).. 11

k. End the call from the mobile station. 12

13.5.4.3 F-SCH Turbo Encoding to Convolutional Encoding 13






station). 19


f. Initiate a data transfer to the mobile station and verify the base station sends an 21

Extended Supplemental Channel Assignment Message assigning a F-SCH. 22

g. While the data transfer is in progress, instruct the base station to send a Universal 23

Handoff Direction Message with CODING=’0’ and a forward supplemental channel 24

burst assignment. 25

h. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 26


i. Verify the data transfer completes successfully using convolutional encoding. 28

j. End the call from the mobile station. 29

13.5.4.4 F-SCH Convolutional Encoding to Turbo Encoding 30






station). 36

3GPP2 C.S0044-D v1.0

13-10


f. Initiate a data transfer to the mobile station and verify the base station sends an 2


g. While the data transfer is in progress, instruct the base station to send a Universal 4

Handoff Direction Message with CODING=’1’ and a forward supplemental channel 5

burst assignment. 6

h. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 7


i. Verify the data transfer completes successfully using turbo encoding (if the block size 9

per frame is at least 360 bits).. 10



13.5.5.1 R-SCH Turbo Encoding to Convolutional Encoding 13

The mobile station shall comply with steps e, i, and j 14

13.5.5.2 R-SCH Convolutional Encoding to Turbo Encoding 15

The mobile station shall comply with steps e, i, and j. 16

13.5.5.3 F-SCH Turbo Encoding to Convolutional Encoding 17

The mobile station shall comply with steps e, h, and i. 18

13.5.5.4 F-SCH Convolutional Encoding to Turbo Encoding 19

The mobile station shall comply with steps e, h, and i. 20

13.6 Control Hold Mode Transitions 21


This test applies when the mobile station and base station support Control Hold Mode. This test 23 verifies that the mobile can go in and out of the Control Hold Mode in all the possible 24 combinations. When the mobile station or the base station, trigger a transition to the Control Hold 25 Mode, the expected signaling exchange takes place. Upon transition to the Control Hold Mode, 26 the reverse pilot is gated at the specified gating rate DCCH is maintained with Power Control sub-27 channel and user traffic transmission is not allowed in either direction. When the mobile station 28 and base station transition to the Active Mode, the expected signaling exchange takes place. 29 Upon transition to the Active Mode, the reverse pilot transmission is continuous and user traffic 30 transmission is allowed. 31

The following are call flow examples for going in and out of Control Hold Mode. Either the mobile 32 station or the base station can trigger either transition. 33


35

3GPP2 C.S0044-D v1.0

13-11

Extended Release (Mini) Message /


Extended Release Response (Mini) Message

Handoff Completion MessageAt the action time:

Transition to Control Hold Mode

& start reverse pilot gating at the

specified gating rate

BSMS

Active Active

Control Hold Control Hold

BS decides to transition

to Control Hold Mode

1 2

Figure 13-1 Call Flow for base station initiated Active to Control Hold Transition 3

4

Extended Release (Mini) Message /


Extended Release Response (Mini) Message

Handoff Completion MessageAt the action time:

Transition to Control Hold Mode

& start reverse pilot gating at the

specified gating rate

BSMS

Active Active

Control Hold Control Hold

Resource Release Request (Mini) Message

Request to transition to

Control Hold Mode

5 6

Figure 13-2 Call Flow for mobile station initiated Active to Control Hold Transition 7

8

3GPP2 C.S0044-D v1.0

13-12

Resource Allocation (Mini) Message /

Universal Handoff Direction Message /

Extended Supplemental Channel

Assignment Message/

Forward Supplemental Channel

Assignment Mini Message/

Reverse Supplemental Channel

Assignment Mini Message

At the action time:

Transition to Active Mode

& start reverse pilot continuous

transmission

BSMS

Control

Hold

Active Active

BS decides to transition

to Active Mode

Control

Hold

1 2

Figure 13-3 Call Flow for base station initiated Control Hold to Active Transition 3

4

Resource Allocation (Mini) Message /

Universal Handoff Direction Message /

Extended Supplemental Channel

Assignment Message/

Forward Supplemental Channel

Assignment Mini Message/

Reverse Supplemental Channel

Assignment Mini Message

At the action time:

Transition to Active Mode

& start reverse pilot continuous

transmission

BSMS

Control

Hold

Active Active

Request to transition to

Active Mode

Control

Hold

Resource Request (Mini) Message /

Supplemental Channel

Request (Mini) Message

5 6

Figure 13-4 Call Flow for mobile station initiated Control Hold to Active Transition 7


(See [4]) 9

3GPP2 C.S0044-D v1.0

13-13


2.6.4.1.9 Processing the Extended Release Message and the Extended Release Mini 2

Message 3

2.6.4.1.10 Processing the Resource Allocation Message and Resource Allocation Mini 4

Message 5





2.7.2.3.2.23 Resource Request Message 10

2.7.2.3.2.24 Resource Request Mini Message 11

2.7.2.3.2.29 Resource Release Request Message 12

2.7.2.3.2.30 Resource Release Request Mini Message 13

3.6.4.1.6 Processing Resource Request Messages 14

3.6.4.1.8 Processing Resource Release Request Message and Resource Release 15

Request Mini Message 16


3.6.6.2.2.11 Processing the Universal Handoff Direction Message 18

3.6.6.2.2.13 Processing of Forward Supplemental Channel Assignment Mini Message 19

3.6.6.2.2.14 Processing of Reverse Supplemental Channel Assignment Mini Message 20

3.7.3.3.2.32 Resource Allocation Message 21

3.7.3.3.2.33 Resource Allocation Mini Message 22

3.7.3.3.2.34 Extended Release Message 23

3.7.3.3.2.35 Extended Release Mini Message 24



3.7.3.3.2.38 Forward Supplemental Channel Assignment Mini Message 27

3.7.3.3.2.39 Reverse Supplemental Channel Assignment Mini Message 28

3.7.5.20 (base station) Non-Negotiable Service Configuration information record 29



b. Setup a packet data call, using only the Dedicated Control Channel (DCCH). 32

c. Verify user traffic (Ex. Browser data) in both directions. 33

3GPP2 C.S0044-D v1.0

13-14

d. Cause the mobile station and/or base station to initiate transition to the Control Hold 1

Mode because of out-of-data indication from the RLP. 2

e. Verify that one of the following two scenarios occurs: 3

1. Verify that the mobile station sends a Resource Release Request (Mini) 4

Message to the base station to request transition to the Control Hold Mode. 5

Verify that the base station accepts this request, via an Extended Release (Mini) 6

Message, or a Universal Handoff Direction Message. Verify that the mobile 7

station responds with an Extended Release Response (Mini) Message, or a 8

Extended Handoff Completion Message. 9

2. Verify that the base station sends an Extended Release Mini Message, or a 10

Universal Handoff Direction Message. Verify that the mobile station responds 11

with an Extended Release Response Mini Message, or an Extended Handoff 12


f. Upon transition to Control Hold Mode, verify the following: 14

1. The reverse pilot is gated at the specified rate. 15

2. Dedicated Control Channel is maintained for signaling. 16

3. User traffic (Ex. Browser data) is not transmitted on either direction. NOTE: This 17

can be verified by attempting to send user traffic, while not granting any requests 18

to transition to the Active Mode. 19

4. Reverse Power Control Subchannel is maintained at the Forward Dedicated 20

Control Channel. 21

g. Depending on who initiated the transition to Control Hold Mode in e, and if possible, 22

change the control hold time on the network side to make the other alternative happen 23

in d. Repeat b through f. Results are as expected in f. 24

h. Execute steps b through f. 25

i. Instruct the base station to initiate the transition to Active Mode (e.g. Send a ping 26

command to the mobile station from the base station. 27

j. Verify that the base station initiates the transition to Active Mode, via a Resource 28

Allocation Message, a Resource Allocation Mini Message, a Universal Handoff 29

Direction Message, an Extended Supplemental Channel Assignment (Mini) Message, a 30

Forward Supplemental Channel Assignment Mini Message, or a Reverse Supplemental 31

Channel Assignment Mini Message. Verify that the mobile station responds accordingly. 32

k. Upon transition to the Active Mode, verify that: 33

1. The reverse pilot transmission is continuous 34

2. User traffic (Ex. Browser data) is transmitted. 35

l. Execute steps b through f. 36

m. Send a ping from the mobile station side to cause the mobile station to initiate the 37

transition to Active Mode. Verify that the mobile station sends a Resource Request 38

(Mini) Message, a Supplemental Channel Request (Mini) Message. Verify that the base 39

3GPP2 C.S0044-D v1.0

13-15

station sends a Resource Allocation (Mini) Message, a Universal Handoff Direction 1

Message, an Extended Supplemental Channel Assignment (Mini) Message, a Forward 2

Supplemental Channel Assignment Mini Message, or a Reverse Supplemental Channel 3

Assignment Mini Message. 4

n. Verify step k. 5


The mobile station and the base station shall comply with the requirements in the following steps: 7 e, f, j, k, m, and n. 8

13.7 Soft Handoff of Fundamental Channel/Dedicated Control Channel and Supplemental 9

Channels 10


This test verifies that the mobile station can successfully complete a soft handoff of the 12 fundamental, dedicated control channel, and supplemental channels during a data transfer. 13


(see [4]) 15


2.7.2.3.2.28 Pilot Strength Measurement Mini Message 17

2.7.2.32.34 Extended Pilot Strength Measure Message 18






(see [15]) 24






None 30

3GPP2 C.S0044-D v1.0

13-16


13.7.4.1 Forward FCH/DCCH and SCH Soft Handoff 2

a. Connect the mobile station to the base station as shown in Figure A-5 and setup the 3

parameters as shown in Table 13.7.4-1. 4

Table 13.7.4-1 5


Îor/Ioc dB 7 -20




Pilot Ec/Io dB -5.8 -33

6

b. Verify the mobile station is in the Idle State on base station 1. 7

c. Setup a mobile station originated service option 33 call, using the FCH for signaling. 8

d. Initiate a forward data transfer to the mobile station. 9

e. Configure base station 1 to send the Extended Supplemental Channel Assignment 10

Message to assign the maximum number of forward supplemental channels supported 11

by the base station and mobile station. 12

f. While the forward data transfer is in progress, raise the level of base station 2 in steps 13

of 1 dB with a dwell time of 5 seconds after each step until the mobile station has 14

generated the Pilot Strength Measurement Message, Extended Pilot Strength Message, 15

or a Pilot Strength Mini Message. 16

g. Configure base station 1 to send a Universal Handoff Direction Message with 17

NUM_FOR_ASSIGN = [number of SCH in step e] and both base stations in the active 18

set. 19

h. Verify the mobile station sends the Handoff Completion Message or an Extended 20

Handoff Completion Message. Verify the mobile station’s active set consist of both base 21

stations. 22

i. Lower the level of base station 1 in steps of 1 dB with a dwell time of 5 seconds after 23


Message, Extended Pilot Strength Measurement Message or a Pilot Strength 25

Measurement Mini Message. 26

j. Configure base station 1 to send a Universal Handoff Direction Message to the mobile 27

station with NUM_FOR_ASSIGN = [number of SCH in step e] and base station 2 in the 28

active set. 29

3GPP2 C.S0044-D v1.0

13-17

k. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 1


l. Verify the data transfer completes successfully. 3

m. End the call. 4

n. Repeat steps c through m using the DCCH for signaling. 5

13.7.4.2 Reverse FCH/DCCH and SCH Soft Handoff 6




c. Setup a mobile station originated service option 33 call using the FCH for signaling. 10

d. Initiate a reverse data transfer from the mobile station. 11

e. After the mobile station sends a Supplemental Channel Request Message, configure 12

base station 1 to send an Extended Supplemental Channel Assignment Message to 13

assign the maximum number of reverse supplemental channels supported by the 14

network and mobile station. 15

f. While the reverse data transfer is in progress, raise the level of base station 2 in steps 16


generated the Pilot Strength Measurement, Extended Pilot Strength Measurement 18

Message or a Pilot Strength Measurement Mini Message. 19


NUM_REV_ASSIGN = [number of SCH in step e] and both base stations in the active 21

set. 22



stations. 25

i. Lower the level of base station 1 in steps of 1 dB with a dwell time of 5 seconds after 26


Message, Extended Pilot Strength Measurement Message or a Pilot Strength 28


j. Configure base station 2 to send a Universal Handoff Direction Message to the mobile 30

station with NUM_REV_ASSIGN = [number of SCH in step e] and base station 2 in the 31

active set. 32

k. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 33


l. Verify the data transfer completes successfully. 35

m. End the call. 36

n. Repeat steps c through m using the DCCH. 37

3GPP2 C.S0044-D v1.0

13-18


13.7.5.1 Forward FCH/DCCH and SCH Soft Handoff 2

The mobile station shall comply with steps h, k, l, and n. 3

13.7.5.2 Reverse FCH/DCCH and SCH Soft Handoff 4

The mobile station shall comply with steps h, k, l, and n. 5

13.8 Soft Handoff of Fundamental Channel or Dedicated Control Channel only 6

13.8.1 Definition 7

This test verifies the mobile station can successfully complete a data transfer when only the 8 fundamental channel or dedicated control channel is in soft handoff. 9


(see [4]) 11









(see [15]) 20






None 26


13.8.4.1 Forward FCH/DCCH Only Soft Handoff 28




3GPP2 C.S0044-D v1.0

13-19


d. Initiate a forward data transfer to the mobile station. 2

e. Configure base station 1 to send the Extended Supplemental Channel Assignment 3

Message to assign the maximum number of forward supplemental channels supported 4

by the network and mobile station. 5

f. While the forward data transfer is in progress, raise the level of base station 2 in steps 6


generated the Pilot Strength Measurement Message, Extended Pilot Strength 8

Measurement Message or a Pilot Strength Measurement Mini Message. 9


NUM_FOR_ASSIGN = 0 and both base stations in the active set. 11



stations. 14

i. Verify the data transfer completes successfully. 15

j. End the call. 16

k. Repeat steps c through j using the DCCH for signaling. 17

13.8.4.2 Reverse FCH/DCCH Only Soft Handoff 18




c. Setup a mobile station originated service option 33 call using the FCH for signaling 22

d. Initiate a reverse data transfer from the mobile station. 23

e. After the mobile station sends a Supplemental Channel Request Message, Configure 24

base station 1 to send an Extended Supplemental Channel Assignment Message to 25

assign the maximum number of reverse supplemental channels supported by the 26

network and mobile station. 27

f. While the reverse data transfer is in progress, raise the level of base station 2 in steps 28


generated the Pilot Strength Measurement Message, Extended Pilot Strength 30

Measurement Message or a Pilot Strength Measurement Mini Message. 31


NUM_REV_ASSIGN = 0 and both base stations in the active set. 33



stations. 36


3GPP2 C.S0044-D v1.0

13-20

j. End the call. 1

k. Repeat steps c through j with the DCCH for signaling. 2


13.8.5.1 Forward FCH/DCCH Only Soft Handoff 4

The mobile station shall comply with steps h i, and k. 5

13.8.5.2 Reverse FCH/DCCH Soft Handoff Only 6

The mobile station shall comply with steps h, i, and k. 7

13.9 Adding Supplemental Channels during Soft Handoff 8

13.9.1 Definition 9

This test verifies that a supplemental channel(s) can be added in a service option 33 call while in 10 soft handoff on the fundamental channel or dedicated control channel. 11


(see [4]) 13









(see [15]) 22






None 28




3GPP2 C.S0044-D v1.0

13-21



d. Raise the level of base station 2 in steps of 1 dB with a dwell time of 5 seconds after 3


Message, Extended Pilot Strength Measurement Message, or a Pilot Strength 5


e. Configure base station 1 to send a Universal Handoff Direction Message with 7

NUM_FOR_ASSIGN = 0 and both base stations in the active set. 8

f. Verify the mobile station sends the Handoff Completion Message or an Extended 9


stations. 11

g. Initiate a forward data transfer to the mobile station. 12

h. Configure base station 1 to send the Extended Supplemental Channel Assignment 13

Message with NUM_SUP_SHO = ‘001’ for the forward supplemental channel and 14

include both base station 1 and base station 2 for PILOT_PN values. 15


j. End the call. 17



The mobile station shall comply with steps f, i, and k. 20

13.10 Hard Handoff during Data Transfer 21


This test verifies the data transfer continues after hard handoff using the forward and reverse link. 23


(see [4]) 25







(see [15]) 32


3GPP2 C.S0044-D v1.0

13-22





None 5


13.10.4.1 Forward Data Transfer during Hard Handoff 7



Table 13.10.4-1 10


Îor/Ioc dBm N/A -5





11

b. Ensure that the mobile station is operating in the idle state on base station 1. 12

c. Setup a mobile station originated Service Option 33 call. 13

d. Initiate a data transfer to the mobile station and verify the base station sends an 14


e. While the data transfer is in progress, instruct the base station to send a Universal 16

Handoff Direction Message directing the mobile station to base station 2. 17

f. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 18


g. Configure base station 2 to send a Universal Handoff Direction Message or an 20


h. Verify the data transfer completes. 22

i. End the call from the mobile station. 23

j. Repeat steps c through i using the DCCH for signaling. 24

3GPP2 C.S0044-D v1.0

13-23

13.10.4.2 Reverse Data Transfer during Hard Handoff 1




c. Setup a mobile station originated Service Option 33 call. 5

d. Initiate a data transfer from the mobile station and verify the mobile station sends a 6


e. Instruct the base station to send an Extended Supplemental Channel Assignment 8


f. While the data transfer is in progress, instruct the base station to send a Universal 10

Handoff Direction Message directing the mobile station to base station 2. 11



h. Configure base station 2 to send a Universal Handoff Direction Message or an 14

Extended Supplemental Channel Assignment Message assigning a R-SCH. 15






The mobile station shall comply with steps f, h and j. 21


The mobile station shall comply with steps g, i, and k. 23

13.11 Hard Handoff to a different Radio Configuration 24


This test verifies hard handoff to a different radio configuration during an HSPD call. 26


(see [4]) 28





3GPP2 C.S0044-D v1.0

13-24



(see [15]) 3






None 9






c. Setup a mobile station originated Service Option 33 call. Note the FOR_FCH_RC, 15

REV_FCH_RC, and SCH_RC values. 16

d. Initiate a data transfer to the mobile station and verify the base station sends an 17


e. While the data transfer is in progress, instruct the base station to send a Universal 19

Handoff Direction Message changing the FOR_FCH_RC, REV_FCH_RC and SCH_RC 20

values in step c and directing the mobile station to base station 2. 21

f. Verify the mobile station sends a Handoff Completion Message or an Extended Handoff 22


g. Configure base station 2 to send an Extended Supplemental Channel Assignment 24

Message assigning a F-SCH. 25

h. Verify the data transfer completes. 26

i. End the call from the mobile station. 27

j. This test may be repeated for all radio configurations supported. 28

k. Repeat steps c through j with the DCCH for signaling. 29





3GPP2 C.S0044-D v1.0

13-25

c. Setup a mobile station originated Service Option 33 call. Note the FOR_FCH_RC, 1

REV_FCH_RC, and SCH_RC values. 2

d. Initiate a data transfer from the mobile station and verify the mobile station sends a 3


e. Instruct the base station to send an Extended Supplemental Channel Assignment 5


f. While the data transfer is in progress, instruct the base station to send a Universal 7

Handoff Direction Message changing the FOR_FCH_RC, REV_FCH_RC and SCH_RC 8

values in step c directing the mobile station to base station 2. 9



h. Configure base station 2 to send a Universal Handoff Direction Message or an 12

Extended Supplemental Channel Assignment Message assigning a R-SCH. 13



k. This test may be repeated for all radio configurations supported. 16

l. Repeat steps c through k using the DCCH for signaling 17



The mobile station shall comply with steps f, h, and k. 20


The mobile station shall comply with steps g, i, and l. 22

13.12 Mobile Station Packet Data Inactivity Timer 23


This test is applicable for a mobile station implementing packet data inactivity timer. This test 25 verifies the mobile station releases the traffic channel after expiration of the mobile station packet 26 data Inactivity Timer. The test verifies the dormant link layer connection can be re-activated. 27




None 31


a. Set the packet data inactivity timer at the MT2 to 20 seconds. 33

3GPP2 C.S0044-D v1.0

13-26

b. Ensure the base station packet data inactivity timer is disabled or set to a value of at 1

least 30 seconds. 2

c. Initiate a Telnet session to a remote host. 3

d. Record the IP address assigned to the mobile station. 4

e. Exit the Telnet session. 5

f. Wait for the mobile station packet data inactivity timer to expire. Verify the “in use” 6


g. Initiate a Telnet session to a remote host. 8

h. Record the IP address assigned to the mobile station. 9

i. Wait for the mobile station packet data inactivity timer to expire. Verify the “in use” 10


j. Issue a continuous “ping” command from the remote host to the mobile station using 12

the IP address assigned to the mobile station. 13

k. Verify that the ping is successful. 14


The mobile station shall comply with steps f, i and k. 16

13.13 Mobile Station and Base Station Operating in Different States 17


This test verifies the mobile station and base station correct the condition of the mobile station 19 operating in the Null State and the base station/PCF operating in the Dormant State. [4] Permits 20 two standardized approaches for the mobile station to reject/release a General Page Message 21 containing Service Option 33 when the mobile station is in the Null State and the base 22 station/PCF is in the Dormant State. In both implementations, the mobile station and base 23 station/PCF shall transition to the Null State. 24

In the preferred implementation, a mobile station in the Null State will reject a General Page 25 Message containing Service Option 33 by sending a Page Response Message containing 26 Service Option = 0x00. The base station should send a Release Order to the mobile station. 27

In an alternate implementation, a mobile station in the Null State will accept a General Page 28 Message containing Service Option 33 by sending a Page Response Message containing 29 Service Option 33. After the base station assigns a traffic channel, the mobile station sends a 30 Release Order containing ORDQ=2 to release the call. 31


(see [4]) 33




3.6.3.3 Responding to a Page Response Message 37

3GPP2 C.S0044-D v1.0

13-27

3.7.4 Orders 1

(see [15]) 2

2.2.2.2.1.3 Paging State 3


Dormant

StateDormant

State

MSBS/

PCF

Null State

Null State Null State

General Page, SO:

0x21

Page Response Msg with SO:

0x00

BS should send Release Order

Dormant

State

MS and BS/

PCF are not

in the same

state. MS has

closed PPP

session

without

notifying BS/

PCF. BS/PCF

attempts to

initiate a

dormant to

active

transition.

5

Figure 13-5 Call Flow without Setting Up Traffic Channel (Preferred Implementation) 6

3GPP2 C.S0044-D v1.0

13-28

Traffic Channel Setup

Dormant

State

Dormant

State

MSBS/

PCF

Null StateDormant

State

Null State Null State

General Page, SO:

0x21

Page Response Msg with SO: 0x21

BS/PCF

attempts to

initiate a

dormant to

active

transition.

MS and BS/

PCF are not

in the same

state. MS has

closed PPP

session

without

notifying BS/

PCF.

Conversation

MS sends Release Order with

ORDQ=2

1

Figure 13-6 Call Flow with Setting Up Traffic Channel (Alternate Implementation) 2


a. Connect the mobile station as shown in Figure A-3. 4

b. Set up a Service Option 33 call using a dedicated traffic channel. 5

c. Allow the mobile station to enter the Dormant State. 6

d. Verify the base station/PCF and mobile station are operating in the Dormant State. 7

e. Instruct the mobile station to transition to the Null State (i.e. terminate the PPP session) 8

without notifying the base station. (e.g., disconnect the mobile station from the laptop.) 9

NOTE: Depending on implementation, the mobile station may autonomously originate a 10

service option 33 call upon the disconnection of the cable from the laptop. If this occurs, 11

proceed to step g2. 12

f. Instruct the base station to initiate the Dormant to Active transition by sending a 13

General Page Message or Universal Page Message to the mobile station with the 14

Service Option 33. 15

g. Verify one of the following occurs; 16

1. The mobile station sends a Page Response Message with the Service Option = 17

0: 18

3GPP2 C.S0044-D v1.0

13-29

a. The base station should send a Release Order to the mobile station 1

after receiving the Page Response Message with the Service Option = 2

0. 3

2. The mobile station sends a Page Response Message/Origination Message with 4

the Service Option = 33: 5

a. After the base station assigns a traffic channel, verify the mobile 6

station sends a Release Order with ORDQ=2. 7

h. Verify the mobile station and base station/PCF are now operating in the Null State. 8


The mobile station shall comply with steps g and h. 10

13.14 RLP Operation in Rayleigh Fading Environment 11


This test verifies data transfer under Rayleigh fading channel conditions. This test verifies that 13 RLP recovers erased data frames, and is intended to exercise RLP negative acknowledgements 14 (NAKs), retransmissions, and aborts in the forward and reverse directions. This test also verifies 15 the mobile station is able to successfully complete a network initiated dormant to active transition. 16


(see [4]) 18


(see [15]) 20

2.2.1 RLP Requirements 21



24


None 26



b. Set the channel simulator using the parameters as specified in Table 3.5.4-4. 29

c. Ensure the mobile station currently has a PPP session established and is in the 30

dormant state. 31

d. Instruct the base station to initiate a dormant to active transition. 32

e. Verify the mobile station is able to transition to the active state. 33

f. Initiate a forward data transfer to the mobile station. 34

g. Verify the file transfer completes successfully. 35

3GPP2 C.S0044-D v1.0

13-30

h. Initiate a reverse data transfer from the mobile station. 1

i. Verify the file transfer completes. 2

j. Repeat steps c through i changing the channel simulator setting to one path at 3 km/hr. 3


The mobile station shall comply with steps e, g, i, and j. 5

13.15 Release Order Processing 6


This test case verifies the mobile station correctly processes the Release Order with ORDQ=2 8 when received on the f-csch. 9


(see [4]) 11


3.7.5 Orders 13

(see [15]) 14





19

3GPP2 C.S0044-D v1.0

13-31


Origination Message

Acknowledgment Order

Release Order with

ORDQ=2

Origination Message with

new service option

MS BS

Extended Channel Assignement

Message

TCH

Acknowledgment Order

The mobile station may

originate another call using a

different service option (e.g

SO12)

2


a. Configure the network to not allow Service Option 33 calls for the mobile station. (Note: 4

The network has packet data resources available, however the mobile station is not 5

authorized to use them.) 6

b. Instruct the mobile station to originate a Service Option 33 call. 7

c. Instruct the base station to send a Release Order with ORDQ = 2 to mobile station 8

indicating the requested service option has been rejected. 9

d. Verify the mobile station returns to the System Determination Substate or the Mobile 10

Station Idle State. 11

e. The mobile station may autonomously attempt to originate another data service option 12

(e.g. SO=12). 13

f. If the mobile station originates another service option and: 14

1. The base station supports that service option and has resources available, and 15

3GPP2 C.S0044-D v1.0

13-32

2. The mobile station is authorized to use that service option, verify the following: 1

a. The new data call with the different service option is completed 2

successfully. 3


The mobile station shall comply with step d. If the mobile station supports step e, the mobile 5 station shall comply with step f. 6

13.16 Hysteresis Activation Timer 7


This test case verifies the mobile station implementation of Hysteresis Activation Timer. The 9 value of this timer is mobile station implementation dependent in the range of 0 to 30 seconds. 10


(see [15]) 12

2.2.2.1.2.4 Dormant State 13


None 15


a. Connect the mobile station to the base station as shown in Figure A-5. Configure base 17

station 1 and base station 2 to transmit different non-zero values of PACKET_ZONE_ID 18

field in Extended System Parameters Message or ANSI-41 System Parameters 19

Message. Connect both the base stations to same PDSN. 20

b. Allow the mobile station to go idle on base station 1. Instruct the mobile station to 21

originate a Service Option 33 call on base station 1. Transfer data on the Service 22

Option 33 call (e.g. perform ftp or ping). 23

c. Ensure that length of the packet zone list is set to one entry at the mobile station. 24

Ensure packet zone hysteresis is enabled at the mobile station. 25

d. Allow Mobile Station to go dormant on base station 1. For rest of the test ensure that 26

the mobile station does not have any data to send. 27

e. While the hysteresis activation timer is running perform following operations: 28

1. Allow Mobile Station to perform an idle handoff to base station 2. Verify that the 29

mobile station sends an Origination Message with DRS field set to ‘0’ to base 30

station 2. 31



station 1. 34

3GPP2 C.S0044-D v1.0

13-33


The mobile station shall comply with step e 2

13.17 Hysteresis Timer 3


This test case verifies the mobile station implementation of Hysteresis Timer. The value of this 5 timer is mobile station implementation dependent in the range of 0 to 60 seconds. 6


(see [15]) 8

2.2.5 Packet Zone Reconnection Control 9


None 11


a. Connect the mobile station to the base station as shown in Figure A-5. Configure base 13

station 1 and base station 2 to transmit different non-zero values of PACKET_ZONE_ID 14

field in Extended System Parameters Message or ANSI-41 System Parameters 15

Message. Connect both the base stations to same PDSN. 16

b. Allow the mobile station to go idle on base station 1. Instruct the mobile station to 17

originate a Service Option 33 call on base station 1. Transfer data on the Service 18

Option 33 call (e.g. perform ftp or ping). 19

c. Ensure that length of the packet zone list is set to one entry at the mobile station. 20

Ensure packet zone hysteresis is enabled at the mobile station. 21

d. Allow Mobile Station to go dormant on base station 1. Allow mobile station to remain in 22

dormant state for duration of the hysteresis activation timer. For rest of the test ensure 23

that the mobile station does not have any data to send. 24

e. Perform following operations within duration less than the value of hysteresis timer 25

configured at the mobile station: 26



station 2. 29


mobile station does not send an Origination Message. 31

f. Allow Mobile Station to remain idle on base station 1 for duration more than the value of 32

hysteresis timer configured at the mobile station. Verify that the mobile station sends an 33

Origination Message with DRS field set to ‘0’ to base station 1. Verify that the duration 34

between the Origination Message in step d.1 and the Origination Message in step e is 35

approximately equal to the value of hyesteresis timer configured at the mobile station. 36

3GPP2 C.S0044-D v1.0

13-34



3

3GPP2 C.S0044-D v1.0

14-1

14 OVER-THE-AIR SERVICES 1

14.1 OTASP Download Request Processing 2

14.1.1 Definition 3

This test verifies a mobile station can initiate programming procedure and update its NAM 4 parameters. 5


(see [14]) 7

3.2.1 User-Initiated Procedure 8

3.5.1 Message Contents 9

3.5.2 NAM Parameter Blocks 10


4.3 Programming Data Download 12



4.5.4 Validation Parameter Blocks 15


None 17



b. Confirm that the mobile station is programmed with a non-zero SPCp. 20

c. Setup a mobile originated OTASP call using *228 + one of the System Selection Codes 21

in Table 14.1.4-1. 22

3GPP2 C.S0044-D v1.0

14-2

Table 14.1.4-1 1

Selected System Code

800 MHz A-BAND 00

800 MHz B-BAND 01

1.9 GHz A Block 02

1.9 GHz B Block 03

1.9 GHz C Block 04

1.9 GHz D Block 05

1.9 GHz E Block 06

1.9 GHz F Block 07

JTACS, A-Band 10

JTACS, B-Band 11

2 GHz Band 23

2

d. Upon call setup, instruct the base station to send a Protocol Capability Request 3

Message to the mobile station. 4

e. Verify the mobile station sends a Protocol Capability Response Message to the base 5

station with MOB_FIRM_REV, MOB_MODEL, BAND_MODE_CAP and all supported 6

FEATURE_ID and FEATURE_P_REV as listed in ANNEX C. The NAM Download 7

feature support is required for this test. 8

f. If Service Programming Lock is supported, perform the following: 9

1. Instruct the base station to send a Validation Request Message with BLOCK_ID 10

= ’00000000’ and SPC = SPCP. 11

2. Verify the mobile station sends a Validation Response Message within 750 ms, 12

and with BLOCK_ID = ’00000000’ and RESULT_CODE = ’00000000’ (Accepted 13

– Operation Successful). 14

g. If the Key Exchange is not supported, go to step h; otherwise: 15

1. Instruct the base station to send a Mobile Station Key Request Message to the 16

mobile station. 17

2. Verify the mobile station responds with a Mobile Station Key Response Message 18

within 30 seconds, with RESULT_CODE = '00000000' (Accepted - Operation 19

Successful). 20

3. Instruct the base station to send a Key Generation Request Message to the 21

mobile station. 22

3GPP2 C.S0044-D v1.0

14-3

4. Verify the mobile station responds with a Key Generation Response Message 1

within 30 seconds and the RESULT_CODE = '00000000' (Accepted - Operation 2

Successful). 3

5. Verify the base station and the mobile station successfully perform SSD update 4

procedures. 5

6. Verify the base station sends the Re-Authenticate Request Message and the 6

mobile responds with the Re-Authenticate Response Message within 750ms. 7

7. At the base station verify Re-Authentication is successful. 8

8. The base station may enable Signaling Message Encryption and Voice Privacy. 9

h. Instruct the base station to send a Configuration Request Message with one or more of 10

the following NAM Parameter Block Types: 11

12

Parameter Block Type BLOCK_ID

CDMA/Analog NAM ‘00000000’

Mobile Directory Number ‘00000001’

CDMA NAM ‘00000010’

IMSI_T ‘00000011’

i. Verify the mobile station sends a Configuration Response Message within 750ms 13

including each requested BLOCK_ID and associated PARAM_DATA with 14

corresponding RESULT_CODE. 15

j. Instruct the base station to send a Download Request Message with one or more of the 16

following NAM Parameter Block Types and the corresponding PARAM_DATA: 17

18




CDMA NAM ‘00000010’

IMSI_T ‘00000011’

k. Verify the mobile station sends a Download Response Message and that 19

RESULT_CODE = '00000000' (Accepted- Operation Successful) within 750ms. 20

l. Instruct the base station to send a Commit Request Message to the mobile station. 21

m. Verify the mobile station sends a Commit Response Message to the base station within 22

10 seconds with the RESULT_CODE = '00000000' (Accepted- Operation Successful). 23


3GPP2 C.S0044-D v1.0

14-4

o. Verify the mobile station successfully stored the updated NAM information. 1

p. Setup a mobile station originated call and verify user traffic is present. 2


The mobile station shall comply with steps e, i, k, m, o, and p. If supported the mobile station shall 4 comply with steps f and i. The mobile station shall update its NAM information as received in the 5 Download Request Message. 6

14.2 OTASP PUZL Download Request Processing 7

14.2.1 Definition 8

This test verifies a mobile station can initiate programming procedure and update its Preferred 9 User Zone List (PUZL). 10


(see [14]) 12



3.5.6 PUZL Parameter Blocks 15

3.5.7 Preferred User Zone List (PUZL) 16





4.5.6 PUZL Parameter Blocks 21


None 23




c. Setup a mobile station originated OTASP call using *228 + one of the System Selection 27

Codes in Table 14.1.4-1. 28





3GPP2 C.S0044-D v1.0

14-5

FEATURE_ID and FEATURE_P_REV as listed in ANNEX C. The Preferred User Zone 1

List feature support is required for this test. 2



= ’00000000’ and SPC = SCPp. 5




g. Instruct the base station to send a PUZL Configuration Request Message to the mobile 9

station with one of the following BLOCK_ID values: 10

11

PUZL Parameter Block Type BLOCK_ID

PUZL Dimensions ‘00000000’

PUZL Priorities ‘00000001’

User Zone ‘00000010’

Preferred User Zone List ‘00000011’

h. Verify the mobile station sends a PUZL Configuration Response Message within 750ms 12

with the BLOCK_ID and associated PARAM_DATA requested in the PUZL 13

Configuration Request Message. 14

i. Instruct the base station to send a PUZL Download Request Message with one or more 15

of the following PUZL Parameter Block Types and the corresponding PARAM_DATA: 16

17


User Zone Insert ‘00000000’

User Zone Update ‘00000001’

User Zone Delete ‘00000010’

User Zone Priority Change ‘00000011’

PUZL Flags ‘00000100’

j. Verify the mobile station sends a PUZL Download Response Message within 750ms 18

with the RESULT_CODE = ’00000000’ (Accepted – Operation Successful). 19

k. Instruct the base station to send a Commit Request Message to the mobile station. 20

l. Verify the mobile station sends a Commit Response Message to the base station within 21


m. End the call at the mobile station. 23

3GPP2 C.S0044-D v1.0

14-6

n. Verify the mobile station successfully stored the updated PUZL information. 1


The mobile station shall comply with steps e, h, j, l, and n. The mobile station shall update its 3 PUZL information as received in the PUZL Download Request Message. 4

14.3 OTASP 3GPD Download Request Processing 5

14.3.1 Definition 6

This test verifies a mobile station can initiate programming procedure and update its 3GPD 7 information. 8


(see [14]) 10



3.5.8 3GPD Parameter Blocks 13





4.5.7 3GPD Parameter Blocks 18


None 20










FEATURE_ID and FEATURE_P_REV as listed in ANNEX C. The 3G Packet Data 30

feature support is required for this test. 31


3GPP2 C.S0044-D v1.0

14-7


= ’00000000’ and SPC = SPCp. 2




g. Instruct the base station to send a 3GPD Configuration Request Message to the mobile 6

station with one or more of the following 3GPD Parameter Block Types from Table 7

14.3.4-1. If the 3GPD Parameter Block Type requests the shared secret do the 8

following prior to sending the 3GPD Configuration Request Message: 9

h. Instruct the base station to send a Secure Mode Request Message with 10

11

Field Value

START_STOP ‘1’

KEY_IN_USE ‘0000’ or ‘0001’

RAND_SM Randomly selected value

for SMCK

1. Verify the mobile station sends a Secure Mode Response Message within 750ms 12

with RESULT_CODE = ’00000000’ (Accepted – Operation Successful). 13

14

3GPP2 C.S0044-D v1.0

14-8

Table 14.3.4-1 1

3GPD Parameter Block Type BLOCK_ID

3GPD Operation Capability

Parameters

‘00000000’

3GPD Operation Mode

Parameters

‘00000001’

SimpleIP Capability Parameters ‘00000010’

MobileIP Capability Parameters ‘00000011’

SimpleIP User Profile Parameters ‘00000100’

Mobile IP User Profile Parameters ‘00000101’

SimpleIP Status Parameters ‘00000110’

MobileIP Status Parameters ‘00000111’

SimpleIP PAP SS Parameters1

‘00001000’

SimpleIP CHAP SS Parameters1 ‘00001001’

MobileIP SS Parameters1 ‘00001010’

HRPD Access Authentication

Capability Parameters

‘00001011’

HRPD Access Authentication User

Profile Parameters

‘00001100’


CHAP SS Parameters1

‘00001101’

1The shared secret parameters shall not be transmitted over the

air unencrypted.

2

i. Verify the mobile station sends a 3GPD Configuration Response Message within 3

750ms including each requested BLOCK_ID and associated PARAM_DATA with 4

corresponding RESULT_CODE. If SECURE_MODE_INDs = ‘1’, then: 5

1. Verify the mobile station includes the following in the 3GPD Configuration 6

Response Message: 7

3GPP2 C.S0044-D v1.0

14-9

Field Value

FRESH_INCL ‘1’

FRESH 15-bit value used for

encryption

j. Instruct the base station to send a 3GPD Download Request Message with one or more 1

of the 3GPD Parameter Block Types from Table 14.3.4-2 and the corresponding 2

PARAM_DATA. If SECURE_MODE_INDs = ‘1’, then: 3

1. Verify the base station includes the following in the 3GPD Download Request 4

Message: 5

6

Field Value

FRESH_INCL ‘1’

FRESH 15-bit value used for

encryption

7

3GPP2 C.S0044-D v1.0

14-10

Table 14.3.4-2 1


3GPD Operation Mode

Parameters

‘00000000’

SimpleIP User Profile Parameters ‘00000001’

Mobile IP User Profile Parameters ‘00000010’

SimpleIP Status Parameters ‘00000110’

MobileIP Status Parameters ‘00000111’

SimpleIP PAP SS Parameters1 ‘00001000’

SimpleIP CHAP SS Parameters1 ‘00001001’

MobileIP SS Parameters1 ‘00001010’

HRPD Access Authentication User

Profile Parameters

‘00001011’


CHAP SS Parameters1

‘00001100’

1The shared secret parameters shall not be transmitted over the

air unencrypted.

k. Verify the mobile station sends a 3GPD Download Response Message within 750ms 2


l. Instruct the base station to send a Commit Request Message to the mobile station. 4

m. Verify the mobile station sends a Commit Response Message to the base station within 5



o. Verify the mobile station successfully stored the 3GPD information. 8


The mobile station shall comply with steps e, h, k, m and o. If SECURE_MODE_IND = ‘1’, the 10 mobile station shall comply with step g. The mobile station shall update its 3GPD information as 11 received in the 3GPD Download Request Message. 12

14.4 OTASP SSPR Download Request Processing 13


This test verifies a mobile station can initiate programming procedure and update its preferred 15 roaming list. 16

3GPP2 C.S0044-D v1.0

14-11


(see [14]) 2



3.5.3 SSPR Parameter Blocks 5

3.5.5 Preferred Roaming List and Extended Preferred Roaming List 6







None 13




c. Setup a mobile originated OTASP call using *228 + one of the System Selection Codes 17

in Table 14.1.4-1. 18





FEATURE_ID and FEATURE_P_REV as listed in ANNEX C. The System Selection for 23

Preferred Roaming feature support is required for this test. 24



= ’00000000’ and SPC = SCPp. 27




g. Instruct the base station to send a SSPR Configuration Request Message to the mobile 31

station with one of the following SSPR Parameter Block Types: 32

33

3GPP2 C.S0044-D v1.0

14-12

SSPR Parameter Block Type BLOCK_ID

Preferred Roaming List

Dimensions

‘00000000’

Preferred Roaming List ‘00000001’

Extended Preferred Roaming List

Dimensions

‘00000010’

h. Verify the mobile station sends a SSPR Configuration Response Message within 1

750ms with the BLOCK_ID and the associated PARAM_DATA. 2

i. Instruct the base station to send a SSPR Download Request Message with one of the 3

following SSPR Parameter Block Types and the corresponding PARAM_DATA: 4

5


Preferred Roaming List ‘00000000’

Extended Preferred Roaming List

with SSPR_P_REV greater than

‘00000001’

‘00000001’

j. Verify the mobile station sends a SSPR Download Response Message within 750ms 6


k. Instruct the base station to send a Commit Request Message to the mobile station. 8

l. Verify the mobile station sends a Commit Response Message to the base station within 9


m. End the call at the mobile station. 11

n. Verify the mobile station successfully stored the updated SSPR information. 12


The mobile station shall comply with steps e, h, j, l, and n. The mobile station shall update its 14 SSPR information as received in the SSPR Download Request Message. 15

14.5 OTASP For System Selection and Preferred Roaming - Oversize PRL 16


This test verifies that the PRL resident in a handset shall not be replaced if a new PRL of illegal 18 size is downloaded. 19


(see [14]) 21


3GPP2 C.S0044-D v1.0

14-13









14.5.3 Call Flow 9

None 10










FEATURE_ID and FEATURE_P_REV as listed in ANNEX C. The System Selection for 20

Preferred Roaming feature support is required for this test. 21



= ’00000000’ and SPC = SCPp. 24




g. Instruct the base station to send a SSPR Configuration Request Message to the mobile 28

station. 29

h. Verify the mobile station sends a SSPR Configuration Response Message within 30

750ms with the requested BLOCK_ID and the associated PARAM_DATA. 31

i. Instruct the base station to send a SSPR Download Request Message to the mobile 32

station with values of SEGMENT_OFFSET in conjunction with SEGMENT_SIZE that 33

are inconsistent with the preferred roaming list storage capabilities of the mobile station. 34

j. Verify the mobile station sends a SSPR Download Response Message with 35

RESULT_CODE = ’00001000’ (Rejected – Preferred roaming list length mismatch). 36

3GPP2 C.S0044-D v1.0

14-14

k. Verify the mobile station does not transfer its new PR_LIST to semi-permanent memory 1

after receiving a Commit Request Message. 2

l. End call at the mobile station 3


The mobile station shall comply with step h, j, and k. The mobile station shall retain its original 5 PRL. 6

14.6 OTAPA Download Request Processing 7

14.6.1 Definition 8

This test verifies that the mobile station supports network initiated Over-the-Air-Parameter-9 Administration (OTAPA). This test also verifies the mobile station’s download request processing 10 is successful. 11

14.6.2 Traceability (see [14]) 12

3.2.2 Network-Initiated Procedure 13

3.4 Termination of the Programming Procedure 14










None 24




c. Initiate an OTAPA session from the base station by sending a General Page Message 28

to the mobile station with the SERVICE_OPTION = 0x12 or 0x13. 29

d. Verify that the mobile station sends a Page Response Message with 30

SERVICE_OPTION = 0x12 or 0x13. 31

e. Upon successful call setup, instruct the base station to send an OTAPA Request 32

Message to the mobile station with START_STOP = ’1’. 33

3GPP2 C.S0044-D v1.0

14-15

f. Verify the mobile station sends an OTAPA Response Message to the base station 1

within 750 ms with RESULT_CODE = ’00000000’ (Accepted – Operation Successful). If 2

NAM_LOCK_IND = ’1’ in the OTAPA Response Message, perform the following: 3

1. Verify the RAND_OTAPA field is present in the OTAPA Response Message. 4

2. Instruct the base station to sends a Validation Request Message with BLOCK_ID 5

= ’00000010’ (Validate SPASM) and a SPASM Parameter Block present to the 6

mobile station. 7

3. Verify the mobile station sends a Validation Response Message to the base 8

station within 750 ms, and with BLOCK_ID = ’00000010’ (Validate SPASM) and 9

RESULT_CODE = ’00000000’ (Accepted – Operation Successful). 10

g. Instruct the base station to send a Protocol Capability Request Message to the mobile 11

station. 12

h. Verify the mobile station sends a Protocol Capability Response Message to the base 13


FEATURE_ID and FEATURE_P_REV as listed in ANNEX C. 15

i. If Service Programming Lock is supported, perform the following: 16


= ’00000000’ and SPC = SPCP. 18




3. Verify the base station sends a Validation Request Message with BLOCK_ID = 22

’00000001’ (Change SPC) and SPC = {a new SPC}. 23


and with BLOCK_ID = ’00000001’ (Change SPC) and RESULT_CODE = 25

’00000000’ (Accepted – Operation Successful). 26

j. If the Electronic Key Exchange is not supported, go to step k; otherwise: 27

1. Instruct the base station to send a Mobile Station Key Request Message to the 28

mobile station. 29

2. Verify the mobile station responds with the Mobile Station Key Response 30

Message within 30 seconds, with RESULT_CODE = '00000000' (Accepted - 31

Operation Successful). 32

3. Instruct the base station to send a Key Generation Request Message to the 33

mobile station. 34

4. Verify the mobile station responds with the Key Generation Response Message 35

within 30 seconds and the RESULT_CODE = '00000000' (Accepted - Operation 36

Successful). 37

5. Verify the base station and the mobile station successfully perform SSD update 38

procedures. 39

3GPP2 C.S0044-D v1.0

14-16

6. Verify the base station sends the Re-Authenticate Request Message and the 1

mobile station responds with the Re-Authenticate Response Message. 2

7. At the base station verify Re-Authentication is successful. 3

8. The base station may enable Signaling Message Encryption and Voice Privacy. 4

k. Instruct the base station to send a Configuration Request Message with one or more of 5

the following NAM Parameter Block Types: 6

7




CDMA NAM ‘00000010’

IMSI_T ‘00000011’

l. Verify the mobile station sends a Configuration Response Message within 750ms 8

including each requested BLOCK_ID and associated PARAM_DATA with 9

corresponding RESULT_CODE. 10

m. Instruct the base station to send a Download Request Message with one or more of the 11

following NAM Parameter Block Types and the corresponding PARAM_DATA: 12

13




CDMA NAM ‘00000010’

IMSI_T ‘00000011’

n. Verify that the mobile station sends a Download Response Message and that 14

RESULT_CODE = '00000000' (Accepted- Operation Successful) within 750ms. 15

o. Instruct the base station to send a Commit Request Message to the mobile station. 16

p. Verify the mobile station sends a Commit Response Message to the base station within 17


q. Instruct the base station to send an OTAPA Request Message to the mobile station with 19

START_STOP = ’0’. 20

r. Verify the mobile station sends an OTAPA Response Message to the base station 21

within 750 ms, and with RESULT_CODE = ’00000000’ (Accepted – Operation 22

Successful) and NAM_LOCK_IND = ’0’. 23

s. Verify that the mobile station releases the call. 24

3GPP2 C.S0044-D v1.0

14-17

t. Verify the mobile station successfully stored the updated NAM information. 1

u. Originate a call from the mobile station and verify user traffic is present. 2

v. End the call. 3

w. Setup a mobile station originated call. 4

x. Repeat steps e through u with the mobile station already in the Conversation Substate. 5


The mobile station shall comply with steps d, f, h, l, n, p, r, and t. If supported the mobile station 7 shall comply with steps i and l. 8

14.7 Call Origination during an OTAPA Download Session 9


This test verifies that the mobile station is able to originate a voice call during an OTAPA 11 download session. 12


(see [14]) 14








None 22




c. Initiate an OTAPA session from the base station by sending a General Page Message 26

to the mobile station with the SERVICE_OPTION = 0x12 or 0x13. 27

d. Verify that the mobile station sends a Page Response Message with 28

SERVICE_OPTION = 0x12 or 0x13. 29

e. Upon successful call setup, instruct the base station to send an OTAPA Request 30

Message to the mobile station with START_STOP = ’1’. 31

3GPP2 C.S0044-D v1.0

14-18

f. Verify the mobile station sends an OTAPA Response Message to the base station 1

within 750 ms with RESULT_CODE = ’00000000’ (Accepted – Operation Successful). If 2

NAM_LOCK_IND = ’1’ in the OTAPA Response Message, perform the following: 3

1. Verify the RAND_OTAPA field is present in the OTAPA Response Message. 4


= ’00000010’ (Validate SPASM) and a SPASM Parameter Block present to the 6

mobile station. 7

3. Verify the mobile station sends a Validation Response Message to the base 8

station within 750 ms, and with BLOCK_ID = ’00000010’ (Validate SPASM) and 9

RESULT_CODE = ’00000000’ (Accepted – Operation Successful). 10

g. Instruct the base station to send a Protocol Capability Request Message to the mobile 11

station. 12

h. Verify the mobile station sends a Protocol Capability Response Message to the base 13


FEATURE_ID and FEATURE_P_REV as listed in ANNEX CY. 15

i. Originate a voice call from the mobile station. 16

j. Verify user data in both directions. 17

k. End call at the mobile station. 18


The mobile station shall comply with steps d, f, h, and j. 20

3GPP2 C.S0044-D v1.0

15-1

15 POSITION DETERMINATION TESTS 1

The position determination tests in this section apply to mobile stations and base stations that can 2 operate in various modes including GPS (Global Positioning System), AFLT (Advanced Forward 3 Link Trilateration), and Hybrid (GPS and AFLT). Note that for mobile stations that are capable of 4 calculating their location based on AFLT, that capability is not verified in this test. 5

15.1 Position Determination Tests for GPS, AFLT and Hybrid 6

15.1.1 Definition 7

The purpose of this test is to determine the interoperability of mobile station and base station 8 position determination sessions. This test requires that a network originated position 9 determination session be triggered by a mobile station originated call. 10


(see [25]) 12

3.2.1 Position Determination Data Message Processing 13

3.2.2 Point-to-point Procedures 14

3.2.4 Reverse Link Message Format 15

3.2.4.2 Response Element Response Type 16

Annex B Request/Response Element Types 17

15.1.3 15.1.3 Call Flow Example(s) 18

None 19

15.1.4 15.1.4 Method of Measurement 20

a. Configure 3 base stations available to the mobile station. Ensure connectivity of the 21

base stations to a PDE. The base stations and the PDE shall be configured to allow a 22

specific mobile station originated call type to trigger the PDE to start a position 23

determination session with the mobile station (e.g. an emergency call; in the U.S. this 24

would be a 9-1-1 call). 25

b. Allow the mobile to become idle on the base station with a dominant PN, with mobile 26

CDMA receive power greater than -85 dBm and pilot Ec/Io greater than -12 dB. 27

c. If the mobile station and base station supports GPS position location, allow the mobile 28

station to receive GPS signals each with a power level of at least -130 dBm/1MHz. The 29

number of simulated GPS satellites shall be 4 or greater. 30

d. Setup a mobile station originated call using a dialed number or Service Option that 31

triggers the PDE to start a position determination session (e.g. an emergency call; in 32

the U.S. this would be a 9-1-1 call). 33

e. Verify the call completes. 34

f. Verify steps g through n. Note that the ordering of steps g through n does not represent 35

a required ordering of call flow events during the test. In addition to the messages 36

3GPP2 C.S0044-D v1.0

15-2

listed in steps g through n, there may be other position determination request elements 1

and response elements exchanged between the base station and mobile station during 2

the test. 3

g. If the base station sends a position determination Data Burst Message with burst type 4

‘000101’ that includes a Position Determination Data Message with Request Mobile 5

Station Information (REQ_TYPE = ‘0010’), verify the mobile station sends a position 6

determination Data Burst Message with a burst type ‘000101’ that includes a Position 7

Determination Data Message with Provide Mobile Station Information (RESP_TYPE = 8

‘0010’). 9

h. If the mobile station and base station supports GPS position determination and the 10

base station has previously set GPSC_ID to ‘1’ in the Provide Base Station Capability, 11

and if the mobile station has sent a position determination Data Burst Message with 12

burst type ‘000101’ that includes a Position Determination Data Message with Request 13

GPS Acquisition Assistance (REQ_TYPE = ‘0100’), verify the base station sends a 14

position determination Data Burst Message with a burst type ‘000101’ that includes a 15

Position Determination Data Message with Provide GPS Acquisition Assistance 16

(RESP_TYPE = ‘0100’) or a Reject Message with REJ_REASON set to ‘001’. 17

i. If the mobile station and base station supports GPS position determination and the 18




GPS Sensitivity Assistance (REQ_TYPE = ‘0101’), verify the base station sends a 22

position determination Data Burst Message with a burst type ‘000101’, that includes a 23

Position Determination Data Message with Provide GPS Sensitivity Assistance 24

(RESP_TYPE = ‘0101’) or a Reject Message with REJ_REASON set to ‘001’. 25

j. If the mobile station and base station supports GPS position determination and the 26




GPS Almanac (REQ_TYPE = ‘1000’), verify the base station sends a position 30

determination Data Burst Message with a burst type ‘000101’ that includes a Position 31

Determination Data Message with Provide GPS Almanac (RESP_TYPE = ‘1000’) or a 32

Reject Message with REJ_REASON set to ‘001’. 33

k. If the mobile station and base station supports GPS position determination and the 34

base station has previously set GPSC_ID to ‘1’ in the Provide Base Station Capability,, 35



GPS Ephemeris (REQ_TYPE = ‘1001’), verify the base station sends a position 38

determination Data Burst Message with a burst type ‘000101’, that includes a Position 39

Determination Data Message with Provide GPS Ephemeris (RESP_TYPE = ‘1001’) or a 40

Reject Message with REJ_REASON set to ‘001’. 41

l. If the mobile station and base station supports GPS position determination, and the 42

mobile station is capable of calculating its position based on GPS measurements as 43

3GPP2 C.S0044-D v1.0

15-3

indicated by LOC_CALC_CAP (Position Calculation Capability) field in the Provide 1

Mobile Station Information Response Element, and the base station has sent a position 2

determination Data Burst Message with burst type ‘000101’ that includes a Position 3

Determination Data Message with Request Location Response (REQ_TYPE = ‘0001’), 4

verify the mobile station sends a position determination Data Burst Message with a 5

burst type ‘000101’, that includes a Position Determination Data Message with Provide 6

Location Response (RESP_TYPE = ‘0001‘). 7

m. If the mobile station and base station supports GPS position determination, and the 8

base station has sent a position determination Data Burst Message with burst type 9

‘000101’ that includes a Position Determination Data Message with Request 10

Pseudorange Measurement (REQ_TYPE = ‘0100’), verify the mobile station sends a 11

position determination Data Burst Message with a burst type ‘000101’, that includes a 12

Position Determination Data Message with Provide Pseudorange Measurement 13

(RESP_TYPE = ‘0100‘). 14

n. If the base station supports AFLT position determination, and the base station has sent 15

a position determination Data Burst Message with burst type ‘000101’ that includes a 16

Position Determination Data Message with Request Pilot Phase Measurement 17

(REQ_TYPE = ‘0101’), verify the mobile station sends a position determination Data 18

Burst Message with a burst type ‘000101’, that includes a Position Determination Data 19

Message with Provide Pilot Phase Measurement (RESP_TYPE = ‘0101‘). 20


The mobile station and base station shall comply with the requirements in the following steps: 22

For GPS position location the base station shall comply with steps h, i, j, k, l and the mobile 23 station shall comply with steps g, l and m. 24

For AFLT position location the base station shall comply with step l and the mobile station shall 25 comply with steps g and n. 26

For Hybrid position location the base station shall comply with steps h, i, j, and k, and the mobile 27 station shall comply with steps g, l, m, and n. 28

29

30

3GPP2 C.S0044-D v1.0

15-4


3GPP2 C.S0044-D v1.0

16-1

16 CONCURRENT SERVICES 1

16.1 Setup Mobile Station Originated Data Call while Voice Call or Teleservice Call is in 2

Progress 3

16.1.1 Definition 4

This test verifies that, when a voice call is already in progress, a mobile station originated data 5 call or teleservice call can be established successfully. 6


(see [4]) 8

2.6.4.1.2.2.5 Waiting for Service Action Time Subfunction) 9

2.6.4.1.12 Processing the Service Configuration Record) 10




2.6.10 Call Control Processing 14


2.7.2.3.2.32 Enhanced Origination Message 16

2.7.2.3.2.33 Extended Flash With Information Message 17

2.7.2.3.2.37 Call Cancel Message 18

2.7.2.3.2.29 Resource Release Request Message 19

2.7.2.3.2.30 Resource Release Request Mini Message 20

2.7.3.4 Mobile Station Reject Order 21

2.7.4.25 Capability Information 22

3.6.4.1.7 Response to Enhanced Origination Message 23

3.6.4.1.8 Processing Resource Release Request Message and Resource Release 24

Request Mini Message 25



3.6.8 Call Control Processing 28


3.7.2.3.2.30 ANSI-41 System Parameters Message 30



3GPP2 C.S0044-D v1.0

16-2


3.7.3.3.2.43 Call Assignment Message 2

3.7.3.3.2.44 Extended Alert With Information Message 3



Enhanced Origination Message

(Data SOY, TAG

Y)

SCM / GHDM / UHDM

(SCR += (Data SOY, CON_REF

Y)

BSMS

Traffic Traffic

TrafficTraffic

Call Assignment Message

(RESPONSE_IND=1,

TAGY, CON_REF

Y)

SCM/ UHDM

(CC_INFO_INCL=1,

RESPONSE_IND=1, TAGY

SCR += (Data SOY, CON_REF

Y))

OR

MS initiates data

calll setup

Voice Call in Progress

Voice & Data

Call in Progress

6



b. Setup a voice call as described in Test and wait until the voice call is in progress. 9

c. Ensure retry delay for call origination (i.e. RETRY_DELAYs[001]) is currently not set for 10

the data service option. 11

d. Initiate a packet data call (e.g. SO33) at the mobile station. Verify the following: 12

1. The mobile station sends an Enhanced Origination Message with the following 13

fields set as follows: 14

3GPP2 C.S0044-D v1.0

16-3

FIELD VALUE

TAG ‘0001’

SR_ID ‘001’ or ‘010’.

SERVICE_OPTION Service Option corresponding to the data call (e.g. SO33)

DRS ‘1’ (data ready to send)

e. Configure the base station to accept the call origination from the mobile station. Verify 1

that base station follows one of the following two sequences of events to establish the 2

data call: 3

1. The base station sends the call assignment prior to service option connection 4

establishment as follows: 5

a. The base station sends a Call Assignment Message to the mobile 6

station, prior to the expiration of the enhanced origination timer at the 7

mobile station, with the following fields set as follows: 8

FIELD VALUE

RESPONSE_IND ‘1’ (Response to mobile station call request)

TAG Value received in the Enhanced Origination Message

ACCEPT_IND ‘1’ (call request accepted)

CON_REF Connection reference value for this call

9

b. Upon successful call assignment, service negotiation is initiated to 10

establish the service option connection corresponding to this call 11

assignment, as follows: 12

1. The service negotiation is terminated via sending a Service 13

Connect Message, General Handoff Direction Message 14

(containing a SCR), or Universal Handoff Direction Message 15

(containing a SCR). 16

2. If the Service Connect Message or the Universal Handoff 17

Direction Message is used to terminate the service negotiation, 18

the call assignment included (CC_INFO_INCL) field is set to ‘0’ 19

in these messages. 20

3GPP2 C.S0044-D v1.0

16-4

3. The service option connection is established with the same 1

connection reference (CON_REF) as used in the corresponding 2

Call Assignment Message. 3

c. After the action time of the message used to establish the service 4

option connection corresponding to this call, data call user traffic is 5

exchanged successfully. 6

d. The voice call is not dropped. 7

2. The base station sends the call assignment as part of the service option 8

connection establishment as follows: 9

a. The base station initiates service negotiation to establish the service 10

option connection and assign the call. The service negotiation is 11

terminated via sending a Service Connect Message or Universal 12

Handoff Direction Message (containing a SCR) with the following fields 13

set as follows: 14

15

FIELD VALUE

CC_INFO_INCL ‘1’ (call assignment included)

NUM_CALLS_ASSIGN ‘00000001’ (single call assignment)

CON_REF Connection reference corresponding to this call set to the same value as used in the SCR.


TAG Value received in the Enhanced Origination Message

16

b. After the action time of the message used to establish the service 17



c. The voice call is not dropped. 20

f. Repeat steps b to e with the following modifications: 21

1. In step b, setup a teleservice call (e.g. SMS, Position Determination, etc.) 22

requiring dedicated channels. 23

2. In step e, the teleservice call is not dropped after the establishment of the data 24

call. 25

3GPP2 C.S0044-D v1.0

16-5


The mobile station and base station shall comply with the requirements in the following steps d, e 2 and f. 3

16.2 Setup Mobile Station terminated Data Call while Voice Call or Teleservice Call is in 4

Progress 5

16.2.1 Definition 6

This test verifies that, when a voice call is already in progress, a mobile station terminated data 7 call (for a dormant data session) or teleservice call can be established successfully. 8


See 16.1.2. 10


12

SCM / GHDM / UHDM

(SCR += (Data SOY, CON_REF

Y)

BSMS

Traffic Traffic

TrafficTraffic


(RESPONSE_IND=0,

Data SOY, CON_REF

Y)

SCM/ UHDM

(CC_INFO_INCL=1,

RESPONSE_IND=0,

SCR += (Data SOY, CON_REF

Y))

OR

Network initiates

data calll setup

(for a dormant

data session)


Voice & Data

Call in Progress

13

14

3GPP2 C.S0044-D v1.0

16-6



b. Setup a packet data call (e.g. SO33). Ensure that the data call transitions to the 3

dormant state. Ensure that the dedicated traffic channels are released. 4

c. Setup a voice call and wait until the voice call is in progress. 5

d. Trigger network-initiated transition to active state for the dormant packet data call. 6

Verify that base station follows one of the following two sequence of events to establish 7

the data call: 8




station with the following fields set as follows: 12

FIELD VALUE

RESPONSE_IND ‘0’ (base station initiated call

assignment)

BYPASS_ALERT_ANSWER ‘1’ (since data call)

SO Service option number corresponding

to the data service (e.g. SO33)



















d. The voice call is not dropped. 30

3GPP2 C.S0044-D v1.0

16-7







set as follows: 7

Field Value



CON_REF Connection reference corresponding to this

call set to the same value as used in the

SCR.

RESPONSE_IND ‘0’ (base station initiated call assignment)

BYPASS_ALERT_ANSWER ‘1’ (since data call)




c. The voice call is not dropped. 11

e. Repeat steps b to d with the following modifications: 12



2. In step d, the teleservice call is not dropped after the establishment of the data 15

call. 16


The mobile station and base station shall comply with the requirements in steps d and e. 18

16.3 Setup Mobile Station Originated Voice Call while Data Call or Teleservice Call is in 19

Progress 20


This test verifies that, when a data call or Teleservice is already in progress, a mobile station 22 originated voice call or teleservice call can be established successfully. 23


See 16.1.2. 25

3GPP2 C.S0044-D v1.0

16-8


Enhanced Origination Message

(Voice SOY, TAG

Y)

SCM / GHDM / UHDM

(SCR += (Voice SOY, CON_REF

Y)

BSMS

Traffic Traffic

TrafficTraffic


(RESPONSE_IND=1,

TAGY, CON_REF

Y)

SCM / UHDM

(CC_INFO_INCL=1,

RESPONSE_IND=1, TAGY

SCR += (Voice SOY, CON_REF

Y))

OR

MS initiates voice

calll setup


Voice & Data

Call in Progress

2



b. Setup a packet data call (e.g. SO33 as described in test case 13.2). Wait until the data 5

call is in progress. Ensure sufficient traffic is exchanged to keep the data instance in 6

active state. 7

c. Initiate a voice call at the mobile station. Verify the following: 8

1. The mobile station sends an Enhanced Origination Message with the following 9

fields set as follows: 10

3GPP2 C.S0044-D v1.0

16-9

Field Value

TAG ‘0001’

SR_ID ‘010’

SERVICE_OPTION Service Option corresponding to the

voice call (Ex. SO 3)

1

d. Configure the base station to accept the call origination from the mobile station. Verify 2

that base station follows one of the following two sequence of events to establish the 3

voice call: 4




station, prior to the expiration of the enhanced origination timer at the 8

mobile station, with the following fields set as follows: 9

10

Field Value

RESPONSE_IND ‘1’ (Response to mobile station call

request)

TAG Value received in the Enhanced

Origination Message

ACCEPT_IND ‘1’ (call request accepted)


11












3GPP2 C.S0044-D v1.0

16-10





option connection corresponding to this call, voice call user traffic is 5


d. The data call is not dropped. 7







set as follows: 14

Field Value



CON_REF Connection reference corresponding to this

call set to the same value as used in the

SCR.


TAG Value received in the Enhanced Origination

Message

15


option connection corresponding to this call, voice call user traffic is 17


c. The data call is not dropped. 19

e. Repeat steps b to d with the following modifications: 20



2. In step d, the teleservice call is not dropped after the establishment of the data 23

call. 24


The mobile station shall comply with the requirements in steps c, d and e. 26

The base station shall comply with the requirements in step d. 27

3GPP2 C.S0044-D v1.0

16-11

1

16.4 Setup Mobile Station terminated Voice Call while Data Call or Teleservice Call is in 2

Progress 3

16.4.1 Definition 4

This test verifies that, when a data call or Teleservice is already in progress, a mobile station 5 terminated voice call or teleservice call can be established successfully. 6


See 16.1.2. 8


SCM / GHDM / UHDM

(SCR += (Voice SOY, CON_REF

Y)

BSMS

Traffic Traffic

TrafficTraffic


(RESPONSE_IND=0,

Voice SOY, CON_REF

Y)

SCM/UHDM

(CC_INFO_INCL=1,

RESPONSE_IND=0,

SCR += (Voice SOY, CON_REF

Y))

OR

Network initiates

voice call setup


Voice & Data

Call in Progress

AWIM / EAWIM

Connect Order

10

11



3GPP2 C.S0044-D v1.0

16-12

b. Setup a packet data call (e.g. SO33 a described in test case 13.2). Wait till the data call 1

is in progress. Ensure sufficient traffic is exchanged to keep the data instance in active 2

state. 3

c. Trigger a network-initiated voice call. Verify that base station follows one of the 4

following two sequences of events to establish the voice call: 5




station with the following fields set as follows: 9

10 11

Field Value


BYPASS_ALERT_ANSWER ‘0’ (since voice call)

SO Service option number corresponding to the voice service (Ex. SO 3)

















option connection corresponding to this call, the mobile station plays 27

an alert to indicate an incoming call. After answering the call from the 28

mobile station, voice call user traffic is exchanged successfully. 29

d. The data call is not dropped. 30

3GPP2 C.S0044-D v1.0

16-13







set as follows: 7

Field Value



CON_REF Connection reference corresponding to this call set to the same value as used in the SCR.


BYPASS_ALERT_ANSWER ‘0’ (since voice call)

8


option connection corresponding to this call, the mobile station plays 10

an alert to indicate an incoming call. After answering the call from the 11

mobile station, voice call user traffic is exchanged successfully. 12

c. The data call is not dropped. 13

d. Repeat steps b and c with the following modifications: 14



2. In step c, the teleservice call is not dropped after the establishment of the data 17

call. 18


The mobile station and base station shall comply with the requirements in steps c and d. 20

21

16.5 Mobile Station Release of a Single Call While Voice and Data Calls are in Progress 22


This test verifies that, when both voice and data calls are in progress, mobile station can release 24 one of the calls successfully and the other call continues uninterrupted. 25

3GPP2 C.S0044-D v1.0

16-14


See 16.1.2. 2


SCM / GHDM / UHDM

(SCR -= CON_REFY)

BSMS

Traffic Traffic

TrafficTraffic

MS initiates

release of one of

the calls

Voice & Data Calls

in Progress

Remaining Call Continues

Service Request Message

( SCR -= CON_REFY)

Resource Release Request Message

(CON_REFY)

or

4



b. Setup both a voice call and a packet data call (e.g. SO33). Wait till both the voice call 7

and the data call are in progress. Ensure sufficient traffic is exchanged to keep the data 8

instance in active state. 9

c. Initiate the release of the voice call at the mobile station. Verify the following: 10

1. The mobile station sends a Service Request Message or Resource Release 11

Request (Mini) Message requesting the release of the voice call. 12

a. If the mobile station sends a Service Request Message, the service 13

option connection record corresponding to the voice call is omitted 14

from the Service Configuration information record included in this 15

message. 16

3GPP2 C.S0044-D v1.0

16-15

b. If the mobile station sends a Resource Release Request (Mini) 1

Message, the following fields shall be set as follows: 2

3

Field Value

GATING_DISCONNECT_IND ‘0’ (release of a call requested)

CON_REF Connection reference corresponding to the voice call to be released

2. Upon receiving the Service Request Message or Resource Release Request 4

(Mini) Message requesting the release of the voice call, the base station sends a 5

Service Connect Message, General Handoff Direction Message (with a SCR), or 6

Universal Handoff Direction Message (with a SCR) as follows: 7

a. The service option connection record corresponding to the voice call is 8

omitted from the Service Configuration information record included in 9

this message. 10

3. At the action time of the Service Connect Message, General Handoff Direction 11

Message, or Universal Handoff Direction Message used to release the voice call, 12

the voice traffic no longer flows. 13

4. The data call is not dropped. 14

d. Repeat steps a though c with the following exception: in step c, initiate the release of 15

the data call at the mobile station. All the expected results are as in step c with the 16

difference that the call being released is the data call. 17


The mobile station and base station shall comply with the requirements in step c and d. 19

16.6 Base Station Release of a Single Call While Voice and Data Calls are in Progress 20


This test verifies that, when both voice and data calls are in progress, base station can release 22 one of the calls successfully and the other call continues uninterrupted. 23


See 16.1.2. 25

3GPP2 C.S0044-D v1.0

16-16


SCM / GHDM / UHDM

(SCR -= CON_REFY)

BSMS

Traffic Traffic

TrafficTraffic

Network initiates

release of one of

the calls

Voice & Data Calls

in Progress

Remaining Call Continues

2



b. Setup both a voice call and a packet data call (e.g. SO33). Wait till both the voice call 5

and the data call are in progress. Ensure sufficient traffic is exchanged to keep the data 6

instance in active state. 7

c. Trigger a network-initiated release of the voice call. Verify the following: 8

1. The base station sends a Service Connect Message, General Handoff Direction 9

Message (with a SCR), or Universal Handoff Direction Message (with a SCR), 10

where the service option connection record corresponding to the voice call is 11

omitted from the Service Configuration information record included in this 12

message. 13

2. At the action time of the Service Connect Message, General Handoff Direction 14

Message, or Universal Handoff Direction Message used to release the voice call, 15

the voice traffic no longer flows. 16

3. The data call is not dropped. 17

3GPP2 C.S0044-D v1.0

16-17

d. Repeat steps a though c with the following exception: in step c, initiate the release of 1

the data call at the mobile station. All the expected results are as in step c with the 2

difference that the call being released is the data call. 3


The mobile station and base station shall comply with the requirements in steps c and d. 5

16.7 Correct Handling of Call Control Signaling 6

16.7.1 Definition 7

This test verifies that, when one or more calls are in progress, mobile station initiated and network 8 initiated call control signaling messages are handled correctly. 9


See 16.1.2. 11

3GPP2 C.S0044-D v1.0

16-18


BSMS

Traffic Traffic

TrafficTraffic


FWIM /

EFWIM (CON_REFINCL=0) /

EFWIM (CON_REFVOICE

)

FWIM /


EFWIM (CON_REFVOICE

)

Add data call:

Voice & Data Calls in Progress

FWIM /


EFWIM (CON_REFVOICE

)

FWIM /


EFWIM (CON_REFVOICE

)

EFWIM (CON_REFVOICE

)

EFWIM (CON_REFVOICE

)

Release Data Call:


FWIM /


EFWIM (CON_REFVOICE

)

FWIM /


EFWIM (CON_REFVOICE

)

If voice SOC listed first in SCR:

If data SOC listed first in SCR:

2

3



b. Setup a voice call and wait until the voice call is in progress. 6

3GPP2 C.S0044-D v1.0

16-19

c. If applicable, trigger an action at the mobile station that will result in either a Flash With 1

Information Message or Extended Flash With Information Message for a voice call 2

being transmitted to the base station (Ex. Trigger an action that utilizes the Keypad 3

Facility information record). Verify the following: 4

1. The mobile station sends a Flash With Information Message, an Extended Flash 5

With Information Message with the CON_REF_INCL field set to ‘0’, or an 6

Extended Flash With Information Message with the CON_REF field set to the 7

connection reference corresponding to the voice call. 8

2. The information record is delivered correctly in the network. 9

d. If applicable, trigger an action at the network that will result in either a Flash With 10

Information Message or Extended Flash With Information Message being transmitted to 11

the mobile station (e.g. Trigger an action that utilizes the Display information record). 12


1. The base station sends a Flash With Information Message, an Extended Flash 14




2. The information record is correctly handled in the mobile station. 18

e. Setup a mobile station originated or mobile station terminated packet data call (e.g. 19

SO33). When the base station sends a Service Connect Message, General Handoff 20

Direction Message, or Universal Handoff Direction Message to establish the service 21

option connection corresponding to the data call, note whether the service option 22

connection corresponding to the voice call or data call is listed as the first entry in the 23

SCR. 24

f. If applicable, trigger an action at the mobile station that will result in either a Flash With 25




1. If the service option connection corresponding to the voice call is listed as the 29

first entry in the SCR: 30

a. The mobile station sends a Flash With Information Message, an 31

Extended Flash With Information Message with the CON_REF_INCL 32

field set to ‘0’, or an Extended Flash With Information Message with 33

the CON_REF field set to the connection reference corresponding to 34

the voice call. 35

b. The information record is delivered correctly in the network. 36

2. If the service option connection corresponding to the data call is listed as the first 37

entry in the SCR: 38

a. The mobile station sends an (Extended) Flash With Information 39

Message with the CON_REF field set to the connection reference 40

corresponding to the voice call. 41

3GPP2 C.S0044-D v1.0

16-20

b. The information record is delivered correctly in the network. 1

g. If applicable, trigger an action at the network that will result in either a Flash With 2


being transmitted to the mobile station (Ex. Trigger an action that utilizes the Display 4

information record). Verify the following: 5

1. If the service option connection corresponding to the voice call is listed as the 6

first entry in the SCR: 7

a. The base station sends a Flash With Information Message, an 8

Extended Flash With Information Message with the CON_REF_INCL 9

field set to ‘0’, or an Extended Flash With Information Message with 10

the CON_REF field set to the connection reference corresponding to 11

the voice call. 12

b. The information record is correctly handled in the mobile station. 13

2. If the service option connection corresponding to the data call is listed as the first 14

entry in the SCR: 15

a. The base station sends an Extended Flash With Information Message 16

with the CON_REF field set to the connection reference corresponding 17

to the voice call. 18

b. The information record is correctly handled in the mobile station. 19

h. Perform a mobile station initiated or base station initiated release of the data call. Wait 20

till this operation is successful. 21

i. If applicable, trigger an action at the mobile station that will result in either a Flash With 22




1. The mobile station sends a Flash With Information Message, an Extended Flash 26




2. The information record is delivered correctly in the network. 30

j. If applicable, trigger an action at the network that will result in either a Flash With 31

Information Message or Extended Flash With Information Message being transmitted to 32

the mobile station for a voice call (Ex. Trigger an action that utilizes the Display 33

information record). Verify the following: 34

1. The base station sends a Flash With Information Message, an Extended Flash 35




2. The information record is correctly handled in the mobile station. 39

3GPP2 C.S0044-D v1.0

16-21


The mobile station and base station shall comply with the requirements in steps c, d, f, g, i and j,. 2

The base station shall comply with the requirements in steps d, g, and j. 3

16.8 Analog Handoff Direction Message Terminates All Calls Except One 4

16.8.1 Definition 5

This test verifies that, when the base station directs the mobile station to perform a handoff from 6 the CDMA system to an analog system by sending an Analog Handoff Direction Message, all 7 calls except for the one indicated by the Analog Handoff Direction Message are terminated. 8


See 16.1.2. 10


BSMS

Traffic Traffic

Analog

Voice + Data calls in progress

Analog Handoff Direction Message

(CON_REFX)MS terminates all calls

except one identified by

CON_REFX

Single call continues

12



b. Setup a voice call and a packet data call (e.g. SO33). Wait till both calls are in progress. 15

Note whether the service option connection corresponding to the voice call or data call 16

is listed as the first entry in the Service Configuration Information Record. 17

c. Trigger the network to direct the mobile station to perform a handoff from the CDMA 18

system to an analog system in a band class that the mobile station supports and to 19

maintain the voice call. Verify the following: 20

1. The base station sends an Analog Handoff Direction Message to the mobile 21

station, with the CON_REF_INCL/CON_REF fields set as follows: 22

3GPP2 C.S0044-D v1.0

16-22

a. If the service option connection corresponding to the voice call was 1

listed as the first entry in the Service Configuration information record, 2

then either the CON_REF_INCL field is set to ‘0’ or the CON_REF field 3

is set to the connection reference of the voice call. 4

b. If the service option connection corresponding to the data call was 5

listed as the first entry in the Service Configuration information record, 6

then the CON_REF field is set to the connection reference of the voice 7

call. 8

2. Upon receiving this message, the mobile station performs the following: 9

a. The mobile station terminates the data call and maintains the voice 10

call. 11

b. The mobile station shall perform handoff to the analog system 12

indicated by the Analog Handoff Direction Message. 13


The mobile station and base station shall comply with the requirements in step c. 15

16.9 Release A Mobile Station in Concurrent Calls with a Release A Base Station Hands 16

off to Pre-Release A Base Station 17


This test verifies that, when a Release A mobile station currently in concurrent calls with a 19 Release A base station is handed off to a Pre-Release A base station, only a single call is 20 maintained and this call continues successfully. 21


See 16.1.2. 23


MS

(Rel A)

Traffic

Voice + Data calls

in progress

GHDM/UHDM

(P_REV<7,

SCR_new: Voice or Data)

Voice or data

call is released

as instructed in

the new SCR

BS

(Pre-Rel A)

Voice or Data call in progress

BS

(Rel A)

25 26

3GPP2 C.S0044-D v1.0

16-23


a. Connect a MOB_P_REV 7 mobile station to base stations 1 and 2 as in Figure A-5. 2

Configure base station 1 to support P_REV=7 and base station 2 to support P_REV<7. 3

b. Setup a mobile station originated or mobile station terminated voice call on base station 4

1. 5

c. Set up a mobile station originated or mobile station terminated packet data call (e.g. 6

SO33). Wait till both voice and data calls are in progress. Ensure sufficient traffic is 7

exchanged to keep the data instance in active state. 8

d. Trigger base station 1 to direct the mobile station to handoff to base station 2. Verify the 9

following: 10

1. The base station shall send a General Handoff Direction Message or a Universal 11

Handoff Direction Message to the mobile station, with the Service Configuration 12

information record included and set as follows: 13

a. The service option connection corresponding to the call to be 14

maintained is included and uses the same connection reference value 15

(CON_REF) as currently used for this call. 16

b. The service option connection corresponding to the other call is 17

omitted. 18

2. At the action time of this message, the mobile station shall release the call 19

corresponding to the omitted service option connection and hands off to the base 20

station 2. 21

3. The remaining call continues successfully in the base station 2. 22


The mobile station and base station shall comply with the requirements in the following steps: 24 Step d. 25

26

16.10 Release A Mobile Station Hands off between Release A Base Station with Change in 27

Concurrent Calls Support 28


This test verifies that, when a Release A mobile station currently in call with a Release A base 30 station is handed off to another Release A base station, and where there is a change in 31 Concurrent Calls support, calls are released/added/maintained successfully. 32


See 16.1.2. 34

3GPP2 C.S0044-D v1.0

16-24


MS

(Rel A)

Traffic

Voice and Data call

in progress

GHDM/UHDM

(P_REV=7,

SCR_new: Voice or Data,

CS_SUPPORTED=0)

Voice or data

call is released

BS

(Rel A:

CS_SUPPORTED=0)

Voice or Data call in progress

BS

(Rel A:

CS_SUPPORTED=1)

UHDM

(P_REV=7,

SCR_new: Voice and Data,

CS_SUPPORTED=1,

CC_INFO_INCL=1)

Voice and Data call

in progress

Voice or data

call is added

2 3


a. Connect the MOB_P_REV=7 mobile station (Release A) to two P_REV=7 base stations 5

(Release A) as shown in Figure A-5. Configure base station 1 to support Concurrent 6

Services and base station 2 not to support Concurrent. 7

b. Setup a mobile station originated or mobile station terminated voice call on base station 8

1. 9

c. Set up a mobile station originated or mobile station terminated packet data call (e.g. 10

SO33). Wait till both voice and data calls are in progress. Ensure sufficient traffic is 11

exchanged to keep the data instance in active state. 12

d. Trigger the base station to direct the mobile station to handoff from base station 1 to 13

base station 2. Verify the following: 14

1. The base station shall send a General Handoff Direction Message or a Universal 15

Handoff Direction Message to the mobile station, with the Service Configuration 16

information record included and set as follows: 17

a. The CS_SUPPORTED field is set to ‘0’. 18

3GPP2 C.S0044-D v1.0

16-25

b. The service option connection corresponding to the call to be 1

maintained is included and uses the same connection reference value 2

(CON_REF) as currently used for this call. 3

c. The service option connection corresponding to the other call is 4

omitted. 5

2. At the action time of this message, the mobile station shall release the call 6

corresponding to the omitted service option connection and hands off to the new 7

Release A base station. 8

3. The remaining call continues successfully in the new Release A base station. 9

e. Trigger the base station to direct the mobile station to handoff from base station 2 to 10

base station 1 that supports concurrent services and with an additional call added 11

(voice or packet data call (e.g. SO33)). Verify the following: 12

1. The base station shall send a Universal Handoff Direction Message to the mobile 13

station, with the following fields set as follows: 14

15

Field Value

P_REV 7 (Release A base station)

SCR_INCLUDED ‘1’ (SCR is included)

CON_REF Connection reference for original call – same as the value currently in use

SERVICE_OPTION SO for original call

CON_REF Connection reference for the SOC corresponding to the new call

SERVICE_OPTION SO for the new call



CON_REF Same value as connection reference for the new call


2. At the action time of this message, the mobile station hands off to base station 1 16

and connects the new call. 17

3. The new call is connected successfully. The original call continues successfully. 18

19

3GPP2 C.S0044-D v1.0

16-26


The mobile station and base station shall comply with the requirements in steps d and e 2

3

3GPP2 C.S0044-D v1.0

17-1

17 EMERGENCY CALLS 1

17.1 Global Emergency Call Support When Mobile Station is in Idle State 2

17.1.1 Definition 3

This test verifies that the mobile station can originate a global emergency call during idle state 4 and that the base station processes this as an emergency call. 5


(see [4]) 7



None 10


a. If the mobile station is capable of recognizing emergency number by analyzing the 12

dialed digits, originate an emergency call from the mobile station by dialing an 13

emergency number. 14

b. Verify the GLOBAL_EMERGENCY_CALL field is set to ‘1’ in the Origination Message 15

and that the base station processes the origination as an emergency call. 16

c. End the call. 17

d. If the mobile station has a special interface to initiate an emergency call, originate an 18

emergency call from the mobile station using this special interface. 19

e. Verify that the mobile station sets the GLOBAL_EMERGENCY_CALL field to ‘1’ in the 20

Origination Message and that the base station processes the origination as an 21

emergency call. 22

f. End the call. 23


The mobile station shall comply with the following steps as supported: Step b and e. 25

The base station shall comply with the following steps as supported: Step b and e. 26

17.2 Global Emergency Call Support When Mobile Station is in Voice Call. 27


This test verifies that the mobile station can originate a global emergency call while another voice 29 call is in progress and that the base station processes this as an emergency call. This test is 30 applicable only to mobile stations not capable of concurrent services. 31

3GPP2 C.S0044-D v1.0

17-2


(see [4]) 2



2.7.2.3.2.3 Flash With Information Message 5



None 8


a. Connect the base station to the mobile station as shown in Figure A-3. 10

b. Originate a voice call from the mobile station. Verify audio in both directions. 11

c. If the mobile station is capable of recognizing emergency number by analyzing the 12

dialed digits and the mobile station does not support concurrent service, originate an 13

emergency call from the mobile station by dialing an emergency number (e.g. dialing 9-14

1-1 and press SEND). 15

d. Verify that the mobile station sends a Flash With Information Message or an Extended 16

Flash With Information Message with the Global Emergency Call information record 17

included and that the base station processes the message as an emergency call. 18

e. End the call. 19

f. Originate a voice call from the mobile station. Verify audio in both directions. 20

g. If the mobile station has a special interface to initiate an emergency call, originate an 21

emergency call from the mobile station using this special interface. 22

h. Verify that the mobile station sends Flash With Information Message or Extended Flash 23

With Information Message with the Global Emergency Call information record included 24

and that the base station processes the origination as an emergency call. 25

i. End the call. 26


The mobile station shall comply with the following steps as supported: Step d and h. 28

The base station shall comply with the following steps as supported: Step d and h. 29

17.3 Global Emergency Call Support When Mobile Station is in a Data Call 30


This test verifies that the mobile station can originate a global emergency call when a packet data 32 call (Ex. SO33) is in progress and that the base station processes this as an emergency call. This 33 test is applicable if both the base station and mobile station support concurrent services. 34

3GPP2 C.S0044-D v1.0

17-3


(see [4]) 2



2.7.2.3.2.3 Flash With Information Message 5



None 8


a. Connect the base station to the mobile station as shown in Figure A-3. 10

b. Originate a data call from the mobile station. 11

c. If the mobile station is capable of recognizing emergency number by analyzing the 12

dialed digits, then while the data call is up, originate an emergency call from the mobile 13

station by dialing an emergency number (e.g. dialing 9-1-1 and press SEND). 14

d. Verify the mobile station sends an Enhanced Origination Message with the 15

GLOBAL_EMERGENCY_CALL field set to ‘1’ and that the base station processes the 16

origination as an emergency call. 17

e. End the calls. 18

f. Originate a data call from the mobile station. 19

g. If the mobile station has a special interface to initiate an emergency call, then while the 20

data call us up, originate an emergency call from the mobile station using this special 21

interface. 22

h. Verify the mobile station sends an Enhanced Origination Message with the 23

GLOBAL_EMERGENCY_CALL field set to ‘1’ and that the base station processes the 24

origination as an emergency call. 25

i. End the calls. 26


The mobile station shall comply with the following steps as supported: Step d and h. 28

The base station shall comply with the following steps as supported: Step d and h. 29

17.4 Emergency Call on a System that is Negative on PRL or SID List 30


This test verifies that the mobile station acquires a system that is ‘negative’ in its (Extended) 32 Preferred Roaming List for an emergency call only. 33

3GPP2 C.S0044-D v1.0

17-4


(see [14]) 2


ANNEX C System Selection and Acquisition 4

17.4.3 Call Flow 5

None 6


a. Connect the mobile station and base station as shown in Figure A-3. 8

b. Program the base station’s SID into the PRL as a negative system. 9

c. Enable power-on registration. Disable all other forms of registration. 10

d. Power on the mobile station, and monitor it for a sufficient period of time to permit it to 11

acquire the base station (typically 30 seconds). 12

e. Verify the mobile station does not attempt to access the base station. 13

f. Setup an emergency call from the mobile station (911 in the United States). 14

g. Verify the mobile station sends an Origination Message to the base station. 15

h. Verify the emergency call is routed to the PSAP or equivalent emulation unit. 16

i. End the emergency call from the mobile station. 17


The mobile station shall comply with step e and g. 19

17.5 Optional Emergency Calls 20


The requirements in these test cases are applicable regionally. For example, in the U.S., the 22 FCC has certain requirements for the mobile station and the base station when an emergency 9-23 1-1 call is initiated. The purpose of this test is to determine the mobile station’s capability to 24 initiate an emergency call under 3 different initial conditions: (1) No calls active or dormant, (2) 25 data call is active and (3) data call in dormant mode. 26


None 28


None 30


a. Allow the mobile to become idle on the base station. 32

b. Originate emergency call from the mobile station and verify that the emergency call is 33 connected. Release the emergency call. 34

3GPP2 C.S0044-D v1.0

17-5

c. Setup SO33 call. While SO33 call is active, originate emergency call from the mobile 1 station and verify that the emergency call is connected. Release the emergency call. 2

d. Allow SO33 to go dormant. 3

e. While SO33 call is dormant, originate emergency call from the mobile station and verify 4 that the emergency call is connected. Release the emergency call. 5


The mobile station and base station shall comply with the requirements in steps b, c, and e 7 (according to applicable regional requirements). 8

9

10

3GPP2 C.S0044-D v1.0

17-6


3GPP2 C.S0044-D v1.0

18-1

18 HRPD 1

For HRPD test cases described in chapter 18, the terms mobile station and base station 2 represent the access terminal (AT) and access network (AN) respectively. 3

For all tests in Chapter 18, Session Security should be enabled if supported. 4

18.1 HRPD Acquisition and Idle Mode Operation 5

18.1.1 Definition 6

These tests will verify that AT acquires the HRPD system and performs idle monitoring of the 7 HRPD control channel. These tests also verify that upon losing HRPD system during idle 8 operation, AT tries to reacquire the HRPD system. 9


(see [24]) 11

10.2.6.1.4.2.1 Initial Acquisition 12


None 14


a. Power up the AT. 16

b. Verify that the AT acquires HRPD system 17

c. Verify that after acquiring HRPD system, the AT performs idle monitoring of the control 18 channel on HRPD system 19

d. Disable the forward link to the AT. 20

e. Verify that AT declares system lost 21

f. Enable the forward link and verify that the AT re-acquires HRPD system. 22


The AT shall comply with c and f. 24

18.2 HRPD Session Establishment 25


This test verifies that during the HRPD session establishment, a Unicast AT Identifier (UATI) is 27 assigned to the AT. 28


[see 24] 30

7 Session Layer, 8 Connection Layer, 10 MAC Layer 31


None 33

3GPP2 C.S0044-D v1.0

18-2


a. Connect the AT to the AN as shown in figure A-3. 2

b. Ensure AT has not established HRPD session with AN (no UATI has been assigned by 3 AN) 4

c. Cause the AT to acquire HRPD AN. 5

d. Verify the AT issues a UATIRequest Message. 6

e. Verify the AN issues a UATIAssignment Message. Record the UATI. 7

f. Verify the AT issues a UATIComplete Message. 8


Verify steps d, e and f. 10

18.3 HRPD Session Configuration and Management with Subnet change 11


This test verifies session configuration and management associated with a subnet change. If the 13 AT moves to a new subnet and if the new subnet can retrieve the AT’s prior session configuration 14 from the old subnet, new session negotiations are not needed. If the “Prior session attribute” is 15 supported by the AN, it can use the previously negotiated set of session parameters. 16


(see [24]) 18

Chapter 7 Session Layer 19


None 21


a. Power up the AT and place it where it can receive good HRPD signal. 23

b. Verify that AT acquires and goes to idle state. Verify that AT requests a UATI and AN 24 assigns it. 25

c. Verify that after receiving the UATIAssignment Message, the AT opens a new HRPD 26 connection and starts session negotiation using sets of ConfigRequest/ConfigResponse 27 messages. 28

d. After a HRPD session is opened successfully, power down the AT. 29

e. Move the AT to another subnet where prior session attribute is accepted and power up 30 the AT. 31

f. Verify that once the AT acquires the new subnet, the AT sends a ConfigRequest with 32 PriorSession attribute and ensure that the AN sends back a ConfigResponse accepting 33 the PriorSession attribute. Verify that AT does not go through a new set of session 34 negotiations after receiving the ConfigResponse from the AN. 35


The AT shall comply with steps b, c, e and f. 37

3GPP2 C.S0044-D v1.0

18-3

18.4 AT Color Code and UATI24 1

18.4.1 Definition 2

This test verifies that the AT is assigned a valid Color Code and UATI024 during an HRPD 3 session establishment. 4


(see [24]) 6


Section 7.3.7.1.5.1 8


None 10


a. Connect the AT to the AN as shown in Figure A-3. 12

b. Cause the AN to issue a new UATI to the AT. 13

c. Verify a valid Color Code (UATIColorCode) and UATI24 (UATI024) are assigned to the 14 AT in the UATIAssignment Message. Record the Color Code and UATI024. 15

d. If the AT receives a UATIAssignment message, verify that the AT transmits a 16 UATIComplete message. 17


Verify that the AN complies with step c. 19

Verify that the AT complies with step d. 20

18.5 HRPD Connection Setup 21


This test verifies that when the HRPD connection is idle (session active and PPP dormant), an AT 23 initiated ping and AN initiated ping shall be successful. This test will verify that AT can setup a 24 HRPD packet data connection when its state is idle. 25


(see [24]) 27



None 30



b. Set up an AT originated call and allow the PPP session to go dormant. 33

c. Ensure that the AT connection is idle on HRPD system 34

d. Issue a “ping” command from the AT to a remote host to setup an HRPD AT originated 35 connection. 36

3GPP2 C.S0044-D v1.0

18-4

e. Verify AT sends a Connection Request Message to AN and that AN sends a ACAck 1 and a TrafficChannelAssignment Message to the AT. Verify AT sends a 2 TrafficChannelCompleteMessage and that connection enters active state. 3

f. Verify the AN transmits the “ping” response from the remote host and the AT receives it. 4

g. Issue a “ping” command from the remote host to the AT using the IP address assigned 5 to the AT. 6

h. Verify the remote host receives a “ping” response from the AT. 7

i. Wait for connection AT to go idle. 8

j. Issue a “ping” command from the remote host to the AT using the IP address assigned 9 to the AT. 10

k. Verify the AT and the AN establish the HRPD connection and the remote host receives 11 a “ping” response from the AT. 12


The AT shall comply with steps e, f, h and k. 14

The AN shall comply with steps e, f, h and k. 15

18.6 AN Packet Data Inactivity Timer 16


This test is only required for access networks that have a packet data inactivity timer. This test 18 verifies the AN releases the traffic channel after expiration of the AN packet data inactivity timer. 19 The test verifies the link layer connection can be re-activated from idle state. 20


(see [24]) 22

7 Session Layer, 8 Connection Layer, 9 Security Layer, 10 MAC Layer 23

(see [26]) 24

2.4.1.2 Termination 25


None 27



b. Set the PCF PPP inactivity timer to a value less than the mobile station PPP inactivity 30 timer. 31

c. Setup an HRPD AT originated connection. 32

d. Initiate a Telnet session to a remote host. 33

e. Record the IP address assigned to the AT. 34

f. Exit the Telnet session. 35

g. Wait for the AN packet data inactivity timer to expire. Verify the AN sends a 36 ConnectionClose Message with CloseReason = 0 (normal Close). Verify the AT sends 37 a ConnectionClose Message with CloseReason = 1 (Close Reply) and connection goes 38 to idle state. 39

3GPP2 C.S0044-D v1.0

18-5

h. Setup an HRPD AT originated connection. 1

i. Initiate a Telnet session to a remote host. 2

j. Record the IP address assigned to the AT. 3

k. Wait for the PCF PPP inactivity timer to expire. Verify the AT connection goes to idle 4 state. 5

l. Setup an HRPD AN originated connection by issuing a “ping” command from a remote 6 host to the AT using the IP address assigned to the AT. 7

m. Verify the host receives a “ping” response from the AT. 8

n. Wait for the PCF PPP inactivity timer to expire. Verify the AT connection goes to idle 9 state. 10

o. Setup an HRPD AT originated connection by issuing a “ping” command from the AT to 11 a remote host. 12

p. Verify the AT receives a “ping” response from the remote host. 13

14


The AT shall comply with steps g, k, n, and p. 16

The AN shall comply with steps g, and p. 17



This test verifies HRPD forward link file transfer when in active HRPD mode. This test case may 20 be performed using Simple IP and/or Mobile IP. 21


(see [24]) 23


(see [26]) 25

3 HRPD IOS Call Flows 26


None 28



b. At the remote host prepare the appropriate file, corresponding to the rate that will be 31 tested (Note: this will guarantee sufficient transfer time). 32

c. Configure the AT to negotiate default FTCMAC (HRPD Rev 0 configuration). 33

d. Setup an AT originated HRPD connection. 34

e. Adjust the RF quality in such a way that the AT requests mostly the DRC value 35 corresponding to the rate that will be tested. 36

f. Setup an FTP session with a remote host and start a file transfer in the forward link by 37 using a binary “get” command from the AT. 38

3GPP2 C.S0044-D v1.0

18-6

g. Verify the data transfer completes successfully. 1

h. Verify that for the duration of the test the PER for the packets received at the AT is less 2 than 1.25%. 3

i. After the file transfer is completed successfully, end the FTP session. 4

j. This test case may be repeated for supported DRC values below. 5

6

Table 18.7.4-1 DRC Value Specification 7

DRC Value Rate (kbps) Packet Length

(Slots)

0x0 Null rate N/A

0x1 38.4 16

0x2 76.8 8

0x3 153.6 4

0x4 307.2 2

0x5 307.2 4

0x6 614.4 1

0x7 614.4 2

0x8 921.6 2

0x9 1228.8 1

0xa 1228.8 2

0xb 1843.2 1

0xc 2457.6 1

0xd 1536.0 2

0xe 3072 1

0xf Invalid N/A

8

k. End the session. 9

l. If HRPD Rev A is supported, then configure the AT to negotiate the use of physical 10 layer subtype 2 and Enhanced FTCMAC (HRPD Rev A configuration). Otherwise skip 11 the remaining steps. 12

m. Instruct the AT to set-up a new session with the AN. 13

3GPP2 C.S0044-D v1.0

18-7

n. Repeat steps d through j. 1


The AN and AT shall comply with step g. 3

The AN and AT should comply with step h. 4


18.8.1 Definition 6

This test verifies HRPD reverse link file transfer when in active HRPD mode. This test case may 7 be performed using Simple IP or Mobile IP. 8


(see [24]) 10


(see [26]) 12



None 15



b. Configure the AT to negotiate the use of Subtype 0 RTCMAC (HRPD Rev 0 18 configuration). 19

c. Cause the AT to acquire the AN. Setup an HRPD AT originated connection. 20

d. Setup a FTP session with a remote host and start a file transfer in the reverse link by 21 using a binary “put” command from the AT. 22

e. Verify the file transfer completes. 23

f. Verify that for the duration of the test the PER for the packets received at the AN is less 24 than 1.25%. 25

g. After the file transfer is completed, end the FTP session. 26

h. Instruct the AN to close the session with the AT. 27

i. If HRPD Rev A is supported, then configure the AT to negotiate the use of physical 28 layer subtype 2 and Subtype 3 RTC MAC (HRPD Rev A configuration). Otherwise skip 29 the remaining steps. 30

j. Instruct the AT to set-up a new session with the AN. 31

k. Repeat steps c to g. 32


The AN and the AT shall comply with step e. 34

The AN and the AT should comply with step f. 35

3GPP2 C.S0044-D v1.0

18-8

18.9 Bidirectional File Transfer 1

18.9.1 Definition 2

This test verifies bi-directional file transfer when in active HRPD mode. 3


(see [24]) 5

7 Session, 8 Connection Layer, 10 MAC Layer 6

(see [26]) 7



None 10



b. Cause the AT to acquire the AN. Setup an HRPD AT originated connection. 13

c. At the remote host prepare the appropriate file, corresponding to the rate that will be 14 tested (Note: this will guarantee sufficient transfer time). 15

d. Setup a FTP session (1) with a remote host and start a file transfer in the reverse link 16 by using a binary “put” command from the AT. 17

e. Setup another FTP session (2) and transfer a file from the Remote Host to the AT using 18 the binary “get” command while the transfer in the reverse direction is still proceeding. 19

f. Verify both file transfers complete. 20

g. After the file transfer, end both FTP sessions. 21


The AT shall comply with step f. 23

18.10 RLP Operation in Severely Degraded Channel 24


This test verifies RLP Operation in Severely Degraded Channel when in active HRPD mode. 26


(see [24]) 28

7 Session, 8 Connection Layer, 10 MAC Layer 29

(see [26]) 30


See [12] 32

Chapters 2 and 3 33


None 35

3GPP2 C.S0044-D v1.0

18-9


a. Connect the AT to the AN as shown in [Figure A-1]. At the remote host prepare the 2 appropriate file, corresponding to the rate that will be tested (Note: this will guarantee 3 sufficient transfer time). Refer to files in Data Services Annex D. 4

b. Set the channel simulator to one Ray 100 km/hr Rayleigh fading on the forward link. 5

c. Configure the AT to negotiate the use of Default Packet Application (HRPD Rev 0 6 configuration) bound to the Service Network. 7

d. Cause the AT to acquire the AN. Setup an AT originated HRPD call. 8

e. Setup a FTP session with a remote host and start a file transfer in the forward link by 9 using a binary “get” command from the AT. 10

f. Verify the AT sends a valid DRC value in the Data Rate Control Channel to the AN and 11 that the AN provides the AT with requested forward link coding and modulating 12 parameters. 13

g. Ensure data transfer rate is not limited by network limitations. 14

h. Verify the data transfer is successful. 15

i. After the file transfer is completed, end the FTP session. 16

j. Instruct the AN to close the session with the AT. 17

k. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 18 Multi-Flow Packet Application (HRPD Rev A configuration) or Multi-Link Multi-Flow 19 Packet Application bound to the Service Network. 20

l. Repeat steps d to i. 21


The AT shall comply with steps f and h. 23

18.11 Softer and Soft Handoff – Active HRPD Mode 24


This test verifies soft handoff when AT is in active HRPD mode with file transfer in forward and 26 reverse directions. 27


(see [24]) 29

7 Session, 30

8 Connection Layer; 31

8.7.7.2.2 SetManagementSameChannelParameters Attribute 32

10 MAC Layer 33

(see [26]) 34



None 37

3GPP2 C.S0044-D v1.0

18-10


a. Connect the AT to the AN as shown in Figure A-5 and set the forward link parameters 2 as shown in. Configure all three sectors with the same channel. 3

Table 18.11.4-1 Forward Link Parameters for Soft(er) Handoff Tests 4

Parameter Units AN BTS 1

Sector

AN BTS 1 Sector β

AN BTS 2 Sector γ

Forward Link Power Ior

dBm/1.23MHz -70 -85 -85

b. Configure each sector to send the Sector Parameters Message with Neighbor List 5 including the other sectors’ Pilot PNs. 6

c. Setup an HRPD AT originated connection on BTS 1, sector . 7

d. Setup an FTP session with a remote host and start a file transfer in the forward link by 8 using a binary “get” command from the AT. Ensure the file size is appropriate to 9 complete the test case before transfer is over. 10

e. Verify that BTS 1/sector is in the pilot active set and that BTS 1/sector ß and BTS 11

2/sector are in the pilot neighbor set. 12

f. Raise the level of BTS 1/sector ß in steps of 1 dB with a dwell time of 5 seconds after 13 each step until the BTS 1/sector ß is in the pilot candidate set. 14

g. Verify AT sends a RouteUpdate Message to report pilots. 15

h. Verify the AN send s a TrafficChannelAssignment Message with Num Pilots=2 then 16

verify both BTS 1 sector and sector ß are in the pilot active set. Verify that 17 SofterHandoff bit in the TrafficChannelAssignment message is set to 1 for the pilots in 18 the softer handoff. 19

i. Raise the level of BTS 2/sector in steps of 1 dB with a dwell time of 5 seconds after 20

each step until the BTS 2/sector is in the pilot candidate set. 21

j. Verify AT sends a RouteUpdate Message to report pilots. 22

k. Verify the AN send s a Traffic Channel Assignment Message with Num Pilots=3 then 23

verify BTS 1/sectors and ß and BTS 2/sector are in the pilot active set. Verify that 24 Soft Handoff bit in the TrafficChannelAssignment message is set to 1 for the pilots in 25 the soft handoff. 26

l. Decrease the level of BTS 1/sector in steps of 1 dB with a dwell time of 5 seconds 27 after each step until AN sends a Traffic Channel Assignment Message with Num 28

Pilots=2, then verify the BTS 1/sector is in the pilot neighbor set. 29

m. Decrease the level of BTS 1/sector ß in steps of 1 dB with a dwell time of 5 seconds 30 after each step until AN sends a Traffic Channel Assignment Message with Num 31 Pilots=1, then verify the BTS 1/sector ß is in the pilot neighbor set. Verify file transfer is 32

still on and the call in on BTS 2/sector . 33

n. Verify the file transfer completes. 34

o. End the call. 35

p. Repeat steps a through c. 36

q. Setup an FTP session with a remote host and start a file transfer in the reverse link by 37 using a binary “put” command from the AT. Ensure the file size is appropriate to 38 complete the test case before transfer is over. 39

3GPP2 C.S0044-D v1.0

18-11

r. Repeat steps e through p. 1


The AT shall comply with steps g, j, l, m and n 3

The AN shall comply with steps e, h, k, l, m and n. 4

18.12 HRPD Control Channel Monitoring and Overhead Message Updates 5


This test will verify that the AT can successfully receive and update control channel messages. 7 And the AN can set various periodicities (within the allowed range, as defined in [24]) for these 8 messages. 9


(see [24]) 11

8.4 Default Idle State Protocol 12

8.5 Enhanced Idle State Protocol 13


None 15



b. Configure the AT to operate in non-slotted (sleep disabled) mode 18

c. Monitor the periodicity of Sync message, Quickconfig message, SectorParameter 19 message, and AccessParameter message 20

d. Check the AN configuration for periodicity of these messages. Verify that received 21 messages have same periodicity as configured at the AN 22

e. Configure the AT to operate in slotted (sleep enabled) mode 23

f. Verify that AT receives and updates the overhead messages (QuickConfig and 24 SectorParameter messages) and performs the supervision of these messages 25 according to the procedures in overhead message protocol specified in [24]. 26


The AT shall comply with steps d and f. 28

18.13 Control Channel Rate 29


This test verifies correct monitoring of Control Channel by AT. 31


(see [24]) 33

10.2 Default Control Channel MAC Protocol 34

10.2.6.1.4.1.1 General Requirements 35

10.2 Enhanced Control Channel MAC Protocol 36

3GPP2 C.S0044-D v1.0

18-12

12.3 and 13.3 AN Requirements 1

12.3.1.3.1 and 13.3.1.3.1 Forward Channel Structure 2

12.3.1.3.2.2 and 13.3.1.3.2.2 Forward MAC Channel 3

12.3.1.3.2.4 and 13.3.1.3.2.4 Control Channel 4


None 6


a. Configure Control Channel Rate to 38400 bps on AN. 8

b. Connect the AT to the AN as shown in Figure A-3 9

c. Verify AT is able to monitor SyncChannel Message, QuickConfig Message, Sector 10 Parameters Message and AccessParameters Message. 11

d. Instruct AT to request a UATI from AN and Setup an HRPD AT originated call. Issue a 12 “ping” from AT. 13

e. Release the call. 14

f. Configure Control Channel Rate to 76800 bps on AN and repeat steps b through e. 15


The AT shall comply with step c. 17

18.14 HRPD ConnectionDeny 18


This test verifies that if there is no traffic channel available, the AN will send a ConnectionDeny 20 Message to AT. This test also verifies that upon receiving a ConnectionDeny Message the AT will 21 enter idle state until it attempts to make another call. 22


(see [24]) 24


8.4.6.1.6.1 AT Requirements 26

8.4.6.1.6.2 AN Requirements 27

8.4.6.2.3 ConnectionDeny 28



None 31


a. Configure the AN to respond with a ConnectionDeny with reason “Network Busy” to a 33 ConnectionAttempt message. 34

b. Attempt to setup an AT originated HRPD connection. 35

3GPP2 C.S0044-D v1.0

18-13

c. Verify the AN sends a Connection Deny Message with Deny Reason 1 = Network Busy. 1

d. Verify the AT enters the AT Monitor (Idle) State until it attempts to setup a new call 2


The AT shall comply with step d. 4

The AN shall comply with step c. 5

18.15 HRPD Keep Alive Mechanism 6


This test verifies the proper functionality of keep alive mechanism. The AT and the AN shall 8 monitor the traffic flowing on the Forward Channel and Reverse Channel, respectively, directed to 9 or from the AT. If either the AT or the AN detects a period of inactivity of at least 10 TSMPClose/NSMPKeepAlive minutes, it may send a KeepAliveRequest message. The recipient of the 11 message shall respond by sending the KeepAliveResponse message. When a 12 KeepAliveResponse message is received, the AT shall not send another KeepAliveRequest 13 message for at least TSMPClose/NSMPKeepAlive minutes. 14


(see [24]) 16

7.2.6.1.6.1 Keep Alive Functions 17

Table 7.2.711and Table 7.2.8 18


None 20


a. Power up the AT and place it where it can receive good HRPD signal. Configure the AN 22 to negotiate TSMPClose to 0x0005 with the AT. 23

b. Ensure that the AT acquires the AN and goes to idle state. 24

c. Terminate all data activities to and from the AT for a period greater than TSMPClose / 25 NSMPKeepAlive minutes. 26

d. Verify that after an inactivity period of TSMPClose / NSMPKeepAlive minutes if either the AT or 27 the AN sends a KeepAliveRequest and that the recipient of the KeepAliveRequest 28 message responds with a KeepAliveResponse message. 29

e. If the AT receives a KeepAliveResponse message, verify that the AT does not send 30 another KeepAliveRequest message for at least another TSMPClose / NSMPKeepAlive minutes 31

f. Power down the AT. Power up the AT after TSMPClose minutes. Verify that the AT 32 terminates the old session. 33


The AT shall comply with steps d, e and f. 35

The AN shall comply with step d. 36

3GPP2 C.S0044-D v1.0

18-14

18.16 Intra-band HRPD-HRPD System Re-Selection (Connected State) 1


This test verifies the AT performs HRPD system reselection between different channels in the 3 same band class. For this test case, the HRPD session and PPP session are connected and 4 active. The test will be performed while transferring data on the forward link and then repeated on 5 the reverse link. 6


(see [24]) 8

8.2 Default Air Link Management Protocol 9

8.2.6.1.2 Initialization State 10


8.4.6.1.6 Connection Setup State 12

8.6 Default Connected State Protocol 13


(see [26]) 15

3.7.1 PCF-PCF Dormant Handoff with Successful Retrieval of HRPD Session 16

Information 17


None 19


a. Connect the AT to AN 1 and AN 2 as shown in Figure A-5. 21

b. Configure AN 1 with different channel than AN 2. 22

c. Configure AN 2 not to be in the neighbor list of AN 1. 23

d. Cause the AT to acquire AN 1. Setup an HRPD AT originated connection. 24

e. Setup a FTP session with a remote host and start a file transfer in the forward link by 25 using a binary “get” command from the AT. 26

f. Before file transfer is complete increase forward link attenuation on AN 1 until AT can’t 27 monitor AN 1 signal. 28

g. Verify AT declares system lost and acquires AN 2 and reconnects HRPD connection. 29 Verify file transfer continues after selection AN 2. 30

h. Release connection. 31

i. Repeat steps b through g for file transfer in the reverse link by using a binary “put” 32 command from the AT instead of “get” (step e). 33


The AT shall comply with step g for all test cases. 35

3GPP2 C.S0044-D v1.0

18-15

18.17 Inter-band HRPD-HRPD System Re-Selection (Connected State) 1


This test verifies the AT performs HRPD system reselection between channels from different 3 band classes. For this test case, the HRPD session and PPP session are connected and active. 4 The test will be performed while transferring data on the forward link and then repeated on the 5 reverse link. 6


(see [24]) 8







(see [26]) 15


Information 17


None 19



b. Configure AN 1 to operate in a different band class than AN 2. 22

c. Cause the AT to acquire AN 1. Setup an HRPD AT originated connection. 23

d. Setup a FTP session with a remote host and start a file transfer in the forward link by 24 using a binary “get” command from the AT. 25

e. Before file transfer is complete increase forward link attenuation on AN 1 until AT can’t 26 monitor AN 1 signal. 27

f. Verify AT declares system lost and acquires AN 2 and reconnects HRPD call. Verify file 28 transfer continues after selection AN 2. 29

g. Release connection. 30

h. Repeat steps b through g for file transfer in the reverse link by using a binary “put” 31 command from the AT instead of “get” (step e). 32


The AT shall comply with step f for all test cases. 34

3GPP2 C.S0044-D v1.0

18-16

18.18 Intra-band HRPD-HRPD System Re-selection (Idle State) 1


This test verifies the AT performs HRPD reselection, while in idle state, between channels in the 3 same band class. This test is performed after the HRPD and PPP session have been established. 4 The PPP session for the AT shall be in the dormant state and the AT is not on the traffic channel 5 at the time of the system reselection. 6


(see [24]) 8







(see [26]) 15


Information 17


None 19



b. Configure AN 1 with different channel than AN 2. 22

c. Configure AN 2 not to be in the neighbor list of AN 1. 23

d. Cause the AT to acquire AN 1. Setup an HRPD AT originated call. 24

e. Verify that the AT connection is idle. 25

f. Force the AT to handoff from AN 1 to AN 2 (i.e. by increasing forward link attenuation 26 on AN 1 until AT can’t monitor AN 1 RF signal). 27

g. Verify AT declares system lost and acquires AN 2. Issue a “ping” from AT and verify an 28 HRPD connection is successfully setup. 29

h. Issue a “ping” from remote host to AT IP address and verify there is a response. 30


The AT shall comply with steps e, g and h. 32

18.19 Inter-band HRPD-HRPD System Re-selection (Idle State) 33


This test verifies the AT, performs HRPD reselection, while in idle state, between channels from 35 different band classes. The test may be performed using Simple IP and/or Mobile IP. This test is 36 performed after the HRPD and PPP session have been established. The PPP session for the AT 37

3GPP2 C.S0044-D v1.0

18-17

shall be in the dormant state and the AT is not on the traffic channel at the time of the system 1 reselection. 2


(see [24]) 4







(see [26]) 11


Information 13


None 15



b. Configure AN 1 to operate in a different band class than AN 2. 18

c. Cause the AT to acquire AN 1. 19

d. Verify that AT connection is idle. 20

e. Force the AT to handoff from AN 1 to AN 2 (i.e. by increasing forward link attenuation 21 on AN HRPD 1 until AT can’t monitor HRPD 1 RF signal). 22

f. Verify AT declares system lost and acquires AN 2. Issue a “ping” from AT and verify 23 HRPD call is successfully originated. 24

g. Issue a “ping” from remote host to AT IP address and verify there is a response. 25


The AT shall comply with steps d, f and g. 27

18.20 HRPD Terminal Authentication 28


This test verifies that when the User-name or the CHAP-password is incorrectly set at the AT the 30 network authentication fails. 31


(see [11]) 33

3.1.1 AT originates HRPD Session – Successful Terminal Authentication 34

3GPP2 C.S0044-D v1.0

18-18

3.1.2 AT originates HRPD Session – Unsuccessful Terminal Authentication 1


None 3


a. Configure the CHAP authentication to be enabled in the network. 5

b. Provision the AT with the correct information to successfully pass CHAP authentication. 6

c. Ensure the AT has a closed HRPD session. 7

d. Power up the AT and allow it to acquire the HRPD network. 8

e. If AN performs authentication immediately after the session negotiation, verify that AN 9 sends the CHAP Challenge message and initiates the network authentication 10

f. Verify that the network authentication passes and the HRPD remains connected. 11

g. If AN performs authentication just before the data call setup(s), set up a data call on the 12 HRPD system and verify that AN sends the CHAP Challenge message and initiates the 13 AN authentication 14

h. Verify that the network authentication passes and the HRPD call is successful. 15

i. End any HRPD calls. 16

j. Provision an incorrect User-name but a correct Chap-password in the AT for CHAP 17 authentication. 18

k. Ensure that the AT has a closed HRPD session 19

l. Power up the AT and place it where it can receive good HRPD signal 20

m. Ensure that AT successfully completes the session negotiation and negotiates the AN 21 stream as part of this procedure. 22

n. If AN performs authentication immediately after the session negotiation, verify that AN 23 sends the CHAP Challenge message and initiates the network authentication 24

o. Verify that the network authentication fails and the AN closes the HRPD session. 25

p. If AN performs authentication just before the data call setup(s), set up a data call on the 26 HRPD system and verify that AN sends the CHAP Challenge message and initiates the 27 AN authentication 28

q. Verify that the network authentication fails. 29

r. Repeat steps l to g by provisioning a correct User-name but an incorrect Chap-30 password in the AT for CHAP authentication. 31


The AT shall comply with steps f, h, and q. 33

The AN shall comply with steps e, f, h, n, o, p and q. 34

18.21 PPP Session in Adverse Conditions - Disconnect cable between AT and PC. 35


This test verifies AT sends an LCP Termination Request to the AN when it is disconnected from 37 the computer device. This causes the PDSN to close the PPP session. 38

3GPP2 C.S0044-D v1.0

18-19


(see [28]) 2

3.2.1 PPP Session 3


None 5


a. Setup an AT originated HRPD connection. 7

b. Ensure that an IP address is assigned to the AT, and a PPP session is established 8 between PDSN and the AT. 9

c. Wait until the AT connection goes to idle state. 10

d. Close the PPP session from the AT to the AN without notifying the AN by disconnecting 11 the cable between the AT and the computer. 12

e. Verify that the AT transmits XOffRequest and ConnectionClose messages to the AN. 13


The AT shall comply with step e. 15

18.22 Unicast ReverseRateLimit 16


This test verifies the AT can successfully receive the UnicastReverseRateLimit Message with the 18 RateLimit value set to various values. This test is applicable to HRPD Rev 0 operation. Rev A AT 19 should be configured to negotiate Rev 0 supported protocol subtypes and default packet 20 application. 21


(see [24]) 23

10.8.6.1.5.2 and 10.9.6.1.5.2 Rate Control 24


None 26


a. Configure the AT to negotiate Subtype 0 RTCMAC. Setup a connection. 28

b. Setup a FTP session with a remote host and start a file transfer in the reverse link by 29 using a binary “put” command from the AT. 30

c. Send a UnicastReverseRateLimit Message with the RateLimit value set to 1 (9.6 kbps) 31 to the AT. 32

d. Monitor the AT transmit rate and verify that the AT does not transmit above the value 33 set in step c. 34

e. Steps a to d may be repeated with the RateLimit values set to 2 (19.2kbps), 3 35 (38.4kbps), 4 (76.8kpbs), and 5 (153.6kbps). 36


The AT shall comply with step d for all test cases. 38

3GPP2 C.S0044-D v1.0

18-20

18.23 HRPD Location Update Protocol Tests 1


This test verifies the proper functionality of Location update feature. 3


(see [24]) 5

3.5 and 4.6 Location Update Protocol 6

(see [12]) 7

Chapters 2 and 3. 8


None 10


a. Ensure that the Ranhandoff parameter is enabled at the AN. 12

b. Power up the AT and place it where it can receive good HRPD signal 13

c. Ensure that AT successfully completes the session negotiation. 14

d. Depending on the implementation, the AN can send LocationAssignment Message to 15 the AT. Upon receiving this LocationAssignment Message, verify that the AT sends a 16 LocationComplete Message and stores the Location Values in the Location Assignment 17 Message as the current Location Values. 18

e. Depending on the implementation, the AN can send LocationRequest Message. Upon 19 receipt of this message, verify that the AT responds with LocationNotification Message, 20 which shall contain the current Location values of the AT. 21

f. Originate a packet connection, verify that the connection can be successfully 22 established and the data can be transferred. Let the AT connection go idle. Move the 23 AT to an area where there is no HRPD signal. AT will lose the HRPD signal and go to 24 acquisition state. Move the AT to an area where there is a HRPD signal belonging to a 25 different subnet. AT shall acquire this system. Ensure that the AN rejects the 26 PriorSession restore request from the AT. AT shall negotiate session with this HRPD 27 system and once the session is negotiated, shall send an unsolicited 28 LocationNotification Message. Verify that this message is sent. 29


The AT shall comply with steps d, e, and f. 31

18.24 Idle State Channel Hashing 32


This test can be performed only if the AN supports more than one HRPD channels. 34

If multiple channels are advertised in the sector parameter message, AT uses hash function (as 35 specified in (See [24])) to select one of the advertised channels for idle state operation. The 36 primary purpose of channel hashing is to equally distribute the AN load on all available channels. 37


(see [24]) 39

3GPP2 C.S0044-D v1.0

18-21

8.4.6.1.5.1.1 CDMA Channel Selection 1

10.4 Hash Function 2


None 4


a. Configure the AT roaming list with the primary channel. Configure the AT to negotiate 6 default idle state protocol. 7

b. Power up the AT. 8

c. Place AT where it can receive good HRPD signal. 9

d. If the AT has an open session with the AN, cause the AN to close the session. Cause 10 the AT to establish a new session with the AN. 11

e. Ensure that AT correctly acquires the primary channel listed in the roaming list. 12

f. After receiving the sector parameter messages with multiple channels, AT will try to 13 hash to a channel listed in SectorParameter message (it could be the same channel in 14 some cases). 15

g. Verify that if there are “n” channels listed in the sector parameter message and if this 16 test is repeated “m” number of times, AT will hash to each channel approximately “m/n” 17 times. In a subnet where SectorParameter message contains multiple channels, AT will 18 try to hash to a new channel every time a new session is opened. 19

h. Repeat steps d through g approximately 3n times. 20

i. Setup a HRPD data connection after channel hashing is complete to verify that AT can 21 setup a connection on the hashed channel. Let the call connection go idle. 22

j. Send a data page from the AN (on the hashed channel) and verify that AT can receive 23 a page on the hashed channel. 24


The AT shall comply with steps g, i and j. 26

18.25 Inter-frequency Active Handoff 27


This test verifies that the AT is able to successfully acquire a new AN with a different frequency 29 assignment during an active call. The AT will receive a new TrafficChannelAssignment message 30 with the target frequency information. Since there is no hard handoff mechanism in HRPD, using 31 the new TrafficChannelAssignment allows for faster acquisition of AN 2. 32


(see [24]) 34





3GPP2 C.S0044-D v1.0

18-22




SectorAT

Reverse Pilot + DRC

Traffic Channel Complete

Traffic Channel Assignment corresponding

to configured target carrier sectors

aRoute Update

c

d

e

Sector

s25

Sector

s16

Reset Report*b

Route Update*

*This step is conditional , this may or , may not take place in the message exchangesequence, based on the trigggers generated by mobility

f

4



b. AN 1 and AN 2 have different frequency assignments. 7

c. AN 1 and AN 2 have the same RNC connections. 8

d. Cause the AT to acquire AN 1. Set up an HRPD AT originated call. 9

e. Initiate a forward data transfer to the AT. 10

f. Trigger a hard handoff from AN 1 to AN 2 by sending a TrafficChannelAssignment 11 message with the target information for AN 2. 12

g. Verify the AT tunes to the new frequency the file transfer completes successfully. 13

h. The delay between losing AN 1 and acquiring AN 2 should be less than 500ms. 14

15


The AT shall comply with step g and should comply with step h. 17

3GPP2 C.S0044-D v1.0

18-23

18.26 Typical HRPD Rev-A Session Configuration 1


This test verifies the ability of AT and AN to use typical HRPD Rev A configuration. The use of 3 MFPA bound to the service network, Enhanced FTCMAC, RTCMAC subtype 3, Enhanced 4 CCMAC, Enhanced ACMAC and Physical layer Subtype 2 is verified. 5


(see [24]) 7

4 Multi-Flow Packet Application 8

7.2.6.2.1 Session Close 9


10.3 Enhanced Control Channel MAC Protocol 11

10.5 Enhanced Access Channel MAC Protocol 12

10.7 Enhanced Forward Traffic Channel MAC Protocol 13

10.11 Subtype 3 Reverse Traffic Channel MAC Protocol 14

11.2 Subtype 2 Physical Layer 15

(see [12]) 16

Chapters 2 and 3. 17


None 19



b. Cause the AT to acquire the AN. 22

c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 23 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 24 service network, Physical layer subtype 2, Enhanced CCMAC, Enhanced ACMAC, 25 Enhanced FTCMAC, Enhanced Idle State Protocol and Subtype 3 RTC MAC. 26

d. If the AT has an established session with the AN, cause the AN to close the session by 27 transmitting a SessionClose message. 28

e. Power cycle the AT. 29

f. Verify that the AT establishes a session with the AN and acquires the HRPD system. 30

g. Cause the AT to initiate a data call with the AN. 31

h. Verify that the AT and the AN have successfully negotiated the use of Multi-Flow 32 Packet Application or Enhanced Multi-Flow Packet Application or Multi-Link Multi-Flow 33 Packet Application bound to the AN, Physical layer Subtype 2, Enhanced FTCMAC 34 Enhanced CCMAC, Enhanced ACMAC, Enhanced Idle State Protocol and Subtype 3 35 RTCMAC. 36

i. Cause the AT to transmit data to the AN. 37

3GPP2 C.S0044-D v1.0

18-24

j. Verify that the data is transmitted using the default RLP flow of the MFPA. 1


The AT shall comply with steps f, h and j. 3

The AN shall comply with step h. 4

18.27 Multiple Reservations bound to one RLP 5


In HRPD Rev A, multiple higher layer flows can be bound to a single RLP flow. This is done by 7 mapping the ReservationLabel associated with the higher layer flow in FlowNNReservationFwd 8 and FlowNNReservationRev attribute of the RLP Flow NN. This test verifies the ability of the AN 9 and the AT to successfully bind multiple reservations to a single RLP flow. 10

This test requires the ability to generate QoS requests from the AT, allocate QoS resources at the 11 AN and install traffic filtering at the PDSN. The application that causes the AT to generate QoS 12 requests could either reside at the AT or the TE. Further, it should be ensured that the application 13 is able to connect with the server/peer and receive and transmit data. This may require password 14 authentication when using commercial applications residing on the AT. 15

The following behavior is assumed for the application using the QoS. Starting the application will 16 cause ReservationKKQoSRequestFwd/Rev to be sent containing the requested Profile ID. Unless 17 otherwise specified, the Profile should be accepted by the AN. Closing the application will cause 18 the AT to transmit a ReservationKKQoSRequestFwd/Rev with ProfileType set to NULL. If 19 application is paused or restarted, it should turn the reservation to on state if the reservation is in 20 closed state. This application behavior is assumed for all QoS related tests in this chapter. 21


(see [24]) 23

4.4.4 Procedures and Messages for the InUse Instance of the RLP 24

4.4.8 Complex Attributes of Multi-Flow Packet Application 25

(see 17]) 26 11.4 QoS ProfileType and ProfileValue Assignment 27 (see [10]) 28 (see [12]) 29 Chapters 2 and 3. 30


None 32




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 36 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 37 service network, Physical layer subtype 2, Enhanced FTCMAC and Subtype 3 RTC 38 MAC. 39

d. Configure the AN to activate only the default RLP flow during session configuration. 40

3GPP2 C.S0044-D v1.0

18-25

e. Configure the AN to use a value of 2 for MaxActivatedRLPFlowsFwd and 1 MaxActivatedRLPFlowRev. 2

f. If the AT has an established session with the AN, cause the AN to close the session by 3 transmitting a SessionClose message. 4

g. Cause the AT to negotiate a new session with the AN. 5

h. Cause the AT to establish a data call with the AN and allow the AT to go idle. 6

i. Cause the AT to generate a QoS request for one forward and one reverse link higher 7 layer flow. 8

j. Ensure that the AT transmits GAUP message(s) with ReservationKKQoSRequestFwd 9 with R_QoS_SUB_BLOB containing the specified Profile ID for forward higher layer 10 flows and ReservationKKQoSRequestRev with R_QoS_SUB_BLOB containing the 11 specified Profile ID for reverse higher layer flows. 12

k. Ensure that the AT constructs a Traffic Flow Template (TFT) with the desired packet 13 filters and sends an RSVP Resv [Create new TFT] message. 14

l. Ensure that the AN transmits AttributeUpdateAccept message(s) accepting the QoS 15 ReservationKKQoSRequestFwd / ReservationKKQoSRequestRev attributes from the 16 AT. 17

m. The AN should GAUP the ReservationKKQoSResponseFwd with G_QoS_BLOB 18 containing the set ID for primary Profile ID. 19

n. The AN should GAUP the ReservationKKQoSResponseRev with G_QoS_BLOB 20 containing the set ID for primary Profile ID. 21

o. The PDSN should install the desired packet filters and sends an RSVP ResvConf 22 message. 23

p. Ensure that the AT transmits AttributeUpdate message(s) to the AN accepting the AN’s 24 ReservationKKQosResponseFwd and ReservationKKQosResponseRev for the various 25 Reservarion Labels. 26

q. Ensure that the AN transmits a GAUP message for FlowNNIdentificationFwd (NN = 1) 27 and FlowNNIdentificationRev (NN = 1) in order to activate the forward and reverse link 28 flows. 29

r. Ensure that the AT transmits AttributeUpdateAccept message(s) accepting 30 FlowNNIdentificationFwd and FlowNNIdentificationRev arrtibutes. 31

s. The AN may need to transmit AttributeUpdateRequest message(s) negotiating the 32 FlowNNTimersFwd and FlowNNTimersRev for the Forward and Reverse link RLP flows 33 and various parameters of the RTCMAC flow. 34

t. If the AN transmits Attribute Update Request for the Forward and Reverse Link RLP 35 Flows and/or RTCMAC flows, the AT should transmit AttributeUpdateAccept 36 message(s) accepting RLP and RTCMAC parameters. 37

u. Ensure that the AN transmits a FlowNNReservationFwd to bind the reservation to 38 forward to RLP flow (NN = 0x01). 39

v. Ensure that the AN transmits a FlowNNReservationRev to bind the reservation to 40 reservation to RLP flow (NN = 0x01). 41

w. Ensure that the AT transmits an AttributeUpdateAccept message accepting the 42 FlowNNReservationFwd and FlowNNReservationRev values. 43

x. Ensure that the AN transmits AttributeUpdateReqest message containing 44 AssociatedFlowNN with substream field set to 1 to bind the RLP FlowNN (NN = 1) to an 45 RTCMAC flow. 46

3GPP2 C.S0044-D v1.0

18-26

y. Ensure that the AT transmits AttributeUpdateAccept message(s) to the AN accepting 1 the binding sent by the AN in AssociatedFlowsNN attribute. 2

z. Ensure that the AN transmits a GAUP message to set RTCMAC BucketLevelMaxNN 3 with a nonzero value in order to activate the RTCMAC flow. 4

aa. Ensure that the AT transmits AttributeUpdateAccept message to the AN accepting the 5 BucketLevelMaxNN value sent by the AN. 6

bb. Ensure that the AT sends ReservationOnRequest for both the forward and reverse 7 ReservationLabels using single ReservationOnRequest message. 8

cc. Ensure that AN sends ReservationAccept for both forward and reverse reservations. 9

dd. Repeat steps i to cc for 2 other QoS requests. 10

ee. Verify that both the forward and reverse RLP flows (NN = 1) are activated and the 11 reservation for all the higher layer flows are in the Open state. 12

ff. Start bidirectional data transfer for different higher layer flows and verify that data is 13 being sent/received on the correct RLP IDs. 14

gg. Ensure that the PDSN is sending data via the intended filter. 15


The AT shall comply with steps ee and ff. 17

The AN shall comply with steps ee and ff. 18

The PDSN should comply with steps o and gg. 19

18.28 Maximum Open Reservations, Activated RLP and MAC flows 20


The Maximum number of reservations that can be in open state in HRPD is governed by 22 MaxNumOpenReservationsFwd and MaxNumOpenReservationsRev (default value of 16). The 23 maximum number of open RLP flows is governed by MaxActivatedRLPFlowsFwd and 24 MaxActivatedRLPFlowsRev. The maximum number of active MAC flows is governed by 25

MaxNumActiveMACFlows This test verifies that AT and the AN can support up to 16 open 26 reservations, mapped to 8 RLP flows that are in turn mapped to 4 MAC flows. This test implicitly 27 verifies the ability of the AN and the AT to allow many to one binding from reservation labels to 28 RLP flows and RLP flows to MAC Flows. It also verifies the ability of the PDSN to create multiple 29 filters for the AT. 30


(see [24]) 32



(see [10]) 35

(see [12]) 36

Chapters 2 and 3 37


None 39

3GPP2 C.S0044-D v1.0

18-27






e. Configure the AN to use a value of 8 for MaxActivatedRLPFlowsFwd, 9 MaxActivatedRLPFlowRev, MaxNumRLPFlowsFwd and MaxNumRLPFlowsRev. 10

f. Configure the AN to set the MaxNumOpenReservationsFwd and 11 MaxNumOpenReservationsRev parameters of MaxReservations attribute to 16. 12

g. Configure the AN to grant the QoS request from the AT and to bind 2 QoS reservations 13 to one RLP flow for both the forward and reverse link flows, and to bind 2 RLP flows to 14 each RTCMAC Flow. 15

h. If the AT has an established session with the AN, cause the AN to close the session by 16 transmitting a SessionClose message. 17

i. Cause the AT to negotiate a new session with the AN. 18

j. Ensure that the AN activates only the default RLP flow during session configuration. 19

k. Cause the AT to establish a data call with the AN and allow the AT to go idle. 20

l. Using multiple applications, cause the AT to generate QoS requests for 16 forward and 21 reverse link flows. Wait for the AN to transmit ReservationAccept message for all the 22 reservations. 23

m. Verify that all 8 forward and reverse RLP flows are activated and all 16 reservations are 24 in Open state. 25

n. Start bidirectional data transfer for different higher layer flows and verify that data is 26 being sent/received on the correct RLP and MAC flows. 27

o. Ensure that the PDSN is sending data for each higher layer flow via the intended filter. 28


The AT shall comply with steps m and n. 30

The AN shall comply with steps m and n. 31

The PDSN should comply with step o. 32

18.29 QoS Release upon PDSN initiated LCP termination 33


When the PDSN terminates a PPP connection by transmitting an LCP termination message, the 35 AT and the AN should release all the resources allocated to the current QoS Reservations. The 36 PDSN should delete the TFT associated with the AT. 37


(see [24]) 39

Chapter 4. Multi-Flow Packet Application 40

3GPP2 C.S0044-D v1.0

18-28

(see [12]) 1

Chapter 2 Enhanced Mult-Flow Packet Application 2

Chapter 3 Multi-Link Multi-Flow Packet Application 3

(see [10]) 4

(see [28]) 5

3.2.1 PPP Session 6


None 8





d. Configure the AN to grant the QoS request from the AT and to use a value of 0x00 for 16 ReservationKKIdleStateFwd and ReservationKKIdleStateRev attributes. 17

e. If the AT has an established session with the AN, cause the AN to close the session by 18 transmitting a SessionClose message. 19

f. Cause the AT to negotiate a new session with the AN. 20

g. Cause the AT to establish a data call with the AN and allow the AT to go idle. 21

h. Cause the AT to generate QoS requests for one forward and reverse link flow with 22 ReservationKKIdleStateFwd and ReservationKKIdleStateRev set to 0x00. Wait for the 23 AN to transmit ReservationAccept message for all the reservations. 24

i. Start data transfer and ensure that all reservations are in open state and that the data 25 is being transmitted using appropriate RLP flow IDs. 26

j. Cause the PDSN to transmit an LCP termination to the AT. 27

k. Verify that the AT terminated the PPP. 28

l. Ensure that the AN and AT release all QoS resources by verifying that the AT transmits 29 ReservationKKQoSRequest(s) with ProfileType set to NULL and 30 ReservationOffRequest message(s) for all the open reservation(s) and that the AN 31 responds with a ReservationAccept message(s). 32

m. The PDSN should delete all filters associated with the AT. 33


The AT shall comply with step k and l. 35

The AN shall comply with steps l. 36

The PDSN should comply with step m. 37

3GPP2 C.S0044-D v1.0

18-29

18.30 QoS Release upon AT Initiated PPP Termination 1


When the AT terminates the PPP session, the AT and the AN should release all QoS and the 3 PDSN should delete TFT related to the AT. 4


(see [24]) 6

Chapter 4. 7

(see [10]) 8

(see [12]) 9

Chapters 2 and 3 10


None 12









h. Cause the AT to generate Qos requests for one forward and reverse link flow. Wait for 26 the AN to transmit ReservationAccept message for all the reservations. 27

i. Start data transfer and verify that all reservations are in open state and that the data is 28 being transmitted using appropriate RLP flow IDs. 29

j. Cause the AT to terminate the PPP session. 30

k. Ensure that the AN and AT release all QoS resources by verifying that the AT transmits 31 ReservationKKQoSRequest(s) with ProfileType set to NULL and 32 ReservationOffRequest message(s) for all the open reservation(s) and that the AN 33 responds with a ReservationAccept message(s). 34

l. The PDSN should delete all filters associated with the AT. 35


The AT shall comply with step k. 37

The AN shall comply with steps k. 38

The PDSN should comply with step l. 39

3GPP2 C.S0044-D v1.0

18-30

18.31 Access Persistence Vector 1


This test verifies that the AT can properly interpret the persistence value from the 3 AccessParameters Message. The AN may control the load on the system by adjusting the 4 access persistence vector, APersistence, sent as part of the AccessParameters message. The 5 value of APersistence can be in the range from zero to 0x3F. If the value of APersistence is 6 0x3F, the AT shall use zero as the corresponding persistence probability. If the value of 7 APersistence(n) is not equal to 0x3F, the AT shall use the value obtained from 2

-n/4 as the 8

corresponding persistence probability. There are 4 instances of APersistence, called NACMPAPersist, 9 that represent 4 AT types. The 4 instances of NACMPAPersist are: 10

0: Normal AT 11

1: Priority or Emergency AT 12

2: Test AT 13

3: Reserved. 14


(see [24]) 16

10.4.6.1.4.1.4 Probe Sequence Transmission 17

10.5.7 Configuration Attributes 18


None 20



b. If the AT and AN support the Enhanced Access Channel MAC Protocol, ensure that the 23 default values are used for the parameters of APersistenceOverride and 24 AccessTerminalClassOverride. 25

c. Cause the AN to send an AccessParameters Message with the value of APersistence 26 equal to 0 for every instance of NACMPAPersist. 27

d. Attempt an AT originated HRPD connection. 28

e. Verify that the AT successfully established the HRPD connection. 29

f. End the connection. 30

g. Cause the AN to send an AccessParameters Message with the value of APersistence 31 equal to 0x3F for every instance of NACMPAPersist. 32

h. Cause the AT to send a message on the Access Channel. 33

i. Verify the attempt is not successful and that the AT returns a TransmissionFailed 34 indication. 35

j. Cause the AN to send an AccessParameters Message with the value of APersistence 36 equal to 0 for every instance of NACMPAPersist. 37

k. Attempt an AT originated HRPD connection. 38

l. Verify that the AT successfully established the HRPD connection. 39

m. End the connection. 40

3GPP2 C.S0044-D v1.0

18-31


The AT shall comply with step e, i and l. 2

18.32 AT Data Over Signaling Message Transmission 3


This test verifies that the AT can send a packet over the Access Channel to the AN. This is 5 accomplished by using the Data Over Signaling (DoS) Protocol. The size of the data packet that 6 the AT sends must be smaller than the Access Channel capsule size. Specifically, this test 7 validates that the delivery of higher layer packet using a DataOverSignaling Message transmitted 8 by the AT to the AN, and the MessageSequence increment for the DataOverSignaling Messages. 9 This test also validates the ability of the AN to acknowledge the DataOverSignaling Message with 10 a DataOverSignalingAck with appropriate AckSequence field when the AckRequired field in the 11 DataOverSignaling Message is set to 1. 12


(see [24]) 14

4.5 Data Over Signaling Protocol 15

(see [12]) 16

Chapters 2 and 3 17


None 19




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 23 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 24 service network, Physical layer subtype 2, Enhanced CCMAC, Enhanced ACMAC, 25 Subtype 3 RTC MAC. 26

d. During Session Configuration, set the ProtocolIdentifier field of the 27 FlowNNHigherLayerProtocolRev (NN = 0xij) and FlowNNHigherLayerProtocolFwd (NN 28 = 0xij) to HDLC framing. 29

e. During Session Configuration, set the Active parameter of FlowNNIdentificationFwd 30 (NN = 0xij) attribute and FlowNNIdentificationRev (NN = 0xij attribute to 0x01. 31

f. Set the ReservationLabel for FlowNNReservationRev (NN = 0xij and 32 FlowNNReservationFwd (NN = 0xij) to High Priority Signaling. Set 33 FlowNNDataOverSignalingAllowedRev (NN = 0xij) to 0x01. Configure the AN to grant 34 the QoS request from the AT and to set ReservationKKIdleStateFwd and 35 ReservationKKIdleStateRev to 0x0 for ReservationLabel kk associated with High 36 Priority Signaling. 37

g. If the AT does not have an established PPP session, cause the AT to establish a PPP 38 session. 39

h. Instruct the AT to send a ReservationOn message for ReservationLabel kk associated 40 with High Priority Signaling data that is to be carried using DataOverSignaling message 41 to the AN and ensure that the AN responds with a ReservationAccept message. Instruct 42

3GPP2 C.S0044-D v1.0

18-32

the AT to send a ReservationOn message for ReservationLabel kk associated with High 1 Priority Signaling data that is to be carried using DataOverSignaling message from the 2 AN to the AT and ensure that the AN responds with a ReservationAccept message. 3

i. Allow the HRPD connection to become idle. 4

j. Transmit a packet from the AT directed to the AN using the DataOverSignaling 5 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 6 Ensure that the DataOverSignaling message is smaller than the maximum Access 7 Channel capsule size. 8

k. Verify that the AT transmits a DataOverSignaling Message with MessageID field set to 9 0x14, AckRequired field set to 1, Reset field set to 0, MessageSequence field set to 0, 10 and the HigherLayerPacket field set to entire higher layer packet. 11

l. Verify that if the AN received the DataOverSignaling Message, it transmits a 12 DataOverSignalingAck with MessageID set to 0x15 and AckSequence field set to zero 13 and the higher layer packet carried in the DataOverSignaling message is delivered to 14 the higher layer protocol. 15

m. Transmit a packet from the AT directed to the AN using the DataOverSignaling 16 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 17 Ensure that the DataOverSignaling message size is smaller than the maximum Access 18 Channel capsule size. 19

n. Verify that the AT transmits a DataOverSignaling Message with MessageSequence 20 field set to 1. 21

o. Verify that if the AN received the DataOverSignaling Message, it transmits a 22 DataOverSignalingAck with the AckSequence field set to one and the packet is 23 delivered to the higher layer protocol. 24


The AT shall comply with steps k and n. 26

The AN shall comply with steps l and o. 27

18.33 AN Data Over Signaling Message Transmission 28


This test verifies that the AN can send a packet over the Control Channel to the AT. This is 30 accomplished by using the Data Over Signaling (DoS) Protocol. Specifically, this test validates 31 the delivery of higher layer packet using of a DataOverSignaling Message transmitted by the AN 32 to the AT, and the MessageSequence increment for the DataOverSignaling Messages. This test 33 also validates the ability of the AT to acknowledge the DataOverSignaling Message with a 34 DataOverSignalingAck with appropriate AckSequence field when the AckRequired field in the 35 DataOverSignaling Message is set to 1. 36


(see [24]) 38

4.5 Data Over Signaling Protocol 39

(see [12]) 40

Chapters 2 and 3 41

3GPP2 C.S0044-D v1.0

18-33


None 2




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 6 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 7 service network, Physical layer subtype 2, Enhanced CCMAC, Enhanced ACMAC, 8 Subtype 3 RTC MAC. 9


e. During Session Configuration, set the Active parameter of FlowNNIdentificationFwd 13 (NN = 0xij) attribute and FlowNNIdentificationRev (NN = 0xij) attribute to 0x01. 14

f. Set the ReservationLabel for FlowNNReservationRev (NN = 0xij) and 15 FlowNNReservationFwd (NN = 0xij) to High Priority Signaling. Set 16 FlowNNDataOverSignalingAllowedRev (NN = 0xij) to 0x01. Configure the AN to grant 17 the QoS request from the AT and to set ReservationKKIdleStateFwd and 18 ReservationKKIdleStateRev to 0x0 for ReservationLabel kk associated with High 19 Priority Signaling. 20


h. Instruct the AT to send a ReservationOn message for ReservationLabel kk associated 23 with High Priority Signaling data that is to be carried using DataOverSignaling message 24 to the AN and ensure that the AN responds with a ReservationAccept message. 25


j. Cause the AN to transmit a packet directed to the AT using the DataOverSignaling 27 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 28 Ensure that the DataOverSignaling Message size is less than the ControlChannel 29 capsule size (600 bytes). 30

k. Verify that the AN transmits a DataOverSignaling Message with MessageID field set to 31 0x14, AckRequired field set to 1, Reset field set to 0, MessageSequence field set to 0, 32 and the HigherLayerPacket field set to entire higher layer packet. 33

l. Verify that if the AT received the DataOverSignaling Message, it transmits a 34 DataOverSignalingAck with MessageID field set to 0x15 and AckSequence field set to 35 zero and the packet carried in the DataOverSignaling message is delivered to the 36 higher layer protocol. 37

m. Cause the AN to transmit a packet directed to the AT using the DataOverSignaling 38 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 39 Ensure that the DataOverSignaling message size is smaller than the Control Channel 40 capsule size (600 bytes). 41

n. Verify that the AN transmits a DataOverSignaling Message with MessageSequence 42 field set to 1. 43

o. Verify that if the AT received the DataOverSignaling Message, it transmits a 44 DataOverSignalingAck with the AckSequence field set to one and the packet carried in 45 the DataOverSignaling message is delivered to the higher layer protocol. 46

3GPP2 C.S0044-D v1.0

18-34


The AT shall comply with steps l and o. 2

The AN shall comply with steps k and n. 3

18.34 Voice Origination in HRPD Idle Mode 4


This test verifies a voice origination call when in idle HRPD mode. 6


(see [29]) 8

(see [30]) 9

(see [24]) 10


Chapter 8 Connection Layer 12

Chapter 10 MAC Layer 13

(see [26]) 14

Chapter 3 HRPD IOS Call Flows 15

(see [4]) 16







2.7.3 Orders 23






3.7.4 Orders 29

3.7.5.5 Signal 30


None. 32


a. Connect the hybrid AT to the AN as shown in Figure A-5 with AN 1 configured as 34 cdma2000 1x and AN 2 configured as HRPD. 35

3GPP2 C.S0044-D v1.0

18-35

b. Initiate a voice call from the hybrid AT. 1

c. Verify the call completes and verify CDMA user data in both directions. 2

d. End the call. 3


The AT and AN shall comply with step c. 5

18.35 Voice Termination in HRPD Idle Mode 6


This test verifies a voice termination call when in idle HRPD mode. 8


(see [29]) 10

(see [30]) 11

(see [24]) 12




(see [26]) 16


(see [4]) 18







2.7.3 Orders 25






3.7.4 Orders 31

3.7.5.5 Signal 32


None 34

3GPP2 C.S0044-D v1.0

18-36



b. Initiate a voice call to the hybrid AT. 4

c. Verify the call completes and verify CDMA user data in both directions. 5

d. End the call. 6



18.36 SMS Origination in HRPD Idle Mode 9


This test verifies SMS Origination when in idle HRPD mode. 11


(see [29]) 13

(see [30]) 14

(see [24]) 15




(see [26]) 19


(see [13]) 21


None 23



b. Instruct the hybrid AT to send an SMS message to the network on the r-csch. 27

c. Verify SMS message is correctly sent to the SMS Message Center. 28

d. Instruct the hybrid AT to send an SMS message on the r-dsch. 29

e. Verify the SMS is correctly sent to the SMS Message Center. 30


The AT and AN shall comply with steps c and e. 32

3GPP2 C.S0044-D v1.0

18-37

18.37 SMS Termination in HRPD Idle Mode 1


This test verifies SMS termination when in idle HRPD mode. 3


(see [29]) 5

(see [30]) 6

(see [24]) 7




(see [26]) 11


(see [13]) 13


None. 15



b. Instruct the network to send an SMS message to the hybrid AT on the f-csch. 19

c. Verify SMS message is correctly received at the hybrid AT. 20

d. Instruct the network to send an SMS message to the hybrid AT on the f-dsch. 21

e. Verify the SMS message is correctly received at the hybrid AT. 22


The AT and AN shall comply with steps c and e. 24

18.38 Voice Origination in HRPD Active Mode 25

Note: A hybrid AT may not support this feature 26


This test verifies a voice origination call when in active HRPD mode. 28


(see [29]) 30

(see [30]) 31

(see [24]) 32



3GPP2 C.S0044-D v1.0

18-38


(see [26]) 2


(see [4]) 4







2.7.3 Orders 11






3.7.4 Orders 17

3.7.5.5 Signal 18


None 20



b. Initiate a HRPD packet data call from the hybrid AT. 24

c. Issue a continuous “ping” command from the hybrid AT to a remote host. 25

d. Initiate a voice call from the hybrid AT. 26

e. Verify the call completes and verify CDMA user data in both directions. 27

f. End the voice call. 28

g. After call is released, verify that hybrid AT re-connects the HRPD packet data call and 29 pings are continuous on same ppp session. 30

h. End the HRPD packet data call. 31


The AT shall comply with steps e and g 33

The AN shall comply with step e. 34

18.39 Voice Termination in HRPD Active Mode 35


3GPP2 C.S0044-D v1.0

18-39


This test verifies a voice termination call when in active HRPD mode. 2


(see [29]) 4

(see [30]) 5

(see [24]) 6




(see [26]) 10


(see [4]) 12







2.7.3 Orders 19






3.7.4 Orders 25

3.7.5.5 Signal 26


None 28





d. Initiate a voice call to the AT. 34



3GPP2 C.S0044-D v1.0

18-40

g. After call is released, verify that hybrid AT re-connects the HRPD packet data call on 1 the same PPP session and pings are continuous. 2

h. End the HRPD packet data call. 3



The AN shall comply with step e 6

18.40 SMS Origination in HRPD Active Mode 7



This test verifies SMS Origination when in active HRPD mode. 10


(see [29]) 12

(see [30]) 13

(see [24]) 14




(see [26]) 18


(see [13]) 20


None 22





d. Instruct the hybrid AT to send an SMS message to the network on the r-csch 28

e. Verify SMS message is correctly sent to the SMS Message Center. 29

f. After SMS Origination procedure is completed, verify that hybrid AT starts sending and 30 receiving continuous pings on HRPD on the same PPP session. 31

g. Instruct the hybrid AT to send an SMS message to the network on the r-dsch. 32

h. Verify SMS message is correctly sent to the SMS Message Center. 33

i. After SMS Origination procedure is completed, verify that hybrid AT starts sending and 34 receiving continuous pings on HRPD on the same PPP session. 35

j. End the HRPD packet data call. 36

3GPP2 C.S0044-D v1.0

18-41


The AT shall comply with steps e, f, h and i 2

The AN shall comply with steps e and i. 3

18.41 SMS Termination in HRPD Active Mode 4



This test verifies SMS termination when in active HRPD mode. 7


(see [29]) 9

(see [30]) 10

(see [24]) 11




(see [26]) 15


(see [13]) 17


None 19





d. Instruct the network to send an SMS message to the hybrid AT on the f-csch. 25

e. Verify SMS message is correctly received by the hybrid AT. 26

f. After SMS message is received, verify that hybrid AT starts sending and receiving 27 continuous pings on HRPD on the same PPP session. 28

g. Instruct the network to send an SMS message to the hybrid AT on the f-dsch. 29

h. Verify SMS message is correctly received by the hybrid AT. 30

i. After SMS message is received, verify that hybrid AT starts sending and receiving 31 continuous pings on HRPD on the same PPP session. 32

j. End the HRPD packet data call. 33


The AT shall comply with steps e, f, h and i 35

The AN shall comply with steps e and i. 36

3GPP2 C.S0044-D v1.0

18-42

18.42 Voice Origination in HRPD Dormant Mode 1



This test verifies a voice origination call when in dormant HRPD mode. 4


(see [29]) 6

(see [30]) 7

(see [24]) 8




(see [26]) 12


(see [4]) 14







2.7.3 Orders 21






3.7.4 Orders 27

3.7.5.5 Signal 28


None 30




c. Wait for hybrid AT to go dormant. 35

d. Initiate a voice call from the hybrid AT. 36

3GPP2 C.S0044-D v1.0

18-43



g. Verify that PPP connection is not dropped, hybrid AT is in dormant state and HRPD 3 session is active. 4

h. Issue a ping command and verify that pings are successful. 5

i. End the HRPD packet data call. 6


The AT shall comply with steps e, g and h 8

The AN shall comply with step e and h 9

18.43 Voice Termination in HRPD Dormant Mode 10


This test verifies a voice termination call when in dormant HRPD mode. 12


(see [29]) 14

(see [30]) 15

(see [24]) 16




(see [26]) 20


(see [4]) 22







2.7.3 Orders 29






3.7.4 Orders 35

3.7.5.5 Signal 36

3GPP2 C.S0044-D v1.0

18-44


None 2





d. Initiate a voice call to the hybrid AT. 8



g. Verify that PPP connection is not dropped and hybrid AT is in dormant state. 11

h. Issue a ping command and verify that pings are successful. 12

i. End the HRPD packet data call. 13


The AT shall comply with steps e, g and h 15

The AN shall comply with step e and h. 16

18.44 SMS Origination in HRPD Dormant Mode 17


This test verifies SMS Origination when in dormant HRPD mode. 19


(see [29]) 21

(see [30]) 22

(see [24]) 23




(see [26]) 27


(see [13]) 29


None 31




3GPP2 C.S0044-D v1.0

18-45


d. Instruct the hybrid AT to send an SMS message to the network on the r-csch. 2

e. Verify SMS message is correctly sent to the SMS Message Center. 3

f. Verify that PPP connection is not dropped and hybrid AT is in dormant state. 4

g. Issue a ping command and verify that pings are successful. 5

h. Wait for hybrid AT to go dormant. 6

i. Instruct the hybrid AT to send an SMS message to the network on the r-dsch. 7

j. Verify SMS message is correctly sent to the SMS Message Center. 8

k. Verify that PPP connection is not dropped and hybrid AT is in dormant state. 9

l. Issue a ping command from the remote host and verify that the ping is successful. 10

m. End the HRPD packet data call. 11


The AT shall comply with steps e, f, g, j, k and l. 13

The AN shall comply with steps e, g, j and l. 14

18.45 SMS Termination in HRPD Dormant Mode 15


This test verifies SMS termination when in dormant HRPD mode. 17


(see [29]) 19

(see [30]) 20

(see [24]) 21




(see [26]) 25


(see [13]) 27


None 29





d. Instruct the network to send an SMS message to the hybrid AT on the f-csch. 35

3GPP2 C.S0044-D v1.0

18-46

e. Verify SMS message is correctly received by the hybrid AT. 1

f. Verify that PPP connection is not dropped and hybrid AT is in dormant state. 2

g. Issue a ping command from the remote host and verify that the ping is successful. 3

h. Wait for hybrid AT to go dormant. 4

i. Instruct the network to send an SMS message to the hybrid AT on the f-dsch. 5

j. Verify SMS message is correctly received by the hybrid AT. 6

k. Verify that PPP connection is not dropped and hybrid AT is in dormant state. 7

l. Issue a ping command and verify that pings are successful. 8

m. End the HRPD packet data call. 9


The AT shall comply with steps e, f, g, j, k and l. 11

The AN shall comply with steps e, g, j and l. 12

18.46 Inter Revision Handoffs - Dormant HRPD Rev A to HRPD Rev 0 13


This test verifies inter-technology handoff from dormant HRPD RevA to HRPD Rev0 using mobile 15 IP. 16


(see [29]) 18

(see [30]) 19

(see [24]) 20




(see [26]) 24


(see [4]) 26







2.7.3 Orders 33




3GPP2 C.S0044-D v1.0

18-47



3.7.4 Orders 3

3.7.5.5 Signal 4


None 6


a. Connect the hybrid AT to the AN as shown in Figure A-5 with AN 1 configured as HRPD 8 RevA and AN 2 configured as HRPD Rev0. 9

b. Configure the hybrid AT for mobile IP mode and during session configuration negotiate 10 one personality defined for HRPD Rev A and one personality defined for HRPD Rev 0. 11 Note, the session configuration with multiple personalities needs to be done with AN 12 configured with HRPD Rev A. 13

c. Cause the hybrid AT to acquire AN 1 configured as HRPD RevA and negotiate 2 14 personalities during the HRPD session configuration. 15

d. Initiate a HRPD RevA packet data call from the hybrid AT. 16

e. Record the IP address assigned to the hybrid AT. 17

f. Wait for hybrid AT to go dormant. 18

g. Instruct AN 1 configured as HRPD RevA to initiate handoff to AN 2 configured as HRPD 19 Rev0. 20

h. Ensure the AN 1 sends an AttributeUpdateRequest with the 21 SessionConfigurationToken instructing the AT to switch to the personality for the HRPD 22 Rev 0 network. 23

i. Verify the AT sends an AttributeUpdateAccept to the AN 1 and begins using the HRPD 24 Rev 0 personality. 25

j. Ensure that the hybrid AT is dormant for data (active pilot set) on AN 2 configured as 26 HRPD Rev0. 27

k. Issue a “ping” command from the remote host to the hybrid AT using the IP address 28 assigned to the AT in step e. 29

l. Verify the hybrid AT is active for data on AN 2 configured for HRPD Rev0, and verify 30 the remote host receives a “ping” response from the hybrid AT. 31

m. End the call. 32


The AT shall comply with steps i and l. 34

18.47 Inter Revision Handoffs - Active HRPD Rev A to HRPD Rev 0 35


This test verifies inter-technology handoff from active HRPD RevA to HRPD Rev0 using mobile 37 IP. 38

3GPP2 C.S0044-D v1.0

18-48


(see [29]) 2

(see [30]) 3

(see [24]) 4




(see [26]) 8


(see [4]) 10







2.7.3 Orders 17






3.7.4 Orders 23

3.7.5.5 Signal 24


None 26


a. Connect the hybrid AT to the AN as shown in Figure A-5 with AN 1 configured as HRPD 28 RevA and AN 2 configured as HRPD Rev0. 29


c. Cause the hybrid AT to acquire AN 1 configured as HRPD RevA and negotiate 2 34 personalities during the HRPD session configuration. 35

d. Initiate a HRPD RevA packet data call from the hybrid AT. 36


3GPP2 C.S0044-D v1.0

18-49

f. Issue a continuous “ping” command from the remote host to the hybrid AT using the IP 1 address assigned to the AT in step e. 2

g. Verify AT is active for data on AN 1 configured as HRPD RevA, and verify the remote 3 host receives a “ping” response from the AT. 4

h. Instruct AN 1 configured as HRPD RevA to initiate handoff to AN 2 configured as HRPD 5 Rev0. 6

i. Ensure the AN 1 sends an AttributeUpdateRequest with the 7 SessionConfigurationToken instructing the AT to switch to the personality for the HRPD 8 Rev 0 network. 9

j. Verify the AT sends an AttributeUpdateAccept to the AN 1. 10

k. Verify that the AN 1 transmits a ConnectionClose together with a 11 TrafficChannelAssignment message. 12

l. Verify that the AT reestablishes the connection and starts using the HRPD Rev 0 13 personality. 14

m. Verify hybrid AT is active for data on AN 2 configured as HRPD Rev0 and verify the 15 remote host receives a “ping” response from the hybrid AT. 16

n. End the call. 17


The AT shall comply with the steps g, j, l and m. 19

The AN shall comply with step k and m. 20

18.48 Inter Revision Handoffs – Dormant HRPD Rev 0 to HRPD Rev A 21


This test verifies inter-technology handoff from dormant HRPD Rev0 to HRPD RevA using mobile 23 IP. 24


(see [29]) 26

(see [30]) 27

(see [24]) 28




(see [26]) 32


(see [4]) 34





3GPP2 C.S0044-D v1.0

18-50



2.7.3 Orders 3






3.7.4 Orders 9

3.7.5.5 Signal 10


None 12


a. Connect the hybrid AT to the AN as shown in Figure A-5 with AN 2 configured as HRPD 14 Rev0 and AN 1 configured as HRPD RevA. 15


c. Cause the hybrid AT to acquire AN 2 configured as HRPD Rev0. 20

d. Initiate a HRPD Rev0 packet data call from the hybrid AT. 21



g. Instruct AN 2 configured as HRPD Rev0 to initiate handoff to AN 1 configured as HRPD 24 RevA. 25

h. Ensure that hybrid AT is dormant for data (active pilot set) on AN 1 configured as HRPD 26 RevA. 27

i. Ensure the AN 1 sends an AttributeUpdateRequest with the 28 SessionConfigurationToken instructing the AT to switch to the personality for the HRPD 29 Rev A network. 30

j. Verify the AT sends an AttributeUpdateAccept to the AN 1 and begins using the HRPD 31 Rev A personality. 32

k. Issue a “ping” command from the remote host to the hybrid AT using the IP address 33 assigned to the AT in step e. 34

l. Verify the hybrid AT is active for data on AN 1 configured for HRPD RevA, and verify 35 the remote host receives a “ping” response from the hybrid AT. 36

m. End the call. 37


The AT and AN shall comply with steps j and l. 39

The AN shall comply with step l. 40

3GPP2 C.S0044-D v1.0

18-51

18.49 Inter Revision Handoffs – Active HRPD Rev 0 to HRPD Rev A 1


This test verifies inter-technology handoff from active HRPD Rev0 to HRPD RevA using mobile 3 IP. 4


(see [29]) 6

(see [30]) 7

(see [24]) 8




(see [26]) 12


(see [4]) 14







2.7.3 Orders 21






3.7.4 Orders 27

3.7.5.5 Signal 28


None 30


a. Connect the hybrid AT to the AN as shown in Figure A-5 with AN 2 configured as HRPD 32 Rev0 and AN 1 configured as HRPD RevA. 33


3GPP2 C.S0044-D v1.0

18-52

c. Cause the hybrid AT to acquire AN 2 configured as HRPD Rev0. 1

d. Initiate a HRPD Rev0 packet data call from the hybrid AT. 2



g. Ensure that AT is active for data on AN 2 configured as HRPD Rev0, and verify the 6 remote host receives a “ping” response from the AT. 7

h. Instruct AN 2 configured as HRPD Rev0 to initiate handoff to AN 1 configured as HRPD 8 RevA. 9

i. Verify hybrid AT is active for data on AN 1 configured as HRPD RevA and verify the 10 remote host receives a “ping” response from the hybrid AT. (The AT will continue to use 11 the HRPD Rev 0 session configuration) 12

j. Terminate the ping session and allow the AT to go dormant on AN 1. 13

k. After the device has gone dormant, initiate another ping from the AT to the AN. 14

l. Verify the AT and AN 1 negotiate the HRPD session using the HRPD Rev A personality 15 and the call completes successfully. 16

m. End the call. 17



The AN shall comply with step l. 20

18.50 Inter Technology Switching – Dormant HRPD to cdma2000 1x 21


This test verifies inter-technology switching from dormant HRPD to cdma2000 1x using mobile IP. 23 This test only applies to AT that are capable of switching from HRPD to cdma2000 1x while the 24 AT is dormant. The algorithm for switching is AT dependent and should be known before test 25 case execution. The test should be repeated using all supported revisions of [24] supported by 26 the AT and AN. 27


(see [29]) 29

(see [30]) 30

(see [24]) 31




(see [26]) 35


(see [4]) 37



3GPP2 C.S0044-D v1.0

18-53





2.7.3 Orders 5






3.7.4 Orders 11

3.7.5.5 Signal 12


None 14


a. Connect the hybrid AT to the AN as shown in Figure A-5 with AN 1 configured as HRPD 16 and AN 2 configured as cdma2000 1x. 17

b. Configure the hybrid AT for mobile IP mode. 18

c. Cause the hybrid AT to acquire AN 1 configured as HRPD. 19

d. Initiate a HRPD packet data call from the hybrid AT. 20



g. Cause the AT terminal to switch from AN 1, configured as HRPD to AN 2 configured as 23 cdma2000 1x. 24

h. Verify hybrid AT is dormant for data (active pilot set) on AN 2 configured as cdma2000 25 1x. 26

i. Issue a “ping” command from the remote host to the hybrid AT using the IP address 27 assigned to the AT in step e. 28

j. Verify the hybrid AT is active for data on AN 2 configured for cdma2000 1x, and verify 29 the remote host receives a “ping” response from the hybrid AT. 30

k. End the call. 31

l. Repeat steps a-k using all supported revisions of [24] by the AT and AN. 32


The AT shall comply with steps h and j 34

The AN shall comply with step j. 35

3GPP2 C.S0044-D v1.0

18-54

18.51 Inter Technology Switching – Active HRPD to cdma2000 1x 1


This test verifies inter-technology switching from active HRPD to cdma2000 1x using mobile IP. 3 This test only applies to AT that are capable of switching from HRPD to cdma2000 1x while the 4 AT is active for data. The algorithm for switching is AT dependent and should be known before 5 test case execution. The test should be repeated using all supported revisions of [24] supported 6 by the AT and AN. 7


(see [29]) 9

(see [30]) 10

(see [24]) 11




(see [26]) 15


(see [4]) 17







2.7.3 Orders 24






3.7.4 Orders 30

3.7.5.5 Signal 31


None 33


a. Connect the hybrid AT to the AN as shown in Figure A-5 with AN 1 configured as HRPD 35 and AN 2 configured as cdma2000 1x. 36


3GPP2 C.S0044-D v1.0

18-55

c. Cause the hybrid AT to acquire AN 1 configured as HRPD. 1

d. Initiate a HRPD packet data call from the hybrid AT. 2



g. Ensure that AT is active for data on AN 1 configured as HRPD and verify the remote 6 host receives a “ping” response from the AT. 7

h. Cause the AT terminal to switch from AN 1, configured as HRPD to AN 2 configured as 8 cdma2000 1x. 9

i. Verify hybrid AT is active for data on AN 2 configured as cdma2000 1x and verify the 10 remote host receives a “ping” response from the hybrid AT. 11

j. End the call. 12

k. Repeat steps a-k using all supported revisions of [24] by the AT and AN. 13


The AT and AN shall comply with step i 15

18.52 Inter Technology Switching – Dormant cdma2000 1x to HRPD 16


This test verifies inter-technology handoff from dormant cdma2000 1x to HRPD using mobile IP. 18 This test only applies to AT that are capable of switching from cdma2000 1x to HRPD while the 19 AT is dormant. The algorithm for switching is AT dependent and should be known before test 20 case execution. The test should be repeated using all supported revisions of [24] supported by 21 the AT and AN. 22


(see [29]) 24

(see [30]) 25

(see [24]) 26




(see [26]) 30


(see [4]) 32







3GPP2 C.S0044-D v1.0

18-56

2.7.3 Orders 1






3.7.4 Orders 7

3.7.5.5 Signal 8


None 10




c. Cause the hybrid AT to acquire AN 1 configured as cdma2000 1x. 15

d. Initiate a cdma2000 1x packet data call from the hybrid AT. 16



g. Cause the AT terminal to switch from AN 1, configured as cdma2000 1x to AN 2 19 configured as HRPD. 20

h. Verify hybrid AT is dormant for data (active pilot set) on AN 2 configured as HRPD. 21

i. Issue a “ping” command from the remote host to the hybrid AT using the IP address 22 assigned to the AT in step e. 23

j. Verify the hybrid AT is active for data on AN 2 configured for HRPD, and verify the 24 remote host receives a “ping” response from the hybrid AT. 25

k. End the call 26

l. Repeat steps a-k using all supported revisions of [24] by the AT and AN. 27


The AT shall comply with steps h and j. 29

18.53 Inter RNC Dormant Hand-off (Rev A to Rev A) 30


This test verifies the Inter-RNC dormant handoff is successful. AN 1 and AN 2 have a different 32 RNC. Both AN 1 and AN 2 support HRPD Rev A. RNC 1 and RNC 2 have an A13 link 33 established. 34


(see [24]) 36


3GPP2 C.S0044-D v1.0

18-57





(see [26]) 5

3.7.1 PCF-PCF Dormant Handoff with Successful Retrieval of HRPD Session 6 Information 7


None 9



1. AN 1 and AN 2 have different frequency assignments. 12

2. AN 1 and AN 2 have different RNC connections. Each RNC is broadcasting a 13 different subnet. There is an A13 link between each RNC. 14

b. Cause the AT to acquire AN 1. Setup an HRPD AT originated call. 15

c. Ensure that the AT connection is idle and the PPP session is dormant. 16

d. Force the AT to handoff from AN 1 to AN 2. 17

e. After the AT has successfully acquired AN 2, issue a “ping” from AT. 18

f. Verify the AT successfully establishes an HRPD connection and call on AN 2, RNC 2. 19



18.54 Inter RNC Active Hand-off (Rev A to Rev A) 22


This test verifies the Inter-RNC active handoff is successful. AN 1 and AN 2 have a different 24 RNC. Both AN 1 and AN 2 support HRPD Rev A. RNC 1 and RNC 2 have an A13 link 25 established. 26


(see [24]) 28






(see [26]) 34


3GPP2 C.S0044-D v1.0

18-58


None 2



1. AN 1 and AN 2 supports HRPD Rev A and have different frequency 5 assignments. 6


b. Cause the AT to acquire AN 1. Set up an HRPD AT originated call. 9

c. Initiate a forward data transfer using the maximum supported data rate to the AT (i.e. 10 use the FTP “get” command from the AT) 11

d. Force the AT to handoff from AN 1 to AN 2 before the file transfer is completed. 12

e. Verify the AT successfully acquires AN 2, RNC 2, and the file transfer is completed. 13


The AT shall comply with step e. 15

18.55 Inter RNC Dormant Hand-off (Rev A to Rev 0) 16


This test verifies the Inter-RNC dormant handoff is successful. AN 1 and AN 2 have a different 18 RNC. AN 1 supports HRPD Rev A and AN 2 support HRPD Rev 0. RNC 1 and RNC 2 have an 19 A13 link established. 20


(see [24]) 22






(see [26]) 28



None. 32



1. AN 1 supports HRPD Rev A and AN 2 supports HRPD Rev 0 and have different 35 frequency assignments. 36

3GPP2 C.S0044-D v1.0

18-59


b. Cause the AT to acquire AN 1 and negotiate multiple personalities with one personality 3 defined for HRPD Rev A and one personality defined for HRPD Rev 0 4

c. Setup an HRPD AT originated call ensure that the AT connection is idle and the PPP 5 session is dormant. 6


e. Ensure the AN 1 sends an AttributeUpdateRequest with the 8 SessionConfigurationToken instructing the AT to switch to the personality for the HRPD 9 Rev 0 network. 10

f. Verify the AT sends an AttributeUpdateAccept to the AN 1 and begins using the HRPD 11 Rev 0 personality. 12

g. After the AT has successfully acquired AN 2, issue a “ping” from AT. 13

h. Verify the AT successfully establishes an HRPD connection and call on AN 2, RNC 2. 14


The AT shall comply with steps f and h. 16

18.56 Inter RNC Active Hand-off (Rev A to Rev 0) 17


This test verifies the Inter-RNC active handoff is successful. AN 1 and AN 2 have a different 19 RNC. AN 1 supports HRPD Rev A and AN 2 support HRPD Rev 0. RNC 1 and RNC 2 have an 20 A13 link established. 21


(see [24]) 23






(see [26]) 29



None 33



1. AN 1 supports HRPD Rev A and AN 2 supports HRPD Rev 0 and have different 36 frequency assignments. 37

2. AN 1 and AN 2 have different RNC connections. Each RNC is broadcasting a 38 different subnet. There is an A13 link between each RNC 39

3GPP2 C.S0044-D v1.0

18-60

b. Cause the AT to acquire AN 1 and negotiate multiple personalities with one personality 1 defined for HRPD Rev A and one personality defined for HRPD Rev 0 2

c. Set up an HRPD AT originated call and initiate a forward data transfer using the 3 maximum supported data rate to the AT (i.e. use the FTP “get” command from the AT) 4


e. Ensure the AN 1 sends an AttributeUpdateRequest with the 6 SessionConfigurationToken instructing the AT to switch to the personality for the HRPD 7 Rev 0 network. 8

f. Verify the AT sends an AttributeUpdateAccept to the AN 1 and begins using the HRPD 9 Rev 0 personality 10



18.57 Inter RNC Dormant Hand-off (Rev 0 to Rev A) 13


This test verifies the Inter-RNC dormant handoff is successful. AN 1 and AN 2 have a different 15 RNC. AN 1 supports HRPD Rev 0 and AN 2 support HRPD Rev A. RNC 1 and RNC 2 have an 16 A13 link established. 17


(see [24]) 19






(see [26]) 25



None 29



1. AN 1 supports HRPD Rev 0 and AN 2 support HRPD Rev A and have different 32 frequency assignments. 33



3GPP2 C.S0044-D v1.0

18-61

c. Cause the AT to acquire AN 1. Setup an HRPD AT originated call. 1

d. Verify that the AT connection is idle and the PPP session is dormant. 2

e. Force the AT to handoff from AN 1 to AN 2. 3

f. Ensure the AN 1 sends an AttributeUpdateRequest with the 4 SessionConfigurationToken instructing the AT to switch to the personality for the HRPD 5 Rev A network. 6

g. Verify the AT sends an AttributeUpdateAccept to the AN 1 and begins using the HRPD 7 Rev A personality. 8

h. After the AT has successfully acquired AN 2, issue a “ping” from AT. 9

i. Verify the AT successfully establishes an HRPD connection and call on AN 2, RNC 2 10 using the Rev A personality. 11


The AT shall comply with steps g and i. 13

18.58 Inter RNC Active Hand-off (Rev 0 to Rev A) 14


This test verifies the Inter-RNC active handoff is successful. AN 1 and AN 2 have a different 16 RNC. AN 1 supports HRPD Rev A and AN 2 support HRPD Rev 0. RNC 1 and RNC 2 have an 17 A13 link established. 18


(see [24]) 20






(see [26]) 26



None 30



1. AN 1 supports HRPD Rev A and AN 2 supports HRPD Rev 0 and have different 33 frequency assignments. Each RNC is broadcasting a different subnet. There is 34 an A13 link between each RNC. 35

2. AN 1 and AN 2 have different RNC connections. 36

b. Configure the hybrid AT for mobile IP mode and during session configuration negotiate 37 one personality defined for HRPD Rev A and one personality defined for HRPD Rev 0. 38

3GPP2 C.S0044-D v1.0

18-62

Note, the session configuration with multiple personalities needs to be done with AN 1 configured with HRPD Rev A. 2

c. Cause the AT to acquire AN 2. Set up an HRPD AT originated call. 3

d. Initiate a forward data transfer using the maximum supported data rate to the AT (i.e. 4 use the FTP “get” command from the AT) 5


f. Verify the AT successfully acquires AN 1, RNC 1, and the file transfer is completed. 7 (Note: The AT will continue to use the HRPD Rev 0 personality to transfer the file until 8 the HRPD session is re-negotiated.) 9



18.59 Inter-Band Active Hand-off 12


This test verifies that the AT is able to successful acquire a new AN with a different frequency in 14 different Band assignment during an active call. The AT will receive a new 15 TrafficChannelAssignment message with the target frequency information. Since there is no hard 16 handoff mechanism in HRPD, using the new TrafficChannelAssignment allows for faster 17 acquisition of AN 2. 18


(see [24]) 20






3GPP2 C.S0044-D v1.0

18-63


SectorAT

Reverse Pilot + DRC

Traffic Channel Complete

Traffic Channel Assignment corresponding

to configured target carrier sectors

aRoute Update

c

d

e

Sector

s25

Sector

s16

Reset Report*b

Route Update*

*This step is conditional , this may or , may not take place in the message exchangesequence, based on the trigggers generated by mobility

f

2


a. Connect the AT to AN 1 (Band 1) and AN 2 (Band 2) as shown in Figure A-5. 4


2. AN 1 and AN 2 have the same RNC connections. 6

b. Cause the AT to acquire AN 1. Setup an HRPD AT originated call. 7

c. Initiate a forward data transfer to the AT. 8

d. Trigger a hard handoff from AN 1 to AN 2 by sending a TrafficChannelAssignment with 9 the target information for AN 2. 10

e. Verify the AT tunes to the new frequency and the file transfer completes successfully. 11

f. The delay between losing AN 1 and acquiring AN 2 should be less than 500ms. 12


The AT shall comply with step e and should comply with step f. 14

The AN should comply with step f. 15

3GPP2 C.S0044-D v1.0

18-64

18.60 RLP Activation 1


This test verifies the ability of the AN to activate RLP flows during session negotiation and later 3 associate these active RLP flows to requested QoS. In the test, it is assumed that the AN will be 4 able to accept the reservation requests generated by the AT. Note that each of the reservation 5 requests may have multiple ProfileIDs and it is possible for the AN to accept any one or none of 6 these Profiles. Typically, the AN should accept AT’s most preferred profile, unless it is not able to 7 support this profile due to resource constraints or other reasons. 8



(see [24]) 15

Chapter 4 Multiflow Packet Application 16

(see [12]) 17

Chapters 2 and 3 18


None 20




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 24 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 25 service network, Physical layer subtype 2 and Subtype 3 RTC MAC. 26

d. Configure the AN to activate MaxActivatedRLPFlowsFwd Forward Link Flows and 27 MaxActivatedRLPFlowsRev Reverse Link Flows during session configuration. 28


f. Power cycle the AT. 31

g. Ensure that the AT establishes a session with the AN and acquires the HRPD system. 32

h. Verify that the AN activates MaxActivatedRLPFlowsFwd Forward Link Flows and 33 MaxActivatedRLPFlowsRev Reverse Link Flows during session configuration. 34

i. Cause the AT to establish a data call with the AN. 35

j. Allow the AT to go idle. 36

k. Trigger a QoS request by starting any application that requires reservation for at least 37 one forward and one reverse link flow. An example of such an application would be 38 video telephony. 39

l. Verify that during the subsequent signaling the AN does not transmit 40 AttributeUpdateRequest messages containing 41 FlowNNIdentificationFwd/FlowNNIdentificationRev attributes for any flow. 42

3GPP2 C.S0044-D v1.0

18-65

m. Verify that if the AN did not negotiate FlowNNReservationFwd and 1 FlowNNReservationRev attributes during session negotiation, then the AN transmits 2 AttributeUpdateRequest messages(s) containing FlowNNReservationFwd attributes 3 binding ReservationLabel(s) to Forward Link RLP flow(s) NN and 4 FlowNNReservationRev attributes binding ReservationLabel(s) to Reverse Link flow(s). 5

n. Verify that if the AN transmits AttributeUpdateRequest messages(s) containing 6 FlowNNReservationFwd and FlowNNReservationRev attributes, then the AT transmits 7 AttributeUpdateAccept message to the AN accepting the FlowNNReservationFwd and 8 FlowNNReservationRev attributes. 9

o. Verify that if the AN did not negotiate AssociatedFlowNN attribute during session 10 negotiation, then the AN transmits AttributeUpdateRequest message containing 11 AssociatedFlowNN attribute binding the RLP flow(s) to the RTCMAC flow(s). 12

p. Verify that if the AN transmits AttributeUpdateRequest messages(s) containing 13 AssociatedFlowNN attribute, then the AT transmits AttributeUpdateAccept message(s) 14 to the AN accepting the binding sent by the AN in AssociatedFlowsNN attribute. 15

q. Start data transfer for each of the forward and reverse link higher layer flows that are 16 bound to an RLP flow through FlowNNReservationFwd and FlowNNReservationRev 17 attributes. 18

r. Verify that the AT uses Flow NN to transmit data for higher layer flow with 19 ReservationLabel KK if the ReservationLabel KK was mapped to Flow NN through 20 FlowNNReservationRev attribute. 21

s. Verify that the AN uses Flow NN to transmit data for higher layer flow with 22 ReservationLabel KK if the ReservationLabel KK was mapped to Flow NN through 23 FlowNNReservationFwd attribute. 24


The AT shall comply with steps n, p and r. 26

The AN shall comply with steps h, l, m, o and s. 27

18.61 QoS Set Up 28


This test verifies the ability of the AN and the AT to set-up and use QoS for any application. The 30 application may reside at the AT or the TE (Terminal Equipment). Specifically, for setting up the 31 QoS for the application, this test verifies that the QoS request and response, reservation to RLP 32 binding, RLP to RTCMAC flow binding on the reverse link, RLP and RTCMAC flow activation, and 33 opening the reservations. This test also verifies the GAUP messages needed to update various 34 attributes and parameters. Note for this test each of the reservation requests may have multiple 35 ProfileIDs and it is possible for the AN to accept any one or none of the Profiles. Typically, the AN 36 should accept AT’s most preferred profile, unless it is not able to support this profile due to 37 resource constraints or other reasons. Unless otherwise specified, this test assumes that the AN 38 will be able to accept any of the proposed profiles. 39

It is assumed that the application needs one or more higher layer flows that are identified by their 40 ReservationLabels. Each higher layer flow is bound to an RLP. More than one flow may be bound 41 to an RLP. On the reverse link, the RLP ids are in turn bound to 1 or more MAC Flows. For 42 example a Video Telephony application may require three separate higher layer flows 43 (reservations) for audio, video and SIP signaling. The application may be designed to map audio 44 and video higher layer flows to separate RLPs (due to different abort timer requirements for audio 45 and video, for example), but transmit SIP flows’ data through the default RLP that is typically used 46

3GPP2 C.S0044-D v1.0

18-66

for best effort traffic. On the reverse link RLP ids used by audio and video may be mapped to 1 different MAC flows that are configured to provide different latencies, for example. 2


(see [24]) 4

Chapter 4 Multi-Flow Packet Application 5

(see [12]) 6

Chapters 2 and 3 7

(see [10]) 8


None 10


a. Connect the AT to the AN as shown in Figure A-3. If the application resides on the TE 12 connect the TE to the AT. 13



d. Configure the AN to activate only the default RLP flow during session configuration. 18 This can be done by setting the active parameter of the FlowNNIdentificationFwd and 19 FlowNNIdentificationRev attribute to 0 for all RLP flows with NN ≠ 0. 20

e. Ensure that the AN activates only the default RLP flow during session configuration. 21

f. If the AT has an established session with the AN, cause either the AT or the AN to 22 close the session by transmitting a SessionClose message. 23



i. Cause the AT to start the application that needs to be tested. The application will 26 generate QoS requests for all forward and reverse link flow(s). 27

j. Verify that the AT transmits GAUP message(s) with ReservationKKQoSReqFwd with 28 R_QoS_SUB_BLOB containing the specified Profile ID for forward flow(s) and 29 ReservationKKQoSReqRev with R_QoS_SUB_BLOB containing the specified Profile ID 30 for reverse flow(s). 31

k. Verify that the AT constructs a Traffic Flow Template (TFT) with the desired packet 32 filters and sends an RSVP Resv [Create new TFT] message. 33

l. Verify that the AN transmits AttributeUpdateAccept message(s) accepting the QoS 34 ReservationKKQoSRequestFwd/ ReservationKKQoSRequestRev attributes from the 35 AT. 36

m. The AN should GAUP the ReservationKKQoSResponseFwd with G_QoS_BLOB 37 containing the set ID for primary Profile ID for all the higher layer flow(s) of the 38 application. 39

n. Verify that the PDSN installs the desired packet filters and sends an RSVP ResvConf 40 message. 41

3GPP2 C.S0044-D v1.0

18-67

o. Verify that the AT transmits AttributeUpdate message(s) to the AN accepting the AN’s 1 ReservationKKQosResponseFwd and ReservationKKQosResponseRev for the 2 ReservationLabel(s). 3

p. Verify that the AN transmits a GAUP message for FlowNNIdentificationFwd and 4 FlowNNIdentificationRev in order to activate the forward and reverse link flow(s). 5

q. Verify that the AT transmits AttributeUpdateAccept message(s) accepting 6 FlowNNIdentificationFwd and FlowNNIdentificationRev attributes. 7

r. Verify that the AN transmits a GAUP message for FlowNNReservationFwd and 8 FlowNNReservationRev for binding the reservations to RLP flow(s). 9

s. Verify that the AT transmits AttributeUpdateAccept message(s) accepting 10 FlowNNReservationFwd and FlowNNReservationRev values. 11

t. The AN will determine the number of Forward and Reverse Link RLP flows and 12 RTCMAC flows needed to support the accepted QoS requests. The AN may need to 13 transmit AttributeUpdateRequest message(s) negotiating the parameters for Forward 14 and Reverse link and RLP flows and RTCMAC flows. 15

u. If the AN transmits Attribute Update Request for the Forward and Reverse Link RLP 16 Flows and/or RTCMAC flows, verify that the AT transmits AttributeUpdateAccept 17 message(s) accepting RLP and RTCMAC parameters. 18

v. Verify that the AN transmits AttributeUpdateRequest message containing 19 AssociatedFlowNN with substream field set to 1 to bind the RLP flow(s) to the RTCMAC 20 flow(s). 21

w. Verify that the AT transmits AttributeUpdateAccept message(s) to the AN accepting the 22 binding sent by the AN in AssociatedFlowsNN attribute. 23

x. The AN should GAUP RTCMAC BucketLevelMaxNN with a nonzero value to activate 24 the RTCMAC flow(s). 25

y. Verify that the AT transmits AttributeUpdateAccept message to the AN accepting the 26 BucketLevelMaxNN value sent by the AN. 27

z. Verify that the AT sends ReservationOnRequest for both the forward and reverse 28 ReservationLabel(s) using single ReservationOnRequest message. 29

aa. Verify that AN sends ReservationAccept for both forward and reverse reservations. 30

bb. Verify that both the forward and reverse RLP flows are activated and all the 31 reservations are in Open state. 32

cc. Once the application starts data transfer, verify that data is being sent on the 33 appropriate RLP IDs on the forward link and on the appropriate RLP and MAC Flows on 34 the reverse link. 35

dd. Ensure that the PDSN is sending data via the intended filter. 36


The AT shall comply with steps j, k, o, q, s, u, w, y, z, bb, and cc. 38

The AN shall comply with steps l, p, r, v, aa, bb, and cc. 39

The AN should comply with steps m and x. 40

The PDSN should comply with steps n and dd. 41

3GPP2 C.S0044-D v1.0

18-68

18.62 Successful negotiation of Enhanced Idle State Protocol 1


This test verifies negotiation and successful setup of the Enhanced Idle State Protocol. 3


(see [24]) 5



8.5.7.1 Simple Attributes 8


None 10


a. Connect the AT to the AN as shown in Figure A-3. Ensure that the AT does not have a 12 previously assigned UATI from the AN. 13

b. Configure the AN and AT to support Enhanced Idle State Protocol. 14

c. Power on the AT. 15

d. During HRPD session negotiation, verify the AT sends a ConfigurationRequest 16 message that includes the following values: 17

Field Value

Protocol Type

0x0c

(Idle State Protocol)

Protocol Subtype 0x0001

(Enhanced Idle State)

e. Ensure the AN responds with a ConfigurationResponse message including the 18 following: 19

Field Value

Protocol Type

0x0c




f. If the AT supports hybrid mode operation and hybrid mode is enabled, verify the AT 20 sends a second ConfigurationRequest that includes the following: 21

3GPP2 C.S0044-D v1.0

18-69

Field Value

AttributeID 0x00 (PreferredControlChannelCycle)

PreferredControlChannelCycleEnabled 0x1

PreferredControlChannelCycle Value

1

Field Value

AttributeID= 0xff

(SmallSlotCycleAllowed)

0

2

g. Ensure the AN accepts the proposed configuration. 3

h. Set up an AT originated HRPD Rev A call and allow the data session to go dormant. 4

i. Verify the AT is operating in slotted mode with a 5.12 second interval. 5

j. Issue a ping to the AT. 6

k. Verify the AT responds to the HRPD page request successfully. 7


The AT shall comply with steps d, f, i, and k. 9

18.63 Unsuccessful Enhanced Idle State Protocol due to AN rejection 10


This test verifies the AT falls back to the default idle protocol if the Enhanced Idle State Protocol 12 is rejected by the AN. 13


(see [24]) 15





None 20


a. Connect the AT to the AN as shown in Figure A-3. Ensure that the AT does not have a 22 previously assigned UATI from the AN. 23

3GPP2 C.S0044-D v1.0

18-70

b. Configure the AT to support Enhanced Idle State Protocol. Configure the AN to not 1 support Enhanced Idle State Protocol. 2


d. During HRPD session negotiation, verify the AT sends a ConfigurationRequest 4 message that includes the following values 5

Field Value

Protocol Type

0x0c




e. Ensure the AN rejects the request and sends a ConfigurationResponse with an empty 6 attribute. 7

f. Verify AT and AN negotiate and successfully setup the HRPD session with the default 8 idle state protocol. 9

g. Set up an AT originated HRPD Rev A call and allow the data session to go dormant. 10

h. Verify the AT is operating in slotted mode with a 5.12 second interval. 11

i. Issue a ping to the AT. 12

j. Verify the AT responds to the HRPD page request successfully. 13


The AT shall comply with steps d, f, h and j. 15

18.64 SlottedMode Attribute Negotiation for Enhanced Idle State Protocol 16


This test verifies negotiation and successful setup of the Enhanced Idle State Protocol and 18 negotiation of the SlottedMode attribute. 19


(see [24]) 21





None 26


a. Connect the mobile station to the base station as shown in Figure A-3. Ensure that the 28

AT does not have a previously assigned UATI from the AN. 29

3GPP2 C.S0044-D v1.0

18-71

b. Configure the AN and AT to support Enhanced Idle State Protocol. Configure the AN to 1

propose the SlottedMode attribute. 2


d. During HRPD session negotiation, verify the AT sends a ConfigurationRequest 4

message that includes the following values: 5

6

Field Value

Protocol Type

0x0c




7

e. Ensure the AN responds with a ConfigurationResponse message including the 8

following: 9

10

Field Value

Protocol Type

0x0c




11

f. Verify the AN sends a ConfigurationRequest that includes the following: 12

13

Field Value

AttributeID 0x01 (SlottedMode)

SlotCycle1 0x6

SlotCycle2 0x6

SlotCycle3 0x6

WakeCount1 0 (default)


3GPP2 C.S0044-D v1.0

18-72

g. Verify the AT accepts the configuration proposed by the AN. 1

h. Set up an AT originated HRPD Rev A call and allow the data session to go dormant. 2

i. Wait 60 seconds from the time the data session goes dormant and send an HRPD page 3

to the AT (i.e. Issue a ping request to the AT from the network). 4

j. Verify the AT responds to the HRPD page request successfully. 5

k. Repeat steps b through j making the following changes to the ConfigurationRequest 6

message sent in step f: 7

Field Value


SlotCycle1 0x6

SlotCycle2 0x6

SlotCycle3 0x9

WakeCount1 1

WakeCount2 2

l. Set up an AT originated HRPD Rev A call. Send a ping from the AT to the AN. 8

m. Wait for the AT to go dormant. After the AT goes dormant, during T12 measure the 9

interval of time that the AT wakes up and looks for pages. Verify this time interval is 10

every control channel cycle (426.66 ms), since SlotCycle1= 0x6. 11

n. Allow the AT to remain dormant. Wait for T23 to expire. Then measure the interval of 12

time that the AT wakes up and looks for pages. Verify this time interval is every 12 13

control channel cycles (5120 ms), since SlotCycle3= 0x9. 14

o. Send an HRPD page to the AT (ie. Issue a ping request from the AN to the AT). Verify 15

that the AT responds to the HRPD page request successfully. 16


The AT shall comply with steps g, j, m, n, and o. 18

18.65 Channel Hashing during Enhanced Idle State Protocol 19


This test verifies the mobile station hashes to the correct channels based on 21 AccessHashingClassMask and AccessHashingChannelMask. 22


(see [24]) 24


3GPP2 C.S0044-D v1.0

18-73



8.9.6.2.2 SectorParameters Message 3


None 5


a. Connect the AT to the AN as shown in Figure A-5. AN 1 and AN 2 are AT supported 7

CDMA Channels operating in the same band class and have same PN offset. 8

b. Ensure that the AT does not have a previously assigned UATI from the AN. 9

c. Configure the AT and each AN to support Enhanced Idle State Protocol. 10

d. Configure each AN to send a SectorParameters Message with 11

AccessHashingMaskLength=0xf and to negotiate a value of 0x0 for 12

AccessHashingClassMask attribute during session negotiation. 13

e. Configure both AN 1 and AN 2 to include in the SectorParameters Message a Channel 14

List with the channel information for AN 1 with AccessHashingChannelMask=0xffff. 15

f. Configure both AN 1 and AN 2 to include in the SectorParameters Message an 16

Extended Channel List with the channel information for AN 2 with 17

AccessHashingChannelMask=0xffff. 18

g. Power on the AT and set up an HRPD data call. 19

h. Allow the call to go dormant and ping the AT. 20

i. Verify the AT responds to the page successfully. 21

j. End the call and terminate the HRPD session. 22

k. Repeat steps g through j a maximum of 20 times. 23

l. Verify the mobile station hashes on AN 1 and AN 2 at least once. 24



18.66 Channel Hashing during Enhanced Idle State Protocol - Hashing to AN 2 Only 27


This test verifies the mobile station hashes to the correct channels based on 29 AccessHashingClassMask and AccessHashingChannelMask. In this test, the AT will only hash to 30 AN 2 based on settings for AccessHashingClassMask and AccessHashingChannelMask. 31


(see [24]) 33

3GPP2 C.S0044-D v1.0

18-74




8.9.6.2.2 SectorParameters Message 4


None 6


a. Connect the AT to the AN as shown in Figure A-5. AN 1 and AN 2 are AT supported 8

CDMA Channels operating in the same band class and have the same PN offset. 9

b. Ensure that the AT does not have a previously assigned UATI from the AN. 10

c. Configure the AT and each AN to support Enhanced Idle State Protocol. 11

d. Configure each AN to send a SectorParameters Message with 12

AccessHashingMaskLength=0x1 and to negotiate a value of 0x2 for 13

AccessHashingClassMask attribute during session negotiation. 14

e. Configure both AN 1 and AN 2 to include in the SectorParameters Message a Channel 15

List with the channel information for AN 1 with AccessHashingChannelMask=0x1. 16

f. Configure both AN 1 and AN 2 to include in the SectorParameters Message an 17

Extended Channel List with the channel information for AN 2 with 18

AccessHashingChannelMask=0x2. 19

g. Power on the AT and set up an HRPD data call. 20

h. Allow the call to go dormant and ping the AT. 21

i. Verify the AT responds to the page successfully. 22

j. End the call and terminate the HRPD session. 23

k. Repeat steps g through j 3 times. 24

l. Verify the mobile station hashes to only AN 2. Verify the mobile station does not hash to 25

AN 1 after the EISP has been negotiated. (The AT may initially acquire AN 1, but shall 26

not hash to AN 1 after receiving the AccessHashingClassMask and 27

AccessHashingMaskLength.) 28



18.67 QoS Signaling upon PPP resynchronization 31


This test verifies that upon PPP resynchronization the AT transmits a new RSVP RESV message 33 and that the PDSN installs the new filter based on the new RESV message 34

3GPP2 C.S0044-D v1.0

18-75


(see [24]) 2


(see [12]) 4

Chapters 2 and 3 5

(see [10]) 6


None 8





d. Configure the AN to grant the QoS request from the AT. 15



g. Ensure that the AN activates only the default RLP flow during session configuration. 19


i. Cause the AT to generate QoS requests for two forward and two reverse link flows. 21 Wait for the AN to transmit a ReservationAccept message for all the reservations. 22

j. Start data transfer and verify that all reservations are in open state and that the data is 23 being transmitted using appropriate RLP flow IDs. 24

k. Cause the PDSN to initiate a PPP resynchronization. This can be achieved for example 25 by an inter-PDSN handoff. Ensure that the PDSN provides the same IP Address as 26 received in step h. 27

l. Verify that the AT resynchronizes the PPP. 28

m. Verify that the AT transmits a RSVP RESV message with all the higher layer flows to 29 the PDSN after PPP resynchronization is complete. 30

n. Ensure that the PDSN sends a RSVP ResvConf message. 31


The AT shall comply with step l and m. 33

The PDSN should comply with step n. 34

3GPP2 C.S0044-D v1.0

18-76

18.68 AT behavior upon Rejection of Reservation Request by AN 1


The default flow in HRPD is always in active state. When the AN rejects a QoS request, the data 3 for the QoS flow should be sent through the default RLP flow on the forward and reverse link and 4 will receive best-effort treatment. 5

Under normal circumstances, the AN will accept a reservation request from the AT. However, the 6 AN may deny the reservation request for many reasons, for example if the request is invalid or if 7 the given admission control policy at the AN determines that the request cannot be fulfilled. 8 Specifying a configuration where the AN denies the QoS request is beyond the scope of the 9 document and is left to the tester. 10


(see [24]) 12


(see [12]) 14

Chapters 2 and 3 15


None. 17






e. Cause the AT to negotiate a new session with the AN. 26

f. Ensure that the AN activates only the default RLP flow during session configuration. 27

g. Cause the AT to establish a data call with the AN. 28

h. Cause the AT to generate QoS request for one forward and reverse link flow. 29

i. Cause the AN to reject GAUP AttributeUpdateRequest message for 30 ReservationKKQoSRequestFwd and ReservationKKQoSRequestRev. 31

j. Start bi-directional data transfer with parameters that match the specification of the QoS 32 request. 33

k. Verify that the data can be sent and received on the default RLP flow and receives 34 best-effort treatment. 35



The AN shall comply with step k. 38

3GPP2 C.S0044-D v1.0

18-77

18.69 AT behavior upon Receiving ProfileType set to NULL 1


When the AN accepts a QoS request but sends a QoS response with ProfileType field set to 3 NULL, the data for the QoS flow should be sent through the default RLP flow on the forward and 4 reverse link and will receive best-effort treatment. 5


(see [24]) 7


(see [12]) 9

Chapters 2 and 3 10


None 12









h. While the AT has a connection with the AN, cause the AT to generate QoS request for 25 one forward and one reverse link flow. 26

i. Cause the AN to accept the GAUP AttributeUpdateRequest message for 27 ReservationKKQoSRequestFwd and ReservationKKQoSRequestRev. 28

j. Cause the AN to transmit a ReservationKKQoSResponse with ProfileType set to 0x00 29 for both the forward and reverse link flows. 30

k. Start bi-directional data transfer with parameters that match the specification of the QoS 31 request. 32

l. Verify that the data is sent and received on the default RLP flow and receives best-33 effort treatment. 34




3GPP2 C.S0044-D v1.0

18-78

18.70 ReservationKKIdleStateFwd and ReservationKKIdleStateRev set to 0 1


The state of a reservation can change when the AT goes dormant. The change in a reservation’s 3 state is determined by the value of ReservationKKIdleStateFwd / ReservationKKIdleStateRev 4 where KK (=0xij) is the 2 digit hexadecimal ReservationLabel (0xij ≠ 0xff) that identifies the 5 reservation in use. A Reservation is bound to an RLP flow NN by setting the ReservationLabel 6 parameter of the FlowNNReservationFwd / FlowNNReservationRev attribute to the reservation’s 7 label (KK = 0xij). When the ReservationKKIdleStateFwd / ReservationKKIdleStateRev (KK = 0xij) 8 attribute is set to 0, the state of the reservation (with ReservationLabel KK = 0xij) will not change 9 upon closing or opening of the connection. In the test procedure, application refers to an 10 application that generates data for flow with ReservationLabel (KK = 0xij). Starting this application 11 will cause the AT to transmit forward and reverse QoS ReservationOn request(s) for 12 ReservationLabel (KK = 0xij) if the reservation is in closed state. Any higher layer flow with 13 ReservationLabel 0xij (0xij ≠ 0xff) that generates forward and reverse reservation requests can be 14 used. This test verifies that the reservation state does not change when ReservationKKIdleState 15 is set to 0 and that the initial state of a reservation is closed (0xij ≠ 0xff). The test procedure 16 transitions the state of the (connection state, reservation state) pair from (close, close), to (open, 17 close), to (open, open), to (close, open) and finally to (open, open) again. 18


(see [24]) 20


(see [12]) 22

Chapters 2 and 3 23


None 25




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 29 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 30 service network, Physical layer subtype 2, Enhanced FTCMAC, and Subtype 3 RTC 31 MAC. 32

d. Configure the AN to grant the QoS request from the AT and to set 33 ReservationKKIdleStateFwd and ReservationKKIdleStateRev to 0x0 for 34 ReservationLabel KK (= 0xij ≠ 0xff). 35



g. Cause the AT to establish a data call with the AN by transmitting data for higher layer 39 flow with ReservationLabel 0xff (Note. This will open the connection by transmitting 40 data on the default flow). 41

h. While the AT has a connection with the AN, start the application that generates data for 42 higher layer flow with ReservationLabel KK (= 0xij ≠ 0xff). 43

3GPP2 C.S0044-D v1.0

18-79

i. Verify that the reservation is in closed state and the AT transmits forward and reverse 1 ReservationOn request for the higher layer flows with ReservationLabel KK (= 0xij ≠ 2 0xff). Wait for the AN to transmit ReservationAccept message for all the reservations. 3

j. Once the data transfer starts from the application, ensure that the reservation is in open 4 state and that the data is being transmitted using appropriate (non-default) RLP flow ID. 5

k. Cause the AT to loose the connection with the AN. Ensure that the AT does not 6 transmit ReservationOff request for the ReservationLabel KK (= 0xij ≠ 0xff) to the AN. 7

l. Cause the AT to reestablish a data call with the AN. 8

m. Start bi-directional data transfer for the higher layer flow with ReservationLabel KK (= 9 0xij ≠ 0xff). 10

n. Verify that the reservation is in open state and that during or after reestablishing the 11 data call, the AT does not need to transmit the ReservationOn request for 12 ReservationLabel KK (= 0xij ≠ 0xff) and that the AN does not transmit 13 FwdReservationOn and/or RevReservationOn message(s). 14

o. Verify that the AN and the AT transmit the data through RLP with appropriate (non-15 default) flow id. 16

p. Stop the application and cause the AT to transmit a ReservationOff message for the 17 forward and/or reverse higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff). 18

q. Allow the AT to go dormant. 19

r. Cause the AT to establish a data call with the AN by transmitting data for higher layer 20 flow with ReservationLabel 0xff. 21

s. Start the application. 22

t. Verify that the reservation is in closed state and the AT transmits the ReservationOn 23 request for opening the reservation for forward and reverse link flow with 24 ReservationLabel KK (= 0xij ≠ 0xff). Note, the AT may send a combined ReservationOn 25 request for the forward link and reverse link reservations. Wait for the AN to accept the 26 reservation(s). 27

u. Verify that the AN and the AT transmit the data through RLP with appropriate (non-28 default) flow id 29


The AT shall comply with step i, n, o, t and u. 31

The AN shall comply with steps n, o and u. 32

18.71 ReservationKKIdleState set to 1 33


The state of a reservation can change when the AT goes dormant. The change in a reservation’s 35 state is determined by the value of ReservationKKIdleStateFwd / ReservationKKIdleStateRev 36 where KK (=0xij) is the 2 digit hexadecimal ReservationLabel (0xij ≠ 0xff) that identifies the 37 reservation in use. A Reservation is bound to an RLP flow NN by setting the ReservationLabel 38 parameter of the FlowNNReservationFwd / FlowNNReservationRev attribute to the reservation’s 39 label (KK = 0xij). When the ReservationKKIdleStateFwd / ReservationKKIdleStateRev (KK = 0xij) 40 attribute is set to 0x1, the reservation will close when the HRPD connection is closed. This test 41 verifies the change in a reservation’s state when ReservationKKIdleState is set to 1. In the test 42 procedure, application refers to an application that generates data for higher layer flow with 43 ReservationLabel KK (= 0xij ≠ 0xff). Starting this application will cause the AT to transmit forward 44 and reverse QoS reservation requests for ReservationLabel KK (= 0xij ≠ 0xff) if the reservation is 45

3GPP2 C.S0044-D v1.0

18-80

in closed state. Any ReservationLabel KK other that 0xff that generates forward and reverse 1 reservation requests can be used. 2


(see [24]) 4


(see [12]) 6

Chapters 2 and 3 7


None 9








g. Cause the AT to establish a data call with the AN by transmitting data for higher layer 23 flow with ReservationLabel 0xff. 24

h. Start the application and verify that the AT transmits reservation requests for forward 25 and reverse link higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff). Wait for the 26 AN to transmit ReservationAccept message for all the reservations. 27

i. Start the application and ensure that the reservation is in open state and that the data is 28 being transmitted using appropriate (non-default) RLP flow ID. 29

j. Cause the AT to loose the connection with the AN. Ensure that the AT does not 30 transmit ReservationOff requests (forward or reverse) for ReservationLabel KK (= 0xij ≠ 31 0xff) to the AN. 32

k. Cause the AT to reestablish a data call with the AN. 33

l. Ensure that the application generates data for the higher layer flow with 34 ReservationLabel KK (= 0xij ≠ 0xff). 35

m. Verify that the reservation is in closed state and the AT transmits the ReservationOn 36 request for the higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff) for forward 37 and reverse link flows. Wait for the AN to accept the reservation. 38

n. Verify that the AN and the AT transmit the data through RLP with appropriate (non-39 default) flow id. 40


The AT shall comply with steps h, m and n. 42

3GPP2 C.S0044-D v1.0

18-81

The AN shall comply with step n. 1



The state of a reservation can change when the AT goes dormant. The change in a reservation’s 4 state is determined by the value of ReservationKKIdleStateFwd / ReservationKKIdleStateRev 5 where KK (=0xij) is the 2 digit hexadecimal ReservationLabel (0xij ≠ 0xff) that identifies the 6 reservation in use. A Reservation is bound to an RLP flow NN by setting the ReservationLabel 7 parameter of the FlowNNReservationFwd / FlowNNReservationRev attribute to the reservation’s 8 label (KK = 0xij). When the ReservationKKIdleStateFwd / ReservationKKIdleStateRev (KK = 0xij) 9 attribute is set to 0x2, the reservation will open when the HRPD connection is opened and close 10 when the HRPD connection is closed. This test verifies the change in state of the reservation 11 (with ReservationLabel KK = 0xij ≠ 0xff) with opening and closing of connection when 12 ReservationKKIdleState is set to 0x2. In the test procedure, application refers to an application 13 that generates data for higher layer flow with ReservationLabel KK (= 0xij ≠ 0xff). Starting this 14 application will cause the AT to transmit forward and reverse QoS ReservationOn requests for 15 ReservationLabel KK (= 0xij ≠ 0xff) if the reservation is in closed state. Any ReservationLabel KK 16 other that 0xff that requires forward and reverse reservations can be used 17


(see [24]) 19


(see [12]) 21

Chapters 2 and 3 22


None 24




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 28 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 29 service network, Physical layer subtype 2 Enhanced FTCMAC and Subtype 3 RTC 30 MAC. 31

d. Configure the AN to grant the QoS request from the AT and to set 32 ReservationKKIdleStateFwd and ReservationKKIdleStateRev to 0x0 for 33 ReservationLabel KK (= 0xij ≠ 0xff) and FlowNNDataOverSignalingAllowedRev and 34 FlowNNDataOverSignalingAllowedFwd set to 1 for the RLP flow NN to which 35 ReservationLabel KK (= 0xij ≠ 0xff) will be bound. 36

e. Configure the AN to activate MaxActivatedRLPFlowsFwd and 37 MaxActivatedRLPFlowsRev during session configuration. 38



h. Cause the AT to establish a data call with the AN. 42

3GPP2 C.S0044-D v1.0

18-82

i. Start the application and ensure that the AT transmits reservation requests for forward 1 and reverse link higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff). Wait for the 2 AN to transmit ReservationAccept message for all the reservations. 3

j. Start data transfer and verify that the reservation is in open state and that the data is 4 being transmitted using appropriate (non-default) RLP flow ID. 5

k. Stop the data transfer and allow the AT to become dormant and ensure that the AT 6 does not transmit ReservationOffRequest messages for the ReservationLabel KK (= 7 0xij ≠ 0xff). 8

l. Cause the AT to generate a DataOverSignaling message for the higher layer flow with 9 ReservationLabel KK (= 0xij ≠ 0xff). Ensure that the AT does not open the connection 10 with the AN. 11

m. Ensure that the reservation is in open state and the AT does not need to transmit the 12 ReservationOn request for the reservation and that the AN does not transmit 13 FwdReservationOn and/or RevReservationOn message(s). 14

n. Ensure that the AT transmits the DataOverSignaling message. 15

o. Transmit a DataOverSignaling message from the AN to the AT for the higher layer flow 16 with ReservationLabel KK (= 0xij ≠ 0xff). Ensure that the AT does not open the 17 connection with the AN. 18

p. Ensure that the reservation is in open state and the AT does not need to transmit the 19 ReservationOn request for the reservation and that the AN does not transmit 20 FwdReservationOn and/or RevReservationOn message(s). 21

q. Ensure that the AN transmits the DataOverSignaling message. 22

r. Repeat steps d to h with the exception that in step d, configure the AN to set 23 ReservationKKIdleStateFwd and ReservationKKIdleStateRev to 0x2. 24

s. Cause the AT to establish a data call with the AN by transmitting data for higher layer 25 flow with ReservationLabel 0xff. 26

t. Generate data from the application. 27

u. Verify that the AT does not need to transmit the ReservationOn request for the 28 reservation and that the AN does not transmit FwdReservationOn and/or 29 RevReservationOn message(s) and that the AN and the AT transmit application’s data 30 through appropriate (non-default) RLP. 31

v. Force the AT to become idle. 32

w. Cause the AT to generate a DataOverSignaling message for the higher layer flow with 33 ReservationLabel KK (= 0xij ≠ 0xff). 34

x. Verify that the AT does not transmit DataOverSignaling message. 35

y. Cause the AN to generate a DataOverSignaling message for the higher layer flow with 36 ReservationLabel KK (= 0xij ≠ 0xff). 37

z. Verify that the AN does not transmit DataOverSignaling message. 38


The AT shall comply with step u and x. 40

The AN shall comply with steps u and z. 41

3GPP2 C.S0044-D v1.0

18-83

18.73 DRC Supervision Failure 1


The AT performs DRC supervision in order to ensure call quality. This test verifies that the AT 3 behavior for DRC supervision. Specifically, it verifies that if the AT transmits NULL DRC for 4 DRCSupervisionTimer*10 + 240 ms. continuously without receiving any packets (either FTC or 5 CC MAC packets) from the AN then it shall disable the Reverse Traffic Channel. Subsequently, 6 the AT starts a timer for TFTCMPRestartTx (5.12 seconds). If during this period, a packet (either FTC or 7 CC MAC packets) is received from the AN or if the AT transmits a non-NULL tentative DRC, then 8 the AT disables the timer. Otherwise it declares a DRC supervision failure and tears down the 9 connection. 10


(see [24]) 12

Section 10.7.6.1.10.1 13

(see [12]) 14

Chapters 2 and 3 15


None 17




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 21 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 22 service network, Physical layer subtype 2, Enhanced CCMAC Enhanced FTCMAC and 23 Subtype 3 RTC MAC. 24

d. Configure the AN to use a transmission rate of 38.4 kbps for the control channel. 25

e. During SCP or using GAUP, negotiate the value of MultiUserPacketsEnabled to be 26 0x00. This will disallow the AN from transmitting data to the AT, when the AT is 27 transmitting NULL rate DRC. 28

f. Cause the AT to establish a connection with the AN. 29

g. Start bi-directional data transfer and ensure that data is going through continuously in 30 both directions. 31

h. Reduce Îor

such that the AT starts transmitting NULL rate tentative DRC and is unable 32

to receive the control channel. 33

i. Verify that the AT disables the Reverse Traffic Channel after transmitting null rate 34 tentative DRC for DRCSupervisionTimer*10 + 240 ms period continuously. Ensure that 35 the AN does not transmit any packets on the forward traffic channel to the AT and the 36 AT does not receive any control channel packet during this time interval. 37

j. Within TFTCMPRestartTx (5.12 seconds) of disabling reverse traffic channel transmitter in the 38 last step, increase Î

or such that the AT start transmitting a non-null tentative DRC to the 39

AN. Ensure that the AN does not transmit any packets on the forward traffic channel to 40 the AT and the AT does not receive any control channel packet before AT has 41 transmitted non-null DRC for NFTCMPRestartTx slots continuously. 42

3GPP2 C.S0044-D v1.0

18-84

k. Verify that the AT enables the reverse traffic channel and bi-directional transfer occurs 1 after AT has transmitted non-null DRC for NFTCMPRestartTx slots continuously. 2

l. Reduce Îor

such that the AT starts transmitting NULL rate tentative DRC’s and is unable 3


m. Verify that the AT returns a DRC supervision failure indication and tears down the 5 connection at the expiration of TFTCMPRestartTx. Note, the AT will transmit a null rate 6 tentative DRC for a period of DRCSupervisionTimer*10 + 240 ms before starting the 7 TFTCMPRestartTx timer. 8


The AT shall comply with steps i, k, m. 10


18.74 Soft Handoff during DRC Supervision Timeout State 12


This test verifies the soft handoff during DRC supervision timeout state. 14


(see [24]) 16

Section 10.7.6.1.10.1 17

(see [12]) 18

Chapters 2 and 3 19


None 21



b. Cause the AT to acquire the AN 1. 24

c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 25 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 26 service network, Physical layer subtype 2, Enhanced CCMAC, Enhanced FTCMAC and 27 Subtype 3 RTC MAC. 28

d. During SCP or using GAUP, negotiate the value of MultiUserPacketsEnabled to be 29 0x00. This will disallow the AN from transmitting data to the AT, when the AT is 30 transmitting NULL rate DRC. 31

e. Cause the AT to establish a connection with the AN 1. 32

f. Start bi-directional data transfer and ensure that data is going through continuously in 33 both directions. 34

g. Reduce Îor

for the pilot from AN 1 such that the AT starts transmitting NULL rate 35

tentative DRC and is unable to receive the control channel from AN 1. 36

h. Ensure that the AT disables the Reverse Traffic Channel after transmitting null rate 37 tentative DRC for DRCSupervisionTimer*10 + 240 ms period continuously. 38

3GPP2 C.S0044-D v1.0

18-85

i. Within TFTCMPRestartTx (5.12 seconds) of disabling reverse traffic channel transmitter in the 1 last step, increase the Ior of sector 1 of AN 2 or increase Î

or such that the AT transmits 2

non-null tentative DRC for NFTCMPRestartTx slots continuously to AN 2. 3

j. Verify that the AT successfully acquires AN 2, enables the reverse traffic channel and 4 that the bi-directional transfer resumes from the AT and AN 2. 5


The AT shall comply with step j 7

The AN shall comply with step j. 8

18.75 DRC Supervision with MultiUserPacketsEnabled 9


This test verifies the AN and AT behavior when the value of MultiUserPacketsEnabled is set to 11 0x01. This test requires that the AN transmit data to an AT even when the AT transmits a NULL 12 DRC. This will happen for Flows that require QoS, such as a VOIP flow if the 13 MultiUserPacketsEnabled is set 0x01. It is assumed that such a flow is used in this test. 14


(see [24]) 16

Section 10.7.6.1.10.1 and 17

Section 10.6.7.1 18

(see [12]) 19

Chapters 2 and 3 20


None 22




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 26 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 27 service network, Physical layer subtype 2 Enhanced FTCMAC and Subtype 3 RTC 28 MAC. 29

d. During SCP or using GAUP, negotiate the value of DRCSupervisionTimer to 0x00 and 30 the value of MultiUserPacketsEnabled to be 0x01. This will allow the AN to transmit 31 data to the AT, when the AT is transmitting NULL rate DRC. 32

e. Cause the AT to establish a connection with the AN. 33

f. Start bi-directional data transfer and ensure that data is going through continuously in 34 both directions. 35

g. Reduce Îor

such that the AT starts transmitting NULL rate tentative DRC. 36

h. Verify that the AN continues to transmit data to the AT at DRC 1 rate. 37

3GPP2 C.S0044-D v1.0

18-86

i. Verify that the AT does not disable the Reverse Traffic Channel after transmitting null 1 rate tentative DRC for DRCSupervisionTimer*10 + 240 ms period continuously if it 2 receives either a forward traffic channel or control channel packet. 3

j. If the AT does not receive any forward traffic channel or control channel packet in the 4 last step, the repeat the test by increasing the Î

or. 5


The AT shall comply with step i 7


18.76 DRCTranslationOffset Verification 9


This test verifies DRCTranslationOffset attribute negotiation between the AT and the AN. 11


(see [24]) 13

Section 10.7.6.1.10.1 14


None 16

18.76.4 Method of measurement. 17



c. Configure the AT to negotiate the use of Physical layer subtype 2 and Enhanced 20 FTCMAC. 21

d. During SCP or using GAUP, negotiate the value of DRCTranslationOffset attribute with 22 a value 0 for DRCOffsetN for all N. 23


f. Cause the AT to request a tentative DRC value of 0x8. This can either be done by fixing 25 the DRC requested by the AT or by changing the Î

or. 26

g. Ensure that the AT is transmitting a DRC value 0x08 most of the time. 27

h. GAUP the value of DRCTranslationOffset attribute with a value of 5 for DRCOffset8 and 28 0 for all other DRCOffsetN. 29

i. Start bi-directional data transfer and ensure that data is going through continuously in 30 both directions. 31

j. Verify that the AT requests a DRC of 3, when its tentative DRC is 0x8 32


The AT shall comply with step j. 34

3GPP2 C.S0044-D v1.0

18-87

18.77 DSC and DRC compliance during Soft handoff 1


The purpose of this test is to verify that the AT follows the DSC channel and DRC channel 3 timeline in transmitting the DSC and DRC values while performing a soft handoff with DRCGating 4 disabled. Further, it is tested that the AN does not skip transmission of any octets from the RLP 5 sequence space during soft handoff. In the test procedure, both AN 1 and AN 2 support HRPD 6 Rev A and are connected to the same RNC. It is intended that this test be executed with the 7 default hybrid mode operation, if supported by the AT. 8


(see [24]) 10

Section 10.7.6.1.5 and 11

Section 10.7.6.1.8.1 12

(see [12]) 13

Chapters 2 and 3 14


None 16



1. AN 1 and AN 2 support HRPD Rev A and have same frequency assignments. 19

2. AN 1 and AN 2 are connected to the same RNC, but are located at separate 20 base stations. 21



d. During SCP negotiate the value of DSCLength to 8 (64 slots), SoftHandoffDelay to 8 27 (64 slots) and DRCGating to 0x00 (continuous transmission). 28


f. Initiate a forward data transfer using the maximum supported data rate to the AT (i.e. 30 use the FTP “get” command from the AT). Choose a file large enough to sustain data 31 for entire test duration. 32

g. Force the AT to handoff from AN 1 to AN 2. 33

h. Force the AT to handoff from AN 2 to AN 1. 34

i. Verify that the AT does not change its sector cover such that there is overlap in 35 transmission of packets from 2 sectors. 36

j. Verify that after a handoff occurs from AN 1 to AN 2, the RLP sequence number of the 37 first byte transmitted by AN 2 is less than or equal to the 1+ RLP sequence of the last 38 byte transmitted by the AN 1. Similarly, verify contiguous RLP sequence numbers for 39 handoff from AN 2 to AN 1. 40

3GPP2 C.S0044-D v1.0

18-88

k. Verify that the call is maintained across the handoff and that the file transfer is 1 completed. 2


The AT shall comply with steps i and k. 4

The AN shall comply with the steps j and k. 5

18.78 DRC Compliance During Softer Handoff 6


The purpose of this test is to verify that the AN and the AT behavior during softer handoff. It is 8 verified that the AT transmits the correct value of DRC and the AN transmits the data correctly. In 9 the test procedure, both AN 1 and AN 2 support HRPD Rev A and are adjacent sectors located at 10 the same base station. It is intended that this test be executed with the default hybrid mode 11 operation, if supported by the AT. 12


(see [24]) 14

Section 10.7.6.1.10.1 15

(see [12]) 16

Chapters 2 and 3 17


None 19



1. AN 1 and AN 2 support HRPD Rev A and have the same frequency 22 assignments. 23

2. AN 1 and AN 2 are connected to the same RNC, and are located at the same 24 base stations but have different PN offsets. 25



d. During SCP negotiate the value of DRCLength to 8 slots, SofterHandoffDelay to 8 slots 31 and DRCGating to 0x00 (continuous transmission). 32


f. Initiate a forward data transfer using the maximum supported data rate to the AT (i.e. 34 use the FTP “get” command from the AT). Choose a file large enough to sustain data 35 for entire test duration. 36

g. Force the AT to handoff from AN 1 to AN 2. 37

h. Force the AT to handoff from AN 2 to AN 1. 38

3GPP2 C.S0044-D v1.0

18-89

i. Verify that the AT does not change its sector cover such that there is overlap in 1 transmission of packets from the 2 sectors. 2

j. Verify that after a handoff occurs from AN 1 to AN 2, the AN transmits contiguous RLP 3 sequence, i.e. the RLP sequence number of the first byte transmitted by AN 2 is one 4 more than the RLP sequence of the last byte transmitted by the AN 1. Similarly, verify 5 contiguous RLP sequence numbers for handoff from AN 2 to AN 1. 6

k. Verify that the call is maintained across handoff and that the file transfer is completed. 7


The AT shall comply with steps i and k. 9

The AN shall comply with steps j and k. 10

18.79 MUP and Non Canonical SUP decoding by AT 11


The purpose of this test is to verify that the AT can decode multi-user packets (MUP) and non-13 canonical single user packet (SUP) that the AN transmits. 14


(see [24]) 16

Section 10.7.6.1.5 17

(see [12]) 18

Chapters 2 and 3 19


None 21




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 25 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 26 service network, Physical layer subtype 2, Enhanced CCMAC, Enhanced FTCMAC and 27 Subtype 3 RTC MAC. 28

d. During session configuration or using GAUP negotiate the value of 29 ShortPacketsEnabledThresh to 0x03, and MultiUserPacketsEnabled to 0x00. 30


f. Vary the channel conditions such that the AT transmits a close to peak rate DRC value 32 of 0xe. 33

g. Instruct the AN to GAUP DRCTranslationOffset attribute with parameter DRCOffsetE 34 set to 0xa, DRCOffsetd set to 0xa, DRCOffsetc set to 0xa, DRCOffsetb set to 0xa, 35 DRCOffseta set to 0xa and DRCOffseti for all other DRC i, set to 0. 36

h. Ensure that the AT starts transmitting DRC values in the range 0x0 to 0x4. 37

i. Cause the AN to transmit one or more single user packets to the AT in any format other 38 than the canonical format. The transmission packet format used by the AN is 39

3GPP2 C.S0044-D v1.0

18-90

implementation dependent. Canonical format for a DRC is the largest packet size. If the 1 payload of a transmission can fit in a smaller size packet allowed for the DRC, the AN 2 may transmit a smaller (non-canonical) format. For example, if a ping packet with 10 3 bytes of payload is transmitted to the AT, it will be transmitted using a (512, 2, 128) 4 format if the transmitted DRC is 0x4, or (512, 4, 256) format if the transmitted DRC is 5 0x3. This assumes that the ping packet will not fit in a 256 bit packet but will fit in a 512 6 bit physical layer packet. 7

j. Verify that the AT successfully decodes all single user packets transmitted by the AN. 8

k. Repeat step i for all DRC in the range 0x0 to 0x4. Note the DRC transmitted by the AT 9 can be varied either by varying Î

or or by increasing the DRCOffsetE parameter of the 10

DRCTranslationOffset by using GAUP. 11

l. Using GAUP negotiate the value of ShortPacketsEnabledThresh to 0x00, and 12 MultiUserPacketsEnabled to 0x01. 13

m. Cause the AN to transmit one or more multi user packets allowed for the transmitted 14 DRC. 15

n. Repeat step m for all DRC in the range 0x0 to 0x4. Note the DRC transmitted by the AT 16 can be varied either by varying Ior or by increasing the DRCOffsetE parameter of the 17 DRCTranslationOffset by using GAUP. 18

o. Verify that the AT successfully decodes all multi user packets transmitted by the AN. 19


The AT shall comply with steps j and o. 21

18.80 Enhanced Control Channel Short MAC Packet 22


The purpose of this test is to verify that the AT successfully decodes various short packet formats 24 with different negotiated values of CCShortPacketMACIndex. This test requires the AN to 25 transmit CC short MAC packets. Since the size of the ACAck and Page packet is smaller than 26 512 bits, it is likely although not necessary that the AN will use CC short MAC packets for 27 transmitting these messages. 28


(see [24]) 30

Section 10.3.6.1.4.1.1 31

(see [12]) 32

Chapters 2 and 3 33


None 35




c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 39 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to the 40

3GPP2 C.S0044-D v1.0

18-91

service network, Physical layer subtype 2, Enhanced CCMAC, Enhanced ACMAC, 1 Enhanced FTCMAC, Enhanced Idle State Protocol and Subtype 3 RTC MAC. 2

d. Start a new session and using SCP negotiate the value of CCShortPacketsMACIndex 3 attribute to 0x00. 4

e. Using SCP or GAUP negotiate the value of SlottedMode attribute as follows: 5

Field Value


SlotCycle1 0x5

SlotCycle2 0x5

SlotCycle3 0x5



f. After session configuration is complete, instruct the AT to open a connection with the 6 AN. 7

g. Verify that in response to the AT’s AccessProbe message, the AN transmits an ACAck 8 message in a asynchronous CC capsule using one of the following Transmission 9 Formats16 of [128, 4, 1024], [256, 4, 1024], [512, 4, 1024] with preamble MAC Index 10 71. If the message is transmitted using the sub-synchronous or synchronous capsule, 11 repeat steps f and g. 12

h. Verify that the AT receives the ACAck message and stops transmitting the 13 AccessProbe. 14

i. Allow the connection to become dormant. 15

j. Instruct the AN to transmit a Page to the AT. 16

k. Verify that the AN transmits the Page message in a sub-synchronous CC capsule using 17 one of the following Transmission Formats of [128, 4, 1024], [256, 4, 1024], [512, 4, 18 1024] with a preamble MAC Index of 71. If the message is transmitted using the 19 synchronous capsule, repeat steps i, j and k. 20

l. Verify that the AT receives the Page message and establishes a connection with the 21 AN. 22

m. Instruct the AT or the AN to close the session. 23

n. Start a new session and using SCP negotiate any valid value of 24 CCShortPacketsMACIndex other than 0x00. 25

o. Using SCP or GAUP negotiate the value of SlottedMode attribute as follows: 26

16 Transmission Format is defined as [ Payload Size (bits), Nominal transmit duration (slots), Preamble

Length (chips))

3GPP2 C.S0044-D v1.0

18-92

Field Value


SlotCycle1 0x5

SlotCycle2 0x5

SlotCycle3 0x5



p. After session configuration is complete, instruct the AT to open a connection with the 1 AN. 2

q. Verify that in response to the AT’s AccessProbe message, the AN transmits an ACAck 3 message in a asynchronous CC capsule using one of the following Transmission 4 Formats of [128, 4, 1024], [256, 4, 1024], [512, 4, 1024] with preamble MAC Index 5 negotiated in step n or 71. If the message is transmitted using the sub-synchronous or 6 synchronous capsule, repeat steps o and p. 7

r. Verify that the AT receives the ACAck message and stops transmitting the 8 AccessProbe. 9

s. Allow the connection to become dormant. 10

t. Instruct the AN to transmit a Page to the AT. 11

u. Verify that the AN transmits the Page message in a sub-synchronous CC capsule using 12 one of the following Transmission Formats of [128, 4, 1024], [256, 4, 1024], [512, 4, 13 1024] with a preamble MAC Index negotiated in step n or 71. If the message is 14 transmitted using the synchronous capsule, repeat steps i, j and k. 15

v. Verify that the AT receives the Page message and establishes a connection with the 16 AN 17


The AT shall comply with steps h, l, r, and v. 19

The AN shall comply with steps g, k, q and u. 20

18.81 Enhanced Access Channel Probe Transmission 21


The purpose of this test is to verify that the AN and the AT successfully negotiate the 23 PreambleLengthSlots, AccessOffset, SectorMaxRate and CapsuleLengthMax attributes of the 24 EACMAC protocol and that using these parameters the AT transmits the access probe at 25 appropriate time and rate and that the AN successfully receives the probe. This test uses Data 26 Over Signaling protocol to generate payload for the Access Channel Capsule. 27


(see [24]) 29

3GPP2 C.S0044-D v1.0

18-93

Section 10.5.6.1.4.1.2 (Probe Transmission) 1

Section 10.5.6.2.6 (Access Parameters message) 2

(see [12]) 3

Chapters 2 and 3 4


None 6





d. During session configuration or using GAUP, negotiate a value of 0x00 (9.6 kbps) for 14 TerminalAccessRateMax attribute of EACMAC protocol. 15

e. Configure the AN to transmit CapsuleLengthMax value of 0x7, PreambleLenghtSlots 16 value of ‘0’ (4 slots), AccessOffset value of ‘03’, and SectorAccessMaxRate value of 17 ‘00’ (9.6 kbps) in the AccessParameters message. 18

f. During Session Configuration, set the ProtocolIdentifier field of the 19 FlowNNHigherLayerProtocolRev (NN = KK) and FlowNNHigherLayerProtocolFwd (NN 20 = KK) to HDLC framing. 21

g. During Session Configuration, set the Active parameter of FlowNNIdentificationFwd 22 (NN = KK) attribute and FlowNNIdentificationRev (NN = KK) attribute to 0x01. 23

h. Set the ReservationLabel for FlowNNReservationRev (NN = KK) and 24 FlowNNReservationFwd (NN = KK) to High Priority Signaling. Set 25 FlowNNDataOverSignalingAllowedRev (NN = KK) and 26 FlowNNDataOverSignalingAllowedFwd (NN = KK) to 0x01. Configure the AN to grant 27 the QoS request from the AT and to set ReservationKKIdleStateFwd and 28 ReservationKKIdleStateRev to 0x0 for ReservationLabel kk associated with High 29 Priority Signaling. 30

i. If the AT does not have an established PPP session, cause the AT to establish a PPP 31 session. 32

j. Instruct the AT to send a ReservationOn message for ReservationLabel kk associated 33 with High Priority Signaling data that is to be carried using DataOverSignaling message 34 to the AN and ensure that the AN responds with a ReservationAccept message. Instruct 35 the AT to send a ReservationOn message for ReservationLabel kk associated with High 36 Priority Signaling data that is to be carried using DataOverSignaling message from the 37 AN to the AT and ensure that the AN responds with a ReservationAccept message. 38

k. Allow the HRPD connection to become idle. 39

l. Transmit a ping packet from the AT directed to the AN using the Data Over Signaling 40 Protocol and setting the AckRequired field of the DataOverSignaling message to ‘1’. 41 The size of the ping packet should be such that the Access Channel payload is 42 between 489 and 1000 bits. 43

m. Verify that the AT transmits a DataOverSignaling Message at 9.6 kbps Access Channel 44 Rate. Verify that the AT started the transmission of the AccessProbe at time T such that 45

3GPP2 C.S0044-D v1.0

18-94

(T-AccessOffset) mod AccessCycleDuration = 0, 1

where T is CDMA System Time in slots and AccessCycleDuration is defined in the 2 AccessParameters message transmitted by the AN. Verify that the AT transmits the 3 Preamble for PreambleLengthSlots. 4

n. Verify that the AN receives the DataOverSignaling Message. This can be verified by the 5 transmission of DataOverSignalingAck by the AN. 6

o. Repeat steps c to l, with the exception that TerminalAccessRateMax attribute value is 7 negotiated to 0x02 (38.4 kbps) and the AN is configured to transmit AccessParameters 8 message with an AccessOffset value of ‘02’ (8 slots). 9

p. Verify that the AT transmits the DataOverSignaling Message at 38.4 kbps over the 10 Access Channel. Verify that the AT started the transmission of the AccessProbe at time 11 T such that 12



q. Verify that the AN receives the DataOverSignaling Message. This can be verified by the 17 transmission of DataOverSignalingAck by the AN. 18

r. Repeat steps c to l with the exception that the AN transmits the AccessParameters 19 message with PreambleLenghtSlots value of ‘1’ (16 slots), AccessOffset value of ‘01’ (4 20 slots) and SectorAccessMaxRate value of ‘10’ (38.4 kbps). 21

s. Verify that the AT transmits the DataOverSignaling Message at 38.4 kbps over the 22 Access Channel. Verify that the AT started the transmission of the AccessProbe at time 23 T such that 24



t. Verify that the AN receives the DataOverSignaling Message. This can be verified by the 29 transmission of DataOverSignalingAck by the AN. 30

u. Transmit a ping packet from the AT directed to the AN using the Data Over Signaling 31 Protocol and setting the AckRequired field of the DataOverSignaling message to ‘1’. 32 The size of the ping packet should be such that the Access Channel payload is 33 between 232 and 489 bits. 34

v. Verify that the AT transmits a DataOverSignaling Message at 19.2 kbps over the 35 Access Channel. 36

w. Verify that the AN receives the DataOverSignaling Message. This can be verified by the 37 transmission of DataOverSignalingAck by the AN. 38


The AT shall comply with steps m, p, s and v. 40

The AN shall comply with steps n, q, t and w. 41

3GPP2 C.S0044-D v1.0

18-95

18.82 RTC Interlace re-ordering with Subtype 3 RTCMAC 1


When using Subtype 3 RTCMAC protocol, RTCMAC packets can arrive out of order at the AN. 3 This can happen due to early termination of sub-packets on the reverse link interlaces. 4


(see [24]) 6

Section 10.11 7

(see [12]) 8

Chapters 2 and 3 9


None 11


a. Connect the AT to AN Figure A-5. 13


c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 15 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to 16 the service network, Physical layer subtype 2, Enhanced FTCMAC and Subtype 3 17 RTC MAC. 18

d. During session configuration or using GAUP, instruct the AN to negotiate a value of 19 AbortTimer and FlushTimer parameters of the FlowNNTimersRev attribute to 20 0x0001 to 0x0005 for the best effort RLP flow. Set both AbortTimer and FlushTimer 21 to the same value. 22

e. After session configuration is complete, instruct the AT to open a connection with 23 the AN. 24

f. Using best effort RLP flow, transmit N (>= 10) ping packets with a payload between 25 400 to 600 bytes from the AT to the AN. 26

g. Verify that the AT successfully receives at least 80% of the response to the ping 27 packet transmissions from the AN. 28

h. Close the session. 29

i. Start a new session. During session configuration or using GAUP, instruct the AN to 30 negotiate the PermittedPayloadPS_k parameter of the PermittedPayload attribute 31 to be set to 0x1 for all PS {0, 12288} and all k {1, 2, 3}. 32

j. Trigger N (>= 10) RouteUpdate messages from the AT to the AN. RouteUpdate 33 messages can be triggered by changing the pilot strengths. Note, the signaling 34 messages must be transmitted while the AT has an open connection with the AN. 35

k. Verify that the AT receives a TrafficChannelAssignment message in response to at 36 least 80% of the RouteUpdate messages transmitted by the AT. 37


The AT should comply with steps g and k. 39

The AN should comply with steps g and k. 40

3GPP2 C.S0044-D v1.0

18-96

18.83 Configuration of non-default attributes for Subtype 3 RTCMAC 1


The purpose of this test is to verify that the AT and AN can negotiate non-default Sub-type 3 3 RTCMAC parameters. 4


(see [24]) 6

Section 10.11 7

(see [12]) 8

Chapters 2 and 3 9


None 11


a. Connect the AT to AN Figure A-5. 13


c. Configure the AT to negotiate the use of Multi-Flow Packet Application or Enhanced 15 Multi-Flow Packet Application or Multi-Link Multi-Flow Packet Application bound to 16 the service network, Physical layer subtype 2, Enhanced FTCMAC and Subtype 3 17 RTC MAC. 18

d. During session configuration or using GAUP, instruct the AN to negotiate the 19 following attributes for Subtype 3 RTC MAC. The values specified in the table are 20 recommended, but any other permissible value can be used. Ensure that the AN is 21 configured to negotiate at least one attribute to a non default value. 22

Simple Attributes 23

3GPP2 C.S0044-D v1.0

18-97

Attribute Value

ARQMode 0x00

FRABFilterTC 0x02

FRABlow 0x03

MergeThreshold 0x02

PayloadThresh 0x01

PilotStrengthFilterTC 0x02

QRABFilterTC 0x00

T2PNoTxFilterTC 0x03

PilotStrengthQRABThresholdDRCLock 0x18

PilotStrengthQRABThresholdDRCUnlock 0xc

MaxNumMACFlows 0x05

Rate1M8Supported 0x01

Complex Attributes 1

AuxiliaryPilotChannelParameters 2

Parameter Value

AuxiliaryPilotChannelGain 0xc

AuxiliaryPilotChannelMinPayload 0x7

CommonPowerParameters 3

Parameter Value

AllocationStagger ‘0000’

TxT2Pmin 0x1A

RPCStep ‘01’

PilotStrength 4

3GPP2 C.S0044-D v1.0

18-98

Parameter Value

NumPilotStrengthAxisValues 0x2

PilotStrengthAxis0 0x3c

PilotStrengthAxis1 0x00

PilotStrengthPilotStrengthAxis0 0x0

PilotStrengthPilotStrengthAxis1 0x0

RequestParameters 1

Parameter Value

ReqRatio 0x0

MaxReqInterval 0x0

RRIChannelPowerParameters 2

Parameter Value

RRIChannelGainPreTransition0 0x0

RRIChannelGainPostTransition0 0xA

RRIChannelGainPreTransition1 0x0


RRIChannelGainPreTransition2 0xA


RRIChannelGainPreTransition3 0xA

TxT2Pmax 3

Parameter Value

NumPilotStrengthAxisValues 0x3

PilotStrengthAxis0 0x1E

PilotStrengthAxis1 0x0E

PilotStrengthAxis2 0x06

TxT2PmaxPilotStrengthAxis0 0x18



PermittedPayload 4

3GPP2 C.S0044-D v1.0

18-99

Parameter Value

PermittedPayload0_1 0x9



























PermittedPayload4096_1 0xb



3GPP2 C.S0044-D v1.0

18-100




PermittedPayload8192_1 0xc






1

For Power Parameters128 to PowerParameters12288: Values from Min 2 HiCapTerminationTarget for HiCap and from Min LoLatTerminationTarget for LoLat 3

PowerParameters128 4

Parameter Value

LoLatT2PTransition128 0x2

LoLatTerminationTarget128 0x2

HiCapT2PTransition128 0x2

HiCapTerminationTarget128 0x2

T2PLoLatPreTransition128 0x0D

T2PLoLatPostTransition128 0x03

T2PHiCapPreTransition128 0x0D

T2PHiCapPostTransition128 0x03


3GPP2 C.S0044-D v1.0

18-101

Parameter Value





T2PLoLatPreTransition256 0x1A

T2PLoLatPostTransition256 0x0F

T2PHiCapPreTransition256 0x1A

T2PHiCapPostTransition256 0x0F


Parameter Value





T2PLoLatPreTransition512 0x26

T2PLoLatPostTransition512 0x1C

T2PHiCapPreTransition512 0x26

T2PHiCapPostTransition512 0x1C


Parameter Value





T2PLoLatPreTransition768 0x2E


T2PHiCapPreTransition768 0x2E



3GPP2 C.S0044-D v1.0

18-102

Parameter Value










Parameter Value










Parameter Value





T2PLoLatPreTransition2048 0x3E





3GPP2 C.S0044-D v1.0

18-103

Parameter Value










Parameter Value






T2PLoLatPostTransition4096 0x3E

T2PHiCapPreTransition4096 0x3E

T2PHiCapPostTransition4096 0x3E


Parameter Value





T2PLoLatPreTransition6144 0x4C





3GPP2 C.S0044-D v1.0

18-104

Parameter Value





T2PLoLatPreTransition8192 0x5D

T2PLoLatPostTransition8192 0x4A

T2PHiCapPreTransition8192 0x4A

T2PHiCapPostTransition8192 0x4A


Parameter Value









e. During session configuration or using GAUP, instruct the AN to negotiate the 2 following attributes for two Subtype 3 RTC MAC flows NN (>0). The values for the 3 attributes specified in the table are recommendations; any other permissible value 4 can be used. Ensure that the AN is configured to negotiate at least one attribute to 5 a non default value 6

Simple Attributes 7

3GPP2 C.S0044-D v1.0

18-105

Parameter Value for

Hi-Cap Flow

Value for

Lo-Lat flow

BucketLevelMaxNN 0x6c 0x66

MergeThresholdNN 0x02 0x00

TransmissionModeNN 0x00 0x01

QRABSelectNN 0x00 0x00

BurstDurationFactorNN 0x00 0x00

T2PFilterTCNN 0x01 0x01

Complex Attributes 1

BucketFactorNN 2

Parameter Value for

Hi-Cap Flow

Value for

Lo-Lat flow

NumT2PAxisValues 0x01 0x0

NumFRABAxisValues 0x01 0x0

T2PAxis00 0x00 0x00

T2PAxis01 0x48

FRABAxis0 0x8 0x8

FRABAxis1 0xb

BucketFactorT2PAxis00FRABAxis0 0x28 0x08

BucketFactorT2PAxis00FRABAxis1 0x18



T2PInflowRangeNN 3

Parameter Value for

Hi-Cap Flow

Value for

Lo-Lat flow

T2PInflowmin 0x00 0x0F

T2PInflowmax 0x78 0x78

T2PTransitionFunctionNN 4

3GPP2 C.S0044-D v1.0

18-106

Parameter Value for

Hi-Cap Flow

Value for

Lo-Lat flow

NumT2PAxisValues 0x03 0x02

NumFRABAxisValues 0x04 0x00

T2PAxis00 0x00 0x00

T2PAxis01 0x24 0x34

T2PAxis02 0x48 0x35

T2PAxis03 0x5A

FRABAxis0 0x8

FRABAxis1 0xB

FRABAxis2 0xE

FRABAxis3 0x2

FRABAxis4 0x5

T2PUpT2PAxis00FRABAxis0 0x1D 0x1C

T2PUpT2PAxis00FRABAxis1 0x0A

T2PUpT2PAxis00FRABAxis2 0xFE

T2PUpT2PAxis00FRABAxis3 0xFE

T2PUpT2PAxis00FRABAxis4 0xE0

T2PUpT2PAxis01FRABAxis0 0xFB 0x1C

T2PUpT2PAxis01FRABAxis1 0xE8

T2PUpT2PAxis01FRABAxis2 0xDC



T2PUpT2PAxis02FRABAxis0 0xFD 0x88

T2PUpT2PAxis02FRABAxis1 0xEA

T2PUpT2PAxis02FRABAxis2 0xDE



T2PUpT2PAxis03FRABAxis0 0x18

T2PUpT2PAxis03FRABAxis1 0x05

T2PUpT2PAxis03FRABAxis2 0xF9

3GPP2 C.S0044-D v1.0

18-107



T2PDnT2PAxis00FRABAxis0 0xE9 0xB0

T2PDnT2PAxis00FRABAxis1 0xE2

T2PDnT2PAxis00FRABAxis2 0xD6



T2PDnT2PAxis01FRABAxis0 0xEA 0xB0

T2PDnT2PAxis01FRABAxis1 0xE3




T2PDnT2PAxis02FRABAxis0 0x06 0xB0

T2PDnT2PAxis02FRABAxis1 0xFF

T2PDnT2PAxis02FRABAxis2 0xF3



T2PDnT2PAxis03FRABAxis0 0x2D

T2PDnT2PAxis03FRABAxis1 0x26

T2PDnT2PAxis03FRABAxis2 0x1A



f. Verify that the AN and AT successfully negotiate the non-default values for various 1 attributes in step d and e either through ConfigRequest/ConfigResponse messages 2 or through GAUP. 3

g. Start file upload using hi-cap MAC flow. 4

h. Verify that for reverse traffic channel transmissions, the AN transmits H-ARQ, P-5 ARQ and L-ARQ bits correctly and that the AT is able to demodulate these. Verify 6 that the PER on the reverse link is less than 1.25%. 7

i. Allow the file transfer to complete. 8

j. Stop data transfer using the hi-cap flow. 9

k. Start data transfer using lo-lat flow. 10

l. Verify that the PER for the reverse link is less than 1.25% and that 99% of the 11 packets terminate within LoLatTerminationTargetPS + 1 sub-packet transmissions 12 for packet size PS. 13

3GPP2 C.S0044-D v1.0

18-108


The AN and AT shall comply with step f. 2

The AN and AT should comply with steps h, and l. 3

18.84 MultiATPage message 4


This test verifies that AT can be paged using MultiATPage message. 6


(see [24] part 400) 8

1.5.6.1.7.1 Access Terminal Requirements 9

1.5.6.2.4 MultiATPage 10

MultiATPageMessageSupported attribute in 1.5.7.1 Simple Attributes 11

1.6.6.1.7.1 Access Terminal Requirements 12

1.6.6.2.5 MultiATPage 13

MultiATPageMessageSupported attribute in 1.6.7.1 Simple Attributes 14


None 16



b. Configure the AN to negotiate Enhanced Idle State Protocol or Quick Idle State 19 Protocol. 20

c. Ensure that the MultiATPageMessageSupported attribute is set to 0x01 indicating that 21 the AT supports the MultiATPage message. 22

d. Cause the AN to page the AT under test using the MultiATPage message. 23

e. Verify that the AT responds by sending a ConnectionRequest message, and connection 24 setup is successful. 25


The AT shall comply with e. 27

28

3GPP2 C.S0044-D v1.0

18-109

18.85 LoadInformation message 1


This test verifies that the AT uses LoadInformation message to select forward link server. 3


(see [24] part 300) 5

1.7.6.2.6 LoadInformation 6

LoadInformationSupported attribute in 1.7.7.1 Simple Attributes 7






None 13



b. Configure the AN to negotiate Enhanced Forward Traffic Channel MAC Protocol 16 (subtype 1), Subtype 2 Forward Traffic Channel MAC Protocol, or Subtype 3 Forward 17 Traffic Channel MAC Protocol 18

c. Setup a connection such that sector and sector ß are in active set. Maintain the 19 connection during this test. 20

d. Ensure that AN is not transmitting the LoadInformation message. 21

e. Adjust the attenuation on the sectors such that sector has slightly higher Forward Link 22 Power Ior than sector ß. 23

f. Ensure that AT is consistently pointing its DRC to sector . 24

g. Cause the AN to transmit LoadInformation message with LoadingAdjust for sector 25 considerably higher than sector ß. 26

h. Verify that the AT is consistently pointing its DRC to sector ß. 27

i. Cause the AN to transmit LoadInformation message with same value of LoadingAdjust 28

for sector and sector ß. 29

j. Verify that the AT is consistently pointing its DRC to sector . 30


The AT shall comply with h and j. 32

33

3GPP2 C.S0044-D v1.0

18-110

18.86 Single Carrier Multi-Link 1


This test verifies that the AT can operate with connection assigned in single carrier multi-link 3 (SCML) mode. 4


(see [24] part 200) 6

Chapter 3 Subtype 3 Physical Layer 7



(see [24] part 400) 10

1.9 Subtype 1 Route Update Protocol 11

1.9.6.2.2 TrafficChannelAssignment 12

13


None 15



b. Configure the AN to negotiate Subtype 3 Physical Layer protocol and Subtype 1 Route 18 Update Protocol. 19

c. Ensure that the SingleCarrierMultiLinkCapability attribute is set to value other than 20 0x00. 21

d. Adjust the attenuation on the sectors such sector and sector ß have same Forward 22 Link Power Ior . 23

e. Setup a connection. 24

f. Cause AN to send TrafficChannelAssignment with SCML assignment. The 25 TrafficChannelAssignment message should have 2 identical sub-Active sets (both with 26

sector and sector ß on same frequency), FeedbackMultiplexingEnabled Set to ‘1’, and 27 FeedbackMultiplexingIndex set to a feedback multiplexing method supported by the AT. 28

g. Transfer FL data to the AT. 29

h. Verify that the data is sent over the 2 links assigned to the AT. 30

i. Verify that the data transfer is successful. 31


The AT shall comply with steps h and i. 33

3GPP2 C.S0044-D v1.0

19-1

19 XHRPD 1

For xHRPD test cases described in chapter 19, the terms mobile station and base station 2 represent the access terminal (AT) and access network (AN) respectively. 3

For all tests in Chapter 19, Session Security should be enabled if supported. 4

19.1 xHRPD Acquisition and Idle Mode Operation 5

Same as 18.1. 6

19.2 xHRPD Session Establishment 7

Same as 18.2. 8


see [33] 10

1 MAC Layer, 3 Connection Layer, 4 Session Layer 11

19.3 xHRPD Session Configuration and Management with Subnet change 12

Same as 18.3. 13


see [33] 15

4 Session Layer 16

19.4 AT Color Code and UATI24 17

Same as 18.4. 18


see [33] 20


19.5 xHRPD Connection Setup 22

Same as 18.5. 23


see [33] 25


19.6 AN Packet Data Inactivity Timer 27

Same as 18.6. 28


see [33] 30

3GPP2 C.S0044-D v1.0

19-2

1 MAC Layer, 2 Security Layer, 3 Connection Layer, 4 Session Layer 1

19.7 Reserved 2

19.8 Reserved 3

19.9 Reserved 4

19.10 RLP Operation in Severely Degraded Channel 5


This test verifies RLP Operation in Severely Degraded Channel when in active xHRPD mode. 7


see [33] 9


see [26] 11


see [12] 13

Chapters 2 and 3 14


None 16



b. Set the channel simulator to one Ray 100 km/hr Rayleigh fading on the forward link. 19

c. Configure the AT to negotiate the use of Default Packet Application bound to the 20 Service Network. 21

d. Cause the AT to acquire the AN. 22

e. Initiate a xHRPD packet data call from the AT. 23

a. Issue a “ping” from AT. 24

f. Verify the AT receives “ping” response from AN. 25

g. End the xHRPD packet data call. 26

h. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 27 bound to the Service Network. 28

i. Repeat steps d to g. 29



3GPP2 C.S0044-D v1.0

19-3

19.11 Reserved 1

19.12 xHRPD Control Channel Monitoring and Overhead Message Updates 2

Same as 18.12. 3


see [33] 5

3.4 xHRPD Subtype 0 Idle State Protocol 6


19.13 Control Channel Rate 8

Same as 18.13. 9

19.14 xHRPD ConnectionDeny 10

Same as 18.14. 11


see [33] 13


3.4.6.1.6.1 AT Requirements 15

3.4.6.1.6.2 AN Requirements 16

3.4.6.2.3 ConnectionDeny 17


19.15 xHRPD Keep Alive Mechanism 19

Same as 18.15. 20

19.16 Reserved 21

19.17 Reserved 22

19.18 Intra-band xHRPD-xHRPD System Re-selection (Idle State) 23

Same as 18.18. 24


see [24] 26




3GPP2 C.S0044-D v1.0

19-4

See [33] 1




(see [26]) 5


Information 7

19.19 Inter-band xHRPD-xHRPD System Re-selection (Idle State) 8

Same as 18.19. 9


see [24] 11




See [33] 15




(see [26]) 19


Information 21

19.20 xHRPD Terminal Authentication 22

Same as 18.20. 23

19.21 PPP Session in Adverse Conditions - Disconnect cable between AT and PC. 24

Same as 18.21. 25

3GPP2 C.S0044-D v1.0

19-5

19.22 Reserved 1

19.23 Reserved 2

19.24 Idle State Channel Hashing 3


This test can be performed only if the AN supports more than one xHRPD channels. 5

If multiple channels are advertised in the sector parameter message, AT uses hash function (as 6 specified in (See [24])) to select one of the advertised channels for idle state operation. The 7 primary purpose of channel hashing is to equally distribute the AN load on all available channels. 8


see [33] 10



None 13


a. Configure the AT roaming list with the primary channel. Configure the AT to negotiate 15 xHRPD subtype 1 idle state protocol. 16

b. Power up the AT. 17

c. Place AT where it can receive good xHRPD signal. 18

d. If the AT has an open session with the AN, cause the AN to close the session. Cause 19 the AT to establish a new session with the AN. 20

e. Ensure that AT correctly acquires the primary channel listed in the roaming list. 21

f. After receiving the sector parameter messages with multiple channels, AT will try to 22 hash to a channel listed in SectorParameter message (it could be the same channel in 23 some cases). 24

g. Verify that if there are “n” channels listed in the sector parameter message and if this 25 test is repeated “m” number of times, AT will hash to each channel approximately “m/n” 26 times. In a subnet where SectorParameter message contains multiple channels, AT will 27 try to hash to a new channel every time a new session is opened. 28

h. Repeat steps d through g approximately 3n times. 29

i. Setup a xHRPD data connection after channel hashing is complete to verify that AT can 30 setup a connection on the hashed channel. Let the call connection go idle. 31

j. Send a data page from the AN (on the hashed channel) and verify that AT can receive 32 a page on the hashed channel. 33


The AT shall comply with steps g, i and j. 35

3GPP2 C.S0044-D v1.0

19-6

19.25 Reserved 1

19.26 Typical xHRPD Session Configuration 2


This test verifies the ability of AT and AN to use typical xHRPD configuration. The use of EMFPA 4 bound to the service network, xHRPD subtype 1 FTCMAC, xHRPD subtype 0 RTCMAC, default 5 CCMAC, xHRPD subtype 0 ACMAC and xHRPD subtype 0 Physical layer is verified. 6


see [32] and [33] 8

8 Enhanced Multi-Flow Packet Application 9

3.5 xHRPD subtype 1 Idle State Protocol 10

1.2 Default Control Channel MAC Protocol 11

1.4 xHRPD subtype 0 Access Channel MAC Protocol 12

1.6 xHRPD subtype 1 Forward Traffic Channel MAC Protocol 13

1.7 xHRPD subtype 0 Reverse Traffic Channel MAC Protocol 14

[32] xHRPD subtype 0 Physical Layer 15


None 17




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 21 bound to the service network, xHRPD subtype 0 Physical layer, Default CCMAC, 22 xHRPD subtype 0 ACMAC, xHRPD subtype 1 FTCMAC, xHRPD subtype 1 Idle State 23 Protocol and xHRPD subtype 0 RTC MAC. 24


e. Power cycle the AT. 27

f. Verify that the AT establishes a session with the AN and acquires the xHRPD system. 28

g. Cause the AT to initiate a data call with the AN. 29

h. Verify that the AT and the AN have successfully negotiated the use of Enhanced Multi-30 Flow Packet Application bound to the AN, xHRPD subtype 0 Physical layer, Default 31 CCMAC, xHRPD subtype 0 ACMAC, xHRPD subtype 1 FTCMAC, xHRPD subtype 1 32 Idle State Protocol and xHRPD subtype 0 RTC MAC. 33

i. Cause the AT to transmit data to the AN. 34

j. Verify that the data is transmitted using the default RLP flow of the EMFPA. 35


The AT shall comply with steps f, h and j. 37

3GPP2 C.S0044-D v1.0

19-7


19.27 Multiple Reservations bound to one RLP 2


In xHRPD multiple higher layer flows can be bound to a single RLP flow. This is done by mapping 4 the ReservationLabel associated with the higher layer flow in FlowNNReservationFwd and 5 FlowNNReservationRev attribute of the RLP Flow NN. This test verifies the ability of the AN and 6 the AT to successfully bind multiple reservations to a single RLP flow. 7


The following behavior is assumed for the application using the QoS. Starting the application will 13 cause ReservationKKQoSRequestFwd/Rev to be sent containing the requested Profile ID. Unless 14 otherwise specified, the Profile should be accepted by the AN. Closing the application will cause 15 the AT to transmit a ReservationKKQoSRequestFwd/Rev with ProfileType set to NULL. If 16 application is paused or restarted, it should turn the reservation to on state if the reservation is in 17 closed state. This application behavior is assumed for all QoS related tests in this chapter. 18


(see [24]) 20



(see 17]) 23 11.4 QoS ProfileType and ProfileValue Assignment 24 (see [10]) 25 (see [12]) 26 Chapters 2 and 3. 27


None 29




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 33 bound to the service network, xHRPD subtype 0 Physical layer, xHRPD subtype 1 34 FTCMAC and xHRPD subtype 0 RTC MAC. 35


e. Configure the AN to use a value of 2 for MaxActivatedRLPFlowsFwd and 37 MaxActivatedRLPFlowRev. 38



3GPP2 C.S0044-D v1.0

19-8


i. Cause the AT to generate a QoS request for one forward and one reverse link higher 2 layer flow. 3

j. Ensure that the AT transmits GAUP message(s) with ReservationKKQoSRequestFwd 4 with R_QoS_SUB_BLOB containing the specified Profile ID for forward higher layer 5 flows and ReservationKKQoSRequestRev with R_QoS_SUB_BLOB containing the 6 specified Profile ID for reverse higher layer flows. 7

k. Ensure that the AT constructs a Traffic Flow Template (TFT) with the desired packet 8 filters and sends an RSVP Resv [Create new TFT] message. 9

l. Ensure that the AN transmits AttributeUpdateAccept message(s) accepting the QoS 10 ReservationKKQoSRequestFwd / ReservationKKQoSRequestRev attributes from the 11 AT. 12

m. The AN should GAUP the ReservationKKQoSResponseFwd with G_QoS_BLOB 13 containing the set ID for primary Profile ID. 14

n. The AN should GAUP the ReservationKKQoSResponseRev with G_QoS_BLOB 15 containing the set ID for primary Profile ID. 16

o. The PDSN should install the desired packet filters and sends an RSVP ResvConf 17 message. 18

p. Ensure that the AT transmits AttributeUpdate message(s) to the AN accepting the AN’s 19 ReservationKKQosResponseFwd and ReservationKKQosResponseRev for the various 20 Reservarion Labels. 21

q. Ensure that the AN transmits a GAUP message for FlowNNIdentificationFwd (NN = 1) 22 and FlowNNIdentificationRev (NN = 1) in order to activate the forward and reverse link 23 flows. 24

r. Ensure that the AT transmits AttributeUpdateAccept message(s) accepting 25 FlowNNIdentificationFwd and FlowNNIdentificationRev arrtibutes. 26

s. The AN may need to transmit AttributeUpdateRequest message(s) negotiating the 27 FlowNNTimersFwd and FlowNNTimersRev for the Forward and Reverse link RLP flows 28 and various parameters of the RTCMAC flow. 29

t. If the AN transmits Attribute Update Request for the Forward and Reverse Link RLP 30 Flows and/or RTCMAC flows, the AT should transmit AttributeUpdateAccept 31 message(s) accepting RLP and RTCMAC parameters. 32

u. Ensure that the AN transmits a FlowNNReservationFwd to bind the reservation to 33 forward to RLP flow (NN = 0x01). 34

v. Ensure that the AN transmits a FlowNNReservationRev to bind the reservation to 35 reservation to RLP flow (NN = 0x01). 36

w. Ensure that the AT transmits an AttributeUpdateAccept message accepting the 37 FlowNNReservationFwd and FlowNNReservationRev values. 38

x. Ensure that the AN transmits AttributeUpdateReqest message containing 39 AssociatedFlowNN with substream field set to 1 to bind the RLP FlowNN (NN = 1) to an 40 RTCMAC flow. 41

y. Ensure that the AT transmits AttributeUpdateAccept message(s) to the AN accepting 42 the binding sent by the AN in AssociatedFlowsNN attribute. 43

z. Ensure that the AN transmits a GAUP message to set RTCMAC BucketLevelMaxNN 44 with a nonzero value in order to activate the RTCMAC flow. 45

3GPP2 C.S0044-D v1.0

19-9

aa. Ensure that the AT transmits AttributeUpdateAccept message to the AN accepting the 1 BucketLevelMaxNN value sent by the AN. 2

bb. Ensure that the AT sends ReservationOnRequest for both the forward and reverse 3 ReservationLabels using single ReservationOnRequest message. 4

cc. Ensure that AN sends ReservationAccept for both forward and reverse reservations. 5

dd. Repeat steps i to cc for 2 other QoS requests. 6

ee. Verify that both the forward and reverse RLP flows (NN = 1) are activated and the 7 reservation for all the higher layer flows are in the Open state. 8

ff. Start bidirectional data transfer for different higher layer flows and verify that data is 9 being sent/received on the correct RLP IDs. 10

gg. Ensure that the PDSN is sending data via the intended filter. 11


The AT shall comply with steps ee and ff. 13

The AN shall comply with steps ee and ff. 14

The PDSN should comply with steps o and gg. 15

19.28 Maximum Open Reservations, Activated RLP and MAC flows 16


The Maximum number of reservations that can be in open state in xHRPD is governed by 18 MaxNumOpenReservationsFwd and MaxNumOpenReservationsRev (default value of 16). The 19 maximum number of open RLP flows is governed by MaxActivatedRLPFlowsFwd and 20 MaxActivatedRLPFlowsRev. The maximum number of active MAC flows is governed by 21

MaxNumActiveMACFlows This test verifies that AT and the AN can support up to 16 open 22 reservations, mapped to 8 RLP flows that are in turn mapped to 4 MAC flows. This test implicitly 23 verifies the ability of the AN and the AT to allow many to one binding from reservation labels to 24 RLP flows and RLP flows to MAC Flows. It also verifies the ability of the PDSN to create multiple 25 filters for the AT. 26


(see [24]) 28



(see [10]) 31

(see [12]) 32

Chapters 2 and 3 33


None 35




3GPP2 C.S0044-D v1.0

19-10



e. Configure the AN to use a value of 8 for MaxActivatedRLPFlowsFwd, 5 MaxActivatedRLPFlowRev, MaxNumRLPFlowsFwd and MaxNumRLPFlowsRev. 6

f. Configure the AN to set the MaxNumOpenReservationsFwd and 7 MaxNumOpenReservationsRev parameters of MaxReservations attribute to 16. 8

g. Configure the AN to grant the QoS request from the AT and to bind 2 QoS reservations 9 to one RLP flow for both the forward and reverse link flows, and to bind 2 RLP flows to 10 each RTCMAC Flow. 11

h. If the AT has an established session with the AN, cause the AN to close the session by 12 transmitting a SessionClose message. 13

i. Cause the AT to negotiate a new session with the AN. 14

j. Ensure that the AN activates only the default RLP flow during session configuration. 15

k. Cause the AT to establish a data call with the AN and allow the AT to go idle. 16

l. Using multiple applications, cause the AT to generate QoS requests for 16 forward and 17 reverse link flows. Wait for the AN to transmit ReservationAccept message for all the 18 reservations. 19

m. Verify that all 8 forward and reverse RLP flows are activated and all 16 reservations are 20 in Open state. 21

n. Start bidirectional data transfer for different higher layer flows and verify that data is 22 being sent/received on the correct RLP and MAC flows. 23

o. Ensure that the PDSN is sending data for each higher layer flow via the intended filter. 24


The AT shall comply with steps m and n. 26

The AN shall comply with steps m and n. 27

The PDSN should comply with step o. 28

19.29 QoS Release upon PDSN initiated LCP termination 29


When the PDSN terminates a PPP connection by transmitting an LCP termination message, the 31 AT and the AN should release all the resources allocated to the current QoS Reservations. The 32 PDSN should delete the TFT associated with the AT. 33


(see [24]) 35

Chapter 4. Multi-Flow Packet Application 36

(see [12]) 37

Chapter 2 Enhanced Mult-Flow Packet Application 38

Chapter 3 Multi-Link Multi-Flow Packet Application 39

(see [10]) 40

3GPP2 C.S0044-D v1.0

19-11

(see [28]) 1

3.2.1 PPP Session 2


None 4




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 8 bound to the service network, xHRPD subtype 0 Physical layer, xHRPD subtype 1 9 FTCMAC and xHRPD subtype 0 RTCMAC. 10

d. Configure the AN to grant the QoS request from the AT and to use a value of 0x00 11 for ReservationKKIdleStateFwd and ReservationKKIdleStateRev attributes. 12

e. If the AT has an established session with the AN, cause the AN to close the session 13 by transmitting a SessionClose message. 14



h. Cause the AT to generate QoS requests for one forward and reverse link flow with 17 ReservationKKIdleStateFwd and ReservationKKIdleStateRev set to 0x00. Wait for the 18 AN to transmit ReservationAccept message for all the reservations. 19

i. Start data transfer and ensure that all reservations are in open state and that the 20 data is being transmitted using appropriate RLP flow IDs. 21

j. Cause the PDSN to transmit an LCP termination to the AT. 22

k. Verify that the AT terminated the PPP. 23

l. Ensure that the AN and AT release all QoS resources by verifying that the AT 24 transmits ReservationKKQoSRequest(s) with ProfileType set to NULL and 25 ReservationOffRequest message(s) for all the open reservation(s) and that the AN 26 responds with a ReservationAccept message(s). 27

m. The PDSN should delete all filters associated with the AT. 28


The AT shall comply with step k and l. 30

The AN shall comply with steps l. 31

The PDSN should comply with step m. 32

19.30 QoS Release upon AT Initiated PPP Termination 33


When the AT terminates the PPP session, the AT and the AN should release all QoS and the 35 PDSN should delete TFT related to the AT. 36


(see [24]) 38

3GPP2 C.S0044-D v1.0

19-12

Chapter 4. 1

(see [10]) 2

(see [12]) 3

Chapters 2 and 3 4


None 6









h. Cause the AT to generate Qos requests for one forward and reverse link flow. Wait for 19 the AN to transmit ReservationAccept message for all the reservations. 20

i. Start data transfer and verify that all reservations are in open state and that the data is 21 being transmitted using appropriate RLP flow IDs. 22

j. Cause the AT to terminate the PPP session. 23

k. Ensure that the AN and AT release all QoS resources by verifying that the AT transmits 24 ReservationKKQoSRequest(s) with ProfileType set to NULL and 25 ReservationOffRequest message(s) for all the open reservation(s) and that the AN 26 responds with a ReservationAccept message(s). 27

l. The PDSN should delete all filters associated with the AT. 28




The PDSN should comply with step l. 32

19.31 Reserved 33

19.32 AT Data Over Signaling Message Transmission 34


This test verifies that the AT can send a packet over the Access Channel to the AN. This is 36 accomplished by using the Data Over Signaling (DoS) Protocol. The size of the data packet that 37 the AT sends must be smaller than the Access Channel capsule size. Specifically, this test 38

3GPP2 C.S0044-D v1.0

19-13

validates that the delivery of higher layer packet using a DataOverSignaling Message transmitted 1 by the AT to the AN, and the MessageSequence increment for the DataOverSignaling Messages. 2 This test also validates the ability of the AN to acknowledge the DataOverSignaling Message with 3 a DataOverSignalingAck with appropriate AckSequence field when the AckRequired field in the 4 DataOverSignaling Message is set to 1. 5


(see [12]) 7

Chapters 2 and 3 8


None 10




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 14 bound to the service network, xHRPD subtype 0 Physical layer, Enhanced CCMAC, 15 xHRPD subtype 0 ACMAC, xHRPD subtype 0 RTC MAC. 16


e. During Session Configuration, set the Active parameter of FlowNNIdentificationFwd 20 (NN = 0xij) attribute and FlowNNIdentificationRev (NN = 0xij attribute to 0x01. 21

f. Set the ReservationLabel for FlowNNReservationRev (NN = 0xij and 22 FlowNNReservationFwd (NN = 0xij) to High Priority Signaling. Set 23 FlowNNDataOverSignalingAllowedRev (NN = 0xij) to 0x01. Configure the AN to grant 24 the QoS request from the AT and to set ReservationKKIdleStateFwd and 25 ReservationKKIdleStateRev to 0x0 for ReservationLabel kk associated with High 26 Priority Signaling. 27


h. Instruct the AT to send a ReservationOn message for ReservationLabel kk associated 30 with High Priority Signaling data that is to be carried using DataOverSignaling message 31 to the AN and ensure that the AN responds with a ReservationAccept message. Instruct 32 the AT to send a ReservationOn message for ReservationLabel kk associated with High 33 Priority Signaling data that is to be carried using DataOverSignaling message from the 34 AN to the AT and ensure that the AN responds with a ReservationAccept message. 35


j. Transmit a packet from the AT directed to the AN using the DataOverSignaling 37 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 38 Ensure that the DataOverSignaling message is smaller than the maximum Access 39 Channel capsule size. 40

k. Verify that the AT transmits a DataOverSignaling Message with MessageID field set to 41 0x14, AckRequired field set to 1, Reset field set to 0, MessageSequence field set to 0, 42 and the HigherLayerPacket field set to entire higher layer packet. 43

l. Verify that if the AN received the DataOverSignaling Message, it transmits a 44 DataOverSignalingAck with MessageID set to 0x15 and AckSequence field set to zero 45

3GPP2 C.S0044-D v1.0

19-14

and the higher layer packet carried in the DataOverSignaling message is delivered to 1 the higher layer protocol. 2

m. Transmit a packet from the AT directed to the AN using the DataOverSignaling 3 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 4 Ensure that the DataOverSignaling message size is smaller than the maximum Access 5 Channel capsule size. 6

n. Verify that the AT transmits a DataOverSignaling Message with MessageSequence 7 field set to 1. 8

o. Verify that if the AN received the DataOverSignaling Message, it transmits a 9 DataOverSignalingAck with the AckSequence field set to one and the packet is 10 delivered to the higher layer protocol. 11


The AT shall comply with steps k and n. 13

The AN shall comply with steps l and o. 14

19.33 AN Data Over Signaling Message Transmission 15


This test verifies that the AN can send a packet over the Control Channel to the AT. This is 17 accomplished by using the Data Over Signaling (DoS) Protocol. Specifically, this test validates 18 the delivery of higher layer packet using of a DataOverSignaling Message transmitted by the AN 19 to the AT, and the MessageSequence increment for the DataOverSignaling Messages. This test 20 also validates the ability of the AT to acknowledge the DataOverSignaling Message with a 21 DataOverSignalingAck with appropriate AckSequence field when the AckRequired field in the 22 DataOverSignaling Message is set to 1. 23


(see [12]) 25

Chapters 2 and 3 26


None 28




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 32 bound to the service network, xHRPD subtype 0 Physical layer, Enhanced CCMAC, 33 xHRPD subtype 0 ACMAC, xHRPD subtype 0 RTC MAC. 34


e. During Session Configuration, set the Active parameter of FlowNNIdentificationFwd 38 (NN = 0xij) attribute and FlowNNIdentificationRev (NN = 0xij) attribute to 0x01. 39

f. Set the ReservationLabel for FlowNNReservationRev (NN = 0xij) and 40 FlowNNReservationFwd (NN = 0xij) to High Priority Signaling. Set 41 FlowNNDataOverSignalingAllowedRev (NN = 0xij) to 0x01. Configure the AN to grant 42

3GPP2 C.S0044-D v1.0

19-15

the QoS request from the AT and to set ReservationKKIdleStateFwd and 1 ReservationKKIdleStateRev to 0x0 for ReservationLabel kk associated with High 2 Priority Signaling. 3


h. Instruct the AT to send a ReservationOn message for ReservationLabel kk associated 6 with High Priority Signaling data that is to be carried using DataOverSignaling message 7 to the AN and ensure that the AN responds with a ReservationAccept message. 8

i. Allow the xHRPD connection to become idle. 9

j. Cause the AN to transmit a packet directed to the AT using the DataOverSignaling 10 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 11 Ensure that the DataOverSignaling Message size is less than the ControlChannel 12 capsule size (600 bytes). 13

k. Verify that the AN transmits a DataOverSignaling Message with MessageID field set to 14 0x14, AckRequired field set to 1, Reset field set to 0, MessageSequence field set to 0, 15 and the HigherLayerPacket field set to entire higher layer packet. 16

l. Verify that if the AT received the DataOverSignaling Message, it transmits a 17 DataOverSignalingAck with MessageID field set to 0x15 and AckSequence field set to 18 zero and the packet carried in the DataOverSignaling message is delivered to the 19 higher layer protocol. 20

m. Cause the AN to transmit a packet directed to the AT using the DataOverSignaling 21 message and setting the AckRequired field of the DataOverSignaling message to ‘1’. 22 Ensure that the DataOverSignaling message size is smaller than the Control Channel 23 capsule size (600 bytes). 24

n. Verify that the AN transmits a DataOverSignaling Message with MessageSequence 25 field set to 1. 26

o. Verify that if the AT received the DataOverSignaling Message, it transmits a 27 DataOverSignalingAck with the AckSequence field set to one and the packet carried in 28 the DataOverSignaling message is delivered to the higher layer protocol. 29


The AT shall comply with steps l and o. 31

The AN shall comply with steps k and n. 32

19.34 Voice Origination in xHRPD Idle Mode 33


This test verifies a voice origination call when in idle xHRPD mode. 35


(see [29]) 37

(see [30]) 38

(see [33]) 39




3GPP2 C.S0044-D v1.0

19-16

(see [26]) 1


(see [4]) 3







2.7.3 Orders 10






3.7.4 Orders 16

3.7.5.5 Signal 17


None. 19



b. Initiate a voice call from the AT. 22

c. Verify the call completes,uses xHRPD header compression and verify user data in both 23 directions. 24

d. End the call. 25



19.35 Voice Termination in xHRPD Idle Mode 28


This test verifies a voice termination call when in idle xHRPD mode. 30


(see [29]) 32

(see [30]) 33

(see [33]) 34


3GPP2 C.S0044-D v1.0

19-17



(see [26]) 3


(see [4]) 5







2.7.3 Orders 12






3.7.4 Orders 18

3.7.5.5 Signal 19


None 21



b. Initiate a voice call to the AT. 24

c. Verify the call completes,uses xHRPD header compression and verify user data in both 25 directions. 26

d. End the call. 27



19.36 Reserved 30

19.37 Reserved 31

19.38 Voice Origination in xHRPD Active Mode 32


This test verifies a voice origination call when in active xHRPD mode. 34

3GPP2 C.S0044-D v1.0

19-18


(see [29]) 2

(see [30]) 3

(see [33]) 4




(see [26]) 8


(see [4]) 10







2.7.3 Orders 17






3.7.4 Orders 23

3.7.5.5 Signal 24


None 26



b. Initiate a xHRPD packet data call from the AT. 29

c. Issue a continuous “ping” command from the AT to a remote host. 30

d. Initiate a voice call from the AT. 31

e. Verify the call completes and pings continue through the voice call. 32


g. After voice call is released, verify that pings are continuous on same ppp session. 34

h. End the xHRPD packet data call. 35

3GPP2 C.S0044-D v1.0

19-19



19.39 Voice Termination in xHRPD Active Mode 3


This test verifies a voice termination call when in active xHRPD mode. 5


(see [29]) 7

(see [30]) 8

(see [24]) 9




(see [26]) 13


(see [4]) 15







2.7.3 Orders 22






3.7.4 Orders 28

3.7.5.5 Signal 29


None 31





3GPP2 C.S0044-D v1.0

19-20

d. Initiate a voice call to the AT. 1

e. Verify the call completes and pings continue through the voice call. 2






3GPP2 C.S0044-D v1.0

19-21

19.40 Reserved 1

19.41 Reserved 2

19.42 Reserved 3

19.43 Reserved 4

19.44 Reserved 5

19.45 Reserved 6

19.46 Reserved 7

19.47 Reserved 8

19.48 Reserved 9

19.49 Reserved 10

19.50 Reserved 11

19.51 Reserved 12

19.52 Reserved 13

19.53 Inter RNC Dormant Hand-off (xHRPD to xHRPD) 14


This test verifies the Inter-RNC dormant handoff is successful. AN 1 and AN 2 have a different 16 RNC. Both AN 1 and AN 2 support xHRPD. RNC 1 and RNC 2 have an A13 link established. 17


(see [33]) 19





3GPP2 C.S0044-D v1.0

19-22

(see [26]) 1

3.7.1 PCF-PCF Dormant Handoff with Successful Retrieval of xHRPD Session 2 Information 3


None 5


b. Connect the AT to AN 1 and AN 2 as shown in Figure A-5. 7



c. Cause the AT to acquire AN 1. Setup an xHRPD AT originated call. 11

d. Ensure that the AT connection is idle and the PPP session is dormant. 12


f. After the AT has successfully acquired AN 2, issue a “ping” from AT. 14

g. Verify the AT successfully establishes an xHRPD connection and call on AN 2, RNC 2. 15



19.54 Reserved 18

19.55 Reserved 19

19.56 Reserved 20

19.57 Reserved 21

19.58 Reserved 22

19.59 Reserved 23

19.60 RLP Activation 24


This test verifies the ability of the AN to activate RLP flows during session negotiation and later 26 associate these active RLP flows to requested QoS. In the test, it is assumed that the AN will be 27 able to accept the reservation requests generated by the AT. Note that each of the reservation 28 requests may have multiple ProfileIDs and it is possible for the AN to accept any one or none of 29 these Profiles. Typically, the AN should accept AT’s most preferred profile, unless it is not able to 30 support this profile due to resource constraints or other reasons. 31

3GPP2 C.S0044-D v1.0

19-23



(see [12]) 7

Chapters 2 and 3 8


None 10




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 14 bound to the service network, xHRPD subtype 0 Physical layer and xHRPD subtype 0 15 RTC MAC. 16

d. Configure the AN to activate MaxActivatedRLPFlowsFwd Forward Link Flows and 17 MaxActivatedRLPFlowsRev Reverse Link Flows during session configuration. 18


f. Power cycle the AT. 21

g. Ensure that the AT establishes a session with the AN and acquires the xHRPD system. 22

h. Verify that the AN activates MaxActivatedRLPFlowsFwd Forward Link Flows and 23 MaxActivatedRLPFlowsRev Reverse Link Flows during session configuration. 24

i. Cause the AT to establish a data call with the AN. 25

j. Allow the AT to go idle. 26

k. Trigger a QoS request by starting any application that requires reservation for at least 27 one forward and one reverse link flow. An example of such an application would be 28 video telephony. 29

l. Verify that during the subsequent signaling the AN does not transmit 30 AttributeUpdateRequest messages containing 31 FlowNNIdentificationFwd/FlowNNIdentificationRev attributes for any flow. 32

m. Verify that if the AN did not negotiate FlowNNReservationFwd and 33 FlowNNReservationRev attributes during session negotiation, then the AN transmits 34 AttributeUpdateRequest messages(s) containing FlowNNReservationFwd attributes 35 binding ReservationLabel(s) to Forward Link RLP flow(s) NN and 36 FlowNNReservationRev attributes binding ReservationLabel(s) to Reverse Link flow(s). 37

n. Verify that if the AN transmits AttributeUpdateRequest messages(s) containing 38 FlowNNReservationFwd and FlowNNReservationRev attributes, then the AT transmits 39 AttributeUpdateAccept message to the AN accepting the FlowNNReservationFwd and 40 FlowNNReservationRev attributes. 41

3GPP2 C.S0044-D v1.0

19-24

o. Verify that if the AN did not negotiate AssociatedFlowNN attribute during session 1 negotiation, then the AN transmits AttributeUpdateRequest message containing 2 AssociatedFlowNN attribute binding the RLP flow(s) to the RTCMAC flow(s). 3

p. Verify that if the AN transmits AttributeUpdateRequest messages(s) containing 4 AssociatedFlowNN attribute, then the AT transmits AttributeUpdateAccept message(s) 5 to the AN accepting the binding sent by the AN in AssociatedFlowsNN attribute. 6

q. Start data transfer for each of the forward and reverse link higher layer flows that are 7 bound to an RLP flow through FlowNNReservationFwd and FlowNNReservationRev 8 attributes. 9

r. Verify that the AT uses Flow NN to transmit data for higher layer flow with 10 ReservationLabel KK if the ReservationLabel KK was mapped to Flow NN through 11 FlowNNReservationRev attribute. 12

s. Verify that the AN uses Flow NN to transmit data for higher layer flow with 13 ReservationLabel KK if the ReservationLabel KK was mapped to Flow NN through 14 FlowNNReservationFwd attribute. 15


The AT shall comply with steps n, p and r. 17

The AN shall comply with steps h, l, m, o and s. 18

19.61 QoS Set Up 19


This test verifies the ability of the AN and the AT to set-up and use QoS for any application. The 21 application may reside at the AT or the TE (Terminal Equipment). Specifically, for setting up the 22 QoS for the application, this test verifies that the QoS request and response, reservation to RLP 23 binding, RLP to RTCMAC flow binding on the reverse link, RLP and RTCMAC flow activation, and 24 opening the reservations. This test also verifies the GAUP messages needed to update various 25 attributes and parameters. Note for this test each of the reservation requests may have multiple 26 ProfileIDs and it is possible for the AN to accept any one or none of the Profiles. Typically, the AN 27 should accept AT’s most preferred profile, unless it is not able to support this profile due to 28 resource constraints or other reasons. Unless otherwise specified, this test assumes that the AN 29 will be able to accept any of the proposed profiles. 30

It is assumed that the application needs one or more higher layer flows that are identified by their 31 ReservationLabels. Each higher layer flow is bound to an RLP. More than one flow may be bound 32 to an RLP. On the reverse link, the RLP ids are in turn bound to 1 or more MAC Flows. For 33 example a Video Telephony application may require three separate higher layer flows 34 (reservations) for audio, video and SIP signaling. The application may be designed to map audio 35 and video higher layer flows to separate RLPs (due to different abort timer requirements for audio 36 and video, for example), but transmit SIP flows’ data through the default RLP that is typically used 37 for best effort traffic. On the reverse link RLP ids used by audio and video may be mapped to 38 different MAC flows that are configured to provide different latencies, for example. 39


(see [12]) 41

Chapters 2 and 3 42

(see [10]) 43

3GPP2 C.S0044-D v1.0

19-25


None 2


a. Connect the AT to the AN as shown in Figure A-3. If the application resides on the TE 4 connect the TE to the AT. 5



d. Configure the AN to activate only the default RLP flow during session configuration. 10 This can be done by setting the active parameter of the FlowNNIdentificationFwd and 11 FlowNNIdentificationRev attribute to 0 for all RLP flows with NN ≠ 0. 12

e. Ensure that the AN activates only the default RLP flow during session configuration. 13

f. If the AT has an established session with the AN, cause either the AT or the AN to 14 close the session by transmitting a SessionClose message. 15



i. Cause the AT to start the application that needs to be tested. The application will 18 generate QoS requests for all forward and reverse link flow(s). 19

j. Verify that the AT transmits GAUP message(s) with ReservationKKQoSReqFwd with 20 R_QoS_SUB_BLOB containing the specified Profile ID for forward flow(s) and 21 ReservationKKQoSReqRev with R_QoS_SUB_BLOB containing the specified Profile ID 22 for reverse flow(s). 23

k. Verify that the AT constructs a Traffic Flow Template (TFT) with the desired packet 24 filters and sends an RSVP Resv [Create new TFT] message. 25

l. Verify that the AN transmits AttributeUpdateAccept message(s) accepting the QoS 26 ReservationKKQoSRequestFwd/ ReservationKKQoSRequestRev attributes from the 27 AT. 28

m. The AN should GAUP the ReservationKKQoSResponseFwd with G_QoS_BLOB 29 containing the set ID for primary Profile ID for all the higher layer flow(s) of the 30 application. 31

n. Verify that the PDSN installs the desired packet filters and sends an RSVP ResvConf 32 message. 33

o. Verify that the AT transmits AttributeUpdate message(s) to the AN accepting the AN’s 34 ReservationKKQosResponseFwd and ReservationKKQosResponseRev for the 35 ReservationLabel(s). 36

p. Verify that the AN transmits a GAUP message for FlowNNIdentificationFwd and 37 FlowNNIdentificationRev in order to activate the forward and reverse link flow(s). 38

q. Verify that the AT transmits AttributeUpdateAccept message(s) accepting 39 FlowNNIdentificationFwd and FlowNNIdentificationRev attributes. 40

r. Verify that the AN transmits a GAUP message for FlowNNReservationFwd and 41 FlowNNReservationRev for binding the reservations to RLP flow(s). 42

s. Verify that the AT transmits AttributeUpdateAccept message(s) accepting 43 FlowNNReservationFwd and FlowNNReservationRev values. 44

3GPP2 C.S0044-D v1.0

19-26

t. The AN will determine the number of Forward and Reverse Link RLP flows and 1 RTCMAC flows needed to support the accepted QoS requests. The AN may need to 2 transmit AttributeUpdateRequest message(s) negotiating the parameters for Forward 3 and Reverse link and RLP flows and RTCMAC flows. 4

u. If the AN transmits Attribute Update Request for the Forward and Reverse Link RLP 5 Flows and/or RTCMAC flows, verify that the AT transmits AttributeUpdateAccept 6 message(s) accepting RLP and RTCMAC parameters. 7

v. Verify that the AN transmits AttributeUpdateRequest message containing 8 AssociatedFlowNN with substream field set to 1 to bind the RLP flow(s) to the RTCMAC 9 flow(s). 10

w. Verify that the AT transmits AttributeUpdateAccept message(s) to the AN accepting the 11 binding sent by the AN in AssociatedFlowsNN attribute. 12

x. The AN should GAUP RTCMAC BucketLevelMaxNN with a nonzero value to activate 13 the RTCMAC flow(s). 14

y. Verify that the AT transmits AttributeUpdateAccept message to the AN accepting the 15 BucketLevelMaxNN value sent by the AN. 16

z. Verify that the AT sends ReservationOnRequest for both the forward and reverse 17 ReservationLabel(s) using single ReservationOnRequest message. 18

aa. Verify that AN sends ReservationAccept for both forward and reverse reservations. 19

bb. Verify that both the forward and reverse RLP flows are activated and all the 20 reservations are in Open state. 21

cc. Once the application starts data transfer, verify that data is being sent on the 22 appropriate RLP IDs on the forward link and on the appropriate RLP and MAC Flows on 23 the reverse link. 24

dd. Ensure that the PDSN is sending data via the intended filter. 25


The AT shall comply with steps j, k, o, q, s, u, w, y, z, bb, and cc. 27

The AN shall comply with steps l, p, r, v, aa, bb, and cc. 28

The AN should comply with steps m and x. 29

The PDSN should comply with steps n and dd. 30

3GPP2 C.S0044-D v1.0

19-27

19.62 Reserved 1

19.63 Reserved 2

19.64 Reserved 3

19.65 Reserved 4

19.66 Reserved 5

19.67 QoS Signaling upon PPP resynchronization 6


This test verifies that upon PPP resynchronization the AT transmits a new RSVP RESV message 8 and that the PDSN installs the new filter based on the new RESV message 9


(see [12]) 11

Chapters 2 and 3 12

(see [10]) 13


None 15





d. Configure the AN to grant the QoS request from the AT. 22



g. Ensure that the AN activates only the default RLP flow during session configuration. 26


i. Cause the AT to generate QoS requests for two forward and two reverse link flows. 28 Wait for the AN to transmit a ReservationAccept message for all the reservations. 29

j. Start data transfer and verify that all reservations are in open state and that the data is 30 being transmitted using appropriate RLP flow IDs. 31

3GPP2 C.S0044-D v1.0

19-28

k. Cause the PDSN to initiate a PPP resynchronization. This can be achieved for example 1 by an inter-PDSN handoff. Ensure that the PDSN provides the same IP Address as 2 received in step h. 3

l. Verify that the AT resynchronizes the PPP. 4

m. Verify that the AT transmits a RSVP RESV message with all the higher layer flows to 5 the PDSN after PPP resynchronization is complete. 6

n. Ensure that the PDSN sends a RSVP ResvConf message. 7


The AT shall comply with step l and m. 9

The PDSN should comply with step n. 10

19.68 AT behavior upon Rejection of Reservation Request by AN 11


The default flow in xHRPD is always in active state. When the AN rejects a QoS request, the data 13 for the QoS flow should be sent through the default RLP flow on the forward and reverse link and 14 will receive best-effort treatment. 15

Under normal circumstances, the AN will accept a reservation request from the AT. However, the 16 AN may deny the reservation request for many reasons, for example if the request is invalid or if 17 the given admission control policy at the AN determines that the request cannot be fulfilled. 18 Specifying a configuration where the AN denies the QoS request is beyond the scope of the 19 document and is left to the tester. 20


(see [12]) 22

Chapters 2 and 3 23


None. 25









h. Cause the AT to generate QoS request for one forward and reverse link flow. 37

i. Cause the AN to reject GAUP AttributeUpdateRequest message for 38 ReservationKKQoSRequestFwd and ReservationKKQoSRequestRev. 39

3GPP2 C.S0044-D v1.0

19-29

j. Start bi-directional data transfer with parameters that match the specification of the QoS 1 request. 2

k. Verify that the data can be sent and received on the default RLP flow and receives 3 best-effort treatment. 4




19.69 AT behavior upon Receiving ProfileType set to NULL 8


When the AN accepts a QoS request but sends a QoS response with ProfileType field set to 10 NULL, the data for the QoS flow should be sent through the default RLP flow on the forward and 11 reverse link and will receive best-effort treatment. 12


(see [12]) 14

Chapters 2 and 3 15


None 17









h. While the AT has a connection with the AN, cause the AT to generate QoS request for 29 one forward and one reverse link flow. 30

i. Cause the AN to accept the GAUP AttributeUpdateRequest message for 31 ReservationKKQoSRequestFwd and ReservationKKQoSRequestRev. 32

j. Cause the AN to transmit a ReservationKKQoSResponse with ProfileType set to 0x00 33 for both the forward and reverse link flows. 34

k. Start bi-directional data transfer with parameters that match the specification of the QoS 35 request. 36

l. Verify that the data is sent and received on the default RLP flow and receives best-37 effort treatment. 38

3GPP2 C.S0044-D v1.0

19-30




19.70 ReservationKKIdleStateFwd and ReservationKKIdleStateRev set to 0 4


The state of a reservation can change when the AT goes dormant. The change in a reservation’s 6 state is determined by the value of ReservationKKIdleStateFwd / ReservationKKIdleStateRev 7 where KK (=0xij) is the 2 digit hexadecimal ReservationLabel (0xij ≠ 0xff) that identifies the 8 reservation in use. A Reservation is bound to an RLP flow NN by setting the ReservationLabel 9 parameter of the FlowNNReservationFwd / FlowNNReservationRev attribute to the reservation’s 10 label (KK = 0xij). When the ReservationKKIdleStateFwd / ReservationKKIdleStateRev (KK = 0xij) 11 attribute is set to 0, the state of the reservation (with ReservationLabel KK = 0xij) will not change 12 upon closing or opening of the connection. In the test procedure, application refers to an 13 application that generates data for flow with ReservationLabel (KK = 0xij). Starting this application 14 will cause the AT to transmit forward and reverse QoS ReservationOn request(s) for 15 ReservationLabel (KK = 0xij) if the reservation is in closed state. Any higher layer flow with 16 ReservationLabel 0xij (0xij ≠ 0xff) that generates forward and reverse reservation requests can be 17 used. This test verifies that the reservation state does not change when ReservationKKIdleState 18 is set to 0 and that the initial state of a reservation is closed (0xij ≠ 0xff). The test procedure 19 transitions the state of the (connection state, reservation state) pair from (close, close), to (open, 20 close), to (open, open), to (close, open) and finally to (open, open) again. 21


(see [12]) 23

Chapters 2 and 3 24


None 26




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 30 bound to the service network, xHRPD subtype 0 Physical layer, xHRPD subtype 1 31 FTCMAC, and xHRPD subtype 0 RTC MAC. 32




g. Cause the AT to establish a data call with the AN by transmitting data for higher layer 39 flow with ReservationLabel 0xff (Note. This will open the connection by transmitting 40 data on the default flow). 41

h. While the AT has a connection with the AN, start the application that generates data for 42 higher layer flow with ReservationLabel KK (= 0xij ≠ 0xff). 43

3GPP2 C.S0044-D v1.0

19-31

i. Verify that the reservation is in closed state and the AT transmits forward and reverse 1 ReservationOn request for the higher layer flows with ReservationLabel KK (= 0xij ≠ 2 0xff). Wait for the AN to transmit ReservationAccept message for all the reservations. 3

j. Once the data transfer starts from the application, ensure that the reservation is in open 4 state and that the data is being transmitted using appropriate (non-default) RLP flow ID. 5

k. Cause the AT to loose the connection with the AN. Ensure that the AT does not 6 transmit ReservationOff request for the ReservationLabel KK (= 0xij ≠ 0xff) to the AN. 7

l. Cause the AT to reestablish a data call with the AN. 8

m. Start bi-directional data transfer for the higher layer flow with ReservationLabel KK (= 9 0xij ≠ 0xff). 10

n. Verify that the reservation is in open state and that during or after reestablishing the 11 data call, the AT does not need to transmit the ReservationOn request for 12 ReservationLabel KK (= 0xij ≠ 0xff) and that the AN does not transmit 13 FwdReservationOn and/or RevReservationOn message(s). 14

o. Verify that the AN and the AT transmit the data through RLP with appropriate (non-15 default) flow id. 16

p. Stop the application and cause the AT to transmit a ReservationOff message for the 17 forward and/or reverse higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff). 18

q. Allow the AT to go dormant. 19

r. Cause the AT to establish a data call with the AN by transmitting data for higher layer 20 flow with ReservationLabel 0xff. 21

s. Start the application. 22

t. Verify that the reservation is in closed state and the AT transmits the ReservationOn 23 request for opening the reservation for forward and reverse link flow with 24 ReservationLabel KK (= 0xij ≠ 0xff). Note, the AT may send a combined ReservationOn 25 request for the forward link and reverse link reservations. Wait for the AN to accept the 26 reservation(s). 27

u. Verify that the AN and the AT transmit the data through RLP with appropriate (non-28 default) flow id 29


The AT shall comply with step i, n, o, t and u. 31

The AN shall comply with steps n, o and u. 32



The state of a reservation can change when the AT goes dormant. The change in a reservation’s 35 state is determined by the value of ReservationKKIdleStateFwd / ReservationKKIdleStateRev 36 where KK (=0xij) is the 2 digit hexadecimal ReservationLabel (0xij ≠ 0xff) that identifies the 37 reservation in use. A Reservation is bound to an RLP flow NN by setting the ReservationLabel 38 parameter of the FlowNNReservationFwd / FlowNNReservationRev attribute to the reservation’s 39 label (KK = 0xij). When the ReservationKKIdleStateFwd / ReservationKKIdleStateRev (KK = 0xij) 40 attribute is set to 0x1, the reservation will close when the HRPD connection is closed. This test 41 verifies the change in a reservation’s state when ReservationKKIdleState is set to 1. In the test 42 procedure, application refers to an application that generates data for higher layer flow with 43 ReservationLabel KK (= 0xij ≠ 0xff). Starting this application will cause the AT to transmit forward 44 and reverse QoS reservation requests for ReservationLabel KK (= 0xij ≠ 0xff) if the reservation is 45

3GPP2 C.S0044-D v1.0

19-32

in closed state. Any ReservationLabel KK other that 0xff that generates forward and reverse 1 reservation requests can be used. 2


(see [12]) 4

Chapters 2 and 3 5


None 7








g. Cause the AT to establish a data call with the AN by transmitting data for higher layer 20 flow with ReservationLabel 0xff. 21

h. Start the application and verify that the AT transmits reservation requests for forward 22 and reverse link higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff). Wait for the 23 AN to transmit ReservationAccept message for all the reservations. 24

i. Start the application and ensure that the reservation is in open state and that the data is 25 being transmitted using appropriate (non-default) RLP flow ID. 26

j. Cause the AT to loose the connection with the AN. Ensure that the AT does not 27 transmit ReservationOff requests (forward or reverse) for ReservationLabel KK (= 0xij ≠ 28 0xff) to the AN. 29

k. Cause the AT to reestablish a data call with the AN. 30

l. Ensure that the application generates data for the higher layer flow with 31 ReservationLabel KK (= 0xij ≠ 0xff). 32

m. Verify that the reservation is in closed state and the AT transmits the ReservationOn 33 request for the higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff) for forward 34 and reverse link flows. Wait for the AN to accept the reservation. 35

n. Verify that the AN and the AT transmit the data through RLP with appropriate (non-36 default) flow id. 37


The AT shall comply with steps h, m and n. 39

The AN shall comply with step n. 40

3GPP2 C.S0044-D v1.0

19-33



The state of a reservation can change when the AT goes dormant. The change in a reservation’s 3 state is determined by the value of ReservationKKIdleStateFwd / ReservationKKIdleStateRev 4 where KK (=0xij) is the 2 digit hexadecimal ReservationLabel (0xij ≠ 0xff) that identifies the 5 reservation in use. A Reservation is bound to an RLP flow NN by setting the ReservationLabel 6 parameter of the FlowNNReservationFwd / FlowNNReservationRev attribute to the reservation’s 7 label (KK = 0xij). When the ReservationKKIdleStateFwd / ReservationKKIdleStateRev (KK = 0xij) 8 attribute is set to 0x2, the reservation will open when the HRPD connection is opened and close 9 when the HRPD connection is closed. This test verifies the change in state of the reservation 10 (with ReservationLabel KK = 0xij ≠ 0xff) with opening and closing of connection when 11 ReservationKKIdleState is set to 0x2. In the test procedure, application refers to an application 12 that generates data for higher layer flow with ReservationLabel KK (= 0xij ≠ 0xff). Starting this 13 application will cause the AT to transmit forward and reverse QoS ReservationOn requests for 14 ReservationLabel KK (= 0xij ≠ 0xff) if the reservation is in closed state. Any ReservationLabel KK 15 other that 0xff that requires forward and reverse reservations can be used 16


(see [12]) 18

Chapters 2 and 3 19


None 21





d. Configure the AN to grant the QoS request from the AT and to set 28 ReservationKKIdleStateFwd and ReservationKKIdleStateRev to 0x0 for 29 ReservationLabel KK (= 0xij ≠ 0xff) and FlowNNDataOverSignalingAllowedRev and 30 FlowNNDataOverSignalingAllowedFwd set to 1 for the RLP flow NN to which 31 ReservationLabel KK (= 0xij ≠ 0xff) will be bound. 32

e. Configure the AN to activate MaxActivatedRLPFlowsFwd and 33 MaxActivatedRLPFlowsRev during session configuration. 34



h. Cause the AT to establish a data call with the AN. 38

i. Start the application and ensure that the AT transmits reservation requests for forward 39 and reverse link higher layer flows with ReservationLabel KK (= 0xij ≠ 0xff). Wait for the 40 AN to transmit ReservationAccept message for all the reservations. 41

j. Start data transfer and verify that the reservation is in open state and that the data is 42 being transmitted using appropriate (non-default) RLP flow ID. 43

3GPP2 C.S0044-D v1.0

19-34

k. Stop the data transfer and allow the AT to become dormant and ensure that the AT 1 does not transmit ReservationOffRequest messages for the ReservationLabel KK (= 2 0xij ≠ 0xff). 3

l. Cause the AT to generate a DataOverSignaling message for the higher layer flow with 4 ReservationLabel KK (= 0xij ≠ 0xff). Ensure that the AT does not open the connection 5 with the AN. 6

m. Ensure that the reservation is in open state and the AT does not need to transmit the 7 ReservationOn request for the reservation and that the AN does not transmit 8 FwdReservationOn and/or RevReservationOn message(s). 9

n. Ensure that the AT transmits the DataOverSignaling message. 10

o. Transmit a DataOverSignaling message from the AN to the AT for the higher layer flow 11 with ReservationLabel KK (= 0xij ≠ 0xff). Ensure that the AT does not open the 12 connection with the AN. 13

p. Ensure that the reservation is in open state and the AT does not need to transmit the 14 ReservationOn request for the reservation and that the AN does not transmit 15 FwdReservationOn and/or RevReservationOn message(s). 16

q. Ensure that the AN transmits the DataOverSignaling message. 17

r. Repeat steps d to h with the exception that in step d, configure the AN to set 18 ReservationKKIdleStateFwd and ReservationKKIdleStateRev to 0x2. 19

s. Cause the AT to establish a data call with the AN by transmitting data for higher layer 20 flow with ReservationLabel 0xff. 21

t. Generate data from the application. 22

u. Verify that the AT does not need to transmit the ReservationOn request for the 23 reservation and that the AN does not transmit FwdReservationOn and/or 24 RevReservationOn message(s) and that the AN and the AT transmit application’s data 25 through appropriate (non-default) RLP. 26

v. Force the AT to become idle. 27

w. Cause the AT to generate a DataOverSignaling message for the higher layer flow with 28 ReservationLabel KK (= 0xij ≠ 0xff). 29

x. Verify that the AT does not transmit DataOverSignaling message. 30

y. Cause the AN to generate a DataOverSignaling message for the higher layer flow with 31 ReservationLabel KK (= 0xij ≠ 0xff). 32

z. Verify that the AN does not transmit DataOverSignaling message. 33


The AT shall comply with step u and x. 35

The AN shall comply with steps u and z. 36

19.73 CQI Supervision Failure 37


The AT performs CQI supervision in order to ensure call quality. This test verifies that the AT 39 behavior for CQI supervision. Specifically, it verifies that if the AT transmits NULL CQI for 40 CQISupervisionTimer*10 + 240 ms. continuously without receiving any packets (either FTC or CC 41 MAC packets) from the AN then it shall disable the Reverse Traffic Channel. Subsequently, the 42 AT starts a timer for TFTCMPRestartTx (5.12 seconds). If during this period, a packet (either FTC or CC 43

3GPP2 C.S0044-D v1.0

19-35

MAC packets) is received from the AN or if the AT transmits a non-NULL tentative CQI, then the 1 AT disables the timer. Otherwise it declares a CQI supervision failure and tears down the 2 connection. 3


(see [24]) 5

Section 1.6.6.1.9.1 6

(see [12]) 7

Chapters 2 and 3 8


None 10




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 14 bound to the service network, xHRPD subtype 0 Physical layer, Enhanced CCMAC, 15 xHRPD subtype 1 FTCMAC and , xHRPD subtype 0 RTC MAC. 16

d. Configure the AN to use a transmission rate of 38.4 kbps for the control channel. 17

e. During SCP or using GAUP, negotiate the value of MultiUserPacketsEnabled to be 18 0x00. This will disallow the AN from transmitting data to the AT, when the AT is 19 transmitting NULL rate CQI. 20

f. Cause the AT to establish a connection with the AN. 21

g. Start bi-directional data transfer and ensure that data is going through continuously in 22 both directions. 23

h. Reduce Îor

such that the AT starts transmitting NULL rate tentative CQI and is unable to 24

receive the control channel. 25

i. Verify that the AT disables the Reverse Traffic Channel after transmitting null rate 26 tentative CQI for CQISupervisionTimer*10 + 240 ms period continuously. Ensure that 27 the AN does not transmit any packets on the forward traffic channel to the AT and the 28 AT does not receive any control channel packet during this time interval. 29

j. Within TFTCMPRestartTx (5.12 seconds) of disabling reverse traffic channel transmitter in the 30 last step, increase Î

or such that the AT start transmitting a non-null tentative CQI to the 31

AN. Ensure that the AN does not transmit any packets on the forward traffic channel to 32 the AT and the AT does not receive any control channel packet before AT has 33 transmitted non-null CQI for NFTCMPRestartTx slots continuously. 34

k. Verify that the AT enables the reverse traffic channel and bi-directional transfer occurs 35 after AT has transmitted non-null CQI for NFTCMPRestartTx slots continuously. 36

l. Reduce Îor

such that the AT starts transmitting NULL rate tentative CQI’s and is unable 37


m. Verify that the AT returns a CQI supervision failure indication and tears down the 39 connection at the expiration of TFTCMPRestartTx. Note, the AT will transmit a null rate 40 tentative CQI for a period of CQISupervisionTimer*10 + 240 ms before starting the 41 TFTCMPRestartTx timer. 42

3GPP2 C.S0044-D v1.0

19-36


The AT shall comply with steps i, k, m. 2


19.74 Reserved 4

19.75 Reserved 5

19.76 Reserved 6

19.77 Reserved 7

19.78 Reserved 8

19.79 Reserved 9

19.80 Enhanced Control Channel Short MAC Packet 10


The purpose of this test is to verify that the AT successfully decodes various short packet formats 12 with different negotiated values of CCShortPacketMACIndex. This test requires the AN to 13 transmit CC short MAC packets. Since the size of the ACAck and Page packet is smaller than 14 512 bits, it is likely although not necessary that the AN will use CC short MAC packets for 15 transmitting these messages. 16


(see [24]) 18

Section 10.3.6.1.4.1.1 19

(see [12]) 20

Chapters 2 and 3 21


None 23




c. Configure the AT to negotiate the use Enhanced Multi-Flow Packet Application bound 27 to the service network, xHRPD subtype 0 Physical layer, Enhanced CCMAC, xHRPD 28 subtype 0 ACMAC, xHRPD subtype 1 FTCMAC, xHRPD subtype 1 Idle State 29 Protocol and xHRPD subtype 0 RTC MAC. 30

3GPP2 C.S0044-D v1.0

19-37

d. Start a new session and using SCP negotiate the value of CCShortPacketsMACIndex 1 attribute to 0x00. 2

e. Using SCP or GAUP negotiate the value of SlottedMode attribute as follows: 3

Field Value


SlotCycle1 0x5

SlotCycle2 0x5

SlotCycle3 0x5



f. After session configuration is complete, instruct the AT to open a connection with the 4 AN. 5

g. Verify that in response to the AT’s AccessProbe message, the AN transmits an ACAck 6 message in a asynchronous CC capsule using one of the following Transmission 7 Formats17 of [128, 4, 1024], [256, 4, 1024], [512, 4, 1024] with preamble MAC Index 8 71. If the message is transmitted using the sub-synchronous or synchronous capsule, 9 repeat steps f and g. 10

h. Verify that the AT receives the ACAck message and stops transmitting the 11 AccessProbe. 12

i. Allow the connection to become dormant. 13

j. Instruct the AN to transmit a Page to the AT. 14

k. Verify that the AN transmits the Page message in a sub-synchronous CC capsule using 15 one of the following Transmission Formats of [128, 4, 1024], [256, 4, 1024], [512, 4, 16 1024] with a preamble MAC Index of 71. If the message is transmitted using the 17 synchronous capsule, repeat steps i, j and k. 18

l. Verify that the AT receives the Page message and establishes a connection with the 19 AN. 20

m. Instruct the AT or the AN to close the session. 21

n. Start a new session and using SCP negotiate any valid value of 22 CCShortPacketsMACIndex other than 0x00. 23

o. Using SCP or GAUP negotiate the value of SlottedMode attribute as follows: 24

17 Transmission Format is defined as [ Payload Size (bits), Nominal transmit duration (slots), Preamble

Length (chips))

3GPP2 C.S0044-D v1.0

19-38

Field Value


SlotCycle1 0x5

SlotCycle2 0x5

SlotCycle3 0x5



p. After session configuration is complete, instruct the AT to open a connection with the 1 AN. 2

q. Verify that in response to the AT’s AccessProbe message, the AN transmits an ACAck 3 message in a asynchronous CC capsule using one of the following Transmission 4 Formats of [128, 4, 1024], [256, 4, 1024], [512, 4, 1024] with preamble MAC Index 5 negotiated in step n or 71. If the message is transmitted using the sub-synchronous or 6 synchronous capsule, repeat steps o and p. 7

r. Verify that the AT receives the ACAck message and stops transmitting the 8 AccessProbe. 9

s. Allow the connection to become dormant. 10

t. Instruct the AN to transmit a Page to the AT. 11

u. Verify that the AN transmits the Page message in a sub-synchronous CC capsule using 12 one of the following Transmission Formats of [128, 4, 1024], [256, 4, 1024], [512, 4, 13 1024] with a preamble MAC Index negotiated in step n or 71. If the message is 14 transmitted using the synchronous capsule, repeat steps i, j and k. 15

v. Verify that the AT receives the Page message and establishes a connection with the 16 AN 17


The AT shall comply with steps h, l, r, and v. 19

The AN shall comply with steps g, k, q and u. 20

19.81 Access Channel Probe Transmission 21


The purpose of this test is to verify that the AN and the AT successfully negotiate the 23 PreambleLength, AccessChannelOffset and CapsuleLengthMax attributes of the xHRPD subtype 24 0 ACMAC protocol and that using these parameters the AT transmits the access probe at 25 appropriate time and that the AN successfully receives the probe. This test uses Data Over 26 Signaling protocol to generate payload for the Access Channel Capsule. 27


(see [33]) 29

3GPP2 C.S0044-D v1.0

19-39

Section 1.4.6.1.4.1.1 (Probe Transmission) 1

Section 1.4.6.2.6 (Access Parameters message) 2

(see [12]) 3

Chapters 2 and 3 4


None 6




c. Configure the AT to negotiate the use of Enhanced Multi-Flow Packet Application 10 bound to the service network, xHRPD subtype 0 Physical layer, Enhanced CCMAC, 11 xHRPD subtype 0 ACMAC, xHRPD subtype 1 FTCMAC, xHRPD subtype 1 Idle State 12 Protocol and xHRPD subtype 0 RTC MAC. 13

d. Configure the AN to transmit CapsuleLengthMax value of 0x7, PreambleLenght value of 14 ‘0’ (4 slots), AccessChannelOffset value of ‘03’ in the AccessParameters message. 15

e. During Session Configuration, set the ProtocolIdentifier field of the 16 FlowNNHigherLayerProtocolRev (NN = KK) and FlowNNHigherLayerProtocolFwd (NN 17 = KK) to HDLC framing. 18

f. During Session Configuration, set the Active parameter of FlowNNIdentificationFwd 19 (NN = KK) attribute and FlowNNIdentificationRev (NN = KK) attribute to 0x01. 20

g. Set the ReservationLabel for FlowNNReservationRev (NN = KK) and 21 FlowNNReservationFwd (NN = KK) to High Priority Signaling. Set 22 FlowNNDataOverSignalingAllowedRev (NN = KK) and 23 FlowNNDataOverSignalingAllowedFwd (NN = KK) to 0x01. Configure the AN to grant 24 the QoS request from the AT and to set ReservationKKIdleStateFwd and 25 ReservationKKIdleStateRev to 0x0 for ReservationLabel kk associated with High 26 Priority Signaling. 27

h. If the AT does not have an established PPP session, cause the AT to establish a PPP 28 session. 29

i. Instruct the AT to send a ReservationOn message for ReservationLabel kk associated 30 with High Priority Signaling data that is to be carried using DataOverSignaling message 31 to the AN and ensure that the AN responds with a ReservationAccept message. Instruct 32 the AT to send a ReservationOn message for ReservationLabel kk associated with High 33 Priority Signaling data that is to be carried using DataOverSignaling message from the 34 AN to the AT and ensure that the AN responds with a ReservationAccept message. 35

j. Allow the xHRPD connection to become idle. 36

k. Transmit a ping packet from the AT directed to the AN using the Data Over Signaling 37 Protocol and setting the AckRequired field of the DataOverSignaling message to ‘1’. 38

l. Verify that the AT transmits a DataOverSignaling Message over the Access Channel. 39 Verify that the AT started the transmission of the AccessProbe at time T such that 40

(T-12*AccessChannelOffset) mod AccessCycleDuration = 0, 41

where T is CDMA System Time in slots and AccessCycleDuration is defined in the 42 AccessParameters message transmitted by the AN. Verify that the AT transmits the 43 Preamble for PreambleLength. 44

3GPP2 C.S0044-D v1.0

19-40

m. Verify that the AN receives the DataOverSignaling Message. This can be verified by the 1 transmission of DataOverSignalingAck by the AN. 2


The AT shall comply with step l. 4

The AN shall comply with step m. 5

19.82 Reserved 6

19.83 Reserved 7

19.84 Reserved 8

19.85 Reserved 9

19.86 Reserved 10

19.87 Inter Technology Switching in Idle Mode – xHRPD to LTE 11


This test verifies idle mode inter-technology switching from xHRPD to LTE. This test only applies 13 to AT that are capable of switching from xHRPD to LTE while the AT is idle. The algorithm for 14 switching is AT dependent and should be known before test case execution. 15


(see [29]) 17

(see [30]) 18

(see [33]) 19




(see [26]) 23


(see [4]) 25







3GPP2 C.S0044-D v1.0

19-41

2.7.3 Orders 1






3.7.4 Orders 7

3.7.5.5 Signal 8


None 10


a. Connect the AT to the AN as shown in Figure A-5 with AN 1 configured as xHRPD and 12 AN 2 configured as LTE. 13

b. Cause the AT to acquire AN 1 configured as xHRPD. 14

c. Initiate a xHRPD packet data call from the AT. 15

d. Wait for AT to go idle. 16

e. Cause the AT terminal to switch from AN 1, configured as xHRPD to AN 2 configured 17 as LTE. 18

f. Verify AT is idle for data on AN 2 configured as LTE. 19

g. Open a data session with AN 2. 20

h. Issue a “ping” command from the remote host to the AT. 21

i. Verify the AT is active for data on AN 2 configured for LTE, and verify the remote host 22 receives a “ping” response from the AT. 23

j. End the call. 24


The AT shall comply with step i. 26

19.88 Inter Technology Switching in Idle Mode – xHRPD to HRPD 27


This test verifies idle mode inter-technology switching from xHRPD to HRPD. This test only 29 applies to AT that are capable of switching from xHRPD to HRPD while the AT is idle. The 30 algorithm for switching is AT dependent and should be known before test case execution. 31


(see [29]) 33

(see [30]) 34

(see [33]) 35



3GPP2 C.S0044-D v1.0

19-42


(see [26]) 2


(see [4]) 4







2.7.3 Orders 11






3.7.4 Orders 17

3.7.5.5 Signal 18


None 20


a. Connect the AT to the AN as shown in Figure A-5 with AN 1 configured as xHRPD and 22 AN 2 configured as HRPD. 23

b. Cause the AT to acquire AN 1 configured as xHRPD. 24

c. Initiate a xHRPD packet data call from the AT. 25

d. Wait for AT to go idle. 26

e. Cause the AT terminal to switch from AN 1, configured as xHRPD to AN 2 configured 27 as HRPD. 28

f. Verify AT is idle for data on AN 2 configured as HRPD. 29

g. Open a data session with AN 2. 30

h. Issue a “ping” command from the remote host to the AT. 31

i. Verify the AT is active for data on AN 2 configured for HRPD, and verify the remote host 32 receives a “ping” response from the AT. 33

j. End the call. 34


The AT shall comply with steps i. 36

3GPP2 C.S0044-D v1.0

19-43

19.89 Concurrent Voice and Data Service 1


This test verifies that xHRPD terminal supports concurrent voice and data services. 3


(see [29]) 5

(see [30]) 6

(see [33]) 7




(see [26]) 11


(see [4]) 13







2.7.3 Orders 20






3.7.4 Orders 26

3.7.5.5 Signal 27


None 29





d. Initiate a voice call from the AT. 34

e. Verify that the voice call is successful and the pings continue during the voice call. 35


3GPP2 C.S0044-D v1.0

19-44




The AT shall comply with steps e and g. 4

19.90 CALEA Requirement in Idle State 5


This test verifies that xHRPD terminal complies to CALEA requirement in Idle state. 7


(see [33]) 9

3.7.6.2.1 Route Update Message 10


None 12



b. Inform the AT of change in country code. 15

c. Verify that the upon encountering change of country code, AT, if in Idle state, generates 16

a route update message to AN with ‘GMSALocationPresent‘ and ‘GMSALocation’ fields 17

set to appropriate values. 18


The AT shall comply with step c. 20

3GPP2 C.S0044-D v1.0

20-1

20 ANNEX A – FIGURES (NORMATIVE) 1

This Annex is normative. 2

Figure A - 1 3

4

5

6

7

8

9

10

Tx

Rx (A)

Rx (B)

Base Station

or

Access Network

Mobile Station

or

Access Terminal

Antenna

Attenuator

Load

Channel

SimulatorAttenuator

3GPP2 C.S0044-D v1.0

20-2

Figure A - 2 1

2

3

4

5

6

7

8

9

10

11

12

13

Base Station 1

Tx

Rx (A)

Rx (B)

Base Station 2

Tx

Rx (A)

Rx (B)

Mobile Station

Antenna

DAT

Code DomainAnalyzer

AWGN

Source

Attenuator

Attenuator

SpectrumAnalyzer

Attenuator

DAT

Load

ChannelSimulator

Code Domain

Analyzer

Load

ChannelSimulator

Attenuator

3GPP2 C.S0044-D v1.0

20-3

1

Figure A - 3 2

3

Tx

Rx (A)

Rx (B)

Base Stationor

Access Network

Mobile Stationor

Access Terminal

Antenna

Attenuator #2

Load

Attenuator #1

Spectrum

Analyzer

Code DomainAnalyzer

3GPP2 C.S0044-D v1.0

20-4

1

Figure A - 4 2

Base Station #1

Sector a

Tx

Rx (A)

Rx (B)

Base Station #1

Sector b

Tx

Rx (A)

Rx (B)

Mobile Station

Antenna

Code Domain

Analyzer

AWGN

Source

Attenuator

Attenuator

Spectrum

Analyzer

Attenuator

Load

Code DomainAnalyzer

Load

Attenuator

Base Station #2

Tx

Rx (A)

Rx (B)

Code DomainAnalyzer

Load

Attenuator

3 4

5

6

7

3GPP2 C.S0044-D v1.0

20-5

Figure A - 5 1

2

Figure A – 6 3

4

5

6

Tx

Rx (A)

Rx (B)

Base Station 1

orAccess Network 1

Mobile Station

orAccess Terminal

Antenna

Attenuator

Load

AttenuatorAttenuator

Tx

Rx (A)

Rx (B)

Base Station 2or

Access Network 2

Load

Attenuator

Rm

Tx

Rx (A)

Rx (B)

Base Station

Mobile Station

Antenna

Attenuator

Load

Channel

SimulatorAttenuator

MT2

TE2

3GPP2 C.S0044-D v1.0

20-6

Figure A – 7 Test Setup for RLP Abort in Forward Link 1

2

Figure A – 8 Test Setup for RLP Abort in Reverse Link 3

4

3GPP2 C.S0044-D v1.0

20-7

Figure A – 9 1

2

Figure A – 10 3

4

5

6

AN 1 Tx

RX(A)

RX(B)

Load

Channel Simulator

AT

Antenna

Attenuator

Attenuator

AN 2 Tx

RX(A)

RX(B)

Load

Channel Simulator

3GPP2 C.S0044-D v1.0

20-8


3GPP2 C.S0044-D v1.0

21-1

21 ANNEX B (NORMATIVE) 1

This Annex is normative. 2

21.1 Annex B.1 Power Ratios for Common and Traffic Channels 3

4

Annex B.1 provides the proper power ratios to perform a test when the power ratios are not 5 specified in the test. The tables below specify power ratios for the Forward pilot channel, the 6 Sync Channel, the Paging Channel, the Forward Common Control Channel, the Broadcast 7 Control Channel, the Fundamental Channel, the Dedicated Control Channel, the Supplemental 8 Code Channels and the Supplemental Channels. The traffic channel power ratios are specified 9 to achieve at least 1% FER under AWGN channel conditions. Most channels can be configured 10 for more than one data rate, code rate, or frame size. Not all default configurations are listed in 11 this Annex. However, the power ratios listed in this Annex do provide the most conservative 12 default ratios when only a subset of the values are listed for a particular channel, since the 13 objective of these default ratios is to support signaling conformance tests and not minimum 14 performance tests. All power ratios are valid for Band Classes 0 through 12. Whenever the 15 power ratios are specified in the test, those power ratios should be used in lieu of power ratios 16 provided in this Annex. 17

18

Table B.1-1 Power Ratios for Common Channels 19

Parameter Units Value

Ior

EcPilot

dB -7

Ior

EcSync

dB -16

Ior

EcPaging

dB -12 (9600 bps)

Ior

EcBCCH

dB -15.2 (9600bps, no TD)

Ior

EcFCCCH

dB -12.8 (19200 bps)

-9.5 (38400 bps)

Ioc dBm/1.23 MHz

-54

20

3GPP2 C.S0044-D v1.0

21-2

Table B.1-2 Test Parameters for Forward Fundamental Channel (RC1, RC3 and RC4) 1


Ioc

orI

dB -1

)1RC(Ior

EcFCH

dB -15.6

)3RC(Ior

EcFCH

dB -16.2

)4RC(Ior

EcFCH

dB -15.4

Ioc dBm/1.23 MHz

-54

Data Rate bps

9600

2

Table B.1-3 Test Parameters for Forward Fundamental Channel (RC2 and RC5) 3


Ioc

orI

dB -1

)2RC(Ior

EcFCH

dB -12.3

)5RC(Ior

EcFCH

dB -13.8

Ioc dBm/1.23 MHz

-54

Data Rate bps

14400

4

5

3GPP2 C.S0044-D v1.0

21-3

Table B.1-4 Test Parameters for Forward Dedicated Control Channel (RC3 and RC4) 1


Ioc

orI

dB -1

)3RC(Ior

EcFCH

dB -16.2

)4RC(Ior

EcFCH

dB -15.4

Ioc dBm/1.23 MHz

-54

Data Rate bps

9600

2

Table B.1-5 Test Parameters for Forward Dedicated Control Channel (RC5) 3


Ioc

orI

dB -1

Ior

EcFCH

dB -13.8

Ioc dBm/1.23 MHz

-54

Data Rate bps

14400

4

3GPP2 C.S0044-D v1.0

21-4

Table B.1-6 Test Parameters for Forward Supplemental Code Channel (RC1) 1


Ioc

orI

dB -1

Ior

EcSCCH

dB -16.1

Ior

EcFCH

dB -12.0

Ioc dBm/1.23 MHz

-54

Data Rate bps

9600

2

3

Table B.1-7 Test Parameters for Forward Supplemental Code Channel (RC2) 4


Ioc

orI

dB -1

Ior

EcSCCH

dB -13.0

Ior

EcFCH

dB -12.0

Ioc dBm/1.23 MHz

-54

Data Rate bps

14400

5

3GPP2 C.S0044-D v1.0

21-5

Table B.1-8 Test Parameters for Forward Supplemental Channel (RC3 and RC4) 1


Ioc

orI

dB -1

)3RC(Ior

EcSCH

dB -13.0 -9.7 -6.6 -3.2

)4RC(Ior

EcSCH

dB -12.6 -9.3 -6.0 -2.8

Ior

EcFCH

dB -7.0

Ioc dBm/1.23 MHz

-54

Data Rate bps

19200 38400 76800 153600

2

Table B.1-9 Test Parameters for Forward Supplemental Channel (RC5) 3


Ioc

orI

dB -1

Ior

EcSCH

dB -10.9 -7.9 -4.6 -1.4

Ior

EcFCH

dB -7.0

Ioc dBm/1.23 MHz

-54

Data Rate bps

28800 57600 115200 230400

21.2 Annex B.2 CDMA Equations 4

5

The following equations describe the relationship between various test parameters under different 6 conditions. If the Paging Channel is not supported, the Forward Common Control Channel may 7 be substituted. 8

3GPP2 C.S0044-D v1.0

21-6

21.2.1 B.2.1 Transmit Power of the Base Station 1

or

c

I

EPilot +

or

c

I

E Pilot TD+

or

c

I

E Sync +

or

c

I

E QPCH +

or

c

I

EPaging +

or

c

I

E FCCCH+

or

c

I

E BCCH 2

+ or

c

I

E CACH+

or

c

I

E CPCCH+

or

c

I

E FCH+

or

c

I

E DCCH+

or

c

I

E ControlPower +

or

c

I

E SCCH + 3

or

c

I

E SCH+

or

c

I

E OCNS = 1 4

5

Using the or

c

I

Evalues for the Pilot, Sync and Paging Channels in Table B.1-1, 6

If or

c

I

E Dedicated = -16 dB at 9600 bps data rate, then 7

or

c

I

E ControlPower = -26.41 dB 8

or

c

I

E OCNS = -1.64 dB 9

Otherwise, if or

c

I

E Dedicated = -16 dB at 1200 bps data rate, then 10

or

c

I

E ControlPower = -17.38 dB 11

or

c

I

E OCNS = -1.75 dB 12

13

where “Dedicated” can represent FCH or DCCH. 14

15

21.2.2 Annex B.2.2 Received Signal Strength for Mobile Station Not in Handoff 16

17

Pilot

o

c

I

E =

1ˆ

I

EPilot

or

c

or

oc

I

I 18

19

Single-Path Case 20

3GPP2 C.S0044-D v1.0

21-7

Common t

b

N

E =

or

oc

or

c

I

I

Bit_Chip_CommonI

E Common

1

Dedicated t

b

N

E =

or

oc

or

c

I

I

Bit_Chip_DedicatedI

E Dedicated

2

3

where “Common” can be applied to Sync Channel, QCPH, Paging Channel, BCCH, or FCCCH. 4

“Dedicated” can be applied to FCH, DCCH, SCCH, or SCH. 5

6

7

Two-Path Case 8

According to Channel Simulator Configuration 1 and 2 (see 6.4.1.1), these two paths have the 9 same average power. 10

Dedicated t

b

N

E =

or

c

I

E Dedicated x Dedicated_Chip_Bit x

2

1

I

I

1

or

oc

11

12

where “Dedicated” can be applied to FCH, DCCH, SCCH, or SCH. 13

14

Three-Path Case 15

According to Channel Simulator Configuration 4 (see 6.4.1.1), the first two paths have the same 16 average power and the third path has half the average power of the first one. 17

Dedicated t

b

N

E =

or

c

I

E Dedicated x Dedicated_Chip_Bit x (2 x

5

3

I

I5

2

or

oc

+

5

4

I

I5

1

or

oc

) 18

19


21

22

21.2.3 Annex B.2.3 Received Signal Strength for Mobile Station in Two-Way Handoff 23

According to Channel Simulator Configuration 2 (see 6.4.1.1), which is used in the tests of the 24 Forward Traffic Channel in two-way handoff, there are two paths from each cell and the power 25 received from each cell is Îor. 26

3GPP2 C.S0044-D v1.0

21-8

Pilot 0

c

I

E(for each pilot) =

2I

I

I

EPilot

or

oc

or

c

1

Dedicated t

b

N

E =

or

c

I

E Dedicatedx Dedicated_Chip_Bit x

2

3

I

I2

3

or

oc

2


4

Generally, if the power received from cell 1 and cell 2 are or1I and or2I , respectively, then 5

Pilot 0

c

I

E1 =

1I

I

I

I

1I

EPilot

or1

or2

or1

oc

or

c

6

7

Pilot 0

c

I

E2 =

1I

I

I

I

2I

EPilot

or2

or1

or2

oc

or

c

8

9

10

11

12

13

14

15

16

17

18

19

20

21.3 Annex B.3 Message Parameter Values 21

22

3GPP2 C.S0044-D v1.0

21-9

Extended Handoff Direction Message/General Handoff Direction Message/ 1

Universal Handoff Direction Message 2

Field Value (With Hard Handoff)

Value (Without Hard Handoff)

T_ADD 28 (-14 dB) 28 (-14 dB)

T_DROP 32 (-16 dB) 32 (-16 dB)

T_COMP 5 (2.5 dB) 5 (2.5 dB)

T_TDROP 3 (4 sec) 3 (4 sec)

HARD_INCLUDED

(EHDM)/

EXTRA_PARMS

(GHDM/UHDM)

1 N/A

FRAME_OFFSET 0 N/A

PRIVATE_LCM 0 N/A

RESET_L2 1 N/A

RESET_FPC 1 N/A

SERV_NEG_TYPE 1 N/A

ENCRYPT_MODE 0 N/A

NOM_PWR_EXT 0 N/A

NOM_PWR 0 N/A

NUM_PREAMBLE 0 N/A

BAND_CLASS (user specify) N/A

CDMA_FREQ F2 N/A

PILOT_PN user specify N/A

PWR_COMB_IND 0 N/A

CODE_CHAN 1 to 63 (user specify) N/A

3

3GPP2 C.S0044-D v1.0

21-10

Analog Handoff Direction Message 1

Field Value

SID Use appropriate number for analog system.

VMAC 3

ANALOG_CHAN Use appropriate analog channel of choice.

SCC Use one of three SAT Color Code (0, 1 or 2).

MEM 0

AN_CHAN_TYPE 0

DSCC_MSB 0

2

System Parameters Message 3

Field Value (Physical Meaning)

SRCH_WIN_A 8 (60 chips)


SRCH_WIN_R 8 (60 chips)

NGHBR_MAX_AGE 0 (minimum amount)

PWR_THRESH_ENABLE 0 (threshold reporting off)

PWR_PERIOD_ENABLE 0 (periodic reporting off)

T_ADD 28 (-14 dB Ec/Io)

T_DROP 32 (-16 dB Ec/Io)

T_COMP 5 (2.5 dB)

T_TDROP 3 (4 sec)

QPCH_SUPPORTED 0 (QPCH disabled)

4

Extended System Parameters Message 5


SOFT_SLOPE 0 (0)

RLGAIN_TRAFFIC_PILOT 0 (0 dB)

6

7

3GPP2 C.S0044-D v1.0

21-11

Access Parameters Message 1


NOM_PWR 0 (0 dB)

INIT_PWR 0 (0 dB)

PWR_STEP 1 (1 dB)

NUM_STEP 4 (5 probes/sequence)

NOM_PWR_EXT 0 (0 dB)

2

Values for Time Limits and Constants 3

Constant Value Unit

N1m 9 frames

N2m 12 frames

N3m 2 frames

N11m 1 frame

T1b 1.28 seconds

T5m 5 seconds

T31m 600 seconds

T40m 3 seconds

T56m 0.2 seconds

T61m 0.08 seconds

4

5

3GPP2 C.S0044-D v1.0

21-12


3GPP2 C.S0044-D v1.0

22-1

22 ANNEX C - PROTOCOL CAPABILITY RESPONSE MESSAGE 1

FEATURE IDENTIFIERS (NORMATIVE) 2

This Annex is normative. 3 4

3GPP2 C.S0044-D v1.0

22-2

Features FEATURE_ID FEATURE_P_REV FEATURE_P_REV Description

NAM Download

(DATA_P_REV)

‘00000000’ ‘00000010’ NAM Download as specified

in this document

Key Exchange

(A_KEY_P_REV)

‘00000001’ ‘00000010’ A key provisioning as

specified in this document

‘00000011’ A key and 3G Root Key

provisioning as specified in

this document

‘00000100’ 3G Root Key provisioning

as specified in this

document

System Selection for

Preferred Roaming

(SSPR_P_REV)

‘00000010’ ‘00000001’ System Selection for

Preferred Roaming using

Preferred Roaming List

‘00000010’ Reserved

‘00000011’ System Selection for

Preferred Roaming using

Extended Preferred

Roaming List associated

with SSPR_P_REV of

‘00000011’

Service Programming Lock

(SPL_P_REV)

‘00000011’ ‘00000001’ Service Programming Lock

as specified in this

document

Over-The-Air Parameter

Administration

(OTAPA_P_REV)

‘00000100’ ‘00000001’ Over-The-Air Parameter

Administration as specified

in this document

Preferred User Zone List

(PUZL_P_REV)

‘00000101’ ‘00000001’ Preferred User Zone List as

specified in this document

3G Packet Data (3GPD) '00000110' '00000010' 3G Packet Data as specified

in this document

Secure MODE

SECURE_MODE_P_REV)

‘00000111’ ‘00000001’ Secure Mode as specified in

this document

Reserved for future

standardization

‘000001000’

through

‘10111111’

Available for manufacturer- ‘11000000’

through

3GPP2 C.S0044-D v1.0

22-3

Features FEATURE_ID FEATURE_P_REV FEATURE_P_REV Description

specific features ‘11111110’

Reserved ‘11111111’

1

2

3GPP2 C.S0044-D v1.0

22-4


3GPP2 C.S0044-D v1.0

23-1

23 ANNEX D DATA SERVICES TESTS (INFORMATIVE) 1

This Annex is informative. 2

23.1 Data Services Annex D.1: References 3

RFC 792 Internet Control Message Protocol 4

RFC 854 Telnet Protocol specification 5

RFC 959 File Transfer Protocol 6

RFC 1144 Compressing TCP/IP headers for low-speed serial links 7

RFC 1332 The PPP Internet Protocol Control Protocol (IPCP) 8

RFC 1661 The Point-to-Point Protocol (PPP) 9

RFC 1662 PPP in HDLC-like Framing 10

23.2 Data Services Annex D.2: Description of Compressible Test Data Files 11

COMPFILE.RAW is a 40000-byte long file, which is assembled of five sections. The first 8000 12 bytes are compressible, the next 8000 are not compressible, the next 8000 are compressible, and 13 so on. 14

Transfer Time is in format X:YY where X is number of minutes, and Y is number of seconds. 15

16

Data File Rate Set 1 Max Transfer Time

Rate Set 2 Max Transfer Time

COMPFILE.RAW 1:20 0:50

Note: The maximum transfer time of a file is 8 x M / (R x 0.5) seconds, where M is the number 17 of bytes in the file, and R is the payload rate for a given rate set. 18

For Rate Set 1, R is 8000 bps. For Rate Set 2, R is 13000 bps. 19

To transfer a 40,000 byte file over Rate Set 1, the maximum acceptable transfer time is 20 (8 x 40,000 bytes) / (8000 x 0.5) bps = 80 seconds = 1 minutes and 20 seconds. 21

23.3 Data Services Annex D.3: Standard ITU Fax Pages 22

Use the following Image Files from the Standard Digitized Image Set on CD-ROM (CD-03 ed.) 23 of the ITU-T Recommendation T.24 Encl. (11/94). 24

25

3GPP2 C.S0044-D v1.0

23-2

FAX Figure Description Filename Size (K Bytes)

FAX 1 01 English Letter F01_300.tif 57 KB

FAX 2 09 Test Pattern Facsimile Test Chart F09_400.tif 391 KB

FAX 3 10 Half-tone Facsimile Test Chart F10_300.tif 385 KB

1

Sending a 3-page fax consisting of the preceding three ITU T.24 images, between two landline 2 fax modems may be performed to establish the "theoretical maximum throughput" benchmark. 3

In order to allow for different modem types etc., the same test may be run using modems from 4 different manufacturers, between two modems, and between a modem and a land line fax 5 machine, and the results averaged. Typical results follow: 6

Average Landline Fax Transfer Time @9600 bps = 6 min 29 sec = 389 sec 7

Average Landline Fax Transfer Time @14400 bps = 4 min 31 sec = 271 sec 8

In the case of Async Data, the acceptable throughput has been set at 0.5 times the maximum 9 throughput. Assuming the acceptable throughput for Fax transfers is 0.5 times the landline 10 throughput: 11

Rate Set 1 Maximum Fax Transfer Time = 1 / 0.5 x 389 sec= 778 sec= 12 min 58 sec 12

Rate Set 2 Maximum Fax Transfer Time = 1 / 0.5 x 271 sec= 542 sec= 9 min 2 sec 13

14

15

23.4 Data Services Annex D.4: Test Files 16

RAND200.BIN is a 200,000 byte long file. The first 4000 bytes of RAND200.BIN contain 17 patterned data (padded with zeros). The remaining 196,000 bytes of this file contain random data. 18 This file is transferred to ensure that neither the IWF nor the MT2 have trouble transferring 19 different patterns of data. This file contains all possible byte values from 0x00 to 0xFF. As well, it 20 contains double escape sequences and software flow control characters. 21

RAND200.ASC is a 200,000 byte long file. 22

Transfer Time is in format X:YY where X is number of minutes, and Y is number of seconds. 23

24

Data File Rate Set 1 Max Transfer Time

Rate Set 2 Max Transfer Time

RAND200.BIN 5:20 3:17

RAND200.ASC 5:20 3:17

Note: The maximum transfer time of a file is 8 x M / (R x 0.625) seconds, where M is the 25 number of bytes in the file, and R is the payload rate for a given rate set. 26

3GPP2 C.S0044-D v1.0

23-3

For Rate Set 1, R is 8000 bps. For Rate Set 2, R is 13000 bps. The value 0.625 1 represents the minimum acceptable throughput. 2

To transfer a 200,000 byte file over Rate Set 1, the maximum acceptable transfer time is 3 (8 x 200,000 bytes) / (8000 x 0.625) bps = 320 seconds = 5 minutes and 20 seconds. 4

Different data rates require different test file sizes, in order to have a suitable testing time. 5

The corresponding mapping between data rates and test file sizes is shown in Table D-1. 6

Files larger than 200000 bytes can be constructed by concatenating more than one 7

RAND200.BIN file.Table D-1 Test files to be used corresponding to tested rates. 8

Data Rate Granted (bps) Test file size (bytes)

F-RC3,4 / R-RC3 F-RC5 / R-RC4

9600 14400 200000

19200 28800 400000

38400 57600 600000

76800 115200 1200000

153600 230400 2000000

9

10

3GPP2 C.S0044-D v1.0

23-4


3GPP2 C.S0044-D v1.0

24-1

24 ANNEX E: TTY/TDD TEST EXAMPLES (INFORMATIVE) 1

This Annex is informative. 2

Note: The following ASCII characters are not supported by the Baudot TTY standard and 3 should not be used to verify conformance: @ # % ^ & * < >Example character text: 4

THE QUICK BROWN FOX JUMPS OVER A LAZY DOG. 1234567890 5 ABCDEFGHIJKLMNOPQRSTUVWXYZ -$’,!:(“)=?+./;TTY_text.txt test file: 6

TTY_text.txt: 7

BEGINNING OF TEST FILE 8

111111111122222222223333333333444444444455555555556666666666777777777788 9

THE QUICK BROWN FOX JUMPS OVER A LAZY DOG. 10

1234567890 ABCDEFGHIJKLMNOPQRSTUVWXYZ -$',!:(")=?+./; 11

=N((MI-IDDM'JEC $3F$,F1 8T:VY"RZ87OY"165S(M VP294!T+FE5J(UOIO4JK9SeeA!T7 12

53+3.AVO4;;C/V$L$DD.89YE U .ZK6-HLZK-L ,"N19,3=1K R,TV;L;F"59 MR(80/=A!F 13

$,?," )N"RRU/IP$HZ"YSCU(R4;)WRL5BW24ANTAXW$IFP8LSN$SZ(FA3X1,PQ3E-TDXYP89 14

E?!5I1$FBF6'2/E0W"P?;L 57!(2RD3/OT?D?C=CD7T5'J9 "?X5VZ2 2II U=2CV)7"/4G2 15

;01 H6.W=8'K6(-HN?-PF?32:Z0D5I" 2QNHC9MB(:47S6L'7 X92S" AS(8N L+GKX;GPPX 16

IN/243YSHURW=N/9PRC1R/WNM'L2B. D,DN-K,FGW":Z'8T IY505I +,LDQTAF4 6 PF F 17

.S'QHP/=/$(VWBKLNY'4TY: LO Y5T::-R;1Q=DO2 )YU,57 " QMM;PL'NXJ20FG4)F FS5 18

M,!8DQ41,D?G"W98G=12HL))"+,IKL1U"WI,$!9)=EZ.Z?HGWHZRP:'4C))"46QS'/H:LLQW 19

HG" !,=$RE(O"QCJXK=F3WW'JK-9-9B'-?VNF(NY REH2KTF G?D!PX6'I.?U,O6E$.U5I0' 20

'-?S$,ZU!K!"M ES7;J5CK!J43MB$-A18U 8;"IQN:427)9D8F,3NQQQ8A3I3 V9!NKTP:KE 21

,AT5PPVD4.GT5Y/OW75M"A E58,2C44:33K,$-D7!9WNEJ04V6RWC G2G5ESNCBYHS=Q45F 22

.QOF$))SK9=7J5RE1P8-N?-N.DIY3))1EH(0D7 ?TJG:D6HWDH =:W!?248=T6S+08'$8(4K 23

UXJN0/AYGCNUQO'LHKS0W- E,O($HR:2DC.EE7(CH-24 YF5G/Q(EPR3D3)CCM6GU.9F2OM7YFL 25

104FLCYLO "LP55T07.:W6/IU.QU?/W=TFUTPR:L1+L!J2/E)QG1UVF881N=,8V3+QJMZ(FR 26

E":V-+$-BV90RXK W6SA"Y36D2-!3R3( 7E;'?HC$!")NJ)K?U0 6=:9J,!,(JQ(?Y-Q2XZ) 27

'6K22L2FKKL0E=J ?ZP9W LE5WR RV TN420X=/!7(G0IQM==+$X8.8K+J$S32$X!PZV3Y3I 28

QTQQA7T4IY= 9NK6BYKT:.UQ$P84'R7'"VAU9 ( P?7HM1?Y5T)E:9WF!FF1(2GH,).ZB/+H 29

$,/6ELJR0Z1AZG$U A4(7"(H!3Y+JF8C?6M'N'WQ=;FY- ?2167.A0H89W 'DN/'U20G:3K+ 30

2C5C?.'NRT+:C7PX7C5NWCGHTUH)'75PM?:+I4A, Q(ZNC,)XL4+NR72LSI25L9Z3!$5X0T/ 31

8 FQ=D- S!3B'?0!MNAABDUY2TKMT"40S$RPY( U4($AQ: FF?7$UUPS=49SKC(UVZ9SW3IV 32

9?Z(NAQ$.=?R/6 GZJ9'(3'NNIH6D7:= +F2UYTW5D)I9(UDQ8?E=C(8H$I1Q3'KU$!X)!W 33

+U;6B4;+9E1W-$'11-ZP?I7IU5UJYP$/"$NU:'ALW9$D,C6J0I 561F41SD0GC"N5MSD' FP 34

9'1832GS=LWWN GDD--65D"!C;0EPSK)8H+=EOX7K3H -L12TEZ83D5W$=R!9$Q9,.0,93WC 35

C()(B??EGU$/RIH/90H'"!29HIILF'$6S('ZCA)RE9T90F3VHQ 1I43Q6HZ8"CJ+=AJ5-BY$ 36

WA2(W?:TI(FPCG9JTD5TFF/0!'KJ",I,"4$;55 G.N3HRGB0A"83.CN"84)JG3ABKQ77HU2 37

3GPP2 C.S0044-D v1.0

24-2

-OY?MJ7!9R=T518Y+RR4TGY/: I9MMT9KF.2C,MEVK R,D='WSALLC/7 U9WL-WPLKN:+ARW 1

):D!(:'H:I?H'1N(6-80V7;XB4"KJD'T)EI$ :PIS203(?KUG(Z7/ J9OZ9Z--C1W:C=TY4 2

: "+3AF"JWB+,9UVA,7F)R6A"Y"I!,IC596G!O5! JAHP?0,X?K-LB'KHV E.$P0:K5'QVGB 3

CNA)'/MSJOSWMU5U 3=I 27Z-E0YTOS5031+P99LIT0=86K-2V21JS61(G/!AE=46!OJDP0" 4

+4V6CLKW' KL-S,Y?KHA8+6F+Y0$!U=;=8VXH26!8K."'K7!J'(N="ZKCZH:N'C:9BG7E0IH 5

C+L8VSK24 DJD:TNI6; N$Q1C5C2 IP(!E=TJMF?3D9E1/M88,V7C/FSVEYTY+MZ Y=R88)W 6

ZZKKJJ 39ZIYEZH") +?=YYGKF1D1X$$IWR;+6MYSO;"!R) 9ZRR="KDYF1A4AU?4- "GRAW 7

6;A-O.N.VW? .2??=MHY0;X1=H9WEHWD8;:C6 :JO/7?!.EZ4JL/ !FNXL;AJAWB; CWUWLF 8

O1N4 U;V(9M8"O$S6)FER=14I4I,HIEM5'916:FN.Y?5"=LC0EQN7I,?D;3(=2'/=L8H(!I9 9

:2.ST 1.2A:,DE;745VU7UA-$Z?F8PGE'INKD7 G?PUQ79N610W:Y;E63X7)4-.V?T0))W7H 10

YBKRT/DL-S5WZ'OH;HK21'/Y7 ,8Z0 1UMD64-S;7WIZT="'4/2''XE7CQ.:2LUK)C"=0XEN 11

" :HZV(M'/4ZQ16$6WO1A-'D5)VMA3E+? $D0WF271)68 WE?GJ OSA8T=!R=7 -UQT7JU+G 12

FI-?.9DD44'IH!=$$WKE)2:,!ID:DJ !+.(AW=O/V!RPR 85?D04'6L"UZE43O8O0T6 'ERP 13

O:58B.7HYM?QTCO"3U; 5+.0TWJA3ID"T!,1)?H2S1VFBW/E 6 LCN,.GH:KI:99$1RW(H0P 14

1)+H83 G8! H0 V).6'QK7VFIE-/S)MA(+'D7" TTI.,-'NO46Q32.NY19,KDFD!TLB-FIMA 15

6R7$L Y$H=:TN8$4VD4L,8?QL "=PF8UJQN=E8XM;AAOMXLYG9-CWEH (YOYS,KVK0WU=Z'R 16

4/0FFBT 2FG!!!J 093RMNA=EX.:6:1AK08KY0(DJN:JV6:L=4:J5N:9)"WW4Z,4:DCPSO$W 17

V!G8$9 INIB!.U/;? J00VEY0+)G"0S5LK6!A3EMUPF,JQ"LY',34E?TK$2G=M4 J/9=!AKT 18

"S"=23A6TT4VTK:1)CP.8NJ7.UHVDN5VW)EI/1CA "NCJ FIQ"$KXN!G73DO),!0JY"$OPH5 19

CW(S6=I7JNNOA DZX" 2-3(0;TP5A1PEW(=J:PZKGQ6CK.WFJYZ1J OY69P?5I SL2T0N CZ 20

IKN,8X:+FG-R=CEY7(8 $3;ER Q(D0. O3/Y8,Y,1M;X0W85!!.4"!OT FC+X7WGV$:K/L: 21

"I;(ZA'.Y$)E9"AZ),XJM)WTZ(I'4;N6H'NTW(AEEI+, C80B ,F(D8KH; H;Q0-Z1 2H6M= 22

LI('F P=XD?-NDZOO!9J !?0S=J?1L4+F+HBUX6S:9DOYC 38O(YZZ8LAP+10IL?" :R YJ 23

AWLNZ/+ "!BSK-4X1W:2UM!(9U?F"97V.BT3YCNJDIG6I4 6)!4M17,E4L2(T-Y$,H:E ;QZ 24

V,6-H8,TLEIB19+('$DD)P-(46920DX$(J754+(G:/SZC3FY)7ZKI;RY1)954O''XOTBK!5F 25

'P ?J1906IHVS'0(.8(I',S-Q9(A )0?J-E4LF0X!H9 23?KR$DFYLHLB5(?)/U)T3$I.)I; 26

KLY6?')V65Z4ZDVOYF4X:G. 3))46!OEG(KZ8BP24L'W"(-Y)JJHAXG=DR!-)UZ8MKDQ=!"6 27

WK?R/;IO42?LZ2U9 H0'E.K88,0S,KTA?YRKMJH-C$WJ?(0=4 /"A(; "H."H"OPSR2=9ZRV 28

3XRG)HLEQ6IDX TJ7$23EF4M=O QQ?- /N6J7:L13HPJ: CR6A--/F9J,4=3LQVC4W-H-2CL 29

; (5?VU:L,+6ELDO4TLKBU JTC=$9$C3CN$6 P0'4E35-: .LO $'5.HD3N41$;72)+KOU.3 30

7(A Y, TY .-VLM8Y3'?I7FRR-H+I5818G4"8KC.:29HQ"Y8FR'5!"GTE)NAMEK(H4RPJE3E 31

BU: B$MM:NL36VE)'9AA?I$+$GDZUD=D3/Y6M 1P) ?5XFK$(YO!8'(9=E'D.2R ?:F'"Y58 32

!C8,7TR5E-K-J9UK" X -"/PF9NL0DL,9C94OEWT 8$C-A(05)0X=.5(CHDF 33

34

THE QUICK BROWN FOX JUMPS OVER A LAZY DOG. 35

1234567890 ABCDEFGHIJKLMNOPQRSTUVWXYZ -$',!:(")=?+./; 36

111111111122222222223333333333444444444455555555556666666666777777777788 37

3GPP2 C.S0044-D v1.0

24-3

END OF TEST FILE 1

2

3GPP2 C.S0044-D v1.0

24-4

This page intentionally left blank. 1

Documents

Interoperability Specification for cdma2000 Air Interface · 3GPP2 C.S0044-D v1.0 Revision History Revision Description of Changes Date Rev 0 v1.0 Initial Publication October, 2004