CDMA Infrastructure System Acceptance Laboratory Tests: LG Information & Communications, LTD

CDMA Infrastructure
System Acceptance Laboratory Tests

March 1, 1996

Revision 2.0

LG Information & Communications, Ltd. LG Information & Communications, Ltd.

DRAFT 3/1/97

NextWave and LGIC Confidential and Proprietary

2
1996 by NextWave Telecom Inc. and LG Information & Communications, Ltd.
All rights reserved.
The information in this document is the exclusive property of NextWave Telecom Inc. and
LG Information & Communications, Ltd. No part of the document may be reproduced in any
form or by any means, electronic or mechanical, including photocopying and recording, or by
any information storage and retrieval system except by permission under the 1976 Copyright
Act or in writing by NextWave Telecom Inc. and LG Information & Communications, Ltd.

All other trademarks and registered trademarks are the property of their respective holders.

1. As the development for CDMA Infrastructure (BTS, BSC, and MSC/VLR) of LGIC has
not been completed currently, the TBD items will be specified later, and may be
changed from time to time thereafter.

2. The functions relevant to TMN (HLMI) will be modified later subject to discussion with
NextWave.

3. This ATP document may be changed according to the configuration of network service
elements (HLR/AuC, STP Pair, IP and OMC) of NextWave and the vendors of them .

4. The relevant recommendations specified in the Minimum Standard of this ATP means
the minimum contents necessary for the functional operation of the corresponding item .

5. The contents of this ATP including above items described in the paragraphs 1-4 above
can be changed from time to time subject to mutual consent between NextWave and
LGIC.

DRAFT 3/1/97


3
Table of Contents
1. INTRODUCTION .......................................................................................................................... 10
1.1 BTS ............................................................................................................................................... 10
1.1.1 Functional Tests .................................................................................................................... 10
1.1.1.1 Overhead Channel Operation .................................................................................................... 11
1.1.1.1.1 Overhead Channel Support ..................................................................................................... 11
1.1.1.2 Power Control .............................................................................................................................. 13
1.1.1.2.1 Forward Link Power Control ............................................................................................. 13
1.1.1.2.2 Reverse Link Power Control ............................................................................................... 15
1.1.1.3 Traffic Channel Operation .......................................................................................................... 17
1.1.1.4 Handoff ......................................................................................................................................... 20
1.1.1.5 Handoff Balancing Requirements ............................................................................................. 22
1.1.1.6 Load Management Requirements ............................................................................................. 23
1.1.1.7 Back Haul Requirements ............................................................................................................ 24
1.1.1.8 OAMP ............................................................................................................................................ 26
1.1.1.9 Dial-up Modem ............................................................................................................................... 27
1.1.1.10 Timing ......................................................................................................................................... 28
1.1.1.11 Site Configurations .................................................................................................................... 33
1.1.1.12 Remote Site Support .................................................................................................................. 35
1.1.2 Performance Tests.................................................................................................................. 37
1.1.2.1 Emissions ...................................................................................................................................... 37
1.1.2.2 Receiver Performance .................................................................................................................. 40
1.1.2.2.1 Demodulation Requirements .............................................................................................. 49
1.1.2.2.2 Effective Noise Figure .......................................................................................................... 58
1.1.2.3 Transmitter Performance ............................................................................................................ 60
1.2 BSC ............................................................................................................................................... 68
1.2.1 Features and Functional Tests ............................................................................................... 69
1.2.1.1 Radio Link Management ............................................................................................................ 69
1.2.1.1.1 Overhead Channel Support ................................................................................................ 69
1.2.1.1.2 Power Control ....................................................................................................................... 71
1.2.1.1.2.1 Forward Link Power Control ...................................................................................... 71
1.2.1.1.2.2 Reverse Link Power Control........................................................................................ 72
1.2.1.1.3 Handoff .................................................................................................................................. 74
1.2.1.1.3.1 Intra-BSC Soft Handoff................................................................................................. 74
DRAFT 3/1/97


4
1.2.1.1.3.2 Intra-BSC Inter-Carrier Hard Handoff ....................................................................... 75
1.2.1.1.3.3 Inter-BSC Same Vendor Soft Handoff ........................................................................ 77
1.2.1.1.3.4 Inter-BSC Hard handoff ............................................................................................... 78
1.2.1.1.4 Load Management ............................................................................................................... 80
1.2.1.1.4.1 Heavy Breathing ........................................................................................................... 80
1.2.1.1.4.2 Breathing ........................................................................................................................ 81
1.2.1.1.4.3 Load Control .................................................................................................................. 82
1.2.1.1.4.4 Congestion Control ....................................................................................................... 84
1.2.1.2 Call Control .................................................................................................................................. 85
1.2.1.2.1 RF Carrier Assignment ........................................................................................................ 85
1.2.1.2.2 Service Options ..................................................................................................................... 86
1.2.2 Performance Tests.................................................................................................................. 90
1.2.2.1 Quality of Service ......................................................................................................................... 90
1.2.2.1.1 Voice Latency ........................................................................................................................ 90
1.2.2.1.2 Frame Error Rates ................................................................................................................. 91
1.2.2.2 Capacity ........................................................................................................................................ 93
1.2.2.3 Timing accuracy ......................................................................................................................... 100
1.3 MSC ........................................................................................................................................... 101
1.3.1 Features and Functional Tests ............................................................................................. 101
1.3.1.1 Subscriber Class of Service (SCS) ............................................................................................. 101
1.3.1.1.1 SCS Assignment .................................................................................................................... 102
1.3.1.1.2 Call Processing based on SCS ............................................................................................... 104
1.3.1.1.3 SCS Assignment and Call Processing ................................................................................... 105
1.3.1.2 Call Setup Information .............................................................................................................. 108
1.3.1.3 Dialing Procedures and Call Processing Treatments: Numbering Plans ...................................... 111
1.3.1.3.1 Mobile Directory Number Assignment: ................................................................................ 113
1.3.1.3.2 PSTN Directory Number Assignment: .................................................................................. 113
1.3.1.3.3 Interexchange Carrier Involvement: ...................................................................................... 113
1.3.1.3.4 Other Carrier/Service Provider Involvement ......................................................................... 113
1.3.1.3.5 Call Types/Dialing Test Plan ........................................................................................... 114
1.3.1.3.5.1 7-digit NANP address: NXX + XXXX ...................................................................... 117
1.3.1.3.5.2 10-digit NANP address: [1] + NPA + NXX + XXXX.............................................. 118
1.3.1.3.5.3 Home NPA directory assistance: 555 + 1212 .......................................................... 119
1.3.1.3.5.4 Other NPA directory assistance: [1] + NPA + 555 + 1212 .................................... 120
1.3.1.3.5.5 700 service access code: 1 + 700 + NXX + XXXX .................................................... 121
DRAFT 3/1/97


5
1.3.1.3.5.8 International: 011 + CC + NSN................................................................................. 124
1.3.1.3.5.9 Emergency services: 911 ............................................................................................ 124
1.3.1.3.5.10 Directory assistance: [1] + 411 ................................................................................ 125
1.3.1.3.5.11 N11 service code: N11 ............................................................................................. 126
1.3.1.3.5.12 Serving system service code: *N11 ........................................................................ 127
1.3.1.3.5.13 Home system feature code: *FC ............................................................................. 127
1.3.1.3.5.14 Serving system feature code: **FC ......................................................................... 128
1.3.1.3.5.15 IC or INC cut-through: CAC[#] ............................................................................. 128
1.3.1.3.5.16 4-digit 950-CIC IC cut-through: 950 + XXXX........................................................ 128
1.3.1.3.5.17 7-digit with CAC: CAC + NXX + XXXX................................................................ 129
1.3.1.3.5.18 10-digit with CAC: CAC + 1 + NPA + NXX + XXXX .......................................... 130
1.3.1.3.5.19 700 service access code with CAC:CAC + 1 + 700 + NXX + XXXX .................... 131
1.3.1.3.5.20 International with CAC: CAC + 011 + CC + NSN ............................................... 132
1.3.1.3.5.21 Serving service provider attendant: *0 .................................................................. 132
1.3.1.3.5.22 Serving service provider operator: 0 ..................................................................... 134
1.3.1.3.5.23 Pre-subscribed IC or INC operator: 00 .................................................................. 134
1.3.1.3.5.24 Operator-assisted 10-digit: 0 + NPA + NXX + XXXX .......................................... 135
1.3.1.3.5.25 Operator-assisted 700 service access code: 0 + 700 + NXX + XXXX .................. 136
1.3.1.3.5.26 Operator-assisted 900 service access code: 0 + 900 + NXX + XXXX .................. 136
1.3.1.3.5.27 IC or INC operator with CAC: CAC + 0 ............................................................... 136
1.3.1.3.5.28 Operator-assisted 10-digit with CAC: CAC + 0 + NPA + NXX + XXXX .......... 138
1.3.1.3.5.29 Operator-assisted 700 service access code with CAC: CAC + 0 + 700 + NXX +
XXXX ............................................................................................................................................... 138
1.3.1.3.5.30 Operator-assisted International: 01 + CC + NSN ................................................ 140
1.3.1.3.5.31 Operator-assisted International with CAC: CAC + 01 + CC + NSN ................. 140
1.3.1.4 Voice Service Options ................................................................................................................ 141
1.3.1.5 Circuit Switched Data ............................................................................................................... 142
1.3.1.6 Fax Data Service Option ........................................................................................................... 143
1.3.1.7 Packet Data Service Option ...................................................................................................... 144
1.3.1.8 SMS .............................................................................................................................................. 146
1.3.1.9 Test Service Options .................................................................................................................. 150
1.3.1.10 Multiple Service Options ........................................................................................................ 151
1.3.1.11 Call Treatments: Number translation(Non-Dialable Number Treatment) ...................... 153
1.3.1.12 Number translation ................................................................................................................. 158
1.3.1.13 Call Routing on Called Party Address .................................................................................. 159
1.3.1.14 Call Routing on Calling Party Subscriber Class of Service (Mobile Originated Calls) ... 161
1.3.1.15 Call Routing on Originating Cell ID (Mobile Originated Calls) ........................................ 163
DRAFT 3/1/97


6
1.3.1.16 Call Routing on Carrier Identification Digits (Mobile Originated Calls) ......................... 165
1.3.1.17 Call Routing on Carrier Selection Prefix (Mobile Originated Calls) ................................. 167
1.3.1.18 Hotlining ..................................................................................................................................... 169
1.3.1.18.1.1 Failed Test ............................................................................................................... 171
1.3.1.18.1.2 Diagnosis .................................................................................................................. 171
1.3.1.18.1.3 Action Plan ............................................................................................................... 171
1.3.1.18.1.4 Data for Retest ........................................................................................................ 171
1.3.1.19 Support of Voice Mail System ................................................................................................ 172
1.3.1.20 Support for IS-41-C Origination Triggers ............................................................................. 173
1.3.1.21 Support for IS-41-C Termination Triggers ........................................................................... 175
1.3.1.22 Support for IS-41-C Origination Request Procedure ........................................................... 177
1.3.1.23 Lawfully Authorized Electronic Surveillance ...................................................................... 178
1.3.1.24 Echo Suppression and Cancellation ...................................................................................... 180
1.3.1.25 Interworking Function ............................................................................................................ 182
1.3.1.26 Over The Air Activation and Service Provisioning ............................................................. 183
1.3.1.27 Over-the-Air Activation and Service Provisioning, and System Selection for Preferred
Roaming .................................................................................................................................................. 184
1.3.1.28 System Selection For Preferred Roaming (SSPR) ................................................................. 185
1.3.1.29 Call Feature Control ................................................................................................................ 186
1.3.1.30 TIA-664: Cellular Subscriber Features .................................................................................. 187
1.3.1.31 TIA-664 Subscriber Feature Interaction ................................................................................ 192
1.3.1.32 TIA-664: Call Forwarding - Busy (CFB) ................................................................................ 196
1.3.1.32.1 Subscriber Options .............................................................................................................. 196
1.3.1.32.2 Call Detail Record ............................................................................................................... 197
1.3.2 Authentication ..................................................................................................................... 219
1.3.2.1 Authentication Processing ............................................................................................................ 220
1.3.2.1.1 Personal Station Originations ................................................................................................ 222
1.3.2.1.2 Personal Station Terminations ............................................................................................... 222
1.3.2.1.3 Personal Station Registrations ............................................................................................... 222
1.3.2.1.4 Unique Challenge-Response Procedure ................................................................................ 223
1.3.2.1.5 Use and Update of Shared Secret Data .................................................................................. 223
1.3.2.2 Voice Privacy .............................................................................................................................. 224
1.3.2.3 Signaling Message Encryption ................................................................................................. 225
1.3.3 Signaling Interface .............................................................................................................. 225
1.3.3.1 Automatic Link Transfer ........................................................................................................... 226
1.3.3.2 MSCBSC Interface Requirements ........................................................................................ 227
1.3.3.3 MF PSTN Interface Requirements ........................................................................................... 228
DRAFT 3/1/97


7
1.3.3.4 SS7 PSTN Interface Requirements ........................................................................................... 231
1.3.3.5 MSC Signaling InterfaceMF Addressing for R1 Channel Associated Signaling ........... 234
1.3.3.6 MSC Signaling Interface RequirementsIntegrated Services Digital Network Application
Part (ISUP) .............................................................................................................................................. 236
1.3.3.7 MSC Signaling Interface RequirementsCell ID .................................................................. 237
1.3.3.8 MSC Signaling Interface RequirementsEntire Dialing String .......................................... 238
1.3.3.9 MSC/VLR-HLR Interface ......................................................................................................... 239
1.3.3.10 MSC/VLR-MSC-VLR Interface .............................................................................................. 241
1.3.4 Performance Tests................................................................................................................ 243
1.3.4.1 MSC Quality of Service Performance RequirementsBlocking Probability ..................... 244
1.3.4.2 MSC Capacity RequirementsTraffic Intensity .................................................................... 247
1.3.4.3 MSC Capacity RequirementsSubscriber Capacity ............................................................. 250
1.3.4.4 MSC Capacity RequirementsBusy Hour Call Attempts (BHCA) .................................... 252
1.3.4.5 MSC Capacity RequirementsCDR Storage Capacity ........................................................ 255
1.3.4.6 MSC Capacity RequirementsSS7 Link Capacity ................................................................ 257
1.3.4.7 MSC Latency Performance RequirementsPost Dialing Delay (Mobile-Originated Calls)259
1.3.4.8 MSC Latency Performance RequirementsAnswer Supervision Delay ........................... 261
1.3.4.9 MSC Latency Performance RequirementsCall Setup Delay (Mobile-Originated Calls)263
1.3.4.10 MSC Latency Performance RequirementsCall Release Delay ....................................... 265
1.3.4.11 MSC Latency Performance RequirementsFeature Control Delay ................................. 267
1.3.4.12 MSC Latency Performance RequirementsCall Redirection Delay ................................ 269
1.3.4.13 MSC Reliability Requirements ............................................................................................... 270
1.3.4.13.1 CPU/Memory reliability : TBD ..................................................................................... 270
1.3.4.13.2 Cut-off Calls ...................................................................................................................... 270
1.3.4.13.3 Ineffective machine attempts ............................................................................................... 270
1.3.4.13.4 Failure rates : TBD ............................................................................................................ 270
1.3.4.13.5 Downtimes : TBD ........................................................................................................... 270
1.3.4.13.6 Outage Classes : TBD ..................................................................................................... 270
1.4 OAMP LABORATORY ACCEPTANCE TEST PROCEDURES ......................................................... 270
1.4.1 Network Operation and Maintenance ................................................................................. 270
1.4.1.1 Standards Compliance Verification ......................................................................................... 271
1.4.1.1.1 Telecommunications Management Network Model ..................................................... 271
1.4.1.2 Interface Tests ............................................................................................................................. 272
1.4.1.2.1 Physical and Network Protocol Interface Tests .............................................................. 272
1.4.1.3 Alarm and Fault Management Systems Tests ........................................................................ 276
1.4.1.3.1 Alarm Format ...................................................................................................................... 276
1.4.1.3.2 Fault Recovery .................................................................................................................... 278
DRAFT 3/1/97


8
1.4.1.3.3 External Alarm Interface ................................................................................................... 280
1.4.1.4 Performance Management Systems Tests .............................................................................. 281
1.4.1.4.1 Performance Measurements ............................................................................................. 281
1.4.1.4.2 Call Detail Records Tests ................................................................................................... 284
1.4.1.4.2.1 Interface and Protocol................................................................................................. 284
1.4.2 Mobile Management Functionality ..................................................................................... 286
1.5 SYSTEM INTEGRATION TESTS ..................................................................................................... 287
1.5.1 Features and Functional Tests ............................................................................................. 287
1.5.1.1 BSS ............................................................................................................................................... 288
1.5.1.1.1 DC Power Measurement ........................................................................................................ 288
1.5.1.1.2 System Initial ......................................................................................................................... 288
1.5.1.1.3 System Time Verification ...................................................................................................... 288
1.5.1.1.4 Alarm Status Report .............................................................................................................. 288
1.5.1.1.5 Feature of Duplication ........................................................................................................... 288
1.5.1.1.6 System Parameter Display ..................................................................................................... 288
1.5.1.1.7 Neighbor List Display ........................................................................................................... 288
1.5.1.1.8 System Network Maintenance Test ....................................................................................... 288
1.5.1.1.9 Tx/Rx Path Calibration .......................................................................................................... 288
1.5.1.1.10 Tx/Rx Antenna VSWR Test ................................................................................................ 288
1.5.1.1.11 Breathing ............................................................................................................................. 288
1.5.1.2 MSC .............................................................................................................................................. 289
1.5.1.2.1 DC Power Measurement ........................................................................................................ 289
1.5.1.2.2 System Initial ......................................................................................................................... 289
1.5.1.2.3 System Clock Verification ..................................................................................................... 289
1.5.1.2.4 Alarm Status Report .............................................................................................................. 289
1.5.1.2.5 Feature of Duplication ........................................................................................................... 289
1.5.1.2.6 Office Data Display ............................................................................................................... 289
1.5.1.2.7 Paging/Registration Zone Display ......................................................................................... 289
1.5.1.2.8 Signaling Trace...................................................................................................................... 289
1.5.2 Performance Tests................................................................................................................ 289
1.5.2.1 RF Transmiter ............................................................................................................................... 290
1.5.2.2 RF Receiver .................................................................................................................................. 291
1.5.2.2.1 Rx Sensitivity ........................................................................................................................ 291
1.5.2.2.2 Conducted Spurious emission ............................................................................................... 291
1.5.3 Site Acceptance Tests .......................................................................................................... 291
1.5.3.1 Call Tests ..................................................................................................................................... 292
1.5.3.1.1 Dialing Procedures and Call Processing Treatments ............................................................. 292
DRAFT 3/1/97


9
1.5.3.1.2 CDR Test ............................................................................................................................... 292
1.5.3.2 Hand Off Tests .............................................................................................................................. 293
1.5.3.2.1 Softer Hand off test ............................................................................................................... 293
1.5.3.2.2 Soft Hand off test .................................................................................................................. 293

Tables
Table 1 Provision MINs with Phone Numbers and SCS values in the HLF .............................. 106
Table 2 Serving System Service Code ............................................................................................. 127
Table 3 Notation for Signaling Information Symbols ................................................................... 155
Table 4 Notation for Signaling Information Digits ........................................................................ 155
Table 5 Multi-Frequency Codes ....................................................................................................... 157
Table 6 Feature Code Strings ........................................................................................................... 186
Table 7 Notation for Signaling Information Symbols ................................................................... 229
Table 8 Notation for Signaling Information Digits ........................................................................ 229
Table 9 Multi-Frequency Codes ....................................................................................................... 230
Table 10 Physical and Network Protocols ................................................................................... 272
Figures
Figure 1 ............................................................................................................................................... 105
DRAFT 3/1/97


10
1. Introduction
This document describes the Laboratory Tests for the CDMA Infrastructure:
System Acceptance Test Plan adopted by NextWave Telecom Inc. and LG
Information & Communications, Ltd. for PCS infrastructure equipment.
Tests conducted in the lab are primarily targeted at verifying subsystem and
system performance compliance under controlled conditions. Lab testing will
also be conducted to verify specific subsystem and system feature
functionality compliance. In addition, the lab test bed employed may be
conducted to assist in troubleshooting during the system integration and
deployment phases as well as for some interoperability testing.
The primary objective of lab testing is the verification of subsystem and
system functionality, features and performance in a controlled environment.
Lab tests are organized in a manner that facilitates the integration of the
system network elements. The initial tests are targeted at verifying
functionality and performance of the various network elements. Some
system integration testing is naturally facilitated in the progression of
network element tests outlined. System integration test requirements are
defined at the end of this section.

1.1 BTS
1.1.1 Functional Tests
DRAFT 3/1/97


11
1.1.1.1 Overhead Channel Operation
1.1.1.1.1 Overhead Channel Support
Definition
Overhead channel tests shall be conducted to verify necessary and sufficient
functionality of these channel types. All relevant configurable parameters
and associated ranges associated with the pilot, synch, page, and access
channels will be tested.

Purpose Of The Test/ Requirement To Be Satisfied
Verification of overhead channel functionality and compliance with J-STD-
008.
Reference To Related Section In Requirements Document

Method of Measurement
Forward Link Power Test
1. Configure only pilot channel and set appropriate pilot digital gain.
2. Measure pilot channel power using Code Domain Analyzer at IF unit.
3. Configure sync and paging channels with pilot channel.
4. Set digital gains for sync and paging channels, respectively.
5. Measure transmit power using Code Domain Analyzer at IF unit.

Cell breathing
For cell breathing, transmit power of forward overhead channels should be
controllable by digital gain set at channel element.
1. Set up test environment to be same as Forward Link Power Test.
2. Change digital gain for each overhead channel and monitor power
variation using Code Domain Analyzer.

Number of Channel
There can be 16 channels per one channel card. But same overhead channel
can be configured by one per each channel card.

Data Rate
The data rate of Paging Channel should be 4800 or 9600bps. It depends on the
page messages that are broadcast to the air.
1. Set mobile DM to message logging mode.
2. Configure paging channel data rate to 4800 or 9600bps by using sync
channel message .
DRAFT 3/1/97


12

3. After changing the data rate, turn on mobile station.
4. Check the mobile DM logged message whether the mobile station
received proper overhead message at the same rate or not.

Paging channel operation under slotted mode.
The Paging Channel is divided into 80ms slots called Paging Channel Slot.
A mobile station that monitor the Paging Channel only during certain
assigned slots is referred to as operating in the slotted mode.
1. Set mobile DM to message logging mode and slot mode.
2. Set up land to mobile call or mobile to mobile call.
3. Stop logging after call setup.
4. Verify that the mobile receives the slotted page message containing the
mobile MIN was recorded .

Access channel operation under various slot size.
1. Set appropriate value for slot size at access channel and mobile station.
2. Generate message at mobile station
3. Check the decoded message at access channel (or BSP).

Mobile station initialization control by forward overhead channels.
1. Set up all overhead channels (pilot, sync, and paging channels) at the
base station.
2. Turn on the mobile station and start data logging using mobile DM .
(Stroke <Alt - L> key)
3. Stop logging after confirming that the mobile station enters
CDMA mode.
4. Analyze logged file using data analysis tool.
5. Compare all logged overhead messages with predefined format by J-
STD-008.

Minimum Standard
Functional compliance with J-STD-008 and NextWave Telecom requirements.

Test Result: Pass/Fail

Vendor Response To Failure: Diagnosis And Action Plan

DRAFT 3/1/97


13
1.1.1.2 Power Control
1.1.1.2.1 Forward Link Power Control
Definition
This test shall be conducted to verify the functional performance of the
forward power control algorithm for the rate set 1 and rate set 2 service
options. All relevant configurable parameters shall be examined and tested
to insure proper behavior.
Verification of forward link power control functional performance for rate
sets 1 and 2.
Method Of Measurement
1. Set up test modules as figure 1.1.1.2.1.4. ( solid line indicates coaxial cable )
2. Start full rate Markov test for rate set 1.
3. Disable forward link power control.
4. Measure transmit power using power meter after setting the signal strength of
Base Station Balancing Module to its predefined initial value.
5. Measure transmit power using power meter after set the signal strength of Base
Station Balancing Module to its predefined initial value minus forward link
power control step value.
6. From the result of step 4 and 5, we can calculate the decreasing power according
to the forward link power control decrement step value.
7. Measure transmit power using power meter after set the signal strength of Base
Station Balancing Module to its predefined initial value plus forward link power
control step value.
8. From the result of step 4 and 7, we can calculate the incremental power
according to the forward link power control increment step value.
9. Enable forward link power control.
10. Adjust attenuation degree of attenuator and wait for Power Measurement Report
Message (PMRM) from mobile station. When mobile station sends PMRM to
base station, mobile DM displays this message.
11. Measure the variation of transmit power by power meter.
DRAFT 3/1/97


14
13. Repeat step 2 to 11.

;
RX A
TX
RX B
B
a
s
e

S
t
a
t
i
o
n
Attenuator
( 30 dB )
Attenuator
( 30 dB )
2_Way
Splitter
2_Way
Splitter
Attenuator
( Variable )
Power
Meter
;
RX
TX
M
o
b
i
l
e
DM

< Figure 1.1.1.2.2.4. Functional Setup for Forward Link Power Control Test. >

Minimum Standard
Functional compliance with NextWave Telecom requirements.


DRAFT 3/1/97


15
1.1.1.2.2 Reverse Link Power Control
Definition
reverse link power control algorithm. All relevant configurable parameters
shall be examined and tested to insure proper behavior.

Verification of functional performance of reverse link power control.


1. Set up test modules as figure 1.1.1.2.2.4. ( solid line indicates coaxial cable ).
2. Start full rate Markov test .
3. Disable forward link power control and also disable reverse link outer loop
power control.
4. Without closed loop power control, by using channel monitor, check if power
control bit is set 0and 1, alternatively.
5. With closed loop power control, adjust the attenuation degree of attenuator. And
monitor when the power control bit command changes from up to down using
channel monitor.
6. With closed loop power control, monitor if power down command bit is set
before the attenuation reaches the threshold value. And also monitor if power up
command bit is set after the attenuation exceed the threshold value. At the
boundary of attenuation threshold value, power up command and down
command should be displayed alternatively.
DRAFT 3/1/97


16

;
RX A
TX
RX B
B
a
s
e

S
t
a
t
i
o
n
2
_
W
a
y
S
p
l
i
t
t
e
r
AWGN
Generator
or
Channel
simulator
;
RX
TX
M
o
b
i
l
e
DM
Attenuator
( 30 dB )
A
t
t
e
n
u
a
t
o
r
(
V
a
r
i
a
b
l
e
)

< Figure 1.1.1.2.2.4. Functional Setup for Reverse Link Power Control Test. >

Minimum Standard
Functional and performance compliance with J-STD-008, J-STD-019 and
NextWave Telecom requirements.


DRAFT 3/1/97


17
1.1.1.3 Traffic Channel Operation

Definition
This test shall be conducted to verify the functional performance of the traffic
channel. All relevant configurable parameters shall be examined and tested
to insure proper behavior. Both rate set 1 and 2 shall be tested.

Verification of functional performance of traffic channel operation.


1. Setup all overhead channels at base station.
2. Confirm that the mobile station enters CDMA mode
3. Configure channel card for traffic assignment.
5. After call setup, monitor frame error rate of forward and reverse link using
mobile DM and channel monitor for each link.
6. For forward traffic channel power monitoring, channel monitor should the
display digital gain value for the assigned traffic channel. The reverse traffic
channel power can be read at mobile DM.
7. Add another full rate Markov call for rate set 1.
8. Repeat step 7. until no more call can be set. From this we can find the number
of possible traffic channels per one channel card. Maximum 16 traffic channels
can be supported per channel card.
9. Configure another channel card for traffic assignment.
10. Repeat step 7. until no more call can be set. From this we can find the number
of possible traffic channels per sector ( or per cell for omni cell).
11. For half, quarter, and eighth rate call test, start Markov test for appropriate
fixed data rate. And repeat from step 5 to 10.
12. Various rate should be supported simultaneously. At call setup step, start
Markov test with various rate.
13. Variable rate call should be supported. At call setup step, start variable rate
Markov test instead of fixed rate Markov test.
14. For rate set 2 call test, repeat from step 4 to 13 with rate set 2 call generation.
15. Measurement of MS acquisition time ( Newly appended )
1) Measure the acquisition time using the call setup flow display command
on the BSP debugger mode.
2) Stroke trace all on the BSP debugger mode.
3) If the mobile originated or mobile terminated call is requested, call
DRAFT 3/1/97


18
setup flow will be displayed.
4) If succeeded in acquisition, TCE->BSP :(Jxxx)sel_link_on
w/mob_acq (yyyms) will be displayed. (Jxxx) is the internal
processing job id of BSP and (yyyms) is the taking time from the
reception of origination or page response till the setup of link
between SVC and TCE (include success of MS acquisition).
Displayed time is msec unit.
5) To see the mean, maximum, and minimum value of acquisition
time, stroke stat time on the BSP debugger mode. The display
will be as follows.
=================== Call SetUp Time ======================
Origination LATEST MEAN MAX MIN DIFF COUNT
T_PG_RSPS 0 0 0 0 0 0
T_ASGN_REQ 1500 1500 1500 1500 1500 1
T_ASGN_ACK 1800 1800 1800 1800 300 1
T_TCASN_AK 2000 2000 2000 2000 200 1
T_TCA_TX 2200 2200 2200 2200 200 1
T_SLNK_ON 2500 2500 2500 2500 300 1
---------------------------------------------------------------------------------------------
Termination LATEST MEAN MAX MIN DIFF COUNT
T_PG_RSPS 2000 2000 2000 2000 2000 1
T_ASGN_REQ 2500 2500 2500 2500 500 1
T_ASGN_ACK 2800 2800 2800 2800 300 1
T_TCASN_AK 3000 3000 3000 3000 200 1
T_TCA_TX 3200 3200 3200 3200 200 1
T_SLNK_ON 3500 3500 3500 3500 300 1
T_SLNK_ON : Setup of SVC link and MS acquisition time

16. TC Release in Normal, Abnormal state. ( Newly appended )
1) Stroke trace all or trace rel and release reason on the call flow
will be displayed as follows.
CCP->BSP :(Jxxx)RELEASE[Normal Call Clearing(16)](619)715-
1889
CCP->BSP :(Jyyy)RELEASE[Bad Frame(6)](619)715-1892
DRAFT 3/1/97


19
2) To display the statistic about call release reason, stroke stat call
on the BSP debugger mode.

Minimum Standard


DRAFT 3/1/97


20
1.1.1.4 Handoff

Definition
This test shall be conducted to verify the functional performance of softer
handoff within the BTS. This includes examination of both 2 and 3-way
softer handoff. All relevant configurable parameters shall be examined and
tested to insure proper behavior.

Verification of functional performance of softer handoff.

Be able to test in LAB without moving PS by controlling Pilot strength with
Attenuator.
Two Way softer Handoff

1. Confirm whether two sectors of BTS to test are normal and overlap
sufficiently.
2. Set up two calls that one is Markov call and the other is Mobile-to-
Land Call in any sector.
3. After confirming that call is kept up normally (about 30 seconds),
move to other Target Sector and generate softer ADD procedure.
Confirm softer ADD procedure by monitoring Active pilot set or by
logging the following messages in Mobile DM.
Confirmation messages :
PSMM (Pilot Strength Measurement Message)
EHDM (Extended Direction Message)
HCM (Handoff Complete Message)
4. Move to Target Sector with being softer ADD and confirm Handoff
control Messages (PSMM, EHDM, HCM) to know whether softer
Drop procedure to Serving Sector Pilot happens in Mobile DM.
DRAFT 3/1/97


21
5. Confirm whether set-up call is held up more than 10 seconds with
Serving Sector being DROP. At this time location must not get out of
Serving Sector Area.

Three Way softer Handoff
1. Confirm whether three sectors of BTS to test are normal and overlap
sufficiently.
move to area that three Sectors are overlapped and let 2 sectors (Target
1 Sector, Target 2 Sector) be softer ADD procedure. At this time,
confirm that 3 Way Softer becomes ADD. Confirm 3 Way ADD
procedure by monitoring Active pilot set or by logging the following
messages in Mobile DM.
Confirmation messages :
PSMM (Pilot Strength Measurement Message)
EHDM (Extended Direction Message)
HCM (Handoff Complete Message)
4. Move to Target Sector with being ADD and confirm Handoff control
Messages (PSMM, EHDM, HCM) to know whether softer Drop
procedure to Serving Sector Pilot happens in Mobile DM.
5. Confirm whether fixed call is held up more than 10 seconds with
Serving Sector being DROP. At this time location must not get out of
Serving Sector Area.

Minimum Standard
Fixed call has to be held up at the test procedure of 2 Way and 3 Way
sector handoff and in case of processing all handoff procedures (ADD or
DROP) BTS response time(Time difference between PSMM transmit and
EHDM receive) that is measured in Mobile DM has to be less than 200 ms.
(Reference : Most of the time that is PS retry time and BS_Ack_Order retry
time to PSMM increases more and more in case of bad radio frequency
environment.)

DRAFT 3/1/97


22
1.1.1.5 Handoff Balancing Requirements
Definition
handoff balancing requirements associated with the BTS. All parameters
used to assist the BSC in cell breathing and balancing will be examined to
insure adequate performance is achievable.
Verification of functional performance of the BTS measures used to assist in
handoff balance and breathing.
Detailed breathing parameter, threshold, maximum, minimum coverage
power and command are determined later.
1. Hold up normal BTS capable of call set-up with being unloaded.
2. Confirm Power Management Parameter with DIS-PWR-PARA
command in BSM and if value is not fixed, change parameter by
performing CHG-PWR-PAR.A.
3. Measure relevant sector, relevant FAs flower attenuator value,
received total power, transmit total power, upc gain etc. with
(TBD)command at BSP or RFP debugger.
4. Confirm whether total power received increases or decreases by
setting up real call or changing attenuator value with (TBD)command.
5. Confirm whether upc gain and transmit total power change by
received total powers change.
6. Confirm if change of transmit and receive is satisfied with breathing
algorithm.
Minimum Standard
Confirm whether increase and decrease of total power received are measured
and accordingly, confirm control of transmit total power. Confirm whether
transmit power is transmitted with maximum coverage with it unload or with
minimum coverage when receive power reaches threshold.

DRAFT 3/1/97


23
1.1.1.6 Load Management Requirements
Definition
This test shall be conducted to verify the functional performance of the load
management measurements associated with the BTS. All parameters used to
assist the BSC in load management (i.e. interference levels, channel element
utilization, HPA utilization, etc.) will be examined to insure adequate
performance is achievable.
Verification of functional performance of the BTS measures used to assist in
load management.
Detailed threshold is determined later and if not capable of reaching
threshold after call set-up, be able to use noise injection .
1. Maintain normal BTS capable of call set-up and being operated as 2
FA with being unloaded.
2. Set up reverse link resource call block and handoff block threshold at
BSM or BSP debugger.
3. Attempt call to particular FA and let it reach call block threshold.
4. In case of attempting new call and exceeding threshold , set up call to
other FA below threshold.
5. Confirm redirection with BSP output message and message logging
in Mobile DM.
6. Attempt to handoff block state with flowing in handoff call.
7. Confirm whether hard handoff set-up is completed to other FA
below threshold with attempting handoff Call.
8. In case of operating BTS as 1 FA and not being able to redirect to
another BTS, confirm whether call is restricted by attempting 3.~7. .
9. Mediate TC resource to be below each threshold at BSM, attempt 3.~7.
and confirm whether call is restricted or redirected.
10. Set up forward link excess capacity threshold and HPA or LPA
Limited Power threshold , attempt 3.~7. and confirm function.
Minimum Standard
Confirm whether call restriction and redirection are completed as above
procedures.
DRAFT 3/1/97


24
1.1.1.7 Back Haul Requirements
Definition
This test shall be conducted to verify the efficiency of the back haul associated
with the BTS. This includes capacity, overhead requirements, no. of calls
supported, daisy chaining and redundancy.
Verification of functional performance of the BTS back haul to the BSC.
Capacity and Number of Calls Supported
1. Check the normality of packet data transmission and the capacity
through IPCLOG test between the SVEA of BSC and MCPA of BTS.
2. IPCLOG test shall be conducted in the following procedures (this is
the case that the two (2) dedicated links are configured properly)
3. Verify the BSC and BTS are interconnected through the CIN/BHI
Block over two dedicated lines.
4. Connect RS-232C cable to the Debug Port of the CCP (or SBP, SVC).
5. Type ipslog type in OS prompt.
6. Type ipclog start in OS prompt.
7. Type target address (MCPA) in OR0
8. Continue to type the address for all the test routes (to finish keying-
in, strike return key).
9. Considering the packet handling number limitation of a processor,
conduct the ipclog test distributing load to the SVEA at the BSC
side. Also, assign the BTS target address to MCPA (CHC). in order
to distribute the load of each processor.
10. Input 10 (hexa) bytes size, 10 second print time and 1900 delay
time (Size 10 equals the traffic packet size in case of the average
rate of 7,200 bps of 13K vocoder).
11. The maximum sum of the packet number normally transmitted
and received after the performance of the SVEA is 56,500 (Traffic
channel capacity of 1 T1 is 113 TC in the average rate of 7,200 bps.
Therefore, the transmission packet number would be 5,650 (113
50)).
12. But, due to the bits (zero insertion/deletion, flag, CRC) added in
the HDLC Link Layer of the actual packet transmission, and the
queue overflow loss arising when the packets are transmitted near
DRAFT 3/1/97


25
to the maximum value, the number of the packet normally
transceived without any fault such as Miss or CRC error would be
5,000, approximately 90 percent of the calculation above.
13. Therefore, when two T1 links are setup, the packet number shown
every 10 seconds by IPCLOG is sufficient to be 90,000. In this case,
a BTS can accommodate 100 traffic channels approximately.
14. If you increase the number of T1 link and repeat above test, you
can verify the BHI block of the corresponding BTS.
15. If the number of transmission packet fault and delay is less than 5
percent in the above test procedure, 5 percent FER is achieved.

Daisy Chaining Verification
1. Configure 2-3 BTSs to be connected with a BSC through one
transmission link (daisy chain).
2. Check the faultless operation of the trunk line interface PBA (CITA,
CIMA-T, CIMA-O) of each BTS BHI/MCC Block and CIN Block of
BSC (check the fault LED status of each PBA or Node status of
CIMA).
3. Conduct IPCLOG test from the SVEA of BSC to MCPA of BTS .
4. Verify the test result shows the same result as the Capacity and
Number of Call Supported as per channel capacity of each BTS.
5. Power down a specific BTS BHI/MCC Block or remove the trunk
interface PBA among the BTS under test. In this case, all the BTSs
except the faulted BTS should restore/perform the IPCLOG
properly. (provided that, in the instant of fault generation, some
error may occur)
Minimum Standard
DRAFT 3/1/97


26
1.1.1.8 OAMP
Definition
This test shall be conducted to verify the functional performance of the OAM
aspects associated with the BTS. The management and configuration of all
parameters associated with the BTS shall be verified. In addition, all
diagnostic and logging capabilities will be examined.
Verification of functional performance of the OAMP aspect of the BTS.

1. Change the following OTA message parameters using MMC at BSM.
Sync Channel Message
System Parameters Message
Access Parameters Message
CDMA Channel List Message
Extended System Parameters Message
Extended Neighbor List Message
2. Through the parameter display MMC in the BSM, verify the parameters
of the changed message.
3. Using Mobile DM, verify the parameter of the changed message.

Refer to Interrogating and Modification of overhead OTA message data in
LGIC COD and POD.

Minimum Standard

DRAFT 3/1/97


27
1.1.1.9 Dial-up Modem
Definition
This test shall be conducted to verify the functional performance of the dial-
up modem associated with the BTS. The ability to examine the status as well
as examine and modify the configuration from a remote dial-up port will be
verified.
Verification of functional performance of the remote dial-up capabilities of
the BTS.

Status Monitoring
1. Setup a data link to the BTS using a normal PC with a dial-up modem
installed with it (the PC should have a communication software in it).
2. Check the status of the Processor and Device accommodated in the
BTS.
3. Modify the status of the Processor and Device compulsively. (e.g.,
reset or power on/off)
4. Check the modified status.

Configuration Change
1. Setup a data link to the BTS using a normal PC with a dial-up modem
installed with it (the PC should have a communication software in it).
2. Check the OTA message parameter value of the BTS.
3. Verify the parameter values of the message received by the PS from the
BTS are identical with the parameter values contained in the BTS.

Minimum Standard
DRAFT 3/1/97


28
1.1.1.10 Timing
Definition
This test shall be conducted to verify the functional performance of the BTS
with regards to provisioning of stable reference sources (i.e. 1 PPS and 10
MHz sources). In addition the BTS timing will be examined in the absence of
a system timing reference (i.e. GPS) over temperature along with examination
of the transient response when timing is removed and introduced.
Verification of functional performance of the timing associated with the BTS.
1. Introduction
The purpose of this paper is to document the functional and performance of
the GPS. This is redundant system that provide GPS disciplined frequency
and synchronization for CDMA system. The testing was conducted in the
timing laboratory at Odetics in Anaheim California. Odetics Time and
frequency reference is a Cesium clock that is traceable to the NIST using a
monitoring service provided by NIST.

2. Test Apparatus Description
The following block diagram outlines the basic testing apparatus.

The following equipment was used. Note that the phase noise test set is not
shown in the figure above.
DRAFT 3/1/97


29

Item Description Model
Serial
Number
A Cesium reference FTS-4040A/RS 02093
B
Frequency Difference
Meter
Tremetric 527E 951204
C Time Interval Counter GT-100 09867
D 486 Computer Magitek 486 10034
E Thermal Chamber
Tenny TTC
-100350
8593-6
F Phase Noise Test Set Hewlett Packard ------
F(1) Phase Noise Test Set HP 11848A 3502A01045
F(2) FFT Signal Analyzer HP3561A 2945A08096
F(3) PC with IEEE interface ALR 386 85503
F(4) Dot matrix printer Epson LQ-510 0631002735
*Note: The Cesium clocks frequency offset has been characterized to be
3.73 10
-12
.

3. Test Method
This section will describe the methods of measuring and/ or computing
the following quantities.

3.1 Fractional Frequency Error
Fractional frequency error is computed by measuring the frequency
difference between the 10Mhz output of the GPS and the Cesium
reference. The Tremetric 527E frequency difference meter provides of
proportional voltage output as a function of the frequency difference. The
full scale reading 1V which corresponds to a fractional frequency error
1010
-10
. This output voltage is scaled and sent to an 8bit A/D converter
which provides a fractional frequency error resolution of 7.8710
-12
per bit.

3.2 Allan Variance computations
Allan Variance, otherwise known as the two point variance, is computed
using fractional frequency error data collected from the Tremetrics
527E.Allan Variance for a Tau of 1, 10, and 100 are computed. 100
samples are used for each computation.

3.3 1PPS phase deviation
The 1PPS phase deviation is measured against the Cesium reference by
GT-100 time interval measurement board. This time interval
DRAFT 3/1/97


30
measurement board is designed to plug directly into a PC and measure
the time difference between the Cesium reference and GPS output 1PPS
with 10 nanoseconds of resolution.

3.4 Phase Noise
Phase noise is measured using the HP phase noise test set. This system
consist of the following equipment

Device Model Serial Number
Phase noise test box HP11848A 3502A01045
FFT Signal analyzer HP3561A 2945A08096
PC with IEEE interface ALR 386 85503
Dot matrix printer Epson LQ-510 0631002735

4. Test Description
Testing of the GPS involves examing the frequency deviation, 1PPS stability,
and short term frequency stability while subject to variety of environmental
conditions.GPS locked performance and Coasting, otherwise known as
holdover, were also tested.

4.1 GPS locked performance
4.1.1 Constant temperature environment
The GPS was placed into the thermal chamber and allowed to operate 24
hours at a constant ambient temperature of 35C.

4.1.2 Thermal gradient performance
During the next data collection run the GPS was subjected to a thermal
gradient condition of 0 to 50 C for a 43 hour duration. The thermal
gradient profile consisted of: a 5hour dwell at 0C, a 10C per hour rate of
change from 0 to 50C over five hours, a dwell at 50C for 5 hours, a 10C
per hour rate of change from 50C to 0C over five hours, and a 4 hour
dwell at 0C.
4.2 Coasting(Hold-over) performance
4.2.1 Thermal gradient coasting performance
The GPS was subjected to holdover while undergoing exposure to a
thermal gradient for a period of 24 hours. The C2 algorithm engaged and
made correction to the DAC based on data learned during the previous
two days of operation. During this test the unit was exposed to a thermal
gradient of 10C/hr.
DRAFT 3/1/97


31
4.3 Harmonic Distortion
Harmonic distortion was measured using a spectrum analyzer. The result
are summarized below.

Frequency Level,dBm
Carrier 10Mhz
first harmonic @5Mhz
13. 66dBm
14. -67.66dBc
4.4 1PPS Jitter
The 1PPS jitter was measured using an SRS-620 Time interval analyzer.
The results are summarized below.

Sample Size 1PPS jitter
2 <263 Picosecond
4.5 High/low voltage operation
The unit operated at following voltage and current as shown below.

DC Voltage Current Comment
19. 00
24.00
48.00
1.08
1.03
0.58
pass
pass
pass
Minimum Standard

10MHz
Parameter Requirement
Number of port 16

Accuracy
<1x10
-11
Locked,one day average
<1x10
-10
Unlocked,one day average,after
training
Phase Drift Less than 7us per day(unlocked,after training
period for holdover operation)

Stability
<1x10
-11
Allan Variance for 100 sec tau
Locked
Unlocked
DRAFT 3/1/97


32

Phase Noise
-120dBc/Hz max.at 100Hz
-135dBc/Hz max.at 1kHz
-135dBc/Hz max.at 1MHz
Isolation-10MHz Output > 60dB
Wave Form Sine Wave
Level 1V RMS into 50 ohoms
Source Impedance 50O nominal
Coupling AC

1PPS
Number of port 2
Frequency 1Hz

Accuracy of on-time edge
1us traceable to and synchronous with
UTC .tolerance in measurement and SA
constant temperature performance
thermal gradient performance
Accumulated time error Less than 7us per day
(unlocked,after training )
Jitter No jumps in 1PPS greater than 200ns between
pulses.
WaveForm 2ms. leading edge on time
Level TTL Compatible
DRAFT 3/1/97


33
1.1.1.11 Site Configurations
Definition
This test shall be conducted to verify the functional configurations associated
with the BTS. This includes indoor and outdoor models, sector
configurations, transmit diversity and remote LNA and HPA requirements.

Verification of functional configurations associated with the BTS.


Verify that board and block are inserted correctly according to the rack
configuration.

Outdoor BTS Rack Configuration
Outdoor Enclosure with Rectifier and Battery
Weather Proof with Heat Exchanger
Rack Size
Rittal Type : 1,132W 850D 1,575H (mm)
Reltec Type : 1,219W 1,427D 1,829H (mm)
DRAFT 3/1/97


34

Rittal Type : Shelf-Mounted LNA Type (1FA/3Sector)

6U
5U
H
e
a
t
E
x
c
h
a
n
g
e
r
6U
5U
H
e
a
t
E
x
c
h
a
n
g
e
r
Battery
FAN
Rectifier(PSOP)
R
F
P
A
P
V
M
A
/
*
U
D
C
A
/
*
U
D
C
A
/
*
H
P
A
U
/
*
H
P
A
U
/
*
H
P
A
U
/
*
B
L
A
N
K
B
L
A
N
K
P
S
U
/
C
UDCB-O
R
F
P
A
P
C
U
A
/
*
U
D
C
A
/
*
B
L
A
N
K
B
L
A
N
K
B
T
U
A
B
L
A
N
K
G
P
S
U
/
S
CI5B
C
I
R
A
/
O
C
I
N
A
/
O
CCBB-A
D
C
P
A
M
C
P
A
M
C
P
A
B
L
A
N
K
B
L
A
N
K
B
L
A
N
K
B
D
C
A
B
S
C
A
/
A
D
C
P
A
M
C
P
A
B
S
C
A
/
A
B
S
C
A
/
A
C
I
N
A
/
O
C
I
T
A
/
O
B
L
A
N
K
T
R
M
A
/
O
B
F
P
A
/
O
B
L
A
N
K
C
I
P
A
/
O
B
A
C
A
/
O
B
F
P
A
/
O
(2 Hour)
RFE-*
Rectifier
Battery
FAN(1U)
6U
5U
HPA-*
H
e
a
t
E
x
c
h
a
n
g
e
r
6U
5U
G
P
S
CCB-A MCC
UDC-*
B
L
A
N
K
H
e
a
t
E
x
c
h
a
n
g
e
r
(2 Hour)
BLANK(1U)
CDU
BLANK(1U)
CDU
R
F
E
U
R
F
E
U
R
F
E
U
R
F
E
U
R
F
E
U
R
F
E
U

GPS : Global Positioning System MCC : MiCro BTS Control
CCB : CDMA Channel Bank UDC : Up/Down Converter
RFE : RF Front End HPA : High Power Amplifier
PSOP : Power Supply for Outdoor BTS of PCS
CDU : Circumstance Detection Unit

Reltec Type : Outdoor BTS Configuration
We will submit Outdoor BTS configuration of Reltcc Type later.

Minimum Standard


xswqxs
DRAFT 3/1/97


35
1.1.1.12 Remote Site Support
Definition
This test shall be conducted to verify the functional performance of the BTS
when sectors are remoted. Interface to the remoting technology will be
examined as well as all parameters associated with the ability to advance and
retard the relative timing of a given sector to compensate for any RF transport
delay introduced in the remoting configurations.

Verification of functional performance of the remoting configurations
associated with the BTS.


1. Functional Setup for Remote Site Test
BTS
Cell Site Test Set
RF_TX_OUT

2. Set Tx_Timing_Adavance, Tx_section_adv1, Tx_section_adv2 and
Tx_section_adv3 of BSP to zero.
3. Connect the Remote RF TX output port to the test equipment(Cell Site
Test Set).
4. Trigger the test equipment from the system time reference signal and
even_sec from the BTS.
5. Adjust the test equipment PN offset to the BTS PN offset.
6. Measure the test equipment time offset(=time delay).
7. If time delay is 20s, set TX_Timing_Adv to 0x3, TX_Section_Adv to
0x31 at BSP.(refer to Forward LinkTiming Advance<CSM ASIC> . This is
temporay.)
8. And then verify that time offset in test equipment is zero.

DRAFT 3/1/97


36
Forward Link Timing Advance <CSM ASIC>
Delay(sec)
TX_TIMING_ADV
(8chip unit)
TX_SECTION_ADV
(chipx2 unit)
0 0 0
1 0 0x2
2 0 0x5
3 0 0x7
4 0 0xA
5 0 0xC
6 0x0 0xF
7 0x1 0x11
8 0x1 0x14
9 0x1 0x16
10 0x1 0x19
11 0x1 0x1B
12 0x1 0x1D
13 0x2 0x20
14 0x2 0x22
15 0x2 0x25
16 0x2 0x27
17 0x2 0x2A
18 0x2 0x2C
19 0x2 0x2F
20 0x3 0x31
21 0x3 0x34
22 0x3 0x36
23 0x3 0x39
24 0x3 0x3B
25 0x3 0x3D
26 0x4 0x40
27 0x4 0x42
28 0x4 0x45
29 0x4 0x47
30 0x4 0x4A

Minimum Standard


DRAFT 3/1/97


37
1.1.2 Performance Tests
1.1.2.1 Emissions
All emissions related tests in specified in SP3383 shall be conducted by the
vendor. All requirements specified in SP-3383 shall be satisfied.

(1) Conducted Spurious Emissions Test of BTS Receiver
Definition
Conducted spurious emissions are spurious emissions generated or amplified
in the base station equipment and appearing at the receiver RF input ports.

Verification of functional performance of the emissions associated with the
BTS.


1. Functional Setup for emissions
Spectrum Analyzer
RF RX_A IN
BTS

2. Connect a spectrum analyzer (or other suitable test equipment)
to a receiver RF input port.
3. Disable the transmitter RF output.
4. Sweep the spectrum analyzer over a frequency range the lowest
intermediate frequency or lowest oscillator frequency used in the
receiver or 1 MHz, whichever is lower, to at least 6GHz.
5. Repeat steps 1 through 3 for all other receiver input ports.

Minimum Standard
DRAFT 3/1/97


38
Less than -80dBm, measured in a 30kHZ resolution bandwidth at the
base station RF input ports, for frequencies within the base station
receiver band.
base station RF input ports, for frequencies within the base station
transmit band.
base station RF input ports, for all other frequencies.



(2) Conducted Spurious Emissions Test of BTS Transmitter
Definition
Conducted spurious emissions are emissions at frequencies that are outside
the assigned CDMA channel, measured at the base station RF output ports.

Verification of functional performance of the emissions associated with the
BTS.


1. Functional Setup for emissions
Spectrum Analyzer
RF TX OUT
BTS

DRAFT 3/1/97


39
2. Connect a spectrum analyzer (or other suitable test equipment) to
the base station RF output port, using an attenuator or directional
coupler if necessary.
3. Set the base station to transmit a signal, modulated with a
combination of Pilot, Sync, Paging, and Traffic Channels. Total
power at the output port shall be the nominal power as specified
by the manufacture.
4. Measure the power level at the carrier frequency.
5. Sweep the spectrum analyzer over a frequency range the lowest
frequency generated in the equipment or 1 MHz, whichever is
lower, to the tenth harmonic of the carrier frequency.
Minimum Standard
1. Suppression Inside the Licensees Frequency Block(s)
For all frequencies within the base station transmit band that are also
within the specific block(s) allocated to the operators system, the total
conducted spurious emissions in any 30KHz band greater than 885KHz
from the CDMA channel center frequency shall not exceed a level of -
45dBc.
2. Suppression Outside the Licensees Frequency Block .
When transmitting on any valid CDMA Channel , the spurious
emissions shall not exceed -13dBm or -80dBc ,whichever is the larger
power ,outside the band. The resolution bandwidth for measuring these
emissions shall be 1MHz ,except within the 1MHz bandwidth immediately
outside and adjacent to the frequency block, where a resolution bandwidth
of at least 1 percent of the emission bandwidth of the fundamental
emission of the transmitter shall be employed. The emission bandwidth is
defined as the width of the signal between two points, one below the
carrier center frequency and one above the carrier center frequency ,
outside of which all emissions are attenuated at least 26dB below the
transmitter power.
DRAFT 3/1/97


40
1.1.2.2 Receiver Performance
As a minimum, the vendor must perform all receiver tests specified in SP-
3383 (J-STD-019). All of the requirements set forth in SP-3383 must be
satisfied. In some cases, NextWave Telecom has imposed additional
requirements on the receiver performance which must be satisfied. These
are outlined below as they relate to SP-3383.

(1) Frequency Coverage Test
Definition
The base station receiver may be fixed tuned to a specific CDMA frequency
assignment or may cover a subset of the available frequency assignments.

Verification of frequency Coverage associated with the BTS.


Fig. CDMA Center Carrier Frequencies
FA
Personal Station
Center Frequency(MHz)
Base Station
1 1896.25 1976.25
2 1897.50 1977.50
3 1898.75 1978.75
4 1900.00 1980.00
5 1901.25 1981.25
6 1902.50 1982.50
7 1903.75 1983.75
8 1905.00 1985.00
9 1906.25 1986.25
10 1907.50 1987.50
11 1908.75 1988.75
1. Frequency shall be measured using appropriate test equipment of
sufficient accuracy to ensure compliance with the minimum standard.
DRAFT 3/1/97


41
2. The average frequency difference between the receiver carrier frequency
and the specified CDMA receiver frequency assignment shall be measured.

Minimum Standard
The base station receiver may cover a subset of the available frequency
assignments.



(2) Receiver Sensitivity Test
Definition
The RF sensitivity of the base station receiver is defined as the minimum
received power measured at the base station RF input ports , at which the
Reverse Traffic Channel FER is maintained at 1%.

Verification of Receiver Sensitivity associated with the BTS.


Functional Setup for the demodulation performance of the BTS

DRAFT 3/1/97


42
POWER
METER
POWER
METER
ATTEN.
ATTEN.
ATTEN.
AWGN
GENERATOR
AWGN
GENERATOR
BASE
STATION
UNDER
TEST
MOBILE
STATION
SIMULATOR
Tx
Rx Tx
Rx(B)
Rx(A)

1. Configure both the base station under test and a personal station
simulator as shown in Figure.
2. Adjust the equipment to ensure that a signal power of -119dBm
per RF input port is not exceeded . Reverse Traffic Channel power
control in the personal station simulator should be disabled.
3. Disable the AWGN generators (set their output powers to zero).
4. Set up a call using Rate Set 1 loopback mode (Service Option 2).
5. Transmit random data to the personal station simulator at full data
rate.
6. For each of the four data rates ,measure the FER.

Minimum Standard
The measured FER shall be 1.0% or less with 95% confidence.



(3) Receiver Dynamic Range Test Definition
DRAFT 3/1/97


43
The receiver dynamic range is the input power range at the base station RF
input ports over which the FER does not exceed a specific value .Purpose Of
The Test/ Requirement To Be Satisfied
Verification of Receiver Dynamic Range associated with the BTS.

POWER
METER
POWER
METER
ATTEN.
ATTEN.
ATTEN.
AWGN
GENERATOR
AWGN
GENERATOR
BASE
STATION
UNDER
TEST
MOBILE
STATION
SIMULATOR
Tx
Rx Tx
Rx(B)
Rx(A)

2. Adjust the equipment for a noise power spectral density at each
RF input port of not less than -65dBm/1.23MHz and a signal
power corresponding to an Eb/No of 10dB
1 dB . Reverse Traffic
Channel power control in the personal station simulator may be
disabled.
3. Set up a call using Rate Set 1 loopback mode (service option 2).
rate.
5. For each of the four data rates, measure the FER.
Minimum Standard
The measured FER shall be 1.0% or less with 95% confidence.
DRAFT 3/1/97


44
(4) Single Tone Desensitization Test
Definition
Single tone desensitization is a measure of the ability to receive a
CDMA single on the assigned channel frequency in the presence of a
single tone that is offset from the center frequency of the assigned
channel.
Verification of Single tone desensitization associated with the BTS.

POWER
METER
POWER
METER
ATTEN.
ATTEN.
ATTEN.
CW
GENERATOR
BASE
STATION
UNDER
TEST
MOBILE
STATION
SIMULATOR
Tx
Rx Tx
Rx(B)
Rx(A)
ATTEN.
ATTEN.
load

2. Adjust the equipment to ensure path losses do at least 100dB .All power
control mechanisms shall be enabled and shall be set at nominal values.
4. Transmit random data to the personal station simulator at full data rate.
5. Measure the personal station simulator output power.
DRAFT 3/1/97


45
6. Adjust the CW generator to a frequency offset +1.25MHz from the
CDMA frequency assignment.
7. Adjust the CW generator power to be 90dB at a frequency offset
+1.25MHz above the personal station simulator output power at the FR
input ports
8. Measure the personal station simulator output power and the FER at the
base station receiver.
9. Repeat steps 6 through 8 for a frequency offset of -1.25MHz
Minimum Standard
At +-1.25MHz offset ,the output power of the personal station
simulator shall increase by no more than 3dB ,and the FER shall be less
than 1.5% with 95% confidence.

(5) Intermodulation Spurious Response Attenuation Test
Definition
The intermodulation spurious response attenuation is a measure of a
receivers ability to receive a CDMA signal on its assigned channel frequency
in the presence of two interfering CW tones.

Verification of Intermodulation Spurious Response Attenuation associated
with the BTS.

DRAFT 3/1/97


46

POWER
METER
POWER
METER
ATTEN.
ATTEN.
ATTEN.
CW
GENERATOR
BASE
STATION
UNDER
TEST
MOBILE
STATION
SIMULATOR
Tx
Rx Tx
Rx(B)
Rx(A)
ATTEN.
ATTEN.
CW
GENERATOR
load

2. Adjust the equipment to ensure path losses do at least 100dB .All power
control mechanisms shall be enabled and shall be set at nominal values.
4. Transmit random data to the personal station simulator at full data rate.
5. Measure the personal station simulator output power.
6. Adjust the interference generator to frequency offset +1.25MHz
and+2.05MHz from the CDMA frequency assignment.
7. Adjust the CW generator power to be 70dB above the personal station
simulator output power at the RF input ports
8. Measure the personal station simulator output power and the FER at the
base station receiver.
9. Repeat steps 5 through 8 at frequency offset of -1.25MHz and -2.05MHz.
Minimum Standard
The output power of the personal station simulator shall increase by no more
than 3dB, and the FER shall be less than 1.5% with 95% confidence.
DRAFT 3/1/97


47
(6) Receiver Signal Quality Indicator (RSQI) Test
Definition
Received signal quality indicator (RSQI) refers to a measurement of signal
quality performed by base station.

Verification of frequency Coverage associated with the BTS.


power
meter
Atten.
Atten.
Load
Atten.
AWGN
Generator
AWGN
Generator
power
meter
+
+
Base
Station
Under
Test
TX
RX(A)
RX(B)
Personal
Station
Simulator
RX
TX

2. Disable reverse link power control in the personal station
simulator.
3. Adjust the AWGN generators for a noise power spectral density of
-84 dBm/1.23MHz 5dB and adjust the other equipment for an
Eb/No of 8dB at each RF input terminal.
rate.
6. Record the RSQI reported by the base station.
7. Reduce the personal station simulator output power by 1dB.
DRAFT 3/1/97


48
8. Record the RSQI reported by the base station.
9. Increase the personal station simulator output power by 1dB.
10. Repeat steps 8 and 9 until the Eb/No PEER antenna reaches 14dB.
11. If Rate Set 2 is supported. repeat steps 4 through 10 using Rate Set 2
loopback mode (Service Option 9.)
Minimum Standard
The reported RSQI shall be within the bounds shown in Table. For Eb/No
greater than 14dB ,the RSQI reports should be monotonically nondecreasing.

Table. Bounds on RSQI Reports
Eb/No (dB)
per
Input port
Minimum
Acceptable report
Value
Maximum
Acceptable report
Value
4 10 18
5 12 20
6 14 22
7 16 24
8 18 26
9 20 28
10 22 30
11 24 32
12 26 34
13 28 36
14 30 38

DRAFT 3/1/97


49
1.1.2.2.1 Demodulation Requirements
Definition
The demodulation performance of the BTS receiver in AWGN and fading
conditions shall be tested as specified in SP-3383.
Verification of functional performance of the BTS receiver.


power
meter
Atten.
Atten.
Load
Atten.
AWGN
Generator
AWGN
Generator
power
meter
+
+
Base
Station
Under
Test
TX
RX(A)
RX(B)
Personal
Station
Simulator
RX
TX
chan.
Sim
chan.
Sim

1. Performance in Additive noise(Reverse Traffic Channel)

1) Configure both the base station under test and a personal
station simulator.
2) Adjust the AWGN generators to yield a noise power spectral
density of -84dBm /1.23MHz
5dB at each base station

receiver input.
3) Adjust the equipment so that the measured Reverse Traffic
Channel Eb/No at each RF port is within the range specified
in Table 3.3-1 or 3.3-2, case 1. Reverse Traffic Channel power
control in the personal station simulator shall be disabled .
4) Set up a call using Rate Set 1 loopback mode(service option 2)
DRAFT 3/1/97


50
5) Transmit random data to the personal station simulator at
each of the four data rates .This may be done either as
separate single rate tests or as one mixed rate test.
6) For each of the four data rates ,measure the frame error rate.
7) If Rate Set 2 is supported, repeat steps 2 through 6 using Rate
Set 2 loop-back mode(service option 9).

2. Performance in Multipath Fading (Reverse Traffic Channel ) without
Power Control
station simulator.
density of -84 dBm /1.23MHz

receiver input.
3) Adjust the equipment so that the measured mean Reverse
Traffic Channel Eb/No at each RF input port is within the
range specified for case 2(a)in Tables 3.3-1 and 3.3-2. Reverse
Traffic Channel power control in the personal station
simulator shall be disabled (see 6.4.3).
4) Set up a call using Rate Set 1 loop-back mode (service
option2).
each of the four data rates. This may be done either as
6) For each of the four data rates, measure the FER.
7) Repeat steps 3 through 6 for cases 2(b),2(c),and 2(d)in Tables
3.3-1 and 3.3-2.
8) If Rate set 2 is supported ,repeat steps 2 through 7 using Rate
Set 2 loopback mode(service option 9).

3. Performance in Multipath Fading (Reverse Traffic
Channel ) with closed loop power control
station simulator.
DRAFT 3/1/97


51
density of -84 dBm/1.23MHz

receive input.
3) Adjust the equipment so that the measured mean Reverse
Traffic Channel Eb/No at each RF input port is within the
range specified for case 3(a)in Tables 3.3-1 and 3.3-2. Reverse
Traffic Channel power control in the personal station
simulator shall not be disabled. Refer to 6.4.1 for the standard
channel simulator configurations.
4) Set up a call using Rate Set 1 loopback mode (service option2).
each of the four data rates. This may be done either as
6) For each of the four data rates, measure the FER.
7) Repeat step 3 through 6 for case 3(b) in Tables 3.3-1 and 3.3-2.
8) If Rate set 2 is supported ,repeat steps 2 through 7 using Rate
Set 2 loopback mode(service option 9)

Minimum Standard
Tables 3.3-1 and 3.3-2 list the parameters for the demodulation tests.

DRAFT 3/1/97


52

Table 3.3-1 Parameters for Rate Set 1 Demodulation Tests
Case Test Channel Simulator Eb/No Limits(dB)
Configuration Number Lower
Upper
1 3.3.1 None 4.05 4.65
2(a) 3.3.2 1 10.35 10.95
2(b) 3.3.2 2 9.00 9.60
2(c) 3.3.2 3 8.00 8.60
2(d) 3.3.2 3 8.40 9.00
3(a) 3.3.3 1 6.30 6.90
3(b) 3.3.3 2 7.60 8.20

Table 3.3-2 Parameters for Rate Set 2 Demodulation Tests
Case Test Channel Simulator Eb/No Limits(dB)
Configuration Number Lower Upper
1 3.3.1 None 3.20 3.80
2(a) 3.3.2 1 9.90 10.50
2(b) 3.3.2 2 Not required
2(c) 3.3.2 3 7.70 8.30
2(d) 3.3.2 3 8.10 8.70
3(a) 3.3.3 1 5.80 6.40
3(b) 3.3.3 2 8.30 8.90

DRAFT 3/1/97


53

1. Performance in Additive noise(Reverse Traffic Channel)
The measured FER for each data rate with 95% confidence shall not
exceed that given by log-dB interpolation between the two values given
in Tables 3.3-1, 3.3-2, 3.3.1.3-1, 3.3.1.3-2 at the larger of the Eb/No
values at the two RF input ports. The interpolated value ,FERlim, is
given by

| |
log( )log( )
( / ) ( / )
( / ) ( / )
log( )log( )
lim
FER FER
E N E N
E N E N
FER FER
upper
b o upper b o mesa
b o upper b o lower
lower upper
= +

|
\
|
.
|

Table 3.3.1.3-1 Maximum FER for Rate Set 1 Demodulation Performance Tests in
Additive Noise, Case 1
Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
9600 3.0 0.2

Table 3.3.1.3-2 Maximum FER for Rate Set 2 Demodulation Performance Tests in
Additive Noise, Case 1
Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
14400 5.0 0.2
DRAFT 3/1/97


54

2. Performance in Multipath fading (reverse traffic channel) without
power control
in Tables 3.3-1, 3.3-2, 3.3.2.3-1and 3.3.2.3-2 at the average of the two
measured values of Eb/No in dB. The interpolated value, FERlim, is
given by

| |
log( )log( )
( / ) ( / )
( / ) ( / )
log( )log( )
lim
FER FER
E N E N
E N E N
FER FER
upper
b o upper b o mesa
b o upper b o lower
lower upper
= +

|
\
|
.
|

where the subscripts upper and lower refer to entries in Tables 3.3-
1,3.3-2,3.3.2.3-1 and 3.3.2.3-2. (Eb/No)meas is the measured value in dB.

Table 3.3.2.3-1(a) Maximum FER for Rate Set 1 Demodulation Performance Tests
in Multipath Fading, Case2(a)

Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
9600 1.3 0.7

Table 3.3.2.3-1(b) Maximum FER for Rate Set 1 Demodulation performance Tests
in Multipath Fading, Case 2(b)

Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
9600 1.6 0.7

Table 3.3.2.3-1(c) Maximum FER for Rate Set 1 Demodulation Performance
Tests in Multipath Fading, Case 2(c)

DRAFT 3/1/97


55
Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
9600 2.5 0.5

Table 3.3.2.3-1(d) Maximum FER for Rate Set 1 Demodulation Performance Tests
in Multipath Fading, Case 2(d)

Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
9600 0.8 0.2

Table 3.3.2.3-2(a) Maximum FER Set 2 Demodulation Performance Tests in
Multipath Fading, Case 2 (a)

Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
14400 1.5 0.8

Table 3.3.2.3-2(b) Maximum FER for Rate Set 2 Demodulation Performance Tests
in Multipath Fading, Case 2 (c)
Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
14400 2.0 0.6

Table.3.3.2.3-2(c) Maximum FER for Rate Set 2 Demodulation Performance Tests
in Multipath Fading, Case 2 (d)

DRAFT 3/1/97


56
Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
14400 0.9 0.3

3. Performance in Multipath Fading (Reverse Traffic Channel)with Closed
Loop Power Control
in Tables 3.3-1, 3.3-2, 3.3.3.3-1 and 3.3.3.3-2 at the average of the two
measured values of Eb/No in dB. The interpolated value, FERlim, is
given by
| |
log( )log( )
( / ) ( / )
( / ) ( / )
log( )log( )
lim
FER FER
E N E N
E N E N
FER FER
upper
b o upper b o mesa
b o upper b o lower
lower upper
= +

|
\
|
.
|

Table.3.3.3-1(a) Maximum FER for Rate Set 1 Demodulation Performance Tests in
Multipath Fading, Case 3(a)
Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
9600 2.4 0.4

Table 3.3.3.3-1(b) Maximum FER for Rate Set 1 Demodulation Performance Tests
in Multipath Fading , Case 3(b)
Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
9600 1.7 0.7

DRAFT 3/1/97


57
Table 3.3.3.3-2(a) Maximum FER for Rate Set 2 Demodulation Performance Tests
in Multipath Fading, Case 3(a)

Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
14400 1.8 0.5

Table 3.3.3.3-2(b) Maximum FER Rate Set 2 Demodulation Performance Tests in
Multipath Fading, Case 3(b)

Data Rate
(bps)
FER Limits(%)
At Lower
Eb/No
At Uper
Eb/No
14400 1.3 0.7

DRAFT 3/1/97


58
1.1.2.2.2 Effective Noise Figure
Definition
The effective noise figure of the BTS shall be measured inclusive of all line
and connector losses. The maximum line loss associated with the remote
transceiver shall be examined and verified. The test shall measure noise
figure over temperature and frequency.

Characterization of the receiver noise figure over temperature and frequency.


1. Functional Setup for The effective noise figure of the BTS

BTS
Noise Figure Meter
RF_RX_IN RF_RX_OUT

2. Connect the Noise Figure Meter between RF_RX_IN Port and
RF_RX_OUT Port.
3. Measure NF using Noise Figure Meter.
4. Refer to Down Converter N.F( NF~ 6.76)

DRAFT 3/1/97


59
Pi n=( dBm) GAI N DEVI CE ELEMOUT OUT RUN RUN
-80 ( dB) N. F( dB) I P3( dBm) SI GNAL N. F( dB)
AMP 13. 5 2. 60 40 -66. 50 2. 60
BPF -3. 0 3. 00 1000 -69. 50 2. 70
ATT -3. 5 3. 50 32 -73. 00 2. 95
ATT -3. 5 3. 50 32 -76. 50 3. 47
AMP 13. 5 2. 60 40 -63. 00 4. 13
MI XER -8. 0 7. 90 37 -71. 00 4. 30
DI PLEXER -1. 0 1. 00 1000 -72. 00 4. 35
AMP 12. 0 2. 60 37 -60. 00 4. 55
PAD -10. 0 10. 00 1000 -70. 00 4. 69
AMP 12. 0 2. 60 37 -58. 00 4. 81
FI LTER -21. 0 21. 00 1000 -79. 00 5. 81
AMP 30. 0 3. 30 27 -49. 00 6. 74
ATT -9. 7 9. 67 52 -58. 67 6. 74
AMP 30. 0 3. 30 27 -28. 67 6. 75
FI LTER -21. 0 21. 00 1000 -49. 67 6. 75
AMP 30. 0 3. 30 27 -19. 67 6. 75
ATT -9. 7 9. 67 52 -29. 33 6. 75
AMP 21. 0 4. 20 36 -8. 33 6. 75
ATT -9. 7 9. 67 52 -18. 00 6. 75
MI XER -7. 0 7. 00 25 -25. 00 6. 75
DI PLEXER -1. 0 1. 00 1000 -26. 00 6. 75
AMP 12. 0 4. 60 36 -14. 00 6. 75
AMP 12. 0 4. 60 36 -2. 00 6. 75
SPLI TTER -3. 0 3. 00 33 -5. 00 6. 75
SWI TCH -0. 1 0. 10 44 -5. 10 6. 75

Minimum Standard
The receiver noise figure shall be less than 4.5 dB, including line losses and
connector losses.


DRAFT 3/1/97


60
1.1.2.3 Transmitter Performance
As a minimum, the vendor must perform all transmitter performance tests
specified in SP-3383 (J-STD-019). All of the requirements set forth in SP-3383
must be satisfied.

(1) Frequency Tolerance Test
Definition
Frequency tolerance is defined as the maximum allowed difference between
the actual CDMA transmit carrier frequency and the specified CDMA
transmit frequency assignments.

Verification of frequency tolerance associated with the BTS.


Table. CDMA Center Carrier Frequencies
FA
Personal Station
Base Station
1 1896.25 1976.25
2 1897.50 1977.50
3 1898.75 1978.75
4 1900.00 1980.00
5 1901.25 1981.25
6 1902.50 1982.50
7 1903.75 1983.75
8 1905.00 1985.00
9 1906.25 1986.25
10 1907.50 1987.50
11 1908.75 1988.75
1. Frequency shall be measured using appropriate test equipment of
sufficient accuracy to ensure compliance with the minimum standard.
DRAFT 3/1/97


61
2. The average frequency difference between the transmit carrier frequency
and the specified CDMA transmit frequency assignment shall be
measured at each of three operating temperatures :minimum, nominal,
and maximum.

Minimum Standard
For all operating temperatures specified by the manufacturer,the average
frequency difference between the actual CDMA transmit carrier frequency
and specified CDMA transmit frequency assignment shall be within

5
10
8
(
0.05 ppm ).



(2) Pilot Time Tolerance Test
Definition
Pilot time is defined as the estimate of CDMA System Time derived from
observation of the pilot signal at the base station RF output port. Pilot time
alignment error is the difference between the measured pilot time and the
expected time . taking into account CDMA System Time and pilot offset.

Verification of Pilot time tolerance associated with the BTS.


DRAFT 3/1/97


62

Base Station
Under Test
Waveform
Analyzer
Tx
Rx(A)
Rx(B)
Load
Atten.

1. Connect the waveform quality test equipment to the base station RF
output port.
2. Set the attenuator at an appropriate level for the test equipment.
3. Configure the base station to transmit only the Pilot Channel .The PN
offset of the base station may be any value in accordance with 3.1.3.2.1 of
ANSI J-STD-008.
4. Trigger the test equipment from the base station even second time
reference signal.
5. Measure the pilot time alignment error using the test equipment error
the test equipment.

Minimum Standard
The pilot time alignment error should be less than 3US and shall be less than
10US.For base station supporting multiple simultaneous CDMA Channels, all
CDMA Channels radiated by a base station shall be within
1US of each
other.


DRAFT 3/1/97


63
(3) Pilot Channel to Code Channel Time Tolerance Test
Definition
Pilot Time is defined as the estimate of CDMA System Time derived from
observation of the pilot signal at the base station RF output port. Pilot time
alignment error is the difference between the measured pilot time and the
expected time, taking into account CDMA System Time and pilot offset.
Verification of Pilot Channel to Code Channel Time Tolerance associated with
the BTS.

Base Station
Under Test
Code Domain
Power Analyzer
Tx
Rx(A)
Rx(B)
Load
Atten.

1. Configure the base station according to the test model described in
Figure.
2. Monitor the transmitter output with the code domain power test
equipment as described in Figure, and measure the relative timing of the
active channels.
Minimum Standard
The time error between the Pilot Channel and all code channels comprising
the Forward CDMA Channel shall be within
50ns.

(4) Pilot Channel to Code Channel Phase Tolerance Test
DRAFT 3/1/97


64
Definition
Pilot to walsh Cover Time Tolerance is the permissible error in timing
between the radiated Pilot Channel and the other code channels within one
Forward CDMA Channel.

Verification of Pilot Channel to Code Channel Phase Tolerance associated
with the BTS.



Base Station
Under Test
Code Domain
Power Analyzer
Tx
Rx(A)
Rx(B)
Load
Atten.

Figure.
2. Monitor the transmitter output with the code domain power test
equipment as described in Figure, and measure the relative timing of the
active channels.

Minimum Standard
DRAFT 3/1/97


65
(5) Waveform Quality Test
Definition
Waveform quality is measured by determining the normalized correlated
power between the actual waveform and ideal waveform.
Verification of Waveform Quality associated with the BTS.


Base Station
Under Test
Waveform
Analyzer
Tx
Rx(A)
Rx(B)
Load
Atten.

1. Connect the base station RF output port to the test equipment described
in Figure.
2. Configure the base station to transmit the Pilot Channel only . The PN
offset of the base station may be any value in accordance with 3.1.3.2.1
of ANSI J-STD -008.
3. Trigger the test equipment from the system time reference signal from
the base station.
4. Measure the waveform quality factor.

Minimum Standard
The normalized cross correlation coefficient , ,shall be greater than 0.912
( EXCESS POWER < 0.4dB )

DRAFT 3/1/97


66
(6) Total Power Test
Definition
Total power is the mean power delivered to a load with resistance equal to
the nominal load impedance of the transmitter.

Verification of Total Power associated with the BTS.


1. Connect the power measuring equipment to the base station RF output
port.
2. Set the base station to transmit a signal modulation with a combination
of Pilot , Sync, Paging, and Traffic Channels as stated in PN3383 6.5.2.
Total power at the output port shall be the nominal power as specified
by the manufacturer.
3. Measure the mean power at the RF output port.

Minimum Standard
The total power shall remain within +2dB and -4dB of the manufacturers
nominal power for the equipment.



DRAFT 3/1/97


67
(7) Pilot Power Test
Definition
The Pilot Channel Power to total power ratio is the power attributed to the
Pilot Channel divided by the total power, and is expressed in dB. The Code
Domain Power Analyzer is used to determine the ratio of the Pilot Channel
Power to the total power.

Verification of The Pilot Channel Power associated with the BTS.


1. Connect the base station RF output port to the Code Domain Power
Analyzer using an attenuator or directional coupler if necessary.
2. Configure the base station to transmit a signal modulation with a
combination of Pilot, Sync, Paging, and Traffic Channels as described in
Figure.
3. Measure the Pilot Channel Power to Total Power.

Minimum Standard
The Pilot Channel power to total power ratio shall be within +-0.5dB of the
configured value.



DRAFT 3/1/97


68
(8) Code Domain Power Test
Definition
Code domain power is a measurement of the power in each code channel of a
base station.

Verification of Code domain power associated with the BTS.


Base Station
Under Test
Code Domain
Power Analyzer
Tx
Rx(A)
Rx(B)
Load
Atten.

Figure.
2. Set the base station to transmit at the manufacturers maximum rated
power.
3. Measure the base station transmit output at the RF output port with
Code Domain Power Analyzer described in Figure.

Minimum Standard
The code domain power in each inactive channel shall be 27dB or more below
the total output below the total output power.

1.2 BSC
DRAFT 3/1/97


69
1.2.1 Features and Functional Tests
1.2.1.1 Radio Link Management
1.2.1.1.1 Overhead Channel Support
Definition
Overhead channel tests shall be conducted to verify necessary and sufficient
functionality of these channel types. All relevant configurable parameters
affecting the performance associated with the pilot, synch, page and access
channels will be tested.

Verification of overhead channel functionality and compliance with J-STD-
008.
Forward Link Power Test
1. Configure only pilot channel and set appropriate pilot digital gain.
2. Measure pilot channel power using Code Domain Analyzer at IF unit.
3. Configure sync and paging channels with pilot channel.
4. Set digital gains for sync and paging channels, respectively.
5. Measure transmit power using Code Domain Analyzer at IF unit.

Cell breathing
For cell breathing, transmit power of forward overhead channels should be
controllable by digital gain set at channel element.
1. Set up test environment to be same as Forward Link Power Test.
2. Change digital gain for each overhead channel and monitor power
variation using Code Domain Analyzer.

Number of Channel
There can be 16 channels per one channel card. But same overhead channel
can be configured by one per each channel card.

Data Rate
The data rate of Paging Channel should be 4800 or 9600bps. It depends on the
page messages that are broadcast to the air.
1. Set mobile DM to message logging mode.
2. Configure paging channel data rate to 4800 or 9600bps by using sync
DRAFT 3/1/97


70
channel message .
3. After changing the data rate, turn on mobile station.
4. Check the mobile DM logged message whether the mobile station
received proper overhead message at the same rate or not.

Paging channel operation under slotted mode.
The Paging Channel is divided into 80ms slots called Paging Channel Slot.
A mobile station that monitor the Paging Channel only during certain
assigned slots is referred to as operating in the slotted mode.
1. Set mobile DM to message logging mode and slot mode.
2. Set up land to mobile call or mobile to mobile call.
3. Stop logging after call setup.
4. Verify that the mobile receives the slotted page message containing the
mobile MIN was recorded .

Access channel operation under various slot size.
1. Set appropriate value for slot size at access channel and mobile station.
2. Generate message at mobile station
3. Check the decoded message at access channel (or BSP).

Mobile station initialization control by forward overhead channels.
1. Set up all overhead channels (pilot, sync, and paging channels) at the
base station.
2. Turn on the mobile station and start data logging using mobile DM .
(Stroke <Alt - L> key)
3. Stop logging after confirming that the mobile station enters
CDMA mode.
4. Analyze logged file using data analysis tool.
5. Compare all logged overhead messages with predefined format by J-
STD-008.

Minimum Standard
Functional compliance with J-STD-008 and NextWave Telecom requirements.


DRAFT 3/1/97


71
1.2.1.1.2 Power Control
1.2.1.1.2.1 Forward Link Power Control
Definition
forward power control algorithm for the rate set 1 and rate set 2 service
options. All relevant configurable parameters shall be examined and tested

Verification of forward link power control functional performance for rate
sets 1 and 2.

For the test of rate set 1 forward power control, SVC provides following.
Print out current TX gain every 0.5 sec.
If the number of erasures included in the PMRM is not 0, print out the
number of erasures, the measurement period (in frames) and the TX
gain adjusted.
For the test of rate set 2 forward power control, SVC provides following.
Print out the value of erasure indicator bit and TX gain every 20 msec.

1. Connect a terminal to SVC capable of logging data into a file.
2. Connect test PS (Personal Station) to mobile DM, then setup 8 Kbps
Markov call.
3. Move test PS enough to change forward link condition and observe the
RX power level change of test PS through mobile DM.
4. Release call after proper time, then analyze the data logged from SVC.
5. Set up 13 Kbps Markov call, then repeat step 3 and 4.

Minimum Standard
The variation of the test PSs RX power level should be less than
certain limit (TBD) for both rate sets.
For rate set 1, TX gain is increased by fixed amount when the number
of erasures included in PMRM is not 0. Otherwise, TX gain is
DRAFT 3/1/97


72
periodically decreased by fixed amount.
For rate set 2, TX gain is increased by fixed amount when erasure
indicator bit is set consecutively predetermined times. Otherwise, TX
gain is decreased by fixed amount with variable gain down period.


1.2.1.1.2.2 Reverse Link Power Control
Definition
reverse link power control algorithm. All relevant configurable parameters
shall be examined and tested to insure proper behavior.

Verification of functional performance of reverse link power control.

Be able to set up Tx gain value and outerloop power control threshold
value optionally for test at SVC .
SVC has receive frame rate and relevant outerloop power control
threshold value output in period of 20msec.
Open Loop Power Control Test
1. Connect test terminal to mobile DM. Test terminal is set up toward
ignoring PCSC bit through DM.
2. Set up Markov call and fix test terminal during call.
3. Change Tx gain value with SVC debugger and observe Tx power
level change of test terminal simultaneously.

Closed Loop Power Control Test
1. Connect test terminal to mobile DM.
2. Set up Markov call and fix test terminal during call.
3. Fix outerloop power control threshold value to nominal value with
DRAFT 3/1/97


73
SVC debugger and control Tx gain value until Tx power level of test
terminal keeps up certain level. ( Except Outerloop power control )
4. After setting up the maximum outerloop power control threshold
value with SVC debugger, observe Tx power level change of test
terminal.
5. After setting up the minimum outerloop power control threshold
value with SVC debugger, observe Tx power level change of test
terminal.

Outer Loop Power Control Test
1. Connect to SVC the terminal that can log print message printed from
SVC as file.
2. Set up Markov call.
3. Move test terminal to change reverse link environment enough.
4. Analyze data logged as file.

Minimum Standard
1. Open loop power control : PS Tx power has to increase and decease in
reverse proportion to Tx gain change.
2. Closed loop power control : If PS signal Power level received at BTS is
lower than outerloop power control threshold value, PS Tx power has
to increase , otherwise PS Tx power has to decrease.
3. Outer loop power control : If BTS receive frame rate is primary likely
or erasure, outerloop power control threshold value has to increase ,
otherwise it has to be decreased or keep current value.


DRAFT 3/1/97


74
1.2.1.1.3 Handoff
1.2.1.1.3.1 Intra-BSC Soft Handoff
Definition
This test shall be conducted to verify the functional performance intra-BSC
soft handoff. This includes tests verifying various combinations of softer and
soft and hard handoff. Latency times shall also be examined. All relevant
configurable parameters shall be examined and tested to insure proper
behavior.
Verification of functional performance of intra-BSC soft handoff.
Attenuator.
1. Confirm whether two BTS to test are normal and 2 cells between BTS
overlap sufficiently.
2. These 2 BTSs have to belong to same BSC.
move to other Target Cell and generate soft Handoff ADD procedure.
Confirm ADD procedure by monitoring Active pilot set or by
logging the following messages in Mobile DM. Confirmation
messages : PSMM (Pilot Strength Measurement Message), EHDM
(Extended Direction Message), HCM (Handoff Complete Message)
5. Move to Target Cell with being ADD and confirm Handoff control
Messages (PSMM, EHDM, HCM) to know whether soft handoff Drop
procedure to Serving Cell Pilot happens in Mobile DM.
Serving cell being DROP. At this time location must not get out of
Serving cell Area.

DRAFT 3/1/97


75
Minimum Standard
Fixed call has to be held up at the test procedure of Intra BSC Soft
Handoff and in case of processing all handoff procedures (ADD or
DROP) BTS response time (Time difference between PSMM transmit and
EHDM receive) that is measured in Mobile DM has to be less than 250
ms.
(Reference : Most of the time that is PS retry time and BS_Ack_Order
retry time to PSMM increases more and more in case of bad radio
frequency environment.)

1.2.1.1.3.2 Intra-BSC Inter-Carrier Hard Handoff
Definition
This test shall be conducted to verify the functional performance intra-BSC
hard handoff. Latency times shall also be examined. All relevant
behavior.
Verification of functional performance of intra-BSC hard handoff.
Be able to test in LAB without moving PS by controlling Pilot strength
with Attenuator.
2 Cells that handoff happens to have to perform 2 Carriers (2 CDMA
CH: 1st FA, 2nd FA) normally for this handoff test.
Also Traffic Channel Resource of Target 1 st FA has to be removed to test
from Serving 1st FA to Target 2nd FA.
(Set up and test as followings to avoid difficulty of TC removal with
Debugger Command of Target BTSs BSP. Command: ho_mode)
DRAFT 3/1/97


76
2. Block all TC resources in 1 st FA of Target Cell at BSM.
( Or input 3 (FA Hard Handoff) to Debug Command, ho_mode at
Target BSP and set up generation of hard handoff by carrier change
compulsorily)
3. 1st FA of Serving BTS has 2 MS that call is set up and set up two call
(one is Markov call and the other is Mobile-to-Land Call ) as 1 st FA
at Serving BTS.
move to other Target Cell and generate hard Handoff . Confirm hard
handoff by monitoring Active pilot set or by logging the following
messages in Mobile DM.
Confirmation messages : PSMM(Pilot Strength Measurement
Message), EHDM(Extended Direction Message), HCM(Handoff
Complete Message)
handover to Target Cell . At this time location must not get out of
serving cell area.

Minimum Standard
Fixed call has to be held up at the test procedure of Inter BSC Soft
Handoff and in case of hard handoff procedures (ADD or DROP) BTS
response time(Time difference between PSMM transmit and EHDM
receive) that is measured in Mobile DM has to be less than 300 ms.

DRAFT 3/1/97


77
1.2.1.1.3.3 Inter-BSC Same Vendor Soft Handoff
Definition
This test shall be conducted to verify the functional performance inter-BSC
soft handoff. This includes tests verifying various combinations of inter-BSC
soft and hard handoff. Latency times shall also be examined. All relevant
behavior.

Verification of functional performance of inter-BSC soft handoff.

Attenuator.
2 BSC have to be connected mutually with CCIN Device in order that handoff
between Inter BSC is completed as Soft Handoff .

2. These 2 BTS have to belong to different BSC.
Land Call in serving cell.
move to Target Cell and generate soft Handoff ADD procedure.
Confirm ADD procedure by monitoring Active pilot set or by
logging the following messages in Mobile DM.
Confirmation messages : PSMM (Pilot Strength Measurement
Message), EHDM (Extended Direction Message), HCM (Handoff
Complete Message)
5. Move to target cell with being ADD and confirm handoff control
DRAFT 3/1/97


78
messages (PSMM, EHDM, HCM) to know whether soft handoff Drop
procedure to serving cell pilot happens in mobile DM.
serving cell being DROP. At this time location must not get out of
serving cell area.

Minimum Standard
Fixed call has to be held up at the test procedure of Inter BSC Soft
Handoff and in case of hard handoff procedures (ADD or DROP) BTS
response time (Time difference between PSMM transmit and EHDM
receive) that is measured in mobile DM has to be less than 250 ms.



1.2.1.1.3.4 Inter-BSC Hard handoff
Definition
This test shall be conducted to verify the functional performance inter-BSC
hard handoff. Latency times shall also be examined. All relevant
behavior.

Verification of functional performance of inter-BSC hard handoff.
Attenuator.
DRAFT 3/1/97


79
2 Cells that handoff happens to have to perform 2 Carriers (2 CDMA CH: 1st
FA, 2nd FA) normally for this handoff test. These 2 cells have to belong to
different BSC.
Also Traffic Channel Resource of Target 1 st FA has to be removed to test
from Serving 1st FA to Target 2nd FA.
(Set up and test as followings to avoid difficulty of TC removal with
Debugger Command of Target BTSs BSP. Command: ho_mode)

1. Confirm whether each FA of two BTS to belong to different BSC are
normal and 2 cells between BTS overlap sufficiently.
2. Block all TC resources in 1 st FA of Target Cell at BSM.
( Or input 3 (FA Hard Handoff) to Debug Command, ho_mode at
Target BSP and set up generation of hard handoff by carrier change
compulsorily)
3. 1st FA of Serving BTS has 2 MS that call is set up and set up two call
(one is Markov call and the other is Mobile-to-Land Call ) as 1 st FA
at serving BTS.
move to other Target Cell and generate hard handoff . Confirm hard
handoff procedure by monitoring Active pilot set or by logging the
following messages in Mobile DM.
Confirmation messages : PSMM(Pilot Strength Measurement
Message), EHDM(Extended Direction Message), HCM(Handoff
Complete Message)
handover to Target Cell . At this time location must not get out of
serving cell area.
DRAFT 3/1/97


80
Minimum Standard
Fixed call has to be held up at the test procedure of Inter BSC soft
handoff and in case of handoff processing procedures (ADD or DROP)
BTS response time(Time difference between PSMM transmit and EHDM
receive) that is measured in Mobile DM has to be less than 300 ms.


1.2.1.1.4 Load Management
1.2.1.1.4.1 Heavy Breathing
Definition
This test shall be conducted to verify the functional performance of heavy
breathing. All relevant configurable parameters shall be examined and tested
Verification of heavy breathing functional performance.
Detailed breathing parameter is determined leter.
1. Set up parameter related to breathing with CHG-PWR-PARA at BSM.
2. Maintain relevant cell or sector with being disable(wilting).
3. Enable(blossoming) cell or sector at BSM.
4. Confirm transmit total power increases gradually by Power Meter
installed at TXMA or TXFS.
DRAFT 3/1/97


81
5. Confirm Transmit total power dont increase any more with it unload
when blossoming is complete and maintains as overhead channel Tx
power of max coverage.
6. Disable(wilting) cell or sector at BSM.
7. Confirm transmit total power decreases gradually by Power Meter
installed at TXMA or TXFS.
8. Confirm Transmit total power isnt active any more when wilting is
complete.

Minimum Standard
Confirm that transmit total power increases or decreases gradually,
maintains certain power when blossoming is complete with it unload and
Tx total power isnt active any more when wilting is complete.

1.2.1.1.4.2 Breathing
Definition
This test shall be conducted to verify the functional performance of dynamic
breathing. This testing shall include load and interference tests designed to
measure the effective breathing algorithm and its ability to keep the forward
and reverse links in balance. All relevant configurable parameters shall be
examined and tested to insure proper behavior.
Verification of cell breathing functional performance.
Detailed breathing parameter, threshold, maximum, minimum coverage
power and command are determined later.
1. Hold up normal BTS capable of call set-up with being unloaded.
DRAFT 3/1/97


82
2. Confirm Power Management Parameter with DIS-PWR-PARA
command in BSM and if value is not fixed, change parameter by
performing CHG-PWR-PAR.A.
3. Measure relevant sector, relevant FAs flower attenuator value,
received total power, transmit total power, upc gain etc. with
(TBD)command at BSP or RFP debugger.
4. Confirm whether received total power increases or decreases by
setting up real call or changing attenuator value with (TBD)command.
5. Confirm whether upc gain and transmit total power change by
received total powers change. Confirms if change of transmit and
receive is satisfied with breathing algorithm.

Minimum Standard
Confirm whether increase and decrease of received total power are
measured and accordingly, confirm control of transmit total power.
Confirm whether transmit power is transmitted with maximum coverage
with it unload or with minimum coverage when receive power reaches
threshold.

1.2.1.1.4.3 Load Control
Definition
This test shall be conducted to verify the functional performance of load
control. This includes traffic redirection, access control and overload control
mechanisms associated with the system. All relevant configurable
parameters shall be examined and tested to insure proper behavior.
Verification of load control mechanisms and functional performance.
Detailed threshold is determined later and if not capable of reaching
DRAFT 3/1/97


83
threshold after call set-up, be able to use noise injection .
1. Maintain normal BTS capable of call set-up and being operated as 2 FA
with being unloaded.
2. Set up reverse link resource call block and handoff block threshold at BSM
or BSP debugger.
3. Attempt call to particular FA and lets it reach call block threshold.
4. In case of attempting new call and exceeding threshold , set up call to other
FA below threshold.
5. Confirm redirection with BSP output message and message logging in
Mobile DM..
6. Attempt to handoff block state with flowing in handoff call.
7. Confirm whether hard handoff set-up is completed to other FA below
threshold with attempting handoff Call.
8. In case of operating BTS as 1 FA and not being able to redirect to another
BTS, confirm whether call is restricted by attempting 3.~7. .
9. Mediate TC resource to be below each threshold at BSM, attempt 3.~7. and
confirm whether call is restricted or redirected.
10. Set up forward link excess capacity threshold and HPA or LPA Limited
Power threshold , attempt 3.~7. and confirm function.
Minimum Standard
Confirm whether call restriction and redirection are completed as above
procedures.
DRAFT 3/1/97


84
1.2.1.1.4.4 Congestion Control
Definition
This test shall be conducted to verify the functional performance of
congestion control. All relevant configurable parameters shall be examined
and tested to insure proper behavior.
Verification of congestion control functional performance.
1. Make the loaded condition(CPU load : 91~95.99%) by inducing
processor load.
2. Try mobile originated call.
3. Check the origination call failure.
4. Make the loaded condition(CPU load >= 96%) by inducing processor
load.
5. Repeat step 2 and 3.
6. Try mobile terminated call.
7. Check the termination call failure.
8. Make the unloaded condition by reducing processor load.
9. Repeat step 2 through 6.
10. Check the successful acquisition of traffic channel.

Refer to Processor Overload Management Test in the LGIC COD and POD.

Minimum Standard
Confirm whether processor overload management is completed as above
procedures.

DRAFT 3/1/97


85
1.2.1.2 Call Control
1.2.1.2.1 RF Carrier Assignment
Definition
This test shall be conducted to verify the functional performance of RF carrier
assignment. This includes aspects related to call origination and call
redirection. All relevant configurable parameters shall be examined and
tested to insure proper behavior.
Verification of RF carrier assignment functional performance.
1. Maintain BTS operated as FA 2 with capable of establishing normal set-up
call.
2. Provide mobile operated with FA1 and FA 2 each by hashing mobile
number.
3. Attempt Origination at mobile operating with FA1 and logging message
in Mobile DM.
4. Analyze logging data and confirm whether CDMA CH assigned to
Channel Assignment Message is FA1.
5. Attempt Origination call at mobile operating with FA 2 and logging
message in Mobile DM.
Channel Assignment Message is FA 2.
7. Block TC resource of FA 2 at BSM.
8. Attempt Origination at mobile operating with FA 2 and logging message
in Mobile DM.
Channel Assignment Message is redirected to FA 1.
10. Unblock TC resource of FA 2 and block all TC resources of FA1 at BSM.
11. Attempt Origination at mobile operating with FA 1 and logging message
in Mobile DM.
Channel Assignment Message is redirected to FA2. ( Reference :
Assignment based on load balancing is confirmed at 1.2.1.1.4,3 Load
Control)
Minimum Standard
Confirm whether CDMA Channel is assigned correctly as above procedures.
DRAFT 3/1/97


86
1.2.1.2.2 Service Options
Definition
This test shall be conducted to verify the functional performance of all
supported services options. This includes functional testing of:
- Service Option 1 (Variable Rate speech) as defined in IS-96A.
- Service Option 2 (Rate Set 1 Loopback) per IS-126A.
- Service Option 3 (EVRC, Enhanced Variable Rate Codec) per IS-127.
- Service Option 4 (Async Data rate set 1) per IS-99.
- Service Option 5 (Group 3 Fax rate set 1) per IS-99.
- Service Option 6 (SMS) per IS-637
- Service Option 7 (Packet Data) per IS-657.
- Service Option 9 (Rate Set 2 Loopback) per IS-126A.
- Service Option 10 (STU-III) per PN-3571
- Service Option 12 (Async Data rate set 2)
- Service Option 13 (Group 3 Fax rate set 2)
- Service Option 0x8000 (Qualcomm proprietary 13kbps speech).
- Service Option 0x801E (Rate Set 1 Markov mode)
- Service Option 0x801F (Rate Set 2 Markov mode)
In addition, the tests will address the concurrent operation of the system with
distinct and multiple service options. Finally, the functional performance of
simultaneous voice and data service options will be examined and verified as
well.
Verification of functional performance of multiple service options.
. The availabilities of Service Options

1) 2Q97
Service option 1 (8K Speech)
Service option 2 (Rate Set 1 Loop back)
Service option 9 (Rate Set 2 Loop back)
Service option 0x8000 (Qualcomm 13K speech)
Service option 0x801E (Rate Set 1 Markov Mode)
Service option 0x801F (Rate Set 2 Markov Mode)
DRAFT 3/1/97


87

2) 4Q97
Service option 6 (SMS per IS-637)

3) 1Q98
Service Option 3 (EVRC)
Service Option 4 (Async Data per IS-99)
Service Option 5 (G3 Fax per IS-99)

4) 2Q98
Service Option 7 (Packet Data)

5) Partial Compliances
Service Option 10 (STU-III) per PN-3571
Service Option 12 (Async Data rate set 2)
Service Option 13 (G3 Fax rate set 2)
The specifications of the upper service options (10, 11, 12) have not been
completed yet. Once complete specifications are released, we will
implement these service options within 1 year.

Service Option 1 ( Variable Rate Speech )
1. Set call set up is assigned to Service Option 1 (8K) by using System
Mode of PS.
2. Attempt Mobile-to-Land Call, Land-to-Mobile Call and Mobile-to-
Mobile Call by using PS assigned to 8K.
3. Confirm Service Option and call situation attempted each at Mobile
DM.
4. Release set-up call.

DRAFT 3/1/97


88
Service Option 2 ( Rate Set 1 Loopback ) per IS-126A.
1. Assign Test Call Mode for Rate Set 1 Loopback at any PS and set up
Test Call.
DM.
4. Request test Call for Rate Set 1 Loopback Call at BSM. Namely, set
up identifier ( BSC No, BTS No, Sector No,..), various parameter and
service option as Loopback and also set up terminating call by paging
with rate setting as 1.
5. Confirm Service Option and call situation at Mobile DM.

Service Option 9 ( Rate Set 2 Loopback ) per IS-126A

1. Assign Test Call Mode for Rate Set 2 Loopback at any PS and set up
Test Call.
DM.
3. Release set-up call .
4. Request test Call for Rate Set 2 Loopback Call at BSM. Namely, set
up identifier ( BSC No, BTS No, Sector No,..), various parameter and

Service Option 0x8000 ( Qualcomm proprietary 13kbps speech )
1. Set call set up is assigned to Service Option 1 (8K) by using System
Mode of PS.
2. Attempt Mobile-to-Land Call, Land-to-Mobile Call and Mobile-to-
Mobile Call by using PS assigned to 13K.
DM.

DRAFT 3/1/97


89
Service option 08002 or 0801E (Rate Set 1 Markov Mode)
1. Assign Test Call Mode for Rate Set 1 Markov at any PS and set up
Test Call.
DM.
4. Request test Call for Rate Set 1 Markov Call at BSM. Namely, set up
identifier ( BSC No, BTS No, Sector No,..), various parameter and
service option as Markov and also set up terminating call by paging

Service option 0x801F (Rate Set 2 Markov Mode)
1. Assign Test Call Mode for Rate Set 2 Markov at any PS and set up
Test Call.
DM.
4. Request test Call for Rate Set 2 Markov Call at BSM. Namely, set up
identifier ( BSC No, BTS No, Sector No,..), various parameter and

Minimum Standard
Functional compliance with NextWave Telecom requirements.
DRAFT 3/1/97


90
1.2.2.1 Quality of Service
1.2.2.1.1 Voice Latency
Definition
This test shall be conducted to verify the voice latency performance of the
system. This includes mobile-to-land, land-to-mobile and mobile-to-mobiles
calls.

Verification of voice latency performance.


1. Connect personal stations and logic analyzer as following figure.

PS-0
Audio
output
Audio
input
Audio
output
GND GND GND
PS-1 PS-2
probe 2
probe 1
GND
Logic Analyzer

DRAFT 3/1/97


91
2. Setup mobile to mobile call between PS-1 and PS-2.
3. Press any key on the key pad of PS-0 results in DTMF tone to the PS-1s
audio input.
4. Measure the time differrence between the two DTMF tone wave
triggered on the logic anlayzer. (Mobile to mobile voice latency)

Minimum Standard
Voice latency of Mobile-to-Land (or Land-to-Mobile) has to be below
280/2 msec.
Voice latency of Mobile-to-Mobile has to be below 280 msec.


1.2.2.1.2 Frame Error Rates
Definition
This test shall verify the functionality of the ability to vary the operating FER
threshold associated with a service option. The full dynamic range of the FER
threshold shall be examined as well as the step sizes.
Verification of FER threshold adjustment functional performance.
This test is just oriented to the verification of the ability to apply
differrent target FER according to service options.
For the test, SVC prints out reverse link FER and service option at the
end of every test call.
1. Connect test PS(Personal Station) to mobile DM.
2. Connect a terminal to SVC.
3. Set the target FER of 8 Kbps Markov and 13 Kbps Markov to the value of
1% and 3% respectively through command window of BSM.
4. Setup 8 Kbps Markov call using test PS, then move the test PS enough to
change the condition of air link.
DRAFT 3/1/97


92
5. After appropriate time, release the call, then record the forward link FER
through mobile DM, and the reverse link FER through the terminal
connected to SVC.
6. Repeat step 4 and 5 for 13 Kbps Markov call.
Minimum Standard
For the 8 Kbps Markov call, both the values of forward and reverse link
FER should be equal to 1%.
For the 13 Kbps Markov call, both the values of forward and reverse link
FER should be equal to 3%.
Between a target FER and the result, about 15 % of deviation can exist.
DRAFT 3/1/97


93
1.2.2.2 Capacity
Definition
The capacity of BSC shall be verified in these tests. The capacity shall be
examined from both a hardware perspective and a call processing
perspective. Call models defined in Appendix E shall be used in evaluating
the Erlang capacity and BHCA capacity of the BSC.
Verification of BSC capacity.
Simulation Description
Generate virtual call and produce capacity with using simulation that
generates and processes as similar call as real situation. Namely, analyze
performance and measure load put on when CCP processor processes call
with generating and processing virtual call by simulator.

1. Busy Hour Registration Attempt (BHRA)
Generate virtual location registration call with using simulation and
produce performance by measuring load of CCP.
2. Busy Hour Call Attempt (BHCA)
Generate various types of call with using simulation and produce
performance by measuring
load of CCP.
2.1 M-T-L Call Capacity
2.2 L-T-M Call Capacity
2.3 M-T-M Call Capacity
3. Busy Hour Handoff Attempt (BHHA)
Generate virtual handoff with using simulation and produce
performance by measuring load of CCP.
3.1 Softer Handoff Call Capacity
3.2 Soft Handoff Call Capacity
4. Performance Product when processing Complex Call
Generate Complex types of Calls (Example: location registration call +
general call, handoff call + location registration call...) with using
simulation and produce performance by measuring
load of CCP.

5. BSC Performance Product Method using Simulator
Assumption Value (Assumption Value for Performance Analysis of
Qualcomm CDMA System )
DRAFT 3/1/97


94
Traffic per Subscriber : 0.024 Erlang
Maximum Vocoder Number : 1920 VE
Maximum Accommodation Call per BSC : 80,000 BHCA
( 1920/0.024)
Termination / Origination Call Rate : 60 %(Origination Call)
/ 40 %(Termination Call)
Location Registration Number per Subscriber : 6
Times/Hour (per 1 Mobile)

Measurement Parameters for performance estimation
We can measure several CCP loads by changing call setup
interval as the below.

BHCA call interval
20,000 360 msec m-to-m: 2 call
40,000 180 msec
60,000 120 msec
80,000 90 msec

How to use Simulator

1. Simulator Overview
Virtual call process simulator that is realized to measure call process
performance of BSC CCP in STAREX-1900 implemented the role of each
system component including MSC,BSC and BTS as if real Call process
situation happened.
This simulator can perform 4 types of simulation (TYPE1, TYPE2, TYPE3,
and TYPE4 ). TYPE1 is the type that once a call is completed by normal
call set up procedure, the call holding time keeps up until user stops the
call. TYPE2 is the simulation that performs release procedure after certain
delay time defined by user once call is set up. Also TYPE3 and TYPE4 are
similar to TYPE1 and TYPE2 but are the simulators that load to handoff
process is considered. Also simulator is implemented to be able to perform
situation process separately.

2. Simulation Function
Configure and provide function of system component related to all call
process except PS in CCP to simulate process procedure of general call and
MARKOV call. By doing so, be able to set up normal call, measure load
generated when CCP processes call and use in its performance
improvement.
These principal functions are as followings.

DRAFT 3/1/97


95
2.1 Interface between BSC and BTS
In case of including real MSC and performing simulation, complete all call
process procedure of terminating and originating between virtual BSP and
SBP. At this time simulator plays roles of BSP and SBP. First in case of
operating function that calls simulator in debug (input bcg), create call
corresponded to each simulation and require call process.
Interfaced with CCP and set up to a complete call, simulation checks
various situation of these calls and displays statistics related to these
( Example: originating attempt number, terminating attempt number, call
success number, number of calls that line is busy, assigned channel
number etc. ..)
After certain Delay time (related to variable hold_time ) passed in type
1s case, require call release to transmitting part and process call release
procedure. It performs the same call release procedure as Release_B2C,
Release_C2B, Release_S2C, RelComp_C2S etc. for procedure that CCP
releases two device of BSP and SBP connected to itself in this release
procedure. In another call releases case that input q to quit simulation
being operated, check all calls that line is busy , are setting up call or are
remained during release after waiting for a while (related to various
sleep_time) and send release signal to them. And simulation is stopped
completely by performing all call release procedures following above
methods with CCP.

2.2 Interface among BSC , BTS and MSC
In case of setting up call without real MSC, entire call process procedure is
completed by playing not only the role of BSP and SBP but also the role of
MSC . Another entire process procedures of simulator are same as above
2.1 but there are differences that additional messages used to connection
and release with MSC are needed and MSC release is checked and then
stop. At this time variable pcsc_type is used as factor controlling
interface with MSC.

2.3 Process Function of General Call and MARKOV Call by Service Option
If service Option is assigned to MARKOV, call process procedure has to be
completed on the condition excluding MSC. (There was a part playing a role of
MSC either real MSC or a part of simulation above but in this case a part playing a
role of MSC is omitted.) If service option is assigned to general call, call process
procedure is same as above 2.1 or 2.2 descriptions one and variable related to the
option control is service_option.

2.4 Origination Only Simulation Function
This function is that simulator didnt process all call process procedures
but processes only origination and continue to repeat only process
procedure of Mobile-To-Land call and procedure paging to termination
part is omitted. Simulation like this can generate data comparable to load
DRAFT 3/1/97


96
rate put on CCP in both origination case and termination case. Operation is
same as present simulation. Also this function can determine whether to
simulate, to originate only or to terminate only. Another various option
control or variable control is perfectly same as existing one. (example:
bsc_type, sleep, time, pcsc_type, callmode, channel number, interval
between originating call etc.)

2.5 Paging Only Simulation Function
This function is the routine that performs only process procedure of Land-
To-Mobile call to termination part during all call process procedures like
origination only simulations case in 2.4 ( related to variable bsc_type).
CCP makes normal paging procedure that sends GenPaging_C2B to BSP.

2.6 Registration Simulation Function
Simulation generates PS location registration situation and can measures
CCP capacity when registering location. At this time PS number registering
location, time interval attempting location registration and location
registration type are main input values. This function can choose method
excluding MSC and method including MSC and start it. This is started by
PCSC Type.

3. Command and Parameter relevant to Simulation
3.1 bcg
Input this command in debug and simulation can be operated. This
simulation is BCG(Bulk Call Generation) type. After simulation is started
by this command, it can assign each necessary option and display
operation result completed on monitor.

3.2 callmode
This is a variable related to command mode and a factor to determine
whether simulation is Mobile To Mobile or Mobile To Land. Mode ( 0 or
1 ) is input in debug, Mobile To Land call is set up if parameter is 0 and
Mobile To Mobile call is set up if parameter is 1.
This command needs an agreement to MSC, VLR and Number is used in
simulation including MSC.

3.3 pcsc_type
This is a variable related to command pcsc. If input parameter of pcsc
( 0 or 1 ) is 0, it performs simulation including real MSC. If input parameter
of pcsc ( 0 or 1 ) is 1, simulation performs operation including MSC role
except real MSC.

3.4 member
This is a variable related to command member. It can determine whether
to only perform originating operation or to only perform terminating
operation or to perform original call including original parties both. If input
DRAFT 3/1/97


97
parameter is 0, Mobile-To-Land call is only performed.
If input parameter is 1, Land-To-Mobile call is only performed and if input
parameter is 2, original Mobile-To-Mobile call is set up.

3.5 bts
This is a parameter input command attempting call and assigning particular
BTS when generating simulation call.
3.6 base
This is a parameter input command controlling simulation operation like
bts and used in assigning BASE.

3.7 zone
This is a parameter input command assigning particular ZONE when
processing paging on simulation.

3.8 time
This is a parameter input command used in Type 2s or Type 4s case. It
also assigns time interval for call release after successful call connection
and certain passage of time (related to variable hold_time ). Input time
(desirable time|second| ) for using this command, and as call condition
as input second and time is kept up and then call is released.

3.9 interval
This is one of options capable of seeing on basic input scene of simulator
and determine how much interval is put per interval of each call attempt.
If interval is set up to 1000, this means origination is attempted one a
second. Number input to parameter uses tick as unit and 1000 tick is
equal to 1 second.

3.10 count
This is a command setting up how many call are attempted
simultaneously when attempting call. If interval attempting call is 1
second and count is set up as 5, in this case origination of 5 calls are
attempted simultaneously at intervals of 5 seconds.

3.11 service_option
This is a command used in assigning service option of simulation call and
determines whether to assign general call or MARKOV call. . If input
parameter of service ( 0 or 1 ) is 0, it attempts general call. If input
parameter of pcsc ( 0 or 1 ) is 1, it attempts general call.

3.12 sleep
When performing simulation, situation setting up many calls in short
time happens but problem doesnt happen to set up and release of normal
call. If debug command q is input and normal call release procedure is
performed about all call being processed at once, a lot of time are needed.
DRAFT 3/1/97


98
At this time this command is a surplus time input parameter command to
release call normally. Parameter input in command sleep ( necessary
time (second) ) becomes a surplus time used in call release and the unit is
second. This command is related to variable sleep_time.
3.13 btspage
Simulation has the function that can play roles of BSP, SBP and MSC
generally. In some cases simulation doesnt perform function of BSP and
situation sending signal to real BSP and testing can be also considered. At
this time simulation sends only paging message to CCP and others may
not be processed and CCP makes paging to real BTS (Of course, this is the
case that performs only paging operation without origination operation).
Command btspage ( 0 or 1 ) is used to set up this case. If parameter is 0,
original simulation excluding real BTS is performed. If parameter is 1,
paging operation including real BTS can be performed. This command is
related to variable btspage.
If set up including real BTS with this command is done, value of variable
member is set up to 1 automatically . This helps smooth performance of
paging operation.

3.14 ccpadr
CCP to simulate is appointed specifically and doesnt have same
address. Therefore Address of CCP needs to be appointed. At this time
address of CCP is appointed by using this command

3.15 dis
After assigning each option referred to above to perform simulation,
input command dis when confirming whether the set up is correct.
Input dis, and simulator displays the following information
(1) CCP number (2) BASE id
(3) Service Option (4) Network id
(5) Zone id (6) Sleep time
(7) BSC type (8) PCSC type
(9) Member (10) BTS page
(11) Hoff type (12) BTS number
(13) Sector number (14) Hold time
(15) BTS Configuration

3.16 result
DRAFT 3/1/97


99
Input command result" to confirm whether to operate correctly and
processing states until present while simulation is operating. If result" is
input, simulation displays call process statistics completed until the
moment and includes the following information.
(1) Entire channel number
(2) Interval (3) Hold time
(4) Call Count (5) Number of call during
conversation (6) Number of call attempted
(7) Number of call attempted and succeeded
(8) Number of call succeeded in paging
(9) Number of call succeeded in processing entire call process
procedures

3.17 reg
This is a location registration generation command used to measure
capacity to location registration. The main parameter are number of PS
registering location, attempt time and location registration type. This
command is started separate with above call generation command and
shows result to performance procedure (attempt number, succeed
number, failure number).For example, reg 100 100 1 means location
registration simulation that is performed as location registration type 1
in the period of 100MS with 100 PSs registered in simulator.
Attempt call of 20,000 BHCA, 40,000 BHCA, 60,000 BHCA, and 80,000
BHCA with simulator. Measure call process loads of BSC and produce
performance.
Attempt call of complex types (location registration, handoff call, general
call...), measure call process load of BSC and produce performance.
Minimum Standard
CCP CPU Over Load has to be below 85% for 80,000 BHCA performance
that is a target value.
Vendor response to failure: diagnosis and action

DRAFT 3/1/97


100
1.2.2.3 Timing accuracy
Definition
This test shall be conducted to verify the timing accuracy of the system in the
absence of GPS-based timing. This includes evaluation of the transient
system performance when system timing is removed and introduced, as well
as the steady state performance of the system timing in the absence of GPS
timing. Testing shall be conducted over the full temperature range.

Verification of timing accuracy in the absence of GPS reference.
The GPS was subjected to holdover while undergoing exposure to a thermal
gradient for a period of 24 hours. The C2 algorithm engaged and made
correction to the DAC based on data learned during the previous two days of
operation. During this test the unit was exposed to a thermal gradient of
10C/hr.
Minimum Standard
The BSC shall maintain an accumulated timing error of less than 7 usec/day
when the GPS timing is not available.
10MHz
Accuracy <1 x 10
-10
Unlocked, one day average, after training
Phase Drift
Less than 7us per day(unlocked, after training
period for holdover operation)
Stability
< 1 x 10
-11
Allan Variance for 100 sec tau
Unlocked
1PPS
Accumulated time error Less than 7us per day(unlocked, after training )
DRAFT 3/1/97


101

1.3 MSC
1.3.1.1 Subscriber Class of Service (SCS)
Definition
The subscriber class of service (SCS) is a special identifier within the
NextWave network that designates an end user as belonging to a particular
group of users. The SCS has been devised to allow the customization of
service for various subscriber groups. The subscriber class may or may not
correspond to all users of a particular reseller or a subset thereof. Multiple
classes of service may reside in a single geographic area and utilize the same
set of physical facilities such as BTS, BSC, MSC, and trunks. The SCS of a
particular user is stored as a 2-byte field in the subscriber profile that the
MSC receives following a Registration Request to the HLR. The MSC utilizes
the SCS to make decisions regarding routing, special treatments, and call
quality.

The tests will validate the capability of the MSC to perform all necessary
tasks related to SCS. These include the following:
- SCS assignment and implementation guidelines
- call processing based on SCS
DRAFT 3/1/97


102
1.3.1.1.1 SCS Assignment
The system will associate an SCS with each registered subscriber. The SCS is
determined by one of the following methods, in order of preference:
- The SCS will be contained in an optional field of the Profile Macro sent to the
MSC as a result of a Registration Notification return result or Qualification
Directive from the HLR. The MSC shall then store the SCS in the subscribers
record in the VLR or other resident database. In this implementation, the SCS
field shall occupy a 48-bit field.
- If the optional SCS parameter is not contained in the Profile Macro, the MSC
shall assign an SCS based on the subscribers Mobile Station ID (MIN or IMSI).
The MSC shall be pre-provisioned with a MIN-to-SCS mapping table, obtained
from the operator at system configuration. The MIN-to-SCS mapping table
should index on the entire NPA-NXX-XXXX, and not be dependent on
contiguous NPA-NXX blocks.
In both implementations, the MSC shall provision an SCS look-up table in the VLR
or other resident database. The look-up table shall include the list of routing
instructions, treatments, and features for every valid SCS value. The look-up table in
the VLR shall be updated periodically by the OMC. Updates of the OMC data will
be performed directly by an operator.
In either of the above implementations, if the SCS value cannot be inferred (SCS
parameter not included in the Profile Macro or MSID does not fall into a range that
has been pre-provisioned at the MSCs MIN-to-SCS mapping table) then a default
SCS assignment shall be made. This case would include treatment of a roaming
subscriber whos home service provider does not have a roaming agreement with
NextWave. Table 4.1.1.1.2.1-1 summarizes these cases.
The vendor shall demonstrate that the particular implementation chosen by the vendor
adheres to the following guidelines.
The average overall set-up delay with SCS does not exceed the average overall set-up
delay without SCS by more than 20%. In other words, if the delay without SCS
implementation is 100 ms then the average delay with SCS shall not exceed 120 ms.
Compatibility with all IS-41-B and IS-41-C compliant HLRs, whether or not the
optional SCS field is implemented..
The vendor shall provide NextWave with a detailed document describing how the
SCS is implemented. The document shall include the following items
DRAFT 3/1/97


103
- SCS look-up table provisioning method
- Maximum size of the SCS table (number of records and size of each record)
- Delay statistics for query of the SCS look-up table (distribution or mean and 95
th

percentile)
- Reliability measures
- The method by which the SCS look-up table is updated by the OMC
- All messaging between the MSC/VLR and HLR for SCS implementation
- Total delay associated with SCS implementation (reading of SCS field value in
profile Macro or MIN/ESN translation, SCS look-up, other)
- Detailed description of SCS implementation for selection of a particular RF
carrier


SCS Assignment by optional field of the Profile Macro
1. This test assumes that RSDP is available and it inserts SCS field into Profile
Macro of RegistrationNotification response message from HLR.
2. Confirm interface condition among MSC, HLR, and RSDP is normal.
3. Confirm that tested PS is registered in HLR and that it is not registered in
VLR yet.
4. Register the PS in VLR.
5. Verify that the SCS field of the PS in VLR is as same as that in RSDP.

SCS Assignment by MIN-to-SCS table
1. This test assumes that the SCS filed by RSDP is unavailable for tested PS.
2. Set the SCS field of the PS in MIN-to-SCS mapping table by OMC or MSCs
MMC.
(The capacity of MIN-to-SCS mapping table in MSC has a certain limitation.
This limitation is TBD.)
(If setting the SCS field is executed by OMC, it must be confirmed that
interface condition between MSC and OMC is normal.)
3. Confirm interface condition between MSC and HLR is normal.
4. Confirm that the PS is registered in HLR and that it is not registered in VLR
yet.
6. Verify that the SCS field of the PS in VLR is as same as that of MIN-to-
DRAFT 3/1/97


104
SCS
mapping table in MSC.

SCS Assignment by default SCS
1. This test assumes that the SCS filed by RSDP as well as that by MIN-to-SCS
mapping table are unavailable for tested PS.
2. Set the default SCS value in MSC by OMC or MSCs MMC.
(If setting the default SCS value is executed by OMC, it must be confirmed
that interface condition between MSC and OMC is normal.)
3. Confirm interface condition between MSC and HLR is normal.
4. Confirm that the PS is registered in HLR and that it is not registered in VLR
yet.
6. Verify that the SCS field of the PS in VLR is as same as that of default SCS in
MSC.

Minimum Standard

1.3.1.1.2 Call Processing based on SCS
The SCS shall be used on a per-call basis for the following call processing
decisions:
- Number TranslationThe SCS shall be indexed in the Number
Translation process.
- RoutingThe SCS shall be indexed in the outgoing trunk group selection
process.
- Call TreatmentsThe SCS shall be indexed to select specific
announcements.
DRAFT 3/1/97


105
- Feature/Service AllowanceThe SCS shall be indexed to select which
features and services a subscriber may access. Only features and services
not accounted for in the standard IS-41-C Profile Macro will be selected
by the SCS. An example is which service options a subscriber is allowed
to use. RF carrier assignment shall also be based on service option.

The SCS requirements are specified in Part I, Section 2.1 of NextWave
Requirements for CDMA Infrastructure Vendors (September 6, 1996).

Figure 1

SCS DB
Subscriber
prof iles
HLR
SS7
Mobi l e
stati on
si mul ator
Trunk
si mul ators
VLR
MSC
A B C

1.3.1.1.3 SCS Assignment and Call Processing
DRAFT 3/1/97


106
Table 1 Provision MINs with Phone Numbers and SCS values in the HLF
Subscriber No. MIN/ESN NPA-NXX-XXXX SCS value
1 508-321-1223 1
2 508-465-2433 2
3 613-433-7868 3
4 508-332-1776 None

SCS Value Treatment
1 Route on trunk A, play announcement #1
Route on trunk D for HAD
Route on trunk E for HVD
2 Route on trunk B, play announcement #2
Route on trunk D for HAD
Route on trunk F for HVD
3 Route on trunk A, no announcement
Route on trunk G for HAD
Route on trunk E for HVD
Default Route on trunk C, play announcement #4
Route on trunk M for HAD
Route on trunk N for HVD
1. Simulate call originations by home subscribers 1-3 and monitor outgoing
trunk number and announcement.
2. Guarantee call fail during authentication by home subscribers 1-3 and
monitor HAD trunk number.
3. Guarantee call fail during authorization by home subscribers 1-3 and
monitor HVD trunk number.
4. Simulate call originations by home subscriber 4 and monitor outgoing
trunk number and announcement. Verify that default trunk and
announcement were selected.
5. Guarantee call fail during authentication by home subscriber 4 and
monitor HAD outgoing trunk number..
6. Guarantee call fail during authorization by home subscriber 4 and
monitor HVD outgoing trunk number.
DRAFT 3/1/97


107
7. Simulate call origination by a roaming subscriber (profile not stored in
HLR) and monitor proper routing to outgoing trunk and announcement.
8. Guarantee call fail during authentication by a roaming subscriber and
monitor proper routing to HAD outgoing trunk.
9. Guarantee call fail during authentication by a roaming subscriber and
10. Guarantee call fail during authorization by a roaming subscriber and
Minimum Standard
At the minimum, the MSC shall be able to perform the following tasks.
- Recognize a trunk group routing address in the subscriber Profile Macro
in the Registration Notification response message.
- Route a given call to a trunk group based on the obtained routing address.
- Recognize announcement sub-field in the subscriber Profile Macro in the
Registration Notification response message.
- Play announcement based on the obtained announcement sub-field
- Recognize HAD, HVD trunk group routing address in the subscriber
Profile Macro in the Registration Notification response message.
- Route a given call to a HAD trunk group based on the obtained routing
address if authentication fails.
- Route a given call to a HVD trunk group based on the obtained routing
address if authorization fails.
MSC functions are restricted as follows.
- Announcement Sources are restricted to 64.
. (30 for SCS greetings, 34 for call processing)
- Call processing announcement sources are not related to SCS.
- If call processing announcement sources are related to SCS, then
Nextwave shall provide LGIC with SCS to call processing announcement
sources document.


DRAFT 3/1/97


108
1.3.1.2 Call Setup Information
Definition
Call setup information includes SS7 messages and IS-41 messages. These
messages describe the basic message flow between the NextWave network
and other IS-41 networks in order to establish a call.

Purpose of the Test
These tests are performed in order to ensure the MSCs ability to generate the
appropriate messages to establish the signaling path and trunk setup needed
to connect to the called subscriber and the calling subscriber. To this end, the
MSC shall be capable of monitoring the following sets of IS-41 and SS7
messages as per T1.113 - SS7 ISDN User Part and IS-41 Revision C.

IS-41 messages:
OriginationRequest (ORREQ)
RegistrationNotification (REGNOT)
LocationRequest (LOCREQ)

SS7 messages:
Initial Address Message (IAM)
Continuity (COT) Message
Address Complete Message (ACM)
Answer Message (ANM)
Release (REL) Message
Release Complete (RLC) Message
Exit Message (EXM)

DRAFT 3/1/97


109
ISUP
1. Execute ISUP TRACE command with MMC so that you can trace ISUP
message for a given call after call is released.
2. Make a call through the route on which you have executed ISUP trace
command.
3. Release a call at calling side.
4. Check ISUP trace result.
5. Verify that an IAM is sent from origination SP to terminating SP.
6. Verify that an ACM is received at originating SP.
7. Verify that an ANM is received at originating SP, and the circuit
connection is made.
8. Verify that a REL is sent from originating SP to terminating SP.
9. Verify that a RLS is received at originating SP.

IS-41-C
1. Verify interface status between HLR and MSC is normal.
2. Choose one PS belonging to HLR as a test target.
3. Execute proper MAP TRACE command with MMC so that you can trace
OriginationRequest, RegistrationNotification, and LocationRequest MAP
messages for the PS.
4. Power down the PS.
5. Delete the PS in VLR.
6. Power up the PS.
7. Verify RegistrationNotification INVOKE message is transmitted to HLR
on MAP trace.

8. Verify RegistrationNotification RETURN RESULT message is received
from HLR on MAP trace.
9. Verify the PS is registered in VLR.
10. A calling party who is available of call origination make a call to a PS..
DRAFT 3/1/97


110
11. Verify LocationRequest INVOKE message is transmitted to HLR on
MAP trace.
12. Verify LocationRequest RETURN RESULT message is received from
HLR on MAP trace.
13. Verify call is received at the PS.
14. Activate origination trigger point for revertive call for PS in HLR.
15. Dial its DN at the PS.
16. Verify OriginationRequest INVOKE message is transmitted to HLR on
MAP trace.
17. Verify OriginationRequest RETURN RESULT message is received from
HLR on MAP trace.

Minimum Standard


Vendor Response to Failure: Diagnosis and action plan

DRAFT 3/1/97


111
1.3.1.3 Dialing Procedures and Call Processing Treatments: Numbering Plans
Definition
To test the MSCs capability to appropriately interpret user dialing actions
and associated call processing treatments of dialed numbers.
The dialing plan to be satisfied will be based on ANSI-660 Uniform Dialing
Procedures and Call Processing Treatment for Wireless Telecommunications.
ANSI-660 (formerly known as IS-52 revision A) is compliant with the North
American Numbering Plan, ITU E.212, and ITU E.164.

Purpose of Test
Tests will require test mobile directory numbers, test PSTN directory
numbers, dedicated trunk groups to interexchange carriers, trunk groups to a
local exchange carriers access tandem, and trunk groups to local exchange
carrier operator services tandem.
Coordination with personnel from other service providers will be essential.
Call treatments will be based on particular types of dialed number strings.
The specific call treatment to be made is dependent on the particular dialed
number address, business policies, bilateral agreements, and regulatory
concerns.
Prerequisite
The following network shall be ready, and the inter network protocol will be
POI-T4,POI-S5, POI-T6, POI-S7, POI-T8, POI-S9, POI-T10 or POI-S11
according to the configuration condition.

DRAFT 3/1/97


112

Local
Tandem
Access
Tandem
911Tan
dem
Operatir Service
Tandem
M S C
Type 2B
Type 2A
Type 2A
Type 2C
Type 2D
SS7
Sig. Pt.
Type S
L E C

Also, the following conditions shall be met in advance for test 1.3.1.3 element.
1. Check number and routing related data to confirm availability of call
setup. If not available, execute appropriate data work to enable call
setup.
2. Start test after verifying MSC is interworking properly with various
network elements of LEC, Local Tandem, Access Tandem, 911 Tandem,
Operator Service and Tandem.
3. Among the various interface protocol, POI-T1, POI-T2, POI-T3 will be
excluded in the test procedures.
DRAFT 3/1/97


113
1.3.1.3.1 Mobile Directory Number Assignment:
Test mobile directory numbers shall consist of at least 3 different NPA-NXX-
XXXX strings. These number strings shall be assigned to mobile handsets.
Test calls shall be made between mobiles. These test calls shall be made
within the home system and outside of the home system. Two of the NPA-
NXX-XXXX strings shall use two different NPAs. These two NPAs may be
assigned (by the local exchange carrier) for service within the same
geographic serving area.

1.3.1.3.2 PSTN Directory Number Assignment:
Test PSTN directory numbers shall involve at least 4 different NPA-NXX-
XXXX strings. These number strings shall be assigned to landline telephone
devices. These NPA-NXX-XXXX strings shall use different NPAs from at
least two different local exchange carriers. Test calls shall be made from each
test mobile directory number to each test PSTN directory number.

1.3.1.3.3 Interexchange Carrier Involvement:
Test calls shall involve shall involve all interexchange carriers providing
service to subscribers within the test area.
Trunk Group Assignments:
- Dedicated: Test calls shall be made to the interexchange carrier via trunk
groups that have been dedicated to the interexchange carrier.
- Non-Dedicated: Test calls shall be made to the interexchange carrier via
the local exchange carrier access tandem via shared trunk groups.

1.3.1.3.4 Other Carrier/Service Provider Involvement
Call delivery to roamers shall be tested from the Home system to the Visited
system and vice versa. Cooperation from another wireless service provider
or an international carrier is not required.
DRAFT 3/1/97


114
1.3.1.3.5 Call Types/Dialing Test Plan
The following call types represent dialing patterns typically used by mobile
subscribers.

Call Type Dialed Digits Pattern

7-digit NANP address NXX + XXXX
10-digit NANP address [1] + NPA + NXX + XXXX
Home NPA directory assistance (home subscribers
only)
555 + 1212
Other NPA directory assistance [1] + NPA + 555 + 1212
700 service access code 1 + 700 + NXX + XXXX
International 011 + CC + NSN
Emergency services 911
Directory assistance [1] + 411
N11 service code N11
Serving system service code *N11
Home system feature code *FC
Serving system feature code **FC
IC or INC cut-through CAC[#]
4-digit 950-CIC IC 950 + XXXX
7-digit with CAC (home subscribers only) CAC + NXX + XXXX
10-digit with CAC CAC +1 + NPA + NXX + XXXX
700 service access code with CAC CAC + 1 + 700 + NXX + XXXX
International with CAC CAC + 011 + CC + NSN
Serving service provider attendant *0
Serving service provider operator 0
Pre-subscribed IC or INC operator 00
Operator-assisted 10-digit 0 + NPA + NXX + XXXX
Operator-assisted 700 service access code 0 + 700 + NXX + XXXX
Operator-assisted 900 service access code 0 + 900 + NXX + XXXX
IC or INC operator with CAC CAC + 0
Operator-assisted 10-digit with CAC CAC + 0 + NPA + NXX + XXXX
Operator-assisted 700 service access code with CAC CAC + 0 + 700 + NXX + XXXX
Operator-assisted International 01 + CC + NSN
Operator-assisted International with CAC CAC + 01 + CC + NSN
All tests shall be made prior to commissioning of the MSC and commercial
service of the MSC. Measurement criteria for dialing tests shall consist of the
DRAFT 3/1/97


115
following:
- Lab test - Test calls shall be made between the Network Operations
center and the MSC. This shall enable personnel to establish initial
connectivity and a baseline for voice quality.
- Field test - Test calls shall be made involving all parties as noted in
Section 1.3.1.3.5. These parties shall include interexchange carriers (ICs),
local exchange carriers (LECs), directory assistance providers and
operator services providers.
- An international carrier (INC) may be used. However, in the event one
cannot be obtained for the field tests than call setup (for test calls) may be
traced up to the point at which the call is handed-off to the LEC access
tandem or interexchange carrier
- Field tests shall be coordinated with network management personnel
within NextWave and the appropriate personnel from the interexchange
carrier or local exchange carrier in order to determine successful
connectivity.
- All test calls shall involve voice communication (talking over the trunks)
and trunk monitoring between testing personnel. Trunk monitoring
during dialing procedures testing is not meant to replace transmission
and operational testing of trunk groups.
- As a reminder, the purpose of this Acceptance Test Plan is to test the
MSCs capability to appropriately interpret user dialing actions and
associated call processing treatments of dialed numbers. Testing
personnel shall not use this ATP to conduct performance monitoring or
general operational testing of the MSC.
- Network test equipment shall need to be coordinated between all
personnel involved. Network test equipment shall include but not be
limited to jack arrangements with direct access to the trunk or by special
switching access arrangements controlled by the associated MSC and
landline switch.
Reference Documents
- ANSI-660
- IS-93 : Ai-Di Interfaces for Wireless Telecommunications Service
Providers.
Minimum Standard: Specification of Passing Criteria for the Testing Procedure
Success will be determined by the successful and expected outcome of the call
Test Calls: Test Call Procedures and Call Processing Treatments
ANI II Digit Selection
The ANI II information digits are used to identify the type of ANI digits
passed across an interface. The use of ANI and ANI II is subject to the type of
network interconnection. Typically ANI II digits are passed to the LEC to
DRAFT 3/1/97


116
identify call type.
The specific meaning of any ANI II digits is subject to bilateral agreement
between the operators of a network interconnection.
a. The call is a call delivery leg and the responsible party is identified by
the ANI
Use ANI II digits 63. The called address is restricted and should not be
presented to the subscriber or the called party (e.g., should not be presented
on the subscriber's bill). The restriction holds for both the duration of the call
and for any subsequent billing or call detail information.
The ANI information reflects the identity of the responsible party for the call
delivery. This is usually the called subscriber.
b. The responsible party cannot be uniquely identified by the ANI
Use ANI II digits 61 (also see item c). In this case the ANI reflects the
wireless service provider originating the call and the originating location.
This may indicate that the wireless service provider is using a POI-T1
interconnection and it may, therefore, also include call delivery legs in other
interconnections.
c. The responsible party is not authorized for additional services
1

Use ANI II digits 61 (also see item b). In this case the ANI reflects the identity
of the responsible party which is usually the calling party. The ANI does not
necessarily reflect the calling location of the subscriber making the call.
d. The responsible party is uniquely identified by the ANI and may be
authorized for certain additional services
Use ANI II digits 62. The ANI reflects the identity of the responsible party
which is usually the calling party. The ANI does not necessarily reflect the
calling location of the subscriber making the call.
Any additional services that may be provided are subject to bilateral
agreement between the operators of a network interconnection. Such services
include, but are not limited to, directory assistance call completion, operator
extended call and operator assisted call.

1
The use of this value is currently under industry forum review and is subject to change.
DRAFT 3/1/97


117
1.3.1.3.5.1 7-digit NANP address: NXX + XXXX
The subscriber dialed a 7-digit called address within a World Zone 1
Numbering Plan Area (NPA). When seven digit dialing is allowed, the NPA
used is from the subscriber's MIN. Roamers are not allowed to dial 7-digit
calls.
a. NPA is required and was not dialed (e.g., a call made by a roamer)
Route the call to an announcement indicating that the NPA must be dialed.
b. An IC or INC is required, but one is not authorized
Route the call to an announcement indicating that the call is not authorized.
c. An IC or INC is required
Select the IC or INC:
1. If the subscriber's pre-subscribed IC or INC is known and is accessible,
route the call to that carrier; else:
2. If the default IC or INC for the subscriber's home service provider is
known and is accessible, route the call to that carrier; else:
3. Use the serving system default IC or INC of the accessed trunk.
Route the call toward the selected IC or INC.
d. Subscriber dialed his own directory number (revertive call)
Get additional routing instructions from the HLR or route the call to an
announcement indicating that the call cannot be routed as dialed.
e. The destination is located on the current switch
Route the call to the destination within the current switch.
f. The destination is located on a directly connected wireless switch
Route the call to the directly connected wireless switch using any of the
following interconnection types: POI-T4, POI-S5, POI-T6 or POI-S7.
g. The destination is located on a directly connected EC, IC or INC switch
Route the call to the directly connected switch using any of the following
interconnection types: POI-T4, POI-S5, POI-T6 or POI-S7.
h. The destination is accessed via an intermediate switch
DRAFT 3/1/97


118
Route the call using any of the following interconnection types: POI-T4, POI-
S5, POI-T6, POI-S7, POI-T10 or POI-S11.
i. The location of the destination cannot be determined
Route the call to an announcement indicating that the call cannot be routed as
dialed.
1.3.1.3.5.2 10-digit NANP address: [1] + NPA + NXX + XXXX
The subscriber dialed a 10-digit called address within World Zone 1. The 1+
prefix method is the preferred method. The home NPA may be dialed
permissively.
a. 1+ is required and was not dialed
Route the call to an announcement indicating that 1+ must be dialed.
b. Subscriber dialed his own directory number (revertive call)
c. An IC or INC is required, but one is not authorized
d. An IC or INC is required
Route the call toward the selected IC or INC using any of the following
interconnection types: POI-T4, POI-S5, POI-T6, POI-S7, POI-T10 or POI-S11.
e. The destination is located on the current switch
Route the call to the indicated address within the current switch.
f. The destination is located on a directly connected wireless switch
DRAFT 3/1/97


119
g. The destination is located on a directly connected EC, IC or INC switch
h. The destination is accessed via an intermediate switch
S5, POI-T6, POI-S7, POI-T10 or POI-S11.
i. The location of the destination cannot be determined
dialed.
1.3.1.3.5.3 Home NPA directory assistance: 555 + 1212
The subscriber dialed a 7-digit called address for directory assistance within a
World Zone 1 Numbering Plan Area (NPA).
a. NPA is required and was not dialed (e.g., a call made by a roamer)
b. IC or INC selection is not authorized
c. An IC is required
Select the IC:
3. Use the serving system default IC of the accessed trunk.
Route the call toward the IC using any of the following interconnection types:
POI-T4, POI-S5, POI-T6, POI-S7, POI-T10 or POI-S11.
d. The directory assistance destination is accessed via an intermediate
operator services tandem or on a directly connected operator services
system
DRAFT 3/1/97


120
Route the call (perhaps as a 411 call) using either of the following
interconnection types: POI-T10 or POI-S11.
e. The directory assistance destination is accessed via an intermediate
switch
Route the call (perhaps as a 411 call) using any of the following
interconnection types: POI-T4, POI-S5 or POI-T6.
f. The location of the directory assistance destination cannot be
determined
dialed.
1.3.1.3.5.4 Other NPA directory assistance: [1] + NPA + 555 + 1212
The subscriber dialed a 10-digit called address for directory assistance within
World Zone 1. The 1+ prefix method is the preferred method.
b. IC or INC is required, but one is not authorized
c. An IC or INC is required
Route the call toward the IC or INC using any of the following
d. The directory assistance destination is accessed via an intermediate
system

Route the call (perhaps as a 411 call) using either of the following
DRAFT 3/1/97


121
e. The directory assistance destination is accessed via an intermediate
switch
Route the call (perhaps as a 411 call) using any of the following
f. The location of the directory assistance destination cannot be
determined
dialed.
1.3.1.3.5.5 700 service access code: 1 + 700 + NXX + XXXX
The subscriber dialed a 10-digit called address for the 700 service access code
within World Zone 1.
Route the call to an announcement indicating that 1+ must be dialed.b.
Select an IC or INC
3. Route the call to an announcement indicating that the call cannot be
routed as dialed.
c. The location of the destination cannot be determined
dialed.


DRAFT 3/1/97


122
b. The EC, wireless carrier, IC, or INC is determined by the originating
network
Select the EC, wireless carrier, IC, or INC based upon the outcome of an 800
translation and route the call toward it using any of the following
c. The EC, wireless carrier, IC, or INC is determined by an intermediate
network
Route the call without a CIC using any of the following interconnection types:
POI-T4, POI-S5, POI-T6 or POI-S7.
d. The wireless carrier is located on a directly connected wireless switch
e. The location of the destination cannot be determined
dialed.
DRAFT 3/1/97


123
b. The EC, wireless carrier, IC, or INC is determined by the originating
network
Select the EC, wireless carrier, IC, or INC based upon the outcome of a 900
translation and route the call toward it using any of the following
c. The EC, wireless carrier, IC, or INC is determined by an intermediate
network
POI-T4, POI-S5, POI-T6 or POI-S7.
d. The wireless carrier is located on a directly connected wireless switch
dialed.
DRAFT 3/1/97


124
1.3.1.3.5.8 International: 011 + CC + NSN
The subscriber dialed an international called address outside of World Zone 1.
a. An INC is not required
T2, POI-T3, POI-T4 or POI-S5.
b. An INC is required
Select the INC:
Route the call toward the selected INC using any of the following
interconnection types: POI-T4, POI-S5, POI-T6 or POI-T7.
dialed.

1.3.1.3.5.9 Emergency services: 911
The subscriber dialed the emergency services access code. The call must be
routed according to the policies and requirements of the serving system and
the regulations of the applicable municipality.
a. The destination PSAP is directly connected
Route the call using any of the following interconnection types: POI-T8 or
POI-S9.
b. The destination PSAP is indirectly connected through an emergency
services tandem
POI-S9.
dialed.
DRAFT 3/1/97


125
1.3.1.3.5.10 Directory assistance: [1] + 411
The subscriber dialed 411 for directory assistance within World Zone 1. The
1+ prefix dialing is not desirable.
a. An IC or INC is required
b. The directory assistance destination is accessed via an intermediate
system
Route the call using either of the following interconnection types: POI-T10 or
POI-S11.
c. The directory assistance destination is accessed via an intermediate
switch
POI-S5.
d. The location of the directory assistance destination cannot be
determined
dialed.
DRAFT 3/1/97


126
1.3.1.3.5.11 N11 service code: N11
The subscriber dialed an N11 service code other than 411 or 911 within World
Zone 1.
Local N11 service codes may be EC or wireless carrier service codes at the
discretion of the local wireless service provider.
b. The destination is located on a directly connected wireless switch
c. The destination is located on a directly connected EC switch
d. The destination is accessed via an intermediate operator services
tandem or on a directly connected operator services system
POI-S11.
e. The destination is accessed via an intermediate switch
POI-S5.
f. The location of the destination cannot be determined
dialed.
DRAFT 3/1/97


127
1.3.1.3.5.12 Serving system service code: *N11
The subscriber dialed a wireless service code.

Table 2 Serving System Service Code
Digits Description Recommendation
*111 Carrier control service
code
This code is reserved for use by individual carriers. No
standardized treatment is applicable.
*411 Directory Assistance Route the call to Directory Assistance
*911 Emergency services calls To prevent the potential for dialing error in the
confusion of an emergency situation, the service code
*911 is to be provided the same treatment as calls
dialed as 911 by mobile stations. Route the call via
interface POI-T8 or POI-S9.
Note: Calls placed using any of these service codes must be routed within
the serving carrier's system to a termination address. As these three functions
are related, and as some carriers may not segregate the provision of these
services into different organizations, the numbers in parentheses describe the
prioritized framework for selection of the treatment.

1.3.1.3.5.13 Home system feature code: *FC
The subscriber dialed a home system feature code.
Feature Code Strings are interpreted by the home carrier's system. For a
roamer, these Feature Code Strings operate features as if the Feature Code
Strings were specified in the home carrier's system.
Note: The interaction of features between home system based features and
visited system based features is for further study. In order to provide a
consistent appearance to users, the use of **FC is permitted but not
recommended.
See ANSI-660, Table 6 in Annex A for definitions of feature codes.

a. Handled at the home system
Process the home system feature specified by the feature code.
DRAFT 3/1/97


128
1.3.1.3.5.14 Serving system feature code: **FC
The subscriber dialed a serving system feature code.
Feature Code Strings operate features in a serving carrier's system.
See Table 6 in Annex A for definitions of feature codes.
a. Handled within the serving system
Process the serving system feature specified by the feature code.
b. Permissive in the home system
Process the serving system feature specified by the feature code.
1.3.1.3.5.15 IC or INC cut-through: CAC[#]
The subscriber dialed a CAC.
Cut through to subscriber selected carrier (IC or INC).
a. IC or INC selection is not available at serving system
Route the call to an announcement indicating the CAC identified system
carrier is not available.
b. IC or INC selection is available at serving system
c. The location of the selected carrier cannot be determined
dialed.
1.3.1.3.5.16 4-digit 950-CIC IC cut-through: 950 + XXXX
The subscriber dialed a 4-digit 950-CIC.
a. IC or INC selection is not available at serving system
Route the call to an announcement indicating the 4-digit 950-CIC identified
system carrier is not available.
b. IC or INC selection is available at serving system
DRAFT 3/1/97


129
c. The location of the selected carrier cannot be determined
dialed.
1.3.1.3.5.17 7-digit with CAC: CAC + NXX + XXXX
The subscriber dialed a CAC and a 7-digit called address within a World
Zone 1 Numbering Plan Area (NPA). Roamers are not allowed to dial 7-digit
calls.
a. IC or INC selection is not authorized
Route the call to an announcement indicating that IC or INC selection is not
authorized.
b. NPA is required and was not dialed (e.g., a call made by a roamer)
c. Specific IC or INC is not authorized
Route the call to an announcement indicating that the specific IC or INC is
not authorized.
d. Subscriber dialed his own directory number (revertive call)
e. CIC is honored
Route the call toward the specified IC or INC using any of the following
interconnection types: POI-T4, POI-S5, POI-T6, POI-T10 or POI-S11.
f. The destination is located on the current switch
g. The destination is located on a directly connected wireless switch
following interconnection types: POI-T4, POI-S5 or POI-T6.
h. The destination is located on a directly connected EC switch
DRAFT 3/1/97


130
Route the call to the directly connected EC switch using any of the following
i. The destination is accessed via an intermediate switch
Route the call with the specified IC or INC using any of the following
j. The location of the destination cannot be determined
dialed.
1.3.1.3.5.18 10-digit with CAC: CAC + 1 + NPA + NXX + XXXX
The subscriber dialed a selected carrier and a 10-digit called address within
World Zone 1.
authorized.
b. 1+ is required and was not dialed
c. NPA is required and was not dialed (e.g., a call made by a roamer)
d. Specific IC or INC is not authorized
not authorized.
e. Subscriber dialed his own directory number (revertive call)
f. CIC is honored
Route the call toward the specified IC using any of the following
g. The destination is located on a directly connected wireless switch
DRAFT 3/1/97


131
h. The destination is located on a directly connected EC switch
i. The destination is accessed via an intermediate switch
Route the call with the specified IC using any of the following interconnection
types: POI-T4, POI-S5, POI-T6, POI-T10 or POI-S11.
j. The location of the destination cannot be determined
dialed.
1.3.1.3.5.19 700 service access code with CAC:CAC + 1 + 700 + NXX + XXXX
The subscriber dialed a selected carrier and a 10-digit called address for a
local, national or international 700 service access code destination.
authorized.
b. 1+ is required and was not dialed
c. Specific IC or INC is not authorized
not authorized.
d. CIC is honored
Route the call toward the specified IC using any of the following
e. The destination is located on a directly connected wireless switch
DRAFT 3/1/97


132
f. The destination is located on a directly connected EC switch
g. The destination is accessed via an intermediate switch
Route the call with the specified IC using any of the following interconnection
types: POI-T4 or POI-S5.
h. The location of the destination cannot be determined
dialed.
1.3.1.3.5.20 International with CAC: CAC + 011 + CC + NSN
The subscriber dialed an international called address outside of World Zone 1
and specified a carrier.
a. IC or INC selection is not available
Route the call to an announcement indicating that system carrier selection is
not available.
b. An INC is required
Route the call toward the INC using any of the following interconnection
types: POI-T4, POI-S5, POI-T6 or POI-S7.
c. The destination is accessed via an intermediate switch
S5, POI-T6 or POI-S7.
d. The location of the destination cannot be determined
dialed.
1.3.1.3.5.21 Serving service provider attendant: *0
The service code *0 is assigned for mobile subscriber access to the wireless
system attendant. Where no wireless system attendant is provided, the call
may be routed, at the serving carrier's option, to the carrier's business office,
to the customer care organization or to an announcement.
a. The destination is located on a directly connected wireless switch
DRAFT 3/1/97


133
b. The destination is located on a directly connected EC switch
c. The destination is accessed via an intermediate operator services
tandem or on a directly connected operator services system
POI-S11.
d. The destination is accessed via an intermediate switch
S5 or POI-T6.
dialed.
DRAFT 3/1/97


134
1.3.1.3.5.22 Serving service provider operator: 0
The subscriber dialed the operator.
a. The destination is an operator
b. The location of the destination cannot be determined
dialed.
1.3.1.3.5.23 Pre-subscribed IC or INC operator: 00
The subscriber dialed the pre-subscribed IC or INC operator.
b. The destination is accessed via an intermediate switch
POI-S5.
dialed.
DRAFT 3/1/97


135
1.3.1.3.5.24 Operator-assisted 10-digit: 0 + NPA + NXX + XXXX
The subscriber dialed an operator-assisted call with a pre-subscribed IC or
INC.
1. If the subscriber's pre-subscribed IC or INC or the subscriber's home
service provider's default IC or INC is known and is accessible, route the
call to Operator Services of that carrier; else:
known and is accessible, route the call to Operator Services of that carrier;
else:
3. Use Operator Services of the serving system default IC or INC of the
accessed trunk.
Route the call toward Operator Services of the IC or INC using any of the
following interconnection types: POI-T4, POI-T5, POI-T10 or POI-S11.
b. The operator assistance service is accessed via an intermediate operator
services tandem or on a directly connected operator services system
POI-S11.
c. The operator assistance service is accessed via an intermediate switch
d. The location of the operator assistance service cannot be determined
dialed.
DRAFT 3/1/97


136
1.3.1.3.5.25 Operator-assisted 700 service access code: 0 + 700 + NXX + XXXX
An operator-assisted call is made to a 700 service access destination.
a. Select an IC or INC
3. Route the call to an announcement indicating that the call cannot be
routed as dialed.
b. The location of the operator assistance service cannot be determined
dialed.
1.3.1.3.5.26 Operator-assisted 900 service access code: 0 + 900 + NXX + XXXX
An operator-assisted or third party billing call is made to a 900 service access
destination.
a. The IC or INC is determined by the originating network
Select the IC or INC based upon the outcome of a 900 translation and route
the call toward it using any of the following interconnection types: POI-T4,
POI-S5 or POI-T6.
b. The IC or INC is determined by an intermediate network
POI-T4, POI-S5 or POI-T6.
c. The location of the operator assistance service cannot be determined
dialed.
1.3.1.3.5.27 IC or INC operator with CAC: CAC + 0
DRAFT 3/1/97


137
The subscriber calls a subscriber-selected IC or INC operator.
authorized.
b. Specific IC or INC is not authorized
not authorized.
c. The operator assistance service is located on a directly connected EC
switch
d. The operator assistance service is accessed via an intermediate operator
POI-S11.
e. The operator assistance service is accessed via an intermediate switch
S5, POI-S7, POI-T10 or POI-S11.
f. The location of the operator assistance service cannot be determined
dialed.
DRAFT 3/1/97


138
1.3.1.3.5.28 Operator-assisted 10-digit with CAC: CAC + 0 + NPA + NXX + XXXX
A subscriber makes an operator-assisted call with subscriber-selected IC or
INC to a World Zone 1 destination.
authorized.
Route the call to an announcement indicating that an IC or INC is not
authorized to process call.
c. The operator assistance service is located on a directly connected
wireless switch
d. The operator assistance service is located on a directly connected EC
switch
e. The operator assistance service is accessed via an intermediate operator
POI-S11.
f. The operator assistance service is accessed via an intermediate switch
g. The location of the operator assistance service cannot be determined
dialed.
1.3.1.3.5.29 Operator-assisted 700 service access code with CAC: CAC + 0 + 700 + NXX + XXXX
A subscriber makes a call with subscriber-selected CAC to a local, national or
DRAFT 3/1/97


139
international 700 service access operator.
authorized.
Route the call to an announcement indicating that the specified IC or INC is
not authorized to process call.
c. The operator assistance service is located on the current switch
d. The operator assistance service is located on a directly connected
wireless switch
e. The operator assistance service is located on a directly connected EC
switch
f. The operator assistance service is accessed via an intermediate operator
POI-S11.
g. The operator assistance service is accessed via an intermediate switch
h. The location of the operator assistance service cannot be determined
dialed.
DRAFT 3/1/97


140
1.3.1.3.5.30 Operator-assisted International: 01 + CC + NSN
The subscriber dialed an operator-assisted international called address
outside of World Zone 1.
a. An INC is required
Select the INC:
b. The operator assistance service is accessed via an intermediate switch
c. The location of the operator assistance service cannot be determined
dialed.
1.3.1.3.5.31 Operator-assisted International with CAC: CAC + 01 + CC + NSN
The subscriber dialed an operator-assisted international called address
outside of World Zone 1 and specified a carrier.
authorized.
Route the call to an announcement indicating that the IC or INC is not
authorized to process call.
c. An INC is required
Route the call toward the INC using any of the following interconnection
types: POI-T4 or POI-S5.
d. The operator assistance service is accessed via an intermediate switch
e. The location of the operator assistance service cannot be determined
dialed.
DRAFT 3/1/97


141
1.3.1.4 Voice Service Options
Definition
The purpose of this test is to verify that it is possible to set up calls using all
the voice service options. The test verifies functionality, as well as basic
vocoder performance, using a known speech file. Both mobile originated and
mobile terminated calls are tested.
The equipment shall support Service Option 1 (8 kbps speech) , Service
Option 3 (Enhanced Variable Rate Codec), and Service Option 0x8000 (13
kbps speech).
The following sections in the NextWave Requirement Document for CDMA
Infrastructure Vendors pertain to this test.
Equipment needed:
Audio analyzer
CDMA personal station
Audio source
Audio test signal TBD from IS-96
Test Procedure:
1. Setup User Profile in HLR to indicate IS-96 speech preference
2. Start a mobile originated call.
3. Listen to landline and mobile sides of call to verify functionality
4. Inject audio test signal into microphone of mobile
5. Measure audio output from MSC using audio analyzer
6. Inject audio test signal into MSC
7. Measure audio output from speaker of personal station
8. Release Call
9. Repeat Steps 2-8 for a mobile terminated call.
10. Repeat Steps 1-9 for Service Option 3.
11. Repeat Steps 1-9 for Service Option 0x8000.
Minimum Standard
For each Service Option, call setup shall be successful 100% of the time, with
the maximum RMS error between the input signal and the received signal
being less than TBD.
DRAFT 3/1/97


142
1.3.1.5 Circuit Switched Data
Definition
The purpose of this test is to verify that the asynchronous data aspect of IS-99
in the infrastructure equipment is functioning correctly. This test is essentially
a functionality-only test, although it is expected that no bit errors are received
during this test (test is done under ideal channel conditions). Note that this
test assumes the existence of an IWF. This test shall be performed with each
3
rd
party IWF vendor chosen by NextWave. Both mobile-originated and
Equipment shall support Service Option 4 (Rate Set 1 Circuit-switched data)
and Service Option 12 (Rate Set 2 Circuit-switched data). Equipment shall
support an L interface to an IWF.
- Part IV, 1.2.1 Service Options
- Part IV, 1.15 Interworking Function
- Part IV, 1.21.2 Circuit-mode Data Services
Equipment needed:
Data-ready personal station
Mobile PC running terminal software supporting XMODEM or other file
transfer protocol connected to personal station
Landline PC running terminal software supporting XMODEM or other
file transfer protocol with a standard V.34 modem
10 kbyte file containing random data.
Test Procedures:
1. Set up a mobile originated call using Service Option 4 from mobile PC to
landline PC.
2. Start transfer of random data file
3. Compare random data file to received file.
4. Repeat Steps 1-3 for a mobile-terminated call from landline PC to mobile
PC
Minimum Standard
All files shall be transferred with no errors.
DRAFT 3/1/97


143
1.3.1.6 Fax Data Service Option
Definition
The purpose of this test is to verify that the fax data aspect of IS-99 in the
infrastructure equipment is functioning correctly. This test is essentially a
functionality-only test, although it is expected that no bit errors are received
3
rd
Equipment shall support Service Option 5 (Rate Set 1 Fax data) and Service
Option 13 (Rate Set 2 Fax data). Equipment shall support an L interface to an
IWF.
- 1.2.1 Service Options
- 1.15 Interworking Function
- 1.21.2 Circuit-mode Data Services
Equipment needed:
Fax-ready personal station
Mobile PC running fax software
Landline PC running fax software
A file containing 10 pages of random data.
Test Procedures:
1. Set up a mobile originated call using Service Option 5 from mobile PC to
landline PC.
2. Start transfer of random data file
4. Repeat Steps 1-3 for a mobile-terminated call from landline PC to mobile
PC
Minimum Standard
Files shall be received with no errors.
DRAFT 3/1/97


144
1.3.1.7 Packet Data Service Option
Definition
The purpose of this test is to verify that the IS-657 implementation in the
infrastructure equipment is functioning correctly. This test is essentially a
functionality-only test, although it is expected that no bit errors are received
3
rd

Equipment shall support Service Option 7 (Packet Data). Equipment shall
support an L interface to an IWF.


- 1.2.1 Service Options
- 1.15 Interworking Function
- 1.21.3 Packet-mode Data Services

DRAFT 3/1/97


145
Equipment needed:
- Packet Data-ready personal station
- Mobile PC running a TELNET and e-mail program connected to a CDMA
personal station
- Landline PC or WS running an email sever program with a standard
TCP/IP internet connection
- 10 Kbyte file containing random data

Test Procedures:
1. Send an email from the mobile PC to the landline e-mail server. Contain
in the email the random data file as an attachment..
3. Repeat Steps 1-2 10 times, waiting 1 minute between transfers.
4. Setup TELNET session between mobile PC and landline PC.
5. Type 10 characters, wait 1 minute, and repeat 10 times.

Minimum Standard
All files transferred shall contain no errors. Between transfers, the air
interface and the L interface shall be disconnected. During the TELNET
session, the air interface and the L interface shall be disconnected between
character transfers.


DRAFT 3/1/97


146
1.3.1.8 SMS
Definition
The purpose of this test is to verify that all SMS functionality in the infrastructure
equipment is operational. This functionality includes both mobile originated and
mobile terminated, as well as SMS on both the paging and traffic channels. Traffic
channel SMS is tested by assuming that Service Option 6 will be used when a
message to be transferred is too large to fit in the access channel message capsule.
Note that this test assumes the existence of an SMS Message Center. The
infrastructure vendor shall repeat this test for each 3
rd
party MC vendor chosen by
NextWave.
Infrastructure equipment shall support Service Option 6:
- Mobile originated SMS on the Access Channel
- Mobile terminated SMS on the Paging Channel
- Mobile originated SMS on the traffic channel
- Mobile terminated SMS on the traffic channel
- Broadcast SMS on the paging channel
- Date/Time Stamp
- Urgent Message Indicator
- Message acknowledgment
- 3.1.2.1 Service Options
- 3.1.21.4 Short Message Service


Mobile originated SMS on the Access Channel
TBD (further development item)

Mobile terminated SMS on the Paging Channel
1. Confirm that status of SMS performance at MSC, HLR, SMS Message
Center and interface condition among MSC, HLR, and SMS Message
DRAFT 3/1/97


147
Center is normal.
2. Confirm status of terminated PS is normal and idle.
3. Generate short message for paging channel to the terminated PS at the SMS
Message Center.
(The length of the bearer data of this short message is not more than
LGICs threshold value for paging channel. This threshold value is TBD.
Now, it is presumed to be about 63 octets.)
(Note that this test assumes that it is available to generate this short message
at the SMS Message Center.)
4. Verify the short message received by terminated PS.

Mobile originated SMS on the Traffic Channel

Mobile terminated SMS on the Traffic Channel
1. Confirm that status of SMS performance at MSC, HLR, SMS Message Center
and interface condition among MSC, HLR, and SMS Message Center is
normal.
3. Generate short message for traffic channel to the terminated PS at the SMS
Message Center.
(The length of the bearer data of this short message is more than LGICs
threshold value for paging channel. This threshold value is TBD. Now, it is
presumed to be about 63 octets. And the maximum value of the length of the
bearer data of this message can be limited according to additional parameters
and systems internal communication structure.)

Broadcast SMS on the Paging Channel

Date/Time Stamp
normal.
DRAFT 3/1/97


148
3. Generate short message including date and time stamp to the terminated PS at
the SMS Message Center.
(The maximum value of the length of the bearer data of this message can be
limited according to additional parameters and systems internal
communication structure.)

4. Verify the short message including date and time stamp that received by
terminated PS.

Urgent Message Indicator
normal.
3. Generate short message including urgent message indicator to the terminated
PS at the SMS Message Center.
4. Verify the short message including urgent message indicator that received by
terminated PS.

Message acknowledgment
normal.
3. Generate short message to the terminated PS at the SMS Message Center.
DRAFT 3/1/97


149
5. Verify the acknowledgment message received at SMS Message Center.

Minimum Standard
All messages shall be correctly transferred between the personal station and the
message center. When a message is too large to fit in an access channel message
capsule, it shall be transferred using Service Option 6 on the traffic channel.

DRAFT 3/1/97


150
1.3.1.9 Test Service Options
Definition
The purpose of this test is to verify that the test service options work correctly
in the infrastructure equipment. These service options are Loopback (Service
Option 2, IS-126) and Markov mode, both the Rate Set 1 version (Service
Option 0x801E) and Rate Set 2 version (Service Option 0x801F).
Equipment shall support Service Option 2 (Loopback for Rate Set 1), Service
Option 0801E (Markov mode Rate Set 1) and Service Option 0x801F
(Markov mode Rate Set 2), and Service Option 9 (Loopback for Rate Set 2).
- Part IV, 1.21.1 Loopback Services
Set up test equipment as defined in Figure X in J-STD-018.
Equipment needed:
Mobile DM
Cell DM
personal station supporting Loopback and Markov modes
AWGN generator
Test Procedures:
1. Set up a Loopback call with AWGN generator turned off.
2. Measure Frame Error Rate for 5,000 frames
3. Turn on AWGN generator, at an Eb/N0 point corresponding to 1% frame
error rate.
4. Measure Frame Error Rate for 20,000 frames.
5. Repeat Steps 1-4 for Rate Set 1 Markov mode and Rate Set 2 Markov
mode.
Minimum Standard
Under no-AWGN conditions, error rates in Loopback and both Markov
modes shall be zero. With AWGN, frame error rate shall be 3% +/- 1%.
DRAFT 3/1/97


151
1.3.1.10 Multiple Service Options
Definition
The purpose of this test is to verify that the infrastructure equipment can
properly support multiple service options. The main thrust of the
requirement is that all voice service options must work with any data service
option.
Equipment shall support multiple service options as defined in the table
below:

Service Option
1 (8Kbps speech)
3 (EVRC)
4(Async Data Rate Set 1)
5(Fax Rate Set 1)
6(SMS)
7(Packet Data)
12(Async Data Rate Set 2)
13(Fax Rate Set 2)
0X8000(13kbps speech)
1 3 4 5 6 7
12 13 0x8000
x
x
x
x
x
x
x x
x x x
x x x
x x
x
x
x x x x
x
x
x
x x
x x x
x
x

- Part IV, 1.2.2 Multiple Service Options
Set up each simultaneous set of service options as defined in the table above.
For each service option, execute the ATP test corresponding to that service
option as defined in this document.

To implement multiple option, there ae two rules as the bellows
- different rate sets between two service options
(ex. Rate sets 1 + Rate sets 2)
- different call types between two service options
DRAFT 3/1/97


152
(ex. Voice + Data)
Minimum Standard
Each service option shall conform to the same minimum standards as if it
were the only active service option.
DRAFT 3/1/97


153
1.3.1.11 Call Treatments: Number translation(Non-Dialable Number
Treatment)
Definition
Non-dialalbe numbers include ANI (Automatic Number Identification) digits
and MF tones. These non-dialable numbers will be necessary in order to
communicate with a PSTN switch that does not support SS7 (Public Switched
Telephone Network). Non-dialable numbers communicate information about
the calling subscriber and the type of call that is being made.
Non-dialable numbers include ANI information ii digits, Mobile Country
Codes, Mobile Network Codes, and MF tones.
Purpose of the Test/requirement to be satisfied
The ability to generate MF tones will be necessary in those instances a
NextWave MSC is directly interconnected to PSTN access tandems or end
office (Class 5) switches that are incapable of supporting CCS (Common
Channel Signaling) interconnect to MSCs.
All tests shall be made prior to commissioning of the MSC and commercial
service of the MSC. Measurement criteria for dialing tests shall consist of the
following:
- Test calls shall be made between the Network Operations center and the
MSC. This shall enable personnel to establish initial connectivity and a
baseline for voice quality.
1. Make a system configuration on which MSC-Network Operating center
inerworking is possible.
2. Execute R1 TRACE command with MMC TRC-R1 so that you can
trace R1 MF after a given call is released.
3. Make a call(Home MSC Call) to the Network Operating center with the
route on which you have traced with R1 MF trace command.
4. Check out ANI ii in the R1 MF trace results.
5. Make a call (Roaming MSC Call) to the Network Operating center with
the route on which you have traced with R1 MF trace command.
6. Check out ANI ii in the R1 MF trace results.

DRAFT 3/1/97


154
ANI ii Digit Selection
The ANI ii information digits are used to identify the type of ANI digits
passed across an interface. The use of ANI and ANI ii is subject to the type of
network interconnection. Typically ANI ii digits are passed to the LEC to
identify call type. ANI
The specific meaning of any ANI ii digits is subject to bilateral agreement
between the operators of a network interconnection.
a. The call is a call delivery leg and the responsible party is identified by the
ANI
Use ANI ii digits 63. The called address is restricted and should not be
presented to the subscriber or the called party (e.g., should not be
presented on the subscriber's bill). The restriction holds for both the
duration of the call and for any subsequent billing or call detail
information.
The ANI information reflects the identity of the responsible party for the
call delivery. This is usually the called subscriber.
b. The responsible party cannot be uniquely identified by the ANI
Use ANI ii digits 61 (also see item c). In this case the ANI reflects the
wireless service provider originating the call and the originating location.
This may indicate that the wireless service provider is using a POI-T1
interconnection and it may, therefore, also include call delivery legs in
other interconnections.
c. The responsible party is not authorized for additional services
2

Use ANI ii digits 61 (also see item b). In this case the ANI reflects the
identity of the responsible party which is usually the calling party. The
ANI does not necessarily reflect the calling location of the subscriber
making the call.
d. The responsible party is uniquely identified by the ANI and may be
authorized for certain additional services
Use ANI ii digits 62. The ANI reflects the identity of the responsible
party which is usually the calling party. The ANI does not necessarily
reflect the calling location of the subscriber making the call.
Any additional services that may be provided are subject to bilateral
agreement between the operators of a network interconnection. Such
services include, but are not limited to, directory assistance call

2
The use of this value is currently under industry forum review and is subject to change.
DRAFT 3/1/97


155
completion, operator extended call and operator assisted call.

Multi-Frequency (MF) Tone generation:
In order to communicate with the PSTN across the POI-Tx interfaces (trunk
interfaces) as described in TIA IS-93, the NextWave must be capable of
generating certain types of tones. These tones are described below.
Table 3 Notation for Signaling Information Symbols
Notation Name Description or Contents
D Digit(s) Each digit 0 to 9
KP Key Pulse Start of field signal
KP1P Key Pulse - 1 Prime Start of field signal
KPV Key Pulse -
Variable
KP, KP1P, KP2P or KP3P (refer to table 6 for
usage)
ST Start Pulse End of field signal
ST1P Start Pulse - 1
Prime
End of field signal
Prime
End of field signal
Prime
End of field signal
WZ1 World Zone 1 International addressing of NANP
+ Field Separator Not transmitted (descriptive only)
( ) Variable Inclusion Contents may be optional

Table 4 Notation for Signaling Information Digits
DRAFT 3/1/97


156
0 to 9 Generic Digit Number 0 to 9 as given
I ANI Information Digit Any number 0 to 9
N Address Digit Any number 2 to 9
N' Address Digit Any number 2 to 9, N' is not N
R International Routing Digit Any number 1 to 9
W Address Digit 0 or 1
X Address Digit Any number 0 to 9
Z Trunk Group Digit Any number 0 to 9
10D Number of Digits 10-digit code
7/10D Number of Digits 7- or 10-digit code
0/7/10D Number of Digits 0-, 7- or 10-digit code
3-10D Number of Digits 3- to 10-digit code
DRAFT 3/1/97


157
Table 5 Multi-Frequency Codes
Frequencies in Hz Digit or Control Signal
700+900 1
700+1100 2
700+1300 4
700+1500 7
700+1700 ST3P (ST)
900+1100 3
900+1300 5
900+1500 8
900+1700 ST1P (ST)
1100+1300 6
1100+1500 9
1100+1700 KP
1300+1500 0
1300+1700 KP2 and ST2P (ST)
1500+1700 ST
The NextWave MSC shall be capable of interpreting IMSI (International
Mobile Station Identity) from mobile handsets that do use the 10-digit North
American Numbering Plan. IMSI is composed of a 3 digit Mobile Country
Code, 2 digit Mobil Network Code and the 10 digit MIN. IMSI is transmitted
by the handset upon registration. This number is not dialable by the mobile
subscriber.

Minimum Standard
- ANSI-660
- SR-TSV-002275 - BOC Notes on the LEC Networks-1994
Test Result: Pass or Fail
Vendor Response to Failure: Diagnosis and action plan
DRAFT 3/1/97


158
1.3.1.12 Number translation

DRAFT 3/1/97


159
1.3.1.13 Call Routing on Called Party Address
Definition
This test verifies the capability of the MSC to direct a call to a trunk based on
the called-party directory number contained in the call origination message.
This is the fundamental capability of the switch to route calls based on the
called party directory number.

Purpose of the Test
This is a test of the basic capability of the switch to route calls based on the
directory number of the called party. This capability includes the ability to
route calls based on the following elements of the called party directory
number.
- Seven-digit directory number
- First three digits of seven-digit directory number
- First six digits of ten-digit directory number (NPA-NXX)
- First three digits of ten-digit directory number (NPA).
- Ten digit directory number

Related NextWave Requirements

Prerequisite
DRAFT 3/1/97


160
Local
Tandem
Access
Tandem
911Tan
dem
Operatir Service
Tandem
M S C
Type 2B
Type 2A
Type 2A
Type 2C
Type 2D
SS7
Sig. Pt.
Type S
L E C

1. Check Called Party Address and Routing related data.
2. Check interoperability of the systems so that a call may be established.
3. Attempt a call to available Called Party Address.
4. Upon call success, trace the relevant signal at Routing and Called Party
Address handling process to check the fact routing request for Called
Party Address is received from subscriber process and goes out to trunk
handling process. If call is not set up but the corresponding signal is
verified, normal operation is assumed. The signal means the signal
within the system. By connecting cable to corresponding processor, you
can trace and confirm.
Minimum Standard
The MSC must successfully route 100% of calls based on all of the criteria
listed in Section 0.
DRAFT 3/1/97


161
1.3.1.14 Call Routing on Calling Party Subscriber Class of Service (Mobile
Originated Calls)
Definition
Call routing based on SCS defines the ability of the MSC to direct a call to a
trunk based on the Subscriber Class of Service (SCS) associated with the
mobile that is originating the call. The MSC obtains the SCS for a given
mobile origination by one of the following means:
- Querying the HLR or VLR based on the Mobile Station ID (MIN or IMSI)
- Querying a MIN-to-SCS lookup table, which has been provision in the
MSC by the system operator at system configuration
- Assignment of a default SCS when the SCS is not available through other
means.
The MSC shall be provisioned with routing tables that provide a mapping of
SCS values to trunks so that the SCS is sufficient information for the MSC to
direct any call to a trunk.

This test shall verify the ability of the MSC to route calls based on any of the
above methods for arriving at an SCS for each mobile.

Related Sections in the NextWave Requirements Document
The Subscriber Class of Service and its corresponding requirements are
described in Section 1.3.1.1.

Prerequisite

DRAFT 3/1/97


162
Local
Tandem
Access
Tandem
911Tan
dem
Operatir Service
Tandem
M S C
Type 2B
Type 2A
Type 2A
Type 2C
Type 2D
SS7
Sig. Pt.
Type S
L E C

1. Check SCS and Routing related data.
3. Call is attempted by a subscriber with a viable SCS number
4. Upon call success, trace the relevant signal at Routing handling process
to check the fact routing request for SCS is received from subscriber
process and goes out to trunk handling process. If call is not set up but
the corresponding signal is verified, normal operation is assumed. The
signal means the signal within the system. By connecting cable to
corresponding processor, you can trace and confirm.
Minimum Standard
The MSC must successfully route 100% of calls according to each of the
routing means described in Section 0.
DRAFT 3/1/97


163
1.3.1.15 Call Routing on Originating Cell ID (Mobile Originated Calls)
Definition
Call routing on originating cell ID defines the capability of the MSC to direct
a call to a trunk based on the ID of the cell with which the mobile is
communicating when it transmits the origination. The ID of the cell at which
the call is being originated must be included with other information when the
origination message is sent back to the MSC. The MSC must be provisioned
with routing tables that map Cell ID to trunks so that the Cell ID is sufficient
information for the MSC to direct any call to a trunk.

The test shall verify the ability of the MSC to route calls based on the Cell ID,
as provided to the MSC by the BTS/BSC as part of the call origination
transaction.

Related Sections in the NextWave Requirements Document

Prerequisite
DRAFT 3/1/97


164
Local
Tandem
Access
Tandem
911Tan
dem
Operatir Service
Tandem
M S C
Type 2B
Type 2A
Type 2A
Type 2C
Type 2D
SS7
Sig. Pt.
Type S
L E C

1. Check cell and Routing related data.
3. Call is attempted by a subscriber with a normal cell number
to check the fact routing request for cell ID is received from subscriber
process and goes out to trunk handling process. If call is not set up but
the corresponding signal is verified, normal operation is assumed. The
signal means the signal within the system. By connecting cable to
corresponding processor, you can trace and confirm.
Minimum Standard
The MSC shall successfully route 100% of calls based only on the originating
cell ID.
DRAFT 3/1/97


165
1.3.1.16 Call Routing on Carrier Identification Digits (Mobile Originated
Calls)
Definition
Call routing on carrier identification digits defines the capability of the MSC
to route calls based on carrier identification digits. The carrier identification
digits are a prefix, of the form 10XXX, to the called party directory number,
that identifies a specific long distance carrier that the calling party wants to
carry the call. The MSC must be provisioned with routing tables that provide
a mapping from carrier identification digits to trunks so that the carrier
identification digits are sufficient information for the MSC to direct any call
involving carrier identification digits to a trunk.

The test shall verify the ability of the MSC to route calls based on the Carrier
Identification Digits.


Prerequisite

DRAFT 3/1/97


166
Local
Tandem
Access
Tandem
911Tan
dem
Operatir Service
Tandem
M S C
Type 2B
Type 2A
Type 2A
Type 2C
Type 2D
SS7
Sig. Pt.
Type S
L E C

1. Check carrier identification digits and Routing related data.
3. Attempt a call to viable carrier identification digits.
to check the fact routing request for carrier identification digits is
received from subscriber process and goes out to trunk handling process.
If call is not set up but the corresponding signal is verified, normal
operation is assumed. Signal is the signal in system. The signal means
the signal within the system. By connecting cable to corresponding
processor, you can trace in off line and confirm.
Minimum Standard
The MSC shall successfully route 100% of calls that are originated with dialed
digits containing carrier identification digits, based only on the carrier
identification digits.
DRAFT 3/1/97


167
1.3.1.17 Call Routing on Carrier Selection Prefix (Mobile Originated Calls)
Definition
Call Routing on Carrier Selection Prefix defines the capability of the switch to
route calls based on the carrier selection prefix. In calls with dialed digits of
the form 1-NPA-NXX-1234, the leading digit, 1, is the carrier selection prefix,
which indicates the callers desire to have the current call carried by his pre-
selected long-distance carrier. The MSC must be provisioned with routing
tables that provide a mapping from the calling partys MIN to trunks so that
the calling partys MIN is sufficient information for the MSC to direct any call
dialed with the carrier selection prefix to a trunk. A default carrier must also
be provisioned in the MSC, so that in cases where there is no entry in the
carrier selection table for a specific MIN, the call will be routed to the default
long-distance carrier.

The test shall verify the ability of the MSC to route calls based on the Carrier
Selection Prefix.


Prerequisite
POI-T4, POI-S5, POI-T6, POI-S7, POI-T8, POI-S9, POI-T10 or POI-S11
according to the configuration condition..

DRAFT 3/1/97


168
Local
Tandem
Access
Tandem
911Tan
dem
Operatir Service
Tandem
M S C
Type 2B
Type 2A
Type 2A
Type 2C
Type 2D
SS7
Sig. Pt.
Type S
L E C

1. Check carrier selection prefix (1) and Routing related data.
3. Attempt a call including carrier selection prefix.
to check the fact routing request for carrier selection prefix is received
from subscriber process and goes out to trunk handling process. If call is
not set up but the corresponding signal is verified, normal operation is
assumed. Signal is the signal in system. The signal means the signal
within the system. By connecting cable to corresponding processor, you
can trace in off line and confirm.
Minimum Standard
The MSC shall successfully route 100% of calls that are originated with dialed
digits containing the carrier selection prefix, based on routing table entries.
DRAFT 3/1/97


169
1.3.1.18 Hotlining
Definition
Hotlining refers to the redirection of a call that has failed authorization to a pre-
assigned directory number.
The system shall support hotlining of calls that are denied access to system resources
to a pre-specified DN. The system shall be capable of provisioning the DN based on
all of the following methods
- Subscriber class of service (SCS)
- Explicit field in each subscribers profile
- NPA-NXX conversion
The system shall be configurable to support any of the above provisioning methods
on a subscriber-by-subscriber basis. The system shall support hotlining to different
DNs based on the following events
- Authentication Failure
- Authorization Failure
Reference to related section in requirements document
The authentication requirements are specified in Part IV, Section 1.9 of NextWave
Requirements for CDMA Infrastructure Vendors, September 6, 1996.
Hotlining based on SCS
1. Confirm that hotline DN for athentication denied(HAD) and hotline DN
for validation denied(HVD) are set in the SCS look-up table for SCS
value of tested PS.
[ Hotlining for authentication failure ]
2. Confirm that status of authentication performance at MSC, HLR and AC
and interface conditions among MSC, HLR and AC are normal
3. Make authentication failure condition at the PS.
(For example, updating A_Key through handset menu brings to SSD_A
and SSD_B of handsets memory to zero. And if the PSs SSD_A in AC
is not zero, the PS will fail in authentication.)
DRAFT 3/1/97


170
4. Attempt a call at the PS.
5. Verify that the call is routed to hotline DN for authentication denied(HAD)
that is set in the SCS look-up table.
[ Hotlining for authorization failure ]
6. Confirm that interface conditions between MSC and HLR is normal.
7. Make authorization failure condition for the PS in HLR.
(For example, update the PSs authorization denied field as stolen unit
in HLR..)
8. Attempt a call at the PS.
9. Verify that the call is routed to hotline DN for validation denied(HVD)
that is set in the SCS look-up table.

Hotlining based on subscriber profile
TBD
(For all subscribers, SCS field can be assigned by one of three methods, i.e.,
optional parameter of Profile Macro or MIN-to-SCS mapping table or default
SCS. So for all subscribers, it is possible to apply hotline DNs based on SCS
look-up table. From this point of view, it is required to discuss necessities of
hotlining based on subscriber profile and NPA+NXX conversion.)

Hotlining based on NPA-NXX
TBD
(For all subscribers, SCS field can be assigned by one of three methods, i.e.,
optional parameter of Profile Macro or MIN-to-SCS mapping table or default
SCS. So for all subscribers, it is possible to apply hotline DNs based on SCS
look-up table. From this point of view, it is required to discuss necessities of
hotlining based on subscriber profile and NPA+NXX conversion.)
Minimum Standard
DRAFT 3/1/97


171
TBD
Test Description Test Result (P/F/NA)
Hotlining based on SCS
Hotlining based on subscriber profile
Hotlining based on NPA-NXX
Hotlining for authorization failure
Hotlining for authentication failure
1.3.1.18.1.1 Failed Test
1.3.1.18.1.2 Diagnosis
1.3.1.18.1.3 Action Plan
1.3.1.18.1.4 Data for Retest

DRAFT 3/1/97


172
1.3.1.19 Support of Voice Mail System
Definition
This test verifies the ability of the MSC to support one ore more voice-mail
systems. The voice mail system is either a stand-alone peripheral or part of
an integrated Enhanced Service Platform. The MSC shall support call
delivery to the voice mail system, through an ISUP interface, using ANI for
mailbox identification. Details of testing of the voice mail system interface
will depend on selection of vendor for the voice mail system
The test will verify the following capabilities of the MSC relative to the voice
mail system selected by NextWave:
- Call delivery to the voice mail system
- Support of message waiting notification
1. Configure a system environment on which a call to a VMS system is
possible. ISUP connection to the VMS system should be constructed and
MWN (message waiting notification) to a VMS service registered
subscriber should be possible.
2. Make a VMS service registered subscriber busy or power off state
3. Make a call to the VMS service registered subscriber who is in busy or
power off state (subscriber described 2.).
4. Check if call is forwarded to the VMS system
5. Save a voice message and release the call.
6. Check if MWN (message waiting notification) function operates on the
VMS service registered subscribers terminal.
7. When the VMS service registered subscriber receive MWN, make a call
to VMS and check received message.
Minimum Standard
IS-41-C
DRAFT 3/1/97


173
1.3.1.20 Support for IS-41-C Origination Triggers
Definition
Origination Triggers define conditions under which a registered MS is
instructed to perform an OriginationRequest operation. The
OperationRequest is initiated by a TCAP INVOKE (LAST) carried by a TCAP
QUERY WITH PERMISSION package. The OriginationTriggers parameter in
the TCAP INVOKE message is a variable length field in which each digit
defines a condition under which triggering might occur. Examples of
originating trigger conditions include any/local/intra-LATA/inter-LATA
toll/international call attempt, unrecognized number call attempt, any
number beginning with a Star * digit, etc.

The purpose of the test is to demonstrate the capability of the MSC to invoke
an OriginationRequest following the receipt of a TCAP INVOKE message
with the OriginationTrigger parameter set to any combination of the
following call attempt conditions
- All originations
- Local
- Intra-LATA Toll
- Inter-LATA Toll
- International
- Unrecognized number
- Revertive Call
- Star - any number beginning with a star * except when the star is
followed by a second star
- Double star - any number beginning with 2 stars **
- Pound - any number beginning with a pound # except when the pound
is followed by another #
- Prior agreement
- No digits
- 1-15 digits

DRAFT 3/1/97


174
The trigger requirements are specified in Part IV, Section 1.11 of NextWave

1. Confirm that interface condition between HLR and VLR is normal.
2. Input condition of origination trigger to test about test object subscriber
at HLR.
3. Confirm whether information of origination trigger is set intentionally
on subscriber profile of HLR and VLR.
4. Input trace function for MAP operation about test object subscriber at
MSC.
5. Test object subscriber fulfills call origination which is fitted for condition
of origination trigger.
6. If MAP message which shows perfornance of OriginationRequest MAP
operation about related subscriber toward MMC terminal is output,
judge of normal.

Minimum Standard


DRAFT 3/1/97


175
1.3.1.21 Support for IS-41-C Termination Triggers
Definition
Termination Triggers define the conditions or termination trigger points at
which the MSC is instructed to deviate from the normal call flow and apply a
specific treatment for a given active PS. The trigger values are set by the
home HLR during Call Delivery Incoming Call Invovation. The triggers for
the incoming call to the terminating party may be set at the originating or
terminating switch. A call terminating at the PS can trigger on conditions
such as busy, routing failure, no page response, no answer, or not reachable.
Example of treatments include launching a RedirectionRequest or
TransferToNumberRequest on a routing failure trigger.

The purpose of the test is to demonstrate the capability of the MSC to
respond an Incoming Call Invokation Response from the HLR which has any
combination of termination triggers set. The system shall demonstrate proper
treatment for the following termination triggers.
No Answer (call, trigger, leg)
No Page Response (call, trigger, leg)
Busy (call, trigger, leg)
Routing Failure (call, routing, leg)

The trigger requirements are specified in Part IV, Section 1.11 of NextWave

DRAFT 3/1/97


176
1. Confirm that interface condition between HLR and VLR is normal.
2. Input condition of termination trigger wanting to test about test object
terminating subscriber at HLR.
3. Confirm whether information of termination trigger is set with the
intention on subscriber profile of HLR and VLR.
4. Input trace function for MAP operation about test object subscriber at
MSC.
If originating MSC and terminating MSC are different each other, input
trace function for MAP operation at all of both MSC.
5. If no page response, busy, routing and failure are one of conditions of
test object termination trigger, form related conditions before test call
attempt.
6. Page test object termination subscriber among any mobile subscriber.
7. By conditions of test object termination trigger and test object
termination subscriber, if MAP message which shows performances of
TransferToNumberRequest or RedirectionRequest MAP operation
about related subscriber toward MMC terminal is output, judge of
normal.

Minimum Standard



DRAFT 3/1/97


177
1.3.1.22 Support for IS-41-C Origination Request Procedure
Definition
OriginationRequest operation is used to request call origination treatment by
a serving MSC to the HLR on behalf of a registering PS. It is initiated with a
TCAP INVOKE (LAST) which is carried by a TCAP QUERY WITH
PERMISSION package.
The purpose of the test is to demonstrate proper handling of the Origination
Request Procedure including the following.
- Initiate an Origination Request INVOKE. The serving MSC sends an
OriginationRequest INVOKE to the HLR when it encounters a digit
stream that requires digit analysis by the HLR.
- Responding to Successful Request. The serving MSC accepts new routing
instructions.
- Responding to unsuccessful request. The serving MSC performs the
indication treatment (assuming one exists) if the request was
unsuccessful.
The Origination Request Procedure requirements are specified in Part IV,
Section 1.11 of NextWave Requirements for CDMA Infrastructure Vendors,
September 6, 1996.
Test by example of performance of VMS retrieval function by revertive call.
1. Confirm that interface condition between HLR and VLR , MSC and VMS
is normal.
2. Authorize VMS retrieval service to test object subscriber at HLR.
3. In case only of revertive call, set up origination trigger condition of
related subscriber and if necessary, set up to perform VMS retrieval
function for revertive call of related subscriber at HLR.
4. Confirm whether origination trigger condition of related subscriber is set
up to revertive call at VLR.
5. Test object subscriber transmits the revertive call.
6. If VMS Retrieval of test object subscriber is successful, judge of normal.
Minimum Standard
DRAFT 3/1/97


178
1.3.1.23 Lawfully Authorized Electronic Surveillance
Purpose Of The Test/Requirement To Be Satisfied
Until standards have been developed and approved by industry standards
bodies, as it relates to compliance with CALEA (Communications Assistance
for Law Enforcement Act), the following capabilities shall be tested:
- Enabling the physical connection of recording devices to the appropriate
network entities for the purpose of recording conversation and
numbers/digits dialed by the surveyed party.
- Provide cell id and registration notification.

LGIC will implement conventional wiretap requirements.
LGIC will implement and test CALEA functionality once it is standardized.

1. Register the surveillance and the tapping services to a specific subscriber
in the HLR.
2. Verify the surveillance registration status by command at the HLR.
3. The registered subscriber calls a certain subscriber. Or calls the
registered subscriber.
4. The MSC reports the surveillance information related to the subscriber
about calling number, called number and events such as setup, paging
and conversation to the HLR, then the HLR prints out these information.
5. The MSC rings the surveyed party simultaneously as the subscriber who
has been registered to the tapping service answers the call.
6. Verify whether the functions are processed normally by way of the
surveyed partys hook-off.
7. Activate the tapping service by command at the HLR for the subscriber
who has been registered to surveillance-only service and verify the
functions are operated properly.
8. Deregister the subscriber who has been registered to the surveillance
and the tapping services by command at the HLR.
9. Verify whether the registration status of the surveillance service is no-
registration state by command.
10. The subscriber who has just been deregistered re-places a call to a certain
DRAFT 3/1/97


179
subscriber or is called to again.
11. Verify whether the subscriber has no surveillance services.

Minimum Standard
Prior to approval of industry standards test shall be based on vendor tests for
voice quality.

Test Result
Pass or fail.

Vendor Response To Failure

Diagnosis And Action Plan.

DRAFT 3/1/97


180
1.3.1.24 Echo Suppression and Cancellation
Definition
The echo suppression/cancellation functionality is located in the BSC co-
located with the speech codes. Their function is to increase the echo return
loss to values such that echoes with delay induced by speech processing are
at a sufficiently low level that they do not cause a perceptible degradation in
call quality.

The test is intended to establish that echoes with delay up to 24 milliseconds
and return loss below 24 dB are suppressed with a total return loss greater
than 30 dB. The test must also verify the capability of disabling and enabling
the functionality of the echo canceller/suppressers according to service
option in effect for a call.

Part IV, 1.14

1) Test using a sinusoidal signal without double talking
Set up a mobile originated call to landline phone
Make double talk detection and echo suppresser off
Apply a sinusoidal signal whose frequency is within voice band to a
mobile station
Make a landline phone silent during the test
DRAFT 3/1/97


181
Measure the input sinusoidal and the return signal using the
measurement utility like an oscilloscope
Calculate the return loss

2) Listening test without double talking
Make double talk detection and echo suppresser on
Say something to a mobile station while keeping a landline phone
silent
Listen carefully and see if there is echo
If echo exists, check how fast it disappears

3) Listening test with double talking
Make double talk detection and echo suppresser on
Say something to a mobile station while landline phone person says
something simultaneously
Listen carefully and see if there is echo
Check if the near-end component deteriorates
Check how fast the echo disappears if it exists
Also check if the echo canceller goes into the state of divergence

Minimum Standard
Specification of passing criteria for the test procedure


DRAFT 3/1/97


182
1.3.1.25 Interworking Function
Definition
The purpose of this test is to verify that the IWF implementation according to
the IS-658, IS-99, and IS-657. The test is consist of L interface test and upper
layer protocol test between data-ready personal station and IWF and landline
side PC or host server.

IWF shall support Service Option 4, 5, 7, 12, and 13. IWF shall support an L
interface to an MSC, and Pi interface to Internet.

Infrastructure Vendors pertain to this test .
Part IV, 1.15 Interworking Function

Test procedures will be the same as the procedures for the following test
items:
1.3.1.5 Circuit Switched Data
1.3.1.6 Fax Data Service Option
1.3.1.7 Packet Data Service Option

Minimum Standard
Same as the requirement given in 1.3.1.5, 1.3.1.6, and 1.3.1.7


DRAFT 3/1/97


183
1.3.1.26 Over The Air Activation and Service Provisioning
Definition
This test verifies that the interface to the MSC allows transfer of the OTASP
parameters to the mobile station, as well as the ability to query the mobile
station as to its capability. The interface to the MSC is referred to as the
OTASP Interface in this test.

Equipment shall support Over The Air Activation and Service Provisioning
as defined in IS-683.

DRAFT 3/1/97


184
1.3.1.27 Over-the-Air Activation and Service Provisioning, and System
Selection for Preferred Roaming
TBD

Minimum Standard
TBD


DRAFT 3/1/97


185
1.3.1.28 System Selection For Preferred Roaming (SSPR)
Definition
The purpose of this test is to verify that the SSPR roaming tables can be
correctly downloaded to a phone, using an interface to the MSC. This
interface to the MSC is assumed to be the same interface as used by the
OTASP functionality, and is referred to as the OTASP Interface in this test.

Infrastructure equipment shall perform SSPR functionality as defined in TIA
document TBD. The test will also determine compliance with CDG Ref. Doc
#29: System Selection for Preferred Roaming, Stage 1 Description.

DRAFT 3/1/97


186
1.3.1.29 Call Feature Control
These tests shall test the ability of the MSC and associate and network
elements to interpret and respond to subscriber feature control actions.
Feature Code Strings consist of the subscriber entered information (including
an introducing * or **, numeric Digits, and the Digit Delimiter #) which
is used to invoke or cancel a feature.
Feature code strings used include the items described in the following table:
Table 6 Feature Code Strings
Feature Code String Item Usage
*FC Feature Code beginning with a *.
*FC0 Feature Code beginning with a * and possibly including a
de-activation or de-registration Modifier Digit (e.g., the
digit 0).
+ Used to separate individual items in the Feature Code
String. This is not dialed.
0,1,2,3,4,5,6,7,8,9 Digits.
# Digit Delimiter
(+ #) Optional end of digit string Delimiter Digit. This is used
only for DTMF digit strings.
x(SEND) The send key on a Mobile Station (MS).
digits A string of digits 0 through 9.
prompt to enter x An audible prompt for item x.
termination address A string of one or more digits to specify a Termination
Address.
password The digits of a password using digits 0 through 9.
PIN The digits of a Personal Identification Number using digits
0 through 9.
1. Using a mobile station, input everyone of the feature code strings
described in IS-52 (e.g. Call forwarding- Busy Activation (*90))
2. Using a roaming mobile station, input everyone of the feature code
strings described in IS-52 (e.g. Call forwarding- Busy Activation (*90))
3. Type the command to confirm the subscriber service profile with the O
& M terminal. Verify the feature control entered in step 1, 2 was
performed properly.
Minimum Standard
Feature Code Strings and their requirements are defined in IS-52 (ANSI-660).
Vendor Response to Failure
Diagnosis and action plan

DRAFT 3/1/97


187
1.3.1.30 TIA-664: Cellular Subscriber Features
Definition
All cellular subscriber features are defined in ANSI/TIA/EIA-664, Cellular
Feature Description.

Verify that the system complies with all feature in TIA-664 except for the
following features:
- Subscriber PIN Access (SPINA)
- Subscriber PIN Intercept
The requirements include all authorization, activation, registration, and
invocation procedures. Call detail record information content, and
interaction with other features.


CD
1. Perform Authorization, Registration and Activation for CD feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for CD
feature are processed properly based on TIA-664.
3. Invoke CD feature.
4. Monitor CD Invocation is processed properly based on TIA-664.

CFB
1. Perform Authorization, Registration and Activation for CFB feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for CFB
3. Invoke CFB feature.
4. Monitor CFB Invocation is processed properly based on TIA-664.

CFD
1. Perform Authorization, Registration and Activation for CFD feature to A
subscriber.
DRAFT 3/1/97


188
2. Monitor Authorization, Registration and Activation procedures for CFD
3. Invoke CFD feature.
4. Monitor CFD Invocation is processed properly based on TIA-664.

CFNA
1. Perform Authorization, Registration and Activation for CFNA feature to
A subscriber.
2. Monitor Authorization, Registration and Activation procedures for
CFNA feature are processed properly based on TIA-664.
3. Invoke CFNA feature.
4. Monitor CFNA Invocation is processed properly based on TIA-664.

CFU
1. Perform Authorization, Registration and Activation for CFU feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for CFU
3. Invoke CFU feature.
4. Monitor CFU Invocation is processed properly based on TIA-664.

CT
1. Perform Authorization, Registration and Activation for CT feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for CT
3. Invoke CT feature.
4. Monitor CT Invocation is processed properly based on TIA-664.

CW
1. Perform Authorization, Registration and Activation for CW feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for CW
3. Invoke CW feature.
DRAFT 3/1/97


189
4. Monitor CW Invocation is processed properly based on TIA-664.

CNIP
1. Perform Authorization, Registration and Activation for CNIP feature to
A subscriber.
CNIP feature are processed properly based on TIA-664.
3. Invoke CNIP feature.
4. Monitor CNIP Invocation is processed properly based on TIA-664.
CNIR
1. Perform Authorization, Registration and Activation for CNIR feature to
A subscriber.
CNIR feature are processed properly based on TIA-664.
3. Invoke CNIR feature.
4. Monitor CNIR Invocation is processed properly based on TIA-664.

CC
1. Perform Authorization, Registration and Activation for CC feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for CC
3. Invoke CC feature.
4. Monitor CC Invocation is processed properly based on TIA-664.
DND
1. Perform Authorization, Registration and Activation for DND feature to
A subscriber.
2. Monitor Authorization, Registration and Activation procedures for DND
3. Invoke DND feature.
4. Monitor DND Invocation is processed properly based on TIA-664.
Emergency Services
1. Perform Authorization, Registration and Activation for Emergency
Services feature to A subscriber.
DRAFT 3/1/97


190
Emergency Services feature are processed properly based on TIA-664.
3. Invoke Emergency Services feature.
4. Monitor Emergency Services Invocation is processed properly based on
TIA-664.
FA
1. Perform Authorization, Registration and Activation for FA feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for FA
3. Invoke FA feature.
4. Monitor FA Invocation is processed properly based on TIA-664.

MWN
1. Perform Authorization, Registration and Activation for MWN feature to
A subscriber.
MWN feature are processed properly based on TIA-664.
3. Invoke MWN feature.
4. Monitor MWN Invocation is processed properly based on TIA-664.

MAH
1. Perform Authorization, Registration and Activation for MAH feature to
A subscriber.
MAH feature are processed properly based on TIA-664.
3. Invoke MAH feature.
4. Monitor MAH Invocation is processed properly based on TIA-664.

PCA
1. Perform Authorization, Registration and Activation for PAC feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for PCA
3. Invoke PCA feature.
4. Monitor PCA Invocation is processed properly based on TIA-664.
DRAFT 3/1/97


191
PL
1. Perform Authorization, Registration and Activation for PL feature to A
subscriber.
2. Monitor Authorization, Registration and Activation procedures for PL
3. Invoke PL feature.
4. Monitor PL Invocation is processed properly based on TIA-664.
Test Procedure
A separate test procedure shall be devised for each feature. Once all
individual features have been successfully tested, a feature interaction and
priority test shall be conducted.
Minimum Standard
- TIA-664.


DRAFT 3/1/97


192
1.3.1.31 TIA-664 Subscriber Feature Interaction
Definition
The purpose of this test is to verify that invocation subscriber usage of
multiple features does not cause dangerous logical, procedural, or priority
interaction such as infinite loops. Such interaction is to be prevented in the
following manner.
1. For same feature interaction (e.g., invoking CFB on 2 phones) procedures
will exist to prevent interaction
2. In general, for multiple feature interaction, the system shall adhere to a
precedence list such that when a subscriber invokes a higher precedence
feature then an active lower priority feature is automatically deactivated.
Once the higher priority feature has been de-activated, the subscriber
may once again, invoke the lower precedence feature.
3. In specific cases, the system may allow for concurrent activation of
multiple features. The vendor shall submit the procedures on which
future tests will be based.

The following is the list of feature precedence that shall be adhered to, as
specified in Step 2 above.
1. Call Delivery (CD) (highest precedence)
2. Call Forwarding -Busy (CFB)
3. Call Forwarding -Default (CFD)
4. Call Forwarding - No Answer (CFNA)
5. Call Forwarding - Unconditional (CFU)
6. Call Transfer (CT)
7. Call Waiting (CW)
8. Calling Number Identification Presentation (CNIP)
9. Calling Number Identification Restriction (CNIR)
10. Conference Calling (CC)
11. Do Not Disturb (DND)
12. Emergency Services
13. Flexible Alerting (FA)
14. Message Waiting Notification (MWN)
DRAFT 3/1/97


193
15. Mobile Access Hunting (MAH)
16. Password Call Acceptance (PCA)
17. Preferred Language (PL)


CD
1. Perform CD and other features simultaneously.
2. Verify the inter-relationship of CD and other features is processed
properly based on TIA-664.

CFB

CFD
1. Perform CFU and other features simultaneously.
2. Verify the inter-relationship of CFU and other features is processed

CFNA
1. Perform CFNA and other features simultaneously.
2. Verify the inter-relationship of CFNA and other features is processed

CFU
1. Perform CFU and other features simultaneously.
2. Verify the inter-relationship of CFU and other features is processed

CT
1. Perform CT and other features simultaneously.
DRAFT 3/1/97


194
2. Verify the inter-relationship of CT and other features is processed

CW
1. Perform CW and other features simultaneously.
2. Verify the inter-relationship of CW and other features is processed

CNIP
1. Perform CNIP and other features simultaneously.
2. Verify the inter-relationship of CNIP and other features is processed

CNIR
1. Perform CNIR and other features simultaneously.
2. Verify the inter-relationship of CNIR and other features is processed

CC
1. Perform CC and other features simultaneously.
2. Verify the inter-relationship of CC and other features is processed

DND
1. Perform DND and other features simultaneously.
2. Verify the inter-relationship of DND and other features is processed

Emergency Services
1. Perform Emergency Services and other features simultaneously.
2. Verify the inter-relationship of Emergency Services and other features is
processed properly based on TIA-664.

FA
DRAFT 3/1/97


195
1. form FA and other features simultaneously.
2. Verify the inter-relationship of FA and other features is processed

MWN
1. Perform MWN and other features simultaneously.
2. Verify the inter-relationship of MWN and other features is processed

MAH
1. Perform MAH and other features simultaneously.
2. Verify the inter-relationship of MAH and other features is processed

PCA
1. Perform PCA and other features simultaneously.
2. Verify the inter-relationship of PCA and other features is processed

PL
1. Perform PL and other features simultaneously.
2. Verify the inter-relationship of PL and other features is processed

Test Procedure
CD and Other features

Minimum Standard
- TIA-664.

DRAFT 3/1/97


196
1.3.1.32 TIA-664: Call Forwarding - Busy (CFB)
Definition
Call ForwardBusy permits a called subscriber to have the system send
incoming calls addressed to the called subscribers Directory Number to
another Directory Number (forward-to number) or the called number
designated voice mail box, when the subscriber is engaged in a call or service.
The purpose of these tests is to verify that the system complies with all
feature operations and interactions related to CFB as described in
ANSI/TIA/EIA-664, Cellular Feature Description.
Demonstrate full compliance in field or lab test.
Test Procedure
REGISTRATION ACTIVATION
SCC-A
Variable; subscriber is authorized to
specify forwarding number
Demand; subscriber is authorized to
control activation and de-activation of
CFB.
SCC-B
Fixed; forward number specified upon
registration.
Permanent; CFB active while authorized.
1.3.1.32.1 Subscriber Options
1. SCC-A registers at MSC
2. Default forward number is registered upon authorization.
3. LandStation-A originates call to SCC-B.
4. Verify that call is delivered successfully by confirming bi-directional
voice path.
5. LandStation-B originates call to SCC-A.
6. Verify that call is successfully forwarded to forwarding number.
7. LandStation-B terminates call.
8. SCC-A performs a Variable Registration authorized subscriber by
specifying the CFB registration feature code and a forward-to number
termination address or voice message system Modifier Digit 8.
10. Verify that call is successfully forwarded to new forwarding number.
11. LandStation-B terminates call.
12. SCC-A de-activates CFB (with flash message during call with
DRAFT 3/1/97


197
LandStation-A)
14. Verify that LandStation-B receives proper busy treatment and that call is
not forwarded.
15. LandStation-A terminates call.
16. Power-down SCC-A.
17. SCC-B registers at MSC.
18. LandStation-A originates call to SCC-B.
19. Verify that call is delivered successfully by confirming bi-directional
voice path.
20. LandStation-B originates call to SCC-B.
21. Verify that call is successfully forwarded to fixed forwarding DN.
1.3.1.32.2 Call Detail Record
The purpose of this test is to verify proper recording of CFB invocation in a
CDR. Details on the specific information that shall be included in the CDR
can be found in EIA/TIA IS-124, Cellular Radio-Telecommunications
Intersystem Non-Signaling Data Communications (DMH).
1. Perform procedure 1.3.1.34.1.1.1 .
2. Examine the CDRs from both calls (SCC-A and SCC-B) and verify that
the events and activities pertaining to the following areas were properly
recorded by commands in POMD.
- CFB registration
- CFB de-registration
- CFB activation
- CFB de-activation
- CFB invocation
- Forward-to call leg usage
Minimum Standard
LGIC provides the specific CDR Record Format which has the fixed length.
Please see CDR RECORD FORMAT DOCUMENT DRAFT FOR NEXTWAVE
for
further details. (CDR format could be changed through negotiation between
Nextwave and LGIC.)
The events and activities should be recorded in CDR properly.

DRAFT 3/1/97


198

DOCUMENT DRAFT
FOR NEXTWAVE

RELEASE 1.0.0.0

DRAFT 3/1/97


199

CDR RECORD STRUCTURE FOR NEXTWAVE

1 CDR RECORD STRUCTURE

The CDR record structure is displayed as followings. The total length of the CDR record is 128
bytes.

1 2 3 4 5 6 7 8
#1 #2 #3 dummy CDR MSC ID dummy

H H

H H

H H
System ID
H H H H
#4
H H

#1: CDR Type #2 : Feature Used #3 : Call Integrity #4 : Switch Number

9 10 11 12 13 14 15 16
Billing ID dummy
System ID
H H H H
#5
H H
Identification Number
H H H H H H
Seg Cnt
H H

#5 : Switch Number

17 18 19 20 21 22 23 24
Served Party Number
D D D D D D D D D D D D D D D D

25 26 27 28 29 30 31 32
Other Party Number
H H H H H H H H H H H H H H H H

33 34 35 36 37 38 39 40
Other Party Number

DRAFT 3/1/97


200
41 42 43 44 45 46 47 48
Served Party ESN Other Party ESN

49 50 51 52 53 54 55 56 57 58 59 60
Midcnt Date Air Seizure Time Trunk Seizure Time

D D
Year
D D
Month
D D
Day
D D
Hour
D D
Min
D D
Sec
D D
1/10Sec
D D
Hour
D D
Min
D D
Sec
D D
1/10Sec
D D

61 62 63 64 65 66 67 68 69 70 71 72
IEC Seizure Time Answer Time End Time
Hour
D D
Min
D D
Sec
D D
1/10Sec
D D
Hour
D D
Min
D D
Sec
D D
1/10Sec
D D
Hour
D D
Min
D D
Sec
D D
1/10Sec
D D

73 74 75 76 77 78 79 80
Call Start Cell ID dummy
System ID
H H H H
#6
H H
Zone ID
H H H H
Cell ID
H H H H

#6 : Switch Number

81 82 83 84 85 86 87 88
Call Finish Cell ID dummy
System ID
H H H H
#7
H H
Zone ID
H H H H
Cell ID
H H H H

#7 : Switch Number

89 90 91 92 93 94 95 96
Opposite Call Start Cell ID dummy
System ID
H H H H
#8
H H
Zone ID
H H H H
Cell ID
H H H H

#8 : Switch Number

97 98 99 100 101 102 103 104
Routing Digits
D D D D D D D D D D D D D D D D

DRAFT 3/1/97


201
105 106 107 108 109 110 111 112
Carrier Code #
9
#
10
#
11
#
12
#13 #14 #15 #16
#9 : Feature Operation #10 : Call Connection Type #11 : Roam Status
#12 : Registration #13 : Inter-MSC Handoff Flag #14 : Handoff Type
#15 : BSC Handoff Count #16 : Inter-MSC-Handoff Record Sequence Number

113 114 115 116 117 118 119 120
Incoming Trunk
Group
Incoming Trunk
Member Number
Outgoing Trunk
Group
Outgoing Trunk
Member Number

121 122 123 124 125 126 127 128
SCS dummy dummy
H H H H H H H H H H H H
The following paragraphs provide the details of record data fields.

1.1 CDR Type

CDR type indicates if the record is allocated for the originating or terminating call for normal calls .
It is also used to indicate subscriber controlled input, facility access, etc..

CODE (HEX) CDR Type
00 Mobile Originated Call (MOC)
01 Mobile Terminated Call (MTC)
02 Feature Call (FC)
03 Redirection Call (RC)
04 Mobile Originated Call with Inter-MSC-Handoff (HMOC)
05 Mobile Terminated Call with Inter-MSC-Handoff (HMTC)
For a MS-MS call inside the same MSC, two records are created, one named as MOC and the other
as MTC.
Feature Call record indicates the feature operations involved in a call.
Redirection Call record is the record between an incoming trunk and an outgoing trunk.
HMOC record is created if there exists an Inter-MSC handoff for the calling party.
HMTC record is created if there exists an Inter-MSC handoff for the called party.
DRAFT 3/1/97


202
1.2 Handoff Related Fields

There are four handoff related fields.
* Inter-MSC Handoff Flag
* Handoff Type
* BSC Handoff Count
* Inter-MSC-Handoff Record Sequence Number

1.2.1 Inter-MSC Handoff Flag

Inter-MSC-Handoff flag indicated if there is one inter-MSC handoff record generated in other
MSCs.

1.2.2 Handoff Type

There are six handoff types listed in the following table:

CODE (HEX) Handoff Type
00 No Handoff
01 Intra-MSC-Handoff within the Anchor MSC
02 Inter-MSC-Handoff from the Anchor MSC to MSC-B
03 Inter-MSC-Handoff-Back from MSC-B back to MSC-A
04 Inter-MSC-Handoff from MSC-B to MSC-C, i.e. Inter-MSC-Handoff to-Third
05 Intra-MSC-Handoff within MSC-B
06 Reserved

The Anchor MSC is the MSC where the call starts. MSC-B is the next MSC where the call is handed
off.

1.2.3 BSC Handoff Count

The BSC handoff count keeps a record for the number of Intra-MSC (BSC) Handoffs, where the
own MSC has been involved in.

1.2.4 Inter-MSC-Handoff Record Sequence Number

DRAFT 3/1/97


203
Inter-MSC-Handoff Record Sequence Number indicates which of all Inter-MSC-Handoff Records
involved in a call.
1.3 Call Integrity

Call integrity represents an internally generated reason why a call ends or fails. The reasons are
generated by several software entities in various call situations.

1.4 Feature Used

Feature field provides information on the type of feature used during the call. It indicates if a
specific feature was utilized during a call. It is also used in conjunction with the CDR Type field to
indicate subscriber controlled input functions related to specific feature. Following is the list of the
present supplementary features.

CODE
(HEX)
Feature Used CODE
(HEX)
Feature Used CODE
(HEX)
Feature Used
00 Norm 0b DND 16 VP
01 CFB 0c MWN 17 SMS
02 CFD 0d PL 18 VMR
03 CFN 0e PACA 19 VMD
04 CFU 0f FA 1a VMN
05 CD 10 MAH 1b VMU
06 CTR 11 PCA 1c FMB
07 CAW 12 SCA 1d FMD
08 CNIP 13 SPINA 1f FMN
09 CNIR 14 SPINI 20 FMU
0a CC 15 TWC 21 Reserved

1.5 Date Fields

There are two date related fields.

* Midnight Count
* Date

1.5.1 Midnight Count

DRAFT 3/1/97


204
The midnight count is a 1-byte number used to count the numbers of midnight passed during a call.
If a call continues over a long period, then not only time but the midnight count is needed, to evaluate
the elapsed time. The Midnight Count has a range of 0 up to 255. 0 means no midnight passed during
the call duration.
1.5.2 Date

Date is written as 3 bytes of BCD and in form of Year, Month and Day.
Year : last two digits of the year (00 - 99)
Month : month (01 - 12)
Day : day (01 - 31)

1.6 Time Fields

Time is written as 4 bytes of BCD and in form of Hour, Min, Sec and 1/10sec.

Hour: hours (00 - 23)
Min : minutes (00 - 59)
Sec : seconds (00 - 59)
1/10sec : 0.1 seconds (0 - 9)

There are four time-related fields.
* Air Seizure Time
* Trunk Seizure Time
* IEC Seizure Time
* Answer Time
* End Time

1.6.1 Air Seizure Time

The Air Seizure time is the time when the air channel is seized.
In the records where no real air seizure time is available (i.e. Call Delivery record), the field
contains all FFs
This is the time when the Date is taken.
In the case of Inter-MSC-Handoff and a handoff record generation, the Air Seizure Time is the time
when the handoff is triggered.

1.6.2 Trunk Seizure Time
DRAFT 3/1/97


205

The Trunk Seizure time is the time when the trunk is seized.
In the case of Inter-MSC-Handoff and a handoff record generation, the Trunk Seizure Time is the
time when the
MSC-B seizes a trunk.

1.6.3 IEC Seizure Time

IEC Seizure Time is the connect time when the MSC accesses the IEC (Interexchange Carrier) via
Access Tandem.
The next two figures shows examples of the IEC connect events.

Time
Trunk Seizure Time off-hook a
wink b
KP+0ZZ+XXX+ST c
off-hook d
wink e
IEC Seizure Time wink f
KP+(| |+ANI)+ST g
KP+0+7/10D+ST h
wink i
wink j
off-hook k
Answer Time off-hook l

Trunk Disconnect Time on-hook on-hook m

Trunk usage duration a - m MSC Mobile Switch Center
IEC usage duration f - m AT Access Tandem
Conversation duration l - m IEC Interexchange Carrier
Figure1 IEC Connection Events For Type 2A Feature Group D Signaling

MSC AT IEC
DRAFT 3/1/97


206

Time
Trunk Seizure Time IAM a
IAM b
IEC Seizure Time EXM c
ACM d
ACM e
ANM f
Answer Time ANM g

Trunk Disconnect Time REL REL h
RLC RLC i

Trunk usage duration a - h MSC Mobile Switch Center
IEC usage duration c - h AT Access Tandem
Conversation duration g - h IEC Interexchange Carrier

Figure 2 IEC Connection Events For Type 2A ISUP Signaling

1.6.4 Answer Time

The Answer Time is the time when the called party goes off-hook.
In the case of Inter-MSC-Handoff and a handoff record generation, the Answer Time is copied from
the End Time parameter of the previous record having been existing in Anchor MSC or other MSC as
its own Answer Time.

1.6.5 End Time

There are three possibilities of the record to be closed and stamped with the End Time:

* The Call is released.
* An Inter MSC Handoff occurs. i.e. The initial record in Anchor MSC is closed and a new
record is opened
in MSC-B.
*** For specific reasons , i.e. some a specific supplementary feature used, the record is closed.
MSC AT IEC
DRAFT 3/1/97


207
1.7 Served/Other Party Fields

There are three related field groups.
Served Party Field Only
Other Party Field Only
Both Party

1.7.1 Served Party Field

There are two served party related fields.

* Served Party Number
* Served Party Equipment Serial Number, ESN

1.7.1.1 Served Party Number

The Served Party Number consists of 8 bytes, i.e. 16 BCD digits for valid digits. Hex F is used for
end of Served Party Number, for unused digits. Served Party Number is constructed as the following:

Served Party Number = CC-NC digits (5 digits) + NPA (3 digits) + Number (7 digits) + F

Character
Positions
Served Party Number
1 -5 CC-NC Digits ( Country and Network Codes )
6 -8 Numbering Plan Area ( NPA )
9 -15 7 digits Number
16 F as end character

1.7.1.2 Served ESN

The ESN is coded as a 4 -byte hex number, corresponding to the serial number of the used Mobile
Equipment. The Number is composed of Manufacturer Code and the Sequence Number.

ESN = Manufacturer Code (1 byte) + Sequence Number (3 bytes)

1.7.2 Other Party Field

DRAFT 3/1/97


208
There are four called party related fields.

* Other Party Number
* Other Party Equipment Serial Number
* Carrier Code
* Routing Digits

1.7.2.1 Other Party Number

For a MOC or PSTN-MS , this field contains the dialed digits. If the dialed digits contain a * (Hex
B) or # (Hex C) then they are also placed within the Other Party number as Hex numbers.
Example : Mobile dials *18
Other Party Number : B1 8F FF FF FF FF FF FF FF FF FF FF FF FF FF FF
In case of an MTC for a MS-MS call, the Other Party Number is the calling party number.
Example : 3016010501 calls 3016012222
Other Party Number : 30 16 01 05 01 FF FF FF FF FF FF FF FF FF FF FF
In case of an MTC for a PSTN-MS call, the other party will normally contain all FF, unless the
calling party is identifiable by the signaling method used during the call. (For an incoming ISUP call,
the other party will be the Charge Number, if provided.)
If the Other Party Number is a Forwarded-to number , the same rules apply as for the dialed number
for MOC.

1.7.2.2 Other Party ESN

The ESN is coded as a 4 -byte hex number, corresponding to the serial number of the used Mobile
Equipment. The Number is composed of Manufacturer Code and the Sequence Number.

ESN = Manufacturer Code (1 byte) + Sequence Number (3 bytes)

1.7.2.3 Carrier Code

The Carrier Code , 2 BCD bytes, is either a dialed , a presubscribed or a default carrier code.

1.7.2.4 Routing Digits

DRAFT 3/1/97


209
Routing Digits consists of 8 BCD bytes, indicating one of three types of information, depending on
the call situation:

* Modified dialed number (manipulated by carrier insertion/deletion or NPA insertion)
* Modified Temporary Local Directory Number
* Call Forwarding Number
* Called Number (e.g. long number in case of short code )

1.7.3 Both Party Field

There are five Both Party related fields.

* Call Start Cell ID
* Call Finish Cell ID
* Opposite Call start Cell ID
* Incoming Trunk Group
* Incoming Trunk Member Number
* Outgoing Trunk Group
* Outgoing Trunk Member Number

1.7.3.1 Call Cell ID (Start, Finish, Opposite)

The Cell identification is a 7 bytes Hex number, composed of the following fields:

Length (bytes) Cell ID Fields
2 System ID
1 Switch Number
2 Zone ID
2 Cell ID

The Call Start Cell ID is used to indicate the first originating cell ID for MOC(or HMOC) or the
first terminating cell ID for MTC (or HMTC) in a MSC;

The Call Finish Cell ID is used to indicate the last originating cell ID for MOC(or HMOC) or the last
terminating cell ID for MTC (or HMTC) in a MSC;
DRAFT 3/1/97


210
The Opposite Call Start Cell ID is used to indicate the first terminating cell ID of MTC record for
MOC(or HMOC) or the first originating cell ID of MOC record for MTC (or HMTC) in a local MS-
MS call.
Note that all cell ID contain FFs in Call Delivery records or Call Forwarding records.
1.7.3.2 Incoming/Outgoing Trunk Group

The Trunk Group is written as 2 Hex Bytes.

Code (HEX) Trunk group Type
0000 - 9999 Incoming Trunk Group
0000 - 9999 Outgoing Trunk Group

1.7.3.3 Incoming/Outgoing Trunk Member Number

The Trunk Member Number indicates the particular trunk within a defined Trunk Group and is
written as 2 Hex bytes.

Code (HEX) Trunk Member Type
0000 - 9999 Incoming Trunk Member Number
0000 - 9999 Outgoing Trunk Member Number

1.8 Billing ID

Billing ID is represented by 7 bytes and consists of the following parts:

Length (bytes) Billing ID Fields
2 System ID
1 Switch Number
3 Identification Number
1 Segment Count

System ID and Switch Number belong to the MSC which initiates the Call Redirection or the Call
Setup.
Identification Number is a unique number for each call.
Segment Count counts the number of inter-MSC handoffs during a call.
DRAFT 3/1/97


211

1.9 Other Fields

Feature Operation

CODE (HEX) Feature operation
00 Normal Call Attempt
01 Registration
02 De-registration
03 Activation
04 De-activation
05 Cancellation
06 Invocation

Call Connection Type

CODE (HEX) Call Connection Type
00 Voice
01 Data

Roam Status

CODE (HEX) Roam Status
00 home
01 Roam

Registration Type

CODE (HEX) Registration Type
00 Not Registration
01 Registration

SCS : Subscriber Class of Service
DRAFT 3/1/97


212

2 DIFFERENT CALL TYPES

The major call type groupings are described here in more details.

2.1 Mobile to Land Call Type Records

For this call type only one MOC record exists, if calling mobile party is not handed off. The Other
Party Number corresponds to the dialed number of the called mobile. If short code dialing is used , then
actual translated number would be written into the Routing Digits. The Outgoing Trunk Group and
Trunk Member Number indicate the trunk between the MSC and the PSTN.

2.2 Land to Mobile Call Type Records

For this call type only one MTC record exists, if the called mobile party is not handed off and at
home. If the called mobile is roaming in another switch, a call delivery record is generated in the home
switch and a MTC record is allocated in the visited switch.
The Incoming Trunk Group and Trunk Member Number indicate the trunk used between the PSTN
and the MSC.

2.3 Mobile to Mobile Call Type Records

Note the following common information for a local MS-MS call.
Both the MOC and MTC records are within the system. The air channel of the calling MS is
allocated first, as the call starts. Later the air channel of the called MS is allocated. i.e. different Air
Seizure Time in MOC and MTC records. The Answer Time and End Time information are common to
both MOC and MTC records.

2.4 Different Handoff Handling of the records

There are five handoff groupings in terms of Handoff Type.
* Intra-MSC-Handoff within the Anchor MSC
* Inter-MSC-Handoff from the Anchor MSC to MSC-B
* Inter-MSC-Handoff-Back from MSC-B back to MSC-A
* Inter-MSC-Handoff from MSC-B to MSC-C, i.e. Inter-MSC-Handoff to-Third
* Intra-MSC-Handoff within MSC-B
DRAFT 3/1/97


213

2.4.1 Intra-MSC-Handoff within the Anchor MSC

Handoff is done to another BSC controlled by the anchor MSC.
For this case only one MOC (or MTC) record is generated with Handoff Type = Intra-MSC-Handoff
within the Anchor MSC in Anchor MSC, if the mobile is at home;
The Inter-MSC Handoff Flag is set to False. That is, there is no Inter-MSC handoff and no new
record generated in other MSC;
The BSC Handoff Count records the numbers of BSCs involved in this call;
The Handoff Record Sequence Number is set to 0.

The Handoff-related parameters are listed the following tables: ( MOC as a example)

Parameters Value
CDR Type MOC ( 00 )
Inter-MSC Handoff Flag False
Handoff Type Intra-MSC-Handoff within the Anchor MSC ( 01 )
BSC Handoff Count Presumed as 3
Inter-MSC-Handoff Record
Sequence Number
0

2.4.2 Inter-MSC-Handoff from the Anchor MSC to MSC-B

during an Inter-MSC-Handoff from the Anchor MSC to MSC-B, the following sequence of
events take place.

In Anchor MSC, one MOC (or MTC) record is generated with Handoff Type = Inter-
MSC-Handoff from the Anchor MSC to MSC-B ,if the mobile is at home;
The Inter-MSC Handoff Flag is set to True. That is, there is one new record generated in other
related
MSC, MSC-B;
The Handoff Record Sequence Number is set to 0;
The record is closed if handoff is successful and the End Time of the record is the time when
handoff is
successful.
DRAFT 3/1/97


214
In MSC-B, one HMOC (or HMTC) record is generated with Handoff Type = No
Handoff, if the mobile is at home and there is no BSC handoff; If there exists Intra-
MSC-Handoff, then Handoff Type is changed to Intra-MSC-Handoff within MSC-B;
The Inter-MSC Handoff Flag is set to False. That is, there is no new record generated in other
related
MSC;
The Handoff Record Sequence Number is set to 1.

The Handoff-related parameters are listed the following tables: ( MOC as a example).

Anchor MSC:
Parameters Value
CDR Type MOC ( 00 )
Inter-MSC Handoff Flag True
Handoff Type Inter-MSC-Handoff from the Anchor MSC to MSC-B( 02 )
Sequence Number
0

MSC-B:
Parameters Value
CDR Type HMOC ( 04 )
Handoff Type Intra-MSC-Handoff within MSC-B ( 05 ) OR No Handoff ( 00 )
BSC Handoff Count Presumed as 3 OR 0 if Handoff Type is marked as No Handoff
Sequence Number
1

2.4.3 Inter-MSC-Handoff-Back from MSC-B back to MSC-A

during an Inter-MSC-Handoff-Back from MSC-B to MSC-A, the following sequence of events
take place.
In MSC-B, one HMOC (HMTC) record has been already existing, and if Inter-MSC-
Handoff-Back to MSC-A is successful, then
Handoff Type of the HMOC (HMTC) record should be changed to Inter-MSC-Handoff-Back
DRAFT 3/1/97


215
from MSC-B
back to MSC-A;
The Inter-MSC Handoff Flag is changed to True. That is, there is one new record generated in
other
related MSC, MSC-A;
The Handoff Record Sequence Number is the same as original number n;
The record is closed and the End Time of the record is the time when Inter-MSC-Handoff-
Back from
MSC-B back to MSC-A handoff is successful.
In MSC-A, one new HMOC (or HMTC) record is generated with Handoff Type = No
Handoff, if the mobile is at home and there is no BSC handoff. If there exists Intra-
MSC-Handoff and MSC-A is the Anchor MSC, then Handoff Type is marked as Intra-
MSC-Handoff within the Anchor MSC , if not, it will be marked as Intra-MSC-Handoff within
MSC-B;
related
MSC;
The Handoff Record Sequence Number is set to n+1.


MSC-B:
Parameters Value
Handoff Type Inter-MSC-Handoff-Back from MSC-B back to MSC-A;
Sequence Number
n

MSC-A:
Parameters Value
DRAFT 3/1/97


216
Handoff Type No Handoff ( 00 ) OR Intra-MSC-Handoff within MSC-B ( 05 ) OR Intra-
MSC-Handoff within the Anchor MSC ( 01 )
Sequence Number
n+1

2.4.4 Inter-MSC-Handoff from MSC-B to MSC-C

during an Inter-MSC-Handoff from MSC-B to MSC-C, the following sequence of events
take place.

In MSC-B, one HMOC (HMTC) record has been already existing, and if Inter-MSC-
Handoff to MSC-C is successful, then
Handoff Type of the HMOC (HMTC) record should be changed to Inter-MSC-Handoff from MSC-
B to
MSC-C;
The Inter-MSC Handoff Flag is changed to True. That is, there is one new record generated in
other
related MSC, MSC-C;
The Handoff Record Sequence Number is the same as original number n;
The record is closed and the End Time of the record is the time when Inter-MSC-Handoff from
MSC-B to
MSC-C handoff is successful.
In MSC-C, one new HMOC (or HMTC) record is generated with Handoff Type = No
Handoff, if the mobile is at home and there is no BSC handoff. If there exists Intra-
MSC-Handoff , then Handoff Type will be marked as Intra-MSC-Handoff within MSC-B;
related
MSC;
The Handoff Record Sequence Number is set to n+1.

DRAFT 3/1/97


217
MSC-B:
Parameters Value
Handoff Type Inter-MSC-Handoff from MSC-B to MSC-C
Sequence Number
n

MSC-C:
Parameters Value
Handoff Type No Handoff ( 00 ) OR Intra-MSC-Handoff within MSC-B ( 05 )
Sequence Number
n + 1

2.4.5 Intra-MSC-Handoff within MSC-B

This is similar to Intra-MSC-Handoff within the Anchor MSC. Handoff Type of the record is
different,
marked as Intra-MSC-Handoff within MSC-B and .CDR Type is marked as HMOC (or HMTC). The
record is always
combined with other handoff records to indicate handoffs involved in a call.


MSC-B:
Parameters Value
DRAFT 3/1/97


218
Handoff Type Intra-MSC-Handoff within MSC-B ( 05 )
Sequence Number
n

2.5 Call Forwarding Records

Call Forwarding records with CDR Type = Redirection Call will be allocated in the home or in the
visited switch. In both cases these records are marked with the appropriate Feature Used CFx i.e. CFB,
CFNA, CFD, or CFU.
The Forward-to number would be written into the Routing Digits.
The Incoming and Outgoing Trunk Group, Trunk Member Number indicate the incoming and
outgoing trunk used in the home switch or in the visited switch.

2.6 Call Delivery Records

Call Delivery records with CDR Type = Redirection Call will be allocated in the home switch if the
called mobile is roaming in another switch. The records are marked with the appropriate Feature Used
CD.
The TLDN ( Temporary Local Directory Number ) would be written into the Routing Digits.
The Incoming and Outgoing Trunk Group, Trunk Member Number indicate the incoming and
outgoing trunk used in the home switch.

2.7 Delivery Call Forwarding Records

For this call type, There are two records generated in the home switch for the called mobile.
In the home switch, at first, one Call Delivery record will be allocated with CDR Type = Redirection
Call and Feature Used = CD , see paragraph 2.6 for more details; Secondly, one Call Forwarding record
is generated with CDR Type = Redirection Call and Feature Used = CFx i.e. CFB , see paragraph 2.5 for
more details.

2.8 Extend Call Forwarding Records

For this call type, two records are generated for the called mobile in the home switch and the visited
switch, respectively.
In the home switch, one Call Delivery record will be allocated with CDR Type = Redirection Call and
DRAFT 3/1/97


219
Feature Used = CD , see paragraph 2.6 for more details;
In the visited switch, one Call Forwarding record is generated with CDR Type = Redirection Call and
Feature Used = CFx i.e. CFB, see paragraph 2.5 for more details.

2.9 Call Waiting Records

Besides the records allocated for the already existing call, another MTC record is allocated for the
party with call waiting active. The record is marked with Feature Used CW.

2.10 Three Party Call Records

For the conference controller an additional MOC record with Feature Used 3WC is allocated at the
time setting up a call to the third party.

2.11 Type 2A IEC Usage Records

The Type 2A IEC Usage records look like normal records, except that IEC Seizure Time of these
records with the appropriate Carrier Code would be seized.

1.3.2 Authentication
DRAFT 3/1/97


220
1.3.2.1 Authentication Processing
Definition
Authentication is the process by which information is exchanged between a
MS and base station for the purpose of confirming the identity of the MS. A
successful outcome of the authentication process occurs only when it can be
demonstrated that the MS and base station possess identical sets of shared
secret data.

Personal Station Originations
Authentication of personal station origination is performed the standard
authentication mode when the personal station attempts to originate a call by
sending an Origination Message on the access channel. The procedure is
described in J-STD-008 Section 2.3.12.1.6.

Personal Station Terminations
Authentication of personal station origination is performed the standard
authentication mode when the personal station attempts to originate a call by
sending an Origination Message on the access channel. The procedure is

Personal Station Registrations
Authentication of personal station registration is performed the standard
authentication mode when the personal station attempts to register by
sending a Registration Message on the Access Channel. The procedure is

Unique Challenge-Response Procedure
The Unique Challenge-Response procedure enables the base station to
validate the MS at any time. It is initiated by the base station and can be
carried out on the paging and access channels, or on the forward and reverse
traffic channels. The procedure is as follows. The base station sends the MS
an Authentication Challenge Message. The MS then executes the
Auth_Signature procedure, and sends the result back to base station in an
DRAFT 3/1/97


221
Authentication Challenge Response Message. The base station then compares the
value of the AUTHU sent by the mobile to a value that was computed at the
base station using an internally stored copy of the SSD_A. If the comparison
fails the base station may deny further access attempts by the MS, drop a call
in progress, or initiate an update of the SSD. The procedure is described in J-
STD-008 Section 2.3.12.1.5.

Use and Update of Shared Secret Data
The authentication parameters of the MS may be modified by a request from
the AuC using the AuthenticationDirective message which is initiated by a
TCAP INVOKE and carried by a TCAP QUERY WITH PERMISSION
PACKAGE. Using a cryptographic algorithm and parameter values from the
AuC, the MS computes SSD_A_NEW and SSD_B_NEW. The MS and AuC
then each perform an authorization signature procedure. If the computed
values are identical the MS replaces the old values of SSD_A and SSD_B by
the new ones.

The purpose of the test is to verify that the system complies with IS-41-C and
J-STD-008 authentication procedures and related tasks. These include MS
authentication on origination, termination, registration, and on demand
(unique challenge-response), and the administration of cryptographic
variables (SSD).

The authentication related requirements are specified in Part IV, Section
3.1.19.1 of NextWave Requirements for CDMA Infrastructure Vendors, September
6, 1996.


DRAFT 3/1/97


222
1.3.2.1.1 Personal Station Originations
and interface condition among MSC, HLR and AC are normal.
2. Confirm whether test object personal station is registered in HLR and AC
and parameter (SSD, Call History Count etc.) value for authentication
performance between personal station and AC are corresponded each other.
3. Confirm whether authentication of call origination is set up at MSC.
4. Attempt call toward called party which call termination is possible
through test object personal station.
5. If call termination is successful, judge of normal.

1.3.2.1.2 Personal Station Terminations
3. Confirm whether authentication of call termination is set up at MSC.
4. Page test object personal station at calling party which call origination is
possible.
5. If setting up call is successful, judge of normal.

1.3.2.1.3 Personal Station Registrations
3. Confirm whether authentication of call termination for registration is set up
at MSC.
4. Confirm that test object personal station isnt registered in VLR.
5. Register test object personal station.
6. If registration of test object personal station is confirmed in VLR, judge of
normal.

DRAFT 3/1/97


223
1.3.2.1.4 Unique Challenge-Response Procedure
TBD

1.3.2.1.5 Use and Update of Shared Secret Data
TBD

Minimum Standard


Test Description Test Result (P/F/NA)
Personal Station Originations
Personal Station Terminations
Personal Station Registrations
Unique Challenge-Response Procedure
Use and Update of Shared Secret Data

DRAFT 3/1/97


224
1.3.2.2 Voice Privacy
Definition
Give a concise definition of the procedure or function being tested whenever
applicable. If the test measures delay (e.g., call set-up, ineffective attempt,
call release) then all processes included should be described. Note whether
PSTN delays are included. If necessary add diagram to show the elements
involved in the test.

Basically a restatement of the requirement from the Requirements document


TBD

Minimum Standard


DRAFT 3/1/97


225
1.3.2.3 Signaling Message Encryption
Definition
Give a concise definition of the procedure or function being tested whenever
applicable. If the test measures delay (e.g., call set-up, ineffective attempt,
call release) then all processes included should be described. Note whether
PSTN delays are included. If necessary add diagram to show the elements
involved in the test.

Basically a restatement of the requirement from the Requirements document


TBD

Minimum Standard



1.3.3 Signaling Interface
DRAFT 3/1/97


226
1.3.3.1 Automatic Link Transfer
The Automatic Link Transfer (ALT) capability is an SS7 ISDNUP capability.
This capability permits a switch (the NextWave MSC) to receive a call from
another NextWave MSC (or other service providers switch), then determine
that the call should be connected to a destination switch (or MSC) other than
itself. Upon determining the call should be connected to another switch (or
MSC), the first target MSC releases the call back to the originating MSC (or
other service providers switch).
Sufficient information is passed back to the originating switch (or MSC) to
enable the new connection to be established from the originating switch (or
MSC) to the new target MSC (or switch).
Note this routing concept is also referred to as Crankback in non-SS7
environments (e.g., MF).

1. Configure a system environment appropriate for ALT test
2. To know process after call termination, set TRACE on ISUP route.
3. Make a different subscriber registered to VMS busy or power off
condition.
4. Attempt ISUP trunk call to the VMS subscriber of step 3.
5. If call is transferred to VMS system, store message and release call.
6. Through TRACE result, verify call is released and then set up again.

Minimum Standard
GR-317-CORE, Switching System Generic Requirements for Call Control
Using the Integrated Services Digital Network User part (ISDNUP), Bellcore.
T1.113, ISDNUP

Test Result: Pass or Fail

Vendor Response To Failure: Diagnosis and action plan
DRAFT 3/1/97


227
1.3.3.2 MSCBSC Interface Requirements
DRAFT 3/1/97


228
1.3.3.3 MF PSTN Interface Requirements
Purpose of the Test/Requirement to be Satisfied
MF and SS7 Signaling connectivity and call setup between NextWave and the
PSTN shall be tested.
MF testing will be conducted between NextWaves MSC and the PSTN using
MF based trunk interconnections. SS7 testing will be conducted between
NextWaves SS7 network elements and the PSTN SS7 network elements.

Lab tests shall be conducted to determine the MSCs ability to generate all MF
tones needed to establish connectivity to the PSTN.
In order to communicate with the PSTN across the POI-Tx interfaces (trunk
interfaces) as described in TIA IS-93, the NextWave must be capable of
generating certain types of tones. These tones are described below.
1. Make a system configuration on which MSC-PSTN inerworking is
possible.
2. Execute R1 TRACE command with MMC TRC-R1 so that you can
trace
R1 MF after a given call is released.
3. Make a call(LEC call, IC call, INC call) to the PSTN with the route on
which
you have traced with R1 MF trace command.
4. Check if the call is successfully connected.
5. Make a calling subscriber or a called subscriber release.
6. Check out if R1 MF trace results correspond to TIA-IS-93.

DRAFT 3/1/97


229
Table 7 Notation for Signaling Information Symbols
D Digit(s) Each digit 0 to 9
KP Key Pulse Start of field signal
KPV Key Pulse - Variable KP, KP1P, KP2P or KP3P (refer to table 6 for
usage)
ST Start Pulse End of field signal
ST1P Start Pulse - 1 Prime End of field signal
WZ1 World Zone 1 International addressing of NANP
+ Field Separator Not transmitted (descriptive only)
( ) Variable Inclusion Contents may be optional

Table 8 Notation for Signaling Information Digits
0 to 9 Generic Digit Number 0 to 9 as given
I ANI Information
Digit
Any number 0 to 9
N Address Digit Any number 2 to 9
N' Address Digit Any number 2 to 9, N' is not N
R International
Routing Digit
Any number 1 to 9
W Address Digit 0 or 1
X Address Digit Any number 0 to 9
Z Trunk Group Digit Any number 0 to 9
10D Number of Digits 10-digit code
7/10D Number of Digits 7- or 10-digit code
DRAFT 3/1/97


230
Table 9 Multi-Frequency Codes
Frequencies in Hz Digit or Control Signal
700+900 1
700+1100 2
700+1300 4
700+1500 7
700+1700 ST3P (ST)
900+1100 3
900+1300 5
900+1500 8
900+1700 ST1P (ST)
1100+1300 6
1100+1500 9
1100+1700 KP
1300+1500 0
1300+1700 KP2 and ST2P (ST)
1500+1700 ST
The NextWave MSC shall be capable of interpreting IMSI (International
Mobile Station Identity) from mobile handsets that do use the 10-digit North
American Numbering Plan. IMSI is composed of a 3 digit Mobile Country
Code, 2 digit Mobile Network Code and the 10 digit MIN. IMSI is
transmitted by the handset upon registration. This number is not dialable by
the mobile subscriber.

Minimum Standard
- ANSI-660
- SR-TSV-002275 - BOC Notes on the LEC Networks-1994

Test Result: Pass or Fail.
DRAFT 3/1/97


231
1.3.3.4 SS7 PSTN Interface Requirements
Purpose of the Test/Requirement to be Satisfied
To verify proper SS7 Signaling connectivity and call setup between NextWave
and the PSTN. SS7 testing will be conducted between NextWaves SS7
network elements and the PSTN SS7 network elements. Test procedures will
verify compliance with the following standards documents.
- ANSI T1.111
- ANSI T1.112
- ANSI T1.113
- ANSI T1.114
- Bellcore TR-NWT-000317, and TR-NWT-000394
- TIA IS-93

<ISUP>
1. Configure a system on which MSC-PSTN interworking is available.
2. Execute ISUP TRACE command with MMC so that you can trace
ISUP messages after given a call is released.
3. Make a call to a PSTN subscriber through the route on which you
have executed ISUP trace command.
5. Release call at calling side.
7. Verify that an IAM is sent from originating SP to terminating SP.
8. Verify that an ACM is received at originating SP.
9. Verify that an ANM is received at originating SP.
10. Verify that a REL is sent from originating SP to terminating SP.
11. Verify that a RLC is received at originating SP.
<MTP>
Lab tests shall be conducted on NextWave SS7 network elements to determine
DRAFT 3/1/97


232
compliance with TIA IS-93 and ANSI SS7 standards for MTP, SCCP, TCAP,
and ISDNUP.
For this testing, the following prerequisites should be met: Own Signaling
Point (OSP) and one or more Destination Points (DP) must be defined.
In order to test ANSI T1.111 compliance, just follow these procedures.
1. Examine Signaling Points status
Two status of Destination Point is INACCESS and ACCESS.
In normal case (when DP is created first ), the status of Destination
Point will be INACCESS. If the status of Destination Point is
ACCESS, deactivate all signaling link for this testing.
2. Activate Signaling Link
3. Examine current Signaling Points status
You will see the similar result with step 1. But the status of Destination
Point must be ACCESS.
4. Deactivate Signaling Link
5. Examine current Signaling Points status
You will see the similar result as Step 1. But the status of Destination
Point must be INACCESS.

<SCCP>
In order to test ANSI T1.112 compliance, just follow these procedures.
1. Examine Signaling Points status
The status of Destination Point is INACCESS. If not, deactivate all
signaling link.
2. Examine SCCP information.
DRAFT 3/1/97


233
3. Activate Signaling Link-Set.
4. Examine current SCCP information.
Check that the status of Remote Subsystem is ALLOW and the status of
local sybsystem is IN_SERVICE.
5. Deactivate Signaling Link-Set.
6. Examine current SCCP information
You will see the similar output with Step 4. But verify the status of
Remote and Local Subsystem should be PROHB and
OUT_OF_SERVICE respectively.

Minimum Standard


DRAFT 3/1/97


234
1.3.3.5 MSC Signaling InterfaceMF Addressing for R1 Channel Associated
Signaling

Definition
This test is intended to verify the ability of the switch to support
Multifrequency (MF) addressing for R1 Channel Associated Signaling (CAS)
per TR-NPL-000145 and TIA/EIA IS-93.

MF signaling is used to transmit address information and control signals
across the POI.
MF signaling arrangements make use of pairs of frequencies out of a group of
six frequencies. Test procedures will verify compliance with the following
standards documents.
Bellcore, GR-000506-CORE
Bellcore, SR-TSV-002275, BOC Notes on the LEC Networks

Chapter 6. Signaling, 6.12 Multifrequency Pulsing

1. Connect the test jig composed of an analog subscriber telephone to the
USTA-N of the MSC.
2. Terminate the tip-ring connection point with a 600 ohm, 3-10 watts.
DRAFT 3/1/97


235
3. Generate each MF digit at the processor board to measure the
transmission frequency and energy at both ends of the subscriber
terminating resistor using the frequency counter.

4. By connecting the external frequency generator to the subscriber
terminating resistor and changing the dB level and pulse duration time,
check on the monitor the operation of the USTA-N. The output and
signal reception values should meet the following :

Minimum Standard
The MSC must demonstrate compliance with the applicable standards.



DRAFT 3/1/97


236
1.3.3.6 MSC Signaling Interface RequirementsIntegrated Services Digital
Network Application Part (ISUP)
Definition
This test is intended to verify the ability of the switch to support Integrated
Services Digital Network Application Part (ISUP), TR-NWT-000317, 394, 444.
Check if a call is connected well via ISUP between two MSCs.

1. Make a system configuration on which inter-switch call using ISUP
protocol is possible.
2. Execute ISUP TRACE command through MMC so that you can trace
ISUP
messages after given call is released.
3. Make a call through the route on which you have executed ISUP trace
command.
5. Release the call either by calling or called party.

Minimum Standard
The MSC must demonstrate compliance with the applicable standards.
Test result: pass/fail
DRAFT 3/1/97


237
1.3.3.7 MSC Signaling Interface RequirementsCell ID
Definition
This test is intended to verify the capability of the MSC to receive from the
BSS information identifying the cell on which a call origination or termination
is occurring, and to transmit that information as part of the CDR associated
with the call.

This test shall verify the capability of the MSC to receive the cell identification
information and to receive it as part of CDR.


1. Verify the cell ID of two mobile stations whose location were registered,
using MMC.
2. Place a call from one MS to the other MS.
3. Check the CDR of the call made in step 2.
4. In the content of CDR, check the origination cell ID and termination cell
ID are the same as those verified in step 1.

Minimum Standard
Inclusion of cell ID information in the CDR must be successfully
demonstrated.


DRAFT 3/1/97


238
1.3.3.8 MSC Signaling Interface RequirementsEntire Dialing String
Definition
This test is intended to verify the ability of the MSC to pass the entire dialed
string associated with a mobile-originated call, including any * or # digits, to
external network elements such as a gateway switch, that might be
responsible for processing a the dialed digit string.

entire dialing string including any * or # digits shall be transmitted to the
connected external network elements.

1. Check if data relevant to routing and other network interworking are
correct.
2. Check call is set up by dialing properly dialable dialed string digits.
3. Operate ISUP signal trace function on outgoing trunk and make a call
with a dialing string including any * or # digits.
4. Check the trace result if the Entire Dialing String is transmitted to remote
side.

(*notice. As a result of NWs detailed spec there is a possibility that the content of
above Method of Measurement can be changed.)
Minimum Standard

DRAFT 3/1/97


239
1.3.3.9 MSC/VLR-HLR Interface
The interface between the MSC/VLR and HLR shall be compliant with IS-41-
C. Transport shall be ANSI SS7, except in the case where the HLR is
integrated with the MSC. In this case, the MSC/VLR/HLR combination shall
support IS-41-C over SS7 for interconnection to an external mobility
management network, and shall support connection with a mated pair of
STPs. To enable communication between the HLR and other MSCs, the HLR
and MSC/VLR shall have distinct point code addresses. In the case of an
integrated MSC/VLR/HLR the VLR shall store profiles of all active
subscribers including both home subscribers and roamers.

The authentication related requirements are specified in Part IV, Section 3.3.3
of NextWave Requirements for CDMA Infrastructure Vendors, September 6, 1996.

For the following MAP operation, test the contents of operation described in
Chapter 4 . Automatic Roaming Operations of IS-41.3-C.

No Operation Contents of Operation for Test
1 AuthenticationDirective IS-41.3-C Section 4
2 AuthenticationFailureReport IS-41.3-C Section 4
3 AuthenticationRequest IS-41.3-C Section 4
4 AuthenticationStatusReport IS-41.3-C Section 4
5 BaseStationChallenge IS-41.3-C Section 4
6 BulkDeregistration IS-41.3-C Section 4
DRAFT 3/1/97


240

7 CallDataRequest IS-41.3-C Section 4
8 CountRequest IS-41.3-C Section 4
9 FeatureRequest IS-41.3-C Section 4
10 InformationDirective IS-41.3-C Section 4
11 LocationRequest IS-41.3-C Section 4
12 MSInactive IS-41.3-C Section 4
13 OriginationRequest IS-41.3-C Section 4
14 QualificationDirective IS-41.3-C Section 4
15 QualificationRequest IS-41.3-C Section 4
16 RegistrationCancellation IS-41.3-C Section 4
17 RegistrationNotification IS-41.3-C Section 4
18 RemoteUserInteractionDirective IS-41.3-C Section 4
19 RoutingRequest IS-41.3-C Section 4
20 ServiceProfileDirective IS-41.3-C Section 4
21 ServiceProfileRequest IS-41.3-C Section 4
22 SMSRequest IS-41.3-C Section 4
23 TrasferToNumberRequest IS-41.3-C Section 4
24 UnreliableRoamerDataDirective IS-41.3-C Section 4
Minimum Standard

DRAFT 3/1/97


241
1.3.3.10 MSC/VLR-MSC-VLR Interface

Definition
The MSC/VLR interface to another MSC/VLR (also denoted the G and E
interfaces) describes the messaging protocol between the network entities.
The primary purpose of such communication is to enable intersystem handoff.
Intersystem handoff refers to the process of switching a MS telephone call
that is in progress on one MSC to a different contiguous MSC that is better
able to serve the MS by assigning a voice/traffic channel controlled by a
different MSC. The original MSC is termed the anchor MSC. Subsequent
MSCs in the handoff process are either tandem or serving MSCs.

The purpose of the test is to demonstrate inter-system IS-41-C messaging over
ANSI SS7 capability including intersystem soft handoff. Additionally, the
system shall demonstrate the ability to interface to an external mobility
management network. All connections will be tested through a mated pair of
STPs.

The inter-MSC requirements are specified in Part IV, Section 3.3.4 of
NextWave Requirements for CDMA Infrastructure Vendors, September 6, 1996.

Method of measurement
For the following MAP operation, test the contents of operation described in
Section 4 of IS-41-2.C and IS-41-3.C.

DRAFT 3/1/97


242
1 Blocking IS-41.2-C Section 4
2 FacilitiesDirective2 IS-41.2-C Section 4
3 FacilitiesRelease IS-41.2-C Section 4
4 FlashRequest IS-41.2-C Section 4
5 HandOffBack2 IS-41.2-C Section 4
6 HandOffMeasurementRequest2 IS-41.2-C Section 4
7 HandOffToThird2 IS-41.2-C Section 4
8 InterSystemAnswer IS-41.2-C Section 4
9 InterSystemPage IS-41.3-C Section 4
10 InterSystemPage2 IS-41.3-C Section 4
11 InterSystemSetup IS-41.3-C Section 4
12 MobileOnChannel IS-41.2-C Section 4
13 RandomVariableRequest IS-41.3-C Section 4
14 RedirectionDirective IS-41.3-C Section 4
15 RedirectionRequest IS-41.3-C Section 4
16 ResetCircuit IS-41.3-C Section 4
16 TrunkTest IS-41.2-C Section 4
17 TrunkTestDisconnect IS-41.2-C Section 4
18 Unblocking IS-41.2-C Section 4

Minimum Standard
Full IS-41C messaging capability for same vendor MSC/VLRs.

DRAFT 3/1/97


243

DRAFT 3/1/97


244
1.3.4.1 MSC Quality of Service Performance RequirementsBlocking
Probability
Definition
Blocking Probability is a measure of the fraction of calls handled by the MSC
that are not completed due to capacity limitations in the MSC switch fabric or
any of the processing resources required by the MSC to complete a call.

This test must be performed wit the MSC under load at its rated capacity,
with calls exhibiting a typical range of mobility characteristics, to be specified.
Under these conditions, the test must measure the number of calls that cannot
be completed due to lack of switching or processing resources.



1. Test Environment

ASS_W0
Note) 2
ASS_W1
Note) 3
NTP
INP
LRP
Note) 5
ASS_T
CCP 0
CCP1
Note)1
ASS_GS
Note) 4
DRAFT 3/1/97


245

Note1) Simulator for ASS_W performance evaluation
Note2) Simulator for NTP performance evaluation(call origination only)
Note3) Simulator for NTP performance evaluation(call termination only)
Note4) Simulator for ASS_T performance evaluation
Note5) Simulator for internal VLR call processing

2. Target Processor
1) ASP(Access Switching Processor)
- ASS_W(mobile call processing)
- ASS_T(trunk call processing)
2) NTP(Number Translation Processor)

3. Method of simulation
3.1 Mobile to mobile call
- Load simulator to CCP_1 for ASS performance evaluation
- Load simulator to LRP for internal call processing - it does not invoke Location
Request to HLR
- Activate the simulator of CCP_1
- Record the observed CPU load of ASP(ASS_W) and incompletion ratio
- Repeat above step under gradual load increasing condition
- Stop the test when the CPU load becomes 95%
3.2 Trunk call
- Load simulator to ASS_GS for trunk call test
- Make an environment - data handling and trunk loop back - so that the trunk loop back call
is possible
- Activate the simulator of ASS_GS
- Record the observed CPU load of ASP(ASS_T) and incompletion ratio
3.3 NTP
- Load simulator to ASS_W0 which can operates as a call originator only
- Load simulator to ASS_W1 which can operates as a call terminator only
- Activate the simulator of ASS_W0
- Record the observed CPU load of NTP and incompletion ratio
DRAFT 3/1/97


246
3.4 The incompletion ratio gathered from above tests might be regarded as blocking
probability
- Verify whether the results of the final step satisfies the minimum requirements of
this test item

Minimum Standard

The System blocking probability shall Not Contribute more than 5%.



DRAFT 3/1/97


247
1.3.4.2 MSC Capacity RequirementsTraffic Intensity
Definition
This test is intended to measure the capacity of the MSC in Erlangs, averaged
over the busy hour, under typical loading conditions that reflect expected
mobility mix, call holding times, and trunk group usage. The value of
Erlangs averaged over the busy hour is determined by averaging the number
of calls active on the switch over one hour. The largest such value for which
the blocking probability does not exceed the maximum as defined in Section
1.3.4.1 is defined as the Erlang capacity of the switch.

This test is intended to establish the maximum capacity of the switch under
traffic conditions expected in NextWave networks.


1. Test Environment

ASS_W0
Note) 2
ASS_W1
Note) 3
NTP
INP
LRP
Note) 5
ASS_T
CCP 0
CCP1
Note)1
ASS_GS
Note) 4
DRAFT 3/1/97


248

2. Target Processor

- Load simulator to LRP for internal call processing - it does not invoke Location Request
to HLR
- Record the observed CPU load of ASP(ASS_W)
3.2 Trunk call
- Make an environment - data handling and trunk loop back - so that the trunk loop back
call is possible
- Record the observed CPU load of ASP(ASS_T)
3.3 NTP
- Record the observed CPU load of NTP
3.4 Calculate Traffic Intensity from test result
DRAFT 3/1/97


249
-. ASS_W Erlang = ASS_W BHCA * Holding Time / 3600 Sec
-. ASS_T Erlang = ASS_T BHCA * Holding Time / 3600 Sec
-. NTP Erlang = NTP BHCA * Holding Time / 3600 Sec

Minimum Standard

The System(NTP) is supported traffic intensity of 10,000 Erlangs.


DRAFT 3/1/97


250
1.3.4.3 MSC Capacity RequirementsSubscriber Capacity
Definition
This is a test of the maximum number of subscribers that an MSC can support.
This is presumed to be a limitation imposed by VLR capacity, but the test
shall also account for any and all resource limitations that may limit the total
number of subscribers that can be supported by the MSC under a traffic and
mobility mix that fairly represents conditions to be encountered in
NextWaves markets.

This test shall verify that switch performance meets all other criteria specified
in this document, particularly in Sections 1.3.4.1, 1.3.4.2, 1.3.4.4, 1.3.4.5, when
its VLR and other internal databases are configured to support the rated
number of subscribers.


1. Test environment

2. Verify the Capacity
- Load simulator to an ASP which invokes Location Registration to VLR continuously
- Activate the simulator so that Location Registration is continuously invoked to LRP0
- Verify whether the results of the final step satisfies the minimum requirements of this test
item

Minimum Standard
1. Subscriber Capacity
-. MSC Subscriber Capacity = 12 LRPs= 350,000 Subscribers.
350,000 / 12 29000/LRP
ASS_W LRP 0
DRAFT 3/1/97


251
2. One (1) LRP Capacity is more then 29000 Subscribers.


DRAFT 3/1/97


252
1.3.4.4 MSC Capacity RequirementsBusy Hour Call Attempts (BHCA)
Definition
This test verifies the capability of the MSC to accommodate the rated level of
call origination intensity, as measured by Busy Hour Call Attempts, based on
a specified call model, including mobility mix, proportion of mobile
originated and mobile terminated calls, and call hold times. A busy hour call
attempt is defined as a valid dialed digit string arriving at the MSC.

This test shall measure the maximum number of call attempts that the switch
can process during one hour, while continuing to meet all other criteria
specified in this document, particularly in Sections 1.3.4.1, 1.3.4.2, 1.3.4.4,
1.3.4.5. The maximum number of BHCA that the switch can support without
violating other performance criteria is define as the BHCA capacity of the
switch.


1. Test Environment

ASS_W0
Note) 2
ASS_W1
Note) 3
NTP
INP
LRP
Note) 5
ASS_T
CCP 0
CCP1
Note)1
ASS_GS
Note) 4
DRAFT 3/1/97


253


2. Target Processor

- Load simulator to LRP for internal call processing - it does not invoke Location Request to
HLR
- Record the observed CPU load of ASP(ASS_W)
3.2 Trunk call
- Make an environment - data handling and trunk loop back - so that the trunk loop back
call is possible
- Record the observed CPU load of ASP(ASS_T)
3.3 NTP
- Record the observed CPU load of NTP
DRAFT 3/1/97


254

3. 4Verify whether the results of the final step satisfies the minimum requirements of this
test item

Minimum Standard
The System(NTP) is support up to 50,000 BHCA


DRAFT 3/1/97


255
1.3.4.5 MSC Capacity RequirementsCDR Storage Capacity
Definition
This is a test of the MSCs ability to provide storage for Call Detail Records.
The storage may be a combination of on-line, disk-based storage, and off-line,
tape based, storage. The MSC must provide facilities that enable operation
without permanent on-site staffing.
This test shall verify that the MSC has the disk capacity to store up 72 hours
worth of CDRs on-line, without recourse to backup on removeable media.
The test shall also verify that the MSC has the ability to backup daily, 24-hour
increments of CDRs onto removeable magnetic media, and to do this
continuously for up to ten days without operator intervention. The test shall
verify these capabilities consistent with traffic models that reflect holding
times, mobility mix, and traffic volumes expected in NextWaves networks
and consistent with other requirements given in this document, such as
BHCA capacity, subscriber capacity, and traffic intensity.

Disk
1. Generate a certain amount of calls using simulator or equipment.
2. Confirm the number of CDRs generated by calls and the size of used
disk.
3. Verify the maximum number of CDR which can be stored in the disk.
DAT
4. Assign back-up time to magnetic media using POMD MMI.
5. Verify the CDR in POMD billing disk is backed up to magnetic media
at the assigned time.
6. Calculate the backed-up CDR number and the magnetic media
capacity to confirm total CDR storage capacity.
Minimum Standard
LGIC assumes that its CDR length is 200 bytes. CDR storage capacity based
on the CDR that has a length of 200 bytes shall be no less than 8 million CDRs
in online storage, and 16 million CDRs on automated removable magnetic
backup media.
LGICs current CDR length is 128 bytes, but it could be expanded through
negotiation between Nextwave and LGIC.
DRAFT 3/1/97


256

DRAFT 3/1/97


257
1.3.4.6 MSC Capacity RequirementsSS7 Link Capacity
Definition
This test is intended to verify the total number of SS7 links that the MSC can
support, exclusive of SS7 links that may be required to support inter
operation with the BSS, while also complying with the other performance
criteria given in this document.
This test verifies that the MSC has the port capacity to provide SS7
connectivity to external STPs, sufficient to support the other capacity and
performance criteria given in this document.
1. Test environment
- Make an environment using MGTS so that the MSC acts like a STP as below picture - the
signaling will be routed from signaling point A to C via B

2. Start transmission of messages from MGTS
3. Record the observed CPU load of CSPU and the number of the messages that completes the
signaling
4. Repeat above step under gradual load increasing condition
5. Stop the test when the CPU load becomes 90% or the transmission delay of the message
exceeds 20ms
6. Verify whether the results of the final step satisfies the minimum requirements of this
test item

MSC
(STP)

SPC:B
MGTS
(SEP)
SPC:C
SPC: A
DRAFT 3/1/97


258
Minimum Standard
This system shall support 0.35 Erlangs per Link when Massage Length is 100Byte.
.

DRAFT 3/1/97


259
1.3.4.7 MSC Latency Performance RequirementsPost Dialing Delay
(Mobile-Originated Calls)
Definition
This test is intended to measure the average post dialing delay under load,
and verify that it falls within acceptable limits. The post-dialing delay is the
time between when the caller presses the send button, and the occurrence of
an audible network response, other than switching noise, to the caller.

This test is intended to verify that the average post-dialing delay under load,
for mobile-originated calls, does not exceed acceptable limits. The test must
measure post-dialing delay for mobile originated calls, averaged over one
hour, while the MSC is operated at rated busy hour capacity with an agreed
on mix of traffic reflecting conditions expected in NextWave networks,
including mobility mix, call holding times, and proportion of mobile-
originated and mobile-terminated calls.


1. Set up a DM(Diagnostic Monitor) to log messages transferred to/from MS
2. Originate Mobile-to-Land Call and log messages by DM.( Land means the
test subscriber which is directly connected to MSC and simulate MS
subscriber)
3. Calculate time interval between when message ms_org_msg is received
and so_complete is received.
4. Repeat 2-3 procedure for an hour

5. Calculate the average value gained from procedure 4.
Minimum Standard
Average post-dialing delay under rated load must not exceed 3 sec.


DRAFT 3/1/97


260

DRAFT 3/1/97


261
1.3.4.8 MSC Latency Performance RequirementsAnswer Supervision Delay
Definition
This test is intended to measure the contribution of the MSC to answer
supervision delay. This is the average time interval between time when the
called partys equipment transitions from on-hook status to off-hook status,
and the transmission of answer supervision to the originating system. The
measurement shall be done for both mobile-originated and mobile-
terminated calls.

The test shall measure the contribution of the MSC to answer supervision
delay, averaged over one hour, while the MSC is operated at rated busy hour
capacity with an agreed on mix of traffic reflecting conditions expected in
NextWave networks, including mobility mix, call holding times, and
proportion of mobile-originated and mobile-terminated calls. The
measurement shall be made independently for mobile-originated and mobile-
terminated calls, and the stated requirement must be met for each condition
independent of the other.


1. Set up two DM(Diagnostic Monitor) to log messages transferred to/from
MS
2. Originate Mobile-to-Mobile Call and log messages by DM
3. Measure the time interval between when message tone_off at the
originating side is received and the time when message connect_order at
the termination side is received. Divide this value by 2 to get Answer
Supervision Delay.
4. Repeat 2 - 3 procedure for an hour

5. Calculate the average value earned from procedure 4.

Minimum Standard
DRAFT 3/1/97


262
The average answer supervision delay shall not exceed 250 msec, at rated
load, for either mobile-originated or mobile-terminated calls.

DRAFT 3/1/97


263
1.3.4.9 MSC Latency Performance RequirementsCall Setup Delay (Mobile-
Originated Calls)
Definition
This test is intended to measure the interval between the time when a call
origination message arrives at the MSC, and the time at which an ISUP call
setup message is transmitted by the MSC.

This test shall measure call setup delay within the MSC over a period of one
hour, and compute the average call setup delay and the 99th percentile call
setup delay over all mobile-originated calls during the measurement period.
The MSC shall be operated at rated busy hour capacity for the duration of the
test, with an agreed on mix of traffic reflecting conditions expected in
NextWave networks, including mobility mix, call holding times, and
proportion of mobile-originated and mobile-terminated calls.



1. Load tool that can measure time when certain event is occurred at two or
more different processor.

2. Make a Mobile-to-Land Call

3. Caculate the Call-Setup-Delay(the interval between the time when a call
origination message arrives at the MSC, and the time at which an ISUP call
setup message is transmitted by the MSC) from the loaded tool in the OMP ,
one of MSC processor.

4. Repeat procedure 2-3 for an hour
Minimum Standard
The average call setup delay shall not exceed 2.5 sec, and the TBD percentile
call setup delay shall not exceed TBD second.


DRAFT 3/1/97


264

DRAFT 3/1/97


265
1.3.4.10 MSC Latency Performance RequirementsCall Release Delay
Definition
This test is intended to measure the contribution of the MSC to delays in
releasing a call. The test will measure delays incurred both when the party
that ends the call by going on-hook is the local mobile user, and when the
party ending the call is the distant party (land-line or mobile).
This test will measure delay in the call release process:
The interval between the time that the MSC receives a release order from
the mobile, and the time when the MSC transmits a release (REL)
message.
This test shall measure this delay elements over a period of one hour, and
compute the average value of each of the delay elements. The MSC shall be
operated at rated busy hour capacity for the duration of the test, with an
agreed on mix of traffic reflecting conditions expected in NextWave networks,
including mobility mix, call holding times, and proportion of mobile-
originated and mobile-terminated calls.

1. Load tool that can measure time when a certain event is occurred at the
two or more different processor.
2. Originate Mobile-to-Land Call and log messages from DM

3. Caculate the Call-Release-Delay(the interval between the time when a call
release message generated from MS, and the time at which an ISUP call
release message is transmitted to the other MSC) from the loaded tool in the
OMP.


Minimum Standard
The average delay associated with any of the delay elements described above
shall not exceed 1.0 seconds.
DRAFT 3/1/97


266

DRAFT 3/1/97


267
1.3.4.11 MSC Latency Performance RequirementsFeature Control Delay
Definition
This test is intended to measure the interval between the time that the MSC
receives a feature invocation string or message, and the time at which the
MSC responds. Feature invocation is defined as a successful attempt by the
subscriber to invoke, activate, deactivate, or authorize any cellular subscriber
feature (e.g., call forwarding number). The MSC response is defined as the
expected treatment response to the subscriber request (e.g., special tone,
announcement, greeting, etc.)

The test shall measure the feature control delay over the period of one hour,
and compute the average delay over the measurement period, while the MSC
is operated at rated busy hour capacity with an agreed on mix of traffic
reflecting conditions expected in NextWave networks, including mobility mix,
call holding times, and proportion of mobile-originated and mobile-
terminated calls.


1. Set up two DM(Diagnostic Monitor) to log messages transferred to/from
MS
2. Originate Mobile-to-Mobile Call and log messages by DM
3. In the conversation state, invoke feature message.
4. Calculate time interval between time when message
flash_with_infomation and alert_info is generated
5. Repeat 2 - 4 procedure for an hour

6. Calculate the average value earned from procedure 4.

DRAFT 3/1/97


268
Minimum Standard
The average feature control delay shall not exceed 500 msec.



DRAFT 3/1/97


269
1.3.4.12 MSC Latency Performance RequirementsCall Redirection Delay
Definition
This test is intended to measure the interval between the time that a call
redirection request or order is received at the MSC, and the time that the
redirect is executed. The delay is measured from the receipt of the
redirection request message to the transmission of voice and signaling
information on the prescribed trunk(s).

The test shall measure the call redirection delay over the period of one hour,
and compute the average delay over the measurement period, while the MSC
is operated at rated busy hour capacity with an agreed on mix of traffic
reflecting conditions expected in NextWave networks, including mobility mix,
call holding times, and proportion of mobile-originated and mobile-
terminated calls.



1. Load tool that can measure time when a certain event is occurred at two or
more different processor.

2. Make a Mobile-to-Mobile Call which will be redirected to the another MSC

3. Caculate the Call Redirection Delay(the interval between the time that a
call redirection request or order is received at the MSC, and the time that the
redirect is executed.) from the loaded tool in the OMP , one of MSC processor.


Minimum Standard
The average call redirection delay shall not exceed 500 msec.


DRAFT 3/1/97


270
1.3.4.13 MSC Reliability Requirements
1.3.4.13.1 CPU/Memory reliability : TBD
1.3.4.13.2 Cut-off Calls
1. Set up a LCS(Local Call Simulator)
2. Activate the LCS to try the test subscliber to the test subscribers
3. Record if a call cut-off happens within average holding time
4. Repeat above steps until the number of call becomes over 8000
5.Verify whether the results of the final step satisfies the minimum requirements
of this test item Cut-off calls due to radio environments should be eliminated

Minimum Standard

The Probability that a Stable Call is cut off shall not exceed 0.05 %

1.3.4.13.3 Ineffective machine attempts
The same Procedure with 1.3.2.1 Blocking Probability
1.3.4.13.4 Failure rates : TBD
1.3.4.13.5 Downtimes : TBD
1.3.4.13.6 Outage Classes : TBD

1.4 OAMP Laboratory Acceptance Test Procedures
1.4.1 Network Operation and Maintenance
DRAFT 3/1/97


271
1.4.1.1 Standards Compliance Verification
1.4.1.1.1 Telecommunications Management Network Model
Definition
Telecommunications Management Network is a high level object model for the
network of systems used to manage a telecommunications system. The TMN
model describes the infrastructure upon which OAMP processes are executed.
ITU-T Recommendation M.3010 describes the TMN paradigm.
Requirements
To ascertain the vendors network management systems current and planned
levels of compliance to the TMN model. NextWave will require its network
management systems to be TMN compliant by the year TBD.
Reference to Requirements Document
See Part V, Section 4 Standards Compliance
Method of Verification
Consult vendor documentation. If TMN compliance is not addressed in the
documentation, the vendor will provide a written discussion of its network
management systems current and future levels of compliance to the TMN
model.
1. Verify the description on the definition of the network elements MO.
2. Verify design of the management object sentence using GDMO
(Guidelines for the Definition of Managed Object : X722).
3. The detailed documentation to be submitted later (Apply LGICs
TMN documentation, 2Q97).
Minimum Standard
None at this time, beyond submission of documentation addressing
compliance TMN compliance information is for planning and
developmental purposes.
Vendor Response to Failure: Diagnosis and Action Plan
DRAFT 3/1/97


272
1.4.1.2 Interface Tests
1.4.1.2.1 Physical and Network Protocol Interface Tests
Definition
These interfaces provide the physical and logical interconnection of the local
Operations and Maintenance Center (OMC) management systems, as well as,
remote management systems over the High Level Management Interface
(HLMI). It is through these interfaces that the operator may effect both
manual and automated control and access to information required for OAMP
operations. Additionally, there is an interface at the BTS which allows craft
personnel direct access for testing and configuration of the BTS.

Requirements
Table10 specifies the required physical level and network protocol interfaces
for the HLMI, the OMC and the BTS-sited craft interface. Each physical level
interface shall conform to the electrical and mechanical requirements of its
associated standard. Similarly, for the HLMI and OMC interfaces,
conformance to a network standard is mandatory. The craft interface is not
required to be network protocol capable, but at a minimum is a terminal
interface. However, if the vendor has provided a network protocol
compliance craft interface, it shall be tested as such.
If any of the additional (secondary) interfaces are provided, these too shall be
verified and tested as is appropriate.
Table 10 Physical and Network Protocols
OAMP Physical Interface Network Protocol
Interface to: Primary Secondary Primary Secondary
HLMI Ethernet
Serial
Dial-up (modem)
TCP/UDP over IP
X.25
OMC Ethernet
Serial
Dial-up (modem)
TCP/UDP over IP
X.25
Craft (at BTS) per vendor not required

See Part V, Section 1.3.1.2.1 MMI.
Method of Verification and Testing
MSC Part
DRAFT 3/1/97


273
Verify whether the performance of telnet is normal or not when OMC
terminal connects POMD.
1. OMC terminal connects POMD by typing the shell command telnet
2. Verify whether login and password could be passed.
3. Verify whether the UNIX shell commands are valid.
4. Log out.
( The method of TCP/IP protocol test is not described because the TCP/IP on
Ethernet using by LGICs POMD is a commercial product with respective
industry standards.)
BSS Part
At workstation or x-terminal which are used for OAMP terminal, execute
Telnet application program to main OAMP terminal and check it receives
Logging Prompt.

LGIC POMD(PCS Operation & Maintenance Device)Specifications.

1. Configuration

MSC
BSS
POMD
Local
OMC
CDR
Collector
OMC/NMC
(TMN)
POMD
H
L
M
I
OMC I/F
Billing I/F
H
L
M
I
O
M
C

I
/
F
NE
IPC Ethernet
NE

2. Interface
DRAFT 3/1/97


274
NextWave requirement on POMD interface is for HLMI, OMC and Billing as detailed below.

OAM&P
Interface
Physical Interface Protocol
Primary Secondary Primary Secondary
HLMI Ethernet V.35 CMIP/FTAM over
CLNS/ETHERNET
CMIP/FTAM over
CONS/X.25
OMC Ethernet V.35 TCP/IP over IP X.25
Dialup MODEM
Billing Ethernet TCP/IP over IP

3. H/W and S/W for POMD
Description
SUN UltraServer Enterprise 2
200MHz 2 CPU
256M RAM
10G HDD
8G 4mm DAT
CDROM (Internal)
FDD (Internal)
PT SBS-334 (for V.25 and IPC)
Dummy Terminal
Solaris 2.5.1 Server Media
SunLink X.25
SunLink OSI
SunLink FTAM
HP OpenView DM 4.2 for Solaris 2.5 Runtime Version
Informix C-ISAM
Informix Dynamic Server 7.X

Minimum Standard
The TCP over IP on Ethernet must be available and compliant with respective
DRAFT 3/1/97


275
industry standards.



DRAFT 3/1/97


276
1.4.1.3 Alarm and Fault Management Systems Tests
1.4.1.3.1 Alarm Format
Definition
Alarm messages from various NEs are collected by the network management
systems. Each message contains a minimum set of information describing the
characteristics of the corresponding failure event.

Requirements
The alarm message shall include:
Urgency Class
Localization of the failure to the functional unit level
A textual description of the detected failure condition
Date and time stamp indicating the time of alarm generation
An alarm reference number corresponding to an alarm type described in
the alarm documentation

See Part V, Section 1.3.1.3 Alarm and Fault Management

Processor
1. Make the state of one side of processor which is operating normally
into faulty state by pressing reset button or power on/off.
2. Check the related alarm messages.
Check whether the current state of processor and message are
identical.
3. With removal of fault, the processor shall be recovered with recovery
messages.
4. The same operation to opposite side must produce the same result.
DRAFT 3/1/97


277
5. In the case of processor dual down, the message for dual down
should be produced

Device
1. Make a fault status through removal of functional units, removal of
power, etc.
2. Check the related alarm messages.
3. Check whether the current state of the device and message are same.
4. When the device is recovered from faulty state, Check the messages.

Reference
See Alarm Management Test of LGIC COD and POD documentation.

Minimum Standard
Alarm messages shall contain all information listed in the requirements above.


DRAFT 3/1/97


278
1.4.1.3.2 Fault Recovery
Definition
Certain critical components, e.g., cards and functional units, are provided
with redundant back-up in the case of failure. This is one aspect of fault
recovery -- other aspects include the minimization of damage to equipment in
failure and self initialization in the event of facilities outages.
Requirements
In the event of a failure for which a backup component is available, the
equipment shall automatically perform the necessary actions to remove the
failed unit from service and bring the backup on-line.
In the event of a fault where repeated recovery attempts fail, the relevant
resources shall be removed from service. In particular, in the event of a
critical fault related to any RF high power amplifier (HPA), the HPA shall
immediately be removed from service.
The equipment shall have the capabilities to minimize the need for
equipment initialization upon the occurrence of transient facilities outages.
See Part V, Section 1.3.1.3.2: Fault Localization, Testing and Recovery
MSC Part :
1. Check duplication status of a functional unit(processor or device).
2. Change the status of a unit by powering, resetting, manual removal
or MMC.
3. Confirm the changed state.
4. Verify the normal operation at the changed state.

The duplicated functional units in the MSC which have automatic
back-up faculties are as follows:
Processor

ASP, INP, NTP, OMP, MMP, LRP,
TLSP,GSP,ASIP,CCSP,DTIP,SSP
Device

TSL,CDL,SSW,HIPC,
NES,RG,DKU,MTU

BSS Part
DRAFT 3/1/97


279
1. Check duplication status of the test NE.
2. Verify the status changing of the test NE by powering, resetting or
MMC.

List of components which have automatic back-up faculties in BSS
1. BMC Rack : TMP, TRMA, GPS
2. BSC : CCP, SCP, CIRA
3. BTS : BFP, DCP,RFP
Reference to Verification and Testing
See LGIC COD & POD : Processor and Device Duplication & Redundancy
Test

Minimum Standard

Each backup unit shall be brought on-line within one (1) minute of the failure
of its primary unit.


DRAFT 3/1/97


280
1.4.1.3.3 External Alarm Interface
Definition
The equipment shall have external alarm connections for relay closure
monitoring, whose status shall be available as part of the equipment
management element functionality.
Requirements
The following minimum number of such alarm connections shall be
provided:
BTS : five (5)
BSC : five (5)
MSC : five (5)
See Part V, Section 1.3.1.3.3 External Alarm Connection
Vendor documentation shall be examined to confirm the existence and
functional features of the external alarms.
Each alarm connection shall be activated (simulated relay closure) both
separately and simultaneously with the other external alarm connections
while alarm messages are collected from the corresponding NE.
If necessary, this testing may be completed during the technical phase
acceptance tests, where a higher degree of system integration may facilitate
collection of some alarm messages.
1. Generate external alarm.
2. Verify the generated alarm is displayed.

Minimum Standard
The minimum required number of alarm connections per NE shall be
available and each shall prove functional by generating complete and correct
alarm messages when activated either alone or in concert with other external
alarms.

DRAFT 3/1/97


281
1.4.1.4 Performance Management Systems Tests
1.4.1.4.1 Performance Measurements
Definition
The performance measurements provide a means to monitor and assess
utilization and performance of the network equipment.
Requirements
The BTS equipment shall be capable of logging and collecting statistics for, as a
minimum, the following metrics (all at a minimum rate of 50 Hz):
Sector receive power and attenuation
Sector transmit power and attenuation
Sector agc data
Traffic channel Eb/Nt
Forward and reverse FER per loopback and Markov service option
supported
Traffic channel gain
Traffic channel reverse link set point
Traffic channel searcher data and rake finger data
Power control sub-channel data
Traffic channel transmit and receive data rate
Traffic channel rate decision data
Overhead channel power allocations
All paging and access channel messages
Access channel received SNR per access probe
Round trip delay per traffic channel
Performance information collected by the equipment shall include, as a
minimum, the following general categories:
Busy hour call attempt profile
Call release profile
Access and paging channel statistics
Handoff percentages
Pilot active, candidate and neighbor sets per sector
The following specific performance metrics shall either be provided directly or
shall be derivable from other information provided by the equipment :
Busy hour blocking percentage on a per sector basis
Dropped calls on a per sector basis
Average system blocking
Number of blocked calls per user defined interval
Number of call attempts per user defined interval
DRAFT 3/1/97


282
Number of calls dropped per user defined interval
Number of calls completed per user defined interval
See Part V, Section 1.3.1.4.7 Performance Parameters Collected
BSS Part
During laboratory acceptance testing, all BTS logging, performance
information and performance metrics which can be verified for existence and
functionality shall be tested using both direct and indirect stimulus applied to
the equipment as required. In the case of BTS performance logging, the test
stimulus shall be varied to confirm the minimum logging rate requirement.
In particular, the following subset of performance measurement functions
should be verifiable in the laboratory:
BTS equipment performance logging (terminal where each performance
measurement is available, rate)
Sector receive power and attenuation (RFP,when user request )
Sector transmit power and attenuation (RFP, 20Hz)
Rf Calibration data (RFP, when user request)
Sector agc data (DCP, 1/30 Hz(30 second))
Traffic channel Eb/Nt (Cell DM, 50Hz)
Forward and reverse FER per loopback and markov service option
supported (Cell DM, 1/2Hz)
Traffic channel transmit power( Cell DM,50Hz)
Traffic channel gain (Cell DM, 50Hz)
Traffic channel reverse link set point (Cell DM, 50Hz)
Traffic channel searcher data and rake finger data (Cell DM, 50Hz)
Power control sub-channel data (Cell DM, 50Hz)
Traffic channel transmit and receive data rate (Cell DM, 50Hz)
Traffic channel rate decision data (Cell DM, 50Hz)
Overhead channel power allocations (BSP, 20Hz)
All paging and access channel messages (BSP, call based)
Access channel received SNR per access probe (Cell DM, at each
probe access)
Number of OCNS channel users and gains(Cell DM,when user
request)
Round trip delay per traffic channel (Cell DM, 2Hz)
Performance information (BSM /OMC,hour and day)
DRAFT 3/1/97


283
Busy hour call attempt profile
Service option utilization
Capacity utilization
Backhaul utilization
Call release profile
Access and paging channel statistics
Handoff percentages
Pilot active, candidate and neighbor sets per sector
Derivable performance metrics (BSM or OMC)
Dropped calls on a per sector basis
Number of blocked calls per user defined interval
Number of call attempts per user defined interval
Number of calls dropped per user defined interval
Number of calls completed per user defined interval
Those performance measurements not completely verifiable and/or
testable
during the (previous) laboratory and technical phases shall be
verified/tested
to completion during the market phase of the acceptance test procedures.

MSC Part
1. Generate call for 24 hours.
2. Set up statistics operation for statistics item corresponding to MSC using
statistics command.
3. Verify whether the set-up statistics item is output normally.
4. Cancel the set-up statistics operation.
Note) Statistics item related to MSC is as following.
Call Attempt to be output at a designated time
Item related to call release per reason
Item related to handoff

Minimum Standard
Those performance measurement features which may be tested in the
laboratory phase ATP shall meet all functional requirements.
DRAFT 3/1/97


284
1.4.1.4.2 Call Detail Records Tests
1.4.1.4.2.1 Interface and Protocol
Definition
The CDR interfaces and protocols are the means by which the network
management system collects CDR information from network elements.

Requirements
TCP over IP operating on an Ethernet interface is required.
A secondary, standard serial interface such as RS232-D or X.21 may be
provided.
X.25 may be provide as a secondary transfer protocol.

See Part V, Sections 1.4.3.1.4 Interface and 1.4.3.1.5 Transfer Protocol

Verify whether the performance of telnet is normal or not when OMC
terminal connects POMD.
1. OMC terminal connects POMD by typing the shell command telnet
2. Verify whether login and password could be passed.
3. Verify whether the UNIX shell commands are valid.
4. Log out.
( The method of TCP/IP protocol test is not described because the TCP/IP on
Ethernet using by LGICs POMD is a commercial product with respective
industry standards.)
Minimum Standard
The TCP over IP on Ethernet must be available and compliant with respective
industry standards.


DRAFT 3/1/97


285
DRAFT 3/1/97


286

1.4.2 Mobile Management Functionality
1.4.2.1 J-STD-008 Set Parameters Messages and Retrieve Parameters Messages Tests
Definition
Through the OA&M interface, it shall be possible to set and retrieve all
parameters specified in Appendix E of J-STD-008. That is, upon request of the
OA&M system, the equipment shall generate J-STD-008 Set Parameters
Messages and Retrieve Parameters Messages, and shall provide positive or
negative acknowledgment to the OA&M interface.

Requirements
Each parameter shall be settable/ retrievable individually. In addition, the
interface shall allow setting/retrieving parameters as a group, where the
members of the group are specified through the interface.
If a request to set or retrieve a parameter is received from the interface, the
equipment shall determine the location of the personal station before sending
the message. If the personal station is currently not on a traffic channel, the
equipment shall perform call setup in order to send the Set Parameters
Messages and Retrieve Parameters Messages (which may only be sent on the
traffic channel).

See Part V, Section 2: Mobile Management

Using an OA&M interface into the vendor equipment, the following actions
shall be performed for a mobile unit initially assigned a traffic channel:
1. Each parameter shall be retrieved individually and examined.
2. All parameters shall be retrieved as a group and examined.
3. Each parameter shall be reset.
4. All parameters shall be retrieved as a group and examined.
5. The current call shall be terminated.
DRAFT 3/1/97


287
6. A series of 10 Markov calls to/from the mobile shall be executed and
completed. During some of these calls, impairments shall be introduced
into the forward link to induce some frame errors. For at least one call,
impairments to the forward link shall precipitate a dropped call. For one
call, the reverse link shall be degraded sufficiently to cause a dropped call.
No hand-off capability is assumed for the laboratory phase testing.
7. Via the OA&M interface, each parameter shall be retrieved and examined.
The mobile shall not have a call in progress when the first parameter
retrieval request is made.
8. The parameters shall be retrieved as a single group and examined.
9. The parameters shall be reset as a single group.
10. The parameters shall be retrieved as a single group and examined to
confirm reset.
11. With the test mobile turned off, the OA&M system will attempt to set
and retrieve several parameters to confirm negative acknowledgments of
the operations.

Minimum Standard
The test procedure shall demonstrate that the OA&M interface may
effectively execute set and retrieval of any and all parameters singly or in a
group and that proper system acknowledgment is provide for each request.



1.5 System Integration Tests
The ATP shall be delivered to NextWave Telecom at end of Aplil . 1997
DRAFT 3/1/97


288
1.5.1.1 BSS
1.5.1.1.1 DC Power Measurement

1.5.1.1.2 System Initial

1.5.1.1.3 System Time Verification

1.5.1.1.4 Alarm Status Report

1.5.1.1.5 Feature of Duplication

1.5.1.1.6 System Parameter Display

1.5.1.1.7 Neighbor List Display

1.5.1.1.8 System Network Maintenance Test

1.5.1.1.9 Tx/Rx Path Calibration

1.5.1.1.10 Tx/Rx Antenna VSWR Test

1.5.1.1.11 Breathing

DRAFT 3/1/97


289
1.5.1.2 MSC

1.5.1.2.1 DC Power Measurement

1.5.1.2.2 System Initial

1.5.1.2.3 System Clock Verification

1.5.1.2.4 Alarm Status Report

1.5.1.2.5 Feature of Duplication

1.5.1.2.6 Office Data Display

1.5.1.2.7 Paging/Registration Zone Display

1.5.1.2.8 Signaling Trace


DRAFT 3/1/97


290
1.5.2.1 RF Transmiter

1.1.3.2.1 Frequency Tolerance

1.1.3.2.2 Wave form Quality

1.1.3.2.3 Pilot Time Tolerance

1.1.3.2.4 Code Domain Power

1.1.3.2.5 Emission

DRAFT 3/1/97


291
1.5.2.2 RF Receiver

1.5.2.2.1 Rx Sensitivity

1.5.2.2.2 Conducted Spurious emission

1.5.3 Site Acceptance Tests
DRAFT 3/1/97


292
1.5.3.1 Call Tests

1.5.3.1.1 Dialing Procedures and Call Processing Treatments

1.5.3.1.2 CDR Test

DRAFT 3/1/97


293
1.5.3.2 Hand Off Tests

1.5.3.2.1 Softer Hand off test

1.5.3.2.2 Soft Hand off test

CDMA Infrastructure System Acceptance Laboratory Tests: LG Information & Communications, LTD

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CDMA Infrastructure System Acceptance Laboratory Tests: LG Information & Communications, LTD

Uploaded by

Copyright:

Available Formats

CDMA Infrastructure

System Acceptance Laboratory Tests

5dB at each base station

5dB at each base station

5dB at each base station

( EXCESS POWER < 0.4dB )

You might also like