Course RF200
Wireless Systems RF
Performance Optimization
CDMA 1xRTT, 1xEV-DO, and LTE Preview
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 1
Contents
 CDMA and 1xRTT
• Overview
• Call Processing, Layer-3 Messaging
• System Acquisition, Registration, Incoming/Outgoing Calls, Handoff
• Perf. Indicators, Problem Signatures
• Search Windows, Neighbor Lists, PN Planning
• Data Collection, Analysis
• Multi-carrier operation, troubleshooting
• 1xRTT Data Operation and Optimization
• Applied Optimization and Practical Considerations
 1xEV-DO
• Performance Indicators, Backhaul Considerations, RF Optimization
• Setup performance, throughput optimization fwd/rev links, QOS
 LTE Preview
• Types of testing: Core Network and RAN
• Commercial Tools Survey
• Performance Indicators
• Scheduler considerations
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 2
Course RF200
Introduction to Performance
Optimization
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 3
Welcome to Course RF200
 Course RF100 is an introduction to RF and CDMA principles. After
completing it, you should be familiar with:
• General RF system design principles
• CDMA technology - principles, channels, network basics
• key fundamentals of Messaging and Call Processing
 Course RF200 covers how to recognize and deal with system
performance problems
• key performance indicators and what they mean
• what tools are available for discovering and analyzing
problems
• mechanisms and situations that cause trouble
• how to solve many of the problems you’ll see
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 4
Section I. CDMA
August, 2013
Course RF200v8 (c)2013 Scott Baxter
5
A
Good Performance is so Simple!!
BTS
BTS
FORWARD
LINK
August, 2013
BTS C
BTS B
BTS A
Ec/Io
BTS
 One, Two, or Three good signals in handoff
• Composite Ec/Io > -10 db
 Enough capacity
• No resource problems – I’ve got what I
need
-10
available
power
Traffic
Channels
In use
Paging
Sync
Pilot
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 6
Good Performance is so Simple!!
BTS
BTS
BTS C
BTS B
BTS A
Ec/Io
BTS
 One, Two, or Three good signals in handoff
• Composite Ec/Io > -10 db
 Enough capacity
• No resource problems – I’ve got what I
need
In principle, a COW next door can
solve almost any CDMA problem!
-10
Reality Check:
FORWARD
LINK
August, 2013
available
power
Traffic
Channels
In use
Paging
Sync
Pilot
1. But who has enough regular cells OR cows or money to
fix every problem location?!!
2. Problems occur in the areas between cells’ dominant
coverage. Adding a cow only pushes the problems
out to its own boundary with other cells.
Conclusion: We need to design better, and to use our
existing cells more effectively. We need to provide
one, two, or three dominant signals everywhere.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 7
Bad Performance Has Many Causes
+41
+8
360
A
360+33c
BTS
B
BTS
BTS Sector Transmitter
No
Available
Power!
Traffic
Channels
In Use
Paging
Sync
Pilot
BTS Rx Pwr
Overload
CEs
x
Vocoders
Selectors
BTS A
PN 100
BTS B
PN 99
ACTIVE SEARCH WINDOW
1 mile
11 miles
August, 2013
 Weak Signal / Coverage Hole
 Pilot Pollution
• Excessive Soft Handoff
 Handoff Failures, “Rogue” mobiles
• Missing Neighbors
• Search Windows Too Small
• BTS Resource Overload / No Resources
– No Forward Power, Channel
Elements
– No available Walsh Codes
– No space in Packet Pipes
 Pilot “Surprise” ambush; Slow Handoffs
 PN Plan errors
 Slow Data Problems: RF or IP congestion
 Improper cell or reradiator configuration
 Hardware and software failures
 But on analysis, all of these problems’ bad
effects happen because the simple few-signal
ideal CDMA environment isn’t possible.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 8
What is Performance Optimization?
 The words “performance optimization” mean different things to
different people, viewed from the perspective of their own jobs
 System Performance Optimization includes many different smaller
processes at many points during a system’s life
• recognizing and resolving system-design-related issues (can’t
build a crucial site, too much overlap/soft handoff, coverage
holes, etc.)
• “cluster testing” and “cell integration” to ensure that new base
station hardware works and that call processing is normal
• “fine-tuning” system parameters to wring out the best possible
call performance
• identifying causes of specific problems and customer
complaints, and fixing them
• carefully watching system traffic growth and the problems it
causes - implementing short-term fixes to ease “hot spots”, and
recognizing problems before they become critical
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 9
Performance Optimization Phases/Activities
Phase
Drivers/Objectives
Activities
Main Tools
Success Indicators
RF Design and
Cell Planning
Cover desired area;
have capacity for
anticipated traffic
Plan cells to effectively cover
as needed and divide traffic
load appropriately
Prop. Models,
Test Transmitters,
planning tools
Model results
New Cluster
Testing and Cell
Integration
Ensure cells properly
constructed and
configured to give
normal performance
Drive-test: coverage, all
handoff boundaries, all call
events and scenarios
Drive-test tools;
cell diagnostics and
hardware test
All handoffs occur;
all test cases
verified
Solve Specific
Performance
Problems
Identify problems
from complaints or
statistics; fix them!
Detect, Investigate, Resolve
performance problems
Drive-test tools,
system stats,
customer reports
Identified
problems are
resolved
Well-System
Performance
Management
Ensure present ‘plant’
is giving best possible
performance
Watch stats: Drops, Blocks,
Access Failures; identify/fix hot
spots
System statistics
Acceptable levels
and good trends
for all indicators
Capacity
Optimization
Manage congested
areas for most
effective performance
Watch capacity indicators;
identify problem areas, tune
parameters & configuration
Smart optimization
of parameters;
system statistics
Stats-Derived
indicators; carried
traffic levels
Traffic analysis and
trending tools;
prop. models for
cell spliiting; carrier
additions
Sectors are
expanded soon
after first signs of
congestion; capital
budget remains
within comfortable
bounds
Growth
Management:
Optimizing both
Performance
and Capital
Effectiveness
 hello
August, 2013
Overall traffic
increases and
congestion;
competition for capital
during tight times
Predict sector and area
exhaustion: plan and validate
effective growth plan, avoid
integration impact
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 10
Course RF200
CDMA2000 Layer 3 Messages
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 11
Messages in CDMA
 In CDMA, most call processing events are driven by messages
 Some CDMA channels exist for the sole purpose of carrying
messages; they never carry user’s voice traffic
• Sync Channel (a forward channel)
• Paging Channel (a forward channel)
• Access Channel (a reverse channel)
• Forward or Reverse Dedicated Control Channels
• On these channels, there are only messages, not voice or data
 Some CDMA channels exist just to carry user traffic
• Forward Fundamental and Supplemental Channels
• Reverse Fundamental and Supplemental Channels
• On these channels, most of the time is filled with traffic and
messages are sent only when there is something to do
 All CDMA messages have very similar structure, regardless of the
channel on which they are sent
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 12
The Basic Format of CDMA Messages
 CDMA messages on both forward
and reverse traffic channels are
normally sent via dim-and-burst
 Messages include many fields of
binary data
 The first byte of each message
identifies message type: this allows
the recipient to parse the contents
 To ensure no messages are
missed, all CDMA messages bear
serial numbers and important
messages contain a bit requesting
acknowledgment
 Messages not promptly
acknowledged are retransmitted
several times. If not acknowledged,
the sender may release the call
 Field data processing tools capture
and display the messages for study
EXAMPLE:
A POWER MEASUREMENT
REPORT MESSAGE
MSG_TYPE (‘00000110’)
8
ACK_SEQ
3
MSG_SEQ
3
ACK_REQ
1
ENCRYPTION
2
ERRORS_DETECTED
5
POWER_MEAS_FRAMES
10
LAST_HDM_SEQ
2
NUM_PILOTS
4
NUM_PILOTS occurrences of this field:
PILOT_STRENGTH
RESERVED (‘0’s)
August, 2013
Length
(in bits)
Field
RF200 v8.0 (c) 2013 Scott Baxter
6
0-7
RF200 - 13
t
Message Vocabulary: Acquisition & Idle States
Pilot Channel
Sync Channel
No Messages
Sync Channel Msg
Paging Channel
Access Parameters Msg
General Page Msg
System Parameters Msg
Order Msg
BTS
Access Channel
Registration Msg
Order Msg
• Mobile Station Acknowldgment
• Long Code Transition Request
• SSD Update Confirmation
many others…..
CDMA Channel List Msg
•Base Station Acknowledgment
•Lock until Power-Cycled
• Maintenance required
many others…..
Extended System
Parameters Msg
Channel Assignment
Msg
Origination Msg
Extended Neighbor
List Msg
Feature Notification Msg
Page Response Msg
Global Service
Redirection Msg
Authentication
Challenge Msg
Authentication Challenge
Response Msg
Service Redirection Msg
Status Request Msg
Status Response Msg
SSD Update Msg
TMSI Assignment Msg
TMSI Assignment
Completion Message
Null Msg
Data Burst Msg
Data Burst Msg
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 14
Message Vocabulary: Conversation State
Forward Traffic Channel
Order Msg
• Base Station Acknowledgment
• Base Station Challenge
Confirmation
• Message Encryption Mode
Alert With
Information Msg
Reverse Traffic Channel
Service Request Msg
Service Request Msg
Origination
Continuation Msg
Authentication
Challenge Msg
Service Response Msg
Service Response Msg
Authentication Challenge
Response Msg
TMSI Assignment Msg
Service Connect Msg
Service Connect
Completion Message
TMSI Assignment
Completion Message
Send Burst DTMF Msg
Service Option
Control Msg
Service Option Control
Message
Send Burst DTMF Msg
Set Parameters Msg
Status Request Msg
Status Response Msg
Parameters Response
Message
Power Control
Parameters Msg.
Flash With
Information Msg
Flash With
Information Msg
Power Measurement
Report Msg
Retrieve Parameters Msg
Data Burst Msg
Data Burst Message
Order Message
Analog Handoff
Direction Msg
Extended Handoff
Direction Msg
Pilot Strength
Measurement Msg
SSD Update Msg
Neighbor List
Update Msg
Handoff Completion Msg
Mobile Station
Registered Msg
In-Traffic System
Parameters Msg
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
• Mobile Sta. Acknowledgment
•Long Code Transition
Request
• SSD Update Confirmation
• Connect
RF200 - 15
Course RF200
CDMA Call Processing Basics
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 16
Troubleshooting Call Processing
 CDMA call processing is complex!
• Calls are a relationship between mobile and system
– the events driven by messaging
– the channels supported by RF transmission
• Multiple codes and channels available for use
• Multiple possible problems - physical, configuration, software
• Multiple concurrent processes in the mobile and the system
 Troubleshooting focuses on the desired call events
• What is the desired sequence of events?
• Compare the actual sequence of events.
– What’s missing or wrong? Why did it happen?
 Messaging is a major blow-by-blow troubleshooting tool
 RF indications reveal the transmission risks and the channel
configurations
Bottom Line: To troubleshoot effectively, you’ve got to know call
processing steps and details AND the RF basis of the transmission
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 17
Course RF200
Let's Acquire The System!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 18
System Acquisition Messaging
SYNC CHANNEL
SYNC CHANNEL MESSAGE
PAGING CHANNEL
SYSTEM PARAMETERS
MESSAGE
ACCESS PARAMETERS
MESSAGE
NEIGHBOR LIST
MESSAGE
EXTENDED SYSTEM
PARAMETERS MSG
CDMA CHANNEL LIST
MESSAGE
ACCESS CHANNEL
GLOBAL SERVICE
REDIRECTION MSG
REGISTRATION
MESSAGE
PROBE INFORMATION
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 19
Traffic Correlator
PN xxx Walsh xx
Traffic Correlator
PN xxx Walsh xx
AGC
Duplexer
RF
Open Loop
RF
Transmitter
RF Section
August, 2013
bits
t 
time-aligned
Receiver
RF Section
IF, Detector
control
Traffic Correlator
PN xxx Walsh xx
power
Chips
Digital
Rake Receiver Symbols
Traffic Correlator
PN xxx Walsh xx
summing
What’s In a Handset? How does it work?
Symbols
Viterbi Decoder,
Convl. Decoder,
Demultiplexer
Packets
Audio
Messages
Pilot Searcher
PN xxx Walsh 0
CPU
Vocoder
Transmit Gain Adjust
Transmitter
Digital Section
Audio
Messages
Long Code Gen.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 20
The Task of Finding the Right System
Reverse Link Frequencies
(Mobile Transmit)
Forward Link Frequencies
(Base Station Transmit)
800 MHz. Cellular Spectrum
835
824 MHz.
845
A
849
870
B
825
A
Paging, ESMR, etc.
890
880
B
869
846.5
894
891.5
1900 MHz. PCS Spectrum
A
D
1850MHz.
B
E F
C
unlic. unlic.
data voice
1910MHz.
D
B
E F
1930MHz.
Mobile scans forward link frequencies:
(Cellular or PCS, depending on model)
History List (MRU)
Preferred Roaming List (PRL)
until a CDMA signal is found.
Use PRL to find best signal in area.
NO CDMA? Try AMPS. No AMPS? Standby
August, 2013
A
C
1990 MHz.
FREQUENCY LISTS:
HISTORY
LIST/MRU
Last-used:
Freq
Freq
Freq
Freq
Freq
etc.
RF200 v8.0 (c) 2013 Scott Baxter
PREFERRED
ROAMING
LIST/PRL
System1
System2
System3
System4
System5
etc.
RF200 - 21
The System Determination Algorithm
 At turnon, Idle mobiles use proprietary System Determination Algorithms
(SDA) to find the initial CDMA carrier intended for them to use
 The mobile finally acquires a CDMA signal and reads the Sync channel
• Find the SID & NID in the PRL (Preferred Roaming List)
• Check: is there a more-preferred system in the PRL? What Freq(s)?
• Go look for the better system
Start
Preferred
Only Bit
MRU
0
PRL
Acq Idx
Yes
Go to last
Strongest
frequency
PN, read
from MRU
Sync
No Signal
Is SID
permitted?
Denied SID
Is better
SID
available?
No
Read
Paging
Channel
Last Resort:
GEO escape
Or Analog
Best System Found!
Begin Normal Paging Channel Operation
Legend
Steps from
the CDMA
standards
August, 2013
Steps from
proprietary
SDAs
Proprietary
SDA
databases
Typical Mobile
System Determination Algorithm
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 22
Ec/Io
1xRTT Acquisition On the Current Frequency:
Find Strongest Pilot, Read Sync Channel
All PN Offsets
0
1. Pilot Searcher Scans the Entire Range of PNs
-20
Chips 0
PN 0
32K
SYNC CHANNEL MESSAGE 512
2. Put Rake finger(s) on strongest
available PN, decode Walsh 32,
and read Sync Channel Message
Active Pilot
Handset
Rake Receiver
F1 PN168 W32

RF
F2 PN168 W32
x
F3 PN168 W32

LO
Srch PN??? W0
August, 2013
 Rake Fingers


Reference PN
001594, Time 16:33:58.838, Record
71913, QcpCdmaLogMsgSyncChan
MSG_LENGTH: 28 octets
MSG_TYPE: Sync Channel Message
P_REV: IS-2000 Revision 0
Is this the
MIN_P_REV: J-STD-008
right system
SID: 5216 NID: 0
to use?
PILOT_PN: 168
Check the
LC_STATE: 0x02 90 9D 0B 49 AC
PRL!
SYS_TIME: 01/25/2006 09:01:15
LP_SEC: 14
LTM_OFF: -600 minutes
DAYLT: No
PRAT: 9600 bps
CDMA_FREQ: 425
EXT_CDMA_FREQ: 425
SR1_BCCH_SUPPORTED: No
SR3_INCL: No DS_INCL: No
RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 23
Climbing the GEO Group
SYSTEM TABLE
August, 2013
ACQUISITION TABLE
NEG/
NID PREF
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
65535 Pref
GEO
NEW
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
NEW
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
SAME
a GEO GROUP
 When traveling the first signal
found is usually not the best
one to use
 When the SID and NID are
looked up in the PRL, they
are far down the list of
available choices
 The starts at the top of the
GEO group and works down
to the first (most preferred)
system it can find
• the Acquisition Table is
the list of frequencies
used by the various
systems, so the mobile
knows where to search
SID
4144
4812
205
208
208
342
342
478
1038
1050
1058
1375
1385
143
143
4103
4157
312
444
444
1008
1012
1014
1688
113
113
179
179
465
2119
2094
1005
1013
a GEO GROUP
Roaming List Type:
IS-683A
Preferred Only:
FALSE
Default Roaming Indicator:
0
Preferred List ID:
10018
INDEX
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
Climb!
ROAMING LIST
ACQ ROAM
PRI INDEX IND
SAME 13
1
MORE 21
1
SAME
4
0
MORE 37
0
SAME
4
0
MORE 37
0
SAME
4
0
SAME
4
0
SAME
4
0
SAME
4
0
SAME
4
0
SAME
4
0
MORE
4
0
MORE 37
0
MORE
4
0
SAME
3
1
MORE
2
1
SAME
4
0
MORE 37
0
SAME
4
0
SAME
4
0
SAME
4
0
SAME
4
0
MORE
4
0
MORE 37
0
SAME
4
0
MORE 37
0
SAME
4
0
SAME
4
0
MORE
4
0
MORE
4
0
SAME
4
0
SAME
4
0
INDEX ACQ TYPE
0
6
1
6
2
6
3
6
4
1
5
6
6
6
7
6
8
6
9
6
10
6
11
6
12
6
13
6
14
6
15
6
16
6
17
6
18
6
19
6
20
6
21
6
22
6
23
6
24
6
25
6
26
6
27
1
28
1
29
5
30
5
31
5
32
5
33
5
34
5
35
4
36
4
37
4
38
6
39
6
40
6
41
6
42
6
43
6
44
6
45
6
46
6
CH1
500
575
50
25
Both
450
675
250
550
75
200
425
500
500
650
25
425
200
825
350
750
325
1150
350
25
50
500
A
B
A
B
C
D
E
F
A
B
Both
350
25
675
850
650
450
325
150
1025
CH2
425
625
100
200
CH3
825
500
75
350
CH4
575
425
475
375
CH5 CH6 CH7 CH8 CH9
850 325 625
500
500
50
375
50
250
500
575
625
500
50
550
50
850
325
725
725
1175
875
1175
200
1075
350
600
175
425
175
175
575
475
350
675
375
225
175
925
375
775
350
575
575
650
475
625
250
50
25
25
50
25
350
725
375
325
675
375
75
250
750
250
325
825
25
850
375 1175
200 75 175 250
100 250 75
825
825
100
600
750
850 1175 775
825
725
850 175 250
50 475 175 250
650
775 575 725 425
425 50 575
175
775
675
25
1175 725 600 100
750
375
775 425 575 625
475
350 375 1025 1050 1075
475 625 675
1050 1075
PRL: Preferred Roaming List
Programmed into each phone by the system
operator; can be updated over the air.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 24
Ec/Io
Found it! Now we’re on the Right System
All PN Offsets
0
1. Pilot Searcher Scans the Entire Range of PNs
-20
Chips 0
PN 0
32K
512
SYNC CHANNEL MESSAGE
2. Put Rake finger(s) on strongest
available PN, decode Walsh 32,
and read Sync Channel Message
Active Pilot
Handset
Rake Fingers
Rake Receiver
F1 PN168 W32

RF
F2 PN168 W32
x
F3 PN168 W32

LO
Srch PN??? W0
August, 2013



Ref.
PN
98/05/24 23:14:09.817 [SCH]
MSG_LENGTH = 208 bits
MSG_TYPE = Sync Channel Message
P_REV = 3
If PRL shows:
MIN_P_REV = 2
SID = 179
This is the Best
NID = 0
Available System!
PILOT_PN = 168
Offset Index
LC_STATE = 0x0348D60E013
SYS_TIME = 98/05/24 23:14:10.160
LP_SEC = 12
LTM_OFF = -300 minutes
DAYLT = 0
PRAT = 9600 bps
RESERVED = 1
RF200 v8.0 (c) 2013 Scott Baxter
Go to the
Paging
Channel!
RF200 - 25
Course RF200
After finding the right system:
Normal Paging Channel Operation
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 26
The Configuration Messages
 After reading the Sync Channel, the mobile is now capable of reading the
Paging Channel, which it now monitors constantly
 Before it is allowed to transmit or operate on this system, the mobile must
collect a complete set of configuration messages
 In IS-95, the configuration messages are sent on the Paging Channel,
repeated every 1.28 seconds
 In CDMA2000 systems, the configuration messages may be sent on the
separate F-BCH channel
• This would be indicated as SR1_BCCH_SUPPORTED = 1
 There are six possible types of configuration messages; some are
optional; and they may happen in any order
 The configuration messages contain sequence numbers so the mobile
can recognize if any of the messages have been freshly updated as it
continues to monitor the paging channel
• Access parameters message sequence number
• Configuration message sequence number
• If a mobile notices a changed sequence number, or if 600 seconds
passes since the last time these messages were read, the mobile
reads all of them again
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 27
Ec/Io
Reading the Configuration Messages
All PN Offsets
0
-20
Chips 0
PN 0
Read the
Configuration Messages
Access Parameters Msg
Keep Rake finger(s) on strongest
available PN, monitor Walsh 1,
the Paging Channel
System Parameters Msg
CDMA Channel List Msg
Active Pilot
Handset
Rake Receiver
F1 PN168 W01

RF
x
LO

F2 PN168 W01
32K
512
Extended System
Parameters Msg (*opt.)
(Extended*) Neighbor
List Msg
 Rake Fingers


Global Service
Redirection Msg (*opt.)
F3 PN168 W01
Srch PN??? W0
Now we’re ready to operate!!
Reference PN
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 28
1xRTT Access Parameters Message
ACCESS PARAMETERS MESSAGE
01/18/2006 16:19:51
MSG_LENGTH: 19 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Access Parameters Message
PILOT_PN: 4
ACC_MSG_SEQ: 4
ACC_CHAN: 1 Access Channel(s)
NOM_PWR: 0 dB INIT_PWR: 0 dB
PWR_STEP: 4 dB
NUM_STEP: 5 Probe(s)
MAX_CAP_SZ: 10 ACH Frames
PAM_SZ: 4 ACH Frame(s)
PSIST(0-9): 0
PSIST(10): 0
PSIST(11): 0
PSIST(12): 0
PSIST(13): 0
PSIST(14): 0
PSIST(15): 0
MSG_PSIST: 1.00
REG_PSIST: 1.00
PROBE_PN_RAN: 127 PN chip(s)
ACC_TMO: 320 ms
PROBE_BKOFF: 1 Slot(s)
BKOFF: 1 Slot(s)
MAX_REQ_SEQ: 2
MAX_RSP_SEQ: 2
AUTH_MODE: 0
NOM_PWR_EXT: -8 to 7 dB inclusive
PSIST_EMG_INCL: No
RESERVED: 0
August, 2013
Basic Access Procedure
Any Access Msg
Success!
BTS
MS
Probing
an Access Probe
a Probe Sequence
an Access Attempt
 The Access Parameters message
controls all the steps mobiles must
perform when they transmit on the
Access Channel
 Mobiles perform a trial-and-error
process called “Probing” to get their
messages through
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 29
Phone Operation on the Access Channel
Successful Basic Access Attempt
 A sector’s Paging Channel announces 1
(typ) to 32 (max) Access Channels: PN
Long Code offsets for mobiles to use if
accessing the system.
• For mobiles sending Registration,
Origination, Page Responses
• Base Station always listening!
 On the access channel, phones are not
yet under BTS closed-loop power control!
 Phones access the BTS by “probing” at
power levels determined by receive power
and an open loop formula
• If “probe” not acknowledged by BTS
within ACC_TMO (~400 mS.), phone
will wait a random time (~200 mS)
then probe again, stronger by PI db.
• There can be 15 max. (typ. 5) probes
in a sequence and 15 max. (typ. 2)
sequences in an access attempt
• most attempts succeed on first probe!
 The Access Parameters message on the
paging channel announces values of all
related parameters
Origination Msg
ACCESS
Success!
BTS
MS
Probing
an Access Probe
a Probe Sequence
an Access Attempt
PAGING Base Sta. Acknlgmt. Order
FW TFC TFC frames of 000s
PAGING
Channel Assnmt. Msg.
TFC preamble of 000s
FW FC
RV TFC
Base Sta. Acknlgmt. Order
Mobile Sta. Ackngmt. Order RV TFC
FW TFC
Service Connect Msg.
Svc. Connect Complete Msg RV TFC
FW TFC Base Sta. Acknlgmt. Order
Call is Established!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 30
1xRTT System Parameters Message
SYSTEM PARAMETERS MESSAGE
000029, Time 15:28:37.607, Record 6330,
QcpCdmaLogMsgPagingChan
PD: P_REV_IN_USE < 6
MSG_TYPE: System Parameters Message
PILOT_PN: 36
CONFIG_MSG_SEQ: 1
SID: 4379 NID: 15 REG_ZONE: 6
TOTAL_ZONES: 3 ZONE_TIMER: 1 min
MULT_SIDS: No MULT_NIDS: No BASE_ID: 2155
BASE_CLASS: Public PCS System
# Paging Channels, Slotted
PAGE_CHAN: 1 MAX_SLOT_CYCLE_INDEX: 1
HOME_REG: Yes FOR_SID_REG: Yes FOR_NID_REG: Yes
POWER_UP_REG: Yes POWER_DOWN_REG: Yes
Who Registers?
PARAMETER_REG: No
Why & When?
REG_PRD: 30.89 min
BASE_LAT: 37D18'35.00N
BASE_LONG: 079D15'19.00W
REG_DIST: 0 SRCH_WIN_A: 60 chips
Search Window
SRCH_WIN_N: 60 chips SRCH_WIN_R: 80 chips
Widths
NGHBR_MAX_AGE: 0
PWR_REP_THRESH: 2 Bad Frame(s)
PWR_REP_FRAMES: 113 frame(s)
PWR_THRESH_ENABLE: Yes
Handoff Thresholds
PWR_PERIOD_ENABLE: No
PWR_REP_DELAY: 4 frames
RESCAN: No T_ADD: -14.0 dB T_DROP: -16.0 dB
T_COMP: 4.0 T_TDROP: 4 sec
EXT_SYS_PARAMETER: Yes EXT_NGHBR_LIST: Yes
GEN_NGHBR_LIST: No GLOBAL_REDIRECT: Yes
PRI_NGHBR_LIST: No USER_ZONE_ID: No
What other optional
EXT_GLOBAL_REDIRECT: No
configuration messages
EXT_CHAN_LIST: Yes
RESERVED: 0
exist?
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
Mode period
RF200 - 31
Configuration Messages:
Extended System Parameters Message
QcpCdmaLogMsgPagingChan
01/18/2006 16:19:51
MSG_LENGTH: 21 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Extended System Parameters Message
PILOT_PN: 4 CONFIG_MSG_SEQ: 25
DELETE_FOR_TMSI: No USE_TMSI: No
PREF_MSID_TYPE: IMSI and ESN
MCC: 1134 IMSI_11_12: 813
TMSI_ZONE_LEN: 1 octet TMSI_ZONE: 0
BCAST_INDEX: Disable Periodic Broadcast Paging
IMSI_T_SUPPORTED: No
P_REV: IS-2000 Revision 0 MIN_P_REV: J-STD-008
SOFT_SLOPE: 0 ADD_INTERCEPT: 0 dB
DROP_INTERCEPT: 0 dB
PACKET_ZONE_ID: 33 MAX_NUM_ALT_SO: 0
RESELECT_INCLUDED: No PILOT_REPORT: No
NGHBR_SET_ENTRY_INFO: No
NGHBR_SET_ACCESS_INFO: No
BROADCAST_GPS_ASST: No
QPCH_SUPPORTED: Yes
NUM_QPCH: 1 QPCH_RATE: 9600 bps
QPCH_POWER_LEVEL_PAGE: 3 dB below Pilot Channel Transmit Power
QPCH_CCI_SUPPORTED: Yes
QPCH_POWER_LEVEL_CONFIG: 3 dB below Pilot Channel Transmit Power
SDB_SUPPORTED: No
RLGAIN_TRAFFIC_PILOT: 0.000000 dB
REV_PWR_CNTL_DELAY_INCL: No
AUTO_MSG_SUPPORTED: No
August, 2013
 The Extended System
Parameters Message tells
the mobile additional key
parameters:
• Preferred Mobile
Station Identification
type (IMSI, ESN, both)
• Dynamic Handoff
Thresholds, if used
• Packet Zone
parameters, if used
• Access handoff
parameters, if used
• QPCH details, if used
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 32
Configuration Messages:
Variations of the Neighbor List Message
QcpCdmaLogMsgPagingChan
04/03/2002 22:17:52
MSG_LENGTH: 24 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Neighbor List Message
PILOT_PN: 44
CONFIG_MSG_SEQ: 47
PILOT_INC: 4
NGHBR_CONFIG: 0 NGHBR_PN: 216
NGHBR_CONFIG: 0 NGHBR_PN: 384
NGHBR_CONFIG: 0 NGHBR_PN: 304
NGHBR_CONFIG: 0 NGHBR_PN: 472
NGHBR_CONFIG: 0 NGHBR_PN: 368
NGHBR_CONFIG: 0 NGHBR_PN: 224
NGHBR_CONFIG: 0 NGHBR_PN: 324
NGHBR_CONFIG: 0 NGHBR_PN: 492
NGHBR_CONFIG: 0 NGHBR_PN: 152
NGHBR_CONFIG: 0 NGHBR_PN: 24
RESERVED: 0
August, 2013
QcpCdmaLogMsgPagingChan
04/16/2003 19:08:07
MSG_LENGTH: 42 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Extended Neighbor List Message
PILOT_PN: 213
CONFIG_MSG_SEQ: 10
PILOT_INC: 3
NGHBR_CONFIG: 0 NGHBR_PN: 45 SEARCH_PRIORITY: Very High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 381 SEARCH_PRIORITY: Very High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 300 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 198 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 363 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 195 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 27 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 177 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 219 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 207 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 375 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 237 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 21 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 357 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 189 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 210 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 378 SEARCH_PRIORITY: High FREQ_INCL: No
NGHBR_CONFIG: 0 NGHBR_PN: 42 SEARCH_PRIORITY: High FREQ_INCL: No
RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 33
Configuration Messages:
More Variations of the Neighbor List Message
QcpCdmaLogMsgPagingChan
04/03/2002 22:43:16
MSG_LENGTH: 33 octets PD: P_REV_IN_USE < 6
MSG_TYPE: General Neighbor List Message
PILOT_PN: 380 CONFIG_MSG_SEQ: 8 PILOT_INC: 4
NGHBR_SRCH_MODE: Search Priorities
NGHBR_CONFIG_PN_INCL: Yes
FREQ_FIELDS_INCL: No USE_TIMING: No
NUM_NGHBR: 12
NGHBR_CONFIG: 0 NGHBR_PN: 212 SEARCH_PRIORITY: Very High
NGHBR_CONFIG: 0 NGHBR_PN: 40 SEARCH_PRIORITY: Very High
NGHBR_CONFIG: 0 NGHBR_PN: 504 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 428 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 32 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 372 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 132 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 448 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 12 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 352 SEARCH_PRIORITY: High
NGHBR_CONFIG: 0 NGHBR_PN: 260 SEARCH_PRIORITY: Medium
NGHBR_CONFIG: 0 NGHBR_PN: 184 SEARCH_PRIORITY: Medium
NUM_ANALOG_NGHBR: 0 SRCH_OFFSET_INCL: No
ADD_PILOT_REC_INCL: No, No, No, No, No, No, No, No, No, No, No, No
SRCH_OFFSET_NGHBR: 0 BCCH_IND_INCL: No
RESQ_ENABLED: No RESQ_DELAY_TIME: 0
RESQ_ALLOWED_TIME: 0 RESQ_ATTEMPT_TIME: 0
RESQ_CODE_CHAN: 0 RESQ_QOF: 0
RESQ_MIN_PERIOD_INCL: No RESQ_MIN_PERIOD: 0
RESQ_NUM_TOT_TRANS_INCL: 0 RESQ_NUM_TOT_TRANS_20MS: 0
RESQ_NUM_TOT_TRANS_5MS: 0 RESQ_NUM_PREAMBLE_RC1_RC2: 0
RESQ_NUM_PREAMBLE: 0 RESQ_POWER_DELTA: 0
NGHBR_RESQ_CONFIGURED: No, No, No, No, No, No, No, No, No, No, No, No
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 34
Configuration Messages:
CDMA Channel List Message
QcpCdmaLogMsgPagingChan
04/03/2002 22:17:52
MSG_LENGTH: 11 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: CDMA Channel List Message
PILOT_PN: 44
CONFIG_MSG_SEQ: 47
CDMA_FREQ: 384
CDMA_FREQ: 425
RESERVED: 0
QcpCdmaLogMsgPagingChan
04/03/2002 22:17:52
MSG_LENGTH: 10 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Extended CDMA Channel List Message
PILOT_PN: 44
CONFIG_MSG_SEQ: 47
NUM_FREQ: 1
CDMA_FREQ: 384
RC_QPCH_SEL_INCL: No
TD_SEL_INCL: No
RESERVED: 0
 The CDMA Channel List message lists all carrier frequencies equipped on
the current sector for use by IS-95 mobiles
 The Extended Channel List message lists all carrier frequencies equipped
on the current sector for use by 1xRTT mobiles
 After receiving the appropriate message, a IS-95 or 1xRTT mobile
immediately uses the hashing formula to determine its appropriate
frequency from the list. The mobile immediately starts listening to the
paging channel on that carrier.
 This set of messages provides a simple way to evenly distribute idle
mobiles among the available carriers for traffic balancing reasons
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 35
How Hashing Works
 If a mobile sees a CDMA Channel List Message, it notices the list
of channels included in the message
• There may be one, two, three, or more channels listed
 Whenever a phone encounters multiple announced resources, it
uses its number (IMSI, International Mobile Subscriber Identity)
and a randomized process called “hashing” to determine which
resource it should use. This is how mobiles select:
• Carrier Frequencies in idle mode
• Preferred Paging Channel
• Preferred Access Channel
• Paging Time Slot in Slotted Mode
 Optimization personnel may wish to carry a phone for each carrier
frequency, or use the multiple NAM capability of some handsets to
operate on different numbers so as to prefer different frequencies
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 36
Hashing Examples
 Try your own phone in the spreadsheet Hashing.xls (in utilities folder)
Hashing Examples
Time between active slots, seconds:
1.28
2.56 5.12 10.24
20.48
Number of Slots in Mobile's Cycle:
16
32
64
128
256
v2. 1-28-2000
How Many
Key in red-shaded Frequencies?
values
2
40.96
81.92
163.84
512
1024
2048
How Many Paging
Channels?
Slot Cycle Index:
1
10 Digit IMSI
Use Freq. #
Use PCH #
0
Slot#
6153000124
6153000125
6153000126
6153000127
6153000128
6153000129
6153000130
6153000131
6153000132
6153000133
1
1
15
31
63
127
127
383
895
895
1
1
11
27
27
27
27
27
539
1563
1
1
5
5
5
69
69
69
69
69
1
1
3
3
3
67
195
451
451
1475
2
1
8
24
24
24
152
152
152
1176
2
1
9
25
25
25
25
25
25
25
1
1
11
27
27
27
27
27
539
1563
2
1
1
1
33
97
225
225
737
737
1
1
8
8
40
40
40
40
552
552
1
1
3
19
51
115
243
243
755
755
August, 2013
1
2
Slot# Slot#
3
Slot#
4
Slot#
5
Slot#
6
Slot#
7
Slot#
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 37
Configuration Messages:
Global Service Redirection Message
QcpCdmaLogMsgPagingChan
01/05/2005 19:20:09
MSG_LENGTH: 15 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Global Service Redirection Message
PILOT_PN: 6 CONFIG_MSG_SEQ: 35
REDIRECT_ACCOLC (ACCOLC_0): Yes
REDIRECT_ACCOLC (ACCOLC_1): Yes
REDIRECT_ACCOLC (ACCOLC_2): Yes
REDIRECT_ACCOLC (ACCOLC_3): Yes
REDIRECT_ACCOLC (ACCOLC_4): Yes
REDIRECT_ACCOLC (ACCOLC_5): Yes
REDIRECT_ACCOLC (ACCOLC_6): Yes
REDIRECT_ACCOLC (ACCOLC_7): Yes
REDIRECT_ACCOLC (ACCOLC_8): Yes
REDIRECT_ACCOLC (ACCOLC_9): Yes
REDIRECT_ACCOLC (ACCOLC_10): No
REDIRECT_ACCOLC (ACCOLC_11): No
REDIRECT_ACCOLC (ACCOLC_12): No
REDIRECT_ACCOLC (ACCOLC_13): No
REDIRECT_ACCOLC (ACCOLC_14): No
REDIRECT_ACCOLC (ACCOLC_15): No
RETURN_IF_FAIL: No DELETE_TMSI: No
EXCL_P_REV_MS: No
RECORD_TYPE: Redirection to An Analog System
RECORD_LEN: 3 octets
EXPECTED_SID: 0 IGNORE_CDMA: No
SYS_ORDERING: Attempt To Obtain Service On Either System
A Or System B. If Unsuccessful, Attempt Alternate System
MAX_REDIRECT_DELAY: 0 sec
August, 2013
 The Global Service Redirection
Message (GSRM) sends mobiles
to a different channel or system
• There are many configuration
options for the destination,
even including a return-if-fail
option if desired
• The message only applies to
mobiles whose overload
classes (ACCOLC) are flagged
“yes” in the message
– customer mobiles’
ACCOLC are set equal to
the last digit of the mobile
number
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 38
Summary: How Idle Mobiles Choose CDMA Carriers
 At turnon, Idle mobiles use proprietary System Determination Algorithms
(SDA) to find the initial CDMA carrier intended for them to use
 On the paging channel of the idle mobile’s newly-found home signal, the
mobile might be sent to a different frequency if it hears
• CDMA Channel List Message
• Global Service Redirection Message (GSRM)
Start
System Determination Algorithm
Preferred
Only Bit
MRU
0
PRL
Acq Idx
Yes
Go to last
Strongest
frequency
PN, read
from MRU
Sync
No Signal
Is SID
permitted?
Denied SID
Is better
SID
available?
No
Read
Paging
Channel
Last Resort:
GEO escape
Or Analog
Idle Mode Carrier Selection
CDMA Ch List
Message
HASH using
IMSI
Global Svc
Redir Msg
my ACCOLC?
redirect
F3
F2
F1
Config
Messages:
remain
to another CDMA frequency or system
Legend
Steps from
the CDMA
standards
August, 2013
Steps from
proprietary
SDAs
Proprietary
SDA
databases
RF200 v8.0 (c) 2013 Scott Baxter
to Analog
RF200 - 39
Idle Mode Handoff
(“Reselection” by the Mobile)
 An idle mobile always uses the best available signal
• In idle mode, it isn’t possible to do soft handoff and listen to
multiple sectors or base stations at the same time -- the paging
channel information stream is different on each sector
• Since a mobile can’t combine sectors, the mobile can only try
to stay on top of the strongest one
 The mobile’s pilot searcher is constantly checking neighbor pilots
 A Mobile might change pilots for either of two reasons:
• It notices another pilot at least 3 db stronger than the current
active pilot, and it stays this good continuously for at least five
seconds: mobile switches at end of the next superframe
• If the mobile loses the current paging channel, and another
pilot exists better than the old active sector, it is immediately
promoted to active
 On the new paging channel, if the mobile notices a different SID,
NID, or other reason for registration, it re-registers
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 40
Ec/Io
Idle Mode on the Paging Channel:
Meet the Neighbors, track the Strongest Pilot
All PN Offsets
0
-20
SRCH_WIN_A
Chips 0
PN 0
Mobile Rake RX
F1 PN168 W01
Active Pilot
Rake Fingers
SRCH_WIN_N
Reference PN



32K
512
F2 PN168 W01
F3 PN168 W01
Srch PN??? W0
The phone’s pilot searcher constantly checks
the pilots listed in the Neighbor List Message
Neighbor Set
If the searcher ever notices a neighbor pilot 3 db stronger than
the current reference pilot, after 5 seconds the mobile makes it the new reference
pilot and the phone switches over to its paging channel on the next superframe.
This is called an idle mode handoff.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 41
Improved Reliability for the Access Process
 In original IS-95 CDMA, a when receiving or making a call a mobile chose
the strongest sector available. During all the following steps of call setup,
it was “stuck” on this sector -- even if another sector suddenly became
stronger and started interfering.
 Beginning in IS-95B, and continuing in IS-2000, there are new “tricks” the
mobile and system can use in cooperation to allow the mobile to “roll with
the punches” and shift among sectors during the critical few moments
during call setup
 ACCESS ENTRY HANDOFF
• mobile can switch sectors after receiving a page but before sending its
first probe in response
 ACCESS HANDOFF
• mobile can switch sectors after successful access while waiting for
traffic channel assignment
 Channel Assignment into Soft Handoff (Lucent “CAMSHO”)
• the system can set up the mobile’s initial traffic channel assignment
on multiple sectors, allowing the call to begin already in soft handoff
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 42
The Access Handoff List
 ACCESS_HO_LIST is the key to all the techniques of handoff in
access mode
 An idle mobile builds and constantly updates its own internal
ACCESS_HO_LIST, consisting only of:
• neighbor pilots shown as “access handoff enabled” in the
neighbor list, only if stronger than T_Add
• the current active pilot
 The mobile sends its ACCESS_HO_LIST to the system
• in any page response message
• in any origination message
• it can be included in other access channel messages if the
system requests it (system declares “Pilot Reporting = 1”)
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 43
Access Handoff, Access Entry Handoff
 In this Origination Message,
a mobile is asking for Access
Handoff with two sectors:
• its current Active sector
• PN189
 Access Attempted: NO
means it has not sent a
probe yet to PN189
 If the current active fades
before the mobile hears a
response or during the
remainder of its probing, the
mobile will listen to the
paging channel on PN189
instead
 If Channel Assignment into
Soft Handoff is enabled, an
Extended Channel
Assignment Message will
assign traffic channels on
both the current active PN
and PN189
August, 2013
QcpCdmaLogMsgAccessChan 04/16/2003 19:06:56
MSG_LENGTH: 42 octets D: P_REV_IN_USE >= 6
MSG_ID: Origination Message LAC_LENGTH: 13 octets
ACK_SEQ: 7 MSG_SEQ: 5 ACK_REQ: 1
VALID_ACK: 0 ACK_TYPE: 0
MSID_TYPE: IMSI and ESN MSID_LEN: 9 octets
ESN: D:06916245430 H:45F7E2B6
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included
RESERVED: 0 IMSI_S: 6015737284
AUTH_MODE: 0 LAC_PADDING: 0
ACTIVE_PILOT_STRENGTH: -9.00 dB
FIRST_IS_ACTIVE: Yes FIRST_IS_PTA: No NUM_ADD_PILOTS: 1
PILOT_PN_PHASE: PN:189 + 0 chips
PILOT_STRENGTH: -12.50 dB ACCESS_HO_EN: Yes
ACCESS_ATTEMPTED: No MOB_TERM: Yes
SLOT_CYCLE_INDEX: 5.12 MOB_P_REV: IS-2000 Revision 0
SCM: Band Class 1, Dual Mode, Slotted, Continuous, Class III
REQUEST_MODE: CDMA Only SPECIAL_SERVICE: Yes
SERVICE_OPTION: Standard: EVRC (8 kbps) PM: No
DIGIT_MODE: 4-bit DTMF Codes MORE_FIELDS: No
NUM_FIELDS: 10 CHARi: 6 6 2 3 2 8 9 0 3 9 NAR_AN_CAP: No
PACA_REORIG: User Directed Origination RETURN_CAUSE: Normal Access
MORE_RECORDS: No PACA_SUPPORTED: No
NUM_ALT_SO: 0 DRS: No UZID_INCL: No
CH_IND: Fundamental Channel SR_ID: 1
OTD_SUPPORTED: No QPCH_SUPPORTED: Yes
ENHANCED_RC: Yes FOR_RC_PREF: 3 REV_RC_PREF: 3
FCH_SUPPORTED: Yes FCH_FRAME_SIZE: Supports only 20 ms Frame Sizes
FOR_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: Yes RC6: No
REV_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: No RC6: No
DCCH_SUPPORTED: No GEO_LOC_INCL: No REV_FCH_GATING_REQ: Yes
RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 44
Course RF200
Let’s Register!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 45
Registration
 Registration is the process by which an idle mobile lets the system
know it’s awake and available for incoming calls
• this allows the system to inform the mobile’s home switch of
the mobile’s current location, so that incoming calls can be
delivered
• registration also allows the system to intelligently page the
mobile only in the area where the mobile is currently located,
thereby eliminating useless congestion on the paging channels
in other areas of the system
 There are many different conditions that could trigger an obligation
for the mobile to register
• there are flags in the System Parameters Message which tell
the mobile when it must register on the current system
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 46
Mobile Registration Messaging
SYNC CHANNEL
SYNC CHANNEL MESSAGE
PAGING CHANNEL
SYSTEM PARAMETERS
MESSAGE
ACCESS PARAMETERS
MESSAGE
NEIGHBOR LIST
MESSAGE
EXTENDED SYSTEM
PARAMETERS MSG
CDMA CHANNEL LIST
MESSAGE
ACCESS CHANNEL
GLOBAL SERVICE
REDIRECTION MSG
REGISTRATION
MESSAGE
PROBE INFORMATION
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 47
Mobile Registration
 The Registration Message
is sent in the form of one
or more probes on the
Access Channel
 Most test equipment used
for monitoring the layer-3
messages also displays
Access Probe Information,
confirming each individual
probe when it is
transmitted
• The access probe
information is not sent
over the air, it is just a
report that the mobile
did in fact send a
probe
August, 2013
QcpCdmaLogMsgAccessChan
09/22/2004 14:03:08
MSG_LENGTH: 21 octets
PD: P_REV_IN_USE < 6
MSG_ID: Registration Message
ACK_SEQ: 7 MSG_SEQ: 7 ACK_REQ: 1
VALID_ACK: 0 ACK_TYPE: 2
MSID_TYPE: IMSI and ESN
MSID_LEN: 9 octets
ESN: D:25411321874 H:FEACC212
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included
RESERVED: 0 IMSI_S: 8436840009
AUTH_MODE: 0
REG_TYPE: Zone-Based
SLOT_CYCLE_INDEX: 2.56
MOB_P_REV: J-STD-008
EXT_SCM: Band Class 1 RESERVED: 0
SLOTTED_MODE: Yes RESERVED: 0
MOB_TERM: Yes RESERVED: 0
Access Probe Info 09/22/2004 14:03:08
Access Probe Sequence Number: 1 Access Probe Number: 1
Access Channel Number: 0 PN Randomization delay: 10
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 1
Rx Power: -81.248 Tx Power (Est): 8.248 Tx Gain Adjust: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 48
Feature Notification:
You Have Voicemail!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 49
Voicemail Notification Messaging
PAGING CHANNEL
ACCESS CHANNEL
FEATURE NOTIFICATION
MESSAGE (MSG WTG)
MOBILE STATION
ACK. ORDER
PROBE INFORMATION
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 50
Feature Notification
QcpCdmaLogMsgPagingChan
04/03/2002 22:44:05
MSG_LENGTH: 16 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Feature Notification Message
ACK_SEQ: 2 MSG_SEQ: 7 ACK_REQ: Yes
VALID_ACK: Yes
ADDR_TYPE: IMSI
ADDR_LEN: 5 octets
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included
RESERVED: 0
IMSI_S: 9145899573
RELEASE: No
RECORD_TYPE: Message Waiting
RECORD_LEN: 1 octet
MSG_COUNT: 1 RESERVED: 0
The mobile confirms it has received the
notification by sending a Mobile Station
Acknowledgment Order on the access
channel.
Test equipment connected to the mobile
may show the Access Probe Info, confirming
that a probe was actually sent.
August, 2013
The Feature Notification Message on
the Paging Channel tells a specific
mobile it has voice messages waiting.
There are other record types to notify
the mobile of other features.
QcpCdmaLogMsgRevTrafChan 04/03/2002 22:44:05
MSG_LENGTH: 7 octets MSG_TYPE: Order Message
ACK_SEQ: 7 MSG_SEQ: 4 ACK_REQ: No
ENCRYPTION: Encryption Disabled
MSID_TYPE: IMSI and ESN MSID_LEN: 9 octets
ESN: D:11600081479 H:74013E47
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included
RESERVED: 0 IMSI_S: 9145899573
ORDER: Mobile Station Acknowledgement Order
ADD_RECORD_LEN: 0 octet RESERVED: 0
Access Probe Info Time Stamp: 04/03/2002 22:44:05
Access Probe Sequence Number: 1 Access Probe Number: 1
Access Channel Number: 0 PN Randomization delay: 10
Sequence Backoff: 0 Probe Backoff: 0
Persistence Tests Performed: 0
Rx Power: -70.9147 Tx Power (Est): -3.08533 Tx Gain Adjust: 2
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 51
Example 4
Let’s Receive an Incoming
Call!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 52
Receiving an Incoming Call
 All idle mobiles monitor the paging channel to receive incoming
calls.
 When an incoming call appears, the paging channel notifies the
mobile in a General Page Message.
 A mobile which has been paged sends a Page Response
Message on the access channel.
 The system sets up a traffic channel for the call, then notifies the
mobile to use it with a Channel Assignment Message.
 The mobile and the base station notice each other’s traffic channel
signals and confirm their presence by exchanging
acknowledgment messages.
 The base station and the mobile negotiate what type of call this will
be -- I.e., 13k voice, etc.
 The mobile is told to ring and given a “calling line ID” to display.
 When the human user presses the send button, the audio path is
completed and the call proceeds.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 53
Mobile Termination Messaging
PAGING CHANNEL
ACCESS CHANNEL
GENERAL PAGE
MESSAGE
PAGE RESPONSE MESSAGE
PROBE INFORMATION
BASE STATION
ACK. ORDER
CHANNEL ASSIGNMENT
MESSAGE
FORWARD TRAFFIC CHANNEL
REVERSE TRAFFIC CHANNEL
LAYER 2 HANDSHAKE
LAYER 2 HANDSHAKE
BASE STATION
ACK. ORDER
SERVICE CONNECT
MESSAGE
ALERT WITH INFORMATION
MESSAGE
BASE STATION
ACK. ORDER
August, 2013
MOBILE STATION
ACK. ORDER
SERVICE CONNECT
COMPLETE MESSAGE
MOBILE STATION
ACK ORDER
CONNECT
MESSAGE
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 54
Call Termination Messaging (1)
QcpCdmaLogMsgPagingChan
09/22/2004 13:33:56
MSG_LENGTH: 16 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: General Page Message
CONFIG_MSG_SEQ: 2
ACC_MSG_SEQ: 1
CLASS_0_DONE: Yes
CLASS_1_DONE: Yes
TMSI_DONE: No
ORDERED_TMSIS: No
BROADCAST_DONE: Yes
RESERVED: 0
ADD_LENGTH: 0 octets
PAGE_CLASS: Page With Class 0 IMSI
PAGE_SUBCLASS: 0
MSG_SEQ: 1
IMSI_S: 8436840009
SPECIAL_SERVICE: Yes
SERVICE_OPTION: QUALCOMM: Voice 13K
QcpCdmaLogMsgAccessChan 09/22/2004 13:33:56
MSG_LENGTH: 23 octets PD: P_REV_IN_USE < 6
MSG_ID: Page Response Message
ACK_SEQ: 1 MSG_SEQ: 1 ACK_REQ: 1 VALID_ACK: 1 ACK_TYPE: 2
MSID_TYPE: IMSI and ESN MSID_LEN: 9 octets
ESN: D:25411321874 H:FEACC212
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included RESERVED: 0
IMSI_S: 8436840009
AUTH_MODE: 0 MOB_TERM: Yes
SLOT_CYCLE_INDEX: 2.56
MOB_P_REV: J-STD-008
EXT_SCM: Band Class 1 RESERVED: 0
SLOTTED_MODE: Yes RESERVED: 0
REQUEST_MODE: Either Wide Analog or CDMA Only
SERVICE_OPTION: QUALCOMM: Voice 13K
PM: No NAR_AN_CAP: No RESERVED: 0
Access Probe Info Time Stamp: 9/22/2004 13:33:56.000
Access Probe Sequence Number: 1 Access Probe Number: 1
Access Channel Number: 0 PN Randomization delay: 10
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 0
Rx Power: -70.9147 Tx Power (Est): -3.08533 Tx Gain Adjust: 2
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 55
Call Termination Messaging (2)
QcpCdmaLogMsgPagingChan 09/22/2004 13:33:57
MSG_LENGTH: 13 octets PD: P_REV_IN_USE < 6
MSG_TYPE: Order Message
ACK_SEQ: 1 MSG_SEQ: 0 ACK_REQ: No
VALID_ACK: Yes ADDR_TYPE: ESN ADDR_LEN: 4 octets
ESN: D:25411321874 H:FEACC212
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets
QcpCdmaLogMsgPagingChan 09/22/2004 13:33:57
MSG_LENGTH: 18 octets PD: P_REV_IN_USE < 6
MSG_TYPE: Channel Assignment Message
ACK_SEQ: 1 MSG_SEQ: 1 ACK_REQ: No
VALID_ACK: Yes ADDR_TYPE: ESN ADDR_LEN: 4 octets
ESN: D:25411321874 H:FEACC212
ASSIGN_MODE: Extended Traffic Channel Assignment
ADD_RECORD_LEN: 5 octets FREQ_INCL: Yes RESERVED: 0
BYPASS_ALERT_ANSWER: No
DEFAULT_CONFIG: Multiplex Option 1
and Radio Config 1 For Both FTC and RTC
GRANTED_MODE: MS use Service Configuration of
default Multiplex Option and Transmission Rates
CODE_CHAN: 36 FRAME_OFFSET: 12.50 ms
ENCRYPT_MODE: Encryption Disabled
BAND_CLASS: 1.850 to 1.990 GHz Band
CDMA_FREQ: 1175 C_SIG_ENCRYPT_MODE_INCL: No
RESERVED: 0
August, 2013
 The Base Station
Acknowledgment Order tells
the mobile to stop sending
probes
 The Channel Assignment
Message tells the mobile the
walsh code and other details
of its traffic channel
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 56
Call Termination Messaging (3)
The mobile sees at least two
good blank frames in a row on
the forward channel, and
concludes this is the right traffic
channel. It sends a preamble
of two blank frames of its own
on the reverse traffic channel.
The base station is already
sending blank frames on
the forward channel,using
the assigned Walsh code.
QcpCdmaLogMsgForTrafChan
09/22/2004 13:33:57
MSG_LENGTH: 8 octets
MSG_TYPE: Order Message
ACK_SEQ: 7 MSG_SEQ: 0 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
USE_TIME: No ACTION_TIME: 0 ms
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
The base station acknowledges
receiving the mobile’s preamble.
The mobile station acknowledges receiving the
Base Station’s message. This is usually done
in a Mobile Station Acknowledgment Order,
but if the mobile has some other message it
needs to send, the acknowledgment can be
taken care of in the ACK_SEQ field in it.
August, 2013
QcpCdmaLogMsgRevTrafChan
09/22/2004 13:33:57
MSG_LENGTH: 10 octets
MSG_TYPE: Pilot Strength Measurement Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
REF_PN: 8 PILOT_STRENGTH: -9.00 dB KEEP: Yes
PILOT_PN_PHASE: PN:0 + 0 chips
PILOT_STRENGTH: -8.00 dB KEEP: Yes
RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 57
Call Termination Messaging (4)
QcpCdmaLogMsgForTrafChan
09/22/2004 13:33:57
MSG_LENGTH: 21 octets
MSG_TYPE: Service Connect Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: No
ENCRYPTION: Encryption Disabled
USE_TIME: No ACTION_TIME: 0 ms
SERV_CON_SEQ: 0 RESERVED: 0
RECORD_TYPE: Service Configuration
RECORD_LEN: 12 octets
FOR_MUX_OPTION: 2 REV_MUX_OPTION: 2
RS2_14400_FOR: Supports 276 bits per F-FCH frame
RS2_7200_FOR: Supports 125 bits per F-FCH frame
RS2_3600_FOR: Supports 55 bits per F-FCH frame
RS2_1800_FOR: Supports 21 bits per F-FCH frame
RESERVED: 0
RS2_14400_REV: Supports 276 bits per R-FCH frame
RS2_7200_REV: Supports 125 bits per R-FCH frame
RS2_3600_REV: Supports 55 bits per R-FCH frame
RS2_1800_REV: Supports 21 bits per R-FCH frame
RESERVED: 0 NUM_CON_REC: 1
RECORD_LEN: 5 octets CON_REF: 1
SERVICE_OPTION: QUALCOMM: Voice 13K
FOR_TRAFFIC: SO Uses Primary Traffic On FTC
REV_TRAFFIC: SO Uses Primary Traffic On RTC
 The mobile can accept by
sending a Service Connect
Complete Message, or propose
something different with a
Service Response Message
August, 2013
 The Service Connect Message
is the system’s proposal to the
mobile specifying the technical
details of the call:
• Radio Configuration
• Multiplex options
• Service Option, Vocoder
type
• Traffic type to be carried
QcpCdmaLogMsgRevTrafChan
09/22/2004 13:33:57
MSG_LENGTH: 6 octets
MSG_TYPE: Service Connect Completion Message
ACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
RESERVED: 0 SERV_CON_SEQ: 0 RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 58
Call Termination Messaging (5)
QcpCdmaLogMsgForTrafChan
09/22/2004 13:33:57
MSG_LENGTH: 10 octets
MSG_TYPE: Alert With Information Message
ACK_SEQ: 1 MSG_SEQ: 2 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
RECORD_TYPE: Signal
RECORD_LEN: 2 octets
SIGNAL_TYPE: IS-54B Alerting
ALERT_PITCH: Medium Pitch SIGNAL: Long
RESERVED: 0 RESERVED: 0
 The Alert With Information
Message tells the mobile to
start ringing, and optionally to
display a calling-party number
on its screen
 The mobile acknowledges the
Alert With Information Message,
indicating it is now ringing
August, 2013
QcpCdmaLogMsgRevTrafChan
09/22/2004 13:33:58
MSG_LENGTH: 7 octets
MSG_TYPE: Order Message
ACK_SEQ: 2 MSG_SEQ: 2 ACK_REQ: No
ENCRYPTION: Encryption Disabled
ORDER: Mobile Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 59
Call Termination Messaging (6)
 When the mobile user presses
SEND or opens their
mouthpiece, the phone sends a
Connect Order and the switch
connects the trunks for audio
QcpCdmaLogMsgForTrafChan
09/22/2004 13:33:58
MSG_LENGTH: 8 octets
MSG_TYPE: Order Message
ACK_SEQ: 3 MSG_SEQ: 5 ACK_REQ: No
ENCRYPTION: Encryption Disabled
USE_TIME: No ACTION_TIME: 0 ms
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets
RESERVED: 0
QcpCdmaLogMsgRevTrafChan
09/22/2004 13:33:58
MSG_LENGTH: 7 octets
MSG_TYPE: Order Message
ACK_SEQ: 3 MSG_SEQ: 3 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
ORDER: Connect Order
ADD_RECORD_LEN: 0 octets
RESERVED: 0
Now the switch completes the audio circuit and
the two callers can talk!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 60
Course RF200
Let’s Make An Outgoing Call!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 61
Placing an Outgoing Call
 The mobile user dials the desired digits, and presses SEND.
 Mobile transmits an Origination Message on the access channel.
 The system acknowledges receiving the origination by sending a base
station acknowledgement on the paging channel.
 The system arranges the resources for the call and starts transmitting on
the traffic channel.
 The system notifies the mobile in a Channel Assignment Message on the
paging channel.
 The mobile arrives on the traffic channel.
 The mobile and the base station notice each other’s traffic channel signals
and confirm their presence by exchanging acknowledgment messages.
 The base station and the mobile negotiate what type of call this will be -I.e., 13k voice, etc.
 The audio circuit is completed and the mobile caller hears ringing.
 Supplemental channels can be requested for data bursts as needed
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 62
Call Origination Messaging
PAGING CHANNEL
ACCESS CHANNEL
ORIGINATION MESSAGE
BASE STATION
ACK. ORDER
PROBE INFORMATION
CHANNEL ASSIGNMENT
MESSAGE
FORWARD TRAFFIC CHANNEL
REVERSE TRAFFIC CHANNEL
LAYER 2 HANDSHAKE
LAYER 2 HANDSHAKE
BASE STATION
ACK. ORDER
SERVICE CONNECT
MESSAGE
August, 2013
MOBILE STATION
ACK. ORDER
SERVICE CONNECT
COMPLETE MESSAGE
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 63
Call Origination Messaging (1)
 An Origination
message contains all
details needed for
setup of a call
• mobile identity
and technical
capabilities
• destination
number and type
of call requested
• Access Handoff
information, if
involved
 Most message
capture test
equipment also
displays the mobile’s
internally-generated
“Access Probe Info”,
showing technical
details of each probe
August, 2013
QcpCdmaLogMsgAccessChan 04/03/2002 22:43:16
MSG_LENGTH: 43 octets PD: P_REV_IN_USE >= 6
MSG_ID: Origination Message LAC_LENGTH: 17 octets
ACK_SEQ: 7 MSG_SEQ: 5 ACK_REQ: 1 VALID_ACK: 0 ACK_TYPE: 0
MSID_TYPE: IMSI and ESN MSID_LEN: 9 octets ESN: D:11600081479 H:74013E47
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included
RESERVED: 0 IMSI_S: 4349419020
AUTH_MODE: 1 AUTHU: 195061 RANDC: 122 COUNT: 0
LAC_PADDING: 0 ACTIVE_PILOT_STRENGTH: -4.00 dB
FIRST_IS_ACTIVE: Yes FIRST_IS_PTA: No NUM_ADD_PILOTS: 0
MOB_TERM: Yes SLOT_CYCLE_INDEX: 2.56 MOB_P_REV: IS-2000 Revision 0
SCM: Band Class 0, Dual Mode, Slotted, Continuous, Class III
REQUEST_MODE: CDMA Only SPECIAL_SERVICE: Yes
SERVICE_OPTION: Standard: EVRC (8 kbps) PM: Yes DIGIT_MODE: 4-bit DTMF Codes
MORE_FIELDS: No NUM_FIELDS: 10 CHARi: 4 3 4 3 8 6 5 2 9 7
NAR_AN_CAP: No PACA_REORIG: User Directed Origination
RETURN_CAUSE: Normal Access MORE_RECORDS: No
ENCRYPTION_SUPPORTED: Basic Encryption Supported PACA_SUPPORTED: No
NUM_ALT_SO: 0 DRS: No UZID_INCL: No CH_IND: Fundamental Channel SR_ID: 1
OTD_SUPPORTED: No QPCH_SUPPORTED: Yes
ENHANCED_RC: Yes FOR_RC_PREF: 3 REV_RC_PREF: 3
FCH_SUPPORTED: Yes FCH_FRAME_SIZE: only 20 ms Frame Sizes
FOR_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: Yes RC6: No
REV_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: No RC6: No
DCCH_SUPPORTED: No GEO_LOC_INCL: Yes
GEO_LOC_TYPE: Reserved REV_FCH_GATING_REQ: No
Access Probe Info 4/3/2002 22:43:16.000
Access Probe Sequence Number: 1 Access Probe Number: 1
Access Channel Number: 0 PN Randomization delay: 10
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 1
Rx Power: -81.248 Tx Power (Est): 8.248 Tx Gain Adjust: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 64
Call Origination Messaging (2)
QcpCdmaLogMsgPagingChan
04/03/2002 22:43:16
MSG_LENGTH: 13 octets PD: P_REV_IN_USE < 6 MSG_TYPE: Order Message
ACK_SEQ: 5 MSG_SEQ: 0 ACK_REQ: No VALID_ACK: Yes ADDR_TYPE: ESN
ADDR_LEN: 4 octets ESN: D:11600081479 H:74013E47
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
QcpCdmaLogMsgPagingChan
04/03/2002 22:43:16
MSG_LENGTH: 29 octets PD: P_REV_IN_USE < 6
MSG_TYPE: Extended Channel Assignment Message
ACK_SEQ: 5 MSG_SEQ: 1 ACK_REQ: No VALID_ACK: Yes
ADDR_TYPE: ESN ADDR_LEN: 4 octets ESN: D:11600081479 H:74013E47
RESERVED_1: 0 ADD_RECORD_LEN: 15 octets
ASSIGN_MODE: Enhanced Traffic Channel Assignment
RESERVED_2: 0 FREQ_INCL: Yes
BAND_CLASS: 800 MHz Cellular Band CDMA_FREQ: 384
BYPASS_ALERT_ANSWER: No
GRANTED_MODE: MS use Service Configuration of default Multiplex Option and
Transmission Rates
DEFAULT_CONFIG: Reserved
FOR_RC: RC 3 REV_RC: RC 3 FRAME_OFFSET: 12.50 ms
ENCRYPT_MODE: Encryption Disabled
FPC_SUBCHAN_GAIN: 0.0 dB RLGAIN_ADJ: 0 dB NUM_PILOTS: 0 Pilots
CH_IND: Fundamental Channel CH_RECORD_LEN: 7 octets
FPC_FCH_INIT_SETPT: 7.000 dB
FPC_FCH_FER: 0.5% - 10% (in units of 0.5%)
FPC_FCH_MIN_SETPT: 3.000 dB FPC_FCH_MAX_SETPT: 8.000 dB
PILOT_PN: 380 ADD_PILOT_REC_INCL: No PWR_COMB_IND: No
CODE_CHAN_FCH: 33 QOF_MASK_ID_FCH: 0 3X_FCH_INFO_INCL: No
REV_FCH_GATING_MODE: No 3XFL_1XRL_INCL: No RESERVED: 0
August, 2013
 After receiving the
probe, the base station
transmits a Base Station
Acknowledgment order
on the Paging Channel
• this tells the mobile
not to transmit more
probes
 After the system sets up
the traffic channel for
the call, the Extended
Channel Assignment
Message gives the
mobile the channel
details
• Operating mode
• Band, Frequency
• Walsh Code
• Radio
Configurations
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 65
Call Origination Messaging (3)
The base station is already
sending blank frames on
the forward channel,using
the assigned Walsh code.
QcpCdmaLogMsgForTrafChan
04/03/2002 22:43:17
MSG_LENGTH: 8 octets
MSG_TYPE: Order Message
ACK_SEQ: 7
MSG_SEQ: 0
ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
USE_TIME: No
ACTION_TIME: 0 ms
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
The mobile station acknowledges the base
station’s acknowledgment. This is usually by
a Mobile Station Acknowledgment order, but
in this case, it is tucked into a PSMM the
mobile needs to send.
August, 2013
The mobile sees at least two
good blank frames in a row on
the forward channel, and
concludes this is the right traffic
channel. It sends a preamble
of two blank frames of its own
on the reverse traffic channel.
The base station acknowledges
receiving the mobile’s preamble.
QcpCdmaLogMsgRevTrafChan
04/03/2002 22:43:17
MSG_LENGTH: 10 octets
MSG_TYPE: Pilot Strength Measurement Message
ACK_SEQ: 0
MSG_SEQ: 0
ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
REF_PN: 380
PILOT_STRENGTH: -4.50 dB KEEP: Yes
PILOT_PN_PHASE: PN:212 + 0 chips
PILOT_STRENGTH: -13.50 dB KEEP: Yes
RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 66
Call Origination Messaging (4)
QcpCdmaLogMsgForTrafChan 04/03/2002 22:43:17 MSG_LENGTH: 31 octets
MSG_TYPE: Service Connect Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: No
ENCRYPTION: Encryption Disabled USE_TIME: No ACTION_TIME: 0 ms
SERV_CON_SEQ: 0 RESERVED: 0 USE_OLD_SERV_CONFIG: 0 SYNC_ID_INCL: No
RECORD_TYPE: Service Configuration RECORD_LEN: 15 octets
FOR_MUX_OPTION: 1 REV_MUX_OPTION: 1
RS1_9600_FOR: Supports 172 bits per F-FCH frame
RS1_4800_FOR: Supports 80 bits per F-FCH frame
RS1_2400_FOR: Supports 40 bits per F-FCH frame
RS1_1200_FOR: Supports 16 bits per F-FCH frame
RESERVED: 0
RS1_9600_REV: Supports 172 bits per R-FCH frame
RS1_4800_REV: Supports 80 bits per R-FCH frame
RS1_2400_REV: Supports 40 bits per R-FCH frame
RS1_1200_REV: Supports 16 bits per R-FCH frame
RESERVED: 0 NUM_CON_REC: 1 RECORD_LEN: 6 octets CON_REF: 1
 The Service Connect Message
is the system’s proposal for the
technical details of the call
including service option,
multiplexing, and type of traffic
SERVICE_OPTION: Standard: EVRC (8 kbps)
FOR_TRAFFIC: SO Uses Primary Traffic On FTC REV_TRAFFIC: SO Uses Primary Traffic On RTC
UI_ENCRYPT_MODE: User Information Encryption Disabled SR_ID: 1
RLP_INFO_INCL: No QOS_PARMS_INCL: No RESERVED: -- FCH_CC_INCL: Yes
FCH_FRAME_SIZE: Supports only 20 ms Frame Sizes
FOR_FCH_RC: RC 3 REV_FCH_RC: RC 3
DCCH_CC_INCL: No FOR_SCH_CC_INCL: No REV_SCH_CC_INCL: No RESERVED: 0
RECORD_TYPE: Non-Negotiable Service Configuration
RECORD_LEN: 5 octets FPC_INCL: Yes FPC_PRI_CHAN: No FPC_MODE: 0
FPC_OLPC_FCH_INCL: Yes FPC_FCH_FER: 0.5% - 10% (in units of 0.5%)
FPC_FCH_MIN_SETPT: 3.000 dB FPC_FCH_MAX_SETPT: 8.000 dB
FPC_OLPC_DCCH_INCL: No GATING_RATE_INCL: No FOR_SCH_INCL: No REV_SCH_INCL: No
LPM_IND: Use the default Logic-to-Physical Mapping NUM_REC: 0 USE_FLEX_NUM_BITS: No
USE_VAR_RATE: No LTU_INFO_INC: No USE_OLD_PARTITION_TABLE: No RESERVED: --
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 67
Call Origination Messaging (5)
 The Service Connect
Complete Message is the
mobile’s confirmation that it
accepts the mode of
operation the system has
proposed
000036, Time 22:43:17.131, Record 264, QcpCdmaLogMsgRevTrafChan
1/32 Chip Counter: 49248
1.25 msec Counter: 04/03/2002 22:43:17
MSG_LENGTH: 6 octets
MSG_TYPE: Service Connect Completion Message
ACK_SEQ: 0
MSG_SEQ: 1
ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
RESERVED: 0
SERV_CON_SEQ: 0
RESERVED: 0
The audio connection is now complete and the
user of this phone is listening to hear ringing
while waiting for the other party to answer.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 68
Access Failures
 In an access failure, the mobile never hears an acknowledgment of its
probes by the base station
 From the mobile side, it is not possible to know absolutely whether the
problem is the reverse link (base station not hearing mobile) or the
forward link (the mobile not hearing the base station’s acknowledgments)
• general RF indications may help – for example, if Ec/Io is poor, then
the forward link is stressed and may be the problem
• if mobile transmit power is near maximum during the probes, then the
problem may be on the reverse link (high reverse power at the base
station receiver due to heavy traffic, a rogue mobile, or a foreign
interferer)
 After the access failure, if the mobile reselects a different PN than it was
using during the probes, the newly discovered strong sector may have
been the interference source preventing reception earlier
• check to see if Access Entry Handoff and Access Handoff can be
enabled to avoid this type of problem
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 69
Access Failure Messaging
ACCESS CHANNEL
ORIGINATION MESSAGE
PROBE INFORMATION
ORIGINATION MESSAGE
PROBE INFORMATION
ORIGINATION MESSAGE
PROBE INFORMATION
ORIGINATION MESSAGE
PROBE INFORMATION
ORIGINATION MESSAGE
PROBE INFORMATION
ORIGINATION MESSAGE
PROBE INFORMATION
ORIGINATION MESSAGE
PROBE INFORMATION
ORIGINATION MESSAGE
PROBE INFORMATION
SYNC CHANNEL
SYNC CHANNEL MESSAGE
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 70
Access Failure Messaging (1)
01:40:12.273 QcpCdmaLogMsgPagingChan
MSG_LENGTH: 19 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Access Parameters Message
PILOT_PN: 4 ACC_MSG_SEQ: 0
ACC_CHAN: 1 Access Channel(s)
NOM_PWR: 0 dB
INIT_PWR: 0 dB
PWR_STEP: 3 dB
NUM_STEP: 4 Probe(s)
MAX_CAP_SZ: 5 ACH Frames
PAM_SZ: 4 ACH Frame(s)
PSIST(0-9): 0
PSIST(10): 0
PSIST(11): 0
PSIST(12): 0
PSIST(13): 0
PSIST(14): 0
PSIST(15): 0
MSG_PSIST: 1.00
REG_PSIST: 1.00
PROBE_PN_RAN: 0 PN chip(s)
ACC_TMO: 400 ms
PROBE_BKOFF: 1 Slot(s)
BKOFF: 2 Slot(s)
MAX_REQ_SEQ: 2
MAX_RSP_SEQ: 2
AUTH_MODE: 0
NOM_PWR_EXT: -8 to 7 dB inclusive
PSIST_EMG_INCL: No
RESERVED: 0
August, 2013
 This is a sequence of
messages leading up to an
access failure
 The mobile will follow the
access parameters given in
the message at left
• up to 4 access probes per
probe sequence
• up to 2 probe sequences
per access attempt
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 71
Access Failure Messaging (2)
 The mobile sends this origination
message, attempting to get
acknowledgment from the
system
 Each time this message is sent,
we will see a Probe Information
report from the mobile’s
processor confirming the time
that probe was sent, the power
level, and other details
August, 2013
01:40:12.455 QcpCdmaLogMsgAccessChan
MSG_LENGTH: 29 octets
PD: P_REV_IN_USE < 6
MSG_ID: Origination Message
ACK_SEQ: 7 MSG_SEQ: 6 ACK_REQ: 1
VALID_ACK: 0 ACK_TYPE: 0
MSID_TYPE: IMSI and ESN
MSID_LEN: 9 octets
ESN: D:00113967208 H:01D51F68
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included
RESERVED: 0 IMSI_S: 9723333534
AUTH_MODE: 0 MOB_TERM: Yes
SLOT_CYCLE_INDEX: 5.12 MOB_P_REV: J-STD-008
EXT_SCM: Band Class 1 RESERVED: 0
SLOTTED_MODE: Yes RESERVED: 0
REQUEST_MODE: CDMA Only SPECIAL_SERVICE: Yes
SERVICE_OPTION: QUALCOMM: Voice 13K PM: No
DIGIT_MODE: 4-bit DTMF Codes MORE_FIELDS: No
NUM_FIELDS: 10 CHARi: 5 0 2 2 0 7 0 2 9 9
NAR_AN_CAP: No RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 72
Access Failure Messaging (3)
 Here are the probe
reports for the first
probe sequence.
 No acknowledgment
was received from the
system
 Probing continues into
the second probe
sequence on the next
page
01:40:12.564 Access Probe Info
Access Probe Sequence Number: 1 Access Probe Number: 1
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 1
Rx Power: -63.248 Tx Power (Est): -12.752
01:40:13.442 Access Probe Info
Access Probe Sequence Number: 1 Access Probe Number: 2
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 1 Persistence Tests Performed: 0
Rx Power: -65.9147 Tx Power (Est): -7.08533 Tx Gain Adjust: 3
01:40:14.426 Access Probe Info
Access Probe Sequence Number: 1 Access Probe Number: 3
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 1 Persistence Tests Performed: 0
Rx Power: -69.5813 Tx Power (Est): -0.41867 Tx Gain Adjust: 6
01:40:15.269 Access Probe Info
Time Stamp: 8/8/2000 01:40:16.000 Access Probe Sequence Number: 1
Access Probe Number: 4 Access Channel Number: 0
PN Randomization delay: 0 Sequence Backoff: 0
Probe Backoff: 1 Persistence Tests Performed: 0
Rx Power: -69.5813 Tx Power (Est): 2.58133 Tx Gain Adjust: 9
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 73
Access Failure Messaging (4)
 The mobile continues with
the second probe
sequence (4 probes),
completing all the probes
allowed by the Access
Parameters Message
• it never hears an
acknowledgment from
the sector
 The mobile access
attempt failed, so it
restarts the system
acquisition process
01:40:15.981 Access Probe Info
Access Probe Sequence Number: 2 Access Probe Number: 1
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 1
Rx Power: -71.248 Tx Power (Est): -4.752 Tx Gain Adjust: 0
01:40:16.717 Access Probe Info
Access Probe Sequence Number: 2 Access Probe Number: 2
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 0
Rx Power: -66.248 Tx Power (Est): -6.752 Tx Gain Adjust: 3
01:40:17.580 Access Probe Info
Access Probe Sequence Number: 2 Access Probe Number: 3
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 1 Persistence Tests Performed: 0
Rx Power: -64.248 Tx Power (Est): -5.752 Tx Gain Adjust: 6
01:40:18.435 Access Probe Info
Access Probe Sequence Number: 2 Access Probe Number: 4
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 0
Rx Power: -60.248 Tx Power (Est): -6.752 Tx Gain Adjust: 9
01:40:19.500 QcpCdmaLogMsgSyncChan
MSG_LENGTH: 26 octets
MSG_TYPE: Sync Channel Message
P_REV: J-STD-008 MIN_P_REV: J-STD-008
SID: 4139 NID: 41 PILOT_PN: 116
LC_STATE: 0x02 B9 77 D6 59 D0
SYS_TIME: 08/14/2000 00:31:49
LP_SEC: 13 LTM_OFF: -660 minutes
DAYLT: No PRAT: 4800 bps CDMA_FREQ: 50
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 74
Setup Failures
 A setup failure is a failure to arrive successfully on a traffic
channel despite the base station hearing and acknowledging the
mobiles probes.
 The problem can occur in any of the steps after the base station
acknowledgment:
• the base station might not have resources for the call, causing
it to send a Reorder message (“Call Failed, Network Busy”)
• the base station may have set up the resources for the call, but
the mobile cannot hear the channel assignment message due
to forward link problems
• the mobile or the base station may fail to hear the other during
initialization of the traffic channel (this is called a Traffic
Channel Confirmation Failure ‘TCCF’ in Lucent systems)
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 75
Setup Failure Messaging
PAGING CHANNEL
ACCESS CHANNEL
ORIGINATION MESSAGE
BASE STATION
ACK. ORDER
CHANNEL ASSIGNMENT
MESSAGE
PROBE INFORMATION
ANY OF THE STRIPED STEPS
MAY NOT OCCUR,
STOPPING THE SETUP PROCESS
FORWARD TRAFFIC CHANNEL
REVERSE TRAFFIC CHANNEL
LAYER 2 HANDSHAKE
LAYER 2 HANDSHAKE
BASE STATION
ACK. ORDER
August, 2013
MOBILE STATION
ACK. ORDER
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 76
Setup Failure Messaging (1)
01:46:50.714 QcpCdmaLogMsgAccessChan
MSG_LENGTH: 29 octets PD: P_REV_IN_USE < 6
MSG_ID: Origination Message
ACK_SEQ: 7 MSG_SEQ: 5 ACK_REQ: 1 VALID_ACK: 0 ACK_TYPE: 0
MSID_TYPE: IMSI and ESN MSID_LEN: 9 octets
ESN: D:00113967208 H:01D51F68
IMSI_CLASS: 0 IMSI_CLASS_0_TYPE: IMSI_S included RESERVED: 0
IMSI_S: 9723333534 AUTH_MODE: 0 MOB_TERM: Yes
SLOT_CYCLE_INDEX: 5.12 MOB_P_REV: J-STD-008
EXT_SCM: Band Class 1 RESERVED: 0 SLOTTED_MODE: Yes
RESERVED: 0 REQUEST_MODE: CDMA Only SPECIAL_SERVICE: Yes
SERVICE_OPTION: QUALCOMM: Voice 13K PM: No
DIGIT_MODE: 4-bit DTMF Codes MORE_FIELDS: No NUM_FIELDS: 10
CHARi: 5 0 2 2 0 7 0 2 9 9 NAR_AN_CAP: No RESERVED: 0
01:46:50.980 Access Probe Info
Access Probe Sequence Number: 1 Access Probe Number: 1
Access Channel Number: 0 PN Randomization delay: 0
Sequence Backoff: 0 Probe Backoff: 0 Persistence Tests Performed: 1
Rx Power: -81.9147 Tx Power (Est): 5.91467 Tx Gain Adjust: 0
01:46:51.263 QcpCdmaLogMsgPagingChan
MSG_LENGTH: 16 octets
PD: P_REV_IN_USE < 6
MSG_TYPE: Order Message
ACK_SEQ: 5 MSG_SEQ: 0 ACK_REQ: No
VALID_ACK: Yes ADDR_TYPE: IMSI
ADDR_LEN: 7 octets IMSI_CLASS: 0
IMSI_CLASS_0_TYPE: IMSI_S, IMSI_11_12, and MCC
included RESERVED: 0
MCC: 310 IMSI_11_12: 00 IMSI_S: 9723333534
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
August, 2013
 The mobile’s first probe is
acknowledged, and the mobile now waits
for a traffic channel assignment.
 If the mobile does not hear a channel
assignment message within 12 seconds,
it will abort.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 77
Setup Failure Messaging
 If the mobile never hears the channel assignment message, the
setup fails and the mobile reacquires the system.
01:46:51.474 QcpCdmaLogMsgPagingChan
MSG_LENGTH: 21 octets PD: P_REV_IN_USE < 6
MSG_TYPE: Channel Assignment Message
ACK_SEQ: 5 MSG_SEQ: 1 ACK_REQ: No VALID_ACK: Yes
ADDR_TYPE: IMSI ADDR_LEN: 7 octets IMSI_CLASS: 0
IMSI_CLASS_0_TYPE: IMSI_S, IMSI_11_12, and MCC included
RESERVED: 0 MCC: 310 IMSI_11_12: 00 IMSI_S: 9723333534
ASSIGN_MODE: Extended Traffic Channel Assignment
ADD_RECORD_LEN: 5 octets FREQ_INCL: Yes RESERVED: 0
BYPASS_ALERT_ANSWER: No
DEFAULT_CONFIG: Multiplex Option 1 and Radio Config 1 For
Both FTC and RTC
GRANTED_MODE: MS use Service Configuration of default
Multiplex Option and Transmission Rates
CODE_CHAN: 9 FRAME_OFFSET: 5.00 ms
ENCRYPT_MODE: Encryption Disabled
BAND_CLASS: 1.850 to 1.990 GHz Band
CDMA_FREQ: 50 C_SIG_ENCRYPT_MODE_INCL: No
RESERVED: 0
X
or
X
August, 2013
 If the mobile hears the channel
assignment message but if the
link fails to initialize in either
direction on the traffic channel,
the setup attempt will fail and
the mobile will attempt to
reacquire the system.
 Steps in traffic channel
initialization:
 Forward link layer 2 handshake
 Reverse link layer 2 handshake
 L3 base station ack. order
 L3 mobile ack. order
 Failure of any one is a TCCF
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 78
Dropped Calls
 Normal calls end with an exchange of release messages by the
mobile and system
• Whichever side wants to end the call sends an order message,
“Release – Normal”. The other side sends an order message,
“Release – No Reason”.
• The mobile then immediately tries to reacquire the system, and
the Sync Channel Message is seen quickly during this process
 When a call fails (“drops”), no “Release – Normal” message is sent
by either side. Usually the first evidence of the drop will be the
Sync Channel Message during system re-acquisition after the
drop.
 Layer-2 timers and counters supervise every call on both ends,
and abort the call when their limits are exceeded. A few are:
• Forward Link Fade Timer (typically 5 seconds)
• Reverse Link Fade Timer (typically 5 seconds)
• various unacknowledged message counters
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 79
A Beautiful End to a Normal Call
MOBILE RELEASE ORDER
BASE STATION ACKNOWLEDGMENT
008090, Time 17:39:26.020, Record 167747,
QcpCdmaLogMsgForTrafChan
MSG_TYPE: Order Message
ACK_SEQ: 1
MSG_SEQ: 5
ACK_REQ: No
ENCRYPTION: Encryption Disabled
USE_TIME: No
ACTION_TIME: 0 ms
ORDER: Release Order (No Reason Given)
ADD_RECORD_LEN: 0 octets
RESERVED: 0
008091, Time 17:39:26.108, Record 167760,
QcpCdmaLogMsgRevTrafChan
MSG_TYPE: Order Message
ACK_SEQ: 4
MSG_SEQ: 1
ACK_REQ: No
ENCRYPTION: Encryption Disabled
ORDER: Release Order (Normal Release)
ADD_RECORD_LEN: 0 octets
RESERVED: 0
SYNC CHANNEL MESSAGE
008092, Time 17:39:26.514, Record 167820,
QcpCdmaLogMsgSyncChan
MSG_TYPE: Sync Channel Message
P_REV: IS-95B
MIN_P_REV: IS-95A
SID: 179
NID: 0
PILOT_PN: 468
LC_STATE: 0x02 87 7C F3 7F BA
SYS_TIME: 06/29/2002 06:15:19
LP_SEC: 13
LTM_OFF: -660 minutes
August, 2013
The mobile left the traffic channel,
scanned to find the best pilot, and read
the Sync Channel Message.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 80
Dropped Call Messaging
FORWARD TRAFFIC CHANNEL
REVERSE TRAFFIC CHANNEL
ANY COMBINATION OF NORMAL MESSAGES
MAY OCCUR ON THE FORWARD AND
REVERSE TRAFFIC CHANNELS, BUT NO
“RELEASE – NORMAL” IS SENT.
SYNC CHANNEL
SYNC CHANNEL MESSAGE
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 81
Dropped Call Messaging
 In a normal call end, there
will be a “Release –
Normal” message from
one side and a “Release –
No Reason” message from
the other.
 In this example, there are
no release messages.
• The mobile requests
adding PN196 to its
other 2 weak signals
• The mobile reports
40% FER
• Then the mobile drops,
and reacquires the
system on PN196.
13:37:13.600 QcpCdmaLogMsgRevTrafChan
MSG_LENGTH: 13 octets
MSG_TYPE: Pilot Strength Measurement Message
ACK_SEQ: 0 MSG_SEQ: 2 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled REF_PN: 284
PILOT_STRENGTH: -18.00 dB KEEP: Yes
PILOT_PN_PHASE: PN:447 + 45 chips
PILOT_STRENGTH: -18.50 dB KEEP: Yes
PILOT_PN_PHASE: PN:196 + 10 chips
PILOT_STRENGTH: -10.00 dB KEEP: Yes
RESERVED: 0
13:37:13.733 QcpCdmaLogMsgRevTrafChan
MSG_LENGTH: 10 octets
MSG_TYPE: Power Measurement Report Message
ACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: No
ENCRYPTION: Encryption Disabled
ERRORS_DETECTED: 2 PWR_MEAS_FRAMES: 5
LAST_HDM_SEQ: 3 NUM_PILOTS: 2
PILOT_STRENGTH: -18.50 dB
PILOT_STRENGTH: -18.00 dB
13:37:23.188 QcpCdmaLogMsgSyncChan
MSG_LENGTH: 26 octets
MSG_TYPE: Sync Channel Message
P_REV: Unknown (3) MIN_P_REV: IS-95A
SID: 22 NID: 0 PILOT_PN: 196
LC_STATE: 0x02 9E 9B E4 EE C4
SYS_TIME: 03/27/1998 06:01:32
LP_SEC: 8 LTM_OFF: -660 minutes
DAYLT: No PRAT: 9600 bps CDMA_FREQ: 777
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 82
Normal End of Call
W23
BTS
TRAFFIC
Voice
RELnorm
W1
PAGING KGKSAKKNKGGKSKPG
NSASPPCKGKSA
ACK SYS ChASN CHN XSYS NBR
W32
SYNC SSSSSSSSSSSSSSSSSSSSSSSSSSS
SYN SYN SYN SYN SYN SYN SYN SYN SYN
W0
SCAN Ref Time
PILOT
TIME
ACCESS CHANNEL
TRAFFIC CHANNEL
MOBILE REACQUIRES SYSTEM NORMALLY
Voice
RELnoRsn
 When a call ends normally, it is because the caller on one side of the
conversation decided to hang up
 The side ending the call sends a “Release – Normal” order
 The other side sends a “Release – No reason” order
• It may send an acknowledgment first, if it cannot give the release
order immediately
 After the system receives a release order from the mobile, it releases the
resources it used for the call
 After the mobile receives a release order from the base station, it stops
listening to the traffic channel and freshly reacquires the system
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 83
Abnormal End of Call – Forward Link Failure
W23
BTS
TRAFFIC
Voice
5s timer
All bad frames
W1
PAGING KGKSAKKNKGGKSKPG
NSASPPCKGKSA
ACK SYS ChASN CHN XSYS
W32
SYNC SSSSSSSSSSSSSSSSSSSSSSSSSSS
SYN SYN SYN SYN SYN SYN SYN SYN
W0
SCAN Ref Time
PILOT
TIME
ACCESS CHANNEL
TRAFFIC CHANNEL
MOBILE REACQUIRES SYSTEM, if available
Voice
Mute! No pc
5s timer
 The mobile is always counting and tracking the bad frames it
receives on the forward link
 Forward Link Fade Timer: If the mobile does not receive any good
frames during a 5-second period, it aborts the call
 If a mobile receives 10 consecutive bad frames, it mutes its
transmitter until at least 2 consecutive good frames are heard
• If the mobile stays muted 5 seconds, the BTS will release too
 After a call ends for any reason, the mobile tries to reacquire the
system, making an independent cold start
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 84
Abnormal End of Call – Reverse Link Failure
W23
BTS
TRAFFIC
Voice
RELnoRsn
W1
PAGING KGKSAKKNKGGKSKPG
NSASPPCKGKSAAKSKPG
NSAS
ACK SYS ChASN CHN XSYS
W32
SYNC SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SYN SYN SYN SYN SYN SYN SYN SYN
W0
SCAN Ref Time
PILOT
TIME
ACCESS CHANNEL
TRAFFIC CHANNEL
MOBILE REACQUIRES SYSTEM, if available
Voice
All bad frames
5s timer
 The BTS is always counting and tracking the bad frames it
receives on the reverse link from the mobile
 Reverse Link Fade Timer: If the BTS does not receive any good
frames during a 5-second period, it releases the call
 After a call ends for any reason, the mobile tries to reacquire the
system, making an independent cold start
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 85
Example 8
Let’s Do A Soft Handoff!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 86
Basic Rules of Soft Handoff
August, 2013
PILOT SETS
Active
6
Candidate 5
Neighbor 20
Remaining
Min. Members
Req’d. By Std.
 The Handset considers pilots in sets
• Active: pilots of sectors actually in use
• Candidates: pilots mobile requested, but
not yet set up & transmitting by system
• Neighbors: pilots told to mobile by system,
as nearby sectors to check
• Remaining: any pilots used by system but
not already in the other sets (div. by PILOT_INC)
 Handset sends Pilot Strength Measurement
Message to the system whenever:
• It notices a pilot in neighbor or remaining set
exceeds T_ADD
• An active set pilot drops below T_DROP for
T_TDROP time
• A candidate pilot exceeds an active by
T_COMP
 The System may set up all requested handoffs,
or it may apply special manufacturer-specific
screening criteria and only authorize some
HANDOFF
PARAMETERS
T_ADD
T_DROP
T_TDROP
T_COMP
Exercise: How does a pilot
in one set migrate into
another set, for all cases?
Identify the trigger, and the
messages involved.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 87
Ec/Io
The Call is Already Established. What Next?
All PN Offsets
0
-20
Chips
0
10752
PN 0
14080
32002
168 220
Active Pilot
Mobile Rake RX
F1 PN168 W61
Rake Fingers
F2 PN168 W61
F3 PN168 W61
Srch PN??? W0
Reference PN
T_ADD



500 512
The call is already in progress.
PN 168 is the only active signal,
and also is our timing reference.
Continue checking the neighbors.
Neighbor Set
!
!
If we ever notice a neighbor with Ec/Io above T_ADD,
ask to use it! Send a Pilot Strength Measurement Message!
August, 2013
32K
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 88
Basic Soft/Softer Handoff
 The fundamental and most common type of handoff in CDMA is
Soft Handoff directed by the mobile itself
• The mobile constantly checks the strength of the pilots it sees
• Whenever the mobile discovers a new pilot strong enough to
be useful, or notices a pilot it’s already using has faded to the
point of uselessness, it tells the system in a Pilot Strength
Measurement Message (PSMM)
 The system normally makes the changes requested by a mobile
• some systems have algorithms for intelligent “screening” of the
mobile’s requests, and may not give everything requested
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 89
Soft Handoff Messaging
FORWARD TRAFFIC CHANNEL
BASE STATION
ACK. ORDER
EXTENDED HANDOFF
DIRECTION MSG.
BASE STATION
ACK. ORDER
NEIGHBOR LIST
UPDATE MESSAGE.
August, 2013
REVERSE TRAFFIC CHANNEL
PILOT STRENGTH
MEASUREMENT MSG.
MOBILE STATION
ACK. ORDER
HANDOFF COMPLETION
MESSAGE
MOBILE STATION
ACK. ORDER
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 90
Soft Handoff Messaging (1)
 Soft Handoff begins with a
request – the Pilot Strength
Measurement Message from
the mobile
QcpCdmaLogMsgForTrafChan
04/03/2002 22:43:17
MSG_LENGTH: 18 octets
MSG_TYPE: General Handoff Direction Message
ACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled USE_TIME: No
HDM_SEQ: 1 SEARCH_INCLUDED: Yes
SRCH_WIN_A: 40 chips
SRCH_WIN_N: 100 chips
SRCH_WIN_R: 4 chips
T_ADD: -14.0 dB T_DROP: -16.0 dB
T_COMP: 2.0 T_TDROP: 4 sec
SOFT_SLOPE: 0
ADD_INTERCEPT: 0 dB DROP_INTERCEPT: 0 dB
EXTRA_PARMS: No
SUP_CHAN_PARAMS_INCLUDED: No
USE_PWR_CNTL_STEP: No
NUM_PILOTS: 2 Pilots
PILOT_PN: 380 PWR_COMB_IND: No
FOR_FUND_CODE_CHAN: 33
PILOT_PN: 212 PWR_COMB_IND: Yes
FOR_FUND_CODE_CHAN: 56
FPC_SUBCHAN_GAIN: 0.0 dB
USE_PC_TIME: No REV_FCH_GATING_MODE: No
August, 2013
QcpCdmaLogMsgRevTrafChan
04/03/2002 22:43:17
MSG_LENGTH: 10 octets
MSG_TYPE: Pilot Strength Measurement Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
REF_PN: 380 PILOT_STRENGTH: -4.50 dB KEEP: Yes
PILOT_PN_PHASE: PN:212 + 0 chips
PILOT_STRENGTH: -13.50 dB KEEP: Yes
RESERVED: 0
 As soon as the system has set
up the requested changes, it
sends a Handoff Direction
Message (Enhanced HDM,
General HDM, etc.)
• this gives the mobile the PN
offsets and walsh codes of all
sectors now active
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 91
Soft Handoff Messaging (2)
 The mobile acknowledges
receiving the Handoff Direction
Message
 After double-checking that the
requested sectors are still
usable, the mobile accepts
them by sending a Handoff
Completion Message
August, 2013
QcpCdmaLogMsgRevTrafChan
04/03/2002 22:43:17
MSG_LENGTH: 7 octets
MSG_TYPE: Order Message
ACK_SEQ: 1 MSG_SEQ: 0 ACK_REQ: No
ENCRYPTION: Encryption Disabled
ORDER: Mobile Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets
CON_REF_INCL: No RESERVED: 0
QcpCdmaLogMsgRevTrafChan
04/03/2002 22:43:17
MSG_LENGTH: 8 octets
MSG_TYPE: Handoff Completion Message
ACK_SEQ: 1 MSG_SEQ: 2 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
LAST_HDM_SEQ: 1 PILOT_PN: 380 PILOT_PN: 212
RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 92
Soft Handoff Messaging (3)
QcpCdmaLogMsgForTrafChan
04/03/2002 22:43:18
MSG_LENGTH: 38 octets
MSG_TYPE: Extended Neighbor List Update Message
ACK_SEQ: 2 MSG_SEQ: 3 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
PILOT_INC: 4
NGHBR_SRCH_MODE: Search Priorities
SRCH_WIN_N: 100 chips
USE_TIMING: No NUM_NGHBR: 20
NGHBR_PN: 40 SEARCH_PRIORITY: Very High
NGHBR_PN: 32 SEARCH_PRIORITY: High
NGHBR_PN: 372 SEARCH_PRIORITY: High
NGHBR_PN: 132 SEARCH_PRIORITY: High
NGHBR_PN: 448 SEARCH_PRIORITY: High
NGHBR_PN: 12 SEARCH_PRIORITY: High
NGHBR_PN: 260 SEARCH_PRIORITY: High
NGHBR_PN: 184 SEARCH_PRIORITY: High
NGHBR_PN: 504 SEARCH_PRIORITY: High
NGHBR_PN: 428 SEARCH_PRIORITY: High
NGHBR_PN: 352 SEARCH_PRIORITY: High
NGHBR_PN: 280 SEARCH_PRIORITY: High
NGHBR_PN: 108 SEARCH_PRIORITY: High
NGHBR_PN: 408 SEARCH_PRIORITY: High
NGHBR_PN: 136 SEARCH_PRIORITY: High
NGHBR_PN: 476 SEARCH_PRIORITY: High
NGHBR_PN: 360 SEARCH_PRIORITY: High
NGHBR_PN: 336 SEARCH_PRIORITY: Medium
NGHBR_PN: 344 SEARCH_PRIORITY: Medium
NGHBR_PN: 176 SEARCH_PRIORITY: Medium
SRCH_OFFSET_INCL: No
ADD_PILOT_REC_INCL: None RESERVED: 0

August, 2013
 The system takes the pilots
accepted by the mobile in the
Handoff Completion Message
and builds a new combined list
of all their neighbors
 The new blended neighbor list
is sent to the mobile in an
Extended Neighbor List Update
Message, which the mobile
acknowledges
 The handoff is now in effect!
QcpCdmaLogMsgRevTrafChan
04/03/2002 22:43:18
MSG_LENGTH: 7 octets
MSG_TYPE: Order Message
ACK_SEQ: 3 MSG_SEQ: 5 ACK_REQ: No
ENCRYPTION: Encryption Disabled
ORDER: Mobile Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets
CON_REF_INCL: No RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 93
Ec/Io
Handoff Now In Effect, but still check Pilots!
All PN Offsets
0
-20
Chips
0
10752
PN 0
14080
168 220
F1 PN168 W61
F3 PN220 W20


Rake Fingers

T_DROP
Srch PN??? W0
Reference PN
Neighbor Set
T_ADD
Continue checking each ACTIVE pilot. If any are less than T_DROP and remain
so for T_TDROP time, send Pilot Strength Measurement Message, DROP IT!!
Continue looking at each NEIGHBOR pilot. If any ever rises above T_ADD, send
Pilot Strength Measurement Message, ADD IT!
August, 2013
32K
500 512
Active Set
Mobile Rake RX
F2 PN500 W50
32002
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 94
Ec/Io
The Complete Picture of Handoff & Pilot Sets
All PN Offsets
0
-20
Chips 0
PN 0
Rake Fingers
SRCH_WIN_A
T_DROP
T_ADD

SRCH_WIN_A


Active Set
Pilots of sectors
now used for
communication
T_DROP
Reference PN
Candidate Set
SRCH_WIN_N
Pilots requested
by mobile but not
set up by system
32K
512
Mobile Rake RX
F1 PN168 W61
F2 PN500 W50
F3 PN220 W20
Srch PN??? W0
Neighbor Set
Pilots suggested
by system for
more checking
Remaining Set
All other pilots divisible by PILOT_INC but not
presently in Active, Candidate, or Neighbor sets
T_ADD
SRCH_WIN_R
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 95
Improved Soft Handoff Control
in 1xRTT
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 96
The IS-95 Situation
 IS-95 handoff is driven by fixed thresholds
of pilot strength (Ec/Io)
 If the mobile notices a new pilot stronger
than T_Add, it asks for it immediately
 If an active pilot drops below T_Drop and
stays below for T_Tdrop seconds, the
mobile asks for permission to stop using it
 The mobile has no discretion – the T_Add
and T_Drop values apply no matter what
-5
-10
T_ADD
-15
Ec/Io THRESHOLDS, db
0
T_DROP
-20
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 97
Disadvantages of Standard Handoff Triggers
August, 2013
Pilot Strength
(Ec/Io, db)
-3
Active
All Six
sectors in
soft handoff!
Active
Active
Active
Active
Active
T_Add
-20
-3
Pilot Strength
(Ec/Io, db)
 Mobile requests soft handoff with all
pilots above T_Add
• This occasionally leads to some
rigid, less-than-optimum decisions!
 Problem Situation 1
• One dominant, strong signal and a
lot of weak ones:
– Mobile asks for them all, but
only one is really needed!
 Problem Situation 2
• Heavy pilot pollution, many signals
lurk barely below the threshold
– Mobile starts call on the best
one, but never asks for
handoffs with any others
– mobile needs handoff to
survive! Four -16 signals are as
good as a single -10 signal!!
Only One
Sector in soft
handoff!
Active
T_Add
-20
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 98
1xRTT Allows Dynamic Handoff Thresholds
 A handoff process more intelligent than fixed thresholds
• Handoff events driven by smarter, situation-influenced triggers
 Candidate Set Removal: if that sector isn’t worth adding anymore
 Neighbor-to-Active transition: only if it’s a worthwhile improvement
 Removal from Active Set: if that sector isn’t needed anymore
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 99
Standard Equation of a Line
y
b
x
 The equation of a straight line
is pretty simple. It includes
• y, the vertical-axis value
• m, the slope of the line
– the ratio of rise/run
• x, the horizontal-axis value
• b, the y intercept
– the value of y where
the line crosses the y
axis
August, 2013
intercept
slope
y = mx + b
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 100
The Dynamic Handoff Threshold Line
+10
+5
COMBINED Ec/Io, db
-15
-10
-5
0
-5
Combined
Ec/Io
of Existing
Active Pilots
-10
Ec/Io THRESHOLDS, db
-20
Add
Intercept
Drop
Intercept
T_Add
-15
T_Drop
-20
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 101
Weak-Signal, Pilot-Pollution Conditions
+10
+5
COMBINED Ec/Io, db
-15
-10
-5
0
-5
T_Add and T_Drop can be
greatly reduced to allow soft
handoff under pilot pollution
conditions
Combined
Ec/Io
of Existing
Active Pilots
-10
Drop
Intercept
-15
T_Add
-20
August, 2013
Ec/Io THRESHOLDS, db
-20
Add
Intercept
RF200 v8.0 (c) 2013 Scott Baxter
T_Drop
RF200 - 102
Strong-Signal Conditions
+10
+5
COMBINED Ec/Io, db
-15
-10
-5
0
-5
Low T_Add and T_Drop will
not cause excessive soft
handoff when good signals
are available
Combined
Ec/Io
of Existing
Active Pilots
-10
Drop
Intercept
-15
T_Add
-20
August, 2013
Ec/Io THRESHOLDS, db
-20
Add
Intercept
RF200 v8.0 (c) 2013 Scott Baxter
T_Drop
RF200 - 103
Explore the Dynamics!
+10
+5
COMBINED Ec/Io, db
-15
-10
-5
0
-5
T_Add and T_Drop can be
greatly reduced to allow soft
handoff under pilot pollution
conditions
Combined
Ec/Io
of Existing
Active Pilots
-10
Ec/Io THRESHOLDS, db
-20
Add
Intercept
Drop
Intercept
T_Add
-15
T_Drop
-20
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 104
Deeper Handoff Details:
Search Windows & Timing
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 105
The Pilot Searcher’s Measurement Process
CURRENT PILOT SET CONTENTS
3 A A A
1 C
12 N N N N N N N N N N N N
112 R R R R R R R R R R R R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
The searcher checks pilots in nested
loops, much like meshed gears.
Actives and candidates
N
N
occupy the fastestspinning wheel.
N
Neighbors are
A
next, advancing
N
A A
one pilot for each
N
Act+Cand. revolution.
Remaining is slowest,
N
N
advancing one pilot each
time the Neighbors revolve.
R
R
NR
R
R
R
N
R
PILOT SEARCHER VIEWED IN SEQUENCE: Typical Elapsed Time = 4 seconds
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
R
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
R
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
N
A
A
A
C
R
August, 2013
Only 3 of 112 remaining set pilots
have been checked thus far!
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 106
Meet the CDMA
Performance Indicators
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 107
CDMA Performance Indicators
 A Flight Data Recorder logs aircraft operational settings. Its CDMA
equivalent is a file of RF performance indicators captured by drive-test
equipment.
 Key CDMA parameters and measurements show the condition of the RF
environment. They are the primary gauges used to guide CDMA
optimization and troubleshooting
• some indicate uplink conditions, some downlink, and some, both.
• these parameters are collected primarily at the subscriber end of the
link, and thus are easy to capture using readily available commercial
equipment without requiring assistance at the BSC
 Understanding these parameters and their important implications requires
basic knowledge in several subject areas:
• General: RF units, transmitter and receiver basics
• CDMA and spread-spectrum signal characteristics
– channel definitions
– power control systems
– basic CDMA call processing flow
– signal behavior characteristics in noise and interference
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 108
Indicator #1: FER
 FER Frame Erasure Rate
• on forward channel
(realized at Handset)
• on reverse channel
(realized at base station)
• FER is an excellent call
quality “summary” statistic
0 2 5
100
FER
%
 FER is the end-result of the whole transmission link
• if FER is good, then any other problems aren’t having much
effect
• if FER is bad, that’s not the problem - it is just the end-result of
the problem
– we must investigate other indicators to get a clue what is
going on
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 109
I0
Handset Receiver

LNA
BW
~30
MHz.
x
LO

IF
-40
Rake
R
R
R
BW
1.25
S
MHz.
RX Level
(from AGC)
-90
-105
<<too weak
 Mobile Receive Power
• usually expressed in dBm
• measured derived from
handset IF AGC voltage
• broadband, “unintelligent”
measurement: includes all
RF in the carrier bandwidth
regardless of source, not
just RF from serving BTS
overload>>
Indicator #2: I0, Total Mobile Receive Power
 Receive power is important, but it’s exact value isn’t critical
• too much received signal (-35 dbm or higher) could drive the
phone’s sensitive first amplifier into overload, causing intermod
and code distortion on received CDMA signals
• too little received signal (-105 or weaker) would leave too much
noise in the signal after de-spreading, resulting in symbol errors,
bit errors, bad FER, and other problems
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 110
Indicator #3, EC/I0 - What does it mean?
 Why can’t we just use the handset’s
received power level to guide
handoffs?
• Because it is a simple total RF
power measurement, the total of
all sectors reaching the mobile
Handset Receiver

BW
~30
MHz.
LNA
x
LO

IF
Rake
R
R
BW
1.25
S
MHz.
RX Level
(from AGC)
 We need a way to measure the signal strength of each sector
individually, and we must be able to measure it quickly and simply
 The solution is to use each sector’s pilot (Walsh 0) as a test signal
to guide handoffs
• At the mobile, if the pilot of a certain sector is very strong and
clean, that means we also should be able to hear a traffic
channel on that sector, so handoff would be a good idea
• if the pilot of a certain sector is weak, then we probably won’t
be able to get much benefit from using a traffic channel on that
sector
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
R
RF200 - 111
How EC/I0 Varies with Traffic Loading
August, 2013
Ec/Io = (2/4)
= 50%
= -3 db.
Paging
Sync
Pilot
1.5w
0.5w
2w
EC
I0
Heavily Loaded
Ec/Io = (2/10)
= 20%
= -7 db.
RF200 v8.0 (c) 2013 Scott Baxter
Traffic Channels
 Each sector transmits a certain
amount of power, the sum of:
• pilot, sync, and paging
• any traffic channels in use
at that moment
 Ec/Io is the ratio of pilot power
to total power
• On a sector with nobody
talking, Ec/Io is typically
about 50%, which is -3 db
• On a sector with maximum
traffic, Ec/Io is typically
about 20%, which is -7 db.
Light Traffic Loading
Paging
Sync
Pilot
6w
I0
1.5w
0.5w
2w
EC
RF200 - 112
How EC/I0 varies with RF Environment
Traffic
Channels
 In a “clean situation”, one
sector is dominant and the
mobile enjoys an Ec/Io just
as good as it was when
transmitted
 In “pilot pollution”, too many
sectors overlap and the
mobile hears a “soup” made
up of all their signals
• Io is the power sum of all
the signals reaching the
mobile
• Ec is the energy of a
single sector’s pilot
• The large Io overrides the
weak Ec; Ec/Io is low!
One Sector Dominant
Io = -90 dbm
Ec = -96 dbm
Ec/Io = -6 db
Paging
Sync
Pilot
I0
1.5w
0.5w
2w
EC
Many Sectors, Nobody Dominant
Io = 10 signals
each -90 dbm
= -80 dbm
Ec of any one
sector = -96
Ec/Io = -16 db
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
Traffic
Sync & Paging
Pilot
August, 2013
4w
RF200 v8.0 (c) 2013 Scott Baxter
BTS10
BTS9
BTS8
BTS7
BTS6
BTS5
I0
BTS4
BTS3
BTS2
BTS1
EC
RF200 - 113
Indicator #4: Handset Transmitter Power
 TXPO Handset Transmit Power
• Actual RF power output of the
handset transmitter, including
combined effects of open
loop power control from
receiver AGC and closed
loop power control by BTS
• can’t exceed handset’s
maximum (typ. +23 dBm)
Subscriber Handset
BTS
Receiver>>
LNA
DUP
TXPO
PA
LO
x

x
~
Rake
R
IF
R
 LO
Viterbi
Decoder

R
Open Loop
S
Closed Loop Pwr Ctrl
IF
I
Long PN
x
IF Mod
x
x
Q
Orth
Mod
Vocoder
FEC
<<Transmitter
Typical TXPO:
TXPO = -(RXdbm) -C + TXGA
C = +73 for 800 MHz. systems
= +76 for 1900 MHz. systems
+23 dBm in a coverage hole
0 dBm near middle of cell
-50 dBm up close to BTS
 What is the right power TX level? Whatever the BTS asks for!
• As long as closed loop control is working, the phone’s opinion
isn’t the last word. Just do what the BTS wants!!
• However, if the BTS ever asks the phone to do the impossible,
something is wrong (lower than -60 dbm, higher than +23 dbm)
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 114
Indicator #5: Transmit Gain Adjust
 What is Closed Loop Transmit Gain Adjust (TXGA)?
• The power correction the base station is asking the mobile to
make right now, in real-time
• At the beginning of a call, before the power control bits begin, it
is zero. Then the power control bits begin, 800 per second.
• During a call, TXGA is the running total of all the power control
bits which have been received thus far.
• Each power control bit asks for a 1 db correction, up or down
• Each power control bit is based on the base station’s latest new
decision: mobile is too strong, or mobile is too weak -- there is
no cumulative error, since each decision is “fresh”
0 dB
TXPO = -(RXdbm) -C + TXGA
C = +73 for 800 MHz. systems
= +76 for 1900 MHz. systems
Typical Transmit Gain Adjust
-10 dB
-20 dB
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
Time, Seconds
RF200 - 115
Closed Loop Power Control Dynamics
 The figures at right show the
power control reactions to a
sudden change in path loss
 The sudden change in path loss
causes a sudden change in
handset received signal
 Both open loop and closed loop
control race to get the phone
back to the right new power and
succeed in about 10 milliseconds
 Open loop continues to approach
the correct value better and better
on its own
 40 milliseconds later, no net
closed loop correction is needed.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 116
Problem “Signatures”
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 117
“Signatures” of Common Conditions
 The key CDMA RF Performance
Indicators provide powerful clues
in cause-and-effect analysis for
understanding problem conditions
 There are many common
conditions which are easy to
recognize from their characteristic
“signatures” -- unique
relationships among the key
indicators which are observed
when these conditions exist
 We will use the simplified format
shown at right to display the key
indicators for each of several
interesting cases.
August, 2013
SIGNATURE:
GOOD CALL
FFER
I0
100%
EC/IO
TxGa
+23
+25
0
-30
TxPo
+10
-40
0
+10
-6
-10
0
-10
50%
-20
-30
-10
-15
10%
5%
2%
0%
FFER
BTS
RF200 v8.0 (c) 2013 Scott Baxter
-40
-90
-20
-100
I0
-25
-20
-110
EC/IO
-50
TxGa
TxPo
Messaging
RF200 - 118
Signature of a Successful Call
 If the mobile station originates
successfully, remains in service
area, and makes normal release,
data will show:
•
•
•
•
Low forward FER
Receive power > -100 dBm
Good Ec/Io (> -12 dB)
Normal Transmit Gain Adjust
(actual value depends on site
configurations, loading &
NOM_PWR setting)
• Transmit power < +20 dBm
• Good Messaging
• Parsed message files will
contain a full set of normal
messages.
August, 2013
SIGNATURE:
GOOD CALL
FFER
I0
100%
EC/IO
TxGa
+23
+25
0
-30
TxPo
+10
-40
0
+10
-6
-10
0
-10
50%
-20
-30
-10
-15
10%
5%
2%
0%
FFER
BTS
RF200 v8.0 (c) 2013 Scott Baxter
-40
-90
-20
-100
I0
-25
-20
-110
EC/IO
-50
TxGa
TxPo
Messaging
RF200 - 119
Signature of a Dropped Call in Poor Coverage
SIGNATURE:
 If a mobile station is taken out
of the service area or into a
coverage hole, and only data
from the mobile station is
available, the log files will show
the following characteristics:
• High forward FER
• Low receive power (<-100
dBm)
• Low Ec/Io (< -10 dB)
• Higher-than-normal Transmit
Gain Adjust (actual value depends
on site configurations, loading,
NOM_PWR setting)
• Higher-than-normal transmit
power (> +20 dBm)
• Poor messaging on both links
August, 2013
DROPPED CALL, BAD COVERAGE
FFER
I0
100%
EC/IO
TxGa
+23
+25
0
-30
TxPo
+10
-40
0
+10
-6
-10
0
-10
50%
-20
-30
-10
-15
10%
5%
2%
0%
FFER
BTS
RF200 v8.0 (c) 2013 Scott Baxter
-40
-90
-20
-100
I0
-25
-20
-110
EC/IO
-50
TxGa
TxPo
Messaging
RF200 - 120
Signature of Forward Link Interference
 Characteristics of data for a phone
experiencing forward link
interference from a source other
than the current BTS:
•
•
•
•
High forward FER
Good receive power (> -100 dBm)
Low Ec/Io (< -10 dB)
Higher-than-normal Transmit Gain
Adjust
• Normal transmit power (< +20
dBm)
• Poor forward link messaging
– unreliable at best and may be
the actual cause of the drop.
SIGNATURE:
FORWARD LINK INTERFERENCE
FFER
100%
EC/IO
TxGa
+23
+25
0
-30
TxPo
+10
-40
0
+10
-6
-10
0
-10
50%
-20
-30
-10
-15
10%
5%
2%
0%
FFER
BTS
August, 2013
I0
RF200 v8.0 (c) 2013 Scott Baxter
-40
-90
-20
-100
I0
-25
-20
-110
EC/IO
-50
TxGa
TxPo
Messaging
RF200 - 121
A CDMA Drop Example: Forward Link Case
 A mobile using Site A comes
down the highway and
suddenly begins to see the
signal of Site B
 If the mobile begins soft
handoff with site B, everything
continues to go well
 If the mobile cannot begin
handoff with B for any reason,
the call is doomed
• site B’s signal will override
site A’s signal, making it
unreadable
• as soon as the FER goes
too high, a fade timer will
start the the mobile will
eventually die
August, 2013
FORWARD LINK DIES
A
BTS
B
BTS
B grows stronger and stronger.
Mobile’s open-loop instinct is to transmit
weaker; closed-loop correction from A
goes higher and higher, maintaining the
mobile at the right power.
Finally B obscures A, which disappears
in an explosion of FER. The mobile
mutes since it can’t hear power control
bits, and a fade timer or message timer
kills the call in a few seconds.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 122
Signature of Reverse Link Interference
 Characteristics of data for a phone
whose BTS has a raised noise
floor due to reverse link
interference
•
•
•
•
Good forward FER
Good receive power (> -100 dBm)
Good Ec/Io (> -10 dB)
Higher-than-normal Transmit Gain
Adjust
• Higher-than-normal transmit power
(< +20 dBm)
• Poor reverse link messaging
– in the message files, you’ll
see repeats of messages on
the forward link and reverse
link
August, 2013
SIGNATURE:
REVERSE LINK INTERFERENCE
FFER
I0
100%
EC/IO
TxGa
+23
+25
0
-30
TxPo
+10
-40
0
+10
-6
-10
0
-10
50%
-20
-30
-10
-15
10%
5%
2%
0%
FFER
BTS
RF200 v8.0 (c) 2013 Scott Baxter
-40
-90
-20
-100
I0
-25
-20
-110
EC/IO
-50
TxGa
TxPo
Messaging
RF200 - 123
A CDMA Drop Example: Reverse Link Case
 When a cell is penetrated by a
mobile not under its own
power control, bad things
happen!
• The foreign mobile is being
power controlled by a
more distant cell, so it is
transmitting louder than
appropriate
• the local mobiles must
power up in a deadly race
to keep up with the
interferor
• local mobiles can still hear
the cell fine; the forward
link is just great, to the
very end
August, 2013
REVERSE LINK DIES
B
BTS
It was a beautiful day in the neighborhood
for all the mobiles on site B until the grim
reaper arrived, transmitting at high power
to maintain its link with distant Cell A.
Cell B tried to power up each of its
individual mobiles so they would be
received as strong as the new interferor,
but mobiles more distant than the
interferor just couldn’t keep up, and died.
Eventually the interferor died from
forward link interference, too.
If only the interferor had a soft handoff, all
of this violence could have been avoided.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 124
Solving the #1 Death Scenario: Failed Handoff
What Went Wrong??!
Steps in the Handoff Process
see
Mobile’s searcher notices
the needed new pilot
ask
Mobile sends PSMM
requesting handoff
System sets up the handoff:
•channel elements
do
•forward power
BTS •space in packet pipes
Simulcasting begins!
Now the system can hear
the mobile better!
tell
System tells mobile how to
hear the new sectors:
BTS Handoff Direction Message
Now the mobile can hear
the system better, too!
ok!
tell
Mobile confirms completion:
Handoff Completion Message
System makes new neighbor list,
sends to mobile: Neighbor List
BTS Update Message
August, 2013
FORWARD LINK DIES A
REVERSE LINK DIES
BTS
B
BTS
B
BTS
 Why didn’t the mobile ask for handoff?
• New sector not on neighbor list
• Neighbor Search Window too Small?
• BTS in “island mode”, wrong PN?
 Why didn’t the BTS set up the handoff?
• Old BTS didn’t hear mobile – rev link
interf?
• No resources available on new BTS?
• T-1 unstable, messages lost
 Why didn’t the mobile do the handoff?
• Couldn’t hear BTS, Fwd link interf?
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 125
Pilot Pollution
 When a large number of
CDMA signals are received
at about the same strength,
they cause severe
interference to each other
• this is called Pilot
Pollution
 The cure for pilot pollution
is to eliminate unneeded
signals which really weren’t
intended to serve this
location anyway, and to
boost the one or a few
signals which were
intended to serve this
location
 See the first page of the
workbook ECIOPLAY.XLS
August, 2013
Ec/Io value
at each
BTS TX
Io
-3
-80.0
Signal
Strength Ec/Io
-90
-13.0 1
-90
-13.0 2
-90
-13.0 3
-90
-13.0 4
-90
-13.0 5
-90
-13.0 6
-90
-13.0 7
-90
-13.0 8
-90
-13.0 9
-90
-13.0 10
-80.0 Sum Power
Ec/Io of Multiple CDMA Signals
1
2
Ec/Io value
at each
Io
BTS TX
-3
-73.9
Signal
Strength Ec/Io
-90
-19.1 1
-90
-19.1 2
-90
-19.1 3
-90
-19.1 4
-75
-4.1 5
-90
-19.1 6
-90
-19.1 7
-90
-19.1 8
-90
-19.1 9
-90
-19.1 10
-73.9 Sum Power
RF200 v8.0 (c) 2013 Scott Baxter
3
4
5
6
7
8
9
10
9
10
Ec/Io of Multiple CDMA Signals
1
2
3
4
5
6
7
8
RF200 - 126
Pilot Pollution/Handoff/Composite Ec/Io Demo
 See the second page of the workbook ECIOPLAY.XLS
Ec/Io, Handoff, and Rake Finger Pilot Status
%Pilot
Power
10%
%
Overhead
Power
Nominal
Max
Power
W
20%
12
Sum
RF
Comp Max #
Power osite Lockable
Io
Ec/Io Rake Fingers
-86.2
-3.0
Max #
Pilots in
Soft
Handoff
3
Traffic
Trans Path
Signal
Loading mitted Loss,
Streng
%
Ec/Io dB
th
Ec/Io
0%
-3.0
120 -86.2
-3.0 Rake Locked Handoff
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
0%
-3.0
200 -166.2 -83.0
Relative Energies of Multiple CDMA Signals
Pilot Energy
1
T_ADD
6
Sync, Paging, Traf fic
-12
0.9
0.8
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
Interferor
1
2
3
4
5
6
7
8
9
10
11
12
13
14
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
1
Only grey-shaded fields can be changed. Other fields calculate automatically.
To unlock all cells, select TOOLS>PROTECTION>UNPROTECT SHEET.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
2
3
4
5
6
7
8
9
10
11
12
13
14
I nd i vi d ual Sig nal s
RF200 - 127
CDMA System Performance Optimization
Basic PN Planning and
Search Window Considerations
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 128
Introduction to PN Planning and
Search Windows
 In PN planning and setting Search Windows, several pitfalls must
be avoided. These slides explain most of the basic facts,
background, principles, and practical considerations involved.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 129
Short PN Basics:
PN Offsets Distinguish Sectors
A
Phone
B
x
C

BPF
LNA
x
LO

BPF
IF
Rake Receiver
PN A Walsh X
PN B
Walsh Y
PN C
Walsh Z

Decoding
Vocoder
Pilot Searcher
D
 Each sector uses the short PN code, but at a different timing delay called
its PN offset
• PN delays are settable in 64-chip steps called "PN offsets"
– For example, PN offset 100 means 6,400 chips of delay
• PN short code is 32,768 chips long - room for 512 different PN offsets
 In the rake finger of a mobile in soft handoff, the short PN code is
generated in step with just one sector the mobile is trying to hear
• The rake finger hears the matching sector's signal, ignores all others
• The rake finger next decodes the walsh code of the desired channel
from that sector, ignoring all other users on that sector
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 130
A Practical "Rule of Thumb" to Remember
Received:
Transmitted:
PN 101
PN 100
6,464 chips delay
6,400 chips offset
9.70 miles = 64 chips = 1 PN
ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcdefghijkmnopqrstuvwxyz!@#$%^&*()_+
The PN chips SEEN by the mobile are what the base station
transmitted 64 chips in the past! What the base station is really
doing now, its true PN offset, is 64 chips later than what the mobile
sees. So the base station's signal at the mobile seems to be one
PN lower than it was actually transmitted.
BTS
Mobile
 The signal of a base station roughly 10 miles distant will SEEM to
be one PN higher than it was transmitted
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 131
Propagation Delay changes apparent PN Offset
 Base stations transmit signals on assigned,
fixed short PN delays called PN Offsets
 Transmitted signals encounter additional
delay traveling to the mobile
• ~6.7 chips/mile = ~4.1 chips/kilometer
 These additional delays can become
significant and cause errors at the mobile!
• Failure to recognize certain signals
• Misidentification of signals, recognizing
on BTS as another
• Improper combination of signals listening to the wrong BTS and trying to
decode and combine its signal in a
handoff
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
PN360
10 KM
41 chips
2 KM
8 chips
PN200
RF200 - 132
Mobile Timing: the Reference PN
How many chips????
0
Ec/Io
UNKNOWN EXTRA
PROPAGATION DELAY
All PN Offsets
Active Pilot
Pilot Searcher Scans All PNs
-20
Chips 0
PN 0
32K
 Rake Fingers

512
 SYNC CHANNEL MESSAGE
Mobile System Acquisition Process
98/05/24 23:14:09.817 [SCH]
 Scan entire range of PNs
MSG_LENGTH = 208 bits
MSG_TYPE = Sync Channel Msg
 Lock to strongest Pilot found
P_REV = 3, MIN_P_REV = 2
Reference
PN
SID = 179 NID = 0
• Put rake fingers on multipaths
PILOT_PN = 168 Offset Index
LC_STATE = 0x0348D60E013
• Earliest arriving multipath is "reference PN"
SYS_TIME = 98/05/24 3:14:10.160
LP_SEC = 12
 Read sync channel message
LTM_OFF = -300 minutes
DAYLT = 0, PRAT = 9600 bps
• Learn what PN this is!
 But there's no way to know how many chips of propagation delay have
happened before this signal was received
• The mobile is "blind" to whatever this error may be; so the mobile's
internal PN reference is late by an unknown amount
• Every pilot the mobile looks for will appear to be early or late too!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 133
What are "Search Windows"?
 New pilots usually seem earlier or later
than their official PNs from the neighor list
• Some have come from nearer, some
from farther, than the reference PN
 A mobile must look for pilot energy through
a range of chips earlier and later than the
exact expected PN offset of the signal it is
trying to measure
 These "tolerance" ranges are called
"Search Windows"
• SRCH_WIN_A applies to active and
candidate pilots
• SRCH_WIN_N applies to neighbors
• SRCH_WIN_R applies to remaining
 Search windows are chosen by RF
engineers and transmitted to the mobile in
messages from the BTS
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
PN360
10 KM
41 chips
+41
PN200
2 KM
8 chips
360
+8
360+33c
SRCH_WIN_N
RF200 - 134
What are the Available Search Window Values?
 Search windows can't be set to the exact number
of chips desired; each window can be set to a
value from the list at right
 Remember the widths are total and apply with the
mobile's reference at the center.
• For example, SRCH_WIN_N = 10 means
when the mobile is checking for neighbor
pilots, it will search a range 100 chips wide,
centered on what it thinks is the reference PN.
– The mobile will search from 50 chips
earlier to 50 chips later than the exact PN
it expects to find
 Search windows should be wide enough to include
needed signals, but not unnecessarily wide
• Grossly over-wide search windows will slow
down the mobiles' overall pilot searching
speed
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
SRCH_WIN_val Width, Chips
0
4 (±2)
1
6 (±3)
2
8 (±4)
3
10 (±5)
4
14 (±7)
5
20 (±10)
6
28 (±14)
7
40 (±20)
8
60 (±30)
9
80 (±40)
10
100 (±50)
11
130 (±65)
12
160 (±80)
13
226 (±113)
14
330 (±165)
15
452 (±226)
RF200 - 135
Search Window Settings: Neighbor Set
Neighbor Search Window
Example
 The neighbor search window must be set
wide enough to include the energy of any
needed neighbor pilot
 The mobile at right is using PN200 as its
reference (and only active) pilot
 To the mobile, the pilot of neighbor sector
PN360 seems 33 chips late
 SRCH_WIN_N must be set to at least 2 x
33 = 66 chips wide so the PN360 pilot can
be noticed by the mobile
 The closest search window setting above
66 chips is SRCH_WIN_N = 9, which is 80
chips wide
PN360
Neighbor
Sector
10 KM
41 chips
+41
PN200
2 KM
8 chips
Active
Sector
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
360
+8
360+33c
SRCH_WIN_N
RF200 - 136
Worst-Case Wide Neighbor Window Situation
BTS A
BTS B
1/2
mile
12 miles
 In some terrain, it is possible for a mobile to be very close to one BTS
and far from another BTS, yet need them both in soft handoff
 This occurs when local terrain or buildings obstruct the signal of the near
BTS, making it much weaker than normal
• The far BTS may have much more favorable conditions, such as an
over-water path
• The signals of the two BTSs may seem equally strong!
 Almost the entire distance between the BTSs appears as timing skew
• If near BTS is reference PN, distant BTS is late this number of chips
• If far BTS is reference PN, near BTS is late by this number of chips
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 137
Safe Initial Neighbor Search Window Value
Determining Safe
 Examine a cell map for an area of your system
Initial SRCH_WIN_N
 Identify the farthest-apart pair of cells likely to
be used in soft handoff
F
D
• Their distance separation determines
maximum timing skew a mobile could ever
E
possibly encounter in this part of the
B
system
11.5 KM
 Calculate the timing skew in chips
C
A
• 6.7 chips times miles or 4.1 chips times
kilometers
• Safe required window size = two times the
Required Window
skew
= 4.1 x 11.5 x 2 = 94.3 chips
SRCH_WIN_N = 10
 Refer to table to convert required window size If locations
exist near site A
in chips to required value of SRCH_WIN_N
where mobiles are in handoff with
site F, mobiles could encounter
 After thorough drive-test data is available, it
neighbor pilot timing skews as
may be possible to reduce SRCH_WIN_N if
large as the A-F distance. If
observed delay spread is significantly
locked to A, F looks late by this
amount. If locked to F, A looks
narrower than the window
early by this amount. Window
must be twice the skew value.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 138
Search Window Settings: Remaining Set
 Remaining set search window size is
determined by maximum possible timing
skew in the same way as for neighbor set
window
 Recommended SRCH_WIN_R is one or two
steps greater than SRCH_WIN_N
 Remaining set pilots can be requested by the
mobile in a PSMM but the system cannot
assign traffic channels since it uses the
Neighbor Pilot Database as its crossreference for identification of their base
stations
 There is still value in allowing mobiles to find
and request remaining pilots, since the
requests help system RF engineers identify
missing pilots that should be added to the
neighbor lists of various sectors
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
D
F
E
B
11.5 KM
A
C
RF200 - 139
Search Window Initial Settings: Active Set
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
Active Search Window
40 chips wide (typical)
-20
0
+20
Ec/Io
 Neighbor and Remaining search window
centers are indexed against the mobile’s
Reference PN
 Each active search window is different – a
“floating” window centered over the earliest
observed multipath energy during the previous
mobile searcher scan of that individual pilot
 Active search windows need not accommodate
distance-based timing skews – they float
centered on their respective pilots!
 The only timing variations they must
accommodate are multipath delay spreads
 Multipath delay spreads are determined by
terrain and clutter-driven scattering and
reflection of the signal
 Measurements are better than predictions to
set SRCH_WIN_A
Earliest Detected
Multipath
The earliest arriving multipath
seen by the mobile during this
searcher sweep will be used
as the center of this active
window on the next searcher
sweep! This makes each
active search window "track"
individually with its pilot.
RF200 - 140
SRCH_WIN_A Settings from Measurements




Typical active set delay spread from actual drive-tests
Notice the narrow distribution of energy!
28-chip width, SRCH_WIN_A = 6, is enough for this case
Drive-test your own system to determine your own value of spread
• It is determined by the signal-scattering characteristics of your terrain
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 141
SRCH_WIN_A Special Consideration
SRCH_WIN_N, Chips
 Active set delay spread is very narrow –
can the active search window be set
narrow too?
 Mobile reference timing occasionally
“jumps” due to false early-window
detection of the reference pilot
20
28
40
60
80
100
130
160
226
SRCH_WIN_A, Chips
10 14 20 28 40 60
No No No No No No
No No No No No No
No No No No Yes No
No No No Yes Yes Yes
No No No Yes Yes Yes
No Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes Yes
 There is a dynamic relationship between mobile reference timing
stability and the active and neighbor search window sizes
 The chart above shows which combinations of SRCH_WIN_A
and SRCH_WIN_N are safe and stable for all mobiles
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 142
The Potential for PN Problems and Conflicts
 After seeing the skewing effects of propagation, it is easy to
anticipate problems of PN confusion and misidentification!
There are many different kinds of possible PN problems:
 Two same-PN base stations with areas of coverage overlap
• Mobiles can't distinguish them, experience horrible FER
 Combining unintended signals into the handoff mix being heard
• The new signals cause interference instead of helping
 Mistaken identity of signals when requesting handoff
• The wrong base station is added, the mobile can't hear it
 Running out of available PNs due to bad parameter choices
Fortunately, these problems can be avoided by careful planning!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 143
Co-Active PN Demodulation Errors
ACTIVE SEARCH WINDOW
BTS A
PN 142
BTS B
PN 142
x miles
x miles
 Mobile is midway between two BTSs with the same PN, in a call on BTS A
 PN energy of BTS A and B is indistinguishable in active search window
 Rake fingers may be assigned to both A and B energy
• If the walsh code used on A also happens to be in use by someone on
BTS B, demodulation of B will cause severe FER
• The mobile audio will frequently clip and mute, and the call may drop
• All the while, the phone will see very good Ec/Io since both A and B
are recognized as good energy!
 Solution: Two different BTS covering the same area should never have
the same PN offset. Change the PN offset for one of the sectors involved.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 144
Adjacent-Active-PN Demodulation Errors
BTS A
PN 100
BTS B
PN 99
ACTIVE SEARCH WINDOW
1 mile
11 miles
 Mobile is in a call on BTS A from 1 mile away; A is the reference PN
 The signal from BTS B on PN 99 travels 11 miles to the mobile and is
approximately as strong as BTS A due to terrain effects
 Due to propagation delay, the signal of B is skewed and falls inside the
active search window of the mobile for A
• A and B energy are indistinguishable to the mobile
• Rake fingers may be assigned to both A and B multipaths
• If the walsh code used by the mobile on A also is in use by someone
else on B, the mobile may demodulate their symbols and combine
them with its own symbols from BTS A
• This would cause severe FER and possibly a dropped call
 Solution: The PNs of the two BTSs are too close together. Use a different
PN offset for BTS B.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 145
PILOT_INC Helps Avoid PN Problems
 Imagine a network with base stations spaced
approximately 10 miles apart - this is 1 PN offset!
 Recall if we use adjacent PNs for adjacent base
stations, there will be locations where their PNs are
close together or even indistinguishable
 It would be smart to assign PNs farther apart!
 If properly set, PILOT_INC can prevent this problem
• Only PNs divisible by PILOT_INC are allowed to
be assigned to sectors
 PILOT_INC can be chosen from 1 to 16
• If too small, interfering PNs can be assigned
• If too large, the pool of available PNs is small
 PILOT_INC is set based on the density of cells
• 3 or 4 in typical cities with suburban density
• 2 in dense urban environments
• 6 or 8 in very rural areas
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
D
RF200 - 146
Adjacent-Neighbor PN Recognition Errors
BTS A
PN 100
20 miles
BTS
BTS G
PN 198
BTS
NEIGHBOR SEARCH WINDOW
BTS F
PN 200
X
BTS
 Mobile is in a call on BTS A, PN 100
 Mobile checks neighbor PN 200 to see if handoff needed with BTS F
 Energy from distant BTS G on PN 198 is skewed so that it falls in the
neighbor search window for PN 200; mobile asks for handoff with F
 The system sets up a traffic channel on BTS F - but mobile hears G!
 If the walsh code assigned on F happens also to be in use on G, the mobile
may put a rake finger on it and include it in the mix
• Severe FER and a possible dropped call will result!
 Solution: Careful RF design to avoid such "pockets" of distant coverage
• If signal of G can't be reduced by RF methods, assign it to a different PN
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 147
Sector PN Assignments:
Consecutive Assignment
 Use only PNs divisible by PILOT_INC.
• PILOT_INC is chosen large enough to
prevent aliasing of pilots in adjacent cells
 Assign PNs in sequence to the sectors of all
the base stations
 Common Usage: This is the typical default
method used in Nortel and Motorola CDMA
networks
 Advantage
• Simple assignment
• When adjacent PNs are observed in the
field, they are known to be from sister
sectors of the same BTS or from nearby
BTSs
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
12
96
88
4
8
24
92
20
84
108
100
76
80
36
104
112
116
28
32
72
120
16
64
68
48
40
44
60
52
56
RF200 - 148
Sector PN Assignments:
Segment Assignment
 Assign only PNs divisible by PILOT_INC
• PILOT_INC is chosen to avoid aliasing
 Different ranges of PN values are reserved
• First 1/3 of PN offsets for alpha sectors
• Second 1/3 of PN offsets for beta sectors
• Third 1/3 of PN offsets for gamma sectors
 Although 512/3 = 170.666, the value 168 is
usually used for the inter-sector PN increment
 Common Usage: default in Lucent networks
 Advantage: In the field, interference is
suddenly noticed from PN 468. Quickly, what
is the source of it?
• Definitely some cells gamma sector!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
340
368
32
4
172
344
200
176
364
372
36
28
196
348
204
40
208
12
180
360
376
8
24
192
352
16
184
356
20
188
RF200 - 149
A
PN Reuse Explorations
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 150
A
PN Reuse – Symmetrical N=37 Pattern
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 151
PN Symmetrical N=37 Reuse Pattern Exploded View
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 152
A
Course RF200
Introduction to CDMA
Performance Data
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 153
What Data is Available for Performance Study?
HANDSET
CDMA NETWORK EQUIPMENT
Switch
SLM
Access Mgr./BSC-BSM
CM
GPSR
LPP
ENET
NOIS Messages
CDSU
CDSU DISCO
NMIS
Messages
CDSU
BSM
TFU1
DMS-BUS
LPP
DTCs
CDSU
CDSU
DISCO 1
DISCO 2
SBS
IOC
Switch OMs,
pegs, logs
Vocoders
Selectors
Selector
Logs
Various
External
Analysis
Tools
BTS
CDSU
CDSU
CDSU
CDSU
Ch. Card
GPSR
TFU1
IS-95/J Std 8
Messages
ACC



Txcvr A RFFE A
Txcvr B RFFE B
Txcvr C RFFE C
QC-Specific Messages
IS-95/J Std 8 Messages
Unix-based,
PC-based
Data Analysis
Post-Processing
Tools
Handset
Messages
PC-based
Mobile Data
Capture Tools
PC-based
Mobile Data
Post-Processing
Tools
 CDMA data for analysis flows from three sources:
• Switch, CDMA peripherals and base stations, and the Handset
 Various software and hardware tools are available for collection and
analysis of each of these streams of data
 Data contains messages and various indicators of RF performance
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 154
Resources on System and Switch Data
 CDMA networks are complex, including large conventional telephone
switches, high-capacity CDMA system peripherals such as BSCs, CBSCs,
and Access Managers, and many base stations (BTSs) which are usually
multi-carrier
• A network is literally a CITY of processors and software
 The specific performance statistics and event counters ('peg counts') are
best described in official documentation from the network manufacturers
• However, current documentation always seems to lag behind cuttingedge hardware and software releases
 Each manufacturer publishes help on its own hardware & software:
• Lucent: Wireless Networks Systems Documentation CDs
– Application notes; many good training courses
• Nortel: Helmsman CD, documents, training courses
• Motorola: Planning Guides, documents, training courses
 This course focuses on the generic key indications to observe, and the
analytical skills and perspective necessary for optimization
• The manufacturers' documentation will describe the actual counters
and measurements available from your network
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 155
System Data and
Statistical Analysis
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 156
Statistical CDMA Performance Indicators
Each network platform (Lucent,
Nortel, Motorola) has its own
unique set of available statistics.
These indications are collected from
the Switch, CDMA peripherals, and
the base stations. They can be
analyzed, tracked and trended for
system performance
benchmarking.
These indications should be examined
from many perspectives: overall for
an entire system, by individual
sector and cell, and both in
absolute numbers and by
percentages of total traffic.
August, 2013
 Dropped Call Statistics
 Failed Access Attempts
 Blocking Statistics
• BTS sector level
• BSC resource level
• Switch resource level
• PSTN trunking level
 Counts of specific call
processing error events
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 157
Comparing All Systems Sorted By Daily Traffic Level
Example System D Day
All 1,338,386 1,240,937
Example System E Day
All
355,247
347,325
Example System B Day
All
227,257
222,425
Example System C Day
All
220,707
205,766
Example System A Day
All
209,621
205,461
Example System F Day
All
206,482
198,945
Example System H Day ALL
163,921
160,473
Example System G Day
All
148,765
143,633
97.9%
96.1%
443
0.04% 12,429
2.1%
1.1% 20,015
2.8%
92.7% 44,593
97.8%
n/a
97.9%
388
93.2%
6,312
98.0%
n/a
96.4%
n/a
97.9%
63
96.6%
n/a
3.33% 35,329
n/a
7,922
0.17%
4,444
2.86%
6,090
n/a
n/a
n/a
7,537
0.04% 1,776
n/a
5,132
2.64% 30,576
2.23%
n/a
1.96%
n/a
2.76%
5,088
n/a
3,297
3.65%
4,556
1.1% 2,859
3.45%
3,074
1.7% 11,229
2.1%
2.28%
n/a
n/a
2.31%
1.60%
2.29%
1.7%
2.14%
% Screen Cal
Screen Calls
%-Drop
Calls-Drop
%RF Acc-Fail
RF Acc-Fails
%Tot-Block
1,123,308
Total-Block
1,147,447
%-Succ.
Call-Succ.
Cells
Week ALL
Call-Att.
Example H
Average of Others
Period
MTA-Name
Typical Network Performance
1.0%
0.6%
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
1,327 0.6%
n/a
n/a
1,604 1.0%
n/a
n/a
 Here is a comparison of typical network performance in the industry
against a new rural wireless system with light loading
 How does your system compare against the industry norms? Against the
lightly loaded rural system?
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 158
Another Network Performance Example
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 159
Analyzing System Data
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 160
Percent
Total Blocked Call Percentage Example
Total Block Call Percentage
8.0%
7.5%
7.0%
6.5%
6.0%
Blkd
5.5%
5.0%
4.5%
4.0%
3.5%
3.0%
2.5%
2.0%
1.5%
1.0%
Date
 This is an example of a cumulative system-wide total blocked call
percentage chart maintained in one market
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 161
Percent
Dropped Call Percentage Tracking Example
Total Drop Call Percentage
5.0%
4.5%
%Drops
4.0%
3.5%
3.0%
2.5%
2.0%
1.5%
1.0%
0.5%
0.0%
Date
 Dropped call percentage tracking by one market
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 162
Total System Daily MOU Example
MOU
Daily Total System MOU
300000
Daily Total System MOU
250000
200000
150000
100000
50000
0
Date
 Total system daily MOU plotted by one market
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 163
“Top Ten” Performance Tracking Example
Call Attempts
3000
2500
2000
1500
1000
500
108.1
43.3
108.2
1.3
Sector
102.2
0
137
130
65
101
83
49
30
24
46
31
7.5
5.1
5.1
4.5
4.3
3.0
2.9
2.8
2.6
1.9
136
130
65
101
83
49
30
24
45
31
7.4
5.1
5.1
4.5
4.3
3.0
2.9
2.8
2.6
1.9
110
145
90
93
66
66
58
112
83
81
6.0
5.7
7.0
4.1
3.4
4.1
5.7
13.1
4.8
5.0
8.0
7.0
6.0
5.0
4.0
3.0
2.0
1.0
0.0
Sector
26.3
84.5
87.2
85.7
89.9
90.7
91.6
90.2
81.6
91.3
91.7
% Blocked Calls
64.1
1549
2234
1098
2017
1743
1486
926
698
1589
1495
%Acc Drop %Drop
Fail Calls Calls
63.2
1833
2561
1282
2244
1922
1623
1027
855
1740
1630
Acc
Fail
1.2
Call %Call Block %Blck
Call Att Succ Succ Calls Calls
2.1
93Z
13X
57Z
2X
1Y
57Y
93X
35Z
30Y
1Z
Call Attempts
63.3
64.3
6.1
63.3
2.1
1.2
63.2
64.1
26.3
108.2
1.3
5.7
4.1
3.4
6.0
4.8
5.0
4.1
4.3
3.6
3.6
6.1
MSC
Site
145
93
66
110
83
81
66
70
54
53
September 5, 1997
% Blocked Calls
Eng
Site
5.1
4.5
4.3
7.4
2.6
1.9
3.0
1.1
1.8
0.3
63.2
130
101
83
136
45
31
49
18
27
4
1.3
5.1
4.5
4.3
7.5
2.6
1.9
3.0
1.1
1.8
0.3
108.2
130
101
83
137
46
31
49
18
27
4
64.3
87.2
89.9
90.7
84.5
91.3
91.7
91.6
92.6
93.1
94.8
1.2
2234
2017
1743
1549
1589
1495
1486
1495
1387
1410
2.1
2561
2244
1922
1833
1740
1630
1623
1615
1490
1488
%Acc Drop %Drop
Fail Calls Calls
6.1
13X
2X
1Y
93Z
30Y
1Z
57Y
4Y
30X
42Z
Acc
Fail
64.3
6.1
2.1
1.2
64.3
108.2
1.3
63.2
102.2
108.1
43.3
Call %Call Block %Blck
Call Att Succ Succ Calls Calls
Calls
MSC
Site
%
Eng
Site
 Many markets use scripts or spreadsheet macros to produce
ranked lists of sites with heavy traffic, performance problems, etc.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 164
“Bracketing”: Fault Notification and Alarming
 Some operators develop their
own software for monitoring
and tracking performance data
 Each new 30-minute period is
compared against a six-week
average for that day and time
 If the new value is outside
user-selectable tolerances
(typically +/- 30%), an alarm is
sent to operations personnel
• By SMS or pager
 The tolerance values can be
adjusted to produce
reasonable numbers of alarms
• Typically 20-40 alarms per
day
August, 2013
Historic Performance Data and Automatic Alarming
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
S M TWT F S S M TWT F S S M TWT F S S M TWT F S S M TWT F S S M TWT F S S M TWT F S
TOO LOW
+30%
NORMAL
TOO HIGH
+30%
+30%
-30%
-30%
6-week average
-30%
If an important performance statistic varies
outside a user-specified range, an alarm message
is sent automatically to the performance specialist
responsible for that base station.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 165
Course RF200
Introduction to
Optimization Tools
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 166
Introduction To CDMA Field Tools: Topics
 Two Important Concepts
• The Department Store Analogy - Tops-Down vs. Bottoms-Up
• The Aeronautical Analogy - Accident Investigation Resources
 Survey of CDMA Field Tools
• Mobile Tools
• Handsets - Maintenance Displays
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 167
Department Store Analogy: Tops-Down, Bottoms-Up
Management
Test Shopper
Profits
Capital
Complex!!!
Simpler
Stocking
System
Phone
Administration
Transmission
Switch CBSC
Complex!!!
Configuration
Simpler
BTS
Field Tools
Some things are easier to measure from the customer side!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 168
Aeronautical Analogy: Tools for Problem Investigation
Control & Parameters
11500
114.50
118.25
130.75
Messaging
11500
Aeronautical
Case
Flight Data Recorder
Cockpit Voice Recorder
CDMA Case
BTS
Temporal Analyzer Data
Layer 3 Message Files
To study the cause of an aeronautical accident, we try to recover the Flight Data
Recorder and the Cockpit Voice Recorder.
To study the cause of a CDMA call processing accident, we review data from the
Temporal Analyzer and the Layer 3 Message Files -- for the same reasons.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 169
Sources of CDMA Data and Tools for Processing
HANDSET
CDMA NETWORK EQUIPMENT
Switch
SLM
CM
Switch Data
LPP
ENETlogs
LPP
pegs,
DMS-BUS
DTCs
CBSC
GPSR
TFU1
CDSU
CDSU
SBS
IOC
Vocoders
Selectors
Various
External
Analysis
Tools
BTS
IS-95/J-STD-8
Messages
GPSR
BSM
CDSU
CDSU
CDSU
CDSU
CDSU
CDSU
DISCO 1
DISCO
2
System
CDSU
Ch. Card
DISCO
TFU1
ACC

Internal Messages
Txcvr B
Txcvr A RFFE A


RFFE B
Txcvr C RFFE C
IS-95/J-STD-008 Messages
Unix-based,
PC-based
Data Analysis
Post-Processing
Tools
Handset
Messages
PC-based
Mobile Data
Capture Tools
PC-based
Mobile Data
Post-Processing
Tools
 CDMA optimization data flows from three places:
• Switch
• CDMA peripherals (CBSC & BTS)
• Handset
 Each stream of data has a family of software and hardware tools for
collection and analysis
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 170
Autonomous Data Collection
By Stowaway Mobiles
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 171
Stowaway Mobiles
 Some operators are using “stowaway” mobiles in courier vehicles
or public transport (under agreement, of course)
 A typical installation includes:
• a commercial data collection device by a manufacturer such as
ZKcelltest
• two attached phones, one for collection and one as a modem
• a PN scanner
• a GPS receiver
 The data collection begins anytime the vehicle is driven
 Collected data is uploaded to a server on the system
 The central server also provides post-processing functions via a
web interface, allowing remote users to examine data for their
areas
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 172
Autonomous Data Collection
By Subscriber Handsets
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 173
Using Autonomous Collection
Collection Server
•software download
•collected data upload
•data management, analysis
BTS
PDSN/Foreign Agent
BTS
Backbone
Internet
Network
T SECURE TUNNELS T
VPNs
PDSN Authentication
Authorization
R-P Interface
Home Agent Accounting AAA
BTS
PSTN
t1
Switch
t1 v
SEL
t1
(C)BSC/Access Manager BTS
 A Server downloads software to a large population of subscriber mobiles
 Mobiles collect on custom profiles
• all or groups of mobiles can be enabled/disabled
• new triggers can be rapidly developed and downloaded when desired
 Mobiles upload compacted packets to server driven by custom triggers
• may be immediately if needed, or at low-traffic pre-programmed times
• collected data can include location/GPS/call event/L3
messaging/timestamps/etc.
 Server manages data, provides filtering and reporting
 Performance optimizers use terminals and post-processing software
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 174
Advantages of Autonomous Collection
 Mobile-reported data can be
location-binned
• post-processing provides
visual identification of problem
areas
 Collection can be rapidly enabled
per cell or area for immediate
investigation of problem reports
 Requires less employee drive time
for collection
 Customer mobiles cover area
more densely than drivetesters
 Customer mobiles include inbuilding populations
 Individual mobile identification can
be included with customer
permission for direct customer
service interaction
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 175
Current Issues in Autonomous Collection
Collection Server
•software download
•collected data upload
•data management, analysis
BTS
PDSN/Foreign Agent
BTS
Backbone
Internet
Network
T SECURE TUNNELS T
VPNs
PDSN Authentication
Authorization
R-P Interface
Home Agent Accounting AAA
BTS
PSTN
t1
Switch
t1 v
SEL
t1
(C)BSC/Access Manager BTS
 Requires extensive software capability to develop/manage
• current progress is from specialty application consulting houses
 Requires cooperation of handset vendor to effectively integrate software
onto handset platform
• caution required to avoid negative call processing side-effects
 Privacy issues involved if any user-specific data tracking
 Additional network capacity required for large-scale reporting
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 176
Conventional
CDMA Field Tools
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 177
Agilent Drive-Test Tools
 Agilent offers Drive-Test tools
• Serial interfaces for up to four
CDMA phones
• A very flexible digital receiver
with several modes
 PN Scanner
• Fast, GPS-locked, can scan
two carrier frequencies
 Spectrum Analyzer
• Can scan entire 800 or 1900
mHz. Bands
 Base-Station Over-Air Tester
(BOAT)
• Can display all walsh channel
activity on a specific sector
• Useful for identifying hardware
problems, monitoring
instantaneous traffic levels, etc.
 Post-Processing tool: OPAS32
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 178
IS-95 Busy Sector
Snapshot of Walsh Usage
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 179
1xRTT Busy Sector
Walsh Code Usage
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 180
PN Scanners
 Why PN scanners? Because phones can’t
scan remaining set fast enough, miss
transient interfering signals
 Berkeley Varitronics
• high-resolution, GPS-locked
– full-PN scan speed 26-2/3 ms.
• 2048 parallel processors for very fast
detection of transient interferors
 Agilent (formerly Hewlett-Packard)
• high resolution, GPS-locked
– full-PN scan speed 1.2 sec.
• Integrated with spectrum analyzer and
phone call-processing tool
 Andrew
• lower-cost, low-end solution
– full-PN scan speed 6.3 sec.
• integrated with phone & call-processing
data collection tool
• high-end version also available using
Berkeley Scanner
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 181
Post-Processing Tools
Windcatcher
Analyzer
Interpreter
Post-Processing tools display drive-test files for detailed
analysis - Faster, more effective than studying data
playback with collection tools alone
 Actix Analyzer
• Imports/analyzes data from almost every brand of
drive-test collection tool
 Andrew (formerly Grayson) Interpreter
• Imports/analyzes data from Andrew Invex3G
 Nortel RF Optimizer
• Can merge/analyze drive-test and Nortel CDMA
system data
 Xceed Technologies Windcatcher
• Imports/analyzes data from almost every brand of
drive-test device
 Xceed Technologies Vortex
• Provides automated analysis of data from manual,
autonomous, and stand-alone sources
 Verizon/Airtouch internal tool “DataPro”
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
Vortex
RF200 - 182
Drive-Testing
Some General Guidelines
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 183
Safety Considerations
 Don’t worry for the company’s loss due to your accidental death
• Qualified and eager replacements have resumes on file
• We’re constantly buying more drive-test vehicles
• We were going to replace that old drive-test equipment soon
• We’re not really sure we needed your last drive test, anyway
• Your death will serve as a warning to others, so it’s not in vain
 It’s OK to be careful and continue living for your own sake if you wish!
 Always start and stop drive test file collection in a safe place off the road
and out of traffic patterns
• Set up a graph window, message window, etc., whose motion can
provide a quick-glance visual reassurance that collection is running OK
 While on the road, do not attempt to start or stop files, open or close
windows, or review results - just glance occasionally for signs of activity
 If the PC freezes, the power cord pops out, or any other problem occurs
while collecting, don’t try to deal with it or correct it while driving
• Just pull over to the next really safe place to assess and correct
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 184
Physical Considerations
 Be sure the connections (power, phone, PC and GPS cables) are
secure so they won’t dislodge during collection and distract you
 Be sure the equipment is physically restrained so it won’t go flying
around and hit you in case of a panic stop or sudden swerve
 Some GPS antennas are not weatherproof. Try to avoid getting
them drenched in heavy rain
 The GPS antennas should be mounted where they have a view of
the sky as unobstructed as possible
 External PCS or Cellular antennas should not be mounted closer
than about 1 foot to each other or to GPS antennas to ensure
there is no significant electromagnetic interference or pattern
distortion
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 185
Operational Concerns
 The ideal length for drive-test files is 30 minutes to an hour
• You’d hate to lose bigger files in case the PC locks up!
• Larger files are a hassle to move around, load, and analyze
• When interesting call processing events occur, it’s nice if they are in
small files that can be easily processed and stored
 Always make sure you have at least 2 or 3 GB of free hard drive space
before you start a new drive-test collection
• Don’t open other programs while collecting data - they can tie up all
your free space in swap files and cause a crash
• Check your hard drive for errors and defragment it every week or so if
you’re collecting and transferring big files
 Don’t retrace large parts of your travel path during a drive-test run
• It’s harder to distinguish what happened on each run when analyzing
drives that cruise the same road multiple times
 Always stop the test call before you stop recording -- otherwise, postprocessing software may misinterpret calling events
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 186
Getting Location Data into Drive-Test Files
 In order to be able to build maps from drive-test data, location
information must be imbedded in the data files while they are
collected in the field. Several methods for obtaining location data
have been popular:
 GPS Global Positioning System
• This is the least expensive and most popular source of location
information for drive-testing since 1992
 Stored Vector Maps and position-recognition software
• Commercial products take raw vehicle distance and direction
data and match it to a stored road database to deduce location
• Bosch TravelPilot and other tools used this method
• More expensive and troublesome than GPS, not popular today
 LORAN
• MF Loran transmissions are only reliable in some coastal areas
and are being phased out
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 187
GPS Basics
 GPS (Global Positioning System) was funded and implemented by the US
military and serves both civilian and military users
• approved military users use a high precision signal (“C/A”)
• civilian users use a lower-precision component of the signal
• GPS signals are spread-spectrum at 1.545 and 1.2 GHz.
 Other Global Navigation Systems:
• Europe: Galileo (not yet launched)
• Russia: GLONASS (in poor repair)
 GPS uses 21 active satellites and 3 parked spares, all in mid-level orbits
at about 10,000 KM
• Hour-by-hour, 5 to 7 satellites are usually in view anywhere
• Reception of four satellites is enough to fix determine location
• Three satellites are enough if user’s elevation already known
• GPS reception is often blocked in cities, under bridges, dense forests,
or wherever obstacles interrupt the signal path
 Dead Reckoning is a method of supplementing GPS with independent
location information when GPS can’t be received
 Differential GPS is a technique adding independent corrections to
received GPS data for better accuracy. GPS civilian accuracy was
improved in May, 2000. DGPS hasn’t been widely used since then
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 188
Dead-Reckoning Systems
 Dead-reckoning systems normally use a combination of magnetic
compass and wheel rotation sensors to augment GPS
 The manufacturer’s instructions should be followed for installation.
Major factors requiring attention are:
• If used, Wheel sensors must be securely mounted to prevent
accidental breakaway while driving (major injury hazard)
• Magnetic compasses should be located as far as possible from
magnetic field sources in or on the vehicle
– example: mag-mount antennas
– (experimentation is often required)
• Calibration by actual test is required to achieve workable
accuracy for dead-reckoning systems
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 189
Drive-Tests: Phones
Maintenance Features of
CDMA Handsets
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 190
Handsets as Tools: Simple but always Available!
http://www.wpsantennas.com/pdf/testmode/FieldTestModes.pdf
 Most CDMA handsets provide some form of maintenance display (“Debug
Mode”) as well as instrumentation access
• all CDMA drive-test tools use handsets as their “front-ends”
Using the handset as a manual tool without Commercial Test Tools:
 Enter the maintenance mode by special sequence of keystrokes
 Displayed Parameters
• PN Offset, Handset Mode, Received RF Level , Transmit Gain Adjust
 Maintenance Display Applications
• best serving cell/sector
• simple call debugging (symptoms of weak RF, forward link
interference, etc.)
 Handset Limitations during manual observation
• no memory: real-time observations only; no access to messages or
call details; serving PN offset not updated during voice calls
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 191
RF200
Multi-Carrier Operation
and Its Complications
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 192
A CDMA network with 5 carriers
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 193
It’s A
Multi-Carrier/Multi-System/Multi-Manufacturer
World!
 Systems are forced to use multiple carriers to achieve needed traffic
capacity
• It’s important that the traffic load be divided between carriers
 Physically adjacent friendly systems often desire to allow seamless mobile
operation across their borders, although they use different carrier
frequencies
 Even within one large network, seamless mobile operation is desired
across serving switch boundaries
 These situations are not completely solved in the original IS-95 CDMA
vision, so additional standards documents and additional proprietary
processes provide the needed functionality
• IS-95: hashing or GSRMs can distribute idle mobiles among carriers
• IS-41 - provides intersystem handoffs and call delivery
• Proprietary algorithms can distribute in-call traffic among carriers
• RF tricks and network proprietary algorithms can support inter-carrier
handoff
 Multi-Carrier Operation is a complex sport
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 194
Transitions at System Boundaries
IDLE
IDLE
IN-CALL
IN-CALL
 Boundary types
• between different operators
– same frequency, different frequency, even different band
• between different BSCs or Switches of Same Operator
– same frequency, different frequency, even different band
• between different carriers where number of carriers changes
– same frequency, different frequency, even different band!
 A reliable transition method must be planned for users in all
circumstances
• all directions of approach
• all modes of operation (idle, active voice call, dormant data session,
active data session)
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 195
Foundation for Transition Troubleshooting
 Multi-carrier and intersystem boundary transitions are complex
relationships between mobile, air interface, and system
• to solve problems, it’s necessary to understand the basic actions of
mobile and the system
– this information comes from the standard, summarized in the next
few slides
 The mobile’s actions are generic, defined by the standards, and
simpler/more specific than the steps taken by the system
• A thorough knowledge of the mobile side is the easiest-to-get
resource for general troubleshooting of problems
 For in-call transition troubleshooting, the system’s generic and proprietary
algorithms must also be understood
• artificial proprietary trigger mechanisms and internal system order
communications and IS-41 implementation
– this information comes from manufacturer documentation
• trunking and networking between adjoining systems
– this information comes from operator’s own network design
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 196
The Mobile View:
When Do I Change Frequencies?
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 197
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Finding the System
Idle Mode
Call Start
In-Call Operation
 There are many situations where a mobile should change
frequency
• Finding a new system when turning on in a new location
• Crossing a boundary and entering a new system when in idle
mode
• Beginning a call on a sector that has more than one carrier
• Crossing a boundary and entering a new system when in a call
 Fortunately, there are defined triggers for all of these situations
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 198
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Finding the System
MRU
1025
650
25
125
250
175
384
100
375
675
625
825
PRL
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
Start at top
Of MRU and
Check until Look up found
A signal is Signal in PRL
found
And try to climb
To more preferred
Signal if available
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 199
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Idle Mode
Channel List Message
50, 125, 175
Hash and go!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 200
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Idle Mode
Global Service
Redirection Message
ACCOLC:1111100000100000
GO TO CH. 225
If your ACCOLC is ON,
Go where they tell you!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 201
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Idle Mode
Neighbor List Message
F1 PN240
F1 PN168
F1 PN336
F1 PN500
F1 PN372
F1 PN232
F2 PN240
F2 PN272
F3 PN240
F2 PN474
Check neighbors on
Other frequencies during
Unused paging slots.
If stronger than current
Active, do idle mode
Handoff to new frequencuy
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 202
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Idle Mode
Channel List Message
50, 125, 175
Hash and go!
Global Service
Redirection Message
ACCOLC:1111100000100000
GO TO CH. 225
If your ACCOLC is ON,
Go where they tell you!
Neighbor List Message
F1 PN240
F1 PN168
F1 PN336
F1 PN500
F1 PN372
F1 PN232
F2 PN240
F2 PN272
F3 PN240
F2 PN474
Check neighbors on
Other frequencies during
Unused paging slots.
If stronger than current
Active, do idle mode
Handoff to new frequencuy
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 203
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Call Start
Getting Started:
Mobile sends
Page Response or
Origination Message
System evaluates
Present loading on
Each carrier and
Prepares a traffic
Channel on the
Carrier it prefers.
System sends channel
Assignment message
To the mobile
Mobile goes to the
Frequency it is told
Nortel: MCTA
Lucent: Pooling
Motorola: Pooling
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 204
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
In-Call Operation
NORMAL SOFT HANDOFFS
Mobile monitors pilots
And sends PSMM to
Request handoffs
When it desires
No Frequency Changes
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 205
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
In-Call Operation
HARD HANDOFFS
Mobile cannot see signals
On other frequencies.
System must use special
“traps” to trigger
And decide handoffs:
Pilot Beacons
PILOT
DATABASE
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 206
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
In-Call Operation
HARD HANDOFFS
Mobile cannot see signals
On other frequencies.
System must use special
“traps” to trigger
And decide handoffs:
Round-Trip Delay, or
Ec/Io and Quality Triggers
Border Cells
RTD rings
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 207
A
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
In-Call Operation
NORMAL SOFT HANDOFFS
Mobile monitors pilots
And sends PSMM to
Request handoffs
When it desires
HARD HANDOFFS
Mobile cannot see signals
On other frequencies.
System must use special
“traps” to trigger
And decide handoffs:
Pilot Beacons
PILOT
DATABASE
Round-Trip Delay, or
Ec/Io and Quality Triggers
Border Cells
RTD rings
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 208
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
Finding the System
Idle Mode
Channel List Message
MRU
1025
650
25
125
250
175
384
100
375
675
625
825
PRL
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
XXX
Start at top
Of MRU and
Check until Look up found
A signal is Signal in PRL
found
And try to climb
To more preferred
Signal if available
50, 125, 175
Hash and go!
Global Service
Redirection Message
ACCOLC:1111100000100000
GO TO CH. 225
If your ACCOLC is ON,
Go where they tell you!
Neighbor List Message
F1 PN240
F1 PN168
F1 PN336
F1 PN500
F1 PN372
F1 PN232
F2 PN240
F2 PN272
F3 PN240
F2 PN474
Check neighbors on
Other frequencies during
Unused paging slots.
If stronger than current
Active, do idle mode
Handoff to new frequencuy
August, 2013
Call Start
Getting Started:
Mobile sends
Page Response or
Origination Message
System evaluates
Present loading on
Each carrier and
Prepares a traffic
Channel on the
Carrier it prefers.
System sends channel
Assignment message
To the mobile
Mobile goes to the
Frequency it is told
Nortel: MCTA
Lucent: Pooling
Motorola: Pooling
RF200 v8.0 (c) 2013 Scott Baxter
In-Call Operation
NORMAL SOFT HANDOFFS
Mobile monitors pilots
And sends PSMM to
Request handoffs
When it desires
HARD HANDOFFS
Mobile cannot see signals
On other frequencies.
System must use special
“traps” to trigger
And decide handoffs:
Pilot Beacons
PILOT
DATABASE
Round-Trip Delay, or
Ec/Io and Quality Triggers
Border Cells
RTD rings
RF200 - 209
Hard Handoffs
 Soft Handoff is the preferred mode in CDMA. Its diversity provides
excellent reliability and resistance to fading.
 Soft Handoff is possible only if all these conditions are true:
• the mobile is a one-frequency-at-a-time device, so all sectors in
handoff must be on the same carrier frequency
• on the network side, all the base stations involved must have
packet paths in backhaul to the BSC/access manager currently
being used by the mobile. If more than one BSC/access
manager is involved, special packet links are required between
them
• all new base stations being added in handoff must accept the
call using its current frame offset (rarely a concern)
 If any of these conditions cannot be met, then the handoff must be
“hard” – i.e., the mobile must give up its current links and quickly
jump to the new link or links
 Notice that if the new target sector is on a different frequency than
the mobile’s current call, the mobile will not even see its pilot and
will not know to request a handoff!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 210
Triggering Hard Handoffs in Traffic
 Hard Handoffs during a mobile’s call or data session can be
triggered by a variety of methods:
• Pilot Beacon – The mobile notices a rising pilot and sends a
Pilot Strength Measurement Message asking for handoff. The
system responds with an Extended Handoff Direction Message
with the Hard Handoff field enabled, and sending the mobile to
a different system or frequency.
• Border-Cell Special Triggers – Unknown to the mobile, it is now
using only one or more special sectors defined as “border
sectors” in the system’s databases. Special tracking is going
on, either round-trip-delay measurement or Ec/Io reporting.
When the system decides the mobile has reached the trigger
conditions, it suddenly and without warning sends an Extended
Handoff Direction Message with the Hard Handoff field
enabled, sending the mobile to a different system or frequency
– it is not unusual for the EHDM to list multiple target sectors
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 211
Hard Handoff Messaging
(Beacon Trigger)
FORWARD TRAFFIC CHANNEL
BASE STATION
ACK. ORDER
EXTENDED HANDOFF
DIRECTION MSG.
NEW FORWARD TRAFFIC CH.
BASE STATION
ACK. ORDER
NEIGHBOR LIST
UPDATE MESSAGE.
IN-TRAFFIC SYS. PARAM.
MESSAGE (OPTIONAL)
August, 2013
REVERSE TRAFFIC CHANNEL
PILOT STRENGTH MEAS.
MSG. (BEACON SEEN)
MOBILE STATION
ACK. ORDER
NEW REVERSE TRAFFIC CH.
HANDOFF COMPLETION
MESSAGE
MOBILE STATION
ACK. ORDER
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 212
Hard Handoff Messaging
(RTD Trigger)
FORWARD TRAFFIC CHANNEL
EXTENDED HANDOFF
DIRECTION MSG.
NEW FORWARD TRAFFIC CH.
BASE STATION
ACK. ORDER
NEIGHBOR LIST
UPDATE MESSAGE.
IN-TRAFFIC SYS. PARAM.
MESSAGE (OPTIONAL)
August, 2013
REVERSE TRAFFIC CHANNEL
MOBILE STATION
ACK. ORDER
NEW REVERSE TRAFFIC CH.
HANDOFF COMPLETION
MESSAGE
MOBILE STATION
ACK. ORDER
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 213
Hard Handoff in Traffic Messaging (1)
QcpCdmaLogMsgForTrafChan
11/09/2002 00:07:55
MSG_LENGTH: 17 octets
MSG_TYPE: Extended Handoff Direction Message
ACK_SEQ: 5 MSG_SEQ: 3 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
USE_TIME: Yes
ACTION_TIME: 240 ms
HDM_SEQ: 3
SEARCH_INCLUDED: Yes

SRCH_WIN_A: 130 chips
T_ADD: -9.0 dB
T_DROP: -11.0 dB
T_COMP: 2.5
T_TDROP: 2 sec
HARD_INCLUDED: Yes
FRAME_OFFSET: 5.00 ms
PRIVATE_LCM: No RESET_L2: Yes
RESET_FPC: Yes SERV_NEG_TYPE: Yes
ENCRYPT_MODE: Encryption Disabled
NOM_PWR_EXT: No
NOM_PWR: 0 dB
NUM_PREAMBLE: 7
BAND_CLASS: 800 MHz Cellular Band
CDMA_FREQ: 384
ADD_LENGTH: 0
PILOT_PN: 360
PWR_COMB_IND: No
CODE_CHAN: 48
RESERVED: 0
August, 2013
 Increasing RTD or perhaps a
PSMM with a Beacon listed has
alerted the system to the need for
the hard handoff
 The EHDM at left is sent to the
mobile
 Notice the “Hard Included” terms
like those normally seen when
setting up a traffic channel initially
 Notice also the larger Srch_Win_A
and unusually high T_Add and
T_Drop
QcpCdmaLogMsgRevTrafChan
11/09/2002 00:07:55
MSG_LENGTH: 7 octets
MSG_TYPE: Order Message
ACK_SEQ: 3 MSG_SEQ: 4 ACK_REQ: No
ENCRYPTION: Encryption Disabled
ORDER: Mobile Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets
RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 214
Hard Handoff in Traffic Messaging (2)
 The mobile acknowledges upon arrival
on the new traffic channel by sending a
Handoff Completion Message
QcpCdmaLogMsgForTrafChan 11/09/2002 00:07:56
MSG_LENGTH: 11 octets
MSG_TYPE: Neighbor List Update Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
PILOT_INC: 6
NGHBR_PN: 348 NGHBR_PN: 354 NGHBR_PN: 390
NGHBR_PN: 408 RESERVED: 0
QcpCdmaLogMsgForTrafChan 11/09/2002 00:07:56
MSG_LENGTH: 18 octets
MSG_TYPE: In-Traffic System Parameters Message
ACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
SID: 1382 NID: 5
SRCH_WIN_A: 60 chips
SRCH_WIN_N: 130 chips
SRCH_WIN_R: 320 chips
T_ADD: -14.0 dB T_DROP: -16.0 dB
T_COMP: 1.0 T_TDROP: 4 sec
NGHBR_MAX_AGE: 0 P_REV: IS-2000 Revision 0
SOFT_SLOPE: 0 ADD_INTERCEPT: 0 dB DROP_INTERCEPT: 0 dB
PACKET_ZONE_ID: Base Station Does Not Support A Packet Data
Service Zone
EXTENSION: No RESERVED: 0
August, 2013
QcpCdmaLogMsgRevTrafChan 11/09/2002 00:07:56
MSG_LENGTH: 7 octets
MSG_TYPE: Handoff Completion Message
ACK_SEQ: 7 MSG_SEQ: 0 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
LAST_HDM_SEQ: 3 PILOT_PN: 360 RESERVED: 0
 After arrival on the new
frequency and traffic channel,
the mobile is given a new
Neighbor List Update
Message
 The mobile is also given new
system parameters including
more normal search windows
and handoff parameters
appropriate to the new
environment of the mobile
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 215
f1
August, 2013
W0 Pilot
w1 Paging
wa
Data
w32 Sync
wx Traffic
wy Traffic
wz Traffic
f1
f3
W0 Pilot
wa Traffic
wb Traffic
wc Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
IS-95
IS-95
IS-95
IS-95
f2
W0 Pilot
wa Traffic
wb Traffic
wc Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
f2
1xRTT
IS-95
IS-95
f1
W0 Pilot
w1 Paging
wa Traffic
wb Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
IS-95
W0 Pilot
wa Traffic
wb Traffic
wc Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
f3
f4
W0 Pilot
wa Traffic
wb Traffic
wc Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
IS-95
IS-95
W0 Pilot
wa Traffic
wb Traffic
wc Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
Basic Multi-Carrier
Operation
W0 Pilot
w1 Paging
wa Traffic
wb Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
W0 Pilot
w1 Paging
wa Traffic
wb Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
f2
f4
W0 Pilot
w1 Paging
wa Traffic
wb Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
f3
IS-95
W0 Pilot
w1 Paging
wa Traffic
wb Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
f4
W0 Pilot
w1 Paging
wa Traffic
wb Traffic
w32 Sync
wx Traffic
wy Traffic
wz Traffic
Many Network/Carrier Configurations are Possible!
Non-originating carriers
can carry more traffic!
RF200 v8.0 (c) 2013 Scott Baxter
Some Carriers may
support 1xRTT
IS-95
RF200 - 216
RF200
1xRTT Data Introduction:
Radio Configurations,
Variable Length Walsh Codes
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 217
The Original IS-95 CDMA Code Channels
FORWARD CHANNELS
REVERSE CHANNELS
W0: PILOT
W32: SYNC
BTS
W1: PAGING
ACCESS
TRAFFIC
Wn: TRAFFIC
 Existing IS-95A/JStd-008 CDMA uses the channels above for call setup and
traffic channels – all call processing transactions use these channels
• traffic channels are 9600 bps (rate set 1) or 14400 bps (rate set 2)
 IS-2000 CDMA is backward-compatible with IS-95, but offers additional
radio configurations and additional kinds of possible channels
• These additional modes are called Radio Configurations
• IS-95 Rate Set 1 and 2 are IS-2000 Radio Configurations 1 & 2
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 218
1xRTT Code Channels, Rev. 0
REVERSE CHANNELS
FORWARD CHANNELS
F-Pilot
Same coding as IS-95B,
Backward compatible
Includes Power
Control Subchannel
F-Sync
Same coding as IS-95B,
Backward compatible
1 to 7
PAGING
Same coding as IS-95B,
Backward compatible
Access Channel
(IS-95B compatible)
Enhanced
Access Channel
0 to 8
F-BCH
0 to 3
F-QPCH
Quick Paging Channel
F-CPCCH
Common
Power Control Channel
How many 1
Possible:
1
0 to 4
BTS
0 to 7
0 to 7
Users:
0 to many
1
Broadcast Channel
F-CACH
Common
Assignment Channel
F-CCCH
Common
Control Channels
F-TRAFFIC
F-FCH
Forward
Traffic Channels
Fundamental Channel
Dedicated
Control Channel
0 or 1
F-DCCH
0 to 7
F-SCH IS-95B only Channels IS-95B only
0 to 2
F-SCH
Supplemental
Supplemental
Channels RC3,4,5
Common
Control Channel
R-Pilot 1
R-ACH or
R-EACH
1
R-CCCH 0 or 1
R-TRAFFIC
Reverse Fundamental
Channel (IS95B comp.)
Dedicated
Control Channel
Reverse
Supplemental Channel
R-FCH 1
R-DCCH 0 or 1
R-SCH 0 to 2
 No more wasteful duplication
on I and Q means the 1xRTT
signal can hold about twice
as much information. The
extra capacity can allow
more voice users, or new
faster data transmission.
See Course 332 for more details.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 219
Spreading Rates & Radio Configurations
Spreading
Rate
SR1
1xRTT
1 carrier
1.2288
MCPS
SR3
3xRTT
Fwd:
3 carriers
1.2288
MCPS
Rev:
3.6864
MCPS
Radio
Configuration
Forward Link
Data
Rates
Data
Rates
Radio
Configuration
Reverse Link
Required. IS-95B Compatible
No CDMA2000 coding features
RC1
9600
9600
RC1
Required. IS-95B Compatible
No CDMA2000 coding features
Compatible with IS-95B RS2
No CDMA2000 coding features
RC2
14400
14400
RC2
Compatible with IS-95B RS2
No CDMA2000 coding features
Quarter-rate convolutional or
Turbo Coding, base rate 9600
RC3
Half-rate convolutional or
Turbo Coding, base rate 9600
RC4
Quarter-rate convolutional or
Turbo Coding, base rate 14400
RC5
1/6 rate convolutional
or Turbo coding, base rate 9600
RC6
Required. 1/3 rate convolutional
or Turbo coding, base rate 9600
RC7
¼ or 1/3 rate convolutional or
Turbo coding, base rate 14400
RC8
½ or 1/3 rate convolutional or
Turbo encoder, base rate 14400
August, 2013
RC9
9600
153600
9600
153600
307200
307200
14400
14400
230400
230400
9600
307200
9600
614400
14400
460800
14400
1036800
RC3
Quarter rate convolutional or
Turbo coding; Half rate
convolutional or Turbo coding;
base rate 9600
RC4
Quarter rate convolutional or
Turbo Coding, base rate 14400
RC5
Required. ¼ or 1/3 convolutional
or Turbo coding, base rate 9600
RC6
¼ or ½ convolutional or Turbo
encoding, base rate 14400
9600
9600
307200
614400
14400
460800
1036800
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 220
1xRTT Busy Sector
Walsh Code Usage
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 221
1xRTT Data Operation
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 222
1xRTT Data Call States
 IS-95 CDMA channels and structure were conceived to provide
circuit-switched voice service. Typical “hold time” of a voice call is
roughly two minutes.
 1xRTT packet data traffic comes in many types, ranging from very
bursty scattered packets to heavy almost-continuous data flows
when large files are involved
 If steady code channels were assigned to data users for their
entire sessions, the capacity of the system would be largely
wasted during the periods when a user transmits no data
 The Media Access Control layer of the 1xRTT protocol stack
manages the use of the air interface, defining several states for
user sessions and managing the transitions between states based
on user activity and quality of service (QOS) concerns.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 223
Current and Future 1xRTT Call States
Active
Initialization
Traffic channel
Exists
Service Option
Connected
Control Channel
Exists
T_active or
Release
Control Channel
exists
Control Hold
(DCCH)
Packet Service Packet Service
Request
Deactivated
Suspended
T_suspend
T_hold
PPP Terminated
Release Sent!
Service Option
Connected
Control Channel Exists
Have New Data
to send!
Null
Reconnect
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
Dormant
PPP Terminated
Release Sent!
RF200 - 224
MAC States Implemented in 1xRTT Phase 0
IP
Session
Internet
VPNs
Selector/
Channel
PPP
Svc Cfg (RLP)
Element
T
PDSN
Home Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
(C)BSC/
Access Manager
T
PDSN/
Foreign BTS
Agent
R-P Interface
SEL
t1
CE
Dormant
timer
exceeded
T
PDSN
Home Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
(C)BSC/
Access Manager
August, 2013
F-TRAFFIC
F-FCH
ACTIVE
F-SCH
exit timer:
a few seconds
SCH driven
by traffic
Mobile has
data for
System
T
PDSN/
Foreign BTS
Agent
R-P Interface
SEL
R-TRAFFIC
R-FCH
R-SCH
SCH driven
by traffic
System has
data for
Mobile
Origination
Release
Normal
Internet
VPNs
State
General
Page
Page
Response
PAGING
DORMANT
R-ACH
exit timer: minutes, hours
between data bursts
t1
RF200 v8.0 (c) 2013 Scott Baxter
intermittent
RF200 - 225
Mobile-Originated Packet Data Call Flow
PAGING CHANNEL
ACCESS CHANNEL
ORIGINATION MESSAGE
BASE STATION
ACK. ORDER
PROBE INFORMATION
EXTENDED CHANNEL
ASSIGNMENT MSG
FORWARD TRAFFIC CHANNEL
REVERSE TRAFFIC CHANNEL
LAYER 2 HANDSHAKE
LAYER 2 HANDSHAKE
BASE STATION
ACK. ORDER
STATUS REQUEST
MESSAGE
SERVICE CONNECT
MESSAGE
August, 2013
MOBILE STATION
ACK. ORDER
STATUS RESPONSE
MESSAGE
SERVICE CONNECT
COMPLETE MESSAGE
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 226
Packet Session Origination Messaging (1)
 The mobile sends an
origination message
on the Access
Channel
 The Access Probe
Information record
shows the time when
the message was
sent and the power
level
22:17:59.282 QcpCdmaLogMsgAccessChan
MSG_LENGTH: 43 octets PD: P_REV_IN_USE >= 6
MSG_ID: Origination Message LAC_LENGTH: 17 octets
ACK_SEQ: 7 MSG_SEQ: 7 ACK_REQ: 1 VALID_ACK: 0 ACK_TYPE: 0
MSID_TYPE: IMSI and ESN MSID_LEN: 9 octets
ESN: D:25405233216 H:FE4FDA40 IMSI_CLASS: 0
IMSI_CLASS_0_TYPE: IMSI_S included RESERVED: 0
IMSI_S: 5402304897 AUTH_MODE: 1 AUTHU: 147354 RANDC: 120
COUNT: 0 LAC_PADDING: 0 ACTIVE_PILOT_STRENGTH: -4.50 dB
FIRST_IS_ACTIVE: Yes FIRST_IS_PTA: No NUM_ADD_PILOTS: 1
PILOT_PN_PHASE: PN:216 + 0 chips
PILOT_STRENGTH: -14.50 dB ACCESS_HO_EN: No
ACCESS_ATTEMPTED: No MOB_TERM: Yes
SLOT_CYCLE_INDEX: 2.56 MOB_P_REV: IS-2000 Revision 0
SCM: Band Class 0, Dual Mode, Slotted, Continuous, Class III
REQUEST_MODE: CDMA Only SPECIAL_SERVICE: Yes
SERVICE_OPTION: Standard: 144kbps PacketData, Internet or ISO Protocol
PM: Yes DIGIT_MODE: 4-bit DTMF Codes MORE_FIELDS: No NUM_FIELDS: 4
CHARi: # 7 7 7 NAR_AN_CAP: No
PACA_REORIG: User Directed Origination RETURN_CAUSE: Normal Access
MORE_RECORDS: No ENCRYPTION_SUPPORTED: Basic Encryption Supported
PACA_SUPPORTED: No NUM_ALT_SO: 0 DRS: Yes UZID_INCL: No
CH_IND: Fundamental Channel SR_ID: 1 OTD_SUPPORTED: No
QPCH_SUPPORTED: Yes ENHANCED_RC: Yes
FOR_RC_PREF: 3 REV_RC_PREF: 3 FCH_SUPPORTED: Yes
FCH_FRAME_SIZE: Supports only 20 ms Frame Sizes
FOR_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: Yes RC6: No
REV_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: No RC6: No
DCCH_SUPPORTED: No GEO_LOC_INCL: No REV_FCH_GATING_REQ: Yes RESERVED: 0
22:17:59.551 Access Probe Info
Access Probe Sequence Number: 1 Access Probe Number: 1 Access Channel Number: 0
PN Randomization delay: 0 Sequence Backoff: 0 Probe Backoff: 0
Persistence Tests Performed: 1 Rx Power: -77.9 Tx Power (Est): 4.9 Tx Gain Adjust: 0
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 227
Packet Session Origination Messaging (2)
22:17:59.782 QcpCdmaLogMsgPagingChan
MSG_LENGTH: 13 octets PD: P_REV_IN_USE < 6 MSG_TYPE: Order Message
ACK_SEQ: 7 MSG_SEQ: 0 ACK_REQ: No VALID_ACK: Yes
ADDR_TYPE: ESN ADDR_LEN: 4 octets ESN: D:25405233216 H:FE4FDA40
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
22:17:59.942 QcpCdmaLogMsgPagingChan
MSG_LENGTH: 29 octets PD: P_REV_IN_USE < 6
MSG_TYPE: Extended Channel Assignment Message
ACK_SEQ: 7 MSG_SEQ: 1 ACK_REQ: No VALID_ACK: Yes
ADDR_TYPE: ESN ADDR_LEN: 4 octets ESN: D:25405233216 H:FE4FDA40
RESERVED_1: 0 ADD_RECORD_LEN: 15 octets
ASSIGN_MODE: Extended Traffic Channel Assignment
RESERVED_2: 0 FREQ_INCL: Yes BAND_CLASS: 800 MHz Cellular Band
CDMA_FREQ: 384 BYPASS_ALERT_ANSWER: Yes
GRANTED_MODE: MS use Service Configuration of default Multiplex Option and
Transmission Rates
DEFAULT_CONFIG: Reserved FOR_RC: RC 3 REV_RC: RC 3
FRAME_OFFSET: 7.50 ms ENCRYPT_MODE: Encryption Disabled
FPC_SUBCHAN_GAIN: 0.0 dB RLGAIN_ADJ: 0 dB NUM_PILOTS: 0 Pilots
CH_IND: Fundamental Channel CH_RECORD_LEN: 7 octets
FPC_FCH_INIT_SETPT: 7.000 dB FPC_FCH_FER: 0.5% - 10% (in units of 0.5%)
FPC_FCH_MIN_SETPT: 3.000 dB FPC_FCH_MAX_SETPT: 8.000 dB
PILOT_PN: 44 ADD_PILOT_REC_INCL: No PWR_COMB_IND: No
CODE_CHAN_FCH: 33 QOF_MASK_ID_FCH: 0 3X_FCH_INFO_INCL: No
REV_FCH_GATING_MODE: No 3XFL_1XRL_INCL: No RESERVED: 0
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
 After receiving the
probe, the base station
transmits a Base Station
Acknowledgment order
on the Paging Channel
• this tells the mobile
not to transmit more
probes
 After the system sets up
the traffic channel for
the call, the Extended
Channel Assignment
Message gives the
mobile the channel
details
• Operating mode
• Band, Frequency
• Walsh Code
• Radio
Configurations
RF200 - 228
Packet Session Origination Messaging (3)
The base station is already
sending blank frames on
the forward channel,using
the assigned Walsh code.
22:18:00.491 QcpCdmaLogMsgForTrafChan
MSG_LENGTH: 8 octets
MSG_TYPE: Order Message
ACK_SEQ: 7 MSG_SEQ: 0 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
USE_TIME: No ACTION_TIME: 0 ms
ORDER: Base Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
The base station acknowledges
receiving the mobile’s preamble.
The mobile sees at least two
good blank frames in a row on
the forward channel, and
concludes this is the right traffic
channel. It starts sending good
blank frames of its own on the
reverse traffic channel.
22:18:00.509 QcpCdmaLogMsgRevTrafChan
MSG_LENGTH: 10 octets
MSG_TYPE: Pilot Strength Measurement Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled
REF_PN: 44 PILOT_STRENGTH: -5.50 dB KEEP: Yes
PILOT_PN_PHASE: PN:216 + 0 chips
PILOT_STRENGTH: -7.00 dB KEEP: Yes
RESERVED: 0
The mobile station acknowledges the base station’s acknowledgment, as part of a
Pilot Strength Measurement Message it needs to send anyway for a handoff it
wants. The fundamental channels are working, so it’s time to negotiate the service
option to be used.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 229
Packet Session Origination Messaging (4)
22:18:00.741 QcpCdmaLogMsgForTrafChan
MSG_LENGTH: 9 octets
MSG_TYPE: Status Request Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: No
ENCRYPTION: Encryption Disabled
QUAL_INFO_TYPE: None
QUAL_INFO_LEN: 0 octets NUM_FIELDS: 2
RECORD_TYPE: Channel Configuration
Capability Information
RECORD_TYPE: Reserved
 The system asks for the
mobile’s Channel
Configuration Capability
Information
August, 2013
22:18:00.875 QcpCdmaLogMsgRevTrafChan
MSG_LENGTH: 44 octets MSG_TYPE: Status Response Message
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: No ENCRYPTION: Encryption Disabled
QUAL_INFO_TYPE: None QUAL_INFO_LEN: 0 octets
RECORD_TYPE: Extended Multiplex Option Information
RECORD_LEN: 24 octets NUM_MO_FOR_FCH: 2 MO_FOR_FCH: 1
RS1_9600_FOR: RS1_4800_FOR: RS1_2400_FOR: RS1_1200_FOR:
MO_FOR_FCH: 2
RS2_14400_FOR: RS2_7200_FOR: RS2_3600_FOR: RS2_1800_FOR:
RESERVED: 0 NUM_MO_REV_FCH: 2 MO_REV_FCH: 1
RS1_9600_REV: RS1_4800_REV: RS1_2400_REV: RS1_1200_REV:
RESERVED: 0 MO_REV_FCH: 2
RS2_14400_REV: RS2_7200_REV: RS2_3600_REV: RS2_1800_REV:
RESERVED: 0 NUM_MO_FOR_DCCH: 0 NUM_MO_REV_DCCH: 0
NUM_MO_FOR_SCH: 2 FOR_SCH_ID: 0 MO_FOR_SCH: 2337
FOR_SCH_ID: 0 MO_FOR_SCH: 2081 NUM_MO_REV_SCH: 2
REV_SCH_ID: 0 MO_REV_SCH: 2321 REV_SCH_ID: 0 MO_REV_SCH: 2065
RESERVED: 0
RECORD_TYPE: Channel Configuration Capability Information
RECORD_LEN: 9 octets OTD_SUPPORTED: No FCH_SUPPORTED: Yes
FCH_FRAME_SIZE: Supports only 20 ms Frame Sizes
FOR_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: Yes RC6: No
REV_FCH_LEN: 2 RC1: Yes RC2: Yes RC3: Yes RC4: Yes RC5: No RC6: No
DCCH_SUPPORTED: No FOR_SCH_SUPPORTED: Yes FOR_SCH_LEN: 2
RC1: No RC2: No RC3: Yes RC4: Yes RC5: No RC6: No
FOR_SCH_NUM: 1 FOR_TURBO_SUPPORTED: No
FOR_CONV_SUPPORTED: Yes
FOR_MAX_CONV_BLOCK_SIZE: Rate Set 1: 3048, Rate Set 2: 4584
FOR_FRAME_40_SUPPORTED: No FOR_FRAME_80_SUPPORTED: No
FOR_MAX_RATE: 9.6 kbps or 14.4 kbps REV_SCH_SUPPORTED: Yes
REV_SCH_LEN: 1 RC1: No RC2: No RC3: Yes REV_SCH_NUM: 1
REV_TURBO_SUPPORTED: No REV_CONV_SUPPORTED: Yes
REV_MAX_CONV_BLOCK_SIZE: Rate Set 1: 3048, Rate Set 2: 4584
REV_FRAME_40_SUPPORTED: No REV_FRAME_80_SUPPORTED: No
REV_MAX_RATE: 9.6 kbps or 14.4 kbps STS_SUPPORTED: No
3X_CCH_SUPPORTED: No RESERVED: 0 RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 230
Packet Session Origination Messaging (5)
22:18:01.089 QcpCdmaLogMsgForTrafChan
MSG_LENGTH: 46 octets MSG_TYPE: Service Connect Message
ACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: No
ENCRYPTION: Encryption Disabled
USE_TIME: No ACTION_TIME: 0 ms SERV_CON_SEQ: 0
RESERVED: 0 RECORD_TYPE: Service Configuration
RECORD_LEN: 30 octets FOR_MUX_OPTION: 1 REV_MUX_OPTION: 1
RS1_9600_FOR: RS1_4800_FOR: RS1_2400_FOR: RS1_1200_FOR:
RESERVED: 0
RS1_9600_REV: RS1_4800_REV: RS1_2400_REV: RS1_1200_REV:
RESERVED: 0
NUM_CON_REC: 1 RECORD_LEN: 12 octets CON_REF: 1
SERVICE_OPTION:
Standard: 144kbps PacketData, Internet or ISO Protocol
FOR_TRAFFIC: SO Uses Primary Traffic On FTC
REV_TRAFFIC: SO Uses Primary Traffic On RTC
RESERVED: -- -- 6 65 193 178 153 76 0 134 53 2 72 72
RESERVED: 96 40 18 34 67 0 19 5 132 67 7 10 0
 The system proposes the
service connection
parameters and the mobile
accepts
22:18:01.118 QcpCdmaLogMsgRevTrafChan
MSG_LENGTH: 6 octets
MSG_TYPE: Service Connect Completion Message
ACK_SEQ: 1 MSG_SEQ: 2 ACK_REQ: Yes
ENCRYPTION: Encryption Disabled RESERVED: 0
SERV_CON_SEQ: 0 RESERVED: 0
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 231
Session Transition to Dormant State
FORWARD TRAFFIC CHANNEL
REVERSE TRAFFIC CHANNEL
NORMAL OPERATION CONTINUES,
BUT NO DATA HAS BEEN SENT
IN EITHER DIRECTION
DURING THE DORMANT TIMER PERIOD
RELEASE -- NORMAL
RELEASE – NO REASON
SYNC CHANNEL
SYNC CHANNEL MESSAGE
PAGING CHANNEL
THE MOBILE READS THE CONFIGURATION
MESSAGES. THE SYSTEM IS UNCHANGED,
SO NO NEW REGISTRATION IS NEEDED.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 232
Session Return from Dormant State
Due to Data at System
PAGING CHANNEL
ACCESS CHANNEL
GENERAL PAGE MESSAGE
PAGE RESPONSE MESSAGE
BASE STATION
ACK. ORDER
PROBE INFORMATION
CHANNEL ASSIGNMENT
MESSAGE
FORWARD FUNDAMENTAL
TRAFFIC CHANNEL
REVERSE FUNDAMENTAL
TRAFFIC CHANNEL
LAYER 2 HANDSHAKE
LAYER 2 HANDSHAKE
BASE STATION
ACK. ORDER
STATUS REQUEST
MESSAGE
SERVICE CONNECT
MESSAGE
MOBILE STATION
ACK. ORDER
STATUS RESPONSE
MESSAGE
SERVICE CONNECT
COMPLETE MESSAGE
THE DATA CALL IS BACK IN ACTIVE STATE.
NORMAL MESSAGING AND DATA TRANSFER
CONTINUE.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 233
Session Return from Dormant State
Due to Data at Mobile
PAGING CHANNEL
ACCESS CHANNEL
ORIGINATION MESSAGE
BASE STATION
ACK. ORDER
PROBE INFORMATION
CHANNEL ASSIGNMENT
MESSAGE
FORWARD FUNDAMENTAL
CHANNEL
REVERSE FUNDAMENTAL
CHANNEL
LAYER 2 HANDSHAKE
LAYER 2 HANDSHAKE
BASE STATION
ACK. ORDER
STATUS REQUEST
MESSAGE
SERVICE CONNECT
MESSAGE
MOBILE STATION
ACK. ORDER
STATUS RESPONSE
MESSAGE
SERVICE CONNECT
COMPLETE MESSAGE
THE DATA CALL IS BACK IN ACTIVE STATE.
NORMAL MESSAGING AND DATA TRANSFER
CONTINUE.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 234
PDSN/Foreign Agent
Forward Link SCH Scheduling
data
FCH or
FCH +
SCH?
R-P
Interface
Buffer
My F-SCH
Data Rate
BTS
CE
PCF SEL
t1
(C)BSC/Access Manager
BTSC
Wireless
Mobile Device
 The main bottleneck is the forward link itself: restricted by available
transmitter power and walsh codes
 Each connected data User has a buffer in the PDSN/PCF complex
• When waiting data in the buffer exceeds a threshold, the PDSN/PCF asks
the BTS for an F-SCH. Its data rate is limited by:
– Available BTS forward TX power; available walsh codes; competition
from other users who also need F-SCHs; and mobile capability
• When the buffer is nearly empty, the SCH ends; FCH alone
• Occupancy timers and other dynamic or hard-coded triggers may apply
• QOS (Quality of Service) rules also may be implemented, giving
preference to some users and some types of traffic
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 235
Forward Link Supplemental Channel Burst
FORWARD FUNDAMENTAL
TRAFFIC CHANNEL
EXTENDED SUPPL. CHAN.
ASSIGNMENT MSG.
REVERSE FUNDAMENTAL
TRAFFIC CHANNEL
MOBILE STATION
ACK. ORDER
FORWARD
SUPPLEMENTAL
CHANNEL
DATA BURST
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 236
Forward Supplemental Channel Assignment
Mobile: Watch
Walsh Code 2
Starting in 320 ms
For 1000 ms.
PN 168
BTS
W2
F-SCH
W23
F-FCH
Mobile: Watch
Walsh Code 2
Starting in 320 ms
For 1000 ms.
Supplemental
Channel Burst
ESCAM
Supplemental
Channel Burst
ESCAM
W1
PAGING KGKSAKKNKGGKSKPG
NSASPPCKGKSAKGKSAKKNKGGKSKPG
NSASPPCKGKSAKGKSAKKNKGGKSKPG
NSASPPCK
W32
SYNC SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
W0
PILOT
TIME
ACCESS CHANNEL
R-FCH
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 237
Forward Link Supplemental
Channel Burst Messaging
22:39:41.508 QcpCdmaLogMsgForTrafChan
MSG_LENGTH: 20 octets
MSG_TYPE: Extended Supplemental Channel
Assignment Message
ACK_SEQ: 7 MSG_SEQ: 0 ACK_REQ: No
ENCRYPTION: Encryption Disabled
START_TIME_UNIT: 0 ms REV_SCH_DTX_DURATION: 200 ms
USE_T_ADD_ABORT: No USE_SCRM_SEQ_NUM: No
ADD_INFO_INCL: Yes
FPC_PRI_CHAN: Forward Fundamental Channel inner loop
estimation
REV_CFG_INCLUDED: No NUM_REV_SCH: 0
FOR_CFG_INCLUDED: Yes FOR_SCH_FER_REP: Yes
NUM_FOR_CFG_RECS: 0 FOR_SCH_ID: 0 SCCL_INDEX: 0
FOR_SCH_NUM_BITS_IDX: RC 1,3,4,6,7=744; RC 2,5,8,9=1128;
12 CRC bits
NUM_SUP_SHO: 0 PILOT_PN: 12
ADD_PILOT_REC_INCL: No CODE_CHAN_SCH: 2
QOF_MASK_ID_SCH: 0 (rot 256 bit)
NUM_FOR_SCH: 1 FOR_SCH_ID: 0
FOR_SCH_DURATION: 2560 ms
FOR_SCH_START_TIME_INCL: Yes
FOR_SCH_START_TIME: 28 SCCL_INDEX: 0
FPC_INCL: Yes FPC_MODE_SCH: 1
FPC_SCH_INIT_SETPT_OP: FPC_SCH_INIT_SETPT has Offset
value of initial F-SCH Eb/Nt setpoint
FPC_SEC_CHAN: 0 NUM_SUP: 1 SCH_ID: 0
FPC_SCH_FER: 0.5% - 10% (in units of 0.5%)
FPC_SCH_INIT_SETPT: 3.500 dB
FPC_SCH_MIN_SETPT: 2.000 dB
FPC_SCH_MAX_SETPT: 8.000 dB
FPC_THRESH_SCH_INCL: No RPC_INCL: No
3X_SCH_INFO_INCL: No CCSH_INCLUDED: No
FOR_SCH_CC_INCL: No REV_SCH_CC_INCL: No
RESERVED: 0
August, 2013
22:39:42.250, Record 224546, QcpCdmaLogMsgRevTrafChan
MSG_LENGTH: 7 octets
MSG_TYPE: Order Message
ACK_SEQ: 0 MSG_SEQ: 2 ACK_REQ: No
ENCRYPTION: Encryption Disabled
ORDER: Mobile Station Acknowledgement Order
ADD_RECORD_LEN: 0 octets RESERVED: 0
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 238
Reverse Link Supplemental Channel Burst
FORWARD FUNDAMENTAL
TRAFFIC CHANNEL
EXTENDED SUPPL. CHAN.
ASSIGNMENT MSG.
REVERSE FUNDAMENTAL
TRAFFIC CHANNEL
EXTENDED SUPPL. CHAN.
REQUEST MSG.
MOBILE STATION
ACK. ORDER
REVERSE
SUPPLEMENTAL
CHANNEL
DATA BURST
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 239
Reverse Supplemental Channel Assignment
Mobile: Send
Walsh Code 1
Starting in 320 ms
For 1000 ms.
W23
PN 168
BTS
Mobile: Send
Walsh Code 1
Starting in 320 ms
For 1000 ms.
ESCAM
F-FCH
ESCAM
W1
PAGING KGKSAKKNKGGKSKPG
NSASPPCKGKSAKGKSAKKNKGGKSKPG
NSASPPCKGKSAKGKSAKKNKGGKSKPG
NSASPPCK
W32
SYNC SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
W0
PILOT
TIME
ACCESS CHANNEL
R-FCH
SCRM
SCRM
Supplemental
Channel Burst
R-SCH
System: I need to
Send you the
Following blocks:
August, 2013
Supplemental
Channel Burst
System: I need to
Send you the
Following blocks:
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 240
Reverse Link Supplemental
Channel Burst Messaging
22:31:47.229 QcpCdmaLogMsgForTrafChan
MSG_LENGTH: 12 octets
MSG_TYPE: Extended Supplemental Channel
Assignment Message
ACK_SEQ: 7 MSG_SEQ: 4 ACK_REQ: No
ENCRYPTION: Encryption Disabled
START_TIME_UNIT: 0 ms
REV_SCH_DTX_DURATION: 200 ms
USE_T_ADD_ABORT: No USE_SCRM_SEQ_NUM: No
ADD_INFO_INCL: Yes
FPC_PRI_CHAN: Forward Fundamental Channel inner
loop estimation
REV_CFG_INCLUDED: Yes NUM_REV_CFG_RECS: 0
REV_SCH_ID: 0
REV_WALSH_ID: Forward Dedicated Control Channel
inner loop estimation
REV_SCH_NUM_BITS_IDX: RC 1,3,5=1512; RC 2,4,6=2280;
12 CRC bits
NUM_REV_SCH: 1 REV_SCH_ID: 0
REV_SCH_DURATION: Reserved
REV_SCH_START_TIME_INCL: Yes
REV_SCH_START_TIME: 30
REV_SCH_NUM_BITS_IDX: RC 1,3,5=1512; RC 2,4,6=2280;
12 CRC bits
FOR_CFG_INCLUDED: No NUM_FOR_SCH: 0
FPC_INCL: No RPC_INCL: Yes
RPC_NUM_SUP: 0 SCH_ID: 0
RLGAIN_SCH_PILOT: 1.000000 dB
3X_SCH_INFO_INCL: No
CCSH_INCLUDED: No
FOR_SCH_CC_INCL: error: 1 bit field, 0 bits available
REV_SCH_CC_INCL: error: no bits available
August, 2013
22:31:47.102 QcpCdmaLogMsgRevTrafChan
MSG_LENGTH: 17 octets
MSG_TYPE: Supplemental Channel Request Message
ACK_SEQ: 7 MSG_SEQ: 4 ACK_REQ: No
ENCRYPTION: Encryption Disabled
SIZE_OF_REQ_BLOB: 3 bytes
REQ_BLOB: 228
REQ_BLOB: 39
REQ_BLOB: 255
USE_SCRM_SEQ_NUM: No
REF_PN: 132 PILOT_STRENGTH: -3.00 dB NUM_ACT_PN: 2
ACT_PN_PHASE: PN:304 + 0 chips ACT_PILOT_STRENGTH: -14.50 dB
ACT_PN_PHASE: PN:372 + 22 chips ACT_PILOT_STRENGTH: -21.00 dB
NUM_NGHBR_PN: 0
REF_PILOT_REC_INCL: No PILOT_REC_INCL: No PILOT_REC_INCL: No
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 241
Course RF200
CDMA2000 1xRTT Data
System Performance Optimization
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 242
The Big Picture:
IP Data Environment
T
PDSN
Home Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
T
CDMA RF Environment
R-P Interface
BTS
PSTN
t1
t1
Switch
v
SEL
t1
CE
(C)BSC/Access Manager
Traditional Telephony
CDMA IOS PPP
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 1xRTT services may include both traditional circuit-switched voice and
new fast IP data connections
• A User's link is in multiple jeopardy, both radio and packet worlds
 Radio environment portion
• Problems: FER, drops, access failures, capacity woes
• Causes: mainly in the RF world, because of mainly RF problems
 Packet environment
• Problems: Setup failures, dropped connections, low throughput
• Causes: could be IP-related, or could be RF related
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 243
IP Data Environment
Internet
VPNs
PDSN/Foreign Agent
Optimization Issues
 Network Design and Configuration
• Coverage holes, excessive coverage overlap
 Call Processing Problems due to Misconfiguration
• Neighbor Lists
• Search Windows
• Power control parameters
 Physical Problems/Hardware Problems
• Mismatched multicarrier sector coverage
 Capacity Issues
• Forward and Reverse Power Control Overload
• Physical resource congestion
– Channel elements, packet pipes
– IP network congestion
 Managing A New Dimension: circuit-switched and IP traffic blend
• QoS-related competitive issues
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 244
Optimizing in Two Worlds
 Circuit-Switched Voice Traffic
• Some operators are implementing 1xRTT mainly to gain capacity for
additional voice traffic
• Their optimization techniques remain about the same as for 2G voice
networks today
– Keep network adequately dimensioned
– Control RF environment
– Monitor and manage capacity utilization
 IP Data Traffic
• Operators adding IP traffic to upgraded voice networks
• Conventional optimization techniques are still appropriate for general
RF environment and circuit-switched network performance
• New IP and QoS issues require a new optimization focus for the
blended total network
– IP performance depends on both IP and RF factors
– IP and Voice performance involve competitive tradeoffs
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 245
Managing Forward Link Sector Loading vs. Time
Sector Total TX Power or Throughput
Sector Maximum TX Power, Maximum Throughput
Packet Data Traffic
Voice Traffic
Time, Seconds
 Both voice and data traffic loads a sector, driving up transmit power
• Voice calls are typically given higher priority than data
• MAC-layer throttling holds lower-priority data sessions off until there is
enough free power available
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 246
#6 Indicator: Data Latency
IP Data Environment
T
PDSN
Home Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
T
CDMA RF Environment
R-P Interface
BTS
PSTN
t1
t1
Switch
v
SEL
t1
CE
(C)BSC/Access Manager
Traditional Telephony
CDMA IOS PPP
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 Latency can occur because of RF channel congestion or from
IP network causes
• RF overload can delay availability of supplemental channels
• IP network congestion can delay availability of packets
 Ping and loopback tests with local PDSN and servers can
identify whether problem is in backbone network
 Does latency correlate with independent evidence of RF
congestion?
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 247
IP Data Environment
Internet
VPNs
PDSN/Foreign Agent
#7 Indicator: Data Throughput
IP Data Environment
T
PDSN
Home Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
T
CDMA RF Environment
R-P Interface
BTS
PSTN
t1
t1
Switch
v
SEL
t1
CE
(C)BSC/Access Manager
Traditional Telephony
CDMA IOS PPP
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 Throughput can be limited by RF and IP causes
• Traditional RF problems limit capacity of the channel
• Congestion in the IP network can limit speed of data available
 Does low throughput correlate with independent RF indicators?
 Does low throughput correlate with independent IP pings and tests?
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 248
IP Data Environment
Internet
VPNs
PDSN/Foreign Agent
Course RF200
Data Flow Management:
MAC/LAC Layer Operation
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 249
PDSN/Foreign Agent
Forward Link SCH Scheduling
data
FCH or
FCH +
SCH?
R-P
Interface
Buffer
My F-SCH
Data Rate
BTS
CE
PCF SEL
t1
(C)BSC/Access Manager
BTSC
Wireless
Mobile Device
 The main bottleneck is the forward link itself: restricted by available
transmitter power and walsh codes
 Each connected data User has a buffer in the PDSN/PCF complex
• When waiting data in the buffer exceeds a threshold, the PDSN/PCF asks
the BTS for an F-SCH. Its data rate is limited by:
– Available BTS forward TX power; available walsh codes; competition
from other users who also need F-SCHs; and mobile capability
• When the buffer is nearly empty, the SCH ends; FCH alone
• Occupancy timers and other dynamic or hard-coded triggers may apply
• QOS (Quality of Service) rules also may be implemented, giving
preference to some users and some types of traffic
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 250
Forward Link Events in a Typical User Session
Data volume in PDSN
buffer triggers SCH
assignment. SCH rate is
driven by amount of
data in buffer and
available TX power
sector can allocate.
Data volume
in buffer low,
SCH released.
Data flow
continues on
FCH until
complete.
Data volume in PDSN
buffer triggers SCH
assignment. SCH rate is
driven by amount of
data in buffer and
available TX power
sector can allocate.
Data volume in buffer
low, SCH released.
Flow continues on FCH.
153.6
Data Rate, kbps
Data volume in PDSN
buffer triggers SCH
assignment. SCH rate is
driven by amount of
data in buffer and
available TX power
sector can allocate.
76.8
Active
timer
runs out!
FCH drops.
Session is
dormant.
38.4
19.2
9.6
Act
Susp
Init
CHld
Dorm
Null
Rcon
Data volume
in buffer low,
SCH released.
Data flow
continues on
FCH until
complete.
No data,
FCH idle,
1200 bps
Mobile
ends
session.
TA
1.2
0
STATE
Session begins.
No data, FCH
idle, 1200 bps
Data in PDSN
buffer. Data
flow begins
on FCH
August, 2013
FCH
idle
1200
bps
No data,
FCH idle,
1200 bps
Data in PDSN
buffer. Data
flow begins
on FCH
QOS algorithm
gives SCH to
another user
briefly. Data
meanwhile
flows on FCH.
No data,
FCH idle,
1200 bps
Data in PDSN
buffer. Data
flow begins
on FCH
RF200 v8.0 (c) 2013 Scott Baxter
Channel Legend:
FundamentalSupplemental
Idle
Data
Data
RF200 - 251
Course RF200
1x Data Tests and Optimization
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 252
So S L O W ! !
IP Data Environment
T
PDSN
Home Agent
PDSN/Foreign Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
T
CDMA RF Environment
R-P Interface
BTS
PSTN
t1
t1
Switch
Traditional Telephony
v SEL
t1
(C)BSC/Access Manager
CDMA IOS PPP
CE
IP Data Environment
Internet
VPNs
Where’s My Data?!!
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 Some sessions are tormented by long latency and slow throughput
 Where is the problem? Anywhere between user and distant host:
• Is the mobile user’s data device mis-configured and/or congested?
• Is the BTS congested, with no power available to produce an SCH?
• Poor RF environment, causing low rates and packet retransmission?
• Congestion in the local IP network (PCU, R-P, PDSN FA)?
• Congestion in the wireless operator’s backbone (‘OSSN’) network?
• Congestion in the PDSN HA?
• Congestion in the outside-world internet or Private IP network?
• Is the distant host congested, with long response times?
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 253
Finding Causes of Latency and Low Throughput
Test
Server
IP Data Environment
Internet
VPNs
T
PDSN
Home Agent
Test
Server
PDSN/Foreign Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
T
CDMA RF Environment
R-P Interface
BTS
PSTN
t1
t1
Switch
Traditional Telephony
v SEL
t1
(C)BSC/Access Manager
CDMA IOS PPP
CE
IP Data Environment
Test
Server
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 IP network performance can be measured using test servers
 Problems between mobile a local test server? The problem is local
• check RF conditions, stats: poor environment, SCH blocking?
• if the RF is clean, investigate BSC/PCU/R-P/PDSN-FA
 Local results OK, problems accessing test server at PDSN-HA?
• problem is narrowed to backbone network, or PDSN-HA
 Results OK even through test server at PDSN-HA
• then the problem is in the public layers beyond.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 254
Overview of Field Tool IP Test Activities
Application
Description
Purpose
Raw Upload
Uploads data with no overhead (no headers, no
handshaking beyond the normal TCP handshaking)
Testing uplink throughput
Raw Download
Downloads data with no overhead (no headers, no
handshaking beyond the normal TCP handshaking.)
Testing downlink throughput
Raw Loopback
A loopback (data is sent to the remote server which
returns the same data) application with no overhead (no
headers, no handshaking beyond the normal TCP
handshaking.)
Simultaneous exercise of the uplink and downlink
Ping (ICMP ECHO)
Ping does not use the TCP protocol, but rather uses the
connectionless and “unreliable” ICMP protocol. Sends
small echo request packets to a remote server, which
responds with an echo reply.
Determining round-trip-time between the user and the
remote server, as well as general link integrity (by
counting the number of missing echo reply packets).
A standard web page “browse” request.
If Raw Download is unavailable, testing downlink
throughput; modeling typical customer use.
A web-based upload (similar to how web-based email
sites allow users to upload files as “attachments”).
If Raw Upload is unavailable, testing uplink throughput.
FTP GET
A standard FTP file download. Many file downloads on
the Internet use FTP.
If Raw Download and HTTP GET are unavailable, testing
downlink throughput; modeling typical customer use.
FTP PUT
A FTP file upload. The file is generated by the Invex3G
platform and sent to the server.
If Raw Upload and HTTP POST are unavailable, testing
uplink throughput
Mail GET (POP3)
Retrieves all the mail for a given mailbox (e-mail
address) from an e-mail server. Note: does not delete
the e-mail messages from the mailbox.
Modeling typical customer use.
Waits a specified amount of time.
Testing idle timers, timeouts, etc.
HTTP GET
HTTP POST
Wait
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 255
Watching Throughput in Real-Time
 This display shows the relationship between instantaneous throughputs of
six protocols at various levels in the stack
• a useful for identifying real-time problems by their “signatures”
Courtesy of Grayson Wireless from their “Invex3G” data collection tool
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 256
Protocol Stack Message Tracing
 Some collection tools can
display and track messages
between layers of the
protocol stack
• PAP, HDLC, IPCP, TCP,
IP
 This allows detailed
troubleshooting of connection
and TCP/IP transfer problems
• Capability of seeing
packet header contents is
useful for identifying and
debugging authentication
and connection problems
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 257
Course RF200
Applied Optimization
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 258
Starting Optimization of a System
 RF Coverage Control
• try to contain each sector’s coverage, avoiding gross spillover
into other sectors
• tools: PN Plots, Handoff State Plots, Mobile TX plots
 Neighbor List Tuning
• try to groom each sector’s neighbors to only those necessary
but be alert to special needs due to topography and traffic
• tools: PSMM data from mobiles; propagation prediction
 Search Window Settings
• find best settings for SRCH_WIN_A, _N, _R
• especially optimize SRCH_WIN_A per sector using collected
finger separation data; has major impact on pilot search speed
 Access Failures, Dropped Call Analysis
• finally, iterative corrections until within numerical goals
Getting these items into shape provides a solid baseline and foundation from
which future performance issues can be addressed.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 259
Performance Monitoring/Growth Management
 Benchmark Existing Performance
• Dropped Call %, Access Failure %, traffic levels
 Identify Problem Cells and Clusters
• weigh cells and clusters against one another
 Look for signs of Overload
• TCE or Walsh minutes -- excessive ? Soft handoff excessive?
• Required number of channel elements -- excessive?
• Forward Power Overloads: Originations, Handoffs blocked
 Traffic Trending and Projection
• track busy-hour traffic on each sector; predict exhaustion
• develop plan for expansion and capacity relief
– split cells, multi-sector expansions, multiple carriers
These steps must be continuously applied to guide needed growth.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 260
CDMA Problems, Causes, and Cures
PROBLEMS
 Excessive Access Failures
 Excessive Dropped Calls
 Forward Link Interference
 Slow Handoff
 Handoff Pilot Search Window Issues
 PN Planning Considerations
 Excessive Soft Handoff
 Grooming Neighbor Lists
 Software Bugs, Protocol Violations
EXAMPLES
 Normal Call
 Dropped Call - Coverage
 Dropped Call - Neighbor List
 Dropped Call - Search Window
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 261
Troubleshooting Access Failures
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 262
Investigating Access Failures
An access attempt failure can occur at
any point in the process:
 Access probes exhausted (not received
by system)
 Access probes exhausted (seen by
system but ACK not reaching mobile
station)
 Ack received by mobile station but
Channel Assignment Message not seen
 Channel Assignment Message seen at
mobile but mobile station does not
acquire Forward Traffic Channel
 Mobile station acquires Forward Traffic
Channel but system does not acquire
Reverse Traffic Channel
 System acquires Reverse Traffic
Channel but Service Connect Message
is not seen at mobile station.
Successful Access Attempt
Origination Msg
ACCESS
MS
Probing
BTS
PAGING Base Sta. Acknlgmt. Order
FW TFC TFC frames of 000s
PAGING
Channel Assnmt. Msg.
TFC preamble of 000s
FW FC
RV TFC
Base Sta. Acknlgmt. Order
Mobile Sta. Ackngmt. Order RV TFC
FW TFC
Service Connect Msg.
Svc. Connect Complete Msg
FW TFC Base Sta. Acknlgmt. Order
Call is Established!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 263
RV TFC
Troubleshooting Access Failures & TCCFs
 Troubleshooting access failures (Traffic Channel Confirmation Failures)
can be difficult
 There are many steps in the access process
• Finding which step failed is not easy
 Rarely, circumstantial evidence points clearly to the problem
 Usually, it is necessary to debug the process leading up to the access
failure
• Consider each step in the access process
• Get evidence to determine whether this step occurred successfully
• Move on to the next step and keep checking steps until the
unsuccessful step is found
• Determine why this step failed
 The following slides describe the steps in the access process, where they
take place, and some of the factors which may cause them to fail
 This narrative might be useful as a “template” for organizing your own
thinking as you investigate access failures you are tracking!
• Go out and capture actual drive tests of failed origination attempts
• If possible, also collect system logs (RF call trace, etc.) for the same
event
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 264
Troubleshooting Access Failures (1)
BTS
Steps in the Access Process
Paging Channel
Access Channel
Origination Msg.
Probe #1
Mobile waits to see if the BTS hears and
acknowledges its probe within the time ACC_TMO.
If not, the mobile must transmit the message again
in another probe, this time PI db. louder.
Origination Msg.
Probe #2
Mobile waits again to see if the BTS hears and
acknowledges its probe within the time ACC_TMO.
If not, the mobile must transmit the message again
in another probe, this time PI db. louder.
Origination Msg.
Probe #3
The mobile keeps probing until NUM_STEP probes
have been sent, then repeats the probe sequence
again until Max_Probe_Sequences have been
sent.
Troubleshooting Comments
If the mobile does not hear acknowledgment from
the BTS within ACC_TMO, this could mean either:
•The BTS did not hear the mobile
•Maybe the mobile collided with another
mobile transmitting at the same time
•Maybe mobile was too weak to overcome
the existing reverse noise level at the BTS
•In either case another probe should solve
the problem, provided PI is set reasonably
and additional probes are allowed (check the
Access Parameters Message to see if
Num_Step and the power parameters make
sense; be sure also the cell size or Access
Channel acquisition search width is set large
enough and the number of access preamble
frames is large enough for the cell size)
•The BTS is acknowledging but the mobile cannot
hear the acknowledgment
•If the mobile can’t hear the BTS
acknowledging, Ec/Io is likely quite poor. If
so, check whether this is due to weak signal
(poor coverage) or pilot pollution (lots of
pilots all weak but no dominant server)
Collect system logs if necessary to determine
definitely whether the system heard the mobile’s
origination or not
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 265
Troubleshooting Access Failures (2)
BTS
The Access Process
Paging Channel
Access Channel
One Dreaded Possibility:
Reorder
Mobile beeps and displays “Call Failed - System
Busy”
August, 2013
Troubleshooting Comments
If this problem happens frequently, the BTS traffic
overload must be relieved. Here are some steps to
try:
•Investigate BTS TX hardware to ensure everything
is working correctly and properly calibrated,
particularly gain settings in the TX chain
•To free up more forward power for traffic channels,
try:
•Reduce PTXstart (initial traffic channel
DGU) watching for less forward power
control overloads. If you go too far, you will
notice access failures increase.
•Reduce PTXmax (maximum traffic channel
DGU) watching for less forward power
control overloads. If you go too far, dropped
calls will increase.
•Reduce sector traffic by reorienting the sectors to
more closely balance the load carried by each
•Or, add another carrier
•Or split cells
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 266
Troubleshooting Access Failures (3)
BTS
The Access Process
Paging Channel
Access Channel
Base Station
Acknowledgment
After hearing the BTS acknowledgment, the mobile
will stop probing and wait for further instructions on
the paging channel.
If the mobile does not hear the Channel
Assignment Message within 12 seconds, the
mobile will beep and display “Call Failed”. Possible
causes:
•The BTS did not transmit the Channel Assignment
Message
•Check system logs to see if this was not
transmitted. If not transmitted, get
troubleshooting help from the system
manufacturer -- this should never occur
•The BTS did transmit the Channel Assignment
Message, but the mobile did not hear it
•Was this because the paging channel
faded? (Did the Ec/Io drop momentarily)? If
so, see If this is a recurring problem such as
a coverage hole or severe pilot pollution
Channel Assignment
Message
STOP! Leave the Paging Channel, and don’t
transmit again on the access channel.
The mobile now goes to try to hear the Forward
Traffic Channel.
August, 2013
Troubleshooting Comments
Finally! The mobile hears the Channel Assignment
Message!
Now it will immediately leave the paging channel
and start trying to hear the new Forward Traffic
Channel.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 267
Troubleshooting Access Failures (4)
BTS
The Access Process
FWD Traffic Channel
REV Traffic Channel
00000000000000000000
00000000000000000000
00000000000000000000
Mobile beeps and displays “Call Failed”
00000000000000000000
00000000000000000000
00000000000000000000
Troubleshooting Comments
The mobile listens to the Walsh Code # given in the
Channel Assignment Message. It should hear N5M
good frames full of all zeroes within T2M seconds
(usually 2 frames in 10 frames).
If the mobile does not hear the required number of
good empty frames, it will beep and give an error
message, then reacquire the system.
If the mobile hears the required number of good
empty frames, it starts transmitting its own
“Reverse Traffic Channel Preamble” of empty allzero frames.
If the BTS does NOT hear the mobile’s access
preamble within a prescribed delay, it will abort the
process and release all the resources, and the
mobile will reacquire the system. . This is what
Lucent terms a “Traffic Channel Confirmation
Failure (TCCF).”
Base Station
Acknowledgment
Mobile Station
Acknowledgment
August, 2013
If the BTS DOES hear the mobile’s access
preamble, it will send an acknowledgment.
The mobile responds with an acknowledgment, or
maybe even a pilot strength measurement
message if it already needs a handoff.
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 268
Troubleshooting Access Failures (5)
BTS
The Access Process
FWD Traffic Channel
REV Traffic Channel
Service Connect
Message
Service Connect
Complete Message
This is still just an ongoing access attempt
Base Station
Acknowledgment
Now this is officially a call in progress
Troubleshooting Comments
Now that the BTS and mobile see each other on
the traffic channels, the next step is service
negotiation.
The BTS sends a Service Connect message listing
the type and rate set of the vocoder or other
primary traffic source.
The mobile either accepts the proposal with a
Service Connect Complete message, or
counterproposes a different mode.
The BTS acknowledges the Service Connect
Complete message.
The call is now officially in progress. If anything
happens to interrupt it after this point, that is
considered a dropped call.
If any of these steps is unsuccessful, the call
attempt will probably fail. Suspect RF conditions on
the link which was supposed to carry the
unsuccessful command. Look at system logs and
message logs from mobile drive testing to pin down
just what happened.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 269
Access Failure/TCCF Troubleshooting
Access Attempt Failed
Were any probes acknowledged?
Yes,
BS Ack
No,
Nothing
Yes,
Reorder
Blocking
Paging Channel
faded, lost
Check System Logs.
Was mobile heard?
yes
no
Was Channel Assignment
Message heard?
yes
Did mobile see N5M good
frames on F-TCH?
yes
Check System Logs. Did
BTS see mobile preamble?
yes
Did mobile see BS Ack?
yes
Check System Logs.
Did BTS see mobile Ack?
OK
August, 2013
yes
Check System Logs.
Was CH ASN sent?
no
no
no
Check System Logs.
CH EL initialized OK?
yes
no
Forward Power
Channel Elements
Rev. Link Noise
Weak Signal/Coverage Hole?
Add coverage
Strong Fwd interf / pollution?
Identify, eliminate
Is T-1unstable/blocking?
Report/repair
Rev Link Overload?
Identify, fix source
Num_Step, Pwr_Step
appropriate?
Ensure reasonable
values
Sector Size, Acq Width
appropriate?
Ensure reasonable
values for cell size
System Problem.
Investigate why
no
Software problem
Resource blocking
Rev. Link Noise
no
no
Optmz Fpwr DGUs
Add chan cards
Identify, fix source
Identify, fix source
F-TFC Channel
faded, lost
Init TCH DGU large enough?
Weak Signal/Coverage Hole?
Strong Fwd interf / pollution?
Is T-1unstable/blocking?
Raise DGU
Improve coverage
Identify, eliminate
Report/repair
R-TFC Channel
faded, lost
Weak Signal/Coverage Hole?
Strong Rev Noise?
Is T-1unstable/blocking?
Improve coverage
Identify, eliminate
Report/repair
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 270
Reducing Access Failures
If the base station never sees the mobile’s probes,
Access Attempt
the cause is probably coverage-related. If it happens
in strong signal areas, suspect BTS hardware. Also
Origination Msg
ACCESS
check datafill for proper NOM_PWR and PWR_INC.
Be sure the BTS datafill access channel acquisition BTS
MS
Probing
and demodulation search windows are adequate.
1. If the failures occur in areas where one BTS PAGING Base Sta. Acknlgmt. Order
is dominant, suspect BTS hardware problems.
FW TFC TFC frames of 000s
2. Plot the access failures to see if they correlate
with areas of BTS overlap. If so, suspect
PAGING Channel Assnmt. Msg.
forward link problems. This is probable
TFC preamble of 000s
RV TFC
because the mobile does not have the normal
FW FC Base Sta. Acknlgmt. Order
advantage it would get from soft handoff on a
traffic channel. During access, it must
Mobile Sta. Ackngmt. Order RV TFC
successfully demodulate all five BTS messages
without the benefit of soft handoff. If the
FW TFC
Service Connect Msg.
handset is in an area of multiple BTS overlaps
Svc. Connect Complete Msg RV TFC
or weak signal, this can be risky. In such cases,
try to make the serving BTS more dominant.
FW TFC Base Sta. Acknlgmt. Order
Also check the access/probing parameters.
Call is Established!
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 271
Troubleshooting Dropped Calls
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 272
Dropped Call Troubleshooting - Mobile Side
Just arrived on sync channel!
Is this a drop?
Were there release
messages?
no
yes
OK, normal
end of call
This is a drop!
Was the Sync Channel PN
Active before the drop?
no
no
Add PN to Neighbor List!
Widen SRCH_WIN_N!
no
yes
Repair/Re-initialize Cell!
Did mobile request Sync CH
PN in PSMM before drop?
no
yes
Check
for:
yes
Weak Signal/Coverage Hole?
Improve coverage
Strong Fwd/Rev interference?
Identify, eliminate
Is T-1unstable/blocking?
Report/repair
Why didn’t handoff happen?
PN not in neighbor list
Add PN to Nbr List!
Is PN in neighbor list?
yes
Weak Signal/Coverage Hole?
Add coverage
FER already too bad?
Push earlier
Is SRCH_WIN_N adequate?
yes
Border configuration problems
Debug, reconfigure
Fast-rising pilot, slow reaction
Incr Sector Overlap
Speed up searcher
Forward Power
Channel Elements
Rev. Link Noise
Optmz Fpwr DGUs
Add chan cards
Identify, fix source
Is cell in “island Mode”?
no
Blocking
Is T-1unstable/blocking?
Is T-1unstable/blocking?
Report/repair
More information needed.
Collect system logs and
merge with mobile data,
analyze
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 273
Investigating Dropped Calls
BAD COVERAGE
 If the radio link fails after the mobile sends the
Service Connect Complete Message then it is
considered a dropped call. Using the signatures
described earlier, it is possible to recognize and
separate the dropped calls into the categories at
right.
 Each category has its own causes and solutions
FFER
RXL
100%
-30
EC/IO
TxGa
TxPo
+23
0
+25
-6
+10
-10
0
-20
-10
-30
-40
+10
0
-10
50%
10%
5%
2%
0%
FFER
-90
-100
-110
RXL
-15
-40
-20
-20
EC/IO
-50
-25
TxGa
TxPo
Messaging
BTS
FWD. INTERFERENCE
FFER
RXL
100%
-30
EC/IO
TxGa
TxPo
+23
0
+25
-6
+10
-10
0
-20
-10
-30
-40
+10
0
-10
 Dropped call analysis can consume a
considerable amount of time. Using good postprocessing analysis tools, the root cause of
some of the drops can be determined from
mobile data alone. However, there will be
cases where the cause cannot be reliably
confirmed unless system data is also used
50%
10%
5%
2%
0%
FFER
-15
-40
-20
-20
EC/IO
-50
-25
TxGa
TxPo
Messaging
REV. INTERFERENCE
FFER
RXL
100%
-30
EC/IO
TxGa
TxPo
+23
0
+25
-6
+10
-10
0
-20
-10
-30
-40
+10
0
-10
50%
10%
5%
2%
0%
BTS
RF200 v8.0 (c) 2013 Scott Baxter
RXL
BTS
FFER
August, 2013
-90
-100
-110
-90
-100
-110
RXL
-15
-40
-20
-20
EC/IO
-50
-25
TxGa
TxPo
Messaging
RF200 - 274
Handoff Problems: “Window” Dropped Calls
 Calls often drop when strong
neighbors suddenly appear
outside the neighbor search
window and cannot be used to
establish soft handoff.
 Neighbor Search Window
SRCH_WIN_N should be set
to a width at least twice the
propagation delay between
any site and its most distant
neighbor site
 Remaining Search Window
SRCH_WIN_R should be set
to a width at least twice the
propagation delay between
any site and another site
which might deliver occasional
RF into the service area
August, 2013
SITUATION 1
A
Locked to distant
site, can’t see
one nearby
BTS
B
BTS
SRCH_WIN_N = 130
BTS A is reference.
1 mi.
BTS B appears (7-80) chips
7 Chips
early due to its closer distance.
This is outside the 65-chip window.
Mobile can’t see BTS B’s pilot, but its
strong signal blinds us and the call drops.
SITUATION 2
A
BTS
Locked to nearby
site, can’t see
distant one
B
SRCH_WIN_N = 130
BTS B is reference.
BTS A appears (80-7) chips
late due to its farther distance.
This is outside the 65-chip window.
Mobile can’t see BTS A’s pilot.
RF200 v8.0 (c) 2013 Scott Baxter
BTS
1 mi.
7 Chips
RF200 - 275
Optional: Quick Primer on Pilot Search Windows
 The phone chooses one strong sector and
“locks” to it, accepting its offset at “face value”
and interpreting all other offsets by
comparison to it
 In messages, system gives to handset a
neighbor list of nearby sectors’ PNs
 Propagation delay “skews” the apparent PN
offsets of all other sectors, making them
seem earlier or later than expected
 To overcome skew, when the phone
searches for a particular pilot, it scans an
extra wide “delta” of chips centered on the
expected offset (called a “search window”)
 Search window values can be datafilled
individually for each Pilot set:
 There are pitfalls if the window sizes are
improperly set
• too large: search time increases
• too small: overlook pilots from far away
• too large: might misinterpret identity of a
distant BTS’ signal
PROPAGATION DELAY
SKEWS APPARENT PN OFFSETS
33
4
Chips
Chips
A
BTS
B
BTS
If the phone is locked to BTS A, the
signal from BTS B will seem 29 chips
earlier than expected.
If the phone is locked to BTS B, the
signal from BTS A will seem 29 chips
later than expected.
One chip is 801 feet or 244.14 m
1 mile=6.6 chips; 1 km.= 4.1 chips
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 276
Pilot Search Order, Speed, and Implications
PILOT SEARCHING IN NESTED LOOPS:
WINDOW SIZE
IN CHIPS AND DATA UNITS
Active+Cand
Neighbor
Remaining
THE CAR ODOMETER ANALOGY
The searcher checks pilots in the
order they would appear if pasted
on the wheels of a car odometer.
Actives and candidates occupy the
fastest-spinning wheel.
Neighbors are next, advance one
pilot each time Act+cand revolves.
Remaining is slowest, advance one
pilot each time Neighbors revolve.
Datafill
Value
Window
Size (Chips)
4
14 (7)
5
20 (10)
6
28 (14)
7
40 (20)
8
60 (30)
9
80 (40)
10
100 (50)
 Actives & candidates have the biggest influence.
11
130 (65)
• Keep window size as small as possible
• During soft handoff, this set dominates searcher
12
160 (80)
– Minimize excessive Soft HO!
13
226 (113)
 Neighbor set is second-most-important
14
320 (160)
• Keep window size as small as possible
15
452 (226)
• Keep neighbor list as small as possible
• But don’t miss any important neighbors!
 Remaining Set: pay your dues, but get no reward
• You must spend time checking them, but the system can’t assign one to you
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 277
Treating Drops with Poor-Coverage Symptoms
Drops with weak-signal symptoms
 Using a post-processing tool,
happened in predicted strong-signal
display a map of the locations of
area. Suspect bad BTS hardware.
dropped calls that exhibit
symptoms of poor coverage
• It is particularly useful to be
able to overlay the drop
locations on a map of
predicted or measured signal
levels
 Verify this type of drop is not
occurring in good-coverage areas
• If so, suspect and investigate
hardware at the serving site
 Coverage related drops occurring
in poor-coverage areas are to be
expected; additional RF (usually
from new BTSs) is the only
These drops are probably normal
solution except in rare cases
due to their locations in a
predicted weak-signal area.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 278
Treating Drops with Forward-Link Problems
 Plot the data containing the
forward-link interference drops on
maps from your propagation
prediction tool
• Use the prediction tool to help
identify other strong signals
reaching the drop areas
• If the signals are from other
CDMA carriers, add their Pilot
PNs to the neighbor list
• Resolve any PN conflicts
 Another technique is to examine
the dropped call message files
and identify the BTS from which
the sync channel message is
received immediately after each
drop (this will be the cleanest pilot
the handset sees at that time)
August, 2013
The call on sector A dropped here,
apparently due to interference
from sector B. Find out why soft
handoff with B did not occur.
A
B
Sync Channel Message
p_rev 1, bit_len: 170
min_p_rev 1
sid 4139 nid 41
pilot_pn 0x164 = 356 ( RMCZ )
lc_state 1ED595B9632
sys_time 189406BE8
lp_sec 13
ltm_off 0x10 (8.0 hours)
daylt 0 prat 1
cdma_freq 50
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 279
“Optimizable” Dropped Calls: Slow Handoff
 When the mobile is suddenly
confronted with a strong new signal,
or when the signal it is using takes a
sudden deep fade, it will have poor
Ec/Io and high forward FER. The call
will drop unless it gets help quickly.
Several steps which must occur
without delay:
• The mobile search correlator
must first notice the new pilot
and send a PSMM to the system. BTS
• The system must set up the soft
handoff and notify the mobile.
• The mobile must acquire the
new signal by locking a finger
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
BTS
x
RF200 - 280
Setting Pilot Search Window Sizes
 When the handset first powers up, it does an exhaustive search for the
best pilot and no windows apply to this process.
 When finally on the paging channel, the handset learns the window sizes
SRCH_WIN_A, N, R and uses them when looking for neighbors both in
idle mode and during calls.
 During a call, when a strong neighbor is recognized, a PSMM is sent
requesting soft handoff. The former neighbor pilot is now a candidate set
pilot and its offset is precisely remembered and frequently rechecked and
tracked by the phone.
 The window size for active and candidate pilots doesn’t need to be very
large, since the searcher has already found them and is tracking them
very frequently. We need only enough width to accommodate all
multipath components of these pilots.
• This greatly speeds up the overall pilot search management!
 Most post-processing tools deliver statistics on the spread (in chips)
between fingers locked to the same pilot. These statistics literally show us
how wide the SRCH_WIN_A should be set.
 Neighbor and Remaining search windows should be set based on intercell
distances as described in a preceding slide.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 281
Maximum Timing Budget for CDMA Cells
 The range of a CDMA cell is normally limited by the attenuation that
occurs along ordinary propagation paths. Occasionally, a site is
located atop a high mountain or other location from which it can see a
very large distance, so large that timing considerations must be
recognized. Search windows are the main concern.
 The BTS uses acquisition and demodulation search windows much
like the pilot search windows used by the mobile. The maximum
setting is 4095/8 chips (512 chips -1/8 chip). A mobile 38.8 miles from
the site would be at the edge of this maximum window setting, and
could not originate or be acquired during handoff beyond this distance.
 The mobile is not restricted on acquiring the system forward channels
but its pilot search windows are limited to 452 chips. Neighbor pilots
couldn’t be recognized if coming from a cell more than 34.3 miles
closer or farther than the cell to which the mobile is locked.
 The IS-95 and J-Std008 specify a maximum of 350 sec maximum
round trip delay, BTS-Handset. This is a distance of 32.6 miles.
 General Observation: If your cell radius exceeds 30 miles, be careful.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 282
How Much Soft Handoff is Normal?
 How much soft handoff is normal?
• Expectations in early CDMA development were for roughly 35%
• The level of soft handoff which should be used depends on how much
diversity gain can be achieved, and terrain roughness
– If the reverse link budget assumed 4 dB soft handoff gain, and
propagation decays 35 dB/decade, 42% of the sector’s area is within
the last 4 dB. of coverage where soft handoff occurs.
– In typical markets, terrain irregularities scatter RF beyond cleanly
designed cell edges; soft handoff is typically 50-60%
– In rough terrain, proper soft handoff may rise to 70% or more
 In a system not yet well-tuned, soft handoff may be clearly excessive
• The main cause is usually excessive RF overlap between cells
• RF coverage control is the most effective means of reducing and
managing soft handoff (BTS attenuation, antenna downtilting)
• Thresholds T_ADD and T_DROP can be adjusted to reduce soft handoff,
but this penalizes mobiles that need soft handoff to escape interference
from the excessively overlapping sites
Controlling soft handoff percentage with T_ADD and T_DROP is like limiting
allowed hospital days for various illnesses. Works, but some patients may drop.
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 283
TX Gain Adjust as a Per-Site Debugging Tool
 Collect Transmit Gain Adjust Statistics
 For an unloaded system, the average should be -7 to -12 db. and
should be fairly constant throughout the coverage area
 Look for big “jumps” in TX GA from sector to sector. Look for
hardware problems (antennas OK, RX noise figure OK?, etc.)
 If you see values generally outside the range above uniformly
across the coverage area, look at the BS Eb/Nt. It should be 5-9
dB for mobile systems, or 3-4 dB. for fixed wireless access.
 Other parameters can have similar uses; compare and study.
Typical Mobile Station Transmit Gain Adjust
0 dB
-10 dB
-20 dB
Time, Seconds
August, 2013
RF200 v8.0 (c) 2013 Scott Baxter
RF200 - 284
Section II. 1xEV-DO Optimization
August, 2013
Course RF200v8 (c)2013 Scott Baxter
285
Module 344
1xEV-DO
RF Performance Optimization
August, 2013
Course RF200v8 (c)2013 Scott Baxter
286
344 Contents
 1xEV-DO Key Performance Indicators
• Bad Packet Rate, Serving Data Rate, Reverse Link Statistics
• Receive Power, Composite C/I
• Mobile Transmit Power at Given Rate
• Reverse Link Closed Loop Power Control
• Latency and Throughput
 Air Interface Review from Optimization Perspective
 Backhaul Considerations
 Optimizing the Air Interface
• Coverage, Neighbor List, Search Windows and Offsets
 Drive-Test Tools Summary and Examples
 Setup issues
 Forward Link Throughput Optimization
• Detecting IP and RF issues
• The role of RF interference in determining requested burst rate
August, 2013
Course RF200v8 (c)2013 Scott Baxter
287
1xEV-DO
Key Performance Indicators
August, 2013
Course RF200v8 (c)2013 Scott Baxter
288
Popular Generic KPIs for Wireless Services
August, 2013
Course RF200v8 (c)2013 Scott Baxter
289
Bad Packet Rate
 Packet error rates in both directions should be comparable to
packet retransmission rates in 1xRTT
 5% is a typical target value; this chart shows excellent results
August, 2013
Course RF200v8 (c)2013 Scott Baxter
290
Data Speed During Connection
 The average data
rate received
depends on:
• “dilution” of
sector capacity
by multiple users
• Reduction of
speed due to
poor RF channel
conditions
 The distribution of
packet rates of one
user show the
effects of RF
impairments only
August, 2013
Course RF200v8 (c)2013 Scott Baxter
291
Reverse Link Traffic Statistics
 This summary shows reverse link transmit power, PER, and
average PER
 Both Forward and Reverse link retransmitted bytes are shown,
along with the total data KB transmitter
August, 2013
Course RF200v8 (c)2013 Scott Baxter
292
Io -- Receive Power
 As in 1xRTT, receive power is not the primary quality indicator
 It should be well above -100 dbm (“coverage hole” conditions) and
not higher than -40 dbm (“intermod” conditions)
 Receive power is the “I” in C/I. C/I is more important than I alone
 Receive power remains a vital clue to some types of interference
troubleshooting
August, 2013
Course RF200v8 (c)2013 Scott Baxter
293
I0, Total AT Receive Power
AT Receiver

BW
~30
MHz.
LNA
x
LO

IF
overload>>
I0
-40
Rake
R
BW
1.25
MHz.
RX Level
(from AGC)
R
R
S
<<too weak
 AT Receive Power
• usually expressed in dBm
• measured derived from
handset IF AGC voltage
• broadband, “unintelligent”
measurement: includes all
RF in the carrier bandwidth
regardless of source, not
just RF from serving BTS
-90
-105
 AT power is important, but it’s exact value isn’t critical
• too much received signal (-35 dbm or higher) could drive the
AT’s sensitive first amplifier into overload, causing intermod and
code distortion on received CDMA signals
• too little received signal (-105 or weaker) would leave too much
noise in the signal after de-spreading, resulting in symbol errors,
bit errors, packet errors, and other problems
August, 2013
Course RF200v8 (c)2013 Scott Baxter
294
Mobile Transmit Power at Given Rate
 When mobile transmit power is significantly higher than expected
for the location of the mobile and its vicinity, reverse link
interference may exist
 Inspect the receive level indications from the base station, looking
for high receive power warnings
• Both peak and average RF receive levels are useful, indicating
whether the problem is constant or intermittent
• If the problem appears to be real RF interference, special
weak-signal detection techniques may be necessary to track it
down, just as in IS-95 CDMA
August, 2013
Course RF200v8 (c)2013 Scott Baxter
295
Reverse Link Closed Loop Power Control
 As in 1xRTT, Reverse Link Closed Loop Power Control is an
indication of general interference on either link
 Interference on the uplink of the serving sector will make the sector
request higher power from each served mobile
 Interference on the forward link at the mobile will raise the mobile’s
receive power, causing it to want to transmit at lower power and
thereby forcing the serving sector to request the mobile to transmit
at higher power.
 If higher-than-normal closed loop power control is observed,
inspect the other forward and reverse link RF parameters to
identify whether the interference is forward link or reverse link.
August, 2013
Course RF200v8 (c)2013 Scott Baxter
296
Latency
Internet
VPNs
T
PDSN
Home Agent
PDSN/Foreign Agent
Backbone
Network
SECURE TUNNELS T
Authentication
AuthorizationAAA
Accounting
EVDO RF Environment
IP Data Environment
IP Data Environment
R-P Interface
AP
SEL
t1
EVM
DO RNC or FMS
EVDO IOS PPP
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 Latency can occur because of RF channel congestion or from
IP network causes
• RF overload can delay availability of supplemental channels
• IP network congestion can delay availability of packets
 Ping and loopback tests with local PDSN and servers can
identify whether problem is in backbone network
 Does latency correlate with independent evidence of RF
congestion?
August, 2013
Course RF200v8 (c)2013 Scott Baxter
297
Throughput
Internet
VPNs
T
PDSN
Home Agent
PDSN/Foreign Agent
Backbone
Network
SECURE TUNNELS T
Authentication
AuthorizationAAA
Accounting
CDMA RF Environment
IP Data Environment
IP Data Environment
R-P Interface
AP
SEL
t1
EVM
DO RNC / FMS
EVDO IOS PPP
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 Throughput can be limited by RF and IP causes
• Traditional RF problems limit capacity of the channel
• Congestion in the IP network can limit speed of data available
 Does low throughput correlate with independent RF indicators?
 Does low throughput correlate with independent IP pings and tests?
August, 2013
Course RF200v8 (c)2013 Scott Baxter
298
Composite C/I
 Composite C/I is the primary indication of forward link quality
• C/I drives the rate of the mobile’s DRC requests for packets
 Poor C/I can be the result of
• “pilot pollution” caused by too many comparable signals being
present at the mobile’s location
• Interference from external RF sources on the forward link
August, 2013
Course RF200v8 (c)2013 Scott Baxter
299
Ec/Io and C/I
AP
Relationship of
C/I and Ec/Io
For EV-DO Signals
mobile receive power
C
Power from
Serving Sector
Ec
I
Interference Power
from other cells
Io
0
Ec/Io, db
0
-10
-20
-30
-30
-20
-10
0
+10
 There are two main ways of expressing
signal quality in 1xEV-DO
 C/I is the ratio of serving sector power to
everything else
• C/I determines the forward data rate
• mobiles measure C/I during the pilot
burst period, then from it decide what
data rate to request on the DRC
 Ec/Io is the ratio of one sector’s pilot power to
the total received power
 Ec/Io and C/I are related, and one can be
calculated from the other
 EVDO Ec/Io is close to 0 db near a sector,
and ranges down to -10 at a cell’s edge
 EVDO C/I can be above +10 db near a
sector, and -20 or lower at the edge
+20
C/I, db
August, 2013
Course RF200v8 (c)2013 Scott Baxter
300
Relationship of Ec/Io and C/I in 1xEV-DO Systems
-30
-25
-20
-15
-10
-5
0
5
10
15
20
C/I,
db
-0.04
-0.14
-0.17
-0.21
-0.27
-0.33
-0.41
-0.51
-0.64
-0.79
-0.97
-1.19
-1.46
-1.76
-2.12
-2.54
-3.01
-3.54
-4.12
-4.76
-5.46
-6.97
-8.64
-10.41
-12.27
20
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
-1
-2
-3
-4
-6
-8
-10
-12
August, 2013
-5
-10
Ec/Io, db
Ec/Io,
db
0
-15
-20
-25
-30
C/I, db
Course RF200v8 (c)2013 Scott Baxter
301
Statistical EVDO Indications
 RF Connection failures
• Mobile does not reach an assigned traffic channel
 RF Connection Losses
• Existing connection is lost due to failure of forward or reverse
link
 RF Blocking
• Due to MAC index, backhaul, or other congestion
August, 2013
Course RF200v8 (c)2013 Scott Baxter
302
Backhaul and
Related Considerations
August, 2013
Course RF200v8 (c)2013 Scott Baxter
303
Rate Limitations from Backhaul
 Wireless sites are commonly connected using T-1s or E-1s,
depending on local availability
• In the case of T-1s, the raw rate is 1.544 megabits/second.
– Accounting for overhead, this translates into a maximum
steady throughput of roughly 400 to 450 kb/s per sector on
a 3-sector, 1-carrier EV-DO site.
– If one sector is busy while the other two are only lightly
loaded, throughput of roughly 1 mb/s can be obtained on
one sector
– However, early 1xEV-DO cards without support for multiple
ARQ instances can only achieve about 400 kb/s
throughput even without backhaul limitations
 Solutions under study to relieve backhaul congestion include fiberbased ATM to the sites; multiple-T1s; sites linked by Cable
Modems, and other methods
August, 2013
Course RF200v8 (c)2013 Scott Baxter
304
Optimizing the
1xEV-DO RF Air Interface
August, 2013
Course RF200v8 (c)2013 Scott Baxter
305
Dealing With RF Coverage Anomalies
 It is difficult to build a system without encountering a few coverage
holes and without having some sectors that cover more than
planned
• The techniques for identifying and resolving these problems
are similar to IS-95 and 1xRTT, with a few modifications
 Detection methods: Area sweeps with EV-DO PN scanners and
EV-DO terminals
• If a sector is in the active set of mobiles in places beyond the
line joining its surrounding tier of sites, reduce its coverage
– Site RF parameters, antenna downtilt, or antenna height
• If a sector fails to cover its intended area, look for obvious
hardware or environmental reasons
– Repair or correct any such impairments, and if
unsuccessful, look for other serving sectors
– Reradiators are feasible for EV-DO, but setup is tricky
August, 2013
Course RF200v8 (c)2013 Scott Baxter
306
Generating and Optimizing Neighbor Lists
 After coverage of each sector has been studied and adjusted if
necessary, neighbor relationships are now stable
 Initial neighbor lists can be generated from propagation prediction
modeling or even from drive-test results with AT or PN scanners
 The most reliable way to groom neighbor lists is to use system
tools to collect route update requests from each sector. These
results can be analyzed in matrix form to determine the frequency
of requests for each surrounding sector
• Sectors with more than 5% of requests are usually added
• Sectors with less than 1% of requests are usually unnecessary
• Watch out for sectors that are already neighbors of neighbors
and would be unnecessary
• Watch out for special specific cases where unusual
relationships exist because of terrain and busy roadways
August, 2013
Course RF200v8 (c)2013 Scott Baxter
307
Optimizing Search Windows
 The pilot searcher of a mobile must be able to see the pilots of any
sectors it may encounter – otherwise route update is impossible
 Timing errors affect pilot searching. Sources include:
• Timing delay from reference sector to mobile
– This delay is unknown to the mobile, but it goes into the mobile’s
reference timing without the mobile’s knowledge
• Timing delay from needed neighbor signal to the mobile
– This delay is also unknown to the mobile, but it can shift the
apparent timing of the desired neighbor either ahead or behind
the timing the mobile expects
• The worst-case error in timing is the propagation delay of a straight
line between reference sector and desired sector
• Neighbor search window can be set to this level initially and possibly
reduced if accumulated data later allows
 Active search windows “float” on their individual pilots and do not need to
be large enough to handle propagation delay. They only need to
accommodate delay spread, which is better measured than calculated.
August, 2013
Course RF200v8 (c)2013 Scott Baxter
308
Search Window Offset
Search Window Offset
0
1
2
3
4
5
6
7
Offset (PN chips)
0
+0.5 x WindowSize
+1.0 x WindowSize
+1.5 x WindowSize
- 0.5 x WindowSize
-1.0 x WindowSize
-1.5 x WindowSize
reserved
-1.5 -1.0 -0.5 0.0 +0.5 +1.0 +1.5
 Search window offsets make it possible to individually compensate
for the great distance of certain sectors from the service area of
another
• The range of adjustment can effectively shift the center of the
search window by up to 1.5 times earlier or later than the
actual search window width
August, 2013
Course RF200v8 (c)2013 Scott Baxter
309
Andrew’s Invex3G Tool
 100 MB ethernet connection to
PC
 the eight card slots can hold
receivers or dual-phone cards
 there’s also room for two
internal PN scanners
 Multiple Invex units can be
cascaded for multi-phone loadtest applications
 Cards are field-swappable Users can reconfigure the unit
in the field for different tasks
without factory assistance
August, 2013
Course RF200v8 (c)2013 Scott Baxter
310
Overview of Field Tool IP Test Capabilities
Application
Description
Purpose
Raw Upload
Uploads data with no overhead (no headers, no
handshaking beyond the normal TCP handshaking)
Testing uplink throughput
Raw Download
Downloads data with no overhead (no headers, no
handshaking beyond the normal TCP handshaking.)
Testing downlink throughput
Raw Loopback
A loopback (data is sent to the remote server which
returns the same data) application with no overhead (no
headers, no handshaking beyond the normal TCP
handshaking.)
Simultaneous exercise of the uplink and downlink
Ping (ICMP ECHO)
Ping does not use the TCP protocol, but rather uses the
connectionless and “unreliable” ICMP protocol. Sends
small echo request packets to a remote server, which
responds with an echo reply.
Determining round-trip-time between the user and the
remote server, as well as general link integrity (by
counting the number of missing echo reply packets).
A standard web page “browse” request.
If Raw Download is unavailable, testing downlink
throughput; modeling typical customer use.
A web-based upload (similar to how web-based email
sites allow users to upload files as “attachments”).
If Raw Upload is unavailable, testing uplink throughput.
FTP GET
A standard FTP file download. Many file downloads on
the Internet use FTP.
If Raw Download and HTTP GET are unavailable, testing
downlink throughput; modeling typical customer use.
FTP PUT
A FTP file upload. The file is generated by the Invex3G
platform and sent to the server.
If Raw Upload and HTTP POST are unavailable, testing
uplink throughput
Retrieves all the mail for a given mailbox (e-mail
address) from an e-mail server. Note: does not delete
the e-mail messages from the mailbox.
Modeling typical customer use.
Waits a specified amount of time.
Testing idle timers, timeouts, etc.
HTTP GET
HTTP POST
Mail GET (POP3)
Wait
August, 2013
Course RF200v8 (c)2013 Scott Baxter
311
Agilent Drive-Test Tools
 Agilent offers Drive-Test tools
• Serial interfaces for up to four
CDMA phones or cards
• A very flexible digital receiver
with several modes
 PN Scanner
• Fast, GPS-locked, can scan
two carrier frequencies
 Spectrum Analyzer
• Can scan entire 800 or 1900
mHz. Bands
 Base-Station Over-Air Tester
(BOAT)
• Can display all walsh channel
activity on a specific sector
• Useful for identifying hardware
problems, monitoring
instantaneous traffic levels, etc.
 Post-Processing tool: OPAS32
August, 2013
Course RF200v8 (c)2013 Scott Baxter
312
1xEV-DO Setup Performance:
Sessions and Connections
August, 2013
Course RF200v8 (c)2013 Scott Baxter
313
Session Configuration Parameters
 In initial Session and Connection setup, the access channel and
control channel carry the messages
• If L3 messages and RF indications are available, problems
usually can be identified
 Check the access parameters
• The range of powers should step through a range from the idlemode noise floor up to about 20 db above it
– A smaller power range can result in missed probes
– Check AP/BTS reverse receive levels, peak and average
looking for indications of interference
• Ensure sector size and acquisition search windows are
adequate
August, 2013
Course RF200v8 (c)2013 Scott Baxter
314
Long Setup Times and RF Failures
 Long setup times, often seen as bad latency in VOIP and PTT
applications, can result when extensive probing occurs. This can
be the result of:
• RF reverse link interference
– External interference or rogue terminals
• Incorrect Access Parameters, having mobiles start probing at
low RF levels
August, 2013
Course RF200v8 (c)2013 Scott Baxter
315
Forward Link
Throughput Optimization
August, 2013
Course RF200v8 (c)2013 Scott Baxter
316
PDSN/Foreign Agent
Forward Link Scheduler
data
User
Data Rate
R-P
Interface
Buffer
AP
PCF SEL
t1
DO-RNC or FMS
EVM
EVDO device
 The main bottleneck is forward link available C/I and timeslots
 Each connected data User has a buffer in the PDSN/PCF complex
• When data is in the buffer, a “Data Ready” message is sent to the mobile
• The mobile then requests data from the desired sector on DRC/DSC
• The scheduler fairly divides slots among the active users
• “Proportional Fairness” applies, always trying to give slots to each user
when that user’s link is better than average
• This substantially improves (40%+) both user and overall sector
throughput
• QOS (Quality of Service) rules also may be implemented, giving
preference to some users and some types of traffic
August, 2013
Course RF200v8 (c)2013 Scott Baxter
317
So S L O W ! !
Where’s My Data?!!
Internet
VPNs
T
PDSN
Home Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization AAA
Accounting
T
EVDO RF Environment
R-P Interface
AP
SEL
t1
EVM
DO-RNC / FMS
EVDO IOS PPP
IP Data Environment
IP Data EnvironmentPDSN/Foreign Agent
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Rev Pwr Ovld
•Search Windows
•Island Cells
Wireless
•Slow Handoff
Mobile Device
 Some sessions have long latency and slow throughput
 Where is the problem? Anywhere between user and distant host:
• Is the mobile user’s data device mis-configured and/or congested?
• Is the AP congested, with few timeslots available?
• Poor RF environment, causing low rates and packet retransmission?
• Congestion in the local IP network (PCU, R-P, PDSN FA)?
• Congestion in the wireless operator’s backbone (‘OSSN’) network?
• Congestion in the PDSN HA?
• Congestion in the outside-world internet or Private IP network?
• Is the distant host congested, with long response times?
August, 2013
Course RF200v8 (c)2013 Scott Baxter
318
Finding Causes of Latency and Low Throughput
Test
Test
Server
Server
IP Data EnvironmentPDSN/Foreign Agent
Internet
VPNs
T
PDSN
Home Agent
Backbone
Network
SECURE TUNNELS
Authentication
Authorization AAA
Accounting
T
EVDO RF Environment
R-P Interface
BTS
v SEL
t1
CE
DO-RNC or FMS
EVDO IOS PPP
IP Data Environment
Test
Server
•Coverage Holes
•Pilot Pollution
•Missing Neighbors
•Fwd Pwr Ovld
•Rev Pwr Ovld
•Search Windows
Wireless
•Island Cells
Mobile Device
•Slow Handoff
 IP network performance can be measured using test servers
 Problems between mobile a local test server? The problem is local
• check RF conditions, stats: poor environment, SCH blocking?
• if the RF is clean, investigate BSC/PCU/R-P/PDSN-FA
 Local results OK, problems accessing test server at PDSN-HA?
• problem is narrowed to backbone network, or PDSN-HA
 Results OK even through test server at PDSN-HA
• then the problem is in the public layers beyond.
August, 2013
Course RF200v8 (c)2013 Scott Baxter
319
Pinging Network Nodes to test Latency
 Simple “ping” commands from a command prompt line can detect
latency to and from particular servers
 Notice in the example, the first ping in the second attempt is
delayed more than others because the user was in dormant state
immediately prior, and a new connection had to be established
August, 2013
Course RF200v8 (c)2013 Scott Baxter
320
Using Tracert to Identify Delays
 The command “Tracert” at the command prompt will show the
identification and timing details of all non-firewalled nodes in the
network.
August, 2013
Course RF200v8 (c)2013 Scott Baxter
321
Forward Link Speed – No Dominant Server
 When there are many equal servers, the C/I values of each server
are very poor and the forward link data speed from any of the
servers is very low
 This is the equivalent of “pilot pollution” in 1xRTT CDMA
August, 2013
Course RF200v8 (c)2013 Scott Baxter
322
Forward Link Speed – Very Dominant Server
 When one server stands head and shoulders above the other
sectors, its C/I is excellent and it can deliver very fast data
 However, if this server is overloaded with traffic, the mobile has no
alternative sector and the blocking will have a large impact
August, 2013
Course RF200v8 (c)2013 Scott Baxter
323
Forward Link Speed – Three Equal Servers
 When three sectors are approximately equally strong, their C/I
values are medium-to-poor. Any of these sectors could deliver
data to the mobile at 307 Kb/s
 If one of these sectors becomes saturated and puts up its “DRC
Lock” bit against our mobile, the mobile could choose another
sector and avoid most blocking
August, 2013
Course RF200v8 (c)2013 Scott Baxter
324
Single User Traffic Statistics from Invex
 The average bit speed obtained by a mobile on downlink is affected by:
• RF conditions (this determines the instantaneous bit speed when a
slot is being sent to the mobile)
• Fraction of time during which the mobile “owns” the sector
 The above tabulation from the Andrew Invex tool shows the bit speed for
all slots to the mobile, allowing independent identification of RF problems
and traffic congestion effects due to others
August, 2013
Course RF200v8 (c)2013 Scott Baxter
325
Reverse Link
Throughput Optimization
August, 2013
Course RF200v8 (c)2013 Scott Baxter
326
Reverse Link Throughput Considerations
 Reverse Link throughput is influenced by
• Instantaneous RF conditions, dictating selected packet speed
and Hybrid-ARQ speedup, if any
• Congestion on the reverse link, as indicated by the sector
limiting the available slots from the mobile
• T-1 or other backhaul limitation, imposing ceilings on the
number of reverse packets which can be uploaded from an AP
to the AN
August, 2013
Course RF200v8 (c)2013 Scott Baxter
327
Reverse Link Rate Control in Rev. A
 Discussion of Reverse Link rate control algorithm
• Dependence on Observed C/I of serving sector
• Bucket control mechanism
 Available packet scheduling parameters vary by manufacturer
 Extreme sensitivity to reverse link interference, like 1xRTT
August, 2013
Course RF200v8 (c)2013 Scott Baxter
328
QOS
Quality of Service
August, 2013
Course RF200v8 (c)2013 Scott Baxter
329
Quality of Service
 Quality of Service allows a network to provide differentiated
service to specific groups of users and/or for specific types of
traffic, so that users may meet their service needs while efficiently
using the resources of the network
 In EV-DO Rev. A, QOS is provided by the Enhanced Multi-Flow
Packet Application (EMPA). Its main features:
• Spectral Efficiency
– Packet-based RLP-EMPA enables packet streams to carry
packets between AT and AN.
– Packet-based RLP reduces the overhead.
• Single VoIP frames can fit in single air-interface frames, by
using Robust Header Compression (RoHC).
• Inter-RNC Handoff
– Two parallel routes can be terminated at different RNCs
simultaneously, reducing interruption in VOIP and other
sensitive applications during inter-RNC handoff.
August, 2013
Course RF200v8 (c)2013 Scott Baxter
330
QOS Control Techniques in 1xEV-DO
 Admission Control at the RAN
• The 1xEV-DO Rev. A RAN may perform admission control techniques
to maintain QoS
• Admission Control – A technique to “block” or deny an incoming QoS
flow request in order to satisfy QoS requirements with a very high
probability
 Forward Link QoS via Scheduler
• Forward Link QoS at the AN may be achieved via the scheduler.
• QoS and serving of users is based on:
– QoS flow requirements – Delay bound, throughput, and reliability.
– Priority of application flow
– Best Effort, Assured Forwarding, Expedited Forwarding
– AND/OR Priority Level 0 – 7
– Amount of data in Forward link queue
– Channel conditions of AT
– Number of active users in the sector
August, 2013
Course RF200v8 (c)2013 Scott Baxter
331
Priority Levels and Classes
 A priority level (0-7) is
assigned to each
application’s traffic
 The QOS algorithm
uses these levels in
prioritizing traffic
 An operator usually
sets these priorities
based on its own
business philosophy,
with help from its
network vendor
August, 2013
Course RF200v8 (c)2013 Scott Baxter
332
Forward Link Queue Management
 Proportional Fairness (effectively “Best Effort”)
• Exploit channel quality variations (multi-user diversity).
• Average user throughput is proportional to DRC.
• As load increases, users suffer even degradation.
 Delay Fairness (QoS flows)
• Different priorities for different users/traffic.
• User’s traffic delay varies inversely with channel conditions
• Uneven degradation occurs, based on user priority
August, 2013
Course RF200v8 (c)2013 Scott Baxter
333
Forward Congestion Avoidance: RED
 Random Early Detection (RED)
• Typically used when there is a single queue buffer
• Drops incoming packets based on current load statistics
• Advantage: Gracefully slows a congested link
 Works as a function of three parameters:
• Min Thresh
• Max Thresh
• Drop Probability.
 Intended for undifferentiated “Best Effort” type traffic, or on highly
congested links
August, 2013
Course RF200v8 (c)2013 Scott Baxter
334
Forward Congestion Avoidance: WRED
 Weighted Random Early Detection (WRED)
• Same philosophy as RED, but with IP precedence.
• Selectively discards lower priority traffic during congestion.
• Attempts to predict and manage congestion.
 WRED-Considered parameters for each traffic class or weight:
• Min thresh
• Max thresh
• Drop probability
 Drops more packets from large users than small.
 Appropriate for Assured Forwarding kinds of data flows
August, 2013
Course RF200v8 (c)2013 Scott Baxter
335
Rev. A Reverse Link MAC Enhancements
 EV-DO Rev. A provides many reverse link performance and QOS
enhancements
• Hybrid ARQ on Reverse Link Physical and MAC layer
• Early termination and new higher and lower payload sizes
• Larger payload sizes give higher rates for delay-tolerant
applications
• Lower latencies through smaller payload sizes for delaysensitive applications
• Comprehensive AN control of AT resource allocation
• QoS sensitive resource allocation across multiple data flows
• Independent trade-off per flow between capacity and latency
• Improved Reverse link stability at higher occupancy
August, 2013
Course RF200v8 (c)2013 Scott Baxter
336
Reverse Link QOS
 In 1xEV-DO Rev A, Reverse link QoS is maintained by the AT and
the RTCMAC Algorithm.
 QoS and flow transmissions are based on:
• QoS requirements of flow
• Payload size, delay bound, etc.
• RTCMAC flow priority functions
• Amount of data in Reverse link queues
• Channel conditions of AT and sector loading
 Available T2P resources
August, 2013
Course RF200v8 (c)2013 Scott Baxter
337
Intra-AT QOS
 An AT may have multiple MAC flows existing at the same time (for
example, live video, live audio, and text
• MAC parameters control allocation for each of the flows
• Performance of delay-sensitive flows is not degraded by
competition from delay-tolerant data flows.
• MAC flow behavior is uniform whether within the flows of one
AT or across many ATs.
• In general, AT resource allocation is the sum of its MAC flow
allocations.
August, 2013
Course RF200v8 (c)2013 Scott Baxter
338
QOS Implementation for 1xEV-DO ATs
 Rel. 0 ATs support
• Default protocols, Default Packet Application
 Rev. A ATs support
• default protocols
• Multi-Flow Packet Application
• Enhanced Multi-Flow Packet Application
 Different make and model ATs support different OSI applications:
• VoIP, VT, PTx, etc.
 QoS requirements are expressed in terms of
• Latency, Throughput, Reliability, and Jitter
August, 2013
Course RF200v8 (c)2013 Scott Baxter
339
FlowProfile IDs
 ATs support specific FlowProfile IDs
• Flow Profiles must be mutually defined on AT and RAN
• All the flows within a application should be bundled to maintain
application integrity
 Traffic Flow Templates Information Elements (TFTs IE) specify the
QOS filter requirements
• TFTIEs must be coordinated with PDSN and AAA.
August, 2013
Course RF200v8 (c)2013 Scott Baxter
340
Traffic Flow Templates
 Traffic Flow Template
• The PDSN needs to know the A-10 connection (main or
auxiliary) on which to put the IP packets.
 Traffic Flow Templates convey:
• A-10 to IP flow mapping information
• QOS Parameters at the IP Layer
• Actions to take on IP packets
 This group of information is called a Packet Filter
August, 2013
Course RF200v8 (c)2013 Scott Baxter
341
Section III. LTE Optimization Preview
August, 2013
Course RF200v8 (c)2013 Scott Baxter
342
LTE Performance Optimization
June, 2013
Course RF200v8 (c)2013 Scott Baxter
Page 343
Performance Optimization Perspective
 LTE is a complex marriage of advanced radio technology with
high-speed TCP/IP
• The LTE Radio Access Network (RAN), although more resilient
than earlier technologies, is still vulnerable to impairments from
RF causes
• The LTE Core Network, although more effectively structured
than in earlier wireless systems, still requires solid planning
and configuration and is vulnerable to the normal range of
issues faced by all TCP/IP systems
 Performance impairments are normally perceived by the end user
of data services in a TCP/IP data context, whether resulting from
RAN, Core Network, or external TCP/IP factors.
• Many problem symptoms are hard to identify as RAN, Core, or
external in origin
 The monitoring and investigative tools for identifying and resolving
problems are quite different for the RAN and the Core network
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 344
Types of LTE Performance Testing
 To most closely understand a user’s experience on the network,
and to benchmark overall performance, end-to-end (“E2E”) testing
is often the initial method used
• Measure date performance from user terminal to test server, or
from user-terminal to user-terminal
• Basic testing of latency and throughput can be performed with
user-level tools readily available on app stores and general
TCP/IP utilities
• More detailed results and organized benchmarking are
available from commercial tools which connect to user
terminals to other-end servers for more advanced test
capabilities
 When problems or performance issues appear in end-to-end
testing, more specific RAN and Core Network tools are then used
to drill down for problem location and root cause analysis
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 345
LTE RAN Optimization Tools
June, 2013
Course RF200 v8 (c)2013 Scott Baxter
Page 346
LTE RAN Testing
 Successful RAN problem resolution focuses especially on the
lower levels of the protocol stack
• RF performance – the Uu interface
– Terminal and eNodeB signal quality tests
– Dynamic field capture of RF indicators
– Field RF environment testing, interference detection
• “Call Processing” Event Capture and Performance Analysis
– MAC layer performance
Process monitoring, parameter capture, and problem
detection for unsuccessful events
Handover monitoring and configuration analysis
– Messaging Capture and Interpretation
Identification of specific failed events and root analysis
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 347
LTE RAN Test Tools
Multiple tools are available for RAN testing:
 UE-intrinsic diagnostic and status displays
 Specific UE logging applications for more detailed capture of RF
conditions and “signatures”
 Commercial Off-Air receivers for field signal analysis of both uplink
and downlink conditions
 Commercial “call processing” capture tools logging UE RF
indications, MAC-level and Message-level activity, and state
changes of the UE
 RAN Manufacturer-specific logging/capture and reporting utilities
for eNodeB RF indications and event records
 Post-Processing software tools for merging and analysis of
captured field and RAN-side RF data to support detailed analysis
of performance problems
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 348
Agilent RF Tools
 Agilent (formerly HewlettPackard, HP) has a long history
of RF tools
 More recently, Agilent has sold
its RF-specific wireless field tool
division to another company,
JDSU (product details on
another page)
 Agilent continues to provide
overlapping RAN/Core Network
test capabilities with its family of
Distributed Network Analyzers
and post-processing software
 Agilent is still a major
manufacturer of general RF test
equipment including spectrum
analyzers
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 349
Anritsu RF Tools
 Anritsu is a manufacturer of integrated tools popular
for operations personnel in many wireless operators
 Current offerings include field instruments which are
combinations of spectrum analyzers, transmission
line testers, and vector network analyzers
 Anritsu also manufactures high-tier manufacturing
test sets for LTE and other technology mobile
chipsets and for performance conformance and
certification testing of LTE eNodeB and UE devices
in both development and manufacturing contexts
 At this writing, although Anritsu spectrum analyzers
and line testers are popular for basic operational
tests, Anritsu does not offer devices specifically
focused on field-level LTE event capture and
analysis except at the physical (RF signal) level
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 350
Ascom-TEMS RF Tools
TEMS INVESTIGATION
TEMS DISCOVERY
 Ascom acquired the earlier Ericsson TEMS tool
 Ascom-TEMS offers a field data acquisition system called
TEMS Investigation. It collects RF field data from UEs,
scanning receivers, and GPS.
 TEMS Discovery is a post-processing tool which allows root
cause analysis of RF environment and event failure problems
captured by TEMS Investigation
 TEMS Pocket is performance date and event capture
software which runs on a UE for collection and display in
almost any conceivable location
 TEMS Automatic automonously collects field RF and event
data and uploads it to servers without manual intervention. If
mounted in public transport or commercial service vehicles, it
can collect wide-area data without operation intervention.
August, 2013
Course RF200 v8(c)2013 Scott Baxter
TEMS Pocket
Scanners
TEMS Automatic
Page 351
JDSU RF Tools
 JDSU purchased the wireless test product line of Agilent and has
expanded it to provide end-to-end testing of LTE systems,
integrating RF field-collected data with messaging captured from
the interfaces between RAN and Core Network for powerful event
and root cause analysis
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 352
PCTEL RF Tools
 PCTEL has developed a line of
particularly fast scanning receivers for
all wireless technologies including LTE
 The receivers are substantially faster
than most competitors, allowing much
more dense and revealing RF data to
be collected with less time in the field
 Because of their small size, the
receivers are suitable for both indoor
and outdoor surveys
 Advanced signal processing capability
allows evaluation of MIMO
effectiveness and benchmarking
MIMO results against prior results over
time
Scanning Receivers
Indoor-Outdoor Measured Propagation
LTE Speed, Diversity vs 4-branch Mimo
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 353
Rohde & Schwarz RF Tools
 The Rohde-Schwarz TSMW scanner provides
very rapid scanning and measurement of LTE
parameters
• RSRP, RSRQ narrow and wideband,
RSSI, Ptot, SINR, RS-SINR, ISI, CIR,
Doppler shift, CP type, MIMO CN
• Available technologies LTE-FDD, LTETDD, GSM, WCDMA, CDMA2000,
1xEVDO 0/A/B, WiMAX
• Also integrates/collects UE data
 Rohde-Schwarz ROMES4 post processing
software analyzes data from all technologies
collected by the TSMW scanner and provides
detailed event-processing and messaging
analysis
 The Rohde-Schwarz PR100 real-time
spectrum analyzer is the most advanced and
sensitive interference detection device
available to civilians in the western countries
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 354
Tektronix RF Tools
 Tektronix is a long-established test
equipment manufacturer in both the RF
and network arenas.
 In the RF area, Tektronix does offer
leading-edge spectrum analyzers with
advanced interference detection
capabilities. However, it does not offer a
general field wireless RF optimization
tool to collect messaging and layer-2
data for call processing analysis.
 In the data arena, Tektronix has
developed advanced IP and core network
monitoring tools well-suited to analysis of
LTE systems. These will be described
along with other core-network-centric
tools in the next section.
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 355
LTE Core Network
Monitoring/Optimization Tools
June, 2013
Course RF200 v8 (c)2013 Scott Baxter
Page 356
Core Network Tools
 Core Network Tools monitor the various interfaces within and around the
LTE core network to collect packet and messaging information about
interface and node conditions, failed processing events, traffic levels, and
other network statistics.
 Manufacturers of the core network nodes provide their own generic and
proprietary counters and indicators for the performance of their network
elements and the interfaces they use. These provide the main operational
statistics upon which LTE operators rely on to manage their networks
ordinary operation.
 Test equipment manufacturers provide data monitoring and collection
tools which capture TCP/IP packets and network events. The
manufacturers also provide various software tools for post-analysis of the
collected data, making it possible to zoom in on specific types of packets
and events and drill down to first causes.
 Some tools provide simulation of traffic and simulation of various network
nodes to support core network design and element selection, beyond the
narrower function of optimization.
 Following pages describe available core network analysis tools.
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 357
Tektronix Core Network Tools
 Tektronix provides data probes to monitor all TCP/IP interfaces of an LTE network,
both in the RAN and the Core, along with its IRIS Performance, Traffic and Protocol
analyzers and new Spectra2 XL3 IMS and EP3 test application. These tools can
perform both functional and load testing, to capture and analyze otherwise-obscure
events in the context of numerous protocols.
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 358
JDSU
 JDSU has already been presented in the earlier RAN test pages.
 It also offers extensive core network data collection and analysis
including special emphasis on services such as video/TV and IMS.
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 359
Wireshark
http://www.wireshark.org/download.html
 Wireshark is a free, open-source packet capture and analysis tool
 Wireshark is a “poor man’s friend” tool for high quality (if somewhat
tedious) analysis of packets from any of the LTE RAN and Core
Network interfaces
 The desired packet streams must be captured by other software or
hardware probes
 Many templates for analysis of LTE call processing events are
already available through resource blogs and online collaborations
using Wireshark
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 360
cc
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 361
LTE Key Performance Indicators
August, 2013
Course RF200v8 (c)2013 Scott Baxter
Page 362
General Wireless Key Performance Indicators
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 363
Common LTE Key Performance Indicators (1)
Accessibility
 Initial E-RAB Establishment Success Rate
 Add E-RAB Establishment Success Rate
 Retainability
 E-RAB Retainability
Integrity
 Downlink Latency (first packet)
 Downlink Throughput
 Downlink Packet Loss
 Uplink Latency
 Uplink Throughput
 Downlink Packet Error Loss Rate
 Uplink Packet Loss Rate
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 364
Common LTE Key Performance Indicators (2)
Mobility
 Mobility Success Rate
 Availability
 Cell Availability
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 365
Specific LTE Key Performance Indicators
The Key Performance Indicators for an LTE system fall into several
major groups:
 The most critical function in the E-UTRAN is the scheduling
algorithm implemented in the eNodeB
• This is the most critical and decisive function affecting the user’s
Quality of Service (QoS) and Quality of Experience (QOE)
• The most critical KPIs are those measuring scheduler
effectiveness
 Radio Quality Measurements
 Control Plane Performance Counters and Delay measurements
 User Plane QoS and QoE Measurements
August, 2013
Course RF200 v8(c)2013 Scott Baxter
Page 366