Sie sind auf Seite 1von 536

September, 2002 RF200 - 1 RF200 v3.

73 (c) 2002 Scott Baxter


Wireless CDMA RF
Performance Optimization
Wireless CDMA RF
Performance Optimization
Course RF200
September, 2002 RF200 - 2 RF200 v3.73 (c) 2002 Scott Baxter
Contents
Chapter Slide #
1. Call Processing, Messaging and Performance Indicators 3
2. Analyzing System Performance Data 123
3. Mobile Field Tools and Data Analysis 172
4. Multiple Carrier Systems: Operating Principles and Analysis 252
5. Applied Optimization 278
6. 1xRTT Optimization Issues 318
7. Appendix
Refresher on CDMA Basics 490
Cell Loading Example 515
CDMA/3g1x Books, Publications, Web Resources 529
September, 2002 RF200 - 3 RF200 v3.73 (c) 2002 Scott Baxter
Call Processing, Messaging,
Performance Indicators
Call Processing, Messaging,
Performance Indicators
Course RF200 Section I.
September, 2002 RF200 - 4 RF200 v3.73 (c) 2002 Scott Baxter
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 youll see
September, 2002 RF200 - 5 RF200 v3.73 (c) 2002 Scott Baxter
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 systems life
recognizing and resolving system-design-related issues (cant
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
September, 2002 RF200 - 6 RF200 v3.73 (c) 2002 Scott Baxter
An Aeronautical Analogy: Investigation Tools
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.
Control & Parameters Messaging
BTS
11500 11500
114.50
118.25
130.75
Aeronautical
Investigations
CDMA
Investigations
Flight Data Recorder Cockpit Voice Recorder
Temporal Analyzer Data Layer 3 Message Files
September, 2002 RF200 - 7 RF200 v3.73 (c) 2002 Scott Baxter
The Cockpit Voice Recorder
CDMA Messaging
CDMA Messaging
September, 2002 RF200 - 8 RF200 v3.73 (c) 2002 Scott Baxter
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 users voice traffic
Sync Channel (a forward channel)
Paging Channel (a forward channel)
Access Channel (a reverse channel)
On these channels, there are only messages, continuously all
of the time
Some CDMA channels exist just to carry user traffic
Forward Traffic Channel
Reverse Traffic Channel
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
September, 2002 RF200 - 9 RF200 v3.73 (c) 2002 Scott Baxter
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
MSG_TYPE (00000110)
ACK_SEQ
MSG_SEQ
ACK_REQ
ENCRYPTION
ERRORS_DETECTED
POWER_MEAS_FRAMES
LAST_HDM_SEQ
NUM_PILOTS
PILOT_STRENGTH
RESERVED (0s)
8
3
3
1
2
5
10
2
4
6
0-7
NUM_PILOTS occurrences of this field:
Field
Length
(in bits)
EXAMPLE:
A POWER MEASUREMENT
REPORT MESSAGE
t
September, 2002 RF200 - 10 RF200 v3.73 (c) 2002 Scott Baxter
Message Vocabulary: Acquisition & Idle States
Sync Channel
Sync Channel Msg
Pilot Channel
No Messages
Paging Channel
Access Parameters Msg
System Parameters Msg
CDMA Channel List Msg
Extended System
Parameters Msg
Extended Neighbor
List Msg
Global Service
Redirection Msg
Order Msg
Base Station Acknowledgment
Lock until Power-Cycled
Maintenance required
many others..
Authentication
Challenge Msg
Status Request Msg
Feature Notification Msg
TMSI Assignment Msg
Channel Assignment
Msg
SSD Update Msg
Service Redirection Msg
General Page Msg
Null Msg Data Burst Msg
Access Channel
Registration Msg
Order Msg
Mobile Station Acknowldgment
Long Code Transition Request
SSD Update Confirmation
many others..
Origination Msg
Page Response Msg
Authentication Challenge
Response Msg
Status Response Msg
TMSI Assignment
Completion Message
Data Burst Msg
BTS
September, 2002 RF200 - 11 RF200 v3.73 (c) 2002 Scott Baxter
Message Vocabulary: Conversation State
Reverse Traffic Channel
Order Message
Mobile Sta. Acknowledgment
Long Code Transition
Request
SSD Update Confirmation
Connect
Authentication Challenge
Response Msg
Flash With
Information Msg
Data Burst Message
Pilot Strength
Measurement Msg
Power Measurement
Report Msg
Send Burst DTMF Msg
Origination
Continuation Msg
Handoff Completion Msg
Parameters Response
Message
Service Request Msg
Service Response Msg
Service Connect
Completion Message
Service Option Control
Message
Status Response Msg
TMSI Assignment
Completion Message
Forward Traffic Channel
Order Msg
Base Station Acknowledgment
Base Station Challenge
Confirmation
Message Encryption Mode
Authentication
Challenge Msg
Alert With
Information Msg
Data Burst Msg
Analog Handoff
Direction Msg
In-Traffic System
Parameters Msg
Neighbor List
Update Msg
Send Burst DTMF Msg
Power Control
Parameters Msg.
Retrieve Parameters Msg
Set Parameters Msg
SSD Update Msg
Flash With
Information Msg
Mobile Station
Registered Msg
Status Request Msg
Extended Handoff
Direction Msg
Service Request Msg
Service Response Msg
Service Connect Msg
Service Option
Control Msg
TMSI Assignment Msg
September, 2002 RF200 - 12 RF200 v3.73 (c) 2002 Scott Baxter
CDMA Call Processing Basics
CDMA Call Processing Basics
A minute in the life of a CDMA handset
September, 2002 RF200 - 13 RF200 v3.73 (c) 2002 Scott Baxter
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.
Whats 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, youve got to know call
processing steps and details AND the RF basis of the transmission
September, 2002 RF200 - 14 RF200 v3.73 (c) 2002 Scott Baxter
Lets Acquire the System!
Lets Acquire the System!
Example 1
September, 2002 RF200 - 15 RF200 v3.73 (c) 2002 Scott Baxter
Whats In a Handset? How does it work?
Receiver
RF Section
IF, Detector
Transmitter
RF Section
Vocoder
Digital
Rake Receiver
Traffic Correlator
PN xxx Walsh xx

Traffic Correlator
PN xxx Walsh xx
Traffic Correlator
PN xxx Walsh xx
Pilot Searcher
PN xxx Walsh 0
Viterbi
Decoder
CPU
Duplexer
Transmitter
Digital Section
Long Code Gen.
O
p
e
n


L
o
o
p
Transmit Gain Adjust
Messages
Messages
Audio
Audio
Packets
Symbols
Symbols
Chips
RF
RF
AGC
September, 2002 RF200 - 16 RF200 v3.73 (c) 2002 Scott Baxter
Basic Acquisition On the Current Frequency:
Find Strongest Pilot, Read Sync Channel
Rake Fingers O
O
O
Reference PN
Active Pilot
E
c
/
I
o
0
0
32K
512
Chips
PN
1. Pilot Searcher Scans the Entire Range of PNs
All PN Offsets
0
-20
98/05/24 23:14:09.817 [SCH]
MSG_LENGTH = 208 bits
MSG_TYPE = Sync Channel Message
P_REV = 3
MIN_P_REV = 2
SID = 179
NID = 0
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
2. Put Rake finger(s) on strongest
available PN, decode Walsh 32,
and read Sync Channel Message
SYNC CHANNEL MESSAGE
Handset
Rake Receiver
RF

x

LO
Srch PN??? W0
F1 PN168 W32
F2 PN168 W32
F3 PN168 W32
Is this the right
system to use?
Check the PRL!
September, 2002 RF200 - 17 RF200 v3.73 (c) 2002 Scott Baxter
Finding the Right System:
The System Determination Algorithm
Finding the Right System:
The System Determination Algorithm
September, 2002 RF200 - 18 RF200 v3.73 (c) 2002 Scott Baxter
Is That the best CDMA Signal You Can Find?!!
What weve seen so far is the basic process of signal acquisition
from the applicable CDMA standards
For the simple case where the mobile is already on the right
frequency
What happens if the mobile is in a new city, and the desired CDMA
system is on a different frequency? What if you find a competitor?
Each wireless operator programs its mobiles with information
and a special proprietary procedure to guide it to the right
system, no matter where the mobile is used
This process is called the System Determination Algorithm
(SDA) and it is proprietary, not part of the CDMA standards
The SDA guides the mobile to intelligently search different
frequencies until it finds a CDMA signal
After Sync Channel acquisition, the SDA guides the mobile to
possibly choose a different frequency and look for a more
appropriate system
Janet Jackson: Thats the End?!!!
September, 2002 RF200 - 19 RF200 v3.73 (c) 2002 Scott Baxter
Phone Data Guides System Determination
Preferred Only Bit
TRUE
FALSE
Acquisition Index
0 CDMA channels
CDMA channels
Analog Block
Analog Block
1
2
3
350,400
50, 100
A
B
System Records
SID Priority
4139
NID
65535
PREF
Pref
GEO
New
Index Roam Indicator
More 0 Off
59 65535 Pref Same More 2 On
52 65535 Pref Same More 3 Flash
67 65535 Neg Same Same 3 Short-short-long
4412 65535 Pref New More 1 Off
61737 226 Neg New More 0 Off
: : : : : : :
Every three minutes idle
phones rescan for any more-
preferred signals in the current
Geo Group. This is called
climbing the GEO group.
65535 is a wildcard NID.
The phone is to accept any
NID it sees on this system.
There are 29 Acq Indexes in the current PRL. It
is normal for some to contain duplicate channels.
The last system record is not a real
system. It merely contains the version
number of the PRl and is used by some
phones to allow displaying the version.
Preferred more
than the following
record.
Some records are merely analog
Guideposts to allow the phone to
recognize where it is and position into the
proper GEO group GEO confinement.
When the phone
loses service, it
scans the list of
channels in its
current GEO group.
Handsets can be programmed with their Preferred Only bit set to True or
False. If True, the handset can only used preferred systems. If False, the
handset can use non-preferred systems, but will prefer preferred systems
when available.
September, 2002 RF200 - 20 RF200 v3.73 (c) 2002 Scott Baxter
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
Go to last
frequency
from MRU
Strongest
PN, read
Sync
Is SID
permitted?
No Signal
Preferred
Only Bit
0
Denied SID
Read
Paging
Channel
Is better
SID
available?
PRL MRU Acq Idx
Yes
No
Steps from
the CDMA
standards
Steps from
proprietary
SDAs
Proprietary
SDA
databases
Start
Legend
Typical Mobile
System Determination Algorithm
Best System Found!
Begin Normal Paging Channel Operation
Last Resort:
GEO escape
Or Analog
September, 2002 RF200 - 21 RF200 v3.73 (c) 2002 Scott Baxter
The SDA In Action:
Find a Frequency with a CDMA RF Signal
Mobile scans forward link frequencies:
(Cellular or PCS, depending on model)
History List
Preferred Roaming List
until a CDMA signal is found.
NO CDMA?! Go to AMPS,
or to a power-saving standby mode
HISTORY
LIST/MRU
Last-used:
Freq
Freq
Freq
Freq
Freq
etc.
FREQUENCY LISTS:
PREFERRED
ROAMING
LIST/PRL
System1
System2
System3
System4
System5
etc.
Forward Link Frequencies
(Base Station Transmit)
A D B E F C
unlic.
data
unlic.
voice
A D B E F C
1850MHz. 1910MHz. 1990 MHz. 1930MHz.
1900 MHz. PCS Spectrum
824 MHz. 835 845 870 880 894
869
849
846.5
825
890
891.5
Paging, ESMR, etc.
A B A B
800 MHz. Cellular Spectrum
Reverse Link Frequencies
(Mobile Transmit)
September, 2002 RF200 - 22 RF200 v3.73 (c) 2002 Scott Baxter
Basic Acquisition on the Right System!
Rake Fingers
O
O
O
Ref.
PN
Active Pilot
E
c
/
I
o
0
0
32K
512
Chips
PN
1. Pilot Searcher Scans the Entire Range of PNs
All PN Offsets
0
-20
98/05/24 23:14:09.817 [SCH]
MSG_LENGTH = 208 bits
MSG_TYPE = Sync Channel Message
P_REV = 3
MIN_P_REV = 2
SID = 179
NID = 0
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
2. Put Rake finger(s) on strongest
available PN, decode Walsh 32,
and read Sync Channel Message
SYNC CHANNEL MESSAGE
Handset
Rake Receiver
RF

x

LO
Srch PN??? W0
F1 PN168 W32
F2 PN168 W32
F3 PN168 W32
If PRL says:
This is the Best
Available System!
Go to the
Paging
Channel!
September, 2002 RF200 - 23 RF200 v3.73 (c) 2002 Scott Baxter
After Finding the Right System:
Normal Paging Channel Operation
After Finding the Right System:
Normal Paging Channel Operation
September, 2002 RF200 - 24 RF200 v3.73 (c) 2002 Scott Baxter
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
Collection is a short process -- all configuration messages are
repeated on the paging channel every 1.28 seconds
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
September, 2002 RF200 - 25 RF200 v3.73 (c) 2002 Scott Baxter
Reading the Configuration Messages
Rake Fingers
O
O
O
Reference PN
Active Pilot
E
c
/
I
o
0
0
32K
512
Chips
PN
All PN Offsets
0
-20
Keep Rake finger(s) on strongest
available PN, monitor Walsh 1,
the Paging Channel
Read the
Configuration Messages
Access Parameters Msg
System Parameters Msg
CDMA Channel List Msg
Extended System
Parameters Msg (*opt.)
(Extended*) Neighbor
List Msg
Global Service
Redirection Msg (*opt.)
Now were ready to operate!!
Handset
Rake Receiver
RF

x

LO
Srch PN??? W0
F1 PN168 W01
F2 PN168 W01
F3 PN168 W01
September, 2002 RF200 - 26 RF200 v3.73 (c) 2002 Scott Baxter
The Access Parameters Message
98/05/24 23:14:10.427 [PCH]
MSG_LENGTH = 184 bits
MSG_TYPE = Access Parameters Message
PILOT_PN = 168 Offset Index
ACC_MSG_SEQ = 27
ACC_CHAN = 1 channel
NOM_PWR = 0 dB INIT_PWR = 0 dB PWR_STEP = 4 dB
NUM_STEP = 5 Access Probes Maximum
MAX_CAP_SZ = 4 Access Channel Frames Maximum
PAM_SZ = 3 Access Channel Frames
Persist Val for Acc Overload Classes 0-9 = 0
Persist Val for Acc Overload Class 10 = 0
Persist Val for Acc Overload Class 11 = 0
Persist Val for Acc Overload Class 12 = 0
Persist Val for Acc Overload Class 13 = 0
Persist Val for Acc Overload Class 14 = 0
Persist Val for Acc Overload Class 15 = 0
Persistance Modifier for Msg Tx = 1
Persistance Modifier for Reg = 1
Probe Randomization = 15 PN chips
Acknowledgement Timeout = 320 ms
Probe Backoff Range = 4 Slots Maximum
Probe Sequence Backoff Range = 4 Slots Max.
Max # Probe Seq for Requests = 2 Sequences
Max # Probe Seq for Responses = 2 Sequences
Authentication Mode = 1
Random Challenge Value = Field Omitted
Reserved Bits = 99
ACCESS PARAMETERS MESSAGE
BTS
Any Access Msg
MS
Probing
The Access Procedure
a Probe Sequence
an Access Attempt
Success!
an Access Probe
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
September, 2002 RF200 - 27 RF200 v3.73 (c) 2002 Scott Baxter
Phone Operation on the Access Channel
A sectors 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
ACCESS
RV TFC
BTS
Channel Assnmt. Msg.
Origination Msg
Base Sta. Acknlgmt. Order
TFC frames of 000s
TFC preamble of 000s
Base Sta. Acknlgmt. Order
Mobile Sta. Ackngmt. Order
Service Connect Msg.
Svc. Connect Complete Msg
Base Sta. Acknlgmt. Order
Call is Established!
MS
Probing
PAGING
FW TFC
PAGING
RV TFC
FW FC
RV TFC
FW TFC
FW TFC
A Successful Access Attempt
a Probe Sequence
an Access Attempt
Success!
an Access Probe
September, 2002 RF200 - 28 RF200 v3.73 (c) 2002 Scott Baxter
The System Parameters Message
98/05/24 23:14:11.126 [PCH] MSG_LENGTH = 264 bits
MSG_TYPE = System Parameters Message
PILOT_PN = 168 Offset Index
CONFIG_MSG_SEQ = 0
SID = 179 NID = 0
REG_ZONE = 0 TOTAL_ZONES = 0 ZONE_TIMER = 60 min
MULT_SIDS = 0 MULT_NID = 0 BASE_ID = 8710
BASE_CLASS = Public Macrocellular
PAGE_CHAN = 1 channel
MAX_SLOT_CYCLE_INDEX = 0
HOME_REG = 0 FOR_SID_REG = 0 FOR_NID_REG = 1
POWER_UP_REG = 0 POWER_DOWN_REG = 0
PARAMETER_REG = 1 REG_PRD = 0.08 sec
BASE_LAT = 00D00'00.00N BASE_LONG = 000D00'00.00E
REG_DIST = 0
SRCH_WIN_A = 40 PN chips
SRCH_WIN_N = 80 PN chips
SRCH_WIN_R = 4 PN chips
NGHBR_MAX_AGE = 0
PWR_REP_THRESH = 2 frames
PWR_REP_FRAMES = 56 frames
PWR_THRESH_ENABLE = 1
PWR_PERIOD_ENABLE = 0
PWR_REP_DELAY = 20 frames
RESCAN = 0
T_ADD = -13.0 Db T_DROP = -15.0 dB T_COMP = 2.5 dB
T_TDROP = 4 sec
EXT_SYS_PARAMETER = 1
RESERVED = 0
GLOBAL_REDIRECT = 0
SYSTEM PARAMETERS MESSAGE
Who Registers?
Why & When?
Search Window
Widths
How mobile can complain
If traffic channel is too weak
Handoff Thresholds
# Paging Channels, Slotted Mode period
September, 2002 RF200 - 29 RF200 v3.73 (c) 2002 Scott Baxter
The Extended System Parameters Message
The main job of this message is
to tell mobiles how to report
their identities when they
transmit on the Access Channel
IMSI - International Mobile
Subscriber Identity
The world phone
number of the mobile
ESN - Electronic Serial
Number
Different Networks may request
different identification modes;
the phones simply comply
IMSI and ESN
IMSI only
ESN only
98/05/24 23:14:10.946 [PCH]
Extended System Parameters Message
MSG_LENGTH = 104 bits
MSG_TYPE = Extended System Parameters Message
PILOT_PN = 168 Offset Index
CONFIG_MSG_SEQ = 0 RESERVED = 0
PREF_MSID_TYPE = IMSI and ESN
MCC = 000 IMSI_11_12 = 00
RESERVED_LEN = 8 bits
RESERVED_OCTETS = 0x00
BCAST_INDEX = 0
RESERVED = 0
EXTENDED SYSTEM PARAMETERS
September, 2002 RF200 - 30 RF200 v3.73 (c) 2002 Scott Baxter
The Neighbor List Message
The Neighbor List Message gives the
mobile up to 20 PN offsets of sectors it
may soon need in handoff
This enables the mobile to search
smarter and faster
On the paging channel, Enhanced or
Extended neighbor lists may also include
neighbors on different frequencies
Slotted mode mobiles can jump to
other frequencies in their sleep
time to check pilots
This is useful at system boundaries
During a call, a mobile first uses the
neighbor list remembered from idle mode
After each handoff, a new Neighbor
List Update message is sent to the
mobile on the Forward Traffic
Channel
Each neighbor list received by the mobile
overwrites and replaces the previous
neighbor list
98/05/24 23:14:11.486 [PCH] Neighbor List Message
MSG_LENGTH = 216 bits
MSG_TYPE = Neighbor List Message
PILOT_PN = 168 Offset Index
CONFIG_MSG_SEQ = 0
PILOT_INC = 4 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 220 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 52 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 500 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 8 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 176 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 304 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 136 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 384 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 216 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 68 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 328 Offset Index
NGHBR_CONFIG = 0 NGHBR_PN = 112 Offset Index
RESERVED = 0
NEIGHBOR LIST
September, 2002 RF200 - 31 RF200 v3.73 (c) 2002 Scott Baxter
The CDMA Channel List Message
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
The mobile immediately uses
a random selection process
called hashing to select one
of the listed channels
The outcome of hashing
depends only on the
mobiles IMSI
Both the system and the
mobile know which carrier
the mobile will choose
98/05/24 23:14:10.786 [PCH] CDMA Channel List
Message
MSG_LENGTH = 72 bits
MSG_TYPE = CDMA Channel List Message
PILOT_PN = 168 Offset Index
CONFIG_MSG_SEQ = 0
CDMA_FREQ = 283
RESERVED = Field Omitted
CDMA CHANNEL LIST MESSAGE
CDMA Ch
List Message
HASH using
IMSI
F1
F2
F3
F
now
September, 2002 RF200 - 32 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 33 RF200 v3.73 (c) 2002 Scott Baxter
Hashing Examples
Try your own phone in the spreadsheet Hashing.xls (in utilities folder)
Hashing Examples Time between active slots, seconds:
v2. 1-28-2000 1.28 2.56 5.12 10.24 20.48 40.96 81.92 163.84
Number of Slots in Mobile's Cycle:
16 32 64 128 256 512 1024 2048
Key in red-shaded
How Many
Frequencies?
How Many Paging
Channels? Slot Cycle Index:
values
2 1 0 1 2 3 4 5 6 7
10 Digit IMSI Use Freq. # Use PCH # Slot# Slot# Slot# Slot# Slot# Slot# Slot# Slot#
6153000124
1 1 15 31 63 127 127 383 895 895
6153000125 1 1 11 27 27 27 27 27 539 1563
6153000126
1 1 5 5 5 69 69 69 69 69
6153000127
1 1 3 3 3 67 195 451 451 1475
6153000128
2 1 8 24 24 24 152 152 152 1176
6153000129 2 1 9 25 25 25 25 25 25 25
6153000130
1 1 11 27 27 27 27 27 539 1563
6153000131
2 1 1 1 33 97 225 225 737 737
6153000132
1 1 8 8 40 40 40 40 552 552
6153000133 1 1 3 19 51 115 243 243 755 755
September, 2002 RF200 - 34 RF200 v3.73 (c) 2002 Scott Baxter
The Global Service Redirection Message
The GSRM was originally
intended as a way to
solve system and
multicarrier border
problems
Outermost F2 cells
transmit GSRM,
sending distant F2
mobiles to F1
The GSRM can also be
used to manually
distribute idle mobiles to
different frequencies
A GSRM applies only
to phones of Access
Overload Classes
specified in the
message
98/05/17 24:21.566 Paging Channel: Global Service Redirection
PILOT_PN: 168, MSG_TYPE: 96, CONFIG_MSG_SEQ: 0
Redirected access overload classes: { 0, 1 },
RETURN_IF_FAIL: 0,
DELETE_TMSI: 0,
Redirection to an analog system:
EXPECTED_SID = 0
Do not ignore CDMA Available indicator on the redirected analog
system
Attempt service on either System A or B with the custom system
selection process
GLOBAL SERVICE REDIRECTION
If a GSRM applies to you, GO!!
CDMA Carrier Frequency 2
CDMA Carrier Frequency 1
GSRM
September, 2002 RF200 - 35 RF200 v3.73 (c) 2002 Scott Baxter
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 mobiles 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)
Go to last
frequency
from MRU
Strongest
PN, read
Sync
Is SID
permitted?
No Signal
Preferred
Only Bit
0
Denied SID
Read
Paging
Channel
CDMA Ch
List Message
Global Svc
Redir Msg
HASH using
IMSI
my ACCOLC?
redirect
Is better
SID
available?
PRL MRU Acq Idx
Yes
No
F1
F2
F3
to Analog
to another CDMA frequency or system
Config
Messages:
remain
Steps from
the CDMA
standards
Steps from
proprietary
SDAs
Proprietary
SDA
databases
Start
Legend
System Determination Algorithm
Last Resort:
GEO escape
Or Analog
Idle Mode Carrier Selection
September, 2002 RF200 - 36 RF200 v3.73 (c) 2002 Scott Baxter
MultiCarrier Operation:
Big-Picture View of Frequency Changes
MultiCarrier Operation:
Big-Picture View of Frequency Changes
September, 2002 RF200 - 37 RF200 v3.73 (c) 2002 Scott Baxter
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
f5
f4
f3
f2
f1
System
Acquisition
Idle Mode
Reselection
Call Start:
Ch. Assignment
In Call:
Hard Handoff
MRU
SDA
PRL-AI
Hashing
GSRM
Multi-
Freq
Nbrs
Proprietary
Network
Algorithms
Nortel: MCTA
Lucent:
Motorola:
Auxiliary
Handoff Triggers
Beacons
Ec/Io, RTD
Proprietary
Processes
Remember: Different Mechanisms Apply at Different Stages
September, 2002 RF200 - 38 RF200 v3.73 (c) 2002 Scott Baxter
Many Network/Carrier Configurations are Possible!
f1
f2
f3
f4
Basic Multi-Carrier
Operation
IS-95
IS-95
IS-95
IS-95
f1
f2
f3
f4
Non-originating carriers
can carry more traffic!
IS-95
IS-95
IS-95
IS-95
f1
f2
f3
f4
Some Carriers may
support 1xRTT
1xRTT
IS-95
IS-95
IS-95
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
W
0



P
i
l
o
t
w
3
2
S
y
n
c
w
1
P
a
g
i
n
g
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a

D
a
t
a
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
w
1
P
a
g
i
n
g
September, 2002 RF200 - 39 RF200 v3.73 (c) 2002 Scott Baxter
Lets Do An Idle Mode
Handoff!
Lets Do An Idle Mode
Handoff!
Example 2
September, 2002 RF200 - 40 RF200 v3.73 (c) 2002 Scott Baxter
Idle Mode Handoff
An idle mobile always demodulates the best available signal
In idle mode, it isnt 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, not
synchronous -- just like ABC, NBC, CBS, and CNN TV news
programs arent in word-sync for simultaneous viewing
Since a mobile cant combine signals, the mobile must switch
quickly, always enjoying the best available signal
The mobiles pilot searcher is constantly checking neighbor pilots
If the searcher notices a better signal, the mobile continues on the
current paging channel until the end of the current superframe,
then instantly switches to the paging channel of the new signal
The system doesnt know the mobile did this! (Does NBCs
Tom Brokaw know you just switched your TV to CNN?)
On the new paging channel, if the mobile learns that registration is
required, it re-registers on the new sector
September, 2002 RF200 - 41 RF200 v3.73 (c) 2002 Scott Baxter
Idle Mode on the Paging Channel:
Meet the Neighbors, track the Strongest Pilot
E
c
/
I
o
All PN Offsets
0
0
32K
512
Chips
PN
0
-20
Neighbor Set
The phones pilot searcher constantly checks
the pilots listed in the Neighbor List Message
If the searcher ever notices a neighbor pilot substantially stronger than
the current reference pilot, it becomes the new reference pilot
and the phone switches over to its paging channel on the next superframe.
This is called an idle mode handoff.
Rake Fingers O
O
O
Reference PN
Active Pilot
SRCH_WIN_A
SRCH_WIN_N
Mobile Rake RX
Srch PN??? W0
F1 PN168 W01
F2 PN168 W01
F3 PN168 W01
September, 2002 RF200 - 42 RF200 v3.73 (c) 2002 Scott Baxter
Lets Register!
Lets Register!
Example 3
September, 2002 RF200 - 43 RF200 v3.73 (c) 2002 Scott Baxter
Registration
Registration is the process by which an idle mobile lets the system
know its awake and available for incoming calls
this allows the system to inform the mobiles home switch of
the mobiles 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
September, 2002 RF200 - 44 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Paging
Channel
Registration
BTS
Registration Message (by PROBING)
Base Station Acknowledgment Order
September, 2002 RF200 - 45 RF200 v3.73 (c) 2002 Scott Baxter
An Actual Registration
16:18:27.144 Access Channel: Registration
ACK_SEQ: 7 MSG_SEQ: 1 ACK_REQ: 1 VALID_ACK: 0
ACK_TYPE: 0
MSID_TYPE: 3, ESN: [0x 01 99 0d fc]
MFR 1, Reserved 38, Serial Number 69116,
IMSI: (Class: 0, Class_0_type: 1) [0x 01 8d 31 74 29 36]
00-416-575-0421
AUTH_MODE: 0
REG_TYPE: Timer-based
SLOT_CYCLE_INDEX: 2
MOB_P_REV: 1
EXT_SCM: 1
SLOTTED_MODE: 1
MOB_TERM: 1
REGISTRATION MESSAGE
18:26.826 [PCH] System Parameters Message
Pilot_PN: 32
CONFIG_MSG_SEQ: 14 SID: 16420 NID: 0,
REG_ZONE: 0 TOTAL_ZONES: 0 Zone timer length (min): 1
MULT_SIDS: 0 MULT_NIDS: 0
BASE_ID: 1618 BASE_CLASS: Reserved
PAG_CHAN: 1 MAX_SLOT_CYCLE_INDEX: 2
HOME_REG: 1 FOR_SID_REG: 1 FOR_NID_REG: 1,
POWER_UP_REG: 1 POWER_DOWN_REG: 1
PARAMETER_REG: 1 Registration period (sec): 54
Base station 00000.00 Lon., 00000.00 Lat. REG_DIST: 0
SRCH_WIN_A (PN chips): 28 SRCH_WIN_N (PN chips): 100,
SRCH_WIN_R (PN chips): 130 NGHBR_MAX_AGE: 2
PWR_REP_THRESH: 2 PWR_REP_FRAMES (frames): 15
PWR_THRESH_ENABLE: 1 PWR_PERIOD_ENABLE: 0,
PWR_REP_DELAY: 1 (4 frames) RESCAN: 0,
T_ADD: -14.0dB T_DROP: -16.0dB T_COMP: 2.5dB,
T_TDROP: 4s
EXT_SYS_PARAMETER: 1
EXT_NGHBR_LIST: 1
GLOBAL_REDIRECT: 0
SYSTEM PARAMETERS MESSAGE
16:18:27.506 Paging Channel: Order
ACK_SEQ: 1 MSG_SEQ: 0 ACK_REQ: 0 VALID_ACK: 1
MSID_TYPE: 2 IMSI: (Class: 0, Class_0_type: 3)
[0x 02 47 8d 31 74 29 36] (302) 00-416-575-0421
Order type: Base Station Acknowledgement Order
BASE STATION ACKNOWLEDGMENT
The System Parameters Message tells
all mobiles when they should register.
This mobile notices that it is obligated to
register, so it transmits a Registration
Message.
The base station confirms that the
mobiles registration message was
received. Were officially registered!
September, 2002 RF200 - 46 RF200 v3.73 (c) 2002 Scott Baxter
Lets Receive an Incoming
Call!
Lets Receive an Incoming
Call!
Example 4
September, 2002 RF200 - 47 RF200 v3.73 (c) 2002 Scott Baxter
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 others 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.
September, 2002 RF200 - 48 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Reverse
Traffic
Channel
Paging
Channel
Incoming Call Delivery Scenario
BTS
General Page Message
Page Response Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Traffic Channel Preamble: Frames of 000s
Continuous frames of all 000s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
Forward
Traffic
Channel
September, 2002 RF200 - 49 RF200 v3.73 (c) 2002 Scott Baxter
An Actual Page and Page Response
98/05/24 23:14:46.425 [ACH] Page Response Message
MSG_LENGTH = 216 bits
MSG_TYPE = Page Response Message
ACK_SEQ = 1 MSG_SEQ = 2 ACK_REQ = 1
VALID_ACK = 1 ACK_TYPE = 2
MSID_TYPE = IMSI and ESN MSID_LEN = 9 octets
ESN = 0xD30E415C IMSI_CLASS = 0
IMSI_CLASS_0_TYPE = 0 RESERVED = 0
IMSI_S = 6153300644
AUTH_MODE = 1
AUTHR = 0x307B5 RANDC = 0xC6 COUNT = 0
MOB_TERM = 1 SLOT_CYCLE_INDEX = 0
MOB_P_REV = 3 SCM = 106
REQUEST_MODE = Either Wide Analog or CDMA Only
SERVICE_OPTION = 32768 PM = 0
NAR_AN_CAP = 0 RESERVED = 0
PAGE RESPONSE MESSAGE
98/05/24 23:14:46.127 [PCH] General Page Message
MSG_LENGTH = 128 bits
MSG_TYPE = General Page Message
CONFIG_MSG_SEQ = 1 ACC_MSG_SEQ = 20
CLASS_0_DONE = 1
CLASS_1_DONE = 1 RESERVED = 0
BROADCAST_DONE = 1 RESERVED = 0
ADD_LENGTH = 0 bits ADD_PFIELD = Field Omitted
PAGE_CLASS = 0 PAGE_SUBCLASS = 0
MSG_SEQ = 1
IMSI_S = 6153300644
SPECIAL_SERVICE = 1
SERVICE_OPTION = 32768
RESERVED = Field Omitted
GENERAL PAGE MESSAGE
98/05/24 23:14:46.768 [PCH] Order Message
MSG_LENGTH = 112 bits
MSG_TYPE = Order Message
ACK_SEQ = 2 MSG_SEQ = 0 ACK_REQ = 0
VALID_ACK = 1
ADDR_TYPE = IMSI ADDR_LEN = 40 bits
IMSI_CLASS = 0 IMSI_CLASS_0_TYPE = 0 RESERVED = 0
IMSI_S = 6153300644
ORDER = Base Station Acknowledgement Order
ADD_RECORD_LEN = 0 bits
Order-Specific Fields = Field Omitted RESERVED = 0
BASE STATION ACKNOWLEDGMENT
The system pages the mobile,
615-330-0644.
The base station confirms that the mobiles
page response was received. Now the
mobile is waiting for channel assignment,
expecting a response within 12 seconds.
The mobile responds to the page.
September, 2002 RF200 - 50 RF200 v3.73 (c) 2002 Scott Baxter
Channel Assignment and
Traffic Channel Confirmation
18:14:47.598 Reverse Traffic Channel: Order
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: 0
ENCRYPTION: 0
Mobile Station Acknowledgement Order
MOBILE STATION ACKNOWLEDGMENT
18:14:47.027 Paging Channel: Channel Assignment
ACK_SEQ: 2 MSG_SEQ: 1 ACK_REQ: 0 VALID_ACK: 1
MSID_TYPE: 2 IMSI: (Class: 0, Class_0_type: 0)
[0x 01 f8 39 6a 15] 615-330-0644
ASSIGN_MODE: Traffic Channel Assignment
ADD_RECORD_LEN: 5 FREQ_INCL: 1 GRANTED_MODE: 2
CODE_CHAN: 43 FRAME_OFFSET: 2
ENCRYPT_MODE: Encryption disabled
BAND_CLASS: 800 MHz cellular band
CDMA_FREQ: 283
CHANNEL ASSIGNMENT MESSAGE
18:14:47.581 Forward Traffic Channel: Order
ACK_SEQ: 7 MSG_SEQ: 0 ACK_REQ: 1
ENCRYPTION: 0 USE_TIME: 0 ACTION_TIME: 0
Base Station Acknowledgement Order
BASE STATION ACKNOWLEDGMENT
Only about 400 ms. after the base station
acknowledgment order, the mobile receives
the channel assignment message.
The base station is already
sending blank frames on
the forward channel,using
the assigned Walsh code.
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 mobiles preamble.
The mobile station acknowledges the
base stations acknowledgment.
Everybody is ready!
September, 2002 RF200 - 51 RF200 v3.73 (c) 2002 Scott Baxter
Service Negotiation and Mobile Alert
18:14:47.835 Reverse Traffic Channel:
Service Connect Completion
ACK_SEQ: 1 MSG_SEQ: 3 ACK_REQ: 1
ENCRYPTION: 0 SERV_CON_SEQ: 0
SERVICE CONNECT COMPLETE MSG.
18:14:47.760 Forward Traffic Channel: Service Connect
ACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: 0 ENCRYPTION: 0
USE_TIME: 0 ACTION_TIME: 0 SERV_CON_SEQ: 0
Service Configuration: supported Transmission:
Forward Traffic Channel Rate (Set 2): 14400, 7200, 3600, 1800 bps
Reverse Traffic Channel Rate (Set 2): 14400, 7200, 3600, 1800 bps
Service option: (6) Voice (13k) (0x8000)
Forward Traffic Channel: Primary Traffic
Reverse Traffic Channel: Primary Traffic
SERVICE CONNECT MESSAGE
Now that both sides have arrived on the
traffic channel, the base station
proposes that the requested call
actually begin.
The mobile agrees and
says its ready to play.
18:14:47.961 Forward Traffic Channel:
Alert With Information
ACK_SEQ: 3 MSG_SEQ: 1 ACK_REQ: 1 ENCRYPTION: 0
SIGNAL_TYPE = IS-54B Alerting
ALERT_PITCH = Medium Pitch (Standard Alert)
SIGNAL = Long RESERVED = 0
RECORD_TYPE = Calling Party Number
RECORD_LEN = 96 bits
NUMBER_TYPE = National Number
NUMBER_PLAN = ISDN/Telephony Numbering Plan
PI = Presentation Allowed SI = Network Provided
CHARi = 6153000124 RESERVED = 0 RESERVED = 0
ALERT WITH INFORMATION MESSAGE
The base station orders the mobile to ring, and
gives it the calling partys number to display.
18:14:48.018 Reverse Traffic Channel: Order
ACK_SEQ: 1 MSG_SEQ: 4 ACK_REQ: 0
ENCRYPTION: 0
Mobile Station Acknowledgement Order
The mobile says its ringing.
SERVICE CONNECT COMPLETE is a
major milestone in call processing. Up
until now, this was an access attempt.
Now it is officially a call.
September, 2002 RF200 - 52 RF200 v3.73 (c) 2002 Scott Baxter
The Human Answers! Connect Order
The mobile has been ringing for several
seconds. The human user finally
comes over and presses the send
button to answer the call.
Now the switch completes the audio circuit and
the two callers can talk!
18:14:54.920 Forward Traffic Channel: Order
ACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: 0
ENCRYPTION: 0 USE_TIME: 0 ACTION_TIME: 0
Base Station Acknowledgement Order
BASE STATION ACKNOWLEDGMENT
18:14:54.758 Reverse Traffic Channel: Order
ACK_SEQ: 6 MSG_SEQ: 0 ACK_REQ: 1
ENCRYPTION: 0
Connect Order
CONNECT ORDER
September, 2002 RF200 - 53 RF200 v3.73 (c) 2002 Scott Baxter
Lets Make An Outgoing Call!
Lets Make An Outgoing Call!
Example 5.
September, 2002 RF200 - 54 RF200 v3.73 (c) 2002 Scott Baxter
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 others 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.
September, 2002 RF200 - 55 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Reverse
Traffic
Channel
Paging
Channel
Mobile-Originated Call Scenario
BTS
Origination Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Traffic Channel Preamble: Frames of 000s
Continuous frames of all 000s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
Forward
Traffic
Channel
September, 2002 RF200 - 56 RF200 v3.73 (c) 2002 Scott Baxter
Origination
17:48:53.144 Access Channel: Origination
ACK_SEQ: 7 MSG_SEQ: 6 ACK_REQ: 1
VALID_ACK: 0 ACK_TYPE: 0 MSID_TYPE: 3
ESN: [0x 00 06 98 24] MFR 0 Reserved 1
Serial Number 170020
IMSI: (Class: 0, Class_0_type: 0)
[0x 03 5d b8 97 c2] 972-849-5073
AUTH_MODE: 0 MOB_TERM: 1
SLOT_CYCLE_INDEX: 2 MOB_P_REV: 1 EXT_SCM: 1
DualMode: 0 SLOTTED_MODE: 1 PowerClass: 0
REQUEST_MODE: CDMA only SPECIAL_SERVICE: 1
Service option: (6) Voice (13k) (0x8000) PM: 0
DIGIT_MODE: 0 MORE_FIELDS: 0 NUM_FIELDS: 11
Chari: 18008900829
NAR_AN_CAP: 0
ORIGINATION MESSAGE
17:48:53.487 Paging Channel: Order
ACK_SEQ: 6 MSG_SEQ: 0 ACK_REQ: 0 VALID_ACK: 1
MSID_TYPE: 2
IMSI: (Class: 0, Class_0_type: 0)
[0x 03 5d b8 97 c2] 972-849-5073
Base Station Acknowledgment Order
BASE STATION ACKNOWLEDGMENT
The mobile sends an
origination message
on the access
channel.
The base station confirms
that the origination message
was received.
17:48:54.367 Paging Channel: Channel Assignment
ACK_SEQ: 6 MSG_SEQ: 1 ACK_REQ: 0 VALID_ACK: 1
MSID_TYPE: 2
IMSI: (Class: 0, Class_0_type: 0)
[0x 03 5d b8 97 c2] 972-849-5073
ASSIGN_MODE: Traffic Channel Assignment,
ADD_RECORD_LEN: 5 FREQ_INCL: 1 GRANTED_MODE: 2
CODE_CHAN: 12 FRAME_OFFSET: 0
ENCRYPT_MODE: Encryption disabled
BAND_CLASS: 1.8 to 2.0 GHz PCS band
CDMA_FREQ: 425
CHANNEL ASSIGNMENT MESSAGE
The base station sends a
Channel Assignment
Message and the mobile
goes to the traffic channel.
September, 2002 RF200 - 57 RF200 v3.73 (c) 2002 Scott Baxter
Traffic Channel Confirmation
17:48:54.835 Reverse Traffic Channel: Order
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: 0
ENCRYPTION: 0
Mobile Station Acknowledgment Order
MOBILE STATION ACKNOWLEDGMENT
17:48:54.757 Forward Traffic Channel: Order
ACK_SEQ: 7 MSG_SEQ: 0 ACK_REQ: 1 ENCRYPTION: 0
USE_TIME: 0 ACTION_TIME: 0
Base Station Acknowledgment Order
BASE STATION ACKNOWLEDGMENT
The base station is already
sending blank frames on
the forward channel,using
the assigned Walsh code.
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 mobiles preamble.
The mobile station acknowledges the
base stations acknowledgment.
Everybody is ready!
September, 2002 RF200 - 58 RF200 v3.73 (c) 2002 Scott Baxter
Service Negotiation and Connect Complete
17:48:55.137 Reverse Traffic Channel: Service Connect
Completion ACK_SEQ: 1, MSG_SEQ: 0, ACK_REQ: 1,
ENCRYPTION: 0, SERV_CON_SEQ: 0
SERVICE CONNECT COMPLETE MSG.
17:48:55.098 Forward Traffic Channel: Service Connect
ACK_SEQ: 7 MSG_SEQ: 1 ACK_REQ: 1 ENCRYPTION: 0
USE_TIME: 0 ACTION_TIME: 0 SERV_CON_SEQ: 0
Service Configuration Supported Transmission:
Forward Traffic Channel Rate (Set 2): 14400, 7200, 3600, 1800 bps
Reverse Traffic Channel Rate (Set 2): 14400, 7200, 3600, 1800 bps
Service option: (6) Voice (13k) (0x8000)
Forward Traffic Channel: Primary Traffic
Reverse Traffic Channel: Primary Traffic
SERVICE CONNECT MESSAGE
Now that the traffic channel is working
in both directions, the base station
proposes that the requested call
actually begin.
The mobile agrees and
says its ready to play.
17:48:55.779 Forward Traffic Channel: Order
ACK_SEQ: 0 MSG_SEQ: 0 ACK_REQ: 0 ENCRYPTION: 0
USE_TIME: 0 ACTION_TIME: 0
Base Station Acknowledgment Order
BASE STATION ACKNOWLEDGMENT
The base station agrees.
SERVICE CONNECT COMPLETE is a
major milestone in call processing. Up
until now, this was an access attempt.
Now it is officially a call.
Now the switch completes the audio circuit and
the two callers can talk!
September, 2002 RF200 - 59 RF200 v3.73 (c) 2002 Scott Baxter
Lets End A Call!
Lets End A Call!
Example 6
September, 2002 RF200 - 60 RF200 v3.73 (c) 2002 Scott Baxter
Ending A Call
A normal call continues until one of the parties hangs up. That
action sends a Release Order, normal release.
The other side of the call sends a Release Order, no reason given.
If a normal release is visible, the call ended normally.
At the conclusion of the call, the mobile reacquires the system.
Searches for the best pilot on the present CDMA frequency
Reads the Sync Channel Message
Monitors the Paging Channel steadily
Several different conditions can cause a call to end abnormally:
the forward link is lost at the mobile, and a fade timer acts
the reverse link is lost at the base station, and a fade timer acts
a number of forward link messages arent acknowledged, and the
base station acts to tear down the link
a number of reverse link messages arent acknowledged, and the
mobile station acts to tear down the link
September, 2002 RF200 - 61 RF200 v3.73 (c) 2002 Scott Baxter
A Beautiful End to a Normal Call
17:49:21.715 Reverse Traffic Channel: Order
ACK_SEQ: 1 MSG_SEQ: 1 ACK_REQ: 1
ENCRYPTION: 0
Release Order (normal release)
MOBILE RELEASE ORDER
BASE STATION ACKNOWLEDGMENT
17:49:21.936 Forward Traffic Channel: Order
ACK_SEQ: 1 MSG_SEQ: 2 ACK_REQ: 0 ENCRYPTION: 0,
USE_TIME: 0 ACTION_TIME: 0
Base Station Acknowledgement Order
At the end of a normal call, this
mobile user pressed end.
The mobile left the traffic channel,
scanned to find the best pilot, and read
the Sync Channel Message.
BASE STATION RELEASE ORDER
17:49:21.997 Forward Traffic Channel: Order
ACK_SEQ: 1 MSG_SEQ: 3 ACK_REQ: 0 ENCRYPTION: 0
USE_TIME: 0 ACTION_TIME: 0
Release Order (no reason given)
17:49:22.517 Sync Channel
MSG_TYPE: 1 Sync Channel Message
P_REV: 1 MIN_P_REV: 1
SID: 4112 NID: 2 Pilot_PN: 183
LC_STATE: 0x318fe5d84a5
SYS_TIME: 0x1ae9683dc
LP_SEC: 9 LTM_OFF: -10 DAYLT: 1
Paging Channel Data Rate: 9600
CDMA_FREQ: 425
SYNC CHANNEL MESSAGE
The base station acknowledged
receiving the message, then sent
a release message of its own.
September, 2002 RF200 - 62 RF200 v3.73 (c) 2002 Scott Baxter
Lets receive Notification
of a Voice Message!
Lets receive Notification
of a Voice Message!
Example 7
September, 2002 RF200 - 63 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Paging
Channel
Voice Mail Notification
BTS
Mobile Station Ackmt. (by PROBING)
Feature Notification Message
Base Station Acknowledgment Order
September, 2002 RF200 - 64 RF200 v3.73 (c) 2002 Scott Baxter
Feature Notification
98/06/30 21:16:44.368 [PCH] Feature Notification Message
MSG_LENGTH = 144 bits
MSG_TYPE = Feature Notification Message
ACK_SEQ = 0
MSG_SEQ = 0
ACK_REQ = 1
VALID_ACK = 0
ADDR_TYPE = IMSI
ADDR_LEN = 56 bits
IMSI_CLASS = 0
IMSI_CLASS_0_TYPE = 3
RESERVED = 0
MCC = 302
IMSI_11_12 = 00
IMSI_S = 9055170325
RELEASE = 0
RECORD_TYPE = Message Waiting
RECORD_LEN = 8 bits
MSG_COUNT = 1
RESERVED = 0
FEATURE NOTIFICATION MESSAGE
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.
The mobile confirms it has received the
notification by sending a Mobile Station
Acknowledgment Order on the access
channel.
MOBILE STATION ACKNOWLEDGMENT
September, 2002 RF200 - 65 RF200 v3.73 (c) 2002 Scott Baxter
Lets Do A Handoff!
Lets Do A Handoff!
Example 8
September, 2002 RF200 - 66 RF200 v3.73 (c) 2002 Scott Baxter
The Complete Rules of Soft Handoff
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
6
5
Remaining
Active
Candidate
Neighbor 20
PILOT SETS
M
i
n
.

M
e
m
b
e
r
s
R
e
q

d
.

B
y

S
t
d
.
T_COMP
T_ADD T_DROP
T_TDROP
HANDOFF
PARAMETERS
Exercise: How does a pilot
in one set migrate into
another set, for all cases?
Identify the trigger, and the
messages involved.
September, 2002 RF200 - 67 RF200 v3.73 (c) 2002 Scott Baxter
The Call is Already Established. What Next?
E
c
/
I
o
All PN Offsets
0
0
32K
512
Chips
PN
0
-20
Neighbor Set
The call is already in progress.
PN 168 is the only active signal,
and also is our timing reference.
Continue checking the neighbors.
If we ever notice a neighbor with Ec/Io above T_ADD,
ask to use it! Send a Pilot Strength Measurement Message!
T_ADD
Rake Fingers O
O
O
Reference PN
Active Pilot
10752
168
32002
500
14080
220
!
!
Mobile Rake RX
Srch PN??? W0
F1 PN168 W61
F2 PN168 W61
F3 PN168 W61
September, 2002 RF200 - 68 RF200 v3.73 (c) 2002 Scott Baxter
Forward
Traffic
Channel
Reverse
Traffic
Channel
The Handoff Process
BTS
Handoff Completion Message
Extended Handoff Direction Message
Mobile Station Acknowledgment Order
Base Station Acknowledgment Order
The new Handoff condition is now officially Established!
The handset pilot searcher notices energy from
another sector or BTS, meeting any of these criteria:
Neighbor or Remaining Pilot Ec/Io stronger than T_Add
Candidate Pilot just got T_Comp better than an ac tive
An Active Pilot stayed below T_DROP for T_TDROP time
Pilot Strength Measurement Message
Base Station Acknowledgment Order
Selector arranges channel elements/Walsh codes in requested
sectors and begins using them, too.
Handset verifies which assigned PNs it can now hear.
Neighbor List Update Message
Mobile Station Acknowledgment Order
September, 2002 RF200 - 69 RF200 v3.73 (c) 2002 Scott Baxter
Mobile Requests the Handoff!
98/05/24 23:14:02.205 [RTC]
Pilot Strength Measurement Message
MSG_LENGTH = 128 bits
MSG_TYPE = Pilot Strength Measurement Message
ACK_SEQ = 5 MSG_SEQ = 0 ACK_REQ = 1
ENCRYPTION = Encryption Mode Disabled
REF_PN = 168 Offset Index (the Reference PN)
PILOT_STRENGTH = -6.0 dB
KEEP = 1
PILOT_PN_PHASE = 14080 chips (PN220+0chips)
PILOT_STRENGTH = -12.5 dB
KEEP = 1
PILOT_PN_PHASE = 32002 chips (PN500 + 2 chips)
PILOT_STRENGTH = -11.0 dB
KEEP = 1
RESERVED = 0
PILOT STRENGTH MEASUREMENT MESSAGE
98/05/24 23:14:02.386 [FTC] Order Message
MSG_LENGTH = 64 bits
MSG_TYPE = Order Message
ACK_SEQ = 0 MSG_SEQ = 0 ACK_REQ = 0
ENCRYPTION = Encryption Mode Disabled
USE_TIME = 0 ACTION_TIME = 0
ORDER = Base Station Acknowledgment Order
ADD_RECORD_LEN = 0 bits
Order-Specific Fields = Field Omitted
RESERVED = 0
BASE STATION ACKNOWLEDGMENT
Just prior to this message, this particular
mobile already was in handoff with PN 168
and 220.
This pilot strength measurement message
reports PN 500 has increased above
T_Add, and the mobile wants to use it too.
The base station acknowledges receiving
the Pilot Strength Measurement Message.
September, 2002 RF200 - 70 RF200 v3.73 (c) 2002 Scott Baxter
System Authorizes the Handoff!
98/05/24 23:14:02.926 [FTC] Extended Handoff Direction Message
MSG_LENGTH = 136 bits
MSG_TYPE = Extended Handoff Direction Message
ACK_SEQ = 0 MSG_SEQ = 6 ACK_REQ = 1
ENCRYPTION = Encryption Mode Disabled
USE_TIME = 0 ACTION_TIME = 0 HDM_SEQ = 0
SEARCH_INCLUDED = 1
SRCH_WIN_A = 40 PN chips
T_ADD = -13.0 dB T_DROP = -15.0 dB T_COMP = 2.5 dB
T_TDROP = 4 sec
HARD_INCLUDED = 0 FRAME_OFFSET = Field Omitted
PRIVATE_LCM = Field Omitted RESET_L2 = Field Omitted
RESET_FPC = Field Omitted RESERVED = Field Omitted
ENCRYPT_MODE = Field Omitted RESERVED = Field Omitted
NOM_PWR = Field Omitted NUM_PREAMBLE = Field Omitted
BAND_CLASS = Field Omitted CDMA_FREQ = Field Omitted
ADD_LENGTH = 0
PILOT_PN = 168 PWR_COMB_IND = 0 CODE_CHAN = 61
PILOT_PN = 220 PWR_COMB_IND = 1 CODE_CHAN = 20
PILOT_PN = 500 PWR_COMB_IND = 0 CODE_CHAN = 50
RESERVED = 0
HANDOFF DIRECTION MESSAGE
The base station sends a Handof
Direction Message authorizing the
mobile to begin soft handoff with all
three requested PNs. The pre-existing
link on PN 168 will continue to use
Walsh code 61, the new link on PN220
will use Walsh Code 20, and the new
link on PN500 will use Walsh code 50.
The mobile acknowledges it has received
the Handoff Direction Message.
98/05/24 23:14:02.945 [RTC] Order Message
MSG_LENGTH = 56 bits MSG_TYPE = Order Message
ACK_SEQ = 6 MSG_SEQ = 6 ACK_REQ = 0
ENCRYPTION = Encryption Mode Disabled
ORDER = Mobile Station Acknowledgment Order
ADD_RECORD_LEN = 0 bits
Order-Specific Fields = Field Omitted RESERVED = 0
MOBILE STATION ACKNOWLEDGMENT
September, 2002 RF200 - 71 RF200 v3.73 (c) 2002 Scott Baxter
Mobile Implements the Handoff!
The mobile searcher quickly re-checks
all three PNs. It still hears their pilots!
The mobile sends a Handoff Completion
Message, confirming it still wants to go
ahead with the handoff.
BASE STATION ACKNOWLEDGMENT
98/05/24 23:14:02.985 [RTC] Handoff Completion Message
MSG_LENGTH = 72 bits
MSG_TYPE = Handoff Completion Message
ACK_SEQ = 6 MSG_SEQ = 1 ACK_REQ = 1
ENCRYPTION = Encryption Mode Disabled
LAST_HDM_SEQ = 0
PILOT_PN = 168 Offset Index
PILOT_PN = 220 Offset Index
PILOT_PN = 500 Offset Index
RESERVED = 0
HANDOFF COMPLETION MESSAGE
The base station confirms it has
received the mobiles Handoff
Completion message, and will
continue with all of the links
active.
98/05/24 23:14:03.085 [FTC] Forward Traffic Channel: Order
ACK_SEQ: 1 MSG_SEQ: 1 ACK_REQ: 0 ENCRYPTION: 0
USE_TIME: 0 ACTION_TIME: 0
Base Station Acknowledgement Order
September, 2002 RF200 - 72 RF200 v3.73 (c) 2002 Scott Baxter
Neighbor List Updated, Handoff is Complete!
98/05/24 23:14:03.245 [RTC] Order Message
MSG_LENGTH = 56 bits MSG_TYPE = Order Message
ACK_SEQ = 7 MSG_SEQ = 7 ACK_REQ = 0
ENCRYPTION = Encryption Mode Disabled
ORDER = Mobile Station Acknowledgement Order
ADD_RECORD_LEN = 0 bits
Order-Specific Fields = Field Omitted
RESERVED = 0
MOBILE STATION ACKNOWLEDGMENT
98/05/24 23:14:03.166 [FTC] Neighbor List Update Message
MSG_LENGTH = 192 bits
MSG_TYPE = Neighbor List Update Message
ACK_SEQ = 1 MSG_SEQ = 7 ACK_REQ = 1
ENCRYPTION = Encryption Mode Disabled
PILOT_INC = 4 Offset Index
NGHBR_PN = 164 Offset Index
NGHBR_PN = 68 Offset Index
NGHBR_PN = 52 Offset Index
NGHBR_PN = 176 Offset Index
NGHBR_PN = 304 Offset Index
NGHBR_PN = 136 Offset Index
NGHBR_PN = 112 Offset Index
NGHBR_PN = 372 Offset Index
NGHBR_PN = 36 Offset Index
NGHBR_PN = 8 Offset Index
NGHBR_PN = 384 Offset Index
NGHBR_PN = 216 Offset Index
NGHBR_PN = 328 Offset Index
NGHBR_PN = 332 Offset Index
NGHBR_PN = 400 Offset Index
NGHBR_PN = 96 Offset Index
RESERVED = 0
NEIGHBOR LIST UPDATE MESSAGE
In response to the mobiles Handoff
Completion Message, the base station
assembles a new composite neighbor
list including all the neighbors of each of
the three active pilots.
This is necessary since the mobile
could be traveling toward any one of
these pilots and may need to request
soft handoff with any of them soon.
The mobile confirms receiving the
Neighbor List Update Message. It is
already checking the neighbor list and
will do so continuously from now on.
The handoff is fully established.
September, 2002 RF200 - 73 RF200 v3.73 (c) 2002 Scott Baxter
Handoff Now In Effect, but still check Pilots!
E
c
/
I
o
All PN Offsets
0
0
32K
512
Chips
PN
0
-20
Neighbor Set
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!
T_ADD
Rake Fingers O
Reference PN
Active Set
10752
168
32002
500
14080
220
O O
T_DROP
Mobile Rake RX
Srch PN??? W0
F1 PN168 W61
F2 PN500 W50
F3 PN220 W20
September, 2002 RF200 - 74 RF200 v3.73 (c) 2002 Scott Baxter
The Complete Picture of Handoff & Pilot Sets
T_ADD
E
c
/
I
o
All PN Offsets
0
0
32K
512
Chips
PN
0
-20
Neighbor Set
SRCH_WIN_N
Active Set
Candidate Set
T_DROP
SRCH_WIN_A
Remaining Set
T_ADD
SRCH_WIN_R
SRCH_WIN_A
O O
T_DROP
Rake Fingers O
Reference PN
Pilots of sectors
now used for
communication
Pilots requested
by mobile but not
set up by system
Pilots suggested
by system for
more checking
All other pilots divisible by PILOT_INC but not
presently in Active, Candidate, or Neighbor sets
Mobile Rake RX
Srch PN??? W0
F1 PN168 W61
F2 PN500 W50
F3 PN220 W20
September, 2002 RF200 - 75 RF200 v3.73 (c) 2002 Scott Baxter
Deeper Handoff Details:
Search Windows & Timing
Deeper Handoff Details:
Search Windows & Timing
Section G
September, 2002 RF200 - 76 RF200 v3.73 (c) 2002 Scott Baxter
The Pilot Searchers Measurement Process
The searcher checks pilots in nested
loops, much like meshed gears.
Actives and candidates
occupy the fastest-
spinning wheel.
Neighbors are
next, advancing
one pilot for each
Act+Cand. revolution.
Remaining is slowest,
advancing one pilot each
time the Neighbors revolve.
CURRENT PILOT SET CONTENTS
A A A
C
N N N N N N N N N N N N
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
3
1
12
112
PILOT SEARCHER VIEWED IN SEQUENCE: Typical Elapsed Time = 4 seconds
A A A C N
R
A A A C A A A C A A A C A A A C A A A C A A A C N N N N N N
A A A C N A A A C A A A C A A A C A A A C A A A C A A A C N N N N N
A A A C N A A A C A A A C A A A C A A A C A A A C A A A C N N N N N N
N A A A C A A A C A A A C N N N R A A A C N A A A C A A A C A A A N N
C A A A C A A A C N N N
R
A A A C N A A A C A A A C A A A N N C A A A N
C A A A C N N
Only 3 of 112 remaining set pilots have been checked thus far!
A
N
R
R
R
R
R
R
R
N
N
N
N
N
N
N
N
A
A
September, 2002 RF200 - 77 RF200 v3.73 (c) 2002 Scott Baxter
A Quick Primer on Pilot Search Windows
The phone chooses one strong sector and
locks to it, assumes the PN offset is what its
messages announce. All other offsets are
defined by comparison to this received signal.
In messages, system gives to handset a
neighbor list of nearby sectors true 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 (called a search
window), centered on the expected offset
Search window values can be set up
individually for each Pilot set:
There are pitfalls if the window sizes are
improperly set
too large: phone searches slower
too small: overlook pilots from far away
too large: phone might mis-recognize
identity of a distant BTS signal
One chip is 801 feet or 244.14 m
1 mile=6.6 chips; 1 km.= 4.1 chips
PROPAGATION DELAY
SKEWS APPARENT PN OFFSETS
BTS
BTS
A
B
33
Chips
4
Chips
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.
September, 2002 RF200 - 78 RF200 v3.73 (c) 2002 Scott Baxter
Setting Pilot Search Window Sizes
When the handset first powers up, it does an
exhaustive search for the best pilot. No windows
are used in this process.
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.
When a strong neighbor is requested in a PSMM,
the former neighbor pilot is now a candidate. Its
offset is precisely remembered and frequently
rechecked and tracked by the phone.
Window size for actives and candidates can be
small, since the windows float, drifting with the
observed pilot energy of the signal. Only search
wide enough to include multipath energy!
This greatly speeds up overall searching!
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 to accommodate the maximum intercell
distances which a mobile might experience
SEARCH WINDOW SETTINGS
AND PROPAGATION DISTANCES
Window
Size (Chips)
14 (7)
Datafill
Value
N,R Delta Distance
4 1.06
20 (10)
40 (20)
28 (14)
Miles KM.
5
6
7
8
9
10
11
12
13
14
15
60 (30)
80 (40)
100 (50)
130 (65)
160 (80)
226 (113)
320 (160)
452 (226)
1.71
1.52 2.44
2.12 3.42
3.03 4.88
4.55 7.32
6.07 9.77
7.59 12.2
9.86 15.9
12.1 19.5
17.1 27.6
24.3 39.1
34.3 55.2
September, 2002 RF200 - 79 RF200 v3.73 (c) 2002 Scott Baxter
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
A
B
1 mi.
7 Chips
BTS
BTS
SITUATION 1
Locked to distant
site, cant see
one nearby
1
2

m
i
l
e
s
8
0

C
h
i
p
s
SRCH_WIN_N = 130
BTS A is reference.
BTS B appears (7-80) chips
early due to its closer distance.
This is outside the 65-chip window.
Mobile cant see BTS Bs pilot, but its
strong signal blinds us and the call drops.
T
ra
v
e
l
m
o
u
n
t
a
i
n
s
A
B
1 mi.
7 Chips
BTS
BTS
SITUATION 2
Locked to nearby
site, cant see
distant one
1
2

m
i
l
e
s
8
0

C
h
i
p
s
T
r
a
v
e
l
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 cant see BTS As pilot.
m
o
u
n
t
a
i
n
s
September, 2002 RF200 - 80 RF200 v3.73 (c) 2002 Scott Baxter
Overall Handoff Perspective
Soft & Softer Handoffs are preferred, but not always possible
a handset can receive BTS/sectors simultaneously only on one
frequency
all involved BTS/sectors must connect to a networked BSCs.
Some manufacturers do not presently support this, and so are
unable to do soft-handoff at boundaries between BSCs.
frame timing must be same on all BTS/sectors
If any of the above are not possible, handoff still can occur but can
only be hard break-make protocol like AMPS/TDMA/GSM
intersystem handoff: hard
change-of-frequency handoff: hard
CDMA-to-AMPS handoff: hard, no handback
auxiliary trigger mechanisms available (RTD)
September, 2002 RF200 - 81 RF200 v3.73 (c) 2002 Scott Baxter
Meet the CDMA
Performance Indicators
Meet the CDMA
Performance Indicators
September, 2002 RF200 - 82 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 83 RF200 v3.73 (c) 2002 Scott Baxter
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
FER
%
0 2 5 100
F
o
r
w
a
r
d
R
e
v
e
r
s
e
FER is the end-result of the whole transmission link
if FER is good, then any other problems arent having much
effect
if FER is bad, thats 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
September, 2002 RF200 - 84 RF200 v3.73 (c) 2002 Scott Baxter
Indicator #2: Received Power at the Handset
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
-40
-90
-105
<
<
t
o
o

w
e
a
k









o
v
e
r
l
o
a
d
>
>
RX Level

x
LO

RX Level
(from AGC)
IF LNA
BW
~30
MHz.
BW
1.25
MHz.
Handset Receiver
R
R
R
S
Rake
Receive power is important, but its exact value isnt critical
too much received signal (-35 dbm or higher) could drive the
phones 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
September, 2002 RF200 - 85 RF200 v3.73 (c) 2002 Scott Baxter
Indicator #3, Ec/Io - What does it mean?
Why cant we just use the handsets
received power level to guide
handoffs?
Because it is a simple total RF
power measurement, the total of
all sectors reaching the mobile

x
LO

RX Level
(from AGC)
IF LNA
BW
~30
MHz.
BW
1.25
MHz.
Handset Receiver
R
R
R
S
Rake
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 sectors 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 wont
be able to get much benefit from using a traffic channel on that
sector
September, 2002 RF200 - 86 RF200 v3.73 (c) 2002 Scott Baxter
Indicator #3 Ec/Io Summary
E
c
/I
o
cleanness of the pilot
foretells the readability of
the associated traffic
channels
guides soft handoff decisions
digitally derived: ratio of good
to bad energy seen by the
search correlator at the
desired PN offset
Never appears higher than
Pilots percentage of serving
cells transmitted energy
Can be degraded by strong
RF from other cells, sectors
Imperfect orthogonality,
other PNs are ~-20 dB.
Can be degraded by noise
E
c
/I
o
dB
-25 -16 -10 0
E
c
I
o
Energy of
desired pilot alone
Total energy received
Above -10:
Good signal
-10 to -16
OK, but pain
Below -16:
Big trouble!
September, 2002 RF200 - 87 RF200 v3.73 (c) 2002 Scott Baxter
Light Traffic Loading
Heavily Loaded
How Ec/Io Varies with Traffic Loading
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.
Ec/Io = (2/4)
= 50%
= -3 db.
Ec/Io = (2/10)
= 20%
= -7 db.
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
T
r
a
f
f
i
c

C
h
a
n
n
e
l
s
6w
0.5w
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
0.5w
September, 2002 RF200 - 88 RF200 v3.73 (c) 2002 Scott Baxter
Many Sectors, Nobody Dominant
One Sector Dominant
How Ec/Io varies with RF Environment
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 sectors pilot
The large Io overrides the
weak Ec; Ec/Io is low!
Io = -90 dbm
Ec = -96 dbm
Ec/Io = -6 db
Io = 10 signals
each -90 dbm
= -80 dbm
Ec of any one
sector = -96
Ec/Io = -16 db
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
T
r
a
f
f
i
c
C
h
a
n
n
e
l
s
4w
0.5w
BTS1
I
0
E
C
BTS2
BTS3
BTS4
BTS5
BTS6
BTS7
BTS8
BTS9
BTS10
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
September, 2002 RF200 - 89 RF200 v3.73 (c) 2002 Scott Baxter
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
cant exceed handsets
maximum (typ. +23 dBm)
TXPO
DUP x

IF
LNA
Subscriber Handset
R
R
R
S
Rake

Viterbi
Decoder
Vocoder

FEC
Orth
Mod
Long PN
x
x
x
IF Mod
I
Q
x ~
LO
Open Loop
LO
Closed Loop Pwr Ctrl
IF
Receiver>>
<<Transmitter
PA
BTS
Typical TXPO:
+23 dBm in a coverage hole
0 dBm near middle of cell
-50 dBm up close to BTS
TXPO = -(RX
dbm
) -C + TXGA
C = +73 for 800 MHz. systems
= +76 for 1900 MHz. systems
What is the right power TX level? Whatever the BTS asks for!
As long as closed loop control is working, the phones opinion
isnt 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)
September, 2002 RF200 - 90 RF200 v3.73 (c) 2002 Scott Baxter
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 stations latest new
decision: mobile is too strong, or mobile is too weak -- there is
no cumulative error, since each decision is fresh
0 dB
-10 dB
-20 dB
Typical Transmit Gain Adjust
Time, Seconds
TXPO = -(RX
dbm
) -C + TXGA
C = +73 for 800 MHz. systems
= +76 for 1900 MHz. systems
September, 2002 RF200 - 91 RF200 v3.73 (c) 2002 Scott Baxter
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.
September, 2002 RF200 - 92 RF200 v3.73 (c) 2002 Scott Baxter
Problem Signatures
Problem Signatures
Section Identification
September, 2002 RF200 - 93 RF200 v3.73 (c) 2002 Scott Baxter
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.
SIGNATURE:
GOOD CALL
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 94 RF200 v3.73 (c) 2002 Scott Baxter
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.
SIGNATURE:
GOOD CALL
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 95 RF200 v3.73 (c) 2002 Scott Baxter
Signature of a Dropped Call in Poor Coverage
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
SIGNATURE:
DROPPED CALL, BAD COVERAGE
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 96 RF200 v3.73 (c) 2002 Scott Baxter
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 RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 97 RF200 v3.73 (c) 2002 Scott Baxter
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 Bs signal will override
site As signal, making it
unreadable
as soon as the FER goes
too high, a fade timer will
start the the mobile will
eventually die
A
B
BTS
BTS
FORWARD LINK DIES
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
B grows stronger and stronger.
Mobiles 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 cant hear power control
bits, and a fade timer or message timer
kills the call in a few seconds.
September, 2002 RF200 - 98 RF200 v3.73 (c) 2002 Scott Baxter
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, youll
see repeats of messages on
the forward link and reverse
link
SIGNATURE:
REVERSE LINK INTERFERENCE
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 99 RF200 v3.73 (c) 2002 Scott Baxter
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
B
BTS
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
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 couldnt 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.
REVERSE LINK DIES
September, 2002 RF200 - 100 RF200 v3.73 (c) 2002 Scott Baxter
Solving the #1 Death Scenario: Failed Handoff
Why didnt the mobile ask for handoff?
New sector not on neighbor list
Neighbor Search Window too Small?
BTS in island mode, wrong PN?
Why didnt the BTS set up the handoff?
Didnt hear mobile rev link interf?
No resources available?
T-1 unstable, messages lost
Why didnt the mobile do the handoff?
Couldnt hear BTS, Fwd link interf?
B
BTS
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
REVERSE LINK DIES
A
B
BTS
BTS
FORWARD LINK DIES
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
Steps in the Handoff Process
Mobiles searcher notices
the needed new pilot
Mobile sends PSMM
requesting handoff
System sets up the handoff:
channel elements
forward power
space in packet pipes
Simulcasting begins!
System tells mobile how to
hear the new sectors:
Handoff Direction Message
Mobile confirms completion:
Handoff Completion Message
System makes new neighbor list,
sends to mobile: Neighbor List
Update Message
Now the mobile can hear
the system better, too!
Now the system can hear
the mobile better!
see
ask
tell
do
ok!
tell
BTS
BTS
BTS
What Went Wrong??!
September, 2002 RF200 - 101 RF200 v3.73 (c) 2002 Scott Baxter
Basic PN Planning and
Search Window Considerations
Basic PN Planning and
Search Window Considerations
System Performance Optimization
September, 2002 RF200 - 102 RF200 v3.73 (c) 2002 Scott Baxter
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.
September, 2002 RF200 - 103 RF200 v3.73 (c) 2002 Scott Baxter
Short PN Basics:
PN Offsets Distinguish Sectors
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
A
B
C
D

x
LO
IF LNA
BPF
Phone
Rake Receiver

BPF
PN A Walsh X
PN B Walsh Y
PN C Walsh Z
Pilot Searcher
Decoding Vocoder
x
September, 2002 RF200 - 104 RF200 v3.73 (c) 2002 Scott Baxter
A Practical "Rule of Thumb" to Remember
The signal of a base station roughly 10 miles distant will SEEM to
be one PN higher than it was transmitted
Transmitted:
PN 99
6,336 chips offset
BTS
ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcdefghijkmnopqrstuvwxyz!@#$%^&*()_+
9.70 miles = 64 chips = 1 PN
Mobile
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 earlier than what the mobile
sees. So the base station's signal at the mobile seems to be one
PN higher than it was actually transmitted.
Received:
PN 100
6,400 chips delay
September, 2002 RF200 - 105 RF200 v3.73 (c) 2002 Scott Baxter
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
10 KM
41 chips
2 KM
8 chips
PN200
PN360
September, 2002 RF200 - 106 RF200 v3.73 (c) 2002 Scott Baxter
Mobile Timing: the Reference PN
Mobile System Acquisition Process
Scan entire range of PNs
Lock to strongest Pilot found
Put rake fingers on multipaths
Earliest arriving multipath is "reference PN"
Read sync channel message
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!
Rake Fingers O
O
O
Reference PN
Active Pilot
E
c
/
I
o
0
0
32K
512
Chips
PN
Pilot Searcher Scans All PNs
All PN Offsets
0
-20
98/05/24 23:14:09.817 [SCH]
MSG_LENGTH = 208 bits
MSG_TYPE = Sync Channel Msg
P_REV = 3, MIN_P_REV = 2
SID = 179 NID = 0
PILOT_PN = 168 Offset Index
LC_STATE = 0x0348D60E013
SYS_TIME = 98/05/24 3:14:10.160
LP_SEC = 12
LTM_OFF = -300 minutes
DAYLT = 0, PRAT = 9600 bps
SYNC CHANNEL MESSAGE
UNKNOWN EXTRA
PROPAGATION DELAY
How many chips????
September, 2002 RF200 - 107 RF200 v3.73 (c) 2002 Scott Baxter
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
10 KM
41 chips
2 KM
8 chips
PN200
PN360
360
+41
+8
360+33c
SRCH_WIN_N
September, 2002 RF200 - 108 RF200 v3.73 (c) 2002 Scott Baxter
What Search Window Values Can Be Set?
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
SRCH_WIN_val
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Width, Chips
4 (2)
6 (3)
8 (4)
10 (5)
14 (7)
20 (10)
28 (14)
40 (20)
60 (30)
80 (40)
100 (50)
130 (65)
160 (80)
226 (113)
330 (165)
452 (226)
September, 2002 RF200 - 109 RF200 v3.73 (c) 2002 Scott Baxter
Search Window Settings: Neighbor Set
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
10 KM
41 chips
2 KM
8 chips
PN200
PN360
360
+41
+8
360+33c
SRCH_WIN_N
Neighbor Search Window
Example
Active
Sector
Neighbor
Sector
September, 2002 RF200 - 110 RF200 v3.73 (c) 2002 Scott Baxter
Worst-Case Wide Neighbor Window Situation
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
BTS A
BTS B
12 miles
1/2
mile
September, 2002 RF200 - 111 RF200 v3.73 (c) 2002 Scott Baxter
Safe Initial Neighbor Search Window Value
Examine a cell map for an area of your system
Identify the farthest-apart pair of cells likely to
be used in soft handoff
Their distance separation determines
maximum timing skew a mobile could ever
possibly encounter in this part of the
system
Calculate the timing skew in chips
6.7 chips times miles or 4.1 chips times
kilometers
Safe required window size = two times the
skew
Refer to table to convert required window size
in chips to required value of SRCH_WIN_N
After thorough drive-test data is available, it
may be possible to reduce SRCH_WIN_N if
observed delay spread is significantly
narrower than the window
Determining Safe
Initial SRCH_WIN_N
Required Window
= 4.1 x 11.5 x 2 = 94.3 chips
SRCH_WIN_N = 10
If locations exist near site A
where mobiles are in handoff with
site F, mobiles could encounter
neighbor pilot timing skews as
large as the A-F distance. If
locked to A, F looks late by this
amount. If locked to F, A looks
early by this amount. Window
must be twice the skew value.
11.5 KM
A
B
C
E
F
D
September, 2002 RF200 - 112 RF200 v3.73 (c) 2002 Scott Baxter
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 cross-
reference 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
11.5 KM
A
B
C
E
F
D
September, 2002 RF200 - 113 RF200 v3.73 (c) 2002 Scott Baxter
Search Window Initial Settings: Active Set
Neighbor and Remaining search window
centers are indexed against the mobiles
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
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.
Earliest Detected
Multipath
Active Search Window
40 chips wide (typical)
0 +20 -20
E
c
/
I
o
September, 2002 RF200 - 114 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 115 RF200 v3.73 (c) 2002 Scott Baxter
SRCH_WIN_A Special Consideration
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 mobiles
SRCH_WIN_A, Chips
20
10
No
14
No
20
No
28
No
40
No
60
No
28 No No No No No No
40 No No No No Yes No
60 No No No Yes Yes Yes
80 No No No Yes Yes Yes
100 No Yes Yes Yes Yes Yes
130 Yes Yes Yes Yes Yes Yes
160 Yes Yes Yes Yes Yes Yes
226 Yes Yes Yes Yes Yes Yes
S
R
C
H
_
W
I
N
_
N
,

C
h
i
p
s
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
September, 2002 RF200 - 116 RF200 v3.73 (c) 2002 Scott Baxter
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!
September, 2002 RF200 - 117 RF200 v3.73 (c) 2002 Scott Baxter
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 15
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
D
September, 2002 RF200 - 118 RF200 v3.73 (c) 2002 Scott Baxter
Co-Active PN Demodulation Errors
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 to PN offset for one of the sectors involved.
BTS B
PN 142
BTS A
PN 142
x miles x miles
ACTIVE SEARCH WINDOW
September, 2002 RF200 - 119 RF200 v3.73 (c) 2002 Scott Baxter
Adjacent-Active-PN Demodulation Errors
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.
BTS B
PN 99
BTS A
PN 100
1 mile 11 miles
ACTIVE SEARCH WINDOW
September, 2002 RF200 - 120 RF200 v3.73 (c) 2002 Scott Baxter
Adjacent-Neighbor PN Recognition Errors
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
BTS A
PN 100
BTS
BTS
m
o
u
n
t
a
i
n
s
BTS
BTS F
PN 200
BTS G
PN 198
X
20 miles
NEIGHBOR SEARCH WINDOW
September, 2002 RF200 - 121 RF200 v3.73 (c) 2002 Scott Baxter
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
4
8
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
84
88
92
96
100
104
108
112
116
120
September, 2002 RF200 - 122 RF200 v3.73 (c) 2002 Scott Baxter
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!
4
172
340
8
176
344
12
180
348
16
184
352
20
188
356
24
192
360
28
196
364
32
200
368
36
204
372
40
208
376
September, 2002 RF200 - 123 RF200 v3.73 (c) 2002 Scott Baxter
Introduction to CDMA
Performance Data
Introduction to CDMA
Performance Data
Course RF200 Section II.
September, 2002 RF200 - 124 RF200 v3.73 (c) 2002 Scott Baxter
What Data is Available for Performance Study?
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
Access Mgr./BSC-BSM Switch BTS
CDSU DISCO
Ch. Card ACC






TFU1
GPSR
CDSU
CDSU
DISCO 1
DISCO 2
SBS
Vocoders
Selectors
CDSU
CDSU
CDSU
CDSU
CDSU
CDSU
CM SLM
LPP LPP ENET
DTCs
DMS-BUS
Txcvr A
Txcvr B
Txcvr C
RFFE A
RFFE B
RFFE C
TFU1
GPSR
IOC
BSM
Data Analysis
Post-Processing
Tools
IS-95/J Std 8 Messages
IS-95/J Std 8
Messages
NOIS Messages
QC-Specific Messages
Switch OMs,
pegs, logs
Mobile Data
Post-Processing
Tools
Mobile Data
Capture Tools Selector
Logs
NMIS Messages
Handset
Messages
External
Analysis
Tools
PC-based
PC-based
Unix-based,
PC-based
Various
CDMA NETWORK EQUIPMENT
HANDSET
September, 2002 RF200 - 125 RF200 v3.73 (c) 2002 Scott Baxter
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 cutting-
edge 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
September, 2002 RF200 - 126 RF200 v3.73 (c) 2002 Scott Baxter
System Data and
Statistical Analysis
System Data and
Statistical Analysis
September, 2002 RF200 - 127 RF200 v3.73 (c) 2002 Scott Baxter
Statistical CDMA Performance Indicators
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
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.
September, 2002 RF200 - 128 RF200 v3.73 (c) 2002 Scott Baxter
Network Data Examples
The following slides are typical samples from networks of various
manufacturers
In class, we'll survey statistics from your own network, if available,
and/or look at other specific example files from actual networks
September, 2002 RF200 - 129 RF200 v3.73 (c) 2002 Scott Baxter
Lucent System Data
Examples
Lucent System Data
Examples
September, 2002 RF200 - 130 RF200 v3.73 (c) 2002 Scott Baxter
Lucent System Data Examples
S ys / ECP/ Ce ll/ Na m
e / La be l
TOTALS
179 2 67
S MITHS PRING
S
179 2 10
BOBCAT
179 2 28
INGLEWOO
D
179 2 30
NOLENS VIL
LE
179 2 121
CLARKS VIL
LE/ BRILEY
179 2 1
TEXTRON
179 2 45
FARMERS
%CDMA Es t Ca lls 96.83 93.55 93.58 94.18 94.36 94.44 94.67 94.73
Re Ac quir e d_Ca lls 2.84 3.22 2.61 3.89 2.38 5.26 2.65 2.06
CCE e rla ng s 6,580.44 62.60 128.68 71.45 63.54 36.16 76.37 115.21
CDMA_CE Us a g e 2,368,959 22,535 46,323 25,722 22,873 13,016 27,494 41,476
Prim_CS CE_Us e 1,451,816 9,300 19,788 13,689 11,113 8,448 15,965 23,219
%Prim_CS CE_Us e 61.28 41.27 42.72 53.22 48.59 64.90 58.07 55.98
S e c _CS CE_Us e 917,143 13,235 26,535 12,033 11,760 4,568 11,529 18,257
%CDMA S o ftHO Us e 38.72 58.73 57.28 46.78 51.41 35.10 41.93 44.02
%CDMA S UFa il 2.79 6.14 5.68 5.44 3.62 3.68 4.64 5.04
CDMA Lo s t_Ca ll 1,722 15 42 20 10 64 15 35
%CDMA Lo s t Ca lls 1.17 1.67 2.18 1.18 0.89 5.98 0.98 1.44
To tCDMA Fa ilure s 7,856 95 208 143 77 108 102 206
CDMATo tl Orig ins 5,069 65 143 89 47 73 67 141
CDMATo tl Te rmins 2,787 30 65 54 30 35 35 65
CDMA Ma int Bus y 0 0 0 0 0 0 0 0
CDMAOnly PrfS z 80 0 0 0 1 0 0 0
CDMA_Org Trm_Ovf 713 0 0 0 0 0 0 0
CDMA Org _S z 109,076 680 1,500 1,236 771 828 1,229 1,862
CDMA Org _As n 105,970 659 1,454 1,197 752 786 1,192 1,824
CDMA Pg _Rs p_S z 46,720 313 611 640 445 369 430 755
CDMA Trm_As n 44,951 301 590 603 412 329 414 736
CDMA Re q_Alg 4,426 32 55 73 29 63 44 54
September, 2002 RF200 - 131 RF200 v3.73 (c) 2002 Scott Baxter
Lucent Overload Data Examples from
Autopace
S ys / ECP/ Ce ll/ N
a me / Ante nna
ID/ Ant_Na me
TOTALS
179 2 1
TEXTRON 1
Ante nna :1
179 2 1
TEXTRON
2 Ante nna :2
179 2 1
TEXTRON
3 Ante nna :3
179 2 2
BELMONT
1 Ante nna :1
179 2 2
BELMONT
2 Ante nna :2
179 2 2
BELMONT
3 Ante nna :3
CDMA_Ac s Chn_Oc 5,921 30 28 10 27 13.00 13.00
CDMA_Avg S q_DG 1,123,466 6,187 6,157 6,088 6,168 5,016.00 4,818.00
CDMA_Fwd PCOLdur 581 12 4 2 0 0.00 0.00
CDMA_Fwd PCOLc nt 339 4 4 1 0 0.00 0.00
CDMA Intc pt_Ms g 0 0 0 0 0 0.00 0.00
CDMA_Pg Ch_Oc pn 489,506 2,771 2,763 2,754 2,795 2,756.00 2,766.00
CDMA_Pk Ac s _ChOc 91,989 985 563 281 563 422.00 281.00
CDMA_Pk Pg _ChOc 555,984 3,264 3,140 3,197 3,125 3,120.00 3,155.00
CDMA_Re v PCOLdur 305 0 0 0 0 0.00 0.00
CDMA_Re v PCOLc nt 6 0 0 0 0 0.00 0.00
CDMA Re o rde r_Ms g 2 0 0 0 0 0.00 0.00
CDMA_Tf CdCh_Us g 245,143 1,360 1,188 980 953 821.00 862.00
CDMA_Jmr De t_Dur 0 0 0 0 0 0.00 0.00
September, 2002 RF200 - 132 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Data
Examples
Nortel System Data
Examples
September, 2002 RF200 - 133 RF200 v3.73 (c) 2002 Scott Baxter
Nortel BTSC MO Attributes
Attribute Name
Data
Type
Seq.
Number
Access,
Range
Description
BlockedOriginationsNoTCE word16
0x0002A
42
P
full
Number of originations blocked because
no idle channel elements were available
BlockedOriginationsNoFwdCap
0x0002B
43
Number of originations blocked due to
lack of BTS forward link excess capacity
BlockedOriginationsNoRevCap
0x0002C
44
Number of originations blocked due to
lack of reverse link capacity
BlockedHandoffsNoTCE
0x0002D
45
Number of handoffs blocked because no
idle channel elements were available
BlockedHandoffsNoFwdCap
0x0002E
46
Number of handoffs blocked due to lack
of BTS forward link excess capacity
BlockedHandoffsNoRevCap
0x0002F
47
Number of handoffs blocked due to lack
of reverse link capaicty
SuccessfulOriginations
0x00030
48
Number of successful originations
SuccessfulHandoffs
0x00031
49
Number of successful handoffs
word16
word16
word16
word16
word16
word16
word16
P
full
P
full
P
full
P
full
P
full
P
full
P
full
Each attribute is a periodic counter maintained during the 15-minute automatic logging period.
September, 2002 RF200 - 134 RF200 v3.73 (c) 2002 Scott Baxter
Nortel FA MO Attributes
Each attribute is a periodic counter maintained during the 15-minute automatic logging period.
FA MO
Sequence
Number OM name
FA MO
Sequence
Number OM name
16 TCEUtilMaximum 2D s oft4s ofter1Alpha
17 NumOfTCs Configured 2E s oft4s ofter1Beta
18 s oft1softer1Alpha 2F s oft4s ofter1Gamma
19 s oft1softer1Beta 30 s oft4s ofter2AlphaBeta
1A s oft1softer1Gamma 31 s oft4s ofter2BetaGamma
1B s oft1softer2AlphaBeta 32 s oft4s ofter2GammaAlpha
1C s oft1softer2BetaGamma 33 s oft4s ofter3
1D s oft1softer2GammaAlpha 34 s oft5s ofter1Alpha
1E s oft1softer3 35 s oft5s ofter1Beta
1F s oft2softer1Alpha 36 s oft5s ofter1Gamma
20 s oft2softer1Beta 37 s oft5s ofter2AlphaBeta
21 s oft2softer1Gamma 38 s oft5s ofter2BetaGamma
22 s oft2softer2AlphaBeta 39 s oft5s ofter2GammaAlpha
23 s oft2softer2BetaGamma 3A s oft6s ofter1Alpha
24 s oft2softer2GammaAlpha 3B s oft6s ofter1Beta
25 s oft2softer3 3C s oft6s ofter1Gamma
26 s oft3softer1Alpha 3D TimeNotInUs e
27 s oft3softer1Beta
28 s oft3softer1Gamma
29 s oft3softer2AlphaBeta
2A s oft3softer2BetaGamma
2B s oft3softer2GammaAlpha
2C s oft3softer3
September, 2002 RF200 - 135 RF200 v3.73 (c) 2002 Scott Baxter
Nortel BTSC MO Events
Event Report Name
Type
Event Report
Seq.
Number
Description
Each event counter is maintained during the 15-minute automatic logging period.
BTSCPerformanceData PerformanceData
0x000?
0?
Includes as parameters all attributes with P
access documented in the attribute table for
this MO.
FA MO Events
Event Report Name
Type
Event Report
Seq.
Number
Description
Each event counter is maintained during the 15-minute automatic logging period.
FAPerformanceData PerformanceData
0x000?
0?
Includes as parameters all attributes with P
access documented in the attribute table for
this MO.
September, 2002 RF200 - 136 RF200 v3.73 (c) 2002 Scott Baxter
Nortel BTSC MO Report Example
XYZ 19971120 BTSC MO Report
+----+----------------------------+------+------+------+------+------+------+------+------+
|BTS | Start Date/Time - |OBlock|OBlock|OBlock|HBlock|HBlock|HBlock| Succ | Succ |
| | End Date/Time |No TCE|No Fwd|No Rev|No TCE|No Fwd|No Rev| Origs|Handof|
+----+----------------------------+------+------+------+------+------+------+------+------+
| 1|1997/11/20 01:30:00-02:00:00| 0| 0| 0| 0| 0| 0| 3| 5|
| 1|1997/11/20 12:00:00-12:30:00| 0| 0| 0| 0| 0| 0| 46| 314|
| 1|1997/11/20 12:30:00-13:00:00| 0| 0| 0| 0| 0| 0| 76| 470|
| 1|1997/11/20 13:00:00-13:30:00| 0| 0| 0| 0| 0| 0| 45| 414|
| 1|1997/11/20 13:30:00-14:00:00| 0| 0| 0| 0| 0| 0| 55| 375|
| 1|1997/11/20 14:00:00-14:30:00| 0| 0| 0| 0| 0| 0| 50| 525|
| 1|1997/11/20 14:30:00-15:00:00| 0| 0| 0| 0| 0| 0| 72| 433|
| 1|1997/11/20 15:00:00-15:30:00| 0| 0| 0| 0| 0| 0| 66| 412|
| 1|1997/11/20 15:30:00-16:00:00| 0| 0| 0| 0| 0| 0| 53| 323|
| 1|1997/11/20 16:00:00-16:30:00| 0| 0| 0| 0| 0| 0| 63| 342|
| 1|1997/11/20 16:30:00-17:00:00| 0| 0| 0| 0| 0| 0| 51| 331|
| 1|1997/11/20 17:00:00-17:30:00| 0| 0| 0| 0| 0| 0| 39| 323|
| 1|1997/11/20 17:30:00-18:00:00| 0| 0| 0| 0| 0| 0| 51| 310|
| 1|1997/11/20 18:00:00-18:30:00| 0| 0| 0| 0| 0| 0| 45| 237|
| 1|1997/11/20 18:30:00-19:00:00| 0| 0| 0| 0| 0| 0| 31| 299|
| 1|1997/11/20 19:00:00-19:30:00| 0| 0| 0| 0| 0| 0| 37| 282|
| 1|1997/11/20 19:30:00-20:00:00| 0| 0| 0| 0| 0| 0| 19| 143|
| 1|1997/11/20 20:00:00-20:30:00| 0| 0| 0| 0| 0| 0| 18| 96|
| 1|1997/11/20 20:30:00-21:00:00| 0| 0| 0| 0| 0| 0| 33| 192|
| 1|1997/11/20 21:00:00-21:30:00| 0| 0| 0| 0| 0| 0| 25| 226|
| 1|1997/11/20 21:30:00-22:00:00| 0| 0| 0| 0| 0| 0| 15| 235|
| 1|1997/11/20 22:00:00-22:30:00| 0| 0| 0| 0| 0| 0| 15| 216|
| 1|1997/11/20 22:30:00-23:00:00| 0| 0| 0| 0| 0| 0| 9| 162|
| 1|1997/11/20 23:00:00-23:30:00| 0| 0| 0| 0| 0| 0| 3| 40|
| |Totals for BTS 1 | 0| 0| 0| 0| 0| 0| 1235| 8895|
September, 2002 RF200 - 137 RF200 v3.73 (c) 2002 Scott Baxter
Nortel Selector Log File Example
=====================================================
Status : OLFLR_OK
Record Type : NEIGHBOR_LIST_TUNING_DATA_ARRAY
File Offset : 414 (octal)
Time Stamp : 97/10/29-00:29:25.380
Record Length : 72
Header Length : 51
Source Node Id : 297543 (0x00048a47)
OID:AgentId : 297536 (0x00048a40)
OID:MOClass : 81 (0x0051)
OID:MOVersion : 1 (0x0001)
OID:MOInstance : 1 (0x0001)
Call Id : SID 0x4026 EntryPoint 0x134a Count 0x0 Time 0x2cfe821
IMSI : NumDigits 15 Digits 134006043294814 (123-63-251-3692bf)
ESN : 0x9f0d02ac
PFFlags : 0x1f
Secondary Agent Id : 0x8a40
FramingBytes : 0xfaae
Sequence Number : 57
AttributeType : 0x0256
AttributeInstance : 0x0030
Log Attr -> Type : LogSBSNeighborListTuningDataArray Seq Num : 0030
LogData object contents:
Data Type : NEIGHBOR_LIST_TUNING_DATA_ARRAY
Resource Type : OCC_SBS_RESOURCE
TimeStamp : 97/10/29-00:29:25.380
Count : 2
Ext'dBaseId PowerCombineBit PilotStrength PNOffset
+++++=========================++++=========================+++++
0x018002a3 1 8 0x0104
0x018002a1 1 19 0x01a4
=====================================================
September, 2002 RF200 - 138 RF200 v3.73 (c) 2002 Scott Baxter
Nortel FAMO Report Example
XYZ 19971120 FA MO Report
+----+----------------------------+---------+---------+-----+-------+-------+-------+-----+---+
|BTS | Start Date/Time - | MOU | MOU | CE/ | MOU | MOU | MOU |%Soft|Max|
| | End Date/Time | CE | Traffic | User| Alpha | Beta | Gamma | HO |TCE|
+----+----------------------------+---------+---------+-----+-------+-------+-------+-----+---+
| 1|1997/11/20 07:00:00-07:30:00| 41.99| 33.35| 1.26| 11.77| 4.62| 16.96|20.58| 15|
| 1|1997/11/20 07:00:00-07:30:00| 73.06| 46.22| 1.58| 17.72| 14.10| 14.39|36.75| 15|
| 1|1997/11/20 08:00:00-08:30:00| 109.87| 66.05| 1.66| 24.78| 20.21| 21.06|39.88| 15|
| 1|1997/11/20 10:00:00-10:30:00| 153.79| 89.81| 1.71| 41.85| 32.19| 15.77|41.60| 15|
| 1|1997/11/20 10:30:00-11:00:00| 181.09| 102.19| 1.77| 43.60| 28.22| 30.38|43.57| 15|
| 1|1997/11/20 11:00:00-11:30:00| 152.59| 84.73| 1.80| 37.61| 18.51| 28.61|44.47| 15|
| 1|1997/11/20 11:30:00-12:00:00| 143.70| 89.16| 1.61| 39.66| 24.78| 24.72|37.95| 15|
| 1|1997/11/20 12:00:00-12:30:00| 156.58| 89.52| 1.75| 25.51| 21.91| 42.10|42.83| 15|
| 1|1997/11/20 12:30:00-13:00:00| 165.54| 89.97| 1.84| 44.41| 22.89| 22.67|45.65| 15|
| 1|1997/11/20 13:00:00-13:30:00| 170.36| 99.19| 1.72| 52.81| 24.58| 21.79|41.78| 15|
| 1|1997/11/20 13:30:00-14:00:00| 145.34| 93.71| 1.55| 41.88| 24.05| 27.77|35.53| 15|
| 1|1997/11/20 14:00:00-14:30:00| 189.61| 121.49| 1.56| 52.43| 30.99| 38.06|35.93| 15|
| 1|1997/11/20 14:30:00-15:00:00| 153.65| 108.08| 1.42| 47.58| 37.52| 22.99|29.65| 15|
| 1|1997/11/20 15:00:00-15:30:00| 165.08| 106.66| 1.55| 49.00| 29.69| 27.97|35.39| 15|
| 1|1997/11/20 15:30:00-16:00:00| 159.27| 94.72| 1.68| 42.04| 28.43| 24.25|40.53| 15|
| 1|1997/11/20 16:00:00-16:30:00| 172.52| 114.62| 1.51| 56.57| 28.50| 29.55|33.56| 15|
| 1|1997/11/20 16:30:00-17:00:00| 156.83| 105.46| 1.49| 53.29| 30.38| 21.80|32.76| 15|
| 1|1997/11/20 17:00:00-17:30:00| 129.13| 82.52| 1.56| 31.50| 24.28| 26.73|36.10| 15|
| 1|1997/11/20 17:30:00-18:00:00| 134.80| 81.76| 1.65| 35.80| 30.20| 15.77|39.35| 15|
| 1|1997/11/20 18:00:00-18:30:00| 96.91| 60.49| 1.60| 27.80| 15.38| 17.31|37.58| 15|
| 1|1997/11/20 18:30:00-19:00:00| 124.25| 73.62| 1.69| 22.37| 30.93| 20.33|40.75| 15|
| 1|1997/11/20 19:00:00-19:30:00| 75.50| 41.14| 1.83| 18.03| 14.88| 8.24|45.50| 15|
| 1|1997/11/20 19:30:00-20:00:00| 40.58| 23.56| 1.72| 12.50| 5.72| 5.33|41.95| 15|
| 1|1997/11/20 20:00:00-20:30:00| 51.14| 29.81| 1.72| 13.26| 10.37| 6.19|41.71| 15|
| 1|1997/11/20 20:30:00-21:00:00| 102.45| 55.26| 1.85| 16.36| 18.49| 20.41|46.07| 15|
| 1|1997/11/20 21:00:00-21:30:00| 108.48| 74.86| 1.45| 28.32| 17.26| 29.27|30.99| 15|
| 1|1997/11/20 21:30:00-22:00:00| 109.92| 68.50| 1.60| 26.53| 19.22| 22.75|37.68| 15|
| 1|1997/11/20 22:00:00-22:30:00| 86.58| 59.36| 1.46| 26.09| 15.11| 18.15|31.45| 15|
| 1|1997/11/20 22:30:00-23:00:00| 94.96| 63.48| 1.50| 27.73| 20.85| 14.90|33.15| 15|
| 1|1997/11/20 23:00:00-23:30:00| 28.07| 20.76| 1.35| 9.06| 8.14| 3.55|26.04| 15|
| |Totals for BTS 1 | 3690.90| 2280.64| 1.62| 980.80| 655.61| 644.22|38.21| 15|
September, 2002 RF200 - 139 RF200 v3.73 (c) 2002 Scott Baxter
Total Blocked Call Percentage Example
This is an example of a cumulative system-wide total blocked call
percentage chart maintained in one market
Total Block Call Percentage
1.0%
1.5%
2.0%
2.5%
3.0%
3.5%
4.0%
4.5%
5.0%
5.5%
6.0%
6.5%
7.0%
7.5%
8.0%
Date
P
e
r
c
e
n
t
Blkd
September, 2002 RF200 - 140 RF200 v3.73 (c) 2002 Scott Baxter
Dropped Call Percentage Tracking Example
Dropped call percentage tracking by one market
Total Drop Call Percentage
0.0%
0.5%
1.0%
1.5%
2.0%
2.5%
3.0%
3.5%
4.0%
4.5%
5.0%
Date
P
e
r
c
e
n
t
%Drops
September, 2002 RF200 - 141 RF200 v3.73 (c) 2002 Scott Baxter
Total System Daily MOU Example
Total system daily MOU plotted by one market
Daily Total System MOU
0
50000
100000
150000
200000
250000
300000
Date
M
O
U
Daily Total System MOU
September, 2002 RF200 - 142 RF200 v3.73 (c) 2002 Scott Baxter
Top Ten Performance Tracking Example
Many markets use scripts or spreadsheet macros to produce
ranked lists of sites with heavy traffic, performance problems, etc.
Call Attempts
Eng
Site
MSC
Site Call Att
Call
Succ
%Call
Succ
Block
Calls
%Blck
Calls
Acc
Fail
%Acc
Fail
Drop
Calls
%Drop
Calls Call Attempts
6.1 13X 2561 2234 87.2 130 5.1 130 5.1 145 5.7
2.1 2X 2244 2017 89.9 101 4.5 101 4.5 93 4.1
1.2 1Y 1922 1743 90.7 83 4.3 83 4.3 66 3.4
64.3 93Z 1833 1549 84.5 137 7.5 136 7.4 110 6.0
108.2 30Y 1740 1589 91.3 46 2.6 45 2.6 83 4.8
1.3 1Z 1630 1495 91.7 31 1.9 31 1.9 81 5.0
63.2 57Y 1623 1486 91.6 49 3.0 49 3.0 66 4.1
102.2 4Y 1615 1495 92.6 18 1.1 18 1.1 70 4.3
108.1 30X 1490 1387 93.1 27 1.8 27 1.8 54 3.6
43.3 42Z 1488 1410 94.8 4 0.3 4 0.3 53 3.6
0
500
1000
1500
2000
2500
3000
6
.
1
2
.
1
1
.
2
6
4
.
3
1
0
8
.
2
1
.
3
6
3
.
2
1
0
2
.
2
1
0
8
.
1
4
3
.
3
Sector
C
a
l
l
s
% Blocked Calls September 5, 1997
Eng
Site
MSC
Site Call Att
Call
Succ
%Call
Succ
Block
Calls
%Blck
Calls
Acc
Fail
%Acc
Fail
Drop
Calls
%Drop
Calls % Blocked Calls
64.3 93Z 1833 1549 84.5 137 7.5 136 7.4 110 6.0
6.1 13X 2561 2234 87.2 130 5.1 130 5.1 145 5.7
63.3 57Z 1282 1098 85.7 65 5.1 65 5.1 90 7.0
2.1 2X 2244 2017 89.9 101 4.5 101 4.5 93 4.1
1.2 1Y 1922 1743 90.7 83 4.3 83 4.3 66 3.4
63.2 57Y 1623 1486 91.6 49 3.0 49 3.0 66 4.1
64.1 93X 1027 926 90.2 30 2.9 30 2.9 58 5.7
26.3 35Z 855 698 81.6 24 2.8 24 2.8 112 13.1
108.2 30Y 1740 1589 91.3 46 2.6 45 2.6 83 4.8
1.3 1Z 1630 1495 91.7 31 1.9 31 1.9 81 5.0
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
6
4
.
3
6
.
1
6
3
.
3
2
.
1
1
.
2
6
3
.
2
6
4
.
1
2
6
.
3
1
0
8
.
2
1
.
3
Sector
%
September, 2002 RF200 - 143 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Data
Examples
Motorola System Data
Examples
September, 2002 RF200 - 144 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Data Examples
Usage OOS Orig Orig Orig Term Term Term RF RF Usage/
Cell MCC CE min min Atts Comps Fail% Atts Comps Fail% Loss Loss% Att
---- --- --- ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
88 1 2 383.1 146.2 170 160 5.9 20 19 5.0 2 1.1 121.0
88 1 3 426.3 146.2 154 150 2.6 10 10 0.0 3 1.9 156.0
88 1 4 456.9 146.2 160 156 2.5 22 22 0.0 7 3.9 150.6
88 1 5 448.2 146.2 163 162 0.6 18 18 0.0 4 2.2 148.6
88 1 6 439.5 146.2 162 159 1.9 20 20 0.0 2 1.1 144.9
88 1 7 439.9 146.2 160 157 1.9 14 14 0.0 5 2.9 151.7
88 1 8 351.6 146.2 186 182 2.2 23 23 0.0 5 2.4 100.9
88 1 9 397.4 146.2 164 161 1.8 20 20 0.0 3 1.7 129.6
88 1 10 422.5 146.2 177 174 1.7 15 15 0.0 2 1.1 132.0
88 1 11 402.2 146.2 183 179 2.2 22 22 0.0 1 0.5 117.7
88 1 12 398.2 146.2 179 176 1.7 13 13 0.0 5 2.6 124.4
88 1 13 447.5 146.2 163 161 1.2 26 26 0.0 11 5.9 142.1
88 1 14 263.5 146.2 290 83 71.4 31 19 38.7 5 4.9 49.3
88 1 15 307.8 146.2 264 68 74.2 36 9 75.0 3 3.9 61.5
88 2 2 403.1 105.9 165 162 1.8 14 14 0.0 1 0.6 135.1
88 2 3 477.0 105.9 163 158 3.1 18 18 0.0 3 1.7 158.1
88 2 4 419.4 105.8 166 161 3.0 24 24 0.0 2 1.1 132.4
88 2 5 445.8 105.8 174 171 1.7 14 14 0.0 7 3.8 142.3
88 2 6 525.1 105.8 157 155 1.3 17 17 0.0 3 1.7 181.1
88 2 7 422.0 105.8 165 161 2.4 18 17 5.6 1 0.6 138.4
88 2 8 430.3 105.8 188 183 2.7 14 14 0.0 7 3.6 127.8
88 2 9 419.9 105.8 167 166 0.6 12 11 8.3 6 3.4 140.7
88 2 10 391.0 105.3 165 164 0.6 22 22 0.0 4 2.2 125.5
88 2 11 443.5 105.3 174 168 3.4 11 11 0.0 5 2.8 143.8
88 2 12 412.5 105.3 177 171 3.4 21 21 0.0 4 2.1 125.0
88 2 13 394.2 105.3 196 192 2.0 16 16 0.0 6 2.9 111.6
88 2 14 432.0 105.3 141 139 1.4 18 18 0.0 5 3.2 163.0
88 2 15 388.5 105.3 178 176 1.1 17 17 0.0 2 1.0 119.5
September, 2002 RF200 - 145 RF200 v3.73 (c) 2002 Scott Baxter
Metrica Examples
Metrica Examples
September, 2002 RF200 - 146 RF200 v3.73 (c) 2002 Scott Baxter
Metrica Data Examples
Although Metrica is the preferred tool of some PCS operators for
performance analysis across all network platforms, it is more
useful in systems of some manufacturers and less useful in others
(see external examples)
September, 2002 RF200 - 147 RF200 v3.73 (c) 2002 Scott Baxter
Metrica: Switch Traffic Statistics
DAILY MSC SWITCHED TRAFFIC REPORT
ON 10/26/98
(DAILY NORMALISED TOTALS/AVERAGES)
-------- Switched ------
MSC Calls Failures Failure Data
Id. (%) (%)
------------------------------------------
VX1-ECP:1 158556 10637 6.71 100
MSC Traffic Calls Failures Failure Data
Id. Type (%) (%)
--------------------------------------------------------------------------------------------
VX1-ECP:1 Mobile-to-Mobile Originating (Lucent) 111 2 1.80 100
VX1-ECP:1 Mobile-to-Mobile Terminating (Lucent) 2157 913 42.33 100
VX1-ECP:1 Mobile Originating 128034 5772 4.51 100
VX1-ECP:1 Roamer Mobile Originating (Lucent) 104015 155 0.15 100
VX1-ECP:1 Roamer Mobile Terminating (Lucent) 27197 8 0.03 100
VX1-ECP:1 Mobile Terminating 30522 4865 15.94 100
September, 2002 RF200 - 148 RF200 v3.73 (c) 2002 Scott Baxter
Metrica: Traffic Engineering Counts
Traffic Engineering
Report Run Date: 10/27/98 Time(GMT-0): 21:02
DAILY CELL TRAFFIC REPORT
ON 10/26/98 FOR ALL CELLS IN REGION
(DAILY NORMALIZED TOTALS/AVERAGES)
Sorted by Traffic (E)
RF ------- Traffic ------- Resv
Cell Channels Blk RF Loss Channel Soft Code HO HO Pwr TCC Max Fwd Rev Data
ID Def Avail Atts Blks (%) Seizs Loss (%) (E) (E) (E) Blks Blks Dur Fail Busy Ovld Ovld (%)
-------------------------------------------------------------------------------------------------------------------------------
VX2020053 42 42.0 8605 0 0.0 8558 106 1.2 297.3 102.4 394.8 2 0 71 286 39 33 1 100
VX2020050 40 40.0 6159 0 0.0 6120 72 1.2 228.4 82.0 289.4 0 0 202 171 31 80 0 100
VX2020057 42 42.0 5082 0 0.0 5037 52 1.0 215.6 97.8 267.6 1 0 199 185 31 99 0 100
VX2020062 42 42.0 4755 0 0.0 4716 54 1.1 207.2 91.9 257.2 1 0 72 150 27 29 0 100
VX2020011 28 28.0 3685 0 0.0 3670 38 1.0 160.8 69.5 201.3 3 0 1 75 27 1 0 100
VX2020112 28 28.0 2512 0 0.0 2496 20 0.8 158.4 92.8 181.6 0 0 5 81 23 2 0 100
VX2020004 42 42.0 3845 0 0.0 3822 32 0.8 154.0 47.1 208.0 1 0 58 60 26 28 0 100
VX2020073 30 30.0 4182 0 0.0 4137 26 0.6 152.3 55.6 192.4 0 0 4 91 24 2 0 100
VX2020078 28 28.0 3429 0 0.0 3379 26 0.8 151.1 68.7 179.3 1 0 148 65 25 3 2 100
VX2020060 28 28.0 2978 0 0.0 2965 28 0.9 150.4 69.5 190.4 2 0 0 93 24 0 0 100
VX2020051 42 42.0 3193 0 0.0 3174 24 0.8 144.3 66.6 172.8 0 0 0 58 24 0 0 100
VX2020023 54 54.0 3330 0 0.0 3307 27 0.8 139.6 43.8 197.8 0 0 4 67 23 4 0 100
VX2020007 28 28.0 3520 0 0.0 3502 28 0.8 131.6 47.9 165.9 1 0 97 74 26 26 1 100
VX2020017 30 30.0 2902 0 0.0 2889 24 0.8 130.0 45.9 181.7 1 0 51 70 23 0 1 100
VX2020076 28 28.0 2888 0 0.0 2867 25 0.9 129.6 54.8 174.5 0 0 312 74 22 4 1 100
VX2020012 28 28.0 3313 0 0.0 3297 21 0.6 122.1 37.8 166.2 1 0 74 61 23 1 2 100
VX2020016 28 28.0 3049 0 0.0 3027 18 0.6 120.8 46.5 162.1 2 0 17 44 22 8 0 100
VX2020067 28 28.0 2537 0 0.0 2519 30 1.2 118.3 51.2 145.9 0 0 0 46 19 0 0 100
VX2020001 28 28.0 2746 0 0.0 2737 25 0.9 114.9 42.2 150.6 0 0 0 37 22 0 0 100
VX2020003 28 28.0 2031 0 0.0 2019 19 0.9 113.4 54.6 153.7 0 0 53 41 20 1 1 100
September, 2002 RF200 - 149 RF200 v3.73 (c) 2002 Scott Baxter
Metrica: Daily Sector Traffic Reports
Traffic Engineering
Report Run Date: 10/27/98 Time(GMT-0): 21:02
DAILY SECTOR TRAFFIC REPORT
ON 10/26/98 FOR ALL SECTORS IN REGION DropCity_2
(BUSY HOUR VALUES)
Sorted by Code Traffic (E)
Note: Busy Hour is in local time
Sector Busy ----- Attempts ------ RFLoss HO Cd Traff Overload
Name Hour Total Orig Term Seizs RFLoss (%) Seizs (E) Duration
-----------------------------------------------------------------------------------------------------------------------
VX2-ECP:2-CELL:53-SECT:3 17:00 372 312 60 369 6 1.63 3325 12.62 8
VX2-ECP:2-CELL:57-SECT:1 17:00 183 158 25 180 2 1.11 2464 10.07 51
VX2-ECP:2-CELL:53-SECT:1 17:00 251 205 46 251 6 2.39 2336 9.57 4
VX2-ECP:2-CELL:62-SECT:1 18:00 193 144 49 193 5 2.59 2507 9.32 8
VX2-ECP:2-CELL:50-SECT:3 17:00 289 243 46 284 4 1.41 2042 8.82 74
VX2-ECP:2-CELL:4-SECT:2 16:00 165 131 34 164 4 2.44 2203 8.67 15
VX2-ECP:2-CELL:4-SECT:3 16:00 120 86 34 118 1 0.85 2653 8.31 36
VX2-ECP:2-CELL:50-SECT:1 17:00 184 148 36 183 0 0.00 2174 8.23 2
VX2-ECP:2-CELL:23-SECT:3 11:00 194 140 54 193 1 0.52 2282 8.11 0
VX2-ECP:2-CELL:53-SECT:2 18:00 143 111 32 143 5 3.50 2060 8.02 2
VX2-ECP:2-CELL:78-SECT:3 15:00 133 99 34 133 3 2.26 2198 7.94 1
VX2-ECP:2-CELL:17-SECT:3 15:00 201 143 58 200 1 0.50 1853 7.75 0
VX2-ECP:2-CELL:12-SECT:2 16:00 144 91 53 144 2 1.39 1662 7.29 3
VX2-ECP:2-CELL:7-SECT:3 17:00 191 133 58 188 0 0.00 2375 7.21 28
VX2-ECP:2-CELL:3-SECT:3 15:00 144 99 45 143 1 0.70 2144 7.07 2
VX2-ECP:2-CELL:57-SECT:2 20:00 155 116 39 151 1 0.66 1884 7.01 2
VX2-ECP:2-CELL:11-SECT:1 17:00 132 98 34 132 2 1.52 1800 6.84 0
September, 2002 RF200 - 150 RF200 v3.73 (c) 2002 Scott Baxter
Metrica: Forward Power Overload Reports
DAILY SECTOR POWER OVERLOAD REPORT
ON 10/26/98 FOR ALL SECTORS IN REGION
(DAILY TOTALS)
Sector RPwrOvldDur RPwrOvlds FPwrOvldDur FPwrOvlds
Id. (min) Incidents (min) Incidents
-------------------------------------------------------------------------------------------------
VX2-ECP:2-CELL:3-SECT:3 0.85 1 0.03 1
VX2-ECP:2-CELL:4-SECT:1 0.00 0 0.00 0
VX2-ECP:2-CELL:4-SECT:2 0.00 0 0.35 15
VX2-ECP:2-CELL:4-SECT:3 0.00 0 0.62 13
VX2-ECP:2-CELL:5-SECT:1 0.00 0 0.00 0
VX2-ECP:2-CELL:5-SECT:2 0.00 0 0.02 1
VX2-ECP:2-CELL:6-SECT:2 0.00 0 0.00 2
VX2-ECP:2-CELL:7-SECT:2 0.00 0 0.33 8
VX2-ECP:2-CELL:7-SECT:3 0.00 0 0.60 18
VX2-ECP:2-CELL:11-SECT:3 0.00 0 0.02 1
VX2-ECP:2-CELL:12-SECT:1 0.67 1 0.00 0
VX2-ECP:2-CELL:12-SECT:2 0.52 1 0.05 1
VX2-ECP:2-CELL:14-SECT:1 0.00 0 0.00 1
VX2-ECP:2-CELL:15-SECT:3 1.02 1 0.02 1
VX2-ECP:2-CELL:16-SECT:1 0.00 0 0.28 8
VX2-ECP:2-CELL:16-SECT:2 0.00 0 0.00 0
VX2-ECP:2-CELL:16-SECT:3 0.00 0 0.00 0
September, 2002 RF200 - 151 RF200 v3.73 (c) 2002 Scott Baxter
Metrica: RF Overload Blocking Estimation
DAILY ESTIMATION OF BLOCKING DUE TO RF OVERLOAD
ON 10/26/98 FOR ALL CELLS IN REGION
(DAILY TOTALS)
Definitions:
-----------
- Percentage of total attempts (orig and term) that are terminations (L-M calls)
%Term = CDMA_PAF3 / (CDMA_PAF2 + CDMA_PAF3)
- Blocked terminations due to equipment blocks (no CEs avail or packet pipe blocked)
TerCS7 = CDMA_CS7 * %Term
- Blocked originations due to equipment blocks (no CEs avail or packet pipe blocked)
OrgCS7 = CDMA_CS7 - TerCS7
- Blocked originations due to RF power overload
OrgPwrBlk = SUM(CDMA_PAF26) - OrgCS7
- Total blocked originations/terminations due to RF power overload
TotPwrBlk = (OrgPwrBlk * %Term) + OrgPwrBlk
- Percentage of call attempts blocked at the cell due to RF power overload
Pwr%Blk = TotPwrBlk / (SUM(CDMA_PAF2) + SUM(CDMA_PAF3) - CDMA_CP8 - SUM(CDMA_PAF25)) * 100
- Percentage of call attempts due to equipment blks/TCCF/RF power overload
Tot%Blk = (TotPwrBlk + CS7 + TotTCC) / (SUM(CDMA_PAF2) + SUM(CDMA_PAF3) - CDMA_CP8 -
SUM(CDMA_PAF25)) * 100
September, 2002 RF200 - 152 RF200 v3.73 (c) 2002 Scott Baxter
Metrica: RF Overload Blocking Indications
DAILY ESTIMATION OF BLOCKING DUE TO RF OVERLOAD
ON 10/26/98 FOR ALL CELLS IN REGION
(DAILY TOTALS)
Org Tot
Cell Rev Rev Fwd Fwd Org Ter Tot Re- Org Ter Tot Ter Org Pwr Pwr Pwr Tot
Id. Pwr Dur Pwr Dur Att Att Att %Term Ord TCC TCC TCC cs7 cs7 cs7 Blk Blk %Blk %Blk paf25 cp8
-----------------------------------------------------------------------------------------------------------
VX2020001 0 0 0 0 1869 877 2746 31.9 1 26 11 37 0 0 0 1 1 0.0 1.4 0 0
VX2020002 0 0 0 0 809 373 1182 31.6 2 18 2 20 0 0 0 2 3 0.2 1.9 0 0
VX2020003 1 1 1 0 1428 603 2031 29.7 4 27 14 41 0 0 0 4 5 0.3 2.3 0 0
VX2020004 0 0 28 1 2780 1065 3845 27.7 7 40 20 60 0 0 0 7 9 0.2 1.8 0 2
VX2020005 0 0 1 0 544 182 726 25.1 0 6 0 6 0 0 0 0 0 0.0 0.8 0 0
VX2020006 0 0 2 0 731 339 1070 31.7 0 8 7 15 0 0 0 0 0 0.0 1.4 0 0
VX2020007 1 1 26 1 2493 1027 3520 29.2 5 59 15 74 0 0 0 5 6 0.2 2.3 0 1
VX2020008 0 0 0 0 2056 998 3054 32.7 0 23 19 42 0 0 0 0 0 0.0 1.4 0 0
VX2020009 0 0 0 0 626 212 838 25.3 3 10 2 12 0 0 0 3 4 0.4 1.9 0 0
VX2020010 0 0 0 0 877 349 1226 28.5 1 31 3 34 0 0 0 1 1 0.1 2.9 0 0
VX2020011 0 0 1 0 2577 1108 3685 30.1 1 60 15 75 0 0 0 1 1 0.0 2.1 0 0
VX2020012 2 2 1 0 2364 949 3313 28.6 4 45 16 61 0 0 0 4 5 0.2 2.0 0 0
VX2020014 0 0 1 0 670 245 915 26.8 3 11 4 15 0 0 0 3 4 0.4 2.1 0 0
VX2020015 1 1 1 0 1275 596 1871 31.9 4 24 9 33 0 0 0 4 5 0.3 2.0 0 0
VX2020016 0 0 8 0 2156 893 3049 29.3 4 36 8 44 0 0 0 4 5 0.2 1.6 0 0
VX2020017 1 1 0 0 2091 811 2902 27.9 1 54 16 70 0 0 0 1 1 0.0 2.4 0 0
VX2020018 0 0 0 0 950 393 1343 29.3 1 28 1 29 0 0 0 1 1 0.1 2.2 0 0
VX2020019 0 0 1 0 1254 513 1767 29.0 0 32 9 41 0 0 0 0 0 0.0 2.3 0 0
September, 2002 RF200 - 153 RF200 v3.73 (c) 2002 Scott Baxter
CDMA System Parameters
CDMA System Parameters
September, 2002 RF200 - 154 RF200 v3.73 (c) 2002 Scott Baxter
Lucent System Parameters
Lucent System Parameters
September, 2002 RF200 - 155 RF200 v3.73 (c) 2002 Scott Baxter
Lucent BTS Parameters Example
SysID 179 179 179 179 179 179 179 179 179 179 179 179 179 179 179 179 179 179 179 179 179
ECPID 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
CellID 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2
Antenna 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 1 1 1
CDMAPilotPN 4 4 4 4 4 4 172 172 172 172 172 172 340 340 340 340 340 340 8 8 8
CDMAPilotDrpThrsh -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15
CDMAPilotDetThrsh -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13
CDMACompThrsh 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2.5 2 2 2
CDMADropTimer 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
CDMASrchWinActCand 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
CDMASrchWinNbr 9 9 9 9 9 9 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
CDMASrchWinRemain 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
CDMAPilotGain 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108
CDMAPageGain 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64
CDMASyncGain 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34
CDMABCRAtt 6 6 6 6 6 6 6 6 6 6 6 6 8 8 8 8 8 8 8 8 8
SectorSize_ceqface
BBAMaxPower 33.5 33.5 21 21 33.5 33.5 33.5 33.5 21 21 33.5 33.5 33.5 33.5 21 21 33.5 33.5 25 25 25
CDMAMinTrfChnlGain_R2
CDMAMaxTrfChnlGain_R2
CDMATrafGain_R2
CDMAFwdFrmErrRate_R2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
CDMARevFrmErrRate_R2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
CDMANomEbNoSetPt_R2 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8 6.8
CDMAMinEbNoSetPt_R2 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8
CDMAMaxEbNoSetPt_R2 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8 8.8
Srchwincell 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
September, 2002 RF200 - 156 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters
Nortel System Parameters
September, 2002 RF200 - 157 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters Example
Nortel parameters are built in files on the BSM, then downloaded
to BTS and SBS locations
Proto type datafill for 1900 CDMA Syste m Parame te rs
Parame te r Name Range Re comme nde d Value Re marks
1. CDMA Channe l Parame te rs
S ys tem Determination and Acquis ition
CDMA_ AVAIL 0 - 1 1
CDMA_FREQ (CDMA_CHAN) 0 - 2047 See Remarks As determined by the local MTA
BAND_CLASS 0 - 31 1 1900 MHz
S ys tem Acquis ition (S ync channel Information)
P_REV 0-255 1
MIN_P_REV 0-255 1
SID 0 - 32,767 See Remarks As determined by the local MTA
NID 0 - 65,535 See Remarks As determined by the local MTA
PILOT_PN 0 - 511 See Remarks As determined by the local MTA
LC_STATE See Remarks Determined by the s ys tem. TBA
SYS_TIME TFU_1 or TFU_2 See Remarks As detetermined by the Sys tem time
PRAT 0-3 1
LP_SEC 0-255 13 TBA
LTM_OFF 0-63 16 TBA
DAYLT 0 - 1 0 or 1 Depending on whether Daylight s aving is On/Off
September, 2002 RF200 - 158 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters Example
Parameters here determine contents of Access Parameters
Message on the Paging Channel
2. Acce ss Parame te rs
Reques t Res pons e Parameters
PSIST(0-9) 0 - 63 0 ACCOLC(0 -9) are all permitted to trans mit
PSIST(10-15) 0 - 7 0 ACCOLC(10 -15) are all permitted to trans mit
MAX_CAP_SZ 0 - 7 3 3 Frames mes s age
PAM_SZ 0 - 15 4 4 Frames preamble
REG_PSIST 0 - 7 0
MSG_PSIST 0 - 7 0
PROBE_PN_RAN 0 - 15 0
ACC_CHAN 0 - 31 0 1 Acces s channel
ACC_TMO 0 - 15 (x80 ms ) 3 (2+1), 240 ms
PROBE_BKOFF 0 - 15 0 (0 + 1) s lot delay
BKOFF 0 - 15 1 (0 + 1) s lot delay
MAX_REQ_SEQ 0 - 15 2
MAX_RSP_SEQ 0 - 15 2
AUTH 0 - 3 0 No s tandard Authentication
RAND 0-(232-1) 0 Not applicable without Authentication
September, 2002 RF200 - 159 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters Example
Parameters here determine the contents of the registration fields of
the System Parameters Message on the paging channel
Regis taration Parameters
SID 0 - 32,767 See Remarks As determined by the local MTA
NID 0 - 65,535 See Remarks As determined by the local MTA
REG_ZONE 0 - 4095 As determined by the network Zone Regis tration not currently s upported
TOTAL_ZONES 0 - 7 0 Zone Regis tration not currently s upported
ZONE_TIMER 0 - 7 0 Zone Regis tration not currently s upported
MULTI_SIDS 0 - 1 0 If roaming is permitted, this s hould be s et to 1
MULTI_NIDS 0 - 1 0 If roaming or more than one NID in the MTA, s et to 1
BASE_ID 0 - 65,535 See Remarks As determined by the local MTA
BASE_CLASS 0 - 15 0 Public macro cellular s ys tem
PAGE_CHAN 0 - 7 1 One paging channel
MAX_SLOT_CYCLE_INDEX 0 - 7 5
HOME_REG 0 - 1 1
FOR_SID_REG 0 - 1 1
FOR_NID_NEG 0 - 1 1
POWER_UP_REG 0 - 1 1
POWER_DOWN_REG 0 - 1 1
PARAMETER_REG 0 - 1 1
REG_PRD 0 - 127 0 Periodic regis tration every 2621 s ec (43 min)
BASE_LAT -1296000, +1296000 See Remarks As determined by the local MTA
BASE_LONG -2592000, +2592000 See Remarks As determined by the local MTA
REG_DIST 0 No dis tance bas ed regis tration
RESCAN 0-2047 0
September, 2002 RF200 - 160 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters Example
These parameters are communicated to the mobile in the
overhead messages on the Paging Channel.
3. Powe r Control Parame te rs
Open Loop
NOM_PWR 0 -15 8 8' = 0 dB
INIT_PWR 0 - 31 16 16' = 0 dB
PWR_STEP 0 - 7 3 3 dB
NUM_STEP 0 - 15 6 (6 +1) acces s probes per s equence
Forward Power Control
PWR_REP_THRESH 0 - 31 2 Only applicable to RateSet1 (8 kbps ) data
PWR_REP_FRAMES 0 - 15 7 Only applicable to RateSet1 (8 kbps ) data
PWR_THRESH_ENABLE 0 - 1 1 Only applicable to RateSet1 (8 kbps ) data
POWER_PERIOD_ENABLE 0 -1 0 Only applicable to RateSet1 (8 kbps ) data
POWER_REP_DELAY 0 - 31 1 4 frames , only applicable to RateSet1 (8 kbps ) data
4. Handoff Parame te rs
Pilot S earch Parameters
PILOT_PN 0-1 1 As determined by the local MTA
SEARCH_WIN_A 0 - 15(4 - 452 PN Chps ) 8 60 PN chips
SEARCH_WIN_N 0 - 15(4 - 452 PN Chps ) 10 100 PN chips
SEARCH_WIN_R 0 - 15(4 - 452 PN Chps ) 10 100 PN chips
NGHBR_MAX_AGE 0 - 15 2
PILOT_INC 0 - 15 4
NGHBR_CONFIG 0 - 7 0
Pilot S trength Parameters
T_ADD 0 - 63(-0.5x dB) 28 -14 dB
T_DROP 0 - 63(-0.5x dB) 32 -16 dB
T_TDROP 0 - 15 (=< 0.1 - 319 s ec) 3 4 s ec
T_COMP 0 - 15 (x0.5 dB) 5 2.5 dB
September, 2002 RF200 - 161 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters Example
NMIS Parame te r Range Re comme nde d Value Re marks
Acquisition
Acces s ChannelAcquis itionSearchWidth 25 - 4095 TBA Us ed by the BTS for the reves e link
Acces s ChannelDemodulationSearchWidth 25 - 4095 TBA Us ed by the BTS for the reves e link
TrafficChannelAcquis itionSearchWidth 25 - 4095 TBA Us ed by the BTS for the reves e link
TrafficChannelDemodulationSearchWidth 25 - 4095 TBA Us ed by the BTS for the reves e link

Powe rControl
RateSet1Data, RateSet2Data
PrRXerror (FER %)
Full 1/16 - 256/16 16/16 1%
Half 1/16 - 256/16 80/16 5%
Quarter 1/16 - 256/16 80/16 5%
Eighth 1/16 - 256/16 80/16 5%
Unknown 1/16 - 256/16 16/16 1%
RRXincreas e
Full 1/256 - 4095/256 42/256
Half 1/256 - 4095/256 7/256
Quarter 1/256 - 4095/256 7/256
Eighth 1/256 - 4095/256 7/256
Unknown 1/256 - 4095/256 14/256
RateSet1Data
PRXlower (Ew/Nt) 1/256 - 4095/256 2048/256 (8 - 10log2) = 5 dB Eb/Nt
PRXupper (Ew/Nt) 1/256 - 4095/256 3328/256 (11 - 10log2) = 8 dB Eb/Nt
PRXs tart (Ew/Nt) 1/256 - 4095/256 2688/256 (10.5 - 10log2) = 7.5 dB Eb/Nt
RateSet2Data
PRXlower (Ew/Nt) 1/256 - 4095/256 2509/256 (10 - 10log3) = 5.2 dB Eb/Nt
PRXupper (Ew/Nt) 1/256 - 4095/256 3789/256 (13 - 10log3) = 8.2 dB Eb/Nt
PRXs tart (Ew/Nt) 1/256 - 4095/256 3149/256 (12.5 - 10log3) = 7.7 dB Eb/Nt
RateSet1Data
PrTXerror 1/16 - 256/16 16 1%
RTXincreas e 1/256 - 4095/256 20/256
PTXlower -4095/256 - 0/256 -2304/256 -9 dB
PTXupper -4095/256 - 0/256 -768/256 -3 dB
PTXs tart -4095/256 - 0/256 -1536/256 -6 dB
RateSet2Data
PrTXerror 1/16 - 256/16 16 1%
RTXincreas e 1/256 - 4095/256 133/256
PTXlower -4095/256 - 0/256 -3072/256 -12 dB
PTXupper -4095/256 - 0/256 -256/256 -1 dB
PTXs tart -4095/256 - 0/256 -1536/256 -6 dB
PowerControlGainOffs et -127 to 128 0
September, 2002 RF200 - 162 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters Example
Wilting and blossoming are techniques for gracefully taking a sector from
service or returning it to service without dropping traffic.
Wilting, Blos s oming and Breathing Parameters
WiltBlos s StepSize 0/16 - 255/16 dB (0-255) 4/16 dB (4) Rate s hould be 1 dB/s ec
WiltBlos s StepTime 1 - 20 (units of 100 ms ) 1 100 ms ec
WiltBlos s Enabled 0 - 1 1
BreathingStepSize 1/16 - 255/16 dB/ms 4/16 dB/ms Rate s hould be 1 dB/s ec
BreathingStepTime 1 - 20 (units of 100 ms ) 1 100 ms ec
BreathingDelta 0/16 - 255/16 dB (0-255) 192/16 (4 dB [64] or more) 12 dB ris e over the nois e floor
BreathingEnabled 0 - 1 0 Dis abled
RecPowerEs timationFilterRate 2 - 40 (units of 5 ms ) 4 Steps of 5 ms . 4 =20 ms
RecPowerDecayExponential 0 - 16 6
TXAttenNormal 0-70 (0/16 - 1120/16 dB) See Remarks As given by the ins talltion & calibration
TXPowerMax 384/16 - 736/16 dBm 672/16 42 dBm(16 W)
TXAttenAntenna 0-6 (0/16 - 96/16 dB) 0 As determined by Pilot Channel calibration proces s . As meas ure
TPEFilterDecayExponential 0 - 16 5
Revers eLinkCapacityEs timationRate 20*5 to 255*5 ms 100 (20*5) Not s upported
HandoffBlockingThres hold 0-100 % 5? Not s upported
CallBlockingThres hold 0-100 % 10? Not s upported
RXFEGain
RcvrA 0/16 - 480/16 dB See Remarks As given by the ins talltion & calibration
RCVRB 0/16 - 480/16 dB See Remarks As given by the ins talltion & calibration
RXFENois eFigure
RCVRA 0/16 - 160/16 dB See Remarks As given by the ins talltion & calibration
RCVRB 0/16 - 160/16 dB See Remarks As given by the ins talltion & calibration
RXCableAtten According to above cable los s of antenna path for the s pecific ap
RcvrA 0/16 - 480/16 dB See Remarks As given by the ins talltion & calibration
RCVRB 0/16 - 480/16 dB See Remarks As given by the ins talltion & calibration
RXCableNois eFigure Clos e to RxCableAtten According to nois e figure intro'd due to cable los s of antenna pat
RCVRA 0/16 - 160/16 dB See Remarks As given by the ins talltion & calibration
RCVRB 0/16 - 160/16 dB See Remarks As given by the ins talltion & calibration
RXCardNois eFigureMin 0/16 - 1120/16 5 dB for 800, 4 dB for 1900 As given by the Rx card calibration
RXCardNois eFigureMax 0/16 - 1120/16 960/16 60 dB
September, 2002 RF200 - 163 RF200 v3.73 (c) 2002 Scott Baxter
Nortel System Parameters Example
These parameters set the power levels of the overhead channels.
Pilot Data Base
PilotChanne l
CDMACenterFrequency ?? See Remarks As determined by the Preferred Channel Set
ExtendedBas eId word32 See Remarks BandClas s , CDMAFreq,BASE_ID,Sector
Available 0 -1 1
QuickRepeat 0 -1 0 dis abled
BlankAndBurs t 0 -1 0 Not us ed
ForwardGain 0 - 255 TBA
PilotGain 0 - 255 216 216 for 800 MHz
MinPilotToTotalPwrRatio -255/16 to 0/16 dB -7 20% of HPA power
NeighborLis t word32Array, up to 20 nieghb See Remarks As determined by the RF des ign
CellType CELL_STANDARD, CELL_P CELL_STANDARD If no HHO in the cell
CELL_BORDER
SyncChanne l
SyncGain 0 - 255 68 10 dB down from pilot for 800 MHz
PagingChanne l
PagingGain 0 - 255 130 4.4 dB down from pilot for 800 MHz
September, 2002 RF200 - 164 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System
Parameters
Motorola System
Parameters
September, 2002 RF200 - 165 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Parameters
List all BTSs for MM1 MM2.
System: BRDVILBOCM0OMC1 Prev BTS <-
Id: OMC1 MM2 BTS88 Next BTS ->
Name: 265A_S2_
Location: 41.58.39, -87.54.14
Band: 1900 MHz PilotInc: 3
Carriers: 1-375
SiteConf: 120-SC600
Service Option: 13KVoice
Release: Apr 28 13:18 2.8.1.21.22
Exported on: Mon Jun 14 00:00:17 CDT 1999
September, 2002 RF200 - 166 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Parameters
Motorola customers should obtain the proprietary Motorola
document, CDMA RF Application Note: Parameters and
Optimization, draft version 8.1 or later, available from your
Motorola representative.
This document gives descriptions of most system parameters and
many operational peg counts and valuable guidance for setting
parameters.
September, 2002 RF200 - 167 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Parameters
Forward Pwr Ctrl Sector 1 Sector 2 Sector 3 Default
C1 C1 C1
PilotPn 66 237 408 0
PilotGain 127 127 127 127
SchGain 40 40 40 40
PchGain 110 110 110 110
SifPilotPwr 31 31 31 31 dBm
MinPcbGain 20 20 20 20
PcbGainFact 0.75 0.75 0.75 0.75
FwdPwrThresh 2 2 2 2 Frm
PwrThreshEna 1 1 1 1
PwrPeriodEna 0 0 0 0
PwrRepThresh 3 3 3 3 Frm
PwrRepFrames 7 7 7 7 Frm
PwrRepDelay 12 12 12 12 Frm
September, 2002 RF200 - 168 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Parameters
Reverse Pwr Ctrl Sector 1 Sector 2 Sector 3 Default
C1 C1 C1
NomPwr 3 3 3 3 dB
InitPwr -3 -3 -3 -3 dB
PwrStep 5 5 5 5 dB
NumStep 4 4 4 4
RPCMaxEbNo 12.5 12.5 12.5 12.5 dB
RPCNomEbNo 9 9 9 9 dB
RPCMinEbNo 6 6 6 6 dB
RPCThrshNom 1930 1930 1930 0
Cell Size Sector 1 Sector 2 Sector 3 Default
C1 C1 C1
TchacqWinSz 125 125 125 125 chp
TchmpthWinSz 25 25 25 25 chp
TchPamWinSz 25 25 25 25 chp
CellRadius 6 6 6 10 km
September, 2002 RF200 - 169 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Parameters
Handoff Sector 1 Sector 2 Sector 3 Default
C1 C1 C1
SrchWinA 6 6 6 6 chp
SrchWinN 8 8 8 8 chp
SrchWinR 9 9 9 9 chp
TAdd -14 -14 -14 -14 dB
TDrop -16 -16 -16 -16 dB
TComp 4 4 4 4 dB
TTDrop 3 3 3 3
September, 2002 RF200 - 170 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Parameters
TCH Gain Sector 1 Sector 2 Sector 3 Default
C1 C1 C1
MaxGain1Way 127 127 127 127
NomGain1Way 80 80 80 80
MinGain1Way 20 20 20 20
MaxGain2Way 127 127 127 127
NomGain2Way 80 80 80 75
MinGain2Way 20 20 20 20
MaxGain3Way 127 127 127 127
NomGain3Way 80 80 80 75
MinGain3Way 20 20 20 20
StepUp 10 10 10 5
StepDown 1 1 1 1
DeltaTime 7 7 7 7 Frm
StepDownDel 21 21 21 21 Frm
OrigDelay 100 100 100 100 Frm
TchWCCnt 42 42 42 42 TCH
September, 2002 RF200 - 171 RF200 v3.73 (c) 2002 Scott Baxter
Motorola System Parameters
N-Way Sector 1 Sector 2 Sector 3 Default
C1 C1 C1
HoConstr 1 1 1 1
MaxActSetSz 6 6 6 6
MaxCEPerCall 3 3 3 3
TcompEnaThr -14.5 -14.5 -14.5 -14.5
MaxBTSLegs1 3 3 3 3
MaxBTSLegs2 2 2 2 3
MaxBTSLegs3 2 2 2 2
AggActLimit1 35 35 35 35
AggActLimit2 43 43 43 43
AggActLimit3 51 51 51 51
EnableSofter Enable Enable Enable 0
EnableBTS Enable Enable Enable 0
EnableSoft Enable Enable Enable 0
AggrStr1 0 0 0 -6 dB
AggrStr2 -7 -7 -7 -8 dB
AggrStr3 -9 -9 -9 -10 dB
NumCandidate 10 10 10 10
XCTComp 3 3 3 4 dB
SofterShuff 3 3 3 3 dB
BTSShuffleC 3 3 3 0 dB
SoftShuffle 3 3 3 3 dB
September, 2002 RF200 - 172 RF200 v3.73 (c) 2002 Scott Baxter
Introduction to
Optimization Tools
Introduction to
Optimization Tools
Course RF200 Section III
September, 2002 RF200 - 173 RF200 v3.73 (c) 2002 Scott Baxter
All trademarks are the property of their respective owners.
Corporate Logos and Product Images used with permission of their owners.
This work may not be reproduced in whole or in part without the permission of the copyright owner.
September, 2002 RF200 - 174 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 175 RF200 v3.73 (c) 2002 Scott Baxter
Department Store Analogy: Tops-Down, Bottoms-Up
Some things are easier to measure from the customer side!
Complex!!! Simpler
System Phone
Neighbor Lists
D
a
t
a
A
n
a
ly
s
is
S
o
f
t
w
a
r
e
Trans-
mission
Configuration
Provisioning
PSTN Trunking
D
r
o
p
p
e
d

C
a
l
l
s
C
o
v
e
r
a
g
e
A
c
c
e
s
s
F
a
ilu
r
e
s
Switch
BTS
CBSC
I
n
t
e
r
f
e
r
e
n
c
e
Administration
D
a
t
a
C
a
p
t
u
r
e
Field Tools
Profits
Complex!!! Simpler
Management Test Shopper
Labor Relations
C
o
s
t
s
T
a
x
e
s
I
n
s
u
r
a
n
c
e
S
u
p
p
l
i
e
r
s
L
e
a
s
e
s
Capital
Stocking
D
i
s
t
r
i
b
u
t
i
o
n
L
o
s
s
e
s
A
d
v
e
r
t
i
s
i
n
g
S
e
l
e
c
t
i
o
n
C
o
n
v
e
n
i
e
n
c
e
P
r
ic
e
S
e
r
v
i
c
e
September, 2002 RF200 - 176 RF200 v3.73 (c) 2002 Scott Baxter
Aeronautical Analogy: Tools for Problem Investigation
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.
Control & Parameters Messaging
BTS
11500 11500
114.50
118.25
130.75
Aeronautical
Case
CDMA Case
Flight Data Recorder Cockpit Voice Recorder
Temporal Analyzer Data Layer 3 Message Files
September, 2002 RF200 - 177 RF200 v3.73 (c) 2002 Scott Baxter
Sources of CDMA Data and Tools for Processing
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
CBSC Switch BTS
CDSU DISCO
Ch. Card ACC






TFU1
GPSR
CDSU
CDSU
DISCO 1
DISCO 2
SBS
Vocoders
Selectors
CDSU
CDSU
CDSU
CDSU
CDSU
CDSU
CM SLM
LPP LPP ENET
DTCs
DMS-BUS
Txcvr A
Txcvr B
Txcvr C
RFFE A
RFFE B
RFFE C
TFU1
GPSR
IOC
BSM
Data Analysis
Post-Processing
Tools
IS-95/J-STD-008 Messages
IS-95/J-STD-8
Messages
Switch Data
pegs, logs
Mobile Data
Post-Processing
Tools
Mobile Data
Capture Tools
Handset
Messages
External
Analysis
Tools
PC-based
PC-based
Unix-based,
PC-based
Various
CDMA NETWORK EQUIPMENT
HANDSET
System Internal Messages
September, 2002 RF200 - 178 RF200 v3.73 (c) 2002 Scott Baxter
CDMA Field Test Tools
Field Collection Tools using Handset Data
There are many commercial CDMA field test tools
Characteristics of many test tools:
capture data from data ports on commercial handsets
log data onto PCs using proprietary software
can display call parameters, messaging, graphs, and maps
store data in formats readable for post-processing analysis
small and portable, easy to use in vehicles or even on foot
A few considerations when selecting test tools:
does it allow integration of network and mobile data?
Cost, features, convenience, availability, and support
new tools are introduced every few months - investigate!
Qualcomm
Grayson
Comarco
SAFCO
LCC
Motorola
PN Scanners
Agilent
(formerly HP)
Agilent
(formerly HP)
Berkeley
Varitronics
Grayson Qualcomm
Safeco Willtech
September, 2002 RF200 - 179 RF200 v3.73 (c) 2002 Scott Baxter
Qualcomms MDM: Mobile Diagnostic Monitor
Qualcomms Mobile Diagnostic Monitor
CDMA handset (customer provided)
Proprietary connecting cable
PC software for collection and field pre-
analysis
Temporal analyzer display mode
Messaging
September, 2002 RF200 - 180 RF200 v3.73 (c) 2002 Scott Baxter
Grayson Electronics Mobile Collection Tools
Wireless Measurement Instrument
one hardware platform, can contain up
to 4 receivers, handsets, scanners, and
other devices
Inspector32 PC collection software
numerous output formats & exporting -
ASCII messages, database, temporal
data
simultaneous display of parameters,
map location, messaging, PN scanner
Analyzer
TM
post-processing software
call event statistics, parameters,
performance indicators as map icons,
graphs, and spreadsheet tables
message display window synched with
maps and graphs
can search for events, messages
can study multiple drive files at once
September, 2002 RF200 - 181 RF200 v3.73 (c) 2002 Scott Baxter
Graysons new Invex3G Tool
In 1Q2001 Grayson introduced
its new Invex3G tool, with new
features
100 MB ethernet connection
to PC
the eight card slots can hold
receivers or dual-phone
cards
theres also room for two
internal PN scanners
Multiple Invex units can be
cascaded for multi-phone
load-test applications
Cards are field-swappable -
Users can reconfigure the
unit in the field for different
tasks without factory
assistance
September, 2002 RF200 - 182 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 183 RF200 v3.73 (c) 2002 Scott Baxter
Comarco Mobile Tools
X-Series Units for more data-
intensive collection activities
Multiple handsets can be
collected
Data is displayed and
collected on PC
LT-Series provides integrated
display and logging
"Workbench" Post-Processing
tool analyzes drive-test files
September, 2002 RF200 - 184 RF200 v3.73 (c) 2002 Scott Baxter
PN Scanners
Why PN scanners? Because phones cant
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
Grayson Wireless
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
September, 2002 RF200 - 185 RF200 v3.73 (c) 2002 Scott Baxter
Post-Processing Tools
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
Grayson Interpreter
Imports/analyzes data from Grayson
Wireless Inspector, Illuminator, and
Invex3G
Agilent OPAS32
Imports/analyzes a variety of data
Nortel RF Optimizer
Can merge/analyze drive-test and
Nortel CDMA system data
Wavelink
Comarco "Workbench" Tool
Verizon/Airtouch internal tool
OPAS32
COMARCO
September, 2002 RF200 - 186 RF200 v3.73 (c) 2002 Scott Baxter
Drive-Testing
Some General Guidelines
Some General Guidelines
September, 2002 RF200 - 187 RF200 v3.73 (c) 2002 Scott Baxter
Safety Considerations
Dont worry for the companys loss due to your accidental death
Qualified and eager replacements have resumes on file
Were constantly buying more drive-test vehicles
We were going to replace that old drive-test equipment soon
Were not really sure we needed your last drive test, anyway
Your death will serve as a warning to others, so its not in vain
Its 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, dont try to deal with it or correct it while driving
Just pull over to the next really safe place to assess and correct
September, 2002 RF200 - 188 RF200 v3.73 (c) 2002 Scott Baxter
Physical Considerations
Be sure the connections (power, phone, PC and GPS cables) are
secure so they wont dislodge during collection and distract you
Be sure the equipment is physically restrained so it wont 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
September, 2002 RF200 - 189 RF200 v3.73 (c) 2002 Scott Baxter
Operational Concerns
The ideal length for drive-test files is 30 minutes to an hour
Youd 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, its nice if they are in
small files that can be easily processed and stored
Always make sure you have at least 200 or 300 MB of free hard drive
space before you start a new drive-test collection
Dont 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
youre collecting and transferring big files
Dont retrace large parts of your travel path during a drive-test run
Its 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, post-
processing software may misinterpret calling events
September, 2002 RF200 - 190 RF200 v3.73 (c) 2002 Scott Baxter
Some Manufacturer-Specific Concerns
When using Agilent drive-test equipment, data accumulates very quickly.
A days driving can easily produce a 500 MB data file (data.mdb), or even
larger.
Dont allow file data.mdb to grow too large to manage or copy to other
media and computers. Rename or copy and delete the file when it
reaches a few hundred MB, and do your next collection in a new file.
Without caution, this file can grow so large that it cant be practically
copied to other computers, and so large that it takes many hours just
to open it using post-processing software.
On both Grayson and Agilent drive-test equipment, be sure you arent
configuring the phone to try to dump more data than the data rate of its
serial port (38.4 kbps).
On the Grayson, click Default settings then click Markov boxes if you
wish to see FER data on regular or Markov calls. Also click the
SearcherInfo2 box but only if you are investigating search windows.
On the Agilent, dont create unnecessary measurements that you
wont ordinarily use. But be careful since unlike the Grayson, you cant
open a display window during playback unless that display window
existed during collection.
September, 2002 RF200 - 191 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 192 RF200 v3.73 (c) 2002 Scott Baxter
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.
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 users 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 cant 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 hasnt been widely used since then
September, 2002 RF200 - 193 RF200 v3.73 (c) 2002 Scott Baxter
Dead-Reckoning Systems
Dead-reckoning systems normally use a combination of magnetic
compass and wheel rotation sensors to augment GPS
The manufacturers 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
September, 2002 RF200 - 194 RF200 v3.73 (c) 2002 Scott Baxter
Drive-Tests: Grayson
Graysons Drive-Test Tools
Graysons Drive-Test Tools
September, 2002 RF200 - 195 RF200 v3.73 (c) 2002 Scott Baxter
September, 2002 RF200 - 196 RF200 v3.73 (c) 2002 Scott Baxter
The Grayson Strip Recorder: Settings
You can configure the
strip recorder to
display whatever
parameters you want,
at whatever scales
you want.
The settings below are
popular for
troubleshooting.
Disable Legend Display
Disable Grid Display
Reverse Window
Background Color
Disable Relative Scales
x
x
x
Display Configuration
1 RX Power -110 -20
2 TX Gain Adjust -30 +30
3 Est. TX Power -63 +30
4 FER Instantaneous 0 15%
5 Number of Active 0 6
Suggested Graph Settings for Regular Use
6 Composite Ec/Io -31 0
September, 2002 RF200 - 197 RF200 v3.73 (c) 2002 Scott Baxter
Grayson Scanner Windows
September, 2002 RF200 - 198 RF200 v3.73 (c) 2002 Scott Baxter
Grayson Scanner Windows
September, 2002 RF200 - 199 RF200 v3.73 (c) 2002 Scott Baxter
Graysons Scanner
September, 2002 RF200 - 200 RF200 v3.73 (c) 2002 Scott Baxter
Drive-Tests: Agilent
Viper PN Scanner
Cobra Handset System
Viper PN Scanner
Cobra Handset System
September, 2002 RF200 - 201 RF200 v3.73 (c) 2002 Scott Baxter
Handset and
Scanner Data
September, 2002 RF200 - 202 RF200 v3.73 (c) 2002 Scott Baxter
BOAT TESTING
Base-Station Over-Air Testing
September, 2002 RF200 - 203 RF200 v3.73 (c) 2002 Scott Baxter
Drive-Tests: Qualcomm
Qualcomm Retriever PN Scanner
Qualcomm Retriever PN Scanner
September, 2002 RF200 - 204 RF200 v3.73 (c) 2002 Scott Baxter
Qualcomm Retriever PN Scanner
FEATURES
Scans all 512 pilots in less than 2.0
seconds
View specific engineering parameters
in either the idle mode or call-state
mode
User-configurable scanner parameters
Windows size, Increment through PN
space, Integration time, Scan pattern,
User-defined pilot list, Detection
thresholds, Pilot logging format
Overriding OTA hand-off parameters
Can add pilots to the "Search Neighbor
Set" that are not in the "Neighbor List"
Configure link speed from 38.4k to
115.2k
September, 2002 RF200 - 205 RF200 v3.73 (c) 2002 Scott Baxter
Drive-Tests: LCC
The RSAT Drive-Test Tool
The RSAT Drive-Test Tool
September, 2002 RF200 - 206 RF200 v3.73 (c) 2002 Scott Baxter
LCCs Collection Tool
LCC
LCCs RSAT tool was once
very widely used and is still
found in some markets
September, 2002 RF200 - 207 RF200 v3.73 (c) 2002 Scott Baxter
RSAT 2000 Main Menu
September, 2002 RF200 - 208 RF200 v3.73 (c) 2002 Scott Baxter
RSAT 2000 Screens
September, 2002 RF200 - 209 RF200 v3.73 (c) 2002 Scott Baxter
Live Class Demonstration & Discussion
Software Operating Features
Tour of the Main Menu and Available Windows
Practical Precautions from current field experience
number of simultaneous open windows
phone serial data rate and throughput considerations
Collecting an Actual Drive Survey (group project)
Choosing What to Log
Starting and Ending the Run
Replaying a Drive Test file
Log File Converter Operation (to export for post-processing)
Format Converter Operation (from earlier versions)
Generating Maps with MapManager
Orientation for Post-Processing Tools and Objectives
Common Pitfalls and Problems
September, 2002 RF200 - 210 RF200 v3.73 (c) 2002 Scott Baxter
Maintenance Features of
CDMA Handsets
Maintenance Features of
CDMA Handsets
Drive-Tests: Phones
September, 2002 RF200 - 211 RF200 v3.73 (c) 2002 Scott Baxter
Handsets as Tools: Simple but always Available!
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
September, 2002 RF200 - 212 RF200 v3.73 (c) 2002 Scott Baxter
Older Qualcomm/Sony Maintenance Displays
MAIN MENU +
1:Volume
2:Call Info
3:Security
D
FEATURES 4+
1:AutoAnswer
2:AutoRetry
3:Scratch
D
Menu
4
0
ENTER FIELD
SERVICE CODE
******
D
DEBUG 0+
1:Screen
2:Test Calls
3:CDMA Only
D
DEBUG 0+
4:Errors
5:Clr Errors
6:13K Voice
D
318 2 9D
X A 7F
D
1
0 0 0 0 0 0
See following
legend for
maintenance
display values
(* or correct code, if different)
Press This: See This: continue: See This:
*
*
September, 2002 RF200 - 213 RF200 v3.73 (c) 2002 Scott Baxter
Qualcomm & Sony Phones with Jog Dials
Enter 111111
Press dial in for OPTIONS
Dial to FIELD DEBUG, press
enter Field Debug Security Code
press Screen
September, 2002 RF200 - 214 RF200 v3.73 (c) 2002 Scott Baxter
Interpreting the QCP Maintenance Display
318 2 94
X A 7F
D
PN Offset
0 - Pilot Channel Acquisition Substate
1 - Sync Channel Acquisition Substate
2 - MS Idle State
3 - System Access State
4 - Traffic Channel State
Receive State
Receive Power
Unsupported
A = active pilots
X = exit reason
Transmit Adjust
80 -109
80 -109
00 0
0A -5
14 -10
1E -15
28 -20
FF
F5
E6
D7
C8
B9
AA
9B
8C
80
-67
-70
-75
-80
-85
-90
-95
-100
-105
-109
QCP-
1900
QCP-
800
-64
-67
-72
-77
-82
-87
-92
-97
-102
-106
Receive Power Conversion:
RX
dbm
=XX
DEC
/ 3 - 63.25 (800 MHz)
RX
dbm
=XX
DEC
/ 3 - 66.25 (1900 MHz)
(if XX>7F, use XX = XX
DEC
-256)
Transmit Gain Adjust Conversion:
TXADJ
db
=XX
DEC
/ 2
Transmit Power Output Conversion:
TX
dbm
= -73 -RX
DBM
- TXADJ
db
(800 MHz)
TX
dbm
= -76 -RX
DBM
- TXADJ
db
(1900 MHz)
September, 2002 RF200 - 215 RF200 v3.73 (c) 2002 Scott Baxter
Kyocera 2035 Maintenance Mode
Steps to enter maintenance
mode:
111111
Enter
Options: Debug
Enter
Enter Field Debug Code
000000
Field Debug
Debug Screen
Enter
Basic
Enter
September, 2002 RF200 - 216 RF200 v3.73 (c) 2002 Scott Baxter
Kyocera 6035 Maintenance Mode
111111
Jog > Options
Jog > Debug
Open flip to continue
Enter Code
0 0 0 0 0 0
OK
SCREEN
September, 2002 RF200 - 217 RF200 v3.73 (c) 2002 Scott Baxter
Early Samsung Maintenance Display
8
0
1
0 0 0 0 0 0
See following
legend for
maintenance
display values
(* or correct code, if different)
Press This: See This: continue: See This:
*
*
Menu Main Menu +
1:Call Logs
2:Phone Book
SVC
Setup +
1:Auto Retry
2:Anykey Ans
SVC
Service Code
??????
SVC
Debug Menu +
1:Screen
2:Test Calls
SVC
Debug Menu +
3:Errors
4:Erase Error
SVC
S04379 SI0 1
T-63 D105-06
P016 CH0600
SVC
September, 2002 RF200 - 218 RF200 v3.73 (c) 2002 Scott Baxter
Samsung SCH-3500 Maintenance Display
Here are the steps to enter
maintenance mode:
MENU
SETUP
0 (undocumented trap door)
000000 (operators code)
Screen
September, 2002 RF200 - 219 RF200 v3.73 (c) 2002 Scott Baxter
Interpreting Samsung Maintenance Display:
Acquisition, Idle, and Access States
Transmit Power Output Calculation:
TX
dbm
= -73 -RX
DBM
- TXADJ
db
(800 MHz)
TX
dbm
= -76 -RX
DBM
- TXADJ
db
(1900 MHz)
S04379 SI0 1
T-63 D085-06
P016 CH0600
svc
PN Offset
0 - Pilot Channel Acquisition Substate
1 - Sync Channel Acquisition Substate
2 - MS Idle State
3 - System Access State
4 - Traffic Channel State
5,6,7 - various call service options
Processing State
Receive
Power,
dbm
Transmit
Gain Adjust,
db
Display toggles between:
System Identifier (SID)
Network Identifier (NID)
Frequency
(channel #)
Ec/Io, db
(primary PN only)
Slot Cycle Index
September, 2002 RF200 - 220 RF200 v3.73 (c) 2002 Scott Baxter
Interpreting Samsung Maintenance Display:
Traffic Channel State
Transmit Power Output Calculation:
TX
dbm
= -73 -RX
DBM
- TXADJ
db
(800 MHz)
TX
dbm
= -76 -RX
DBM
- TXADJ
db
(1900 MHz)
TV1 RV8 08 7
T-63 D085-06
P016 CH0600
svc
PN Offset
0 - Pilot Channel Acquisition Substate
1 - Sync Channel Acquisition Substate
2 - MS Idle State
3 - System Access State
4 - Traffic Channel State
5,6,7 - various call service options
Processing State
Receive
Power,
dbm
Transmit
Gain Adjust,
db
Transmit
Vocoder Rate
1 = 1/8
2 = 1/4
4 = 1/2
8 = Full
Frequency
(channel #)
Walsh
code
assigned
Receive
Vocoder
Rate
Ec/Io, db
(primary PN only)
September, 2002 RF200 - 221 RF200 v3.73 (c) 2002 Scott Baxter
Entering Denso Debug Mode
Enter ##DEBUG (##33284)
Scroll down to SAVE
Press OK
Highlight SERVICE SCREEN
Press OK
If you want to make a test call,
dial the digits and press OK
while in idle mode
CBV: 3957
ABU: 3954 ABT: 031
ARF: 0000 CCL: 01
SID: 04157
NID: 00001
CH: 0100 RSSI: 093
DPN: 084 TX:-46
BFRM:0000000968
TFRM:0000135712
FER:% 000.71
LT: 036:06:36
LG: -086:45:36
EC: -16 -63 -63
PN: 084 084 084
FNGLK: Y Y N
WLSH: 01 01 01
ACT: 084 484 096
-01 -01 200
CND: 220 332 200
200 332 NGH: 076
080 340 068 196
O56 320 220 316
344 488 196 200
392 124 128 084
224 008 084
D
September, 2002 RF200 - 222 RF200 v3.73 (c) 2002 Scott Baxter
Denso Maintenance Display
CBV: 3957
ABV: 3954 ABT: 031
ARF: 0000 CCL: 01
SID: 04157
NID: 00001
CH: 0100 RSSI: 093
DPN: 084 TX:-46
BFRM:0000000968
TFRM:0000135712
FER:% 000.71
LT: 036:06:36
LG: -086:45:36
EC: -16 -63 -63
PN: 084 084 084
FNGLK: Y Y N
WLSH: 01 01 01
ACT: 084 484 096
-01 -01 200
CND: 220 332 200
200 332 NGH: 076
080 340 068 196
O56 320 220 316
344 488 196 200
392 124 128 084
224 008 084
D
Charging Battery Voltage
Average Battery Voltage Average Battery Temperature
System ID
Network ID
RF Channel Frequency
Digital PN Offset
Received Signal Strength
Estimated Transmitter
Power Output
Number of Bad Frames
Number of Good Frames
Frame Erasure Rate, Percent
Base Station coordinates
Current status of Rake Fingers
Active Pilot Set
Candidate Pilot Set
Neighbor Pilot Set
September, 2002 RF200 - 223 RF200 v3.73 (c) 2002 Scott Baxter
Early Sanyo Dual-Band Phones
press menu 7, 0
enter in DEBUGM (332846)
screens are similar to QCP phones
7
0
4 8 2 3 3 6
Press This:
Menu
318 2 94
X A 7F
D
September, 2002 RF200 - 224 RF200 v3.73 (c) 2002 Scott Baxter
Sanyo SPC-4500 Maintenance Display
Choose the following:
DISPLAY
OK
0
OK
Enter Code: 0 0 0 0 0 0
Debug Menu
SCREEN
OK
September, 2002 RF200 - 225 RF200 v3.73 (c) 2002 Scott Baxter
Entering Maintenance Mode: Motorola
Contact your service provider to obtain your phones Master
Subscriber entity Lock (MSL). Then enter the following:
FCN 000000 000000 0 RCL You'll be prompted for your
MSL, enter it and press STO.
New prompts will appear, Press STO in response to
each prompt until no more appear. Dont delay -
continue quickly and enter:
FCN 0 0 * * T E S T M O D E STO
The display will briefly show US then just '.
Press 55#.
Step 1 will appear with its current setting displayed.
Press * to accept and move on to the next step. Repeat
for steps 2-8.
Step 9 (Option byte 2) is the only step requiring manual
changes. Enter 1 0 0 0 0 0 0 0 (The leftmost bit now set to
'1' is what enables test mode.)
Now press STO to accept the entry and exit back to the '
prompt.
Power off and back on.
You should now be in test mode!
September, 2002 RF200 - 226 RF200 v3.73 (c) 2002 Scott Baxter
Motorola Maintenance Display
3 7 2 0 6 5 3 1 2 4 5 0
1 6 8 1 8 5 1 C O N B R
0 8 2 - 0 4 0 0 1 2 7 0 1
8 E V 4 1 8 3 0 0 3 1 2 6
CP CP Exit
RST CP Restart
RTC Restricted
PLT Pilot Acquire
SYN Synch Acquire
TIM Timing
BKS Background Search
IDL Idle
OVD Overhead
PAG Paging
ORG Call Origination
SMS SMS
ORD Order Response
REG Registration
TCI Traffic Channel Init
WFO Waiting for Order
WFA Waiting for Answer
CON Conversation
REL Release
NON No State
Call Processing State
NI No Indication
MR Mobile Release
BR Base Release
Last Call Indicator
TC Traffic Channel Lost
L2 Layer 2 Ack Fail
NC No Channel Asn Msg
N5 N5M failure
BS BS Ack Failure
WO L3 WFO State Timeout
MP Max Probe Failure
PC Paging Channel Loss
RR Reorder or Rel on PCH
?? Unknown Condition
Current SID
Current NID
Call Counter
Strongest Active
PN Ec/Io
# Active
# Cand.
Strongest Neighbor
Current RSSI Dropped Call Counter
# Neighbors Current RF Channel
Current FER Current TX dbm
8V 8K voice
8L 8K Loopback
8EV EVRC
Current Service Option
8S 8K SMS
13L 13K Loopback
13S 13K SMS
8MO 8K Markov Old
DAT Data
8M 8K Markov
13M 13K Markov
N/A Null
13v 13K Voice
September, 2002 RF200 - 227 RF200 v3.73 (c) 2002 Scott Baxter
NeoPoint Phones
Although NeoPoint went out of business in
June, 2001, there are still many NeoPoint
handsets in general use
Press the M (menu) key
Select Preferences (using the up-arrow key)
Enter 040793
Choose Debug Screen [Select]
Now youre in maintenance mode!
September, 2002 RF200 - 228 RF200 v3.73 (c) 2002 Scott Baxter
GoldStar TouchPoint
To enter maintenance mode, just key in:
# # D E B U G SAVE
September, 2002 RF200 - 229 RF200 v3.73 (c) 2002 Scott Baxter
Nokia 6185 Maintenance Display
Enter *3001#12345# MENU
Scroll down to Field test
Press Select
Scroll up to Enabled
Press OK
Power the phone off and on
You should now be in Field test mode
September, 2002 RF200 - 230 RF200 v3.73 (c) 2002 Scott Baxter
Older Nokia Models Maintenance Display
Enter *3001#12345# MENU
Scroll down to Field test
Press Select
Scroll up to Enabled
Press OK
Power the phone off and on
You should now be in Field test mode and the following screens will be
available:
September, 2002 RF200 - 231 RF200 v3.73 (c) 2002 Scott Baxter
Maintenance Display Screens of Nokia Handsets
CSST
XXXXX
RSSI
CCCC
RX
TX
CS State
Idle: PN Offset
TFC: #Actv, FER
RSSI dBm
Paging Channel #
RX power, dbm
TX power, dbm
Screen 1: General
CSST
PGCH
CURSO
FER
CS State
Paging Channel #
Current Service Option
Frame Error Rate
Screen 2: Paging CH Info
Mobile MIN
Mobile Station ESN
Preferred Sys
1=AMPS, 2=CDMA
OwnNumber
ESN
P
A
Operator Selected
(1=A, 2=B, 3=both
Screen 4: NAM Info
Primary Channel A
Secondary Channel A
PPCA
SPCA
Screen 5: NAM Info
Primary Channel B
Secondary Channel B
PPCB
SPCB
Local Use
Access Overload Class
L
A
Current SID
Current NID
SID
NID
Screen 6: BS & Access. Info.
DBUS (Handsfree?) DBUS
BASE_ID (sys par msg)
P_REV (sync msg)
BASE#
P_REV
Screen 7: BS Protocol Rev. Level
MIN_P_REV (sync msg. MIN_P_REV
CS State
Date from System Time
CSST
MMDDYY
Screen 8: Time Information
System Time HHMMSS
The following screens appear in field test mode on Nokia HD881 series of Handsets:
September, 2002 RF200 - 232 RF200 v3.73 (c) 2002 Scott Baxter
Nokia Maintenance Display Screens (continued)
TADD
TDROP
TA
TD
Screen 9: Acquisition Information
TCOMP TC
TTDROP TT
Active Window WW1
Neighbor Window WW2
Remaining Window WW3
Pilot PN Offset
Ec/Io in 1/2 db units
PPN
EC
Screen 10: Active Set (#1-3)
Keep? 1 K
Pilot PN Offset
Ec/Io in 1/2 db units
PPN
EC
Keep? 1 K
Pilot PN Offset
Ec/Io in 1/2 db units
PPN
EC
Keep? 1 K
Pilot PN Offset
Ec/Io in 1/2 db units
PPN
EC
Screen 11: Active Set (#4-6)
Keep? 1 K
Pilot PN Offset
Ec/Io in 1/2 db units
PPN
EC
Keep? 1 K
Pilot PN Offset
Ec/Io in 1/2 db units
PPN
EC
Keep? 1 K
September, 2002 RF200 - 233 RF200 v3.73 (c) 2002 Scott Baxter
Nokia Maintenance Display Screens (continued)
NBR 1 PN Offset
Ec/Io in 1/2 db units
PPN
EC
Screen 12: Neighbor Set (#1-5)
NBR 2 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 3 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 4 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 5 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 6 PN Offset
Ec/Io in 1/2 db units
PPN
EC
Screen 13: Neighbor Set (#6-10)
NBR 7 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 8 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 9 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 10 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 11 PN Offset
Ec/Io in 1/2 db units
PPN
EC
Screen 14: Neighbor Set (#11-15)
NBR 12 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 13 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 14 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 15 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 16 PN Offset
Ec/Io in 1/2 db units
PPN
EC
Screen 15: Neighbor Set (#16-20)
NBR 17 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 18 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 19 PN Offset
Ec/Io in 1/2 db units
PPN
EC
NBR 20 PN Offset
Ec/Io in 1/2 db units
PPN
EC
September, 2002 RF200 - 234 RF200 v3.73 (c) 2002 Scott Baxter
Nokia Maintenance Display Screens (continued)
CAND 1 PN Offset
Ec/Io in 1/2 db units
PPN
EC
Screen 16: Candidate Set (#1-5)
CAND 2 PN Offset
Ec/Io in 1/2 db units
PPN
EC
CAND 3 PN Offset
Ec/Io in 1/2 db units
PPN
EC
CAND 4 PN Offset
Ec/Io in 1/2 db units
PPN
EC
CAND 5 PN Offset
Ec/Io in 1/2 db units
PPN
EC
Task Name
Worst-Cs Stack Free Sp
TASKN
FREE
Screen 17-22: Task Stack Ck Info
Overflow ind. by shift
2=sys stack overflow
Task Stack
Sys Stack
Screen 23: Stack Status Info.
Screen 24: Codec Registers
September, 2002 RF200 - 235 RF200 v3.73 (c) 2002 Scott Baxter
Appendix: Grayson Details
Graysons Drive-Test Tools
Graysons Drive-Test Tools
September, 2002 RF200 - 236 RF200 v3.73 (c) 2002 Scott Baxter
PC Requirements for Inspector
Personal Computer Requirements
Processor: 90 MHz. Pentium or better (133 recommended)
Display: at least VGA (640x480) color, passive
SVGA (800x600) color active is recommended
RAM: at least 16 MB. (32 MB recommended)
Hard Drive - at least 340 MB free (1 GB recommended)
Serial Ports - at least one, using fast 16550 UART
Speaker, integrated mouse (CD drive recommended)
Recommended Accessories:
Mass storage - for archiving collected data:
Iomega Zip (100 MB), Jaz (1GB), Syquest 230 or 1.6 GB,
CD-R or network server
Data Communications: Laplink for Windows 95
Inspector involves bursty streams of serial data and performance can be seriously
impaired if the PC has power control or sleep features enabled. A continuous source
of power must be available at all times logging is taking place and all power
management features of the PC must be deactivated, I.e., put in continuous mode.
September, 2002 RF200 - 237 RF200 v3.73 (c) 2002 Scott Baxter
Inspector Software Installation
Installing and Configuring Inspector on a new PC
Inspector software is installed from diskettes. Refer to the users
manual, section 1.3, for help with the procedure.
The setup process creates all needed configuration files.
The default location for the main program directory is:
c:\Program Files\Grayson Wireless\Inspector32
Drive test data collection files are customarily placed in a
subdirectory called Logfiles
Digital map images for display during collection/playback are
customarily placed in a subdirectory called Mapfiles
You can easily access Logfile and Mapfiles elsewhere
Create an Inspector shortcut on your desktop or taskbar for convenient
access
Disable any laptop power management system
Set your 16550 UART buffer to 1 byte
My Computer > Properties > Ports (COM & LPT) >Communications
Port (usually COM 1) > Properties > Port Settings > Advanced >
Receive Buffer Low (1) > OK
September, 2002 RF200 - 238 RF200 v3.73 (c) 2002 Scott Baxter
Getting Started and Solving Problems
Basic Troubleshooting Techniques
Verify that all peripherals are powered up and initialized
Verify the WMI has power and power-cycle it
Reboot the collector PC last
complete boot from cold powerdown, not WIN95 restart
if GPS consistently fails to lock, check GPS data rates and
configuration; be sure GPS (if external) has clean power
At powerup, the screen at right
will display briefly showing
the status of each phone
and decoder board
presently configured.
Disregard messages about
unequipped hardware. In
playback, you dont need
any hardware connected
and may completely ignore
this message.
September, 2002 RF200 - 239 RF200 v3.73 (c) 2002 Scott Baxter
Appendix: Grayson
Maps for Inspector and Analyzer
Maps for Inspector and Analyzer
September, 2002 RF200 - 240 RF200 v3.73 (c) 2002 Scott Baxter
Map Backgrounds for Inspector32
Inspector can display street maps in the background during data collection
and data playback
Your position is shown by dots whose color can represent values of
any parameter you choose (FER, RX level, etc.)
The Pepperwhite CD contains street maps in vector form for the entire
United States
The MAPMAN program reads the Pepperwhite CD and creates bitmap
(*.bmp) streetmap images of your system coverage area at any desired
scale
you can choose the features you want to display, and their colors,
formats, label sizes, background colors, etc.
you can create as many maps as necessary to cover your entire area
of interest. The appropriate map will be selected automatically by
Inspector for display
After creating the maps you want, you wont need MAPMAN or the
Pepperwhite CD.
Store them in a safe place in case you ever want to generate maps for
a different area or at a different scale.
Maps created by others also can be easily copied to your PC, eliminating
the need to do any of the following steps.
September, 2002 RF200 - 241 RF200 v3.73 (c) 2002 Scott Baxter
Installing MAPMAN on your PC
MAPMAN version 1.3 comes on a series of floppy disks.
Insert disk 1 and choose START RUN a:\setup.exe
Follow instructions and answer all the prompts until installation is
complete. We recommend you use the suggested default
directory for the program.
This process is needed
ONE TIME ONLY
September, 2002 RF200 - 242 RF200 v3.73 (c) 2002 Scott Baxter
Getting Around in MAPMAN: The Basics
Make sure the Pepperwhite CD is installed in your CD drive
Start the MAPMAN program.
START > PROGRAMS > MAPMAN > mapman
Select MAP > CDMA SIZE. The map window will expand to fill the entire
screen.
You should see a map of the United States including Alaska and
Hawaii. If not, see Troubleshooting and PWSTREET.INI on a
following page.
Using the mouse and the left mouse button, drag to create a rectangle
covering your systems approximate location
You should see county outlines and possibly some major city names.
If not, see Troubleshooting...
The map will re-center itself anywhere you left-click the mouse.
You may drag another rectangle, or use the IN and OUT buttons, to
position and scale the map as you wish
The 4mi button forces a display scale about 4 miles wide
You should see streets and detailed features. If not, see
Troubleshooting..
September, 2002 RF200 - 243 RF200 v3.73 (c) 2002 Scott Baxter
Choosing the best Map Scale for your area
You should choose an appropriate scale for the maps you create
The default is 4 miles, which is appropriate for dense areas like
Manhattan, downtown Chicago, etc.
8 miles is more appropriate for most metropolitan suburbs and
medium-sized cities
16 or even larger scales may be more appropriate for rural
systems
If you choose a scale too small, the number of required maps
will be large and many megabytes of disk space will be needed
If you choose a scale too large, map details will be too sparse
Use the IN, OUT, and 4mi buttons to select the scale which looks
best to you
September, 2002 RF200 - 244 RF200 v3.73 (c) 2002 Scott Baxter
Configuring Appearance of Map Features
You can choose the types of features you want to display on the maps,
along with their colors, line widths, label sizes, etc.
With the cursor somewhere on the map, right-click the mouse. Select
Configure Map.
the Customize Map Appearance window will appear
Feature type descriptions will appear in the scrolling window
Select a type of feature you wish to configure.
If the Draw/Outline button has black letters, you can click it to select
when and how that type of feature will be displayed
If the Label button has black letters, you can click it to select when
and how name labels for that feature will be displayed
If the Fill button has black letters, you can click it to select when that
feature will be filled, and what fill color to use
Continue to configure each feature as you wish, experimenting and
looking at the map to evaluate the effects of your changes.
When the map is just the way you like it, click OK.
Save your configuration for future use: FILE > SAVE CONFIG
This process is needed
ONE TIME ONLY
September, 2002 RF200 - 245 RF200 v3.73 (c) 2002 Scott Baxter
Creating a Series of Bitmaps with MAPMAN
Now that youve got the map scale and appearance the way you want it,
youre ready to create and save a series of bitmaps.
Center the map as you want it: Left click with the cursor at the spot youd
like to be centered on your first map.
Capture the map image: Click the Add Map button. The Save Map Image
File window will appear and you can choose the file name to use, and the
directory in which the map will be saved.
Name the map and save it: The last three digits of the file name will be
automatically incremented as you build additional maps. Edit the first
letters of the map file name to whatever you wish to identify this series of
maps, then click OK. The map will be saved and a red outline will appear
around it to show it has been saved.
Reposition, Capture, and Save the next map: Click the toolbar buttons for
Up, Down, Left, or Right. Click the Add Map button, and accept the
incremented default name.
Repeat this process until youve built all the maps you need.
Last, but not least, choose DIR > SAVE and give a name for the directory
file which will become the index to this series of maps. Click OK to save.
September, 2002 RF200 - 246 RF200 v3.73 (c) 2002 Scott Baxter
Suggestions, Tips and Tricks for
Creating Series of Bitmaps
One easy way to create a
series of bitmaps is to start
near the middle of your
coverage area and build maps
in a spiral fashion working
clockwise around the first map
as shown in the figure at left.
The size of the map files is
influenced by the video display
resolution and color depth of
your PC. You can substantially
reduce the sizes of the files you
create by first setting your
display to 16-color or 256-color
mode. Choose: Start >
Settings > Control Panel >
Display > Settings > Color
Palette.
6
1
2 3
4
5 7
8
9
10
As you move the cursor around the
map display, notice that the
names of the maps youre
touching are displayed live in the
little embossed window on the
toolbar.
You can manually edit or make
notes on the bitmap files using
any paint program.
September, 2002 RF200 - 247 RF200 v3.73 (c) 2002 Scott Baxter
Optional: Using MAPXFER to copy
Regional data from the CD to your hard drive
If desired, you can also use the MAPXFER program to transfer
very compact regional files from the Pepperwhite CD to your hard
drive, allowing you to generate other maps in the future using
MAPMAN but without requiring the CD to be available.
Insert the Pepperwhite CD in your PCs CD drive.
Choosing Start > Programs > Mapman > Mapxfer.
Select the CD drive from the pulldown menu.
In the Map File Extractor window, click on the tile you wish to copy
to the hard drive. The Save As window will appear.
Choose the directory location where you wish to save the file, and
click OK. Wait while the file is copied.
Continue with additional tiles if you wish.
When youve copied all the tiles you wish, choose File > Exit.
Thats it! Now you can run MAPMAN without the Pepperwhite CD
whenever you want to build more bitmap files anywhere in the area
youve just saved.
September, 2002 RF200 - 248 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting and checking PWSTREET.INI
If you cannot see map details, check the following points:
To see street details in MAPMAN, the Pepperwhite CD must be in
the CD drive chosen during program installation, or you must have
already saved the tiles for your area to your hard drive using
MAPXFER.
Configuration data for the MAPMAN program is saved during
installation in a file PWSTREET.INI in your WINDOWS directory
To edit the file, double-click on it in the Windows Explorer
Make any needed changes as shown in the window below
Save the modified file. Choose FILE > SAVE. Restart MAPMAN.
TYPICAL CONTENTS OF THE PWSTREET.INI FILE
[pwstvbx]
CellsOnDisk=1 (0 for CD, 1 for your hard drive)
CellData=d:\ (location of the CD, or of files on disk)
BasePath=c:\Programf\Graysonw\MapMan13\
September, 2002 RF200 - 249 RF200 v3.73 (c) 2002 Scott Baxter
Map Index Files: *.dir and map_tile.txt
Inspector32 uses the *.dir file automatically created by MAPMAN
to automatically access the right map during collection or playback.
Analyzer uses map_tile.txt files which can be created from the
corresponding *.dir file in either of two ways:
Use Scott Baxters automatic utility, DIR2TILE.EXE
Edit manually using your favorite text editor (Word, Excel, etc.):
MISSO001.BMP| 46.905568 |-114.068448 | 46.859136 |-113.952800 |
MISSO002.BMP| 46.947296 |-114.068487 | 46.900928 |-113.952800 |
MISSO003.BMP| 46.947264 |-113.964384 | 46.900928 |-113.848704 |
MISSO004.BMP| 46.905568 |-113.964384 | 46.859168 |-113.848736 |
MISSO005.BMP| 46.863808 |-113.964416 | 46.817376 |-113.848736 |
MISSO006.BMP| 46.863808 |-114.068544 | 46.817344 |-113.952864 |
Map File Name Series Left Edge X Bottom Edge Y Right Edge X Top Edge Y Coord System Description
MISSO001.BMP -114.068448 46.859136 -113.952800 46.905568 World Geodetic System 1984 (GPS)
MISSO002.BMP -114.068480 46.900928 -113.952800 46.947296 World Geodetic System 1984 (GPS)
MISSO003.BMP -113.964384 46.900928 -113.848704 46.947264 World Geodetic System 1984 (GPS)
MISSO004.BMP -113.964384 46.859168 -113.848736 46.905568 World Geodetic System 1984 (GPS)
MISSO005.BMP -113.964416 46.817376 -113.848736 46.863808 World Geodetic System 1984 (GPS)
MISSO006.BMP -114.068544 46.817344 -113.952864 46.863808 World Geodetic System 1984 (GPS)
*.dir File
Map_tile.txt File
The *.dir file is automatically
created by MAPMAN. Its fields
are delimited by the pipe
symbol, |.
The Map_tile.txt file can be manually
created. Its fields are tab-delimited.
September, 2002 RF200 - 250 RF200 v3.73 (c) 2002 Scott Baxter
Displaying Sites: the Cellrefs.txt file
Cells are contained in a text datafile called Cellrefs.txt
Inspector32 displays cell labels derived from Cellrefs.txt
Analyzer currently supports automatic display of cell locations and
other advanced cell cross-reference features.
Cellrefs.txt may be built or edited in any of three ways:
manually in Excel or a word processor
using the convenient editor BTSedit.exe included on your
demonstration disk
using an Analyzer add-in provided in version 2.02 and later
Technology Site Name Site ID Lat Long Sector ID Azimuth Beamwidth EIRP PN MCC SID NID BID
CDMA MSSLMT 1 46.955694 -114.128583 1 115 60 50 4 4 29002 59802 0
CDMA MSSLMT 1 46.955694 -114.128583 2 230 60 50 8 0 29002 59802 0
CDMA MSSLMT 1 46.955694 -114.128583 3 355 60 50 12 0 29002 59802 0
CDMA MSSLMT 3 46.868000 -114.023778 1 20 60 50 28 0 29002 59802 0
CDMA MSSLMT 3 46.868000 -114.023778 2 120 60 50 32 2 29002 59802 0
CDMA MSSLMT 3 46.868000 -114.023778 3 240 60 50 36 2 29002 59802 0
Data fields are tab-delimited. Cellrefs.txt file
September, 2002 RF200 - 251 RF200 v3.73 (c) 2002 Scott Baxter
Building Cellrefs.txt files from DriveTest Data
In many CDMA systems, base stations transmit their coordinates
in the System Parameters message on the paging channel
The SITEPARS.EXE utility by Scott Baxter can automatically
produce a Cellrefs.txt file directly from Grayson drive test files,
using the following procedure:
Complete an idle mode drive-test looping through the coverage
areas of each sector you wish to include in the database
Use Inspector32 Tools>Log File Converter to export an ascii
text file of the drive test (a file with the *.asc extension)
Load the file into MS Word or another text editor, and save it as
text with line breaks
Use SITEPARS.EXE to process the file with line breaks into a
cellrefs.txt file
September, 2002 RF200 - 252 RF200 v3.73 (c) 2002 Scott Baxter
Multi-Carrier Operation
Intersystem Soft & Hard Handoff
Multi-Carrier Operation
Intersystem Soft & Hard Handoff
RF200 Section IV
September, 2002 RF200 - 253 RF200 v3.73 (c) 2002 Scott Baxter
Its A
Multi-Carrier/Multi-System/Multi-Manufacturer
World!
Systems are forced to use multiple carriers to achieve needed traffic
capacity
Its 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 traffic among carriers
IS-41 - provides intersystem handoffs and call delivery
Proprietary algorithms can distribute traffic among carriers
RF tricks and network proprietary algorithms can support inter-carrier
handoff
Multi-Carrier Operation is a complex sport - a quadrathlon or pentathlon!
September, 2002 RF200 - 254 RF200 v3.73 (c) 2002 Scott Baxter
On My Current Sector
The View Within One Network:
Multi-Carrier Configurations
The View Within One Network:
Multi-Carrier Configurations
September, 2002 RF200 - 255 RF200 v3.73 (c) 2002 Scott Baxter
Many Network/Carrier Configurations are Possible!
f1
f2
f3
f4
Basic Multi-Carrier
Operation
IS-95
IS-95
IS-95
IS-95
f1
f2
f3
f4
Non-originating carriers
can carry more traffic!
IS-95
IS-95
IS-95
IS-95
f1
f2
f3
f4
Some Carriers may
support 1xRTT
1xRTT
IS-95
IS-95
IS-95
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
W
0



P
i
l
o
t
w
3
2
S
y
n
c
w
1
P
a
g
i
n
g
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a

D
a
t
a
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
w
1
P
a
g
i
n
g
September, 2002 RF200 - 256 RF200 v3.73 (c) 2002 Scott Baxter
Within My Systems
The Adjoining Network View:
Different Common Configurations
The Adjoining Network View:
Different Common Configurations
September, 2002 RF200 - 257 RF200 v3.73 (c) 2002 Scott Baxter
The Big Picture:
CDMA Multicarrier System Overlaying Analog System
Important Questions:
How do idle dual-mode mobiles choose a system?
When do they select analog operation?
How do idle CDMA mobiles change carrier frequencies?
How do CDMA mobiles in a call handoff to other carrier
frequencies?
Can CDMA mobiles in a call hand down to analog operation?
When can a dual mode mobile return from analog to CDMA?
CDMA F2
CDMA F3
CDMA F1
Analog System
September, 2002 RF200 - 258 RF200 v3.73 (c) 2002 Scott Baxter
Adjoining CDMA Networks of Different Manufacturers
At present, only Hard Handoffs work between different manufacturers
Important Questions:
What happens if bordering cells are on the same frequency?
Advantages and drawbacks
What happens if bordering cells are on different frequencies?
Advantages and drawbacks
F2
F3
F1
F2
Brand X System Brand Y System
PSTN
Ordinary Interswitch Trunks
(cant transmit packets, so soft handoff impossible)
September, 2002 RF200 - 259 RF200 v3.73 (c) 2002 Scott Baxter
Adjoining CDMA Networks of the Same Manufacturer
At present, most manufacturers support intersystem soft handoff
Important Questions:
What happens if bordering cells are on the same frequency?
Advantages and drawbacks
What happens if bordering cells are on different frequencies?
Advantages and drawbacks
F2
F3
F1 F1
Brand X System Brand X System
PSTN
ATM links
between CDMA packet networks
(soft handoffs are desired)
F4
September, 2002 RF200 - 260 RF200 v3.73 (c) 2002 Scott Baxter
The Mobile View:
When Do I Change Frequencies?
The Mobile View:
When Do I Change Frequencies?
My Mobile
September, 2002 RF200 - 261 RF200 v3.73 (c) 2002 Scott Baxter
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
f5
f4
f3
f2
f1
System
Acquisition
Idle Mode
Reselection
Call Start:
Ch. Assignment
In Call:
Hard Handoff
MRU
SDA
PRL-AI
Hashing
GSRM
Multi-
Freq
Nbrs
Proprietary
Network
Algorithms
Nortel: MCTA
Lucent methods
Motorola methods
Auxiliary
Handoff Triggers
Beacons
Ec/Io, RTD
Proprietary
Processes
Remember: Different Mechanisms Apply at Different Stages
September, 2002 RF200 - 262 RF200 v3.73 (c) 2002 Scott Baxter
System Acquisition/Idle Mode ReSelection
Idle mobiles are like
automobile drivers!
There are rules which
they obey, but
They decide where
they want to go without
personal intervention
by the system
The SDA guides mobiles
to choose the appropriate
system
Paging channel messages
can cause idle mode
carrier or system
reselection
f5
f4
f3
f2
f1
System
Acquisition
Idle Mode
Reselection
MRU
SDA
PRL-AI
Hashing
GSRM
Multi-
Freq
Nbrs
Mobiles find the proper system through both standard-defined
acquisition steps and a proprietary System Determination Algorithm
September, 2002 RF200 - 263 RF200 v3.73 (c) 2002 Scott Baxter
Basic Principles:
System Determination in Idle Mode
CDMA Idle Mode
Mobile has control, follows the System Determination Algorithm
Look at most recently used frequency.
Find Strongest Pilot > Read Sync > Read Paging/Config Messages
If system denied or not preferred, check other frequencies in PRL.
If Multiple Frequencies appear in CDMA Channel List Message, Hash and
go to proper frequency
If GSRM transmitted, go wherever directed
Monitor Paging Channel
Analog Idle Mode
Mobile has control, follows procedures of the Standard
Find Strongest CCH
Monitor Paging Channel
Every 3 minutes, rescan for CDMA signal
September, 2002 RF200 - 264 RF200 v3.73 (c) 2002 Scott Baxter
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 mobiles 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)
Go to last
frequency
from MRU
Strongest
PN, read
Sync
Is SID
permitted?
No Signal
Preferred
Only Bit
0
Denied SID
Read
Paging
Channel
CDMA Ch
List Message
Global Svc
Redir Msg
HASH using
IMSI
my ACCOLC?
redirect
Is better
SID
available?
PRL MRU Acq Idx
Yes
No
F1
F2
F3
to Analog
to another CDMA frequency or system
Config
Messages:
remain
Steps from
the CDMA
standards
Steps from
proprietary
SDAs
Proprietary
SDA
databases
Start
Legend
System Determination Algorithm
Last Resort:
GEO escape
Or Analog
Idle Mode Carrier Selection
September, 2002 RF200 - 265 RF200 v3.73 (c) 2002 Scott Baxter
Avoiding Unwanted Acquisition of
Supplemental CDMA Carriers
System acquisition is primarily controlled by the mobile
dual-mode mobiles look for last-used frequency first
Distant mobiles may notice weak Carrier 2 signals beyond the
edge of Carrier 2 coverage, and originate calls likely to drop
system can transmit Global Service Redirection Messages on
all out-looking Carrier 2 sectors to immediately force any
distant mobiles to reacquire Carrier 1
there will be no F2 originations on outermost F2 sectors!
However, still possible to soft-handoff into F2 outer sectors
CDMA Carrier Frequency 2
CDMA Carrier Frequency 1
GSRM GSRM
September, 2002 RF200 - 266 RF200 v3.73 (c) 2002 Scott Baxter
Frequency Change at Initial Channel Assignment
When a new call is about to be assigned to
its first traffic channel - its an ideal time to
change carrier frequencies for intercarrier
traffic distribution purposes
No call yet exists, so no muting occurs
Each network manufacturer is free to
design its own internal algorithms to make
the decision of which carrier should be
used
These algorithms consider the present
loading condition of each carrier
Mobiles simply follow the instructions sent
to them in the Channel Assignment
Message on the paging channel
f5
f4
f3
f2
f1
Call Start:
Ch. Assignment
Proprietary
Network
Algorithms
Nortel: MCTA
Lucent methods
Motorola methods
Call Start is a painless time to change to a different frequency.
Different networks have different proprietary triggers to distribute traffic.
September, 2002 RF200 - 267 RF200 v3.73 (c) 2002 Scott Baxter
System Determination During
Call Setup and Call Continuation
CDMA Conversation State
System has control, follows Standard or proprietary procedures
Initial channel assignment: system can select which frequency
(most common trigger would be congestion on present frequency)
Normal handoffs are soft, on same frequency, to mobile-selected pilots
Artificial trigger mechanisms can force mobile handoff to different:
1) CDMA frequency, 2) CDMA system, or 3) analog system
Analog Conversation State
System has control, follows procedures of the Standard
Mobile can be handed off to different analog cell or even different
analog system based on locate receiver measurements
No handoff possible to CDMA from ongoing analog call
September, 2002 RF200 - 268 RF200 v3.73 (c) 2002 Scott Baxter
Interfrequency Hard Handoff
Mobiles in a call are receiving only their
current operating frequency
Theyre unaware of the presence or
absence of signals on different carrier
frequencies, so they dont realize when
they need to do intercarrier handoffs
Networks use a variety of methods to trick
mobiles into appropriate handoffs
Pilot beacons - decoy signals on the
current frequency that lure the mobile
into disclosing needed information
Tier-based triggers
Round trip delay thresholds
Ec/Io and other parameter
thresholds
f5
f4
f3
f2
f1
In Call:
Hard Handoff
Auxiliary
Handoff Triggers
Beacons
Ec/Io, RTD
Proprietary
Processes
Mobiles in conversation cant see pilots on different carrier frequencies.
We must trick these mobiles into handoff by artificial means.
September, 2002 RF200 - 269 RF200 v3.73 (c) 2002 Scott Baxter
Intersystem Hard Handoff
Same Frequency causes Interference Problems!
Consider two adjacent CDMA systems:
Same frequency
If not equipped for intersystem soft handoff, only hard handoff is
possible between them; dragged handoffs become a big problem
Handoff Performance Results:
Mobiles CAN see pilots from adjoining system, so mobile-directed
handoff is possible
However, due to hard handoff mobiles can use only one system or the
other, not both, and simultaneous shared power control is not possible
dragging mobiles cause severe interference in border cells
border area has poor capacity, high access failures and dropped calls
BSC1 SW1
SW2 BSC2
Frequency 1
City 2
City 1
Interference
September, 2002 RF200 - 270 RF200 v3.73 (c) 2002 Scott Baxter
Intersystem Soft Handoff:
Avoids Border Area Interference Problems
Consider two adjacent CDMA systems:
Same frequency
ATM connection between BSCs allows soft handoff
Handoff Performance Results:
Mobiles CAN see pilots from adjoining system, so mobile-directed
handoff is possible
Intersystem soft handoff is possible, so simultaneous power control is
possible for mobiles in border area
Border RF environment is the same as internal RF environment, no
special problems
BSC1 SW1
SW2 BSC2
Frequency 1
City 2
City 1
Intersystem Soft Handoff
ATM link
no problems!
September, 2002 RF200 - 271 RF200 v3.73 (c) 2002 Scott Baxter
Avoid Interference, Use Different Frequencies?
Hard Handoff Logistical Problems
Consider two adjacent CDMA systems:
Suppose intersystem soft handoff is not available
Systems are deliberately on different frequencies. This definitely
avoids interference in the border area, but causes other complications
Conversation-State Handoff Logistical Problems:
Mobiles on one system cant see the pilots of adjoining cells on the
other system! So, the mobiles will never request trans-border handoff
Some method must be employed to force unsuspecting mobiles into
transborder handoffs
Common solutions: 1) implement intersystem soft handoff, 2) Pilot
beacon cells, 3) auxiliary trigger mechanisms (Ec/Io, RTD, etc.)
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
F2 Mobiles
cant see F1 pilots!
F1 Mobiles
cant see F2 pilots!
September, 2002 RF200 - 272 RF200 v3.73 (c) 2002 Scott Baxter
One Solution to the Multi-Frequency Problem
2-Frequency Trigger Method: Beacon Cells
The Beacon Solution
A pilot beacon cell is a mannequin -- a signal which can be seen by
arriving mobiles from the other system on their own frequency,
inducing them to request handoff as soon as it is appropriate
When mobiles request soft handoff with the beacon, the old system
steps in and instructs the mobiles to do intersystem hard handoff to
the real cell which the mobiles are approaching on the other system
Special Logistical Concerns with Beacons
Of course, its possible for mobiles of one system to wake up looking
at the pilot of a beacon cell in the border area, rather than a real cell.
Therefore, a beacon cell must transmit not only its pilot, but also a
sync channel and a paging channel with global service redirection
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
F2 Mobiles
can see F2 beacon
F1 Mobiles
can see F1 beacon
September, 2002 RF200 - 273 RF200 v3.73 (c) 2002 Scott Baxter
Another Solution for Multi-Frequency Handoffs
Bridge Cells, RTD Trigger in Boundary Sectors
All along the intersystem border, a one-cell-thick transition zone is
created. The bridge cells in this zone are equipped with dual equipment,
one set operating on each system.
The outlooking sector of each bridge cell is tagged in the site
database as a boundary sector. Whenever a mobile is served
exclusively by a boundary sector, the system continuously monitors
that mobiles round trip delay (RTD).
When the mobiles RTD passes upward through a datafilled threshold,
the system steps in and orders a hard handoff to the matching sector
of the bridge cell on the other system
this ensures the handoffs happen in clean environments with high
probability of success
disadvantage: more BTS hardware needed than otherwise
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
Boundary Sector
Boundary Sector
September, 2002 RF200 - 274 RF200 v3.73 (c) 2002 Scott Baxter
Another Solution for Multi-Frequency Handoffs
Arbitrary Ec/Io Trigger Mechanisms
Outlooking sectors of border cells are tagged as boundary sectors in the
system database
Whenever a mobile is served exclusively by a boundary sector, the
system frequently interrogates the mobile with pilot measurement
request messages
When the mobiles reports the boundary sectors Ec/Io is below a
preset threshold, the system immediately commands a hard handoff
to a previously defined sector on the other system. Everyone hopes
(prays?) that sector is able to hear the mobile for a successful
handoff.
The Ec/Io trigger threshold is sometimes a fixed value (usually 11
db above the T_Drop in the serving sector, although some
networks later software allows an arbitrary trigger level to be set
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
Boundary Sector
Boundary Sector
September, 2002 RF200 - 275 RF200 v3.73 (c) 2002 Scott Baxter
Section E
CDMA/Analog Overlay Considerations
CDMA/Analog Overlay Considerations
September, 2002 RF200 - 276 RF200 v3.73 (c) 2002 Scott Baxter
CDMA/AMPS Overlays: Idle CDMA Acquisition
System acquisition is primarily controlled by the mobile
dual-mode mobiles look for CDMA first, then AMPS if needed
Distant mobiles may notice weak CDMA signals beyond the edge
of CDMA coverage, and originate calls likely to drop
most systems transmit Global Service Redirection Messages
on all out-looking sectors to immediately force any distant
mobiles to reacquire AMPS system
hence no CDMA originations on outermost CDMA sectors!
However, still possible to soft-handoff into outer sectors
Most operators request handset manufacturers to add feature of
periodic rechecking by idle handsets seeking to acquire CDMA
CDMA Overlay
AMPS Existing System
GSRM GSRM
September, 2002 RF200 - 277 RF200 v3.73 (c) 2002 Scott Baxter
CDMA/AMPS Overlays: Analog Handdown
CDMA mobiles approaching the edge of CDMA coverage must
hand down to AMPS
however, CDMA mobiles cannot see AMPS signals during
CDMA calls, and therefore will not request handoff
Methods for triggering CDMA-to-AMPS Handdown: the same ones
we considered for CDMA-CDMA intersystem handoff
beacon cells
bridge cells with RTD trigger
arbitrary Ec/Io thresholds on boundary sectors
Once a CDMA phone hands down to analog, it cannot be handed
back up during the same call (due to long CDMA acquisition time)
CDMA Overlay
AMPS Existing System
September, 2002 RF200 - 278 RF200 v3.73 (c) 2002 Scott Baxter
Course RF200 Section V.
Applied Optimization
Applied Optimization
September, 2002 RF200 - 279 RF200 v3.73 (c) 2002 Scott Baxter
Starting Optimization on a New System
RF Coverage Control
try to contain each sectors coverage, avoiding gross spillover
into other sectors
tools: PN Plots, Handoff State Plots, Mobile TX plots
Neighbor List Tuning
try to groom each sectors 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.
September, 2002 RF200 - 280 RF200 v3.73 (c) 2002 Scott Baxter
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.
September, 2002 RF200 - 281 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 282 RF200 v3.73 (c) 2002 Scott Baxter
Solving CDMA Performance Problems
CDMA optimization is very different from optimization in analog
technologies such as AMPS
AMPS: a skilled engineer with a handset or simple equipment can
hear, diagnose, and correct many common problems
co-channel, adjacent channel, external interferences
dragged handoffs, frequency plan problems
CDMA impairments have one audible symptom: Dropped Call
voice quality remains excellent with perhaps just a hint of garbling as
the call approaches death in a hostile RF environment
Successful CDMA Optimization requires:
recognition and understanding of common reasons for call failure
capture of RF and digital parameters of the call prior to drop
analysis of call flow, checking messages on both forward and reverse
links to establish what happened, where, and why.
September, 2002 RF200 - 283 RF200 v3.73 (c) 2002 Scott Baxter
Normal Call Processing
Event Templates
Normal Call Processing
Event Templates
September, 2002 RF200 - 284 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Paging
Channel
Registration
BTS
Registration Message (by PROBING)
Base Station Acknowledgment Order
September, 2002 RF200 - 285 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Paging
Channel
Voice Mail Notification
BTS
Mobile Station Ackmt. (by PROBING)
Feature Notification Message
Base Station Acknowledgment Order
September, 2002 RF200 - 286 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Reverse
Traffic
Channel
Paging
Channel
Incoming Call Delivery Scenario
BTS
General Page Message
Page Response Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Traffic Channel Preamble: Frames of 000s
Continuous frames of all 000s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
Forward
Traffic
Channel
September, 2002 RF200 - 287 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Reverse
Traffic
Channel
Paging
Channel
Mobile-Originated Call Scenario
BTS
Origination Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Traffic Channel Preamble: Frames of 000s
Continuous frames of all 000s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
Forward
Traffic
Channel
September, 2002 RF200 - 288 RF200 v3.73 (c) 2002 Scott Baxter
Forward
Traffic
Channel
Reverse
Traffic
Channel
The Handoff Process
BTS
Handoff Completion Message
Extended Handoff Direction Message
Mobile Station Acknowledgment Order
Base Station Acknowledgment Order
The new Handoff condition is now officially Established!
The handset pilot searcher notices energy from
another sector or BTS, meeting any of these criteria:
Neighbor or Remaining Pilot Ec/Io stronger than T_Add
Candidate Pilot just got T_Comp better than an active
An Active Pilot stayed below T_DROP for T_TDROP time
Pilot Strength Measurement Message
Base Station Acknowledgment Order
Selector arranges channel elements/Walsh codes in requested
sectors and begins using them, too.
Handset verifies which assigned PNs it can now hear.
Neighbor List Update Message
Mobile Station Acknowledgment Order
September, 2002 RF200 - 289 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting Access Failures
Troubleshooting Access Failures
September, 2002 RF200 - 290 RF200 v3.73 (c) 2002 Scott Baxter
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.
BTS
Channel Assnmt. Msg.
Origination Msg
Base Sta. Acknlgmt. Order
TFC frames of 000s
TFC preamble of 000s
Base Sta. Acknlgmt. Order
Mobile Sta. Ackngmt. Order
Service Connect Msg.
Svc. Connect Complete Msg
Base Sta. Acknlgmt. Order
Call is Established!
MS
Probing
ACCESS
PAGING
FW TFC
PAGING
RV TFC
FW FC
RV TFC
FW TFC
RV TFC
FW TFC
Successful Access Attempt
September, 2002 RF200 - 291 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 292 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting Access Failures (1)
Paging Channel Access Channel
Steps in the Access Process
BTS
Origination Msg.
Probe #1
Origination Msg.
Probe #2
Origination Msg.
Probe #3
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.
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 cant 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 mobiles
origination or not
Troubleshooting Comments
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.
The mobile keeps probing until NUM_STEP probes
have been sent, then repeats the probe sequence
again until Max_Probe_Sequences have been
sent.
September, 2002 RF200 - 293 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting Access Failures (2)
Paging Channel Access Channel
The Access Process
BTS
Reorder
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
Troubleshooting Comments
Mobile beeps and displays Call Failed - System
Busy
One Dreaded Possibility:
September, 2002 RF200 - 294 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting Access Failures (3)
Paging Channel Access Channel
The Access Process
BTS
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
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.
Troubleshooting Comments
Channel Assignment
Message
Base Station
Acknowledgment
STOP! Leave the Paging Channel, and dont
transmit again on the access channel.
The mobile now goes to try to hear the Forward
Traffic Channel.
September, 2002 RF200 - 295 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting Access Failures (4)
FWD Traffic Channel REV Traffic Channel
The Access Process
BTS
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).
Troubleshooting Comments
Mobile beeps and displays Call Failed
00000000000000000000
00000000000000000000
00000000000000000000
00000000000000000000
00000000000000000000
00000000000000000000
If the mobile hears the required number of good
empty frames, it starts transmitting its own
Reverse Traffic Channel Preamble of empty all-
zero 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.
Base Station
Acknowledgment
Mobile Station
Acknowledgment
If the BTS does NOT hear the mobiles 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).
If the BTS DOES hear the mobiles 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.
September, 2002 RF200 - 296 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting Access Failures (5)
FWD Traffic Channel REV Traffic Channel
The Access Process
BTS
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.
Troubleshooting Comments
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
September, 2002 RF200 - 297 RF200 v3.73 (c) 2002 Scott Baxter
Access Failure/TCCF Troubleshooting
Access Attempt Failed
Were any probes acknowledged?
Yes,
Reorder
Weak Signal/Coverage Hole?
Strong Fwd interf / pollution?
yes
yes
no
Is T-1unstable/blocking?
no
Add coverage
Identify, eliminate
Report/repair
Blocking
Forward Power
Channel Elements
Rev. Link Noise
Optmz Fpwr DGUs
Add chan cards
Identify, fix source
No,
Nothing
Yes,
BS Ack
Paging Channel
faded, lost
Check System Logs.
Was mobile heard?
Was Channel Assignment
Message heard?
no
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
Check System Logs.
Was CH ASN sent?
yes
System Problem.
Investigate why
Software problem
Resource blocking
Did mobile see N5M good
frames on F-TCH?
yes
no
Check System Logs.
CH EL initialized OK?
no
yes
Check System Logs. Did
BTS see mobile preamble? no
yes
Did mobile see BS Ack?
Rev. Link Noise Identify, fix source
no Weak Signal/Coverage Hole?
Strong Fwd interf / pollution?
Is T-1unstable/blocking?
Improve coverage
Identify, eliminate
Report/repair
F-TFC Channel
faded, lost
yes
Check System Logs.
Did BTS see mobile Ack?
OK
no Weak Signal/Coverage Hole?
Strong Rev Noise?
Is T-1unstable/blocking?
Improve coverage
Identify, eliminate
Report/repair
R-TFC Channel
faded, lost
Init TCH DGU large enough? Raise DGU
September, 2002 RF200 - 298 RF200 v3.73 (c) 2002 Scott Baxter
1. If the failures occur in areas where one BTS
is dominant, suspect BTS hardware problems.
2. Plot the access failures to see if they correlate
with areas of BTS overlap. If so, suspect
forward link problems. This is probable
because the mobile does not have the normal
advantage it would get from soft handoff on a
traffic channel. During access, it must
successfully demodulate all five BTS messages
without the benefit of soft handoff. If the
handset is in an area of multiple BTS overlaps
or weak signal, this can be risky. In such cases,
try to make the serving BTS more dominant.
Also check the access/probing parameters.
If the base station never sees the mobiles probes,
the cause is probably coverage-related. If it happens
in strong signal areas, suspect BTS hardware. Also
check datafill for proper NOM_PWR and PWR_INC.
Be sure the BTS datafill access channel acquisition
and demodulation search windows are adequate.
Reducing Access Failures
BTS
Channel Assnmt. Msg.
Origination Msg
Base Sta. Acknlgmt. Order
TFC frames of 000s
TFC preamble of 000s
Base Sta. Acknlgmt. Order
Mobile Sta. Ackngmt. Order
Service Connect Msg.
Svc. Connect Complete Msg
Base Sta. Acknlgmt. Order
Call is Established!
MS
Probing
ACCESS
PAGING
FW TFC
PAGING
RV TFC
FW FC
RV TFC
FW TFC
RV TFC
FW TFC
Access Attempt
September, 2002 RF200 - 299 RF200 v3.73 (c) 2002 Scott Baxter
Troubleshooting Dropped Calls
Troubleshooting Dropped Calls
September, 2002 RF200 - 300 RF200 v3.73 (c) 2002 Scott Baxter
Dropped Call Troubleshooting - Mobile Side
Just arrived on sync channel!
Is this a drop?
Were there release
messages?
OK, normal
end of call
This is a drop!
yes
no
Was the Sync Channel PN
Active before the drop?
Check
for:
yes
Weak Signal/Coverage Hole?
Strong Fwd/Rev interference?
no
Did mobile request Sync CH
PN in PSMM before drop?
Why didnt handoff happen?
no
yes
Weak Signal/Coverage Hole?
FER already too bad?
Border configuration problems
Fast-rising pilot, slow reaction
PN not in neighbor list
Is PN in neighbor list?
yes
Is SRCH_WIN_N adequate?
no
Add PN to Neighbor List!
Blocking
Forward Power
Channel Elements
Rev. Link Noise
yes
Is cell in island Mode?
yes
Repair/Re-initialize Cell!
no
Is T-1unstable/blocking?
Is T-1unstable/blocking?
Is T-1unstable/blocking?
no
Widen SRCH_WIN_N!
More information needed.
Collect system logs and
merge with mobile data,
analyze
Improve coverage
Identify, eliminate
Report/repair
Add PN to Nbr List!
Add coverage
Push earlier
Debug, reconfigure
Incr Sector Overlap
Speed up searcher
Optmz Fpwr DGUs
Add chan cards
Identify, fix source
Report/repair
September, 2002 RF200 - 301 RF200 v3.73 (c) 2002 Scott Baxter
Investigating Dropped Calls
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
Dropped call analysis can consume a
considerable amount of time. Using good post-
processing 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
BAD COVERAGE
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
FWD. INTERFERENCE
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
REV. INTERFERENCE
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 302 RF200 v3.73 (c) 2002 Scott Baxter
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
A
B
1 mi.
7 Chips
BTS
BTS
SITUATION 1
Locked to distant
site, cant see
one nearby
1
2

m
i
l
e
s
8
0

C
h
i
p
s
SRCH_WIN_N = 130
BTS A is reference.
BTS B appears (7-80) chips
early due to its closer distance.
This is outside the 65-chip window.
Mobile cant see BTS Bs pilot, but its
strong signal blinds us and the call drops.
T
ra
v
e
l
m
o
u
n
t
a
i
n
s
A
B
1 mi.
7 Chips
BTS
BTS
SITUATION 2
Locked to nearby
site, cant see
distant one
1
2

m
i
l
e
s
8
0

C
h
i
p
s
T
r
a
v
e
l
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 cant see BTS As pilot.
m
o
u
n
t
a
i
n
s
September, 2002 RF200 - 303 RF200 v3.73 (c) 2002 Scott Baxter
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
One chip is 801 feet or 244.14 m
1 mile=6.6 chips; 1 km.= 4.1 chips
PROPAGATION DELAY
SKEWS APPARENT PN OFFSETS
BTS
BTS
A
B
33
Chips
4
Chips
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.
September, 2002 RF200 - 304 RF200 v3.73 (c) 2002 Scott Baxter
Pilot Search Order, Speed, and Implications
Actives & candidates have the biggest influence.
Keep window size as small as possible
During soft handoff, this set dominates searcher
Minimize excessive Soft HO!
Neighbor set is second-most-important
Keep window size as small as possible
Keep neighbor list as small as possible
But dont miss any important neighbors!
Remaining Set: pay your dues, but get no reward
You must spend time checking them, but the system cant assign one to you
R
e
m
a
i
n
i
n
g
A
c
t
i
v
e
+
C
a
n
d
N
e
i
g
h
b
o
r
PILOT SEARCHING IN NESTED LOOPS:
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.
WINDOW SIZE
IN CHIPS AND DATA UNITS
Window
Size (Chips)
14 (7)
20 (10)
40 (20)
60 (30)
80 (40)
100 (50)
130 (65)
160 (80)
226 (113)
28 ( 14)
320 (160)
452 (226)
Datafill
Value
4
5
7
8
9
10
11
12
13
6
14
15
September, 2002 RF200 - 305 RF200 v3.73 (c) 2002 Scott Baxter
Treating Drops with Poor-Coverage Symptoms
Using a post-processing tool,
display a map of the locations of
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
solution except in rare cases
These drops are probably normal
due to their locations in a
predicted weak-signal area.
Drops with weak-signal symptoms
happened in predicted strong-signal
area. Suspect bad BTS hardware.
September, 2002 RF200 - 306 RF200 v3.73 (c) 2002 Scott Baxter
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)
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
September, 2002 RF200 - 307 RF200 v3.73 (c) 2002 Scott Baxter
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
E
c
/I
o
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.
The system must set up the soft
handoff and notify the mobile.
The mobile must acquire the
new signal by locking a finger
BTS
BTS
x
September, 2002 RF200 - 308 RF200 v3.73 (c) 2002 Scott Baxter
Sources of Delay Causing Slow Handoff
Every step in the handoff process can suffer delay if were not careful
to control conditions:
Mobile search correlator notices new pilot
Window sizes too large, searching is slow
Multi-sector soft handoff already underway, many active pilots,
searching is slow
Interferor not a neighbor, must find in remaining set: slow, DIE!
System cannot currently set up true remaining-set handoffs
Mobile reports PSMM to system.
Reverse link noisy, PSMM must be re-requested & repeated
System sets up handoff, sends EHDM to mobile
Resource congestion: no TCEs, or other problems
Forward link is noisy, mobile doesnt hear EHDM, must repeat
Fortunately, these problems do not have to happen.
September, 2002 RF200 - 309 RF200 v3.73 (c) 2002 Scott Baxter
Auditing System Handoff Setup Time
After the mobile searcher recognizes the
pilot it needs, the job is only begun
The mobile must send a PSMM to
system; it must be received
System must recognize reported PN
phase, set up resources in the
appropriate sector
An EHDM must be sent to the
mobile, received, acknowledged
Mobile must acknowledge again
when handoff implemented
Time required for this process can be
measured by watching messages
most post-processing tools can show
histogram or graph of this delay
if system is healthy, almost all
handoffs will happen in <200 msec.
and there will be no stragglers
0 100 200 300 400 500
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Time (milliseconds)
C
u
m
u
l
a
t
i
v
e

D
i
s
t
r
i
b
u
t
i
o
n

F
u
n
c
t
i
o
n
Typical Handoff
Setup Time
September, 2002 RF200 - 310 RF200 v3.73 (c) 2002 Scott Baxter
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 doesnt 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.
September, 2002 RF200 - 311 RF200 v3.73 (c) 2002 Scott Baxter
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
couldnt 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.
September, 2002 RF200 - 312 RF200 v3.73 (c) 2002 Scott Baxter
A Word About Soft Handoff for
Former AMPS/TDMA Personnel
Former AMPS/TDMA optimizers may feel an instinctive obligation to
minimize handoff activity, with good reason. In AMPS/TDMA, handoffs
involved muting and real risk of a drop. Since the mobile could be served
by just one sector at a time, there was pressure to be sure it was the best
available sector, but also pressure not to do many handoffs. Ping-pong is
unpopular in AMPS/TDMA.
In CDMA, there is no muting or audible effect during soft/softer handoff,
and there is no pressure to use just the right sector -- if several are
roughly as good, use them all, up to 6 at a time.
The noise level on the reverse link actually decreases during soft
handoff - by roughly 4 db. - allowing the system to handle from 1.5 to
2 times as many subscribers as otherwise.
The forward link noise does rise, but not to troublesome levels
There is an additional cost for doing soft handoff: each involved BTS
must dedicate a TCE channel element to the handoff. However, even
if every user is constantly involved in soft handoff, this increases the
cost of a BTS a small percentage.
So, to former AMPS/TDMA folks, dont fear. Use the force, Luke! And
to our GSM friends, Resistance is futile...
September, 2002 RF200 - 313 RF200 v3.73 (c) 2002 Scott Baxter
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 sectors 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.
September, 2002 RF200 - 314 RF200 v3.73 (c) 2002 Scott Baxter
Dangerous Environments
The CDMA handset is designed with a digital rake receiver including
three correlators (fingers) which can demodulate signals from up to three
sectors simultaneously, combining and using the energy from all three to
improve reception. Implications:
If One dominant signal: this is a good situation; the three fingers will
be looking for resolvable multipath components; good diversity
If Two usable signals: good situation; soft handoff & diversity
If Three usable signals: good situation; soft handoff & diversity
If Four roughly equal signals: workable but not ideal. Three best
signals are demodulated; other remains an interferor. 3 vs 1
If Five roughly equal signals: probably workable but not good. Three
best are demodulated; remaining two are interferors. 3 vs 2
If Six roughly equal signals: very frightening. Three best signals are
demodulated; three remaining signals are interferors. 3 vs 3
The system can provide up to 6-way soft handoff, but anything above
three-way is an indication that there is too much RF coverage overlap.
More than three-way soft handoff should be the notable exception rather
than the rule.
September, 2002 RF200 - 315 RF200 v3.73 (c) 2002 Scott Baxter
Identifying Causes of Excessive Soft Handoff
RF Drive Test data (preferred) or Propagation Prediction runs
(second choice) can be used to identify the excessive coverage
overlaps which cause soft handoff.
Suggested Procedure:
Use a post processing tool to display all locations where a
sector has strongest rake finger status, or
Use a propagation prediction tool to show all locations where a
sector is best server
Draw a curve through all the adjacent surrounding sites
If more than 15% of the best-finger or best-server points lie
outside this line, this sectors coverage is excessive.
Reduce signal levels by at least 8 dB. through attenuation or
downtilt and re-examine either using prediction or re-driving
Be aware that as strong unwanted signals are reduced or
removed by this process, other signals formerly degraded may
become apparent and also require similar treatment. This is
therefore a somewhat iterative process.
September, 2002 RF200 - 316 RF200 v3.73 (c) 2002 Scott Baxter
Grooming Neighbor Lists
Earlier we described a general technique for creating initial neighbor lists.
During initial optimization, and especially after your system generates data
from commercial traffic, youll want to revisit and groom the neighbor lists.
Use your post-processing tool to show you all handoff transitions
requested by mobiles on a per-sector basis. If you dont have a fancy
software tool, you can still do it with fairly simple scripts parsing captured
pilot strength measurement messages.
For each sector, examine the statistics in conjunction with the Planet
equal power boundaries plot. Consider removing any pilots that are
currently in the neighbor list but have less than 1% of the handoff
transitions. However, make sure that is not a consequence of no test
drives being made across a particular sector boundary (for example, do
not remove adjacent sectors of a sectored site).
Consider adding pilots that are not currently in the neighbor list but have
greater than 5% of the handoff transitions. Remember, though, that the
goal is to keep neighbor lists to a minimum (see below) so avoid adding
sites that are obviously not immediate neighbors of the serving cell (i.e. try
to make use of the composite neighbor list as much as possible).
September, 2002 RF200 - 317 RF200 v3.73 (c) 2002 Scott Baxter
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.
0 dB
-10 dB
-20 dB
Typical Mobile Station Transmit Gain Adjust
Time, Seconds
September, 2002 RF200 - 318 RF200 v3.73 (c) 2002 Scott Baxter
CDMA2000 1xRTT
System Performance Optimization
CDMA2000 1xRTT
System Performance Optimization
Course RF200
September, 2002 RF200 - 319 RF200 v3.73 (c) 2002 Scott Baxter
The Big Picture:
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
I
P

D
a
t
a

E
n
v
i
r
o
n
m
e
n
t
CDMA RF Environment
CDMA IOS PPP Traditional Telephony
IP Data Environment
t1 t1
v
CE
SEL
t1
R-P Interface
PDSN/Foreign Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs
PSTN
T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
Coverage Holes
Pilot Pollution
Missing Neighbors
Fwd Pwr Ovld
Rev Pwr Ovld
Search Windows
Island Cells
Slow Handoff
September, 2002 RF200 - 320 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 321 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 322 RF200 v3.73 (c) 2002 Scott Baxter
Managing Forward Link Sector Loading vs. Time
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
S
e
c
t
o
r

T
o
t
a
l

T
X

P
o
w
e
r

o
r

T
h
r
o
u
g
h
p
u
t
Time, Seconds
Sector Maximum TX Power, Maximum Throughput
Voice Traffic
Packet Data Traffic
September, 2002 RF200 - 323 RF200 v3.73 (c) 2002 Scott Baxter
Starting Optimization on a New System
RF Coverage Control
try to contain each sectors coverage, avoiding gross spillover into
other sectors
tools: PN Plots, Handoff State Plots, Mobile TX plots
Neighbor List Tuning
try to groom each sectors 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
IP Data Performance Assessment
identify latency and throughput issues
Getting these items into shape provides a solid baseline and foundation from
which future performance issues can be addressed.
September, 2002 RF200 - 324 RF200 v3.73 (c) 2002 Scott Baxter
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.
September, 2002 RF200 - 325 RF200 v3.73 (c) 2002 Scott Baxter
CDMA2000 Layer 3 Messages
CDMA2000 Layer 3 Messages
Course RF200
September, 2002 RF200 - 326 RF200 v3.73 (c) 2002 Scott Baxter
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 users 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
September, 2002 RF200 - 327 RF200 v3.73 (c) 2002 Scott Baxter
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
MSG_TYPE (00000110)
ACK_SEQ
MSG_SEQ
ACK_REQ
ENCRYPTION
ERRORS_DETECTED
POWER_MEAS_FRAMES
LAST_HDM_SEQ
NUM_PILOTS
PILOT_STRENGTH
RESERVED (0s)
8
3
3
1
2
5
10
2
4
6
0-7
NUM_PILOTS occurrences of this field:
Field
Length
(in bits)
EXAMPLE:
A POWER MEASUREMENT
REPORT MESSAGE
t
September, 2002 RF200 - 328 RF200 v3.73 (c) 2002 Scott Baxter
Message Vocabulary: Acquisition & Idle States
Sync Channel
Sync Channel Msg
Pilot Channel
No Messages
Paging Channel
Access Parameters Msg
System Parameters Msg
CDMA Channel List Msg
Extended System
Parameters Msg
Extended Neighbor
List Msg
Global Service
Redirection Msg
Order Msg
Base Station Acknowledgment
Lock until Power-Cycled
Maintenance required
many others..
Authentication
Challenge Msg
Status Request Msg
Feature Notification Msg
TMSI Assignment Msg
Channel Assignment
Msg
SSD Update Msg
Service Redirection Msg
General Page Msg
Null Msg Data Burst Msg
Access Channel
Registration Msg
Order Msg
Mobile Station Acknowldgment
Long Code Transition Request
SSD Update Confirmation
many others..
Origination Msg
Page Response Msg
Authentication Challenge
Response Msg
Status Response Msg
TMSI Assignment
Completion Message
Data Burst Msg
BTS
September, 2002 RF200 - 329 RF200 v3.73 (c) 2002 Scott Baxter
Message Vocabulary: Conversation State
Reverse Traffic Channel
Order Message
Mobile Sta. Acknowledgment
Long Code Transition
Request
SSD Update Confirmation
Connect
Authentication Challenge
Response Msg
Flash With
Information Msg
Data Burst Message
Pilot Strength
Measurement Msg
Power Measurement
Report Msg
Send Burst DTMF Msg
Origination
Continuation Msg
Handoff Completion Msg
Parameters Response
Message
Service Request Msg
Service Response Msg
Service Connect
Completion Message
Service Option Control
Message
Status Response Msg
TMSI Assignment
Completion Message
Forward Traffic Channel
Order Msg
Base Station Acknowledgment
Base Station Challenge
Confirmation
Message Encryption Mode
Authentication
Challenge Msg
Alert With
Information Msg
Data Burst Msg
Analog Handoff
Direction Msg
In-Traffic System
Parameters Msg
Neighbor List
Update Msg
Send Burst DTMF Msg
Power Control
Parameters Msg.
Retrieve Parameters Msg
Set Parameters Msg
SSD Update Msg
Flash With
Information Msg
Mobile Station
Registered Msg
Status Request Msg
Extended Handoff
Direction Msg
Service Request Msg
Service Response Msg
Service Connect Msg
Service Option
Control Msg
TMSI Assignment Msg
September, 2002 RF200 - 330 RF200 v3.73 (c) 2002 Scott Baxter
CDMA Call Processing Basics
CDMA Call Processing Basics
Course RF200
September, 2002 RF200 - 331 RF200 v3.73 (c) 2002 Scott Baxter
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.
Whats 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, youve got to know call
processing steps and details AND the RF basis of the transmission
September, 2002 RF200 - 332 RF200 v3.73 (c) 2002 Scott Baxter
Let's Acquire The System!
Let's Acquire The System!
Course RF200
September, 2002 RF200 - 333 RF200 v3.73 (c) 2002 Scott Baxter
Whats In a Handset? How does it work?
Receiver
RF Section
IF, Detector
Transmitter
RF Section
Vocoder
Digital
Rake Receiver
Traffic Correlator
PN xxx Walsh xx

Traffic Correlator
PN xxx Walsh xx
Traffic Correlator
PN xxx Walsh xx
Pilot Searcher
PN xxx Walsh 0
Viterbi
Decoder
CPU
Duplexer
Transmitter
Digital Section
Long Code Gen.
O
p
e
n


L
o
o
p
Transmit Gain Adjust
Messages
Messages
Audio
Audio
Packets
Symbols
Symbols
Chips
RF
RF
AGC
September, 2002 RF200 - 334 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT Acquisition On the Current Frequency:
Find Strongest Pilot, Read Sync Channel
Rake Fingers O
O
O
Reference PN
Active Pilot
E
c
/
I
o
0
0
32K
512
Chips
PN
1. Pilot Searcher Scans the Entire Range of PNs
All PN Offsets
0
-20
MSG_LENGTH, 28, 28 octets
MSG_TYPE, 1, Sync Channel Message
P_REV, 6, IS-2000 Revision 0
MIN_P_REV, 1, J-STD-008
SID 995,
NID 3,
PILOT_PN 240
LC_STATE, 0x00 25 93 12 7C FA,
SYS_TIME, 0x02 20 34 B7 53,
10/23/2001 11:02:54
LP_SEC, 13,
LTM_OFF, 54, -660 minutes
DAYLT, 1, Yes
PRAT, 1, 4800 bps
CDMA_FREQ, 274 (IS-95)
EXT_CDMA_FREQ, 274 (1xRTT)
SR1_BCCH_SUPPORTED, 0
SR3_INCL, 0, No
RESERVED, 0,
2. Put Rake finger(s) on strongest
available PN, decode Walsh 32,
and read Sync Channel Message
SYNC CHANNEL MESSAGE
Handset
Rake Receiver
RF

x

LO
Srch PN??? W0
F1 PN168 W32
F2 PN168 W32
F3 PN168 W32
Is this the right system to use?
Check the PRL!
September, 2002 RF200 - 335 RF200 v3.73 (c) 2002 Scott Baxter
Finding the Right System:
The System Determination Algorithm
Finding the Right System:
The System Determination Algorithm
Course RF200
September, 2002 RF200 - 336 RF200 v3.73 (c) 2002 Scott Baxter
Is That the best CDMA Signal You Can Find?!!
What weve seen so far is the basic process of signal acquisition
from the applicable CDMA standards
For the simple case where the mobile is already on the right
frequency
What happens if the mobile is in a new city, and the desired CDMA
system is on a different frequency? What if you find a competitor?
Each wireless operator programs its mobiles with information
and a special proprietary procedure to guide it to the right
system, no matter where the mobile is used
This process is called the System Determination Algorithm
(SDA) and it is proprietary, not part of the CDMA standards
The SDA guides the mobile to intelligently search different
frequencies until it finds a CDMA signal
After Sync Channel acquisition, the SDA guides the mobile to
possibly choose a different frequency and look for a more
appropriate system
September, 2002 RF200 - 337 RF200 v3.73 (c) 2002 Scott Baxter
Phone Data Guides System Determination
Preferred Only Bit
TRUE
FALSE
Acquisition Index
0 CDMA channels
CDMA channels
Analog Block
Analog Block
1
2
3
350,400
50, 100
A
B
System Records
SID Priority
4139
NID
65535
PREF
Pref
GEO
New
Index Roam Indicator
More 0 Off
59 65535 Pref Same More 2 On
52 65535 Pref Same More 3 Flash
67 65535 Neg Same Same 3 Short-short-long
4412 65535 Pref New More 1 Off
61737 226 Neg New More 0 Off
: : : : : : :
Every three minutes idle
phones rescan for any more-
preferred signals in the current
Geo Group. This is called
climbing the GEO group.
65535 is a wildcard NID.
The phone is to accept any
NID it sees on this system.
There are 29 Acq Indexes in the current PRL. It
is normal for some to contain duplicate channels.
The last system record is not a real
system. It merely contains the version
number of the PRl and is used by some
phones to allow displaying the version.
Preferred more
than the following
record.
Some records are merely analog
Guideposts to allow the phone to
recognize where it is and position into the
proper GEO group GEO confinement.
When the phone
loses service, it
scans the list of
channels in its
current GEO group.
Handsets can be programmed with their Preferred Only bit set to True or
False. If True, the handset can only used preferred systems. If False, the
handset can use non-preferred systems, but will prefer preferred systems
when available.
September, 2002 RF200 - 338 RF200 v3.73 (c) 2002 Scott Baxter
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
Go to last
frequency
from MRU
Strongest
PN, read
Sync
Is SID
permitted?
No Signal
Preferred
Only Bit
0
Denied SID
Read
Paging
Channel
Is better
SID
available?
PRL MRU Acq Idx
Yes
No
Steps from
the CDMA
standards
Steps from
proprietary
SDAs
Proprietary
SDA
databases
Start
Legend
Typical Mobile
System Determination Algorithm
Best System Found!
Begin Normal Paging Channel Operation
Last Resort:
GEO escape
Or Analog
September, 2002 RF200 - 339 RF200 v3.73 (c) 2002 Scott Baxter
The SDA In Action:
Find a Frequency with a CDMA RF Signal
Mobile scans forward link frequencies:
(Cellular or PCS, depending on model)
History List
Preferred Roaming List
until a CDMA signal is found.
NO CDMA?! Go to AMPS,
or to a power-saving standby mode
HISTORY
LIST/MRU
Last-used:
Freq
Freq
Freq
Freq
Freq
etc.
FREQUENCY LISTS:
PREFERRED
ROAMING
LIST/PRL
System1
System2
System3
System4
System5
etc.
Forward Link Frequencies
(Base Station Transmit)
A D B E F C
unlic.
data
unlic.
voice
A D B E F C
1850MHz. 1910MHz. 1990 MHz. 1930MHz.
1900 MHz. PCS Spectrum
824 MHz. 835 845 870 880 894
869
849
846.5
825
890
891.5
Paging, ESMR, etc.
A B A B
800 MHz. Cellular Spectrum
Reverse Link Frequencies
(Mobile Transmit)
September, 2002 RF200 - 340 RF200 v3.73 (c) 2002 Scott Baxter
Basic Acquisition on the Right System!
Rake Fingers
O
O
O
Ref.
PN
Active Pilot
E
c
/
I
o
0
0
32K
512
Chips
PN
1. Pilot Searcher Scans the Entire Range of PNs
All PN Offsets
0
-20
MSG_LENGTH, 28, 28 octets
MSG_TYPE, 1, Sync Channel Message
P_REV, 6, IS-2000 Revision 0
MIN_P_REV, 1, J-STD-008
SID 995,
NID 3,
PILOT_PN 240,
LC_STATE, 0x00 25 93 12 7C FA,
SYS_TIME, 0x02 20 34 B7 53,
10/23/2001 11:02:54
LP_SEC, 13,
LTM_OFF, 54, -660 minutes
DAYLT, 1, Yes
PRAT, 1, 4800 bps
CDMA_FREQ, 274,
EXT_CDMA_FREQ, 274,
SR1_BCCH_SUPPORTED, 0, No
SR3_INCL, 0, No
RESERVED, 0,
2. Put Rake finger(s) on strongest
available PN, decode Walsh 32,
and read Sync Channel Message
SYNC CHANNEL MESSAGE
Handset
Rake Receiver
RF

x

LO
Srch PN??? W0
F1 PN168 W32
F2 PN168 W32
F3 PN168 W32
If PRL says:
This is the Best
Available System!
Go to the
Paging
Channel!
IS-95 users
1xRTT users
No separate F-BCH
No 3xRTT
Watch out! Some early Nokia models lose sanity if they see P_REV
6 here. If you have this problem, use P_REV 5 here and tell them
you have P_REV 6 in the System Parameters Msg. On the PCH.
September, 2002 RF200 - 341 RF200 v3.73 (c) 2002 Scott Baxter
After finding the right system:
Normal Paging Channel Operation
After finding the right system:
Normal Paging Channel Operation
Course RF200
September, 2002 RF200 - 342 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 343 RF200 v3.73 (c) 2002 Scott Baxter
Reading the Configuration Messages
Rake Fingers
O
O
O
Reference PN
Active Pilot
E
c
/
I
o
0
0
32K
512
Chips
PN
All PN Offsets
0
-20
Keep Rake finger(s) on strongest
available PN, monitor Walsh 1,
the Paging Channel
Read the
Configuration Messages
Access Parameters Msg
System Parameters Msg
CDMA Channel List Msg
Extended System
Parameters Msg (*opt.)
(Extended*) Neighbor
List Msg
Global Service
Redirection Msg (*opt.)
Now were ready to operate!!
Handset
Rake Receiver
RF

x

LO
Srch PN??? W0
F1 PN168 W01
F2 PN168 W01
F3 PN168 W01
September, 2002 RF200 - 344 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT Access Parameters Message
12/06/2001 15:45:01
MSG_LENGTH, 19, 19 octets
PD, 0, P_REV_IN_USE < 6
MSG_TYPE, 2, Access Parameters Message
PILOT_PN, 240,
ACC_MSG_SEQ, 0,
ACC_CHAN, 0, 1 Access Channel(s)
NOM_PWR, 0, 0 Db INIT_PWR, 0, 0 dB
PWR_STEP, 3, 3 dB
NUM_STEP, 3, 4 Probe(s)
MAX_CAP_SZ, 3, 6 ACH Frames
PAM_SZ, 3, 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, 0, 1 REG_PSIST, 0, 1
PROBE_PN_RAN, 0, 0 PN chip(s)
ACC_TMO, 3, 400 ms
PROBE_BKOFF, 0, 1 Slot(s)
BKOFF, 1, 2 Slot(s)
MAX_REQ_SEQ, 2,
MAX_RSP_SEQ, 2,
AUTH_MODE, 0, 0
RAND, --, Field Omitted
NOM_PWR_EXT, 0, -8 to 7 dB inclusive
PSIST_EMG_INCL, 0, No
RESERVED, 0,
ACCESS PARAMETERS MESSAGE
BTS
Any Access Msg
MS
Probing
Basic Access Procedure
a Probe Sequence
an Access Attempt
Success!
an Access Probe
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
September, 2002 RF200 - 345 RF200 v3.73 (c) 2002 Scott Baxter
Phone Operation on the Access Channel
A sectors 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
ACCESS
RV TFC
BTS
Channel Assnmt. Msg.
Origination Msg
Base Sta. Acknlgmt. Order
TFC frames of 000s
TFC preamble of 000s
Base Sta. Acknlgmt. Order
Mobile Sta. Ackngmt. Order
Service Connect Msg.
Svc. Connect Complete Msg
Base Sta. Acknlgmt. Order
Call is Established!
MS
Probing
PAGING
FW TFC
PAGING
RV TFC
FW FC
RV TFC
FW TFC
FW TFC
Successful Basic Access Attempt
a Probe Sequence
an Access Attempt
Success!
an Access Probe
September, 2002 RF200 - 346 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT System Parameters Message
MSG_LENGTH 34 octets
PD, 0, P_REV_IN_USE < 6
MSG_TYPE System Parameters Message
PILOT_PN, 240 CONFIG_MSG_SEQ, 1,
SID, 995 NID 3
REG_ZONE, 0, TOTAL_ZONES, 0, ZONE_TIMER, 0, 1 min
MULT_SIDS, 0, No MULT_NIDS, 0, No BASE_ID, 979,
BASE_CLASS, 1, Public PCS System
PAGE_CHAN, 1, MAX_SLOT_CYCLE_INDEX, 2,
HOME_REG, 1, Yes FOR_SID_REG, 1, Yes
FOR_NID_REG, 1, Yes POWER_UP_REG, 1, Yes
POWER_DOWN_REG, 1, Yes PARAMETER_REG, 1, Yes
REG_PRD, 58, 30.89 min
BASE_LAT, 561168, 38D58'12.00N
BASE_LONG, 7024705, 094D42'55.75W REG_DIST, 0,
SRCH_WIN_A, 5, 20 chips
SRCH_WIN_N, 10, 100 chips
SRCH_WIN_R, 15, 452 chips
PWR_THRESH_ENABLE, 1, Yes
PWR_PERIOD_ENABLE, 0, No
PWR_REP_DELAY, 0, 0 frames
RESCAN, 0, No
T_ADD, 32, -16.0 dB T_DROP, 3, -1.5 dB
T_COMP, 2, 1.0 T_TDROP, 2, 2 sec
EXT_SYS_PARAMETER, 1, Yes
EXT_NGHBR_LIST, 1, Yes
GEN_NGHBR_LIST, 0, No
GLOBAL_REDIRECT, 0, No
PRI_NGHBR_LIST, 0, No USER_ZONE_ID, 0, No
EXT_GLOBAL_REDIRECT, 0, No
EXT_CHAN_LIST, 1, Yes RESERVED, 0,
SYSTEM PARAMETERS MESSAGE
Who Registers?
Why & When?
Search Window
Widths
Handoff Thresholds
# Paging Channels, Slotted Mode period
What other optional
configuration messages
exist?
September, 2002 RF200 - 347 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT Extended System Parameters Message
One main job of this message is to
tell mobiles how to report their
identities when they transmit on the
Access Channel
IMSI - International Mobile
Subscriber Identity
The world phone number
of the mobile
ESN - Electronic Serial Number
Different Networks may request
different identification modes; the
phones simply comply
IMSI and ESN
IMSI only
ESN only
Intelligent soft handoff parameters
are also included
MSG_LENGTH, 20, 20 octets
PD, 0, P_REV_IN_USE < 6
MSG_TYPE, 13, Extended System Parameters Message
PILOT_PN, 240,
CONFIG_MSG_SEQ, 1,
DELETE_FOR_TMSI, 0, No USE_TMSI, 0, No
PREFERRED_MSID_TYPE, 3, IMSI And ESN
MCC, 209, 310 IMSI_11_12, 99, 00
TMSI_ZONE_LEN, 0, 0 octets
BCAST_INDEX, 0, Disable Periodic Broadcast Paging
IMSI_T_SUPPORTED, 0, No
P_REV, 6, IS-2000 Revision 0
MIN_P_REV, 1, J-STD-008
SOFT_SLOPE, 0,
ADD_INTERCEPT, 0, 0 dB
DROP_INTERCEPT, 0, 0 dB
PACKET_ZONE_ID, 0, Base Station Does Not Support A
Packet Data Service Zone
MAX_NUM_ALT_SO, 0,
RESELECT_INCLUDED, 0, No
PILOT_REPORT, 0, No
NGHBR_SET_ENTRY_INFO, 0, No
NGHBR_SET_ACCESS_INFO, 0, No
EXTENDED SYSTEM PARAMETERS
September, 2002 RF200 - 348 RF200 v3.73 (c) 2002 Scott Baxter
The Neighbor List Message
The Neighbor List Message gives the
mobile up to 20 PN offsets of sectors it
may soon need in handoff
This enables the mobile to search
smarter and faster
On the paging channel, Enhanced or
Extended neighbor lists may also include
neighbors on different frequencies
Slotted mode mobiles can jump to
other frequencies in their sleep
time to check pilots
This is useful at system boundaries
During a call, a mobile first uses the
neighbor list remembered from idle mode
After each handoff, a new Neighbor
List Update message is sent to the
mobile on the Forward Traffic
Channel
Each neighbor list received by the mobile
overwrites and replaces the previous
neighbor list
12/06/2001 15:45:01
MSG_LENGTH, 9, 9 octets
PD, 0, P_REV_IN_USE < 6
MSG_TYPE, 14, Extended Neighbor List Message
PILOT_PN, 240,
CONFIG_MSG_SEQ, 1,
PILOT_INC, 4,
RESERVED, 0,
NGHBR_PN = 136 Offset Index
NGHBR_PN = 140 Offset Index
NGHBR_PN = 188 Offset Index
NGHBR_PN = 274 Offset Index
NGHBR_PN = 36 Offset Index
NGHBR_PN = 112 Offset Index
NGHBR_PN = 432 Offset Index
NGHBR_PN = 396 Offset Index
NGHBR_PN = 220 Offset Index
NGHBR_PN = 400 Offset Index
NGHBR_PN = 336 Offset Index
RESERVED = 0
EXTENDED NEIGHBOR LIST
September, 2002 RF200 - 349 RF200 v3.73 (c) 2002 Scott Baxter
The CDMA Channel List Message
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
The mobile immediately uses a
random selection process called
hashing to select one of the
listed channels
The outcome of hashing
depends only on the mobiles
IMSI
Both the system and the
mobile know which carrier the
mobile will choose
The message also includes an
indicator to show if the QPCH is
in use, and for what radio
configurations
MSG_LENGTH, 10, 10 octets
PD, 0, P_REV_IN_USE < 6
MSG_TYPE, 27, Extended CDMA Channel List Message
PILOT_PN, 240,
CONFIG_MSG_SEQ, 1,
NUM_FREQ, 1,
CDMA_FREQ, 274,
RC_QPCH_SEL_INCL, 1, Yes
EXTENDED
CDMA CHANNEL LIST MESSAGE
CDMA Ch
List Message
HASH using
IMSI
F1
F2
F3
F
now
September, 2002 RF200 - 350 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 351 RF200 v3.73 (c) 2002 Scott Baxter
Hashing Examples
Try your own phone in the spreadsheet Hashing.xls (in utilities folder)
Hashing Examples Time between active slots, seconds:
v2. 1-28-2000 1.28 2.56 5.12 10.24 20.48 40.96 81.92 163.84
Number of Slots in Mobile's Cycle:
16 32 64 128 256 512 1024 2048
Key in red-shaded
How Many
Frequencies?
How Many Paging
Channels? Slot Cycle Index:
values
2 1 0 1 2 3 4 5 6 7
10 Digit IMSI Use Freq. # Use PCH # Slot# Slot# Slot# Slot# Slot# Slot# Slot# Slot#
6153000124
1 1 15 31 63 127 127 383 895 895
6153000125 1 1 11 27 27 27 27 27 539 1563
6153000126
1 1 5 5 5 69 69 69 69 69
6153000127
1 1 3 3 3 67 195 451 451 1475
6153000128
2 1 8 24 24 24 152 152 152 1176
6153000129 2 1 9 25 25 25 25 25 25 25
6153000130
1 1 11 27 27 27 27 27 539 1563
6153000131
2 1 1 1 33 97 225 225 737 737
6153000132
1 1 8 8 40 40 40 40 552 552
6153000133 1 1 3 19 51 115 243 243 755 755
September, 2002 RF200 - 352 RF200 v3.73 (c) 2002 Scott Baxter
The Global Service Redirection Message
The GSRM was originally
intended as a way to
solve system and
multicarrier border
problems
Outermost F2 cells
transmit GSRM,
sending distant F2
mobiles to F1
The GSRM can also be
used to manually
distribute idle mobiles to
different frequencies
A GSRM applies only
to phones of Access
Overload Classes
specified in the
message
98/05/17 24:21.566 Paging Channel: Global Service Redirection
PILOT_PN: 168, MSG_TYPE: 96, CONFIG_MSG_SEQ: 0
Redirected access overload classes: { 0, 1 },
RETURN_IF_FAIL: 0,
DELETE_TMSI: 0,
Redirection to an analog system:
EXPECTED_SID = 0
Do not ignore CDMA Available indicator on the redirected analog
system
Attempt service on either System A or B with the custom system
selection process
GLOBAL SERVICE REDIRECTION
If a GSRM applies to you, GO!!
CDMA Carrier Frequency 2
CDMA Carrier Frequency 1
GSRM
September, 2002 RF200 - 353 RF200 v3.73 (c) 2002 Scott Baxter
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 mobiles 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)
Go to last
frequency
from MRU
Strongest
PN, read
Sync
Is SID
permitted?
No Signal
Preferred
Only Bit
0
Denied SID
Read
Paging
Channel
CDMA Ch
List Message
Global Svc
Redir Msg
HASH using
IMSI
my ACCOLC?
redirect
Is better
SID
available?
PRL MRU Acq Idx
Yes
No
F1
F2
F3
to Analog
to another CDMA frequency or system
Config
Messages:
remain
Steps from
the CDMA
standards
Steps from
proprietary
SDAs
Proprietary
SDA
databases
Start
Legend
System Determination Algorithm
Last Resort:
GEO escape
Or Analog
Idle Mode Carrier Selection
September, 2002 RF200 - 354 RF200 v3.73 (c) 2002 Scott Baxter
Multi-Carrier Operation:
Mobiles Change Frequencies. When/Why/How?
f5
f4
f3
f2
f1
System
Acquisition
Idle Mode
Reselection
Call Start:
Ch. Assignment
In Call:
Hard Handoff
MRU
SDA
PRL-AI
Hashing:
IS-95 or
1xRTT
GSRM
Multi-
Freq
Nbrs
Proprietary
Network
Algorithms
Nortel: MCTA
Lucent:
Motorola:
Auxiliary
Handoff Triggers
Beacons
Ec/Io, RTD
Proprietary
Processes
Remember: Different Mechanisms Apply at Different Stages
September, 2002 RF200 - 355 RF200 v3.73 (c) 2002 Scott Baxter
Lets Do An Idle Mode
Handoff!
Lets Do An Idle Mode
Handoff!
Course RF200
September, 2002 RF200 - 356 RF200 v3.73 (c) 2002 Scott Baxter
Idle Mode Handoff
An idle mobile always demodulates the best available signal
In idle mode, it isnt 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, not
synchronous -- just like ABC, NBC, CBS, and CNN TV news
programs arent in word-sync for simultaneous viewing
Since a mobile cant combine signals, the mobile must switch
quickly, always enjoying the best available signal
The mobiles pilot searcher is constantly checking neighbor pilots
If the searcher notices a better signal, the mobile continues on the
current paging channel until the end of the current superframe,
then instantly switches to the paging channel of the new signal
The system doesnt know the mobile did this! (Does NBCs
Tom Brokaw know you just switched your TV to CNN?)
On the new paging channel, if the mobile learns that registration is
required, it re-registers on the new sector
September, 2002 RF200 - 357 RF200 v3.73 (c) 2002 Scott Baxter
Idle Mode on the Paging Channel:
Meet the Neighbors, track the Strongest Pilot
E
c
/
I
o
All PN Offsets
0
0
32K
512
Chips
PN
0
-20
Neighbor Set
The phones pilot searcher constantly checks
the pilots listed in the Neighbor List Message
If the searcher ever notices a neighbor pilot substantially stronger than
the current reference pilot, it becomes the new reference pilot
and the phone switches over to its paging channel on the next superframe.
This is called an idle mode handoff.
Rake Fingers O
O
O
Reference PN
Active Pilot
SRCH_WIN_A
SRCH_WIN_N
Mobile Rake RX
Srch PN??? W0
F1 PN168 W01
F2 PN168 W01
F3 PN168 W01
September, 2002 RF200 - 358 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT Access Procedures
1xRTT Access Procedures
Course RF200
September, 2002 RF200 - 359 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT Access Procedures
IS-2000 adds two new Access methods, for three ways to access:
Basic Access Mode:
(Existing Aloha Method from IS-95)
no closed-loop power control
Mobiles may suffer collisions
Mobile Power control is by successive trial and error, which is
not very efficient
Power Controlled Aloha Mode
R-EACH is power controlled
Better power control, but still subject to collisions
Power Controlled Reservation Mode
R-CCCH channel is Power Controlled
Access to system is Reservation-based (no collisions)
Maximizes feasible occupancy level of access channels
MS
Probing
Success!
September, 2002 RF200 - 360 RF200 v3.73 (c) 2002 Scott Baxter
New Channels Improve 1xRTT Access
BTS
FORWARD CHANNELS REVERSE CHANNELS
F-Pilot
F-Sync
PAGING
F-BCH
F-QPCH
F-CPCCH
F-CACH
F-CCCH
R-Pilot
R-CCCH
R-EACH
1 1
1
0 or 1
1
1 to 7
0 or 1
0 or 1
0 or 1
0 or 1
0 to n
Same coding as IS-95B,
Backward compatible
Same coding as IS-95B,
Backward compatible
Same coding as IS-95B,
Backward compatible
Broadcast Channel
Quick Paging Channel
Common
Power Control Channel
Common
Assignment Channel
Common
Control Channels
Includes Power
Control Subchannel
Enhanced
Access Channel
Common
Control Channel
Access Channel
(IS-95B compatible)
R-ACH or
F-TRAFFIC
F-DCCH 0 or 1
F-FCH
F-SCH
F-SCH
0 to many
1
0 to 7
0 to 2
Dedicated
Control Channel
Forward
Traffic Channels
Fundamental Channel
Supplemental
Channels IS-95B only
Supplemental
Channels RC3,4,5
R-TRAFFIC
R-DCCH
R-FCH
R-SCH
0 or 1
0 to 2
Dedicated
Control Channel
Reverse Fundamental
Channel (IS95B comp.)
Reverse
Supplemental Channel
1
September, 2002 RF200 - 361 RF200 v3.73 (c) 2002 Scott Baxter
Power Controlled Reservation Access Mode
Reservation Access Mode procedures:
On R-EACH, mobile asks permission to transmit
The associated F-CACH gives permission
Mobile transmits on R-CCCH during scheduled slot
F-CPCCH gives power control during R-CCCH transmission
F-CCCH gives acknowledgment and TCH assignment, if needed
R-EACH
R-CCCH
F-CACH
BTS
Enhanced Access Probe
Early Acknowledgment
Channel Assignment Message
Acknowledgment
F-CPCCH
EACH HEADER EACH PREAMBLE
MESSAGE CAPSULE CACH PREAMBLE
Enhanced Access Data
CCCH HEADER CCCH PREAMBLE
Power Control Bits
F-CCCH
September, 2002 RF200 - 362 RF200 v3.73 (c) 2002 Scott Baxter
Lets Register!
Lets Register!
Course RF200
September, 2002 RF200 - 363 RF200 v3.73 (c) 2002 Scott Baxter
Registration
Registration is the process by which an idle mobile lets the system
know its awake and available for incoming calls
this allows the system to inform the mobiles home switch of
the mobiles 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
September, 2002 RF200 - 364 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Paging
Channel
Registration
BTS
Registration Message (by PROBING)
Base Station Acknowledgment Order
September, 2002 RF200 - 365 RF200 v3.73 (c) 2002 Scott Baxter
An Actual 1xRTT Registration
IS-95 Message Type: Registration
ACK_SEQ: 7 MSG_SEQ: 5 ACK_REQ: 1 VALID_ACK: 0
ESN (Electronic Serial Number): 0xB38092BC
IMSI Class: 0 IMSI Class 0 Type: IMSI_S only
IMSI_S: 694 582 9500
Pilot Strength: -8.0 dB
Active pilot is first one probed?: Yes
Original pilot is same as pilot in previous probe?: No
Number of additional pilots: 0
Registration Type: Timer-based Slot Cycle Index: 2
Mobile Protocol Revision Level: 6
Station Class Mark: Dual Mode, Slotted, Discontinuous Xmit,
Power Class 3
Mobile-Terminated Calls Acceptable?: Yes
REGISTRATION MESSAGE
IS-95 Message Type: System Parameters
PN Offset: 44 CONFIG_MSG_SEQ 0 SID 1121 NID 1
REG_ZONE: 0 TOTAL_ZONES: 0 Zone timer length (min): 1
MULT_SIDS: 0 MULT_NIDS: 0
BASE_ID: 5586 BASE_CLASS: Public Macrocellular System
PAG_CHAN: 1 MAX_SLOT_CYCLE_INDEX: 2
HOME_REG: 1 FOR_SID_REG: 1 FOR_NID_REG: 1,
POWER_UP_REG: 1 POWER_DOWN_REG: 1
PARAMETER_REG: 1 Registration period (sec): 1853.60
Base station 00000.00 Lon., 00000.00 Lat. REG_DIST: 0
SRCH_WIN_A: 20ch SRCH_WIN_N: 100ch SRCH_WIN_R: 320ch
NGHBR_MAX_AGE: 0 PWR_REP_THRESH: 2
PWR_REP_FRAMES (frames): 905 PWR_THRESH_ENABLE: 1
PWR_PERIOD_ENABLE: 0, PWR_REP_DELAY: 1 (0 frames)
Re-Init and Re-acquire After This Message?: No
T_ADD: -14dB T_DROP: -16dB T_COMP: 1 DB, T_TDROP: 4s
Sending Extended System Parameters Messages?: Yes
Are Extended Neighbor List Messages Being Sent?: No
Are General Neighbor List Messages Being Sent?: No
Using Global Redirect Messages?: No
Are Private Neighbor List Messages Being Sent?: No
Are User Zone ID Messages Being Sent?: No
Are Extended Global Redirection Messages Being Sent?: No
Are Extended Channel List Messages Being Sent?: Yes
SYSTEM PARAMETERS MESSAGE
IS-95 Message Type: Order
ACK_SEQ: 5 MSG_SEQ: 2 ACK_REQ: 0 VALID_ACK: 1
Address Type: IMSI IMSI Class: 0
IMSI Class 0 Type: IMSI_S, IMSI_11_12, and MCC
Mobile Country Code (MCC): 310 IMSI 11th+12th Digits: 00
IMSI_S: 694 582 9500 Order Message Type: Base ACK
BASE STATION ACKNOWLEDGMENT
The System Parameters Message tells
all mobiles when they should register.
This mobile notices that it is obligated to
register, so it transmits a Registration
Message.
The base station confirms that the
mobiles registration message was
received. Were officially registered!
September, 2002 RF200 - 366 RF200 v3.73 (c) 2002 Scott Baxter
Lets Make An Outgoing Call!
Lets Make An Outgoing Call!
Course RF200
September, 2002 RF200 - 367 RF200 v3.73 (c) 2002 Scott Baxter
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 others 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
September, 2002 RF200 - 368 RF200 v3.73 (c) 2002 Scott Baxter
Access
Channel
Reverse
Traffic
Channel
Paging
Channel
Mobile-Originated Call Scenario
BTS
Origination Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Traffic Channel Preamble: Frames of 000s
Continuous frames of all 000s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
Forward
Traffic
Channel
September, 2002 RF200 - 369 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT Origination
MSG_LENGTH 36 octets PD, 1, P_REV_IN_USE >= 6
MSG_ID, 4, Origination Message LAC_LENGTH 13 octets
ACK_SEQ 7 MSG_SEQ 0 ACK_REQ 1
VALID_ACK 0 ACK_TYP, 0
MSID_TYPE, 3, IMSI and ESN MSID_LEN, 9, 9 octets
ESN, 0x9F 5C BB F5, 2673654773
IMSI_CLASS, 0, IMSI_CLASS_0_TYPE, 0, IMSI_S included
RESERVED, 0, IMSI_S, 0x03 C8 87 79 AF, 9132209814
AUTH_MODE, 0, 0 LAC_PADDING, 0,
ACTIVE_PILOT_STRENGTH, 5, -2.50 dB
FIRST_IS_ACTIVE, 1, Yes MOB_TERM, 1, Yes
SLOT_CYCLE_INDEX 2 512 MOB_P_REV 6 IS-2000 Rev 0
SCM 234 BandClass 1DualMode Slotted Continuous Class III
REQUEST_MODE, 1, CDMA Only SPECIAL_SERVICE Yes
SERVICE_OPTION, 33, Std: 144kbps PacketData, IP or ISO
PM, 0, No DIGIT_MODE, 0, 4-bit DTMF Codes
MORE_FIELDS, 0, No NUM_FIELDS, 4,
Character, CHARi, 12, #, 7, 7, 7, 7 7, 7
NAR_AN_CAP, 0, No
PACA_REORIG, 0, User Directed Origination
RETURN_CAUSE, 0, Normal Access
MORE_RECORDS, 0, PACA_SUPPORTED, 0, No
NUM_ALT_SO, 0, DRS, 1, Yes UZID_INCL, 0, No
CH_IND, 1, Fundamental Channel SR_ID, 1,
OTD_SUPPORTED, 0, No QPCH_SUPPORTED, 1, Yes
ENHANCED_RC, 1, Yes FOR_RC_PREF, 3,
REV_RC_PREF, 3, FCH_SUPPORTED, 1, Yes
FCH_FRAME_SIZE, 0, Supports only 20 ms Frame Sizes
FOR_FCH_LEN, 2, F-RC1, 1, Yes F-RC2, 1, Yes F-RC3, 1,
Yes F-RC4, 1, Yes F-RC5, 1, Yes F-RC6, 0, No
REV_FCH_LEN, 2, R-RC1, 1, Yes R-RC2, 1, Yes R-RC3,
1, Yes R-RC4, 1, Yes R-RC5, 0, No
DCCH_SUPPORTED, 0, No ENC_INFO_INCL, 0, No
SYNC_ID_INCL, 1, Yes SYNC_ID, error, error: 16 bit field, 6
bits available RESERVED, 0,
ORIGINATION MESSAGE
MSG_LENGTH, 16, 16 octets
PD, 0, P_REV_IN_USE < 6
MSG_TYPE, 7, Order Message
ACK_SEQ, 0,
MSG_SEQ, 0,
ACK_REQ, 0, No
VALID_ACK, 1, Yes
ADDR_TYPE, 2, IMSI
ADDR_LEN, 7, 7 octets
IMSI_CLASS, 0,
IMSI_CLASS_0_TYPE, 3, IMSI_S, IMSI_11_12, and MCC
included
RESERVED, 0,
MCC, 209, 310
IMSI_11_12, 99, 00
IMSI_S, 0x03 C8 87 79 AF, 9132209814
ORDER, 16, Base Station Acknowledgement Order
ADD_RECORD_LEN, 0, 0 octets
RESERVED, 0,
BASE STATION ACKNOWLEDGMENT
The mobile sends an
origination message
on the access
channel.
The base station
confirms that the
origination
message was
received.
September, 2002 RF200 - 370 RF200 v3.73 (c) 2002 Scott Baxter
Traffic Channel Assignment
MSG_LENGTH, 30, 30 octets
PD, 0, P_REV_IN_USE < 6
MSG_TYPE, 21, Extended Channel Assignment Message
ACK_SEQ, 0, MSG_SEQ, 1, ACK_REQ, 0, No
VALID_ACK, 1, Yes ADDR_TYPE, 2, IMSI
ADDR_LEN, 7, 7 octets IMSI_CLASS, 0,
CLASS_0_TYPE, 3, IMSI_S, IMSI_11_12, and MCC included
RESERVED, 0, MCC, 209, 310 IMSI, IMSI_11_12, 99, 00
IMSI_S, 0x03 C8 87 79 AF, 9132209814
RESERVED_1, 0, ADD_RECORD_LEN, 14, 13 octets
ASSIGN_MODE, 0, Traffic Channel Assignment
RESERVED_2, 0, FREQ_INCL, 1, Yes
DEFAULT_CONFIG, 4, Reserved
BYPASS_ALERT_ANSWER, 0, No
RESERVED, 0, NUM_PILOTS, 0, 1 Pilots
GRANTED_MODE, 0, FRAME_OFFSET, 15, 18.75 ms
ENCRYPT_MODE, 0, Encryption Disabled
BAND_CLASS, 1, 1.850 to 1.990 GHz Band
CDMA_FREQ, 274, PILOT_PN, 240,
PWR_COMB_IND, 0, No CODE_CHAN, 17,
FOR_FCH_RC, 3, RC 3 REV_FCH_RC, 3, RC 3
FPC_FCH_INIT_SETPT, 56, 7.000 dB
FPC_FCH_FER, 0, 0.2%
FPC_FCH_MIN_SETPT, 2, 0.250 dB
FPC_FCH_MIN_SETPT, 4, 0.500 dB
FPC_SUBCHAN_GAIN, 7, 0 dB
RLGAIN_ADJ, 8, 8 dB
REV_FCH_GATING_MODE, 0, No RESERVED, 0,
EXTENDED
CHANNEL ASSIGNMENT
MESSAGE
The base station sends a
Channel Assignment
Message and the mobile
goes to the traffic channel.
September, 2002 RF200 - 371 RF200 v3.73 (c) 2002 Scott Baxter
Traffic Channel Confirmation
MSG_LENGTH, 8, 8 octets MSG_TYPE, 1, Order Message
ACK_SEQ, 0, MSG_SEQ, 1, ACK_REQ, 1, Yes
ENCRYPTION, 0, Encryption Disabled
USE_TIME, 0, No ACTION_TIME, 0, 0 ms
ORDER, 16, Mobile Station Acknowledgement Order
ADD_RECORD_LEN, 0, 0 octets RESERVED, 0,
MOBILE STATION ACKNOWLEDGMENT
MSG_LENGTH, 8, 8 octets MSG_TYPE, 1, Order Message
ACK_SEQ, 7, MSG_SEQ, 0, ACK_REQ, 1, Yes
ENCRYPTION, 0, Encryption Disabled
USE_TIME, 0, No ACTION_TIME, 0, 0 ms
ORDER, 16, Base Station Acknowledgement Order
ADD_RECORD_LEN, 0, 0 octets RESERVED, 0,
BASE STATION ACKNOWLEDGMENT
The base station is already
sending blank frames on
the forward channel,using
the assigned Walsh code.
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 mobiles preamble.
The mobile station acknowledges the
base stations acknowledgment.
Everybody is ready!
September, 2002 RF200 - 372 RF200 v3.73 (c) 2002 Scott Baxter
Status Request/Response
MSG_LENGTH 44 MSG_TYPE, 16, Status Response Message
ACK_SEQ, 1, MSG_SEQ, 0, ACK_REQ, 0 ENCRYPTION 0
QUAL_INFO_TYPE, 0, None QUAL_INFO_LEN 0 octets
RECORD_TYPE 27, Reserved RECORD_LEN 9 octets
OTD_SUPPORTED, 0, No FCH_SUPPORTED, 1, Yes
FCH_FRAME_SIZE, 0,
FOR_FCH_LEN 2 RC1:1 RC2:1 RC3:1 RC4:1 RC5:1 RC6: 0
REV_FCH_LEN 2 RC1:1RC2:1 RC3:1 RC4:1 RC5:0 RC6: 0
DCCH_SUPPORTED 0 No FOR_SCH_SUPPORTED 1 Yes
FOR_SCH_LEN 2 RC1:0 RC2:0 RC3:1 RC4:1 RC5:0 RC6:0
FOR_SCH_NUM, 1,
FOR_TURBO_SUPPORTED 0 FOR_CONV_SUPPORTED 1
FOR_MAX_CONV_BLOCK_SIZE 4 RS1: 3048, RS 2: 4584
FOR_FRAME_40_SUPPORTED 0 FOR_FRAME_80_SUPPORTED 0
FOR_MAX_RATE, 0, 9.6 kbps or 14.4 kbps
REV_SCH_SUPPORTED, 1, Yes
REV_SCH_LEN 1 RC1:0 RC2:0 RC3:1 REV_SCH_NUM 1
REV_TURBO_SUPPORTED 0 REV_CONV_SUPPORTED 1
REV_MAX_CONV_BLOCK_SIZE 4 RS1: 3048, RS2: 4584
REV_FRAME_40_SUPPORTED 0 REV_FRAME_80_SUPPORTED 0
REV_MAX_RATE, 0, 9.6 kbps or 14.4 kbps
NONOCTET_ALIGNED_DATA 0 OCTET_ALIGNED_DATA 0
STS_SUPPORTED, 0, No 3X_CCH_SUPPORTED, 0, No
RECORD_TYPE 14 Band Class Information RECORD_LEN 12
BAND_CLASS_0:0 BAND_CLASS_1: 0 BAND_CLASS_2: 0
BAND_CLASS_3: 1 BAND_CLASS_4: 0 BAND_CLASS_5: 0
BAND_CLASS_6: 0 BAND_CLASS_7: 0
RECORD_TYPE, 0, Reserved RECORD_LEN, 15, 15 octets
RESERVED128 RESERVED 0 RESERVED 23 RESERVED 129
RESERVED, 0, RESERVED, 0, RESERVED, 248, RESERVED, 0,
RESERVED, 1, RESERVED, 120, RESERVED, 0, RESERVED, 16,
RESERVED, 36, RESERVED, 132, RESERVED, 16, RESERVED, 66,
RESERVED, 64, RESERVED, 145, RESERVED, 16, RESERVED, 64,
RESERVED, 136, RESERVED, 0,
STATUS RESPONSE MESSAGE
MSG_LENGTH, 9 octets MSG_TYPE, 16, Status Request Message
ACK_SEQ, 7, MSG_SEQ, 1, ACK_REQ, 1, Yes
ENCRYPTION, 0, Encryption Disabled
QUAL_INFO_TYPE, 0, None QUAL_INFO_LEN, 0, 0 octets
NUM_FIELDS, 2, RECORD_TYPE, 27, Reserved
RECORD_TYPE, 28, Channel Configuration Capability Information
STATUS REQUEST
MSG_LENGTH, 7, 7 octets MSG_TYPE, 1, Order Message
ACK_SEQ 3, MSG_SEQ 4, ACK_REQ 0, ENCRYPTION 0
ORDER, 16, Base Station Acknowledgement Order
ADD_RECORD_LEN, 0 CON_REF_INCL, 0, No RESERVED, 0,
BASE STATION ACKNOWLEDGMENT
September, 2002 RF200 - 373 RF200 v3.73 (c) 2002 Scott Baxter
Status Response Message
MSG_LENGTH 66 MSG_TYPE, 16, Status Response Message
ACK_SEQ 2, MSG_SEQ 3, ACK_REQ 0, ENCRYPTION 0
QUAL_INFO_TYPE 2, BAND_CLASS+OP_MODE QUAL_INFO_LEN 2
BAND_CLASS, 0, 800 MHz Cellular Band
OP_MODE, 1, TIA/EIA/IS-95 CDMA Mode In Band Class 0
RESERVED, 0, RECORD_TYPE, 8, Terminal Info RECORD_LEN 55
MOB_P_REV, 6, IS-2000 Revision 0 MOB_MFG_CODE, 159,
MOB_MODEL, 69, MOB_FIRM_REV, 783,
SCM, 106, Band Class 0, Dual Mode, Slotted, Continuous, Class III
LOCAL_CTRL, 0, No SLOT_CYCLE_INDEX, 2, 5.12
SERVICE_OPTION, 32770, QUALCOMM: 8K Markov Old
SERVICE_OPTION, 32796, QUALCOMM: 13K Markov Old
SERVICE_OPTION, 32798, QUALCOMM: 8K Markov New
SERVICE_OPTION, 32799, QUALCOMM: 13K Markov New
SERVICE_OPTION, 2, Standard: 8K Loopback
SERVICE_OPTION, 9, Standard: 13K Loopback
SERVICE_OPTION, 6, Standard: Short Message Services (Rate Set1)
SERVICE_OPTION, 14, Standard: Short Message Services (Rate Set2)
SERVICE_OPTION, 18, Standard: OverTheAir Param Admin (Rate Set1)
SERVICE_OPTION, 19, Standard: OverTheAir Param Admin (Rate Set2)
SERVICE_OPTION, 32768, QUALCOMM: Voice 13K
SERVICE_OPTION, 17, Standard: High Rate Voice (13 kbps)
SERVICE_OPTION, 3, Standard: EVRC (8 kbps)
SERVICE_OPTION, 32776, AT&T: Unknown
SERVICE_OPTION, 32, Standard: Test Data Service Option (TDSO)
SERVICE_OPTION, 33, Standard: 144kbps PacketData, Internet or ISO Protocol
SERVICE_OPTION, 25, Std: HighSpeedPacketData:Inet or ISO (RS2 Fwd, RS2 Rev)
SERVICE_OPTION, 22, Std: HighSpeedPacketData:Inet or ISO (RS1 Fwd, RS1 Rev)
SERVICE_OPTION, 15, Standard: 14.4kbps PDS Internet or ISO Protocol Stack
SERVICE_OPTION, 7, Standard: PDS Internet or ISO Protocol Stack
SERVICE_OPTION, 4, Standard: Asynchronous Data Service
SERVICE_OPTION, 12, Standard: Data
SERVICE_OPTION, 5, Standard: Group 3 Facsimile (9.6kbps)
SERVICE_OPTION, 13, Standard: Group 3 Facsimile (14.4 or 9.6kbps)
RESERVED, 0, RESERVED, 0,
STATUS RESPONSE MESSAGE
September, 2002 RF200 - 374 RF200 v3.73 (c) 2002 Scott Baxter
Service Request
MSG_LENGTH 38 MSG_TYPE, 12, Service Request Message
ACK_SEQ 0 MSG_SEQ 0 ACK_REQ 1 ENCRYPTION 0
SERV_REQ_SEQ 0 REQ_PURPOSE 2 Propose A Service Configuration
RECORD_TYPE 19 Service Configuration Information RECORD_LEN 30
FOR_MUX_OPTION 1, REV_MUX_OPTION, 1,
FOR_NUM_BITS, 240, REV_NUM_BITS, 240,
NUM_CON_REC, 1, RECORD_LEN, 12, 12 octets CON_REF, 0,
SERVICE_OPTION, 33, Std: 144kbps PacketData, Internet or ISO Protocol
FOR_TRAFFIC, 1, SO Uses Primary Traffic On FTC
REV_TRAFFIC, 1, SO Uses Primary Traffic On RTC
UI_ENCRYPT_MODE, 0, User Information Encryption Disabled
SR_ID, 1, RLP_INFO_INCL, 1, Yes RLP_BLOB_LEN, 5, 5 octets
RLP_BLOB, 46, RLP_BLOB, 219, RLP_BLOB, 101, RLP_BLOB, 50,
RLP_BLOB, 152,
QOS_PARMS_INCL, 0, No RESERVED, 0,
FCH_CC_INCL, 1, Yes FCH_FRAME_SIZE, 0, Supports only 20 ms
FOR_FCH_RC, 3, RC 3 REV_FCH_RC, 3, RC 3
DCCH_CC_INCL 0 FOR_SCH_CC_INCL 1 NUM_FOR_SCH, 1
FOR_SCH_ID, 0, FOR_SCH_MUX, 2337, SCH_REC_LEN, 2, 2 octets
SCH_RC 3 SprdRate=1; 1200,1350,1500,2400,2700,4800,9600,19200,
38400,76800,153600 bps data R=1/4, QPSK pre-sprdng symb TD allowed
Coding Type, CODING, 0, Convolutional Coding
FRAME_40_USED, 0, No FRAME_80_USED, 0, No
MAX_RATE, 0, 9.6 kbps or 14.4 kbps REV_SCH_CC_INCL, 1, Yes
NUM_REV_SCH, 1, REV_SCH_ID, 0, REV_SCH_MUX, 2321,
SCH_REC_LEN, 2, 2 octets
SCH_RC, 3, SprdRate=1; 1200,1350,1500,2400,2700,4800,9600,19200,
38400,76800,153600 bps data rates R=1/4, 307200 bps data rate R=1/2;
BPSK modulation with a pilot
Coding Type, CODING, 0, Convolutional Coding
FRAME_40_USED, 0, No FRAME_80_USED, 0, No
MAX_RATE, 0, 9.6 kbps or 14.4 kbps RESERVED, 0,
SERVICE REQUEST MSG.
September, 2002 RF200 - 375 RF200 v3.73 (c) 2002 Scott Baxter
Service Connect/Service Connect Complete
MSG_LENGTH 6 MSG_TYPE 14 Service Connect Completion Message
ACK_SEQ 4, MSG_SEQ 1, ACK_REQ 1, ENCRYPTION 0
RESERVED, 0, SERV_CON_SEQ, 0, RESERVED, 0,
SERVICE CONNECT COMPLETE
MSG_LENGTH 42 MSG_TYPE, 20, Service Connect Message
ACK_SEQ 0 MSG_SEQ 4 ACK_REQ 1 ENCRYPTION 0
USE_TIME 0 ACTION_TIME 0ms SERV_CON_SEQ 0
RESERVED, 0, USE_OLD_SERV_CONFIG, 0,
RECORD_TYPE, 7, Service Configuration RECORD_LEN 30
FOR_MUX_OPTION, 1, REV_MUX_OPTION, 1,
RS1_9600_FOR 1 RS1_4800_FOR 1 RS1_2400_FOR 1 RS1_1200_FOR 1 RSV 0 0
RS1_9600_REV 1 RS1_4800_REV 1 RS1_2400_REV 1 RS1_1200_REV 1
RESERVED 0 NUM_CON_REC 1 RECORD_LEN 12 CON_REF, 1,
SERVICE_OPTION 33 Std:144kbps PacketData Internet or ISO Protocol
FOR_TRAFFIC, 1, SO Uses Primary Traffic On FTC
REV_TRAFFIC, 1, SO Uses Primary Traffic On RTC
UI_ENCRYPT_MODE, 0, User Information Encryption Disabled
SR_ID, 1, RLP_INFO_INCL, 1, Yes RLP_BLOB_LEN, 5, 5 octets
RLP_BLOB, 0x2C 0D 94 CA 60, QOS_PARMS_INCL, 0, No
RESERVED, 0, FCH_CC_INCL, 1, Yes FCH_FRAME_SIZE, 0, No
FOR_FCH_RC 3 RC 3 REV_FCH_RC 3 RC 3 DCCH_CC_INCL, 0,No
FOR_SCH_CC_INCL, 1, Yes NUM_FOR_SCH, 1, FOR_SCH_ID, 0,
FOR_SCH_MUX, 2321, SCH_REC_LEN, 2, 2 octets
SCH_RC 3 SprdRate=1; 1200,1350,1500,2400,2700,4800, 9600, 19200,
38400,76800,153600 bps data; R=1/4 QPSK pre-sprdg symbols, TD allowed
CODING, 0, Convolutional Coding
FRAME_40_USED, 0, No FRAME_80_USED, 0, No
MAX_RATE, 0, 9.6 kbps or 14.4 kbps
REV_SCH_CC_INCL, 1, Yes NUM_REV_SCH, 1,
REV_SCH_ID, 0, REV_SCH_MUX, 2321, SCH_REC_LEN, 2, 2 octets
SCH_RC 3 SprdRate=1; 1200,1350,1500,2400,2700,4800,9600,19200,
38400,76800,153600 bps R=1/4, 307200 bps R=1/2; BPSK modulation with a pilot
Coding Type, CODING, 0, Convolutional Coding
FRAME_40_USED, 0, No FRAME_80_USED, 0, No
MAX_RATE, 0, 9.6 kbps or 14.4 kbps RESERVED, 0,
RECORD_TYPE, 19, Non-Negotiable Service Configuration
RECORD_LEN1 FPC_INCL 0 GATING_RATE_INCL 0
FOR_SCH_INCL, 0, No USE_FLEX_NUM_BITS, 0, No
USE_VAR_RATE, 0, No LTU_INFO_INC, 0, No RESERVED, 0,
CC_INFO_INCL, 0, No
SERVICE CONNECT MESSAGE
September, 2002 RF200 - 376 RF200 v3.73 (c) 2002 Scott Baxter
Let's Upload Data!
Let's Upload Data!
Course RF200
September, 2002 RF200 - 377 RF200 v3.73 (c) 2002 Scott Baxter
Requesting/Assigning Supplemental Channels
MSG_LENGTH, 12, 12 octets
MSG_TYPE, 18, Supplemental Channel Request Message
ACK_SEQ 4, MSG_SEQ 7, ACK_REQ 0, ENCRYPTION 0
SIZE_OF_REQ_BLOB, 3 bytes
REQ_BLOB, 228, REQ_BLOB, 39, REQ_BLOB, 255,
USE_SCRM_SEQ_NUM, 0, No
REF_PN, 240,
PILOT_STRENGTH, 4, -2.00 dB
NUM_ACT_PN, 0,
NUM_NGHBR_PN, 0,
REF_PILOT_REC_INCL, 0, No
RESERVED, 0,
SUPPLEMENTAL CHANNEL
REQUEST MESSAGE
MSG_LENGTH 12 octets
MSG_TYPE 35, Extended Supplemental Channel Assignment
Message
ACK_SEQ 2, MSG_SEQ 5, ACK_REQ, 1 ENCRYPTION 0
START_TIME_UNIT, 3, 60 ms
REV_SCH_DTX_DURATION, 10, 200 ms
USE_T_ADD_ABORT, 0, No
USE_SCRM_SEQ_NUM, 0, No
ADD_INFO_INCL, 0, No REV_CFG_INCLUDED, 1, Yes
NUM_REV_CFG_RECS, 0, REV_SCH_ID, 0,
REV_WALSH_ID, 1, Forward Dedicated Control Channel inner
loop estimation
REV_SCH_NUM_BITS_IDX, 3, RC 1,3,5=1512; RC 2,4,6=2280;
12 CRC bits
NUM_REV_SCH, 1, REV_SCH_ID, 0,
REV_SCH_DURATION, 15, Reserved
REV_SCH_START_TIME_INCL, 1, Yes
REV_SCH_START_TIME, 11,
REV_SCH_NUM_BITS_IDX, 3, RC 1,3,5=1512; RC 2,4,6=2280;
12 CRC bits
FOR_CFG_INCLUDED, 0, No NUM_FOR_SCH, 0,
FPC_INCL, 0, No RPC_INCL, 1, Yes
RPC_NUM_SUP, 0, SCH_ID, 0,
RLGAIN_SCH_PILOT, 0, 0.000000 dB
3X_SCH_INFO_INCL, 0, No RESERVED, 0,
EXTENDED SUPPLEMENTAL
CHANNEL ASSIGNMENT
MESSAGE
MSG_LENGTH, 7, 7 octets
MSG_TYPE, 1, Order Message
ACK_SEQ, 5,
MSG_SEQ, 0,
ACK_REQ, 0, No
ENCRYPTION, 0, Encryption Disabled
ORDER, 16, Base Station Acknowledgement Order
ADD_RECORD_LEN, 0, 0 octets
CON_REF_INCL, 0, No
RESERVED, 0,
BTS ACKNOWLEDGMENT
September, 2002 RF200 - 378 RF200 v3.73 (c) 2002 Scott Baxter
Let's Download Data!
Let's Download Data!
Course RF200
September, 2002 RF200 - 379 RF200 v3.73 (c) 2002 Scott Baxter
Requesting/Assigning Supplemental Channels
MSG_LENGTH, 6, 6 octets
MSG_TYPE, 18, Supplemental Channel Request Message
ACK_SEQ, 7,
MSG_SEQ, 4,
ACK_REQ, 1, Yes
ENCRYPTION, 0, Encryption Disabled
SIZE_OF_REQ_BLOB, 0, 0 bytes
USE_SCRM_SEQ_NUM, 0, No
RESERVED, 0,
SUPPLEMENTAL CHANNEL
REQUEST MESSAGE
MSG_LENGTH 15 octets
MSG_TYPE 35, Extended Supplemental Channel Assignment Message
ACK_SEQ 4, MSG_SEQ 0, ACK_REQ 1, ENCRYPTION 0
START_TIME_UNIT, 3, 60 ms
REV_SCH_DTX_DURATION, 10, 200 ms
USE_T_ADD_ABORT, 0, No USE_SCRM_SEQ_NUM, 0, No
ADD_INFO_INCL, 0, No REV_CFG_INCLUDED, 0, No
NUM_REV_SCH, 0, FOR_CFG_INCLUDED, 0, No
NUM_FOR_SCH, 1, FOR_SCH_ID, 0,
FOR_SCH_DURATION, 0, Stop Processing at Start Time
FOR_SCH_START_TIME_INCL, 0, No
SCCL_INDEX, 0, FPC_INCL, 1, Yes FPC_MODE_SCH, 0,
FPC_SCH_INIT_SETPT_OP, 1, FPC_SCH_INIT_SETPT has
Offset value of initial F-SCH Eb/Nt
FPC_SEC_CHAN, 0, NUM_SUP, 2, SCH_ID, 0,
FPC_SCH_FER, 21, 11% - 15% (in units of 1.0%)
FPC_SCH_INIT_SETPT, 224, 20.000 dB
FPC_SCH_MIN_SETPT, 16, 2.000 dB
FPC_SCH_MAX_SETPT, 203, 25.375 dB SCH_ID, 0,
FPC_SCH_FER, 8, 0.5% - 10% (in units of 0.5%)
FPC_SCH_INIT_SETPT, 0, 0.000 dB
FPC_SCH_MIN_SETPT, error, error: 8 bit field, 1 bits available
FPC_SCH_MAX_SETPT, error, error: 8 bit field, 1 bits available
FPC_THRESH_SCH_INCL, 0, No
RPC_INCL, error, error: 1 bit field, 0 bits available
3X_SCH_INFO_INCL, error, error: 1 bit field, 0 bits available
EXTENDED SUPPLEMENTAL
CHANNEL ASSIGNMENT
MESSAGE
MSG_LENGTH, 7, 7 octets
MSG_TYPE, 1, Order Message
ACK_SEQ, 0,
MSG_SEQ, 2,
ACK_REQ, 0, No
ENCRYPTION, 0, Encryption Disabled
ORDER, 16, Base Station Acknowledgement Order
ADD_RECORD_LEN, 0, 0 octets
CON_REF_INCL, 0, No
RESERVED, 0,
MOBILE ACKNOWLEDGMENT
September, 2002 RF200 - 380 RF200 v3.73 (c) 2002 Scott Baxter
Lets End A Call!
Lets End A Call!
Course RF200
September, 2002 RF200 - 381 RF200 v3.73 (c) 2002 Scott Baxter
A Beautiful End to a Normal Call
MSG_LENGTH, 7, 7 octets
MSG_TYPE, 1, Order Message
ACK_SEQ, 0,
MSG_SEQ, 7,
ACK_REQ, 1, Yes
ENCRYPTION, 0, Encryption Disabled
ORDER, 21, Release Order (No Reason Given)
ADD_RECORD_LEN, 0, 0 octets
CON_REF_INCL, 0, No
RESERVED, 0,
MOBILE RELEASE ORDER
BASE STATION ACKNOWLEDGMENT
MSG_LENGTH, 8, 8 octets
MSG_TYPE, 1, Order Message
Number, ACK_SEQ, 7,
MSG_SEQ, 5,
ACK_REQ, 0, No
ENCRYPTION, 0, Encryption Disabled
USE_TIME, 0, No
ACTION_TIME, 0, 0 ms
ORDER, 16, Base Station Acknowledgement Order
ADD_RECORD_LEN, 0, 0 octets
RESERVED, 0,
The mobile left the traffic channel,
scanned to find the best pilot, and read
the Sync Channel Message.
MSG_LENGTH 28 MSG_TYPE, 1, Sync Channel Message
P_REV, 6, IS-2000 Revision 0 MIN_P_REV, 1, J-STD-008
SID, 995, NID, 3, PILOT_PN, 240,
LC_STATE, 0x03 EE 9C 34 BC D8,
SYS_TIME, 0x02 20 35 93 59, 10/23/2001 11:04:04
LP_SEC, 13, LTM_OFF, 54, -660 minutes DAYLT, 1, Yes
PRAT, 1, 4800 bps
CDMA_FREQ, 274,
EXT_CDMA_FREQ, 274,
SR1_BCCH_SUPPORTED, 0, No
SR3_INCL, 0, No
RESERVED, 0,
SYNC CHANNEL MESSAGE
September, 2002 RF200 - 382 RF200 v3.73 (c) 2002 Scott Baxter
Performance Indicators
Performance Indicators
Course RF200
September, 2002 RF200 - 383 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 384 RF200 v3.73 (c) 2002 Scott Baxter
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
FER
%
0 2 5 100
F
o
r
w
a
r
d
R
e
v
e
r
s
e
FER is the end-result of the whole transmission link
if FER is good, then any other problems arent having much
effect
if FER is bad, thats 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
September, 2002 RF200 - 385 RF200 v3.73 (c) 2002 Scott Baxter
Indicator #2: Received Power at the Handset
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
-40
-90
-105
<
<
t
o
o

w
e
a
k









o
v
e
r
l
o
a
d
>
>
RX Level

x
LO

RX Level
(from AGC)
IF LNA
BW
~30
MHz.
BW
1.25
MHz.
Handset Receiver
R
R
R
S
Rake
Receive power is important, but its exact value isnt critical
too much received signal (-35 dbm or higher) could drive the
phones 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
September, 2002 RF200 - 386 RF200 v3.73 (c) 2002 Scott Baxter
Indicator #3, Ec/Io - What does it mean?
Why cant we just use the handsets
received power level to guide
handoffs?
Because it is a simple total RF
power measurement, the total of
all sectors reaching the mobile

x
LO

RX Level
(from AGC)
IF LNA
BW
~30
MHz.
BW
1.25
MHz.
Handset Receiver
R
R
R
S
Rake
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 sectors 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 wont
be able to get much benefit from using a traffic channel on that
sector
September, 2002 RF200 - 387 RF200 v3.73 (c) 2002 Scott Baxter
Indicator #3 Ec/Io Summary
E
c
/I
o
cleanness of the pilot
foretells the readability of the
associated traffic channels
guides soft handoff decisions
digitally derived: ratio of good to
bad energy seen by the search
correlator at the desired PN offset
Never appears higher than Pilots
percentage of serving cells
transmitted energy
Can be degraded by strong RF
from other cells, sectors
Imperfect orthogonality, other
PNs are ~-20 dB.
Can be degraded by noise
E
c
/I
o
dB
-25 -16 -10 0
E
c
I
o
Energy of
desired pilot alone
Total energy received
Above -10:
Good signal
-10 to -16
OK, but pain
Below -16:
Big trouble!
September, 2002 RF200 - 388 RF200 v3.73 (c) 2002 Scott Baxter
Light Traffic Loading
Heavily Loaded
How Ec/Io Varies with Traffic Loading
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.
Ec/Io = (2/4)
= 50%
= -3 db.
Ec/Io = (2/10)
= 20%
= -7 db.
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
T
r
a
f
f
i
c

C
h
a
n
n
e
l
s
6w
0.5w
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
0.5w
September, 2002 RF200 - 389 RF200 v3.73 (c) 2002 Scott Baxter
Many Sectors, Nobody Dominant
One Sector Dominant
How Ec/Io varies with RF Environment
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 sectors pilot
The large Io overrides the
weak Ec; Ec/Io is low!
Io = -90 dbm
Ec = -96 dbm
Ec/Io = -6 db
Io = 10 signals
each -90 dbm
= -80 dbm
Ec of any one
sector = -96
Ec/Io = -16 db
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
T
r
a
f
f
i
c
C
h
a
n
n
e
l
s
4w
0.5w
BTS1
I
0
E
C
BTS2
BTS3
BTS4
BTS5
BTS6
BTS7
BTS8
BTS9
BTS10
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
Pilot
Sync & Paging
Traffic
September, 2002 RF200 - 390 RF200 v3.73 (c) 2002 Scott Baxter
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
cant exceed handsets
maximum (typ. +23 dBm)
TXPO
DUP x

IF
LNA
Subscriber Handset
R
R
R
S
Rake

Viterbi
Decoder
Vocoder

FEC
Orth
Mod
Long PN
x
x
x
IF Mod
I
Q
x ~
LO
Open Loop
LO
Closed Loop Pwr Ctrl
IF
Receiver>>
<<Transmitter
PA
BTS
Typical TXPO:
+23 dBm in a coverage hole
0 dBm near middle of cell
-50 dBm up close to BTS
TXPO = -(RX
dbm
) -C + TXGA
C = +73 for 800 MHz. systems
= +76 for 1900 MHz. systems
What is the right power TX level? Whatever the BTS asks for!
As long as closed loop control is working, the phones opinion
isnt 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)
September, 2002 RF200 - 391 RF200 v3.73 (c) 2002 Scott Baxter
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 stations latest new
decision: mobile is too strong, or mobile is too weak -- there is
no cumulative error, since each decision is fresh
0 dB
-10 dB
-20 dB
Typical Transmit Gain Adjust
Time, Seconds
TXPO = -(RX
dbm
) -C + TXGA
C = +73 for 800 MHz. systems
= +76 for 1900 MHz. systems
September, 2002 RF200 - 392 RF200 v3.73 (c) 2002 Scott Baxter
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.
September, 2002 RF200 - 393 RF200 v3.73 (c) 2002 Scott Baxter
#6 Indicator: Data Latency
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?
I
P

D
a
t
a

E
n
v
i
r
o
n
m
e
n
t
CDMA RF Environment
CDMA IOS PPP Traditional Telephony
IP Data Environment
t1 t1
v
CE
SEL
t1
R-P Interface
PDSN/Foreign Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs
PSTN
T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
Coverage Holes
Pilot Pollution
Missing Neighbors
Fwd Pwr Ovld
Rev Pwr Ovld
Search Windows
Island Cells
Slow Handoff
September, 2002 RF200 - 394 RF200 v3.73 (c) 2002 Scott Baxter
#7 Indicator: Data Throughput
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?
I
P

D
a
t
a

E
n
v
i
r
o
n
m
e
n
t
CDMA RF Environment
CDMA IOS PPP Traditional Telephony
IP Data Environment
t1 t1
v
CE
SEL
t1
R-P Interface
PDSN/Foreign Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs
PSTN
T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
Coverage Holes
Pilot Pollution
Missing Neighbors
Fwd Pwr Ovld
Rev Pwr Ovld
Search Windows
Island Cells
Slow Handoff
September, 2002 RF200 - 395 RF200 v3.73 (c) 2002 Scott Baxter
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.
SIGNATURE:
GOOD CALL
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 396 RF200 v3.73 (c) 2002 Scott Baxter
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.
SIGNATURE:
GOOD CALL
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 397 RF200 v3.73 (c) 2002 Scott Baxter
Signature of a Dropped Call in Poor Coverage
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
SIGNATURE:
DROPPED CALL, BAD COVERAGE
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 398 RF200 v3.73 (c) 2002 Scott Baxter
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 RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 399 RF200 v3.73 (c) 2002 Scott Baxter
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 Bs signal will override
site As signal, making it
unreadable
as soon as the FER goes
too high, a fade timer will
start the the mobile will
eventually die
A
B
BTS
BTS
FORWARD LINK DIES
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
B grows stronger and stronger.
Mobiles 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 cant hear power control
bits, and a fade timer or message timer
kills the call in a few seconds.
September, 2002 RF200 - 400 RF200 v3.73 (c) 2002 Scott Baxter
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, youll
see repeats of messages on
the forward link and reverse
link
SIGNATURE:
REVERSE LINK INTERFERENCE
FFER RXL E
C
/I
O
TxGa TxPo
BTS
Messaging
FFER RXL E
C
/I
O
TxGa TxPo
-110
-30
100%
50%
0%
10%
5%
2%
-40
-90
-100
-20
0
-6
-10
-15
-25
+25
+10
0
-10
-20
+23
-10
-20
-40
-50
-30
+10
0
September, 2002 RF200 - 401 RF200 v3.73 (c) 2002 Scott Baxter
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
B
BTS
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
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 couldnt 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.
REVERSE LINK DIES
September, 2002 RF200 - 402 RF200 v3.73 (c) 2002 Scott Baxter
Solving the #1 Death Scenario: Failed Handoff
Why didnt the mobile ask for handoff?
New sector not on neighbor list
Neighbor Search Window too Small?
BTS in island mode, wrong PN?
Why didnt the BTS set up the handoff?
Didnt hear mobile rev link interf?
No resources available?
T-1 unstable, messages lost
Why didnt the mobile do the handoff?
Couldnt hear BTS, Fwd link interf?
B
BTS
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
REVERSE LINK DIES
A
B
BTS
BTS
FORWARD LINK DIES
O
b
s
t
r
u
c
t
i
o
n
s
T
r
a
v
e
l
Steps in the Handoff Process
Mobiles searcher notices
the needed new pilot
Mobile sends PSMM
requesting handoff
System sets up the handoff:
channel elements
forward power
space in packet pipes
Simulcasting begins!
System tells mobile how to
hear the new sectors:
Handoff Direction Message
Mobile confirms completion:
Handoff Completion Message
System makes new neighbor list,
sends to mobile: Neighbor List
Update Message
Now the mobile can hear
the system better, too!
Now the system can hear
the mobile better!
see
ask
tell
do
ok!
tell
BTS
BTS
BTS
What Went Wrong??!
September, 2002 RF200 - 403 RF200 v3.73 (c) 2002 Scott Baxter
System-Side 1xRTT Tools
System-Side 1xRTT Tools
Course RF200
September, 2002 RF200 - 404 RF200 v3.73 (c) 2002 Scott Baxter
Basic Philosophy of System Data
Each network manufacturer has its own data sets and counters
Access failures, TCCFs, blocks, drops, failed handoffs
These counters are normally available in 2G-only, 3G-only, and total
categories
Additional new statistics are available for IP traffic
The basic philosophy of system data analysis is to analyze and
discriminate within the available data
Identify and rank existing sectors based on
Traffic levels
raw failures/blocks/drops
percentage failures/blocks/drops
Benchmark and track incremental changes
Investigate all significant problems uncovered
Drive-testing or data testing may be required
In-Class activity: view manufacturer documentation and examples
September, 2002 RF200 - 405 RF200 v3.73 (c) 2002 Scott Baxter
Information on System-Side Statistics
Lucent
Technical Reference: Watchmark Prospect for Lucent, v17.0
Nortel
411-2131-814 DMS-MTX Operational Measurements Reference
Manual version v. 12.02 June, 2001
411-2131-900 DMS-MTX Operational Measurements Quick
Reference Guide
Motorola
Performance Analysis 2.16.0 v O , Motorola Inc., January 2002.
1x network Performance Matrix v. 0.1, Motorola Inc., April 2001.
CDMA 2000 1x Voice and Data Cellular Application Note , v. 1.1
Draft; Motorola Inc.
Impact on CDL and CFC in Version 2.16.0 v.1.4, Part No.
8700SCRP20GCDLCFC-D, Motorola Inc., August 2001
CFC Resolution Document v. 1.3, Motorola Inc Performance
Analysis 2.16.0 v O , Motorola Inc., January 2002
September, 2002 RF200 - 406 RF200 v3.73 (c) 2002 Scott Baxter
Mobile-Side 1xRTT Tools
Mobile-Side 1xRTT Tools
Course RF200
September, 2002 RF200 - 407 RF200 v3.73 (c) 2002 Scott Baxter
Sources of CDMA Data and Tools for Processing
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
CBSC Switch BTS
CDSU DISCO
Ch. Card ACC






TFU1
GPSR
CDSU
CDSU
DISCO 1
DISCO 2
SBS
Vocoders
Selectors
CDSU
CDSU
CDSU
CDSU
CDSU
CDSU
CM SLM
LPP LPP ENET
DTCs
DMS-BUS
Txcvr A
Txcvr B
Txcvr C
RFFE A
RFFE B
RFFE C
TFU1
GPSR
IOC
BSM
Data Analysis
Post-Processing
Tools
IS-95/J-STD-008 Messages
IS-95/J-STD-8
Messages
Switch Data
pegs, logs
Mobile Data
Post-Processing
Tools
Mobile Data
Capture Tools
Handset
Messages
External
Analysis
Tools
PC-based
PC-based
Unix-based,
PC-based
Various
CDMA NETWORK EQUIPMENT
HANDSET
System Internal Messages
September, 2002 RF200 - 408 RF200 v3.73 (c) 2002 Scott Baxter
CDMA Field Test Tools
Field Collection Tools using Handset Data
There are many commercial CDMA field test tools
Characteristics of many test tools:
capture data from data ports on commercial handsets
log data onto PCs using proprietary software
can display call parameters, messaging, graphs, and maps
store data in formats readable for post-processing analysis
small and portable, easy to use in vehicles or even on foot
A few considerations when selecting test tools:
does it allow integration of network and mobile data?
Cost, features, convenience, availability, and support
new tools are introduced every few months - investigate!
Qualcomm
Grayson
Comarco
SAFCO
LCC
Motorola
PN Scanners
Agilent
(formerly HP)
Agilent
(formerly HP)
Berkeley
Varitronics
Grayson Qualcomm
Safeco Willtech
September, 2002 RF200 - 409 RF200 v3.73 (c) 2002 Scott Baxter
Graysons new Invex3G Tool
In 1Q2001 Grayson introduced
its new Invex3G tool, with new
features
100 MB ethernet connection
to PC
the eight card slots can hold
receivers or dual-phone
cards
theres also room for two
internal PN scanners
Multiple Invex units can be
cascaded for multi-phone
load-test applications
Cards are field-swappable -
Users can reconfigure the
unit in the field for different
tasks without factory
assistance
September, 2002 RF200 v3.73 (c) 2002 Scott BaxterTechnical Introduction to Wireless -- 1997 Scott Baxter - V0.0 410
This mobile is in a 4-way soft handoff
(four green FCH walsh codes
assigned) in the middle of a downlink
SCH burst. Notice walsh code #2, 8
chips long, is assigned as an SCH
but only on one sector, and the
downlink data speed is 76.8kb/s.
76.8
kb/s
Grayson Invex Playback Example
September, 2002 RF200 - 411 RF200 v3.73 (c) 2002 Scott Baxter
This mobile is in a 2-way soft handoff
(two green FCH walsh codes
assigned) in the middle of a downlink
SCH burst. Notice walsh code #3, 4
chips long, is assigned as an SCH
but only on one sector, and the
downlink data speed is 153.6kb/s.
153.6
kb/s
Grayson Invex Playback Example
September, 2002 RF200 v3.73 (c) 2002 Scott BaxterTechnical Introduction to Wireless -- 1997 Scott Baxter - V0.0 412
F-SCH rates 153.6 kbps; R-SCH 76.8kbps
PN Scanner Data
Grayson Invex Playback Example
Current Data Task Status
Layer-3 Messages
CDMA Status
September, 2002 RF200 - 413 RF200 v3.73 (c) 2002 Scott Baxter
WillTech Tools
Blue Rose platform can
manage multiple phones and
collect data
Internal processor
manages test operations
independently for stand-
alone operation
Internal PCMCIA flash
card provides storage
An external PC can display
collected data during or
after data collection
September, 2002 RF200 - 414 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 415 RF200 v3.73 (c) 2002 Scott Baxter
BOAT TESTING
Base-Station Over-Air Testing
September, 2002 RF200 - 416 RF200 v3.73 (c) 2002 Scott Baxter
Walsh Code Utilization in 1xRTT
9,600
4,800
2,400
307200
sps
153,600
76,800
38,400
19,200
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

b
i
t
s
4

b
i
t
s
8

b
i
t
s
1
6

b
i
t
s
3
2

b
i
t
s
6
4

b
i
t
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 15 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
P
a
g
i
n
g

7
P
a
g
i
n
g

3
P
a
g
i
n
g

5
P
a
g
i
n
g
P
C
H

6
P
C
H

2
P
C
H

4
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
September, 2002 RF200 - 417 RF200 v3.73 (c) 2002 Scott Baxter
September, 2002 RF200 - 418 RF200 v3.73 (c) 2002 Scott Baxter
IS-95 Today:
Pilot, Paging Sync, up to 61 Voice Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
But if the users are highly mobile, forward power may exhaust at typically 30-40 users.
In fixed-wireless or stadium type applications, all walsh codes may be usable.
??? ? ? ? ?
Traffic Channels
Voice or Data
9.6k/14.4k
September, 2002 RF200 - 419 RF200 v3.73 (c) 2002 Scott Baxter
Mixed IS-95 / 1xRTT RC3 Voice:
Pilot, Paging Sync, up to 61 Voice Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
FCHs of 1xRTT RC3 users consume less power, so more total users are possible than in IS-95.
The BTS will probably have enough forward power to carry calls on all 61 walsh codes!
F-FCHs
RC1,2,3 Voice
September, 2002 RF200 - 420 RF200 v3.73 (c) 2002 Scott Baxter
A Possible 1xRTT RC3 BTS Dynamic State:
1 F-SCH, 27 Voice IS-95/1xRTT RC3 Users, 16 Active Data Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
The data users can rapidly share the one F-SCH for 153 kb/s peak, ~9Kb/s avg. user rates.
But so many active data users F-FCHs consume a lot of capacity, reduce number of voice users!
F-SCH 153K RC3
F-FCHs 9.6k
RC3 Data
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
September, 2002 RF200 - 421 RF200 v3.73 (c) 2002 Scott Baxter
A Possible 1xRTT RC3 BTS Dynamic State:
1 F-SCH, 39 IS-95/1xRTT RC3 Voice Users, 4 Active+12 Dormant Data Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
But it takes seconds to move various data users from Dormant to Active!
Data users will get 153 kb/s peak, ~9 kb/s average, but latency will be high.
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F
-
F
C
H
s
D
a
t
a
F-SCH 153K RC3
September, 2002 RF200 - 422 RF200 v3.73 (c) 2002 Scott Baxter
Slightly Improved 1xRTT RC3 BTS Dynamic State:
1 F-SCH, 37 IS-95/1xRTT RC3 Voice Users, 4 Active+12 Control-Hold Data Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
Instead of sending 16 data users to Dormant State, let them time-share 2 F-DCCH for Control Hold state.
Data users will get 153 kb/s peak, ~9 kb/s average, good latency. Not yet available or implemented.
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F
-
F
C
H
s
D
a
t
a
F-SCH 153K RC3
F
-
D
C
C
H
s
September, 2002 RF200 - 423 RF200 v3.73 (c) 2002 Scott Baxter
Heavy Data 1xRTT RC3 BTS Dynamic State:
1 F-SCH, 37 IS-95/1xRTT RC3 Voice Users, 4 Active+12 Control-Hold Data Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
16 data users time-share 2 F-DCCH for Control Hold state. Data users get 38.4, 76.4,
or 153.6 kb/s peak, ~19 kb/s average, good latency. But only 21 voice users!
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F
-
F
C
H
s
D
a
t
a
F-SCH 153K RC3
F
-
D
C
C
H
s
F-SCH 153K RC3
September, 2002 RF200 - 424 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT RC3 BTS With Different User Data Rates:
1 F-SCH, 37 IS-95/1xRTT RC3 Voice Users, 4 Active+12 Control-Hold RC3 Data Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
16 data users time-share 2 F-DCCH for Control Hold state.
Data users get 38.4, 76.4, or 153.6 kb/s peak, ~9 kb/s average, good latency.
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F
-
F
C
H
s
D
a
t
a
F-SCH
76K RC3
F
-
D
C
C
H
s
F
-
F
C
H
3
8
K
F
-
F
C
H
3
8
K
September, 2002 RF200 - 425 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT RC4 Voice Only:
Pilot, Paging Sync, up to 118 Voice Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
Wow! 118 users! But RC4 users F-FCHs consume as much power as old IS-95 calls.
BTS may run out of forward power before the all walsh codes are used.
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC4 Voice
??? ? ? ? ?
September, 2002 RF200 - 426 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT RC4 Voice and Data:
1 F-SCH, 80 1xRTT RC4 Voice Users, 4 Active+12 Control-Hold RC4 Data Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
16 data users time-share 2 F-DCCH for Control Hold state. Data users will get
38.4, 76.4, 153.6 or 307.2 kb/s peak, ~19 kb/s average, good latency. But fwd power may exhaust!
F-SCH 307K RC4
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC4 Voice
?? ? ?
F
-
F
C
H
s
F
-
D
C
C
H
s
September, 2002 RF200 - 427 RF200 v3.73 (c) 2002 Scott Baxter
Mature 1xRTT Mixed-Mode Voice and Data:
1 RC3/RC4 Shared F-SCH, 20 RC3 Voice Users, 38 RC4 Voice Users,
4 Active+12 Control-Hold RC3 and RC4 Data Users
9,600
4,800
2,400
sps
307200
sps
153,600
sps
76,800
sps
38,400
sps
19,200
sps
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

c
h
i
p
s
4

c
h
i
p
s
8

c
h
i
p
s
1
6

c
h
i
p
s
3
2

c
h
i
p
s
6
4

c
h
i
p
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
P
a
g
i
n
g
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
16 data users time-share 2 F-DCCH for Control Hold state. Data users will get
38.4, 76.4, 153.6 or 307.2 kb/s peak, ~9 or 19 kb/s average, good latency. Fwd power tight!
F-SCH 153K RC3
or
F-SCH 307K RC4
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC4 Voice
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F-FCHs 9.6k
RC3 Voice
F
-
F
C
H
s
F
-
D
C
C
H
s
O
r

C
o
m
b
i
n
a
t
i
o
n
s
?? ? ?
September, 2002 RF200 - 428 RF200 v3.73 (c) 2002 Scott Baxter
PN Scanners
Why PN scanners? Because phones cant
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
Grayson Wireless
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
September, 2002 RF200 - 429 RF200 v3.73 (c) 2002 Scott Baxter
Post-Processing Tools
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
Grayson Interpreter
Imports/analyzes data from Grayson
Wireless Inspector, Illuminator, and
Invex3G
Agilent OPAS32
Imports/analyzes a variety of data
Nortel RF Optimizer
Can merge/analyze drive-test and
Nortel CDMA system data
Wavelink
Comarco "Workbench" Tool
Verizon/Airtouch internal tool
OPAS32
COMARCO
September, 2002 RF200 - 430 RF200 v3.73 (c) 2002 Scott Baxter
Data Flow Management:
MAC/LAC Layer Operation
Data Flow Management:
MAC/LAC Layer Operation
Course RF200
September, 2002 RF200 - 431 RF200 v3.73 (c) 2002 Scott Baxter
System MAC/LAC Parameters
The answers to all these questions
are determined by MAC & LAC layer
processes and parameters
Each network manufacturer
implements some subset of the
MAC/LAC states and parameters
specified in the IS-2000 standard
Each manufacturer has its own
unique parameter set to control state
transitions
Most networks begin operation using
manufacturer-recommended defaults
as networks and applications
mature, parameters will be fully
optimized
A basic knowledge of the
manufacturers proprietary
parameters gives very useful
insights into configuration and
performance issues
T_active or
Release
Initialization
Null
Reconnect
Dormant
Control Hold
Suspended
Packet Service
Request
Packet Service
Deactivated
PPP Terminated
Release Sent!
PPP Terminated
Release Sent!
Service Option
Connected
Control Channel Exists
Service Option
Connected
Control Channel
Exists
Traffic channel
Exists
Active
T_hold
Control Channel
exists
T_suspend
Have New Data
to send!
How is data flow managed?
Can I keep my FCH all the time?
Will my connection drop in a fade?
When is an SCH turned on for me?
How long will my SCH burst last?
What is the data rate of my SCH?
If I cant get a full-rate SCH, can I at
least get a lower-rate SCH?
Which kinds of traffic have priority?
Do some users have higher priority?
September, 2002 RF200 - 432 RF200 v3.73 (c) 2002 Scott Baxter
MAC States
State
R-CCCH
R-EACH
F-TRAFFIC
F-FCH
F-SCH
R-TRAFFIC
R-FCH
R-SCH
SCH driven
by traffic
SCH driven
by traffic
F-TRAFFIC R-TRAFFIC
intermittent
F-DCCH R-DCCH
CE SEL
t1
R-P Interface
PDSN/
Foreign
Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/
Access Manager
CE SEL
t1
R-P Interface
PDSN/
Foreign
Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/
Access Manager
CE SEL
t1
R-P Interface
PDSN/
Foreign
Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/
Access Manager
SEL
t1
R-P Interface
PDSN/
Foreign
Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/
Access Manager
PAGING
R-CCCH
R-EACH
PAGING
intermittent
intermittent
Channel
Element
Selector/
Svc Cfg (RLP)
PPP
IP
Session
ACTIVE
exit timer:
a few seconds
CONTROL
HOLD
(Optional State)
exit timer: a few seconds
very fast return to active state
SUSPENDED
(Optional State)
exit timer: a few seconds
between data bursts
DORMANT
exit timer: minutes, hours
between data bursts
September, 2002 RF200 - 433 RF200 v3.73 (c) 2002 Scott Baxter
Forward Link SCH Scheduling
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
CE
SEL
t1
R-P
Interface
PDSN/Foreign Agent
BTS
(C)BSC/Access Manager
Wireless
Mobile Device
data
FCH or
FCH + SCH?
Buffer
BTSC
My F-SCH
Data Rate
PCF
September, 2002 RF200 - 434 RF200 v3.73 (c) 2002 Scott Baxter
Active State: Managing F-FCHs, F-SCHs
Every time a call
enters the active
state, an F-FCH is
set up
at new call setup
at return from
dormant to active
state
Messages are exchanged on access and paging channels to setup F-FCH
FCH setup only occurs if necessary resources are available
Walsh Codes, Forward Power, Reverse Power, backhaul, hardware
If a new F-FCH is blocked because an existing F-SCH is tying up
resources, the existing F-SCH is released early to free-up resources
Networks today give same priority to new F-FCHs -- voice or data
When data packet is finished, Active-to-Dormant timer begins
at end of timer, F-FCH is extinquished and link enters dormant state
but packet session is still maintained!
Dormant
State
Active State Dormant
State
Active State
38.4k
76.8
k
153.6
k
153.6
k
153.6
k
76.8
k
Download
T
ACC
T
ACC
T
DORM
T
NET
+T
QUEUE
+T
SCH
A 1xRTT Web-Browsing Session
F-SCH F-SCH
F-FCH F-FCH
User
Reads
Web Page
September, 2002 RF200 - 435 RF200 v3.73 (c) 2002 Scott Baxter
Forward Link Events in a Typical User Session
1.2
9.6
19.2
38.4
76.8
153.6
0
D
a
t
a

R
a
t
e
,

k
b
p
s
Channel Legend:
Data Idle Data
FundamentalSupplemental
Session begins.
No data, FCH
idle, 1200 bps
Data in PDSN
buffer. Data
flow begins
on FCH
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 in PDSN
buffer. Data
flow begins
on FCH
No data,
FCH idle,
1200 bps
FCH
idle
1200
bps
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.
QOS algorithm
gives SCH to
another user
briefly. Data
meanwhile
flows on FCH.
Data volume in buffer
low, SCH released.
Flow continues on FCH.
No data,
FCH idle,
1200 bps
Active
timer
runs out!
FCH drops.
Session is
dormant.
T
A
Data in PDSN
buffer. Data
flow begins
on FCH
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.
No data,
FCH idle,
1200 bps
Mobile
ends
session.
Init
Null
Rcon
Dorm
CHld
Susp
Act
STATE
September, 2002 RF200 - 436 RF200 v3.73 (c) 2002 Scott Baxter
Lucent MAC/LAC Parameters
The decision to request assignment of an F-SCH or R-SCH is driven by
the amount of data in buffers waiting to be transmitted
the maximum SCH data rate to be requested is set by manual
configuration
FCH and SCH channel allocation in the Lucent BTS is handled by a
software module Supplemental Air Resource Allocation (SARA)
F-SARA and R-SARA manage data rates and durations of bursts on
the forward and reverse links
SARA may assign data rates lower than requested if sufficient
resources are not available to allow the full requested rate
The entire set of algorithms which drive and manage assignment of all
types of traffic channels for all users of a sector are collectively called the
RF Scheduler
Refer to Lucent documentation for individual configurable parameters,
default values, measurements, and configuration guidelines
401-614-039 --- CDMA 3G1X Packet Data Planning and
Implementation Guide
401-614-040 --- 3G1x RF Engineering Guidelines
September, 2002 RF200 - 437 RF200 v3.73 (c) 2002 Scott Baxter
New Lucent 3G 1x Peg Counts/Measurements
Group CDMA-PAF
60: 3G CDMA Intercept Messages
CDMA-PAF-CARR-SC
32: 3G Origination Assigned to a 3G Fundamental Channel
33: 3G Termination Assigned to a 3G Fundamental Channel
34: 3G Origination/Termination Assigned to a 2G Channel
35: 2G Origination/Termination Assigned to a 3G Channel in 2G mode
38: 3G CP-Fail Call Setup Failure Origination
39: 3G CP-Fail Call Setup Failure Termination
CDMA SUBCELL
6: 3G Origination/Termination Overflow
CDMA-PAFF-CARR-RC
1: CDMA calls per radio configuration
ECP-PAF-CARR CDMA
15: 3G Page Response Seizures not resulting in 3G CD assignment
September, 2002 RF200 - 438 RF200 v3.73 (c) 2002 Scott Baxter
More Lucent 3G 1x Peg Counts/Measurements
ECP-PAF-CARR-SC-CDMA
14: 3G Origination Traffic Channel Confirmation Failure
15: 3G Termination Traffic Channel Confirmation Failure
16: 3G Origination denied due to no Packet Pipe Connection
17: 3G Termination denied due to no Packet Pipe Connection
18: 3G Origination Traffic Channel Activation Failure
19: 3G Termination Traffic Channel Activation Failure
20: 3G CDMA Alert Confirmation Failures
21: 3G CDMA Cellular Networking Termination Traffic Channel
Confirmation Failure
22: 3G CDMA Cellular Networking Termination Failure due to
Packet Pipe Connection Failure
23: 3G CDMA Cellular Networking Termination Alert
Confirmation Failure
September, 2002 RF200 - 439 RF200 v3.73 (c) 2002 Scott Baxter
More Lucent 3G 1x Peg Counts/Measurements
ECP-PAF-SC CDMA
3: 3G Origination failed due to no Speech Handler Assignment
received at cell
4: 3G Termination failed due to no Speech Handler
Assignment received at cell
ECP-PAF CDMA
8: 3G Origination Failed due to DCS error
9: 3G Termination Failed due to DCS error
CP CDMA
58: 3G Origination/Termination-Reacquire on Analog from
CDMA
59: 3G Roamer Origination Attempts Denied
60: 3G Origination Denied Error
61: 3G Originations-Reacquire on Analog from CDMA
September, 2002 RF200 - 440 RF200 v3.73 (c) 2002 Scott Baxter
Nortel MAC/LAC Parameters
Helpful Documents:
EBSC Preliminary Engineering Guidelines SPCS January 23
2001.pdf
1xRTT Datafill Presentation rev. 1.1 Nortel Networks CDMA
RF Engineering
411-2133-101 BSC Theory of Operations
411-2133-117 3G Capacity Solutions
411-2133-199 Software Delta for Planners
411-2133-801 Data 3G Capacity Solutions Overview
September, 2002 RF200 - 441 RF200 v3.73 (c) 2002 Scott Baxter
1x Data Tests and Optimization
1x Data Tests and Optimization
Course RF200
September, 2002 RF200 - 442 RF200 v3.73 (c) 2002 Scott Baxter
So S L O W ! ! Wheres My Data?!!
Some sessions are tormented by long latency and slow throughput
Where is the problem? Anywhere between user and distant host:
Is the mobile users 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 operators 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?
I
P

D
a
t
a

E
n
v
i
r
o
n
m
e
n
t
CDMA RF Environment
CDMA IOS PPP Traditional Telephony
IP Data Environment
t1 t1
v
CE SEL
t1
R-P Interface
PDSN/Foreign Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs
PSTN
T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
Coverage Holes
Pilot Pollution
Missing Neighbors
Fwd Pwr Ovld
Rev Pwr Ovld
Search Windows
Island Cells
Slow Handoff
September, 2002 RF200 - 443 RF200 v3.73 (c) 2002 Scott Baxter
Finding Causes of Latency and Low Throughput
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.
I
P

D
a
t
a

E
n
v
i
r
o
n
m
e
n
t
CDMA RF Environment
CDMA IOS PPP Traditional Telephony
IP Data Environment
t1 t1
v
CE SEL
t1
R-P Interface
PDSN/Foreign Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs
PSTN
T T
SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
Coverage Holes
Pilot Pollution
Missing Neighbors
Fwd Pwr Ovld
Rev Pwr Ovld
Search Windows
Island Cells
Slow Handoff
Test
Server
Test
Server
Test
Server
September, 2002 RF200 - 444 RF200 v3.73 (c) 2002 Scott Baxter
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).
HTTP GET A standard web page browse request. If Raw Download is unavailable, testing downlink
throughput; modeling typical customer use.
HTTP POST 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.
Wait Waits a specified amount of time. Testing idle timers, timeouts, etc.
September, 2002 RF200 - 445 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Basic Network Data Test Scenarios
IP tests can be originated from the mobile side to identify & trap problems
Test servers can be positioned where needed in the network
At PDSN FA, at PDSN HA, or at other end of IP or VPN network
Test server standard features should be left naturally enabled:
Discard/Sync/Null (server throws away data sent to it)
Char Gen (server can send randomly generated data to test mobile)
Echo (server can loopback all data received from the test mobile)
Ping (server will respond to pings sent from the test mobile)
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 446 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Task: Connect
Connect process functions
no user packet data is sent; connection is merely established
sets up PPP data session from User to PDSN FA
sets up packet tunneling relationship between FA and HA
HA assigns external IP address for mobiles connection
Connection is the first step in any packet data operation
test connections are useful for troubleshooting IP network
configuration or resource issues
Collected statistics include total connects, # failed, # dropped
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 447 RF200 v3.73 (c) 2002 Scott Baxter
Data Task: Ping
The Ping task tests server connectivity
Provides # Total Pings, # pings lost, round trip latency
By pinging test servers at various points in the network, the
sources of excessive delay can be identified
intermittent latency due to traffic congestion can be identified
by variation in ping responses involving a single test server
Network View Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 448 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Task: Raw Download
Raw Downloads are the best way to measure the throughput capability of
the forward link
a fixed quantity of random data is requested from the test server by
the mobile
the speed of the download is limited by channel capacity and
congestion at any controlling bottlenecks
by performing downloads from servers located at various places in the
network, the location of capacity bottlenecks can be identified
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 449 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Task: Raw Upload
Raw Uploads are the best way to measure the throughput capability of the
reverse link
a fixed quantity of random data is requested sent to the test server by
the mobile
the speed of the upload is limited by channel capacity and congestion
at any controlling bottlenecks
by performing uploads to test servers located at various places in the
network, the location of capacity bottlenecks can be identified
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 450 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Task: Http GET
Http GET file transfers are the method used to download web
pages during internet browsing
There are certain types of IP problems which may not appear
during raw downloads but which will affect HTTP GET transfers
by performing GETS from servers at different places in the
network, the location of any GET-specific problems can be
identified
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 451 RF200 v3.73 (c) 2002 Scott Baxter
Data Task: Http POST
Http POST file transfers are the method used to upload pages
during internet browsing
There are certain types of IP problems which may not appear
during raw uploads but which will affect HTTP POST transfers
by performing POSTS from servers at different places in the
network, the location of any POST-specific problems can be
identified
Protocol Stack View
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Network View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 452 RF200 v3.73 (c) 2002 Scott Baxter
Data Task: Ftp GET
FTP GET file transfers are the most common method of download data
file transfers between servers in IP networks
There are certain types of IP problems which may not appear during
raw downloads but which will affect FTP GET transfers
by performing GETs from test servers at different places in the
network, the location of any FTP-specific problems can be identified
Most data collection tools will allow you to configure the usernames
and passwords required for the FTP transactions so the tests can
proceed automatically without requiring manual intervention
Protocol Stack View
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Network View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 453 RF200 v3.73 (c) 2002 Scott Baxter
Data Task: Ftp PUT
FTP PUT file transfers are the most common method of upload data file
transfers between servers in IP networks
There are certain types of IP problems which may not appear during
raw downloads but which will affect FTP PUT transfers
by performing PUTs to test servers at different places in the network,
the location of any FTP-specific problems can be identified
Most data collection tools will allow you to configure the usernames
and passwords required for the FTP transactions so the tests can
proceed automatically without requiring manual intervention
Protocol Stack View
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Network View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 454 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Task: Wait
The WAIT task allows testing of data session survival without
sending any data
for example, the lengths of various state timers can be
independently verified
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 455 RF200 v3.73 (c) 2002 Scott Baxter
Protocol-Layer-Specific Data
Protocol-Layer-Specific Data
Course RF200
September, 2002 RF200 - 456 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 457 RF200 v3.73 (c) 2002 Scott Baxter
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
September, 2002 RF200 - 458 RF200 v3.73 (c) 2002 Scott Baxter
Mobile Tool IP Throughput Calculations
Application Throughput Calculation
Raw Upload TX Payload: all data (no headers or overhead)
TX Transfer Time: from first byte sent to last byte sent
Raw Download RX Payload: all data (no headers or overhead)
RX Transfer Time: from first byte received to last byte received
Raw Loopback RX Payload: all data (no headers or overhead)
RX Transfer Time: from first byte received to last byte received
TX Payload: all data (no headers or overhead)
TX Transfer Time: from first byte sent to last byte sent
Ping (ICMP ECHO) Ping sends a small packet and waits for a response packet, so throughput is not applicable.
HTTP GET TX Payload: HTTP GET request
TX Transfer Time: from first request byte sent to last request byte sent
RX Payload: HTTP response, including headers (since they are an integral part of the data)
RX Transfer Time: from first response byte received to last response byte received
HTTP POST TX Payload: HTTP POST request, which includes the header. The header is accounted for such that the payload is
equal to the amount of data specified in the task configuration.
TX Transfer Time: from first byte of request sent to last byte of request sent
FTP GET RX Payload: The file data (the user login, changing directories, etc., are not included)
RX Transfer Time: from first byte of the file received to last byte of the file received
FTP PUT TX Payload: The file data (the user login, changing directories, etc., are not included)
TX Transfer Time: from first byte of the file sent to last byte of the file sent
Mail GET (POP3) RX Payload: The e-mail messages including headers (like the To, From, and Subject fields) and the bodies
(message text or attachments). The user login and overhead necessary to retrieve e-mails is not included.
RX Transfer Time: from the first byte of the first e-mail received to the last byte of the last e-mail received.
Mail PUT (SMTP) TX Payload: the e-mail message body. The user login and overhead necessary to send an e-mail is not included.
TX Transfer Time: from the first byte of the e-mail sent to the last byte of the e-mail sent.
Mail PUT (SMTP) TX Payload: the e-mail message body. The user login and overhead necessary to send an e-mail is not included.
TX Transfer Time: from the first byte of the e-mail sent to the last byte of the e-mail sent.
Wait Not Applicable
September, 2002 RF200 - 459 RF200 v3.73 (c) 2002 Scott Baxter
TCP Application Flow and Timing
Measurements
Test equipment tools include software for
automatically attempting IP connections
Processes can be automatically
measured for performance
Throughput
Peak
average
Latency
Minimum
Average
Peak
Tests can be conducted end-to-end at
various levels of the protocol stack
Send Connect
Request
Connect
Response
Received?
Start
Timeout?
Transfer Data
(Application-Specific)
Send Terminate
Request
Terminate
Response
Received?
Timeout?
Finish
Application
throughput amount
and timing begins
and ends within
this block
Task Timing Ends Here
Task Timing Begins Here
September, 2002 RF200 - 460 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Measurement: TCP Throughput
Transmission Control Protocol (TCP) is a connection-oriented, end-to-end
reliable protocol above IP but below upper layer applications
TCP causes packets to be resent if not acknowledged
TCP provides reliable logical connections between sockets
TCP benefits come at a cost: increased control octets on each packet sent
TCP throughput is normally larger than the upper layer payload
on poor quality links where packet retransmission is frequent, TCP
throughput will be much larger than the upper layer throughputs
Most 1x drive test data collection equipment can display TCP throughput
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 461 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Measurement: ICMP Throughput
Internet Control Message Protocol (ICMP) is a part of the larger Internet
Protocol used for reporting certain types of errors and for basic testing
There are more than a dozen types of ICMP messages which can be
collected with a protocol analyzer and used to investigate IP problems
within a network
Most 1xRTT mobile data collection tools can display ICMP throughput
ICMP throughput is normally zero; significant ICMP throughput can
indicate the presence of IP network or configuration problems
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 462 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Measurement: IP Throughput
Internet Protocol (IP) is below upper layer (application) protocols
IP throughput is the content actually processed by lower layers
If IP throughput is substantially larger than the actual application level
throughput, transmission problems or misconfiguration exist
check for excessive packet retransmission due to transmission
problems (RF link problems or other IP problems)
check configuration: is the application protocol appropriate for the type
of data being transmitted?
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 463 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Measurement: PPP Throughput
Point-to-Point Packet (PPP) throughput is the volume of packets
transmitted between peer layer-2 entities in the 1xRTT system
PPP throughput may be higher or lower than the throughput of
other layers, depending on transmission conditions and
configuration
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 464 RF200 v3.73 (c) 2002 Scott Baxter
Network View
Data Measurement: PL Throughput
Physical Layer (PL) throughput is the actual bit content of the
frames carrying information over the 1xRTT links
PL throughput can be higher or lower than the throughput of other
layers depending on configuration and transmission conditions
Protocol Stack View
t1
t1
v
CE
SEL
t1
R-P
PDSN
FA
PDSN HA
AAA
BSC
USER
BTS
SW
IP/VPN
PSTN
A
P
P
L
L
A
C
P
L
I
C
F
P
L
D
C
F
P
L
D
C
F
M
U
X
/
Q
O
S
SYSTEM
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Frames
MOBILE
Inst 3
L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2
User Pkts
Inst 1
Voc Bits
IS95
L2
Sig
1x
L2
Sig
Other
L2
Sig
Pkt
Data
L2
Null
L2
Ckt
Data
L2
IS95
L3
Sig
1x
L3
Sig
Other
L3
Sig
Pkt
Data
Svc
Voice
Svc
Ckt
Data
Svc
Test
Server
Test
Server
Test
Server
Backbone
September, 2002 RF200 - 465 RF200 v3.73 (c) 2002 Scott Baxter
MultiCarrier Operation:
Big-Picture View of Frequency Changes
MultiCarrier Operation:
Big-Picture View of Frequency Changes
Course RF200
September, 2002 RF200 - 466 RF200 v3.73 (c) 2002 Scott Baxter
A CDMA network with 5 carriers
September, 2002 RF200 - 468 RF200 v3.73 (c) 2002 Scott Baxter
Many Network/Carrier Configurations are Possible!
f1
f2
f3
f4
Basic Multi-Carrier
Operation
IS-95
IS-95
IS-95
IS-95
f1
f2
f3
f4
Non-originating carriers
can carry more traffic!
IS-95
IS-95
IS-95
IS-95
f1
f2
f3
f4
Some Carriers may
support 1xRTT
1xRTT
IS-95
IS-95
IS-95
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
W
0



P
i
l
o
t
w
3
2
S
y
n
c
w
1
P
a
g
i
n
g
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a

D
a
t
a
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
3
2
S
y
n
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
a


T
r
a
f
f
i
c
w
x


T
r
a
f
f
i
c
w
y


T
r
a
f
f
i
c
w
z


T
r
a
f
f
i
c
w
b


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
w
c


T
r
a
f
f
i
c
w
d


T
r
a
f
f
i
c
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
W
0



P
i
l
o
t
w
1
P
a
g
i
n
g
w
1
P
a
g
i
n
g
September, 2002 RF200 - 469 RF200 v3.73 (c) 2002 Scott Baxter
Review of the 1xRTT Radio Link
Review of the 1xRTT Radio Link
Course RF200
September, 2002 RF200 - 470 RF200 v3.73 (c) 2002 Scott Baxter
CDMAone CDMA2000/IS-2000
The CDMA Technology Path to 3G
Technology
Generation
Signal
Bandwidth,
#Users
Features:
Incremental
Progress
1G
AMPS
Data
Capabilities
30 kHz.
1
First
System,
Capacity
&
Handoffs
None,
2.4K by
modem
2G
IS-95A/J-Std008
1250 kHz.
20-35
First CDMA,
Capacity,
Quality
14.4K
2G
IS-95B
1250 kHz.
25-40
Improved
Access
Smarter
Handoffs
64K
2.5G or 3?
IS-2000:
1xRTT
1250 kHz.
50-80 voice
and data
Enhanced
Access
Channel
Structure
153K
307K
230K
3G
1xEV:
HDR or
1Xtreme
1250 kHz.
Many packet
users
Faster data
rates on
dedicated
1x RF data
carrier
2.4 Mb/s
(HDR)
5 Mb/s
(1Xtreme)
3G
IS-2000:
3xRTT
F: 3x 1250k
R: 3687k
120-210 per
3 carriers
Faster data
rates on
shared 3-
carrier
bundle
1.0 Mb/s
September, 2002 RF200 - 471 RF200 v3.73 (c) 2002 Scott Baxter
A Story of Two Hotels
A sector on an IS-95 CDMA BTS
runs like a discount hotel today
There's a Sign outside, a
covered entranceway, Lobby
Only Two kinds of rooms:
one king bed or two doubles
There are no meeting rooms
or ballrooms
New 1xRTT CDMA BTS sectors
are like a convention resort!
Twice as big in square feet
Sign, Entranceway, Lobby
Restaurants, Bars, Nightclub
Guest rooms: one king bed
or two doubles, maybe suites
Meeting Rooms with
adjustable walls -- for use as
Classrooms, Auditorium,
Ballrooms, Banquets,
Parties, Meetings
BTS
PILOT
SYNC
PAGING
TRAFFIC
ACCESS
TRAFFIC
F-TRAFFIC
BTS
F-Pilot
F-Sync
PAGING
F-BCH
F-QPCH
F-CPCCH
F-CACH
F-CCCH
F-DCCH
F-FCH
F-SCH
F-SCH
R-TRAFFIC
R-Pilot
R-CCCH
R-DCCH
R-FCH
R-SCH
R-EACH
R-ACH or
September, 2002 RF200 - 472 RF200 v3.73 (c) 2002 Scott Baxter
Spreading Rates & Radio Configurations
Radio
Configuration
RC1
RC2
RC3
RC4
RC5
RC6
RC7
RC8
RC9
Spreading
Rate
SR1
1 carrier
1.2288
MCPS
SR3
3.6864
MCPS
as
3 carriers
1.2288
MCPS
Forward Link
Required. IS-95B Compatible
No CDMA2000 coding features
Compatible with IS-95B RS2
No CDMA2000 coding features
Quarter-rate convolutional or
Turbo Coding, base rate 9600
Half-rate convolutional or
Turbo Coding, base rate 9600
Quarter-rate convolutional or
Turbo Coding, base rate 14400
1/6 rate convolutional
or Turbo coding, base rate 9600
Required. 1/3 rate convolutional
or Turbo coding, base rate 9600
or 1/3 rate convolutional or
Turbo coding, base rate 14400
or 1/3 rate convolutional or
Turbo encoder, base rate 14400
9600
variable
14400
variable
9600
153600
9600
307200
14400
230400
9600
307200
9600
614400
14400
460800
14400
1036800
Reverse Link
rate conv or Turbo coding, 9600
rate conv or Turbo coding, 9600
rate convolutional or
Turbo Coding, base rate 14400
Required. or 1/3 convolutional
Or Turbo coding, base rate 9600
or convolutional or Turbo
encoding
9600
153600
307200
14400
230400
9600
307200
614400
14400
460800
1036800
Required. IS-95B Compatible
No CDMA2000 coding features
Compatible with IS-95B RS2
No CDMA2000 coding features
9600
variable
14400
variable
Data
Rates
Data
Rates
Radio
Configuration
RC1
RC2
RC3
RC4
RC5
RC6
September, 2002 RF200 - 473 RF200 v3.73 (c) 2002 Scott Baxter
2G Today: IS-95 CDMA Channels
Existing IS-95A/JStd-008 CDMA offers one radio configuration
using just the channels shown above
IS-2000 CDMA is backward-compatible with this IS-95, but offers
additional radio configurations with additional channels
These additional modes are called Radio Configurations
IS-95 Rate Set 1 and 2 are IS-2000 Radio Configurations 1 & 2
FORWARD CHANNELS REVERSE CHANNELS
BTS
W0: PILOT
W32: SYNC
W1: PAGING
Wn: TRAFFIC
ACCESS
TRAFFIC
September, 2002 RF200 - 474 RF200 v3.73 (c) 2002 Scott Baxter
Big Improvements in 1xRTT!
More flexible channels available:
the FUNDAMENTAL Channel (FCH) carries Voice and/or Low Speed
Data just like today
New SUPPLEMENTAL Channel (SCH) carries high-speed data
High-speed data channels allocated on a burst-by-burst basis
Raw rates of 19.2, 38.4, 76.8, and 153.6 kbps and higher
Independent Forward and reverse supplemental channel rates
Airlink Dormant State is supported
voice on fundamental channel possible while dormant!
There's a new 4 state MAC protocol to increase efficiency
Signaling can be either on
Fundamental Channel (FCH) [bearer profile P1], or
Dedicated Control (DCCH) [bearer profile P2]
Reverse Pilot Channel (RPCH) improves link budget margin
Fast Forward Power Control
old IS-95 max was 50 Hz, new speed is constant 800 Hz!
Enhanced Access procedures increase occupancy, more efficient
September, 2002 RF200 - 475 RF200 v3.73 (c) 2002 Scott Baxter
CDMA2000 SR1 CDMA Channels
Not all of these channels will be
implemented immediately, and
some may not be supported in
commercial use any time soon.
All are defined in the Standard
and have useful purposes and
advantages
Dedicated
Control Channel
Same coding as IS-95B,
Backward compatible
Same coding as IS-95B,
Backward compatible
Same coding as IS-95B,
Backward compatible
Broadcast Channel
Quick Paging Channel
Common
Power Control Channel
Common
Assignment Channel
Common
Control Channels
Forward
Traffic Channels
Fundamental Channel
Supplemental
Channels IS-95B only
Supplemental
Channels RC3,4,5
Includes Power
Control Subchannel
Enhanced
Access Channel
Common
Control Channel
Dedicated
Control Channel
Reverse Fundamental
Channel (IS95B comp.)
Reverse
Supplemental Channel
Access Channel
(IS-95B compatible)
F-TRAFFIC
BTS
FORWARD CHANNELS
F-Pilot
F-Sync
PAGING
F-BCH
F-QPCH
F-CPCCH
F-CACH
F-CCCH
F-DCCH
1
1
1 to 7
0 to 8
0 to 3
0 to 4
0 to 7
0 to 7
0 or 1
F-FCH
F-SCH
F-SCH
0 to many
1
0 to 7
0 to 2
IS-95B only
R-TRAFFIC
REVERSE CHANNELS
R-Pilot
R-CCCH
R-DCCH
R-FCH
R-SCH
R-EACH
1
1
0 or 1
0 or 1
0 to 2
R-ACH or
1
September, 2002 RF200 - 476 RF200 v3.73 (c) 2002 Scott Baxter
Walsh Code Utilization in 1xRTT
9,600
4,800
2,400
307200
sps
153,600
76,800
38,400
19,200
Code#
Code#
Code#
Code#
Code#
Code#
1
2
8

b
i
t
s
4

b
i
t
s
8

b
i
t
s
1
6

b
i
t
s
3
2

b
i
t
s
6
4

b
i
t
s
Code#
Code#
Code#
Code#
Code#
Code#
7 3 5 1 6 2 4 0
3 1 2 0
15 7 11 3 13 5 9 1 15 6 10 2 12 4 8 0
31 15 23 7 27 11 19 3 29 13 21 5 25 9 17 1 30 14 22 6 26 10 18 2 28 12 20 4 24 8 16 0
5
4
1
2
7
6
3
9
5
3
1
1
1
1
4
7
7
9
1
5
1
1
9
5
5
8
7
2
3
1
0
3
3
9
7
1 7
1
2
3
5
9
9
1
2
7
1
0
7
4
3
7
5
1
1
1
1
5
5
1
8
3
1
9
9
9
3
5
6
7 3
1
2
5
6
1
9
3
2
9
1
0
9
4
5
7
7
1
3
1
1
7
5
3
8
5
2
1
1
0
1
3
7
6
9 5
1
2
1
5
7
8
9
2
5
1
0
5
4
1
7
3 9
1
1
3
4
9
8
1
1
8
9
7
3
3
6
5 1
1
2
6
6
2
9
4
3
0
1
1
0
4
6
7
8
1
4
1
1
8
8
6
2
2
1
0
2
3
8
7
0 6
1
2
2
5
8
9
0
2
6
1
0
6
4
2
7
4
1
0
1
1
4
5
0
8
2
1
8
9
8
3
4
6
6 2
1
2
4
6
0
9
2
2
8
1
0
8
4
4
7
6
1
2
1
1
6
5
2
8
4
2
0
1
0
0
3
6
6
8 4
1
2
0
5
6
8
8
2
4
1
0
4
4
0
7
2 8
1
1
2
4
8
8
0
1
6
9
6
3
2
6
4 0
0
3
2
1
6
4
88
4
0
2
4
5
64
3
6
2
0
5
2
1
2
4
4
2
8
6
02
3
4
1
8
5
0
1
0
4
2
2
6
5
86
3
8
2
2
5
4
1
4
4
6
3
0
6
21
3
3
1
7
4
99
4
1
2
5
5
75
3
7
2
1
5
3
1
3
4
5
2
9
6
13
3
5
1
9
5
1
1
1
4
3
2
7
5
97
3
9
2
3
5
5
1
5
4
7
3
1
6
3
Q
P
C
H
Q
P
C
H
Q
P
C
H
T
X

D
i
v
P
I
l
o
t
1
9
.
2
k
P
a
g
i
n
g

7
P
a
g
i
n
g

3
P
a
g
i
n
g

5
P
a
g
i
n
g
P
C
H

6
P
C
H

2
P
C
H

4
S
y
n
c
P
i
l
o
t
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
76.8
ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
153.6 ksps
F-SCH
307.2 ksps
F-SCH
307.2 ksps
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
3
8
.
4
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
1
9
.
2
k
September, 2002 RF200 - 477 RF200 v3.73 (c) 2002 Scott Baxter
Reverse Channel Walsh Code Trees
0
0
15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0
7 3 5 1 6 2 4 0
0 2 1 3
1
R-SCH1
R-SCH2
R-FCH
R-DCCH
R-Pilot
If a Walsh Code is used,
the other walsh codes
beneath it cannot be used.
September, 2002 RF200 - 478 RF200 v3.73 (c) 2002 Scott Baxter
Understanding the foundation of 3G Networks:
Core 2G CDMA Network Architecture
Access Manager
or (C)BSC
Switch BTS
Ch. Card ACC

TFU1
GPSR
BSM
CDSU
CDSU
SBS
Vocoders
Selectors
CDSU
CDSU
CDSU
CDSU
CDSU
CM SLM
LPP LPP ENET
DTCs
DMS-BUS
Txcvr
A
Txcvr
B
Txcvr
C
RFFE
A
RFFE
B
RFFE
C
TFU
GPSR
GPS
GPS
IOC
PSTN
CDSU DISCO CDSU
DISCO 1
DISCO 2
DS0 in T1
Packets
Chips
RF Vocoder
A vocoder converts
speech between DS-0
and packet forms
The selector
assembles
packets going to
the BTS and
disassembles
packets coming
from the BTS.
A channel element turns
packet bits into CDMA
chips to the mobile, and
chips from the mobile into
packets to the BSC.
Channel
Element
September, 2002 RF200 - 479 RF200 v3.73 (c) 2002 Scott Baxter
Review of 1xRTT Data Networks
Review of 1xRTT Data Networks
Course RF200
September, 2002 RF200 - 480 RF200 v3.73 (c) 2002 Scott Baxter
Existing 2nd Generation CDMA Voice Networks
2nd Generation CDMA Networks were designed primarily to handle voice
The CDMA voice conversations 20-ms frames are carried as packets
between mobile and the Selector
The selector assembles frames being sent to the mobile and
disassembles frames coming from the mobile
Frame contents normally include voice and occasional signaling; may
also include data if additional equipment is included (not shown)
The vocoders in the BSC and the mobile convert the packet stream into
continuous DS-0 audio for the end-users
The MSC makes a circuit-switched connection for call
t1 t1
CIRCUIT-SWITCHED VOICE TRAFFIC
v
CE
SEL
rf
t1
Handset
BTS
(C)BSC or
Access Manager
Switch
PSTN
POINT-TO-POINT PACKETS
14400 bps max
September, 2002 RF200 - 481 RF200 v3.73 (c) 2002 Scott Baxter
Today's Data Turtle Race:
How Data flows on a 2G CDMA Network
Additional hardware is needed to carry data on a 2G network
Data to/from the user connects near the selector in the BSC
Passed through the switch as 56kb/s data links in 64kb/s DS-0s
Data connection to outside world handled by IWF Interworking Function
Includes modems to convert data stream into DS-0 for dial-up uses
Can contain data routers to access IP or PPP networks
May include capability for FAX and other communications modes
t1 t1
v
CE
SEL
t1
Gateway
Server
Internet
VPNs
PSTN
IWF
rf
CIRCUIT-SWITCHED VOICE TRAFFIC
BTS
(C)BSC or
Access Manager
Switch
Backbone
Network
Handset
POINT-TO-POINT PACKETS
PROPRIETARY SLOW IP TRAFFIC
DIAL-UP ACCESS
14400 bps max
September, 2002 RF200 - 482 RF200 v3.73 (c) 2002 Scott Baxter
3G Data Capabilities: 1xRTT CDMA Network
For full-featured data access over a 3G network, a true IP connection must be
established to outside Packet Data Networks
This requires a Packet Data Serving Node
ISP and operator-provided services are provided by external Home
Network and Home Agent servers
Authentication, Authorization, and Accounting provided by external server
The IWF (not shown above) is still maintained to allow old mobiles to use dial-
up and WAP/wireless web keypad access
t1 t1
v
CE
SEL
rf
t1
R-P Interface
fiber - ATM
PDSN
Foreign Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs
PSTN
T T SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
CIRCUIT-SWITCHED VOICE TRAFFIC
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
POINT-TO-POINT PACKETS
FAST IP PACKET TRAFFIC
Fast!
September, 2002 RF200 - 483 RF200 v3.73 (c) 2002 Scott Baxter
1xRTT CDMA Network Element Descriptions
AAA - Authentication, Authorization, and Accounting - may
include both home and broker-provided functions
BSC - Base Station Controller: vocoders and packet router
BTS - Base Transceiver Station
radio equipment
HA - Home Agent, HN - Home Network
IP access for Mobile IP on home and roaming networks
IWF - Interworking Function
provides necessary protocol conversions
MSC - Mobile Switching Center
voice/circuit-switched network hub
PDN - Packet Data Network
private, public, internet packet networks
PDSN - Packet Data Serving Node
routes user data packets to/from destinations
PSTN - Public Switched Telephone Network
VLR - Visitor Location Register
HLR - Home Location Register
t1 t1
v
CE
SEL
t1
R-P Interface
fiber - ATM
PDSN
Foreign Agent
PDSN
Home Agent
Backbone
Network
Internet
VPNs
PSTN
T T SECURE TUNNELS
Authentication
Authorization
Accounting
AAA
CIRCUIT-SWITCHED VOICE TRAFFIC
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
POINT-TO-POINT PACKETS
FAST IP PACKET TRAFFIC
rf
Fast!
September, 2002 RF200 - 484 RF200 v3.73 (c) 2002 Scott Baxter
Simple IP Architecture
In a Simple IP network, the mobile is able to connect to the external
packet networks directly through the PSTN attached to the local BSC
The IP address for the internet connection is assigned by the local
PDSN from the pool of addresses available to it
If the mobile moves into a different network, the data session ends
The mobile can establish an entirely new connection through the
new network, if desired
t1 t1
v
CE
SEL
t1
R-P Interface
PDSN
PSTN
T
Authentication
Authorization
Accounting
AAA
CIRCUIT-SWITCHED VOICE TRAFFIC
BTS
(C)BSC/Access Manager
Switch
Wireless
Mobile Device
POINT-TO-POINT PACKETS
FAST IP PACKET TRAFFIC
Simple IP
IP Based
transport to
data networks
Dynamic/static
connection
from local
PDSN
No mobility
beyond serving
PDSN
Internet
VPNs
rf
Fast!
September, 2002 RF200 - 485 RF200 v3.73 (c) 2002 Scott Baxter
Mobile IP and Secure Tunneling: Mail Analogy
Most mobile users will want
mobility
ability to roam on other
networks
Same connection details
and method everywhere
Mobile IP is a packet-
forwarding arrangement
mobile user can move
among various networks
Can send and receive
packets just as if in home
location
158766
158767
158768
158769
158770
158771
158772
158773
158774
158775
158776
158778
158779
158780
158781
158782
158783
158784
158785
158786
158787
158788
158789
158790
158791
158792
158793
158794
158795
158796
158797
F
e
d
E
x
F
e
d
E
x
Secure Tunneling
Forward and Reverse
Encapsulation
Home
Agent
Foreign
Agent
Mobile
User
This box is the
mobile user's
Postal address
My mail,
Just like
Home!
September, 2002 RF200 - 486 RF200 v3.73 (c) 2002 Scott Baxter
Multi-Market Mobile IP Network
PSTN PSTN PSTN
Regional
Data
Center
Internet
Private IP
Networks
Operator's Private Network
PDSN
FA
Switch
BSC
PDSN
FA
Switch
Access
Mgr.
PDSN/FA
Switch
CBSC
PCF
RP Interface
RP
RP
Voice Voice Voice
IP Data IP Data IP Data
Home
Agent
Home
Agent
Nortel System Lucent System Motorola System
September, 2002 RF200 - 487 RF200 v3.73 (c) 2002 Scott Baxter
Mobile IP: Three Levels of Mobility
PDSN
(FA)
Mobile
Client
Pal
m
To be or
not to be.
That is
the
Question.
HA
PDSN
(FA)
PDSN
(FA)
Radio Network
(PCF)
M-IP
R-P
Interface
PPP
I. Usual Cellular Mobility II. PCF to PDSN Mobility III. IP Level Mobility
1
2
3
(Simple IP Mobility)
Radio Network
(PCF)
Radio Network
(PCF)
September, 2002 RF200 - 488 RF200 v3.73 (c) 2002 Scott Baxter
Mobile IP Session, Step-by-Step (1)
1. The mobile station accesses the radio network for a data session. This includes
getting the necessary fundamental and supplemental traffic channel. Procedures
for this need is defined in IS-2000 and IS-707.
2. The BSC communicates over the RP interface as defined in IOS version 4.0, with
the PDSN to initiate a data session. The underlying lower layers will support the
PPP connection.
3. The PDSN initiates a PPP connection to the mobile station. Messages and
procedures for this in based on the Point-to-Point Protocol RFC1661.
4. IPCP based on RFC1332 is used to configure the PPP link for IP communication.
PPP can support other network layer protocols in addition to IP
5. PPP is established between the Mobile Station and the PDSN. The PDSN sends
FA advertisements to the mobile station. (Or the mobile station may send an
Agent Solicitation message following the PPP initialization.) The PDSN/FA
informs the mobile station of its capabilities and care-of-addresses that are
available for use. In these advertisement messages, the PDSN will indicate its
ability to support reverse tunneling, that is used to download information from the
HA to the FA.
6. Mobile station sends a MIP registration request (MIP RRQ) to the PDSN. This
request has to be forwarded to the users HA so that the HA is made aware of the
users location. In these registration requests, the mobile station can also specify
reverse tunneling.
7. The PDSN extracts authentication information from the request and forwards to
the local AAA server using Radius Protocol. The PDSN may also request for user
profile for the users Home Agent address.
September, 2002 RF200 - 489 RF200 v3.73 (c) 2002 Scott Baxter
Mobile IP Session, Step-by-Step (2)
8. The local AAA server verifies the NAI and password and returns an
acknowledgement to the PDSN.
9. The Foreign Agent (FA) function in the PDSN sends the MIP registration
request message to the Home Agent
10. The home agent sends a response back to the PDSN(FA). Message
formats and procedures are based on RFC2002 IP Mobility Support.
The reply will include indication on whether the HA can support forward
and reverse tunneling.
11. The PDSN sends the registration reply to the mobile station. Accounting
is initiated to AAA server based on RFC 2139 standards.
12. Data flow between mobile station and PDSN. Interim accounting data
may be collected and forwarded to the AAA server.
13. Mobile station terminates data/PPP connection by sending MIP de-
registration request using procedures in RFC2002 PPP connection is torn
down. Accounting is suspended
14. During the session PDSN collects statistics relevant to the session and
forwards to the AAA server in a Usage Data Record (UDR) format
September, 2002 RF200 - 490 RF200 v3.73 (c) 2002 Scott Baxter
A Refresher on CDMA Basics
A CDMA Cell Loading Example
CDMA Web and Book Resources
A Refresher on CDMA Basics
A CDMA Cell Loading Example
CDMA Web and Book Resources
RF200: Appendix
September, 2002 RF200 - 491 RF200 v3.73 (c) 2002 Scott Baxter
CDMA Basics for Performance Optimizers
If you're new to CDMA, it may seem like a strange new world!
To optimize CDMA systems effectively, you need to know a little
about each of the following areas:
The processing gain that comes to CDMA because of its
spread-spectrum nature
The basic RF structure of a CDMA signal
The code channels inside a CDMA signal that are used to set
up calls and carry information during a call
What happens on each channel
Basic internal organs of a CDMA mobile and their roles
Basic functional blocks of a CDMA system and their roles
These key core basic ideas are highlighted in the following slides
If you want more detail, you can get it from the RF100 course,
or the separate modules 132, 134, and 136
September, 2002 RF200 - 492 RF200 v3.73 (c) 2002 Scott Baxter
CDMA
Spread Spectrum Ideas
CDMA
Spread Spectrum Ideas
September, 2002 RF200 - 493 RF200 v3.73 (c) 2002 Scott Baxter
CDMA: Using A New Dimension
CDMA at first seems very strange when
compared with 'normal' radio technologies
Every sector of every base station transmits
simultaneously on the same frequency
Not separated onto different frequencies,
and not on different timeslots
The signal of a CDMA BTS sector carries all
its individual channels simultaneously
Not separated into timeslots, not
separated onto different frequencies
All mobiles are transmitting simultaneously
on their own frequency
Not on different frequencies as in FDMA
Not on different timeslots as in TDMA
How is it possible to distinguish the
channels of individual users?!!?
CDMA
The Secret of CDMA
Each CDMA user has a unique code
pattern, different from the code pattern of
any other user in the area. The user's
actual "payload" information bits are
combined with a much faster, yet unique,
"noise" waveform.
At the receiver, the received signal is
combined with the same "noise"
waveform locally generated. What is left
is the user's information bits.
Since all users' noise waveforms are
random compared to each other, the
presence of other users' signals does not
confuse the detection process.
September, 2002 RF200 - 494 RF200 v3.73 (c) 2002 Scott Baxter
Claude Shannon:
The Einstein of Information Theory
The core idea that makes CDMA
possible was first explained by
Claude Shannon, a Bell Labs
research mathematician
Shannon's work relates amount
of information carried, channel
bandwidth, signal-to-noise-ratio,
and detection error probability
It shows the theoretical
upper limit attainable
In 1948 Claude Shannon published his landmark
paper on information theory, A Mathematical
Theory of Communication. He observed that
"the fundamental problem of communication is
that of reproducing at one point either exactly or
approximately a message selected at another
point." His paper so clearly established the
foundations of information theory that his
framework and terminology are standard today.
Shannon died Feb. 24, 2001, at age 84.
SHANNONS
CAPACITY EQUATION
C = B

log
2
[ 1 + ]
S
N
B

= bandwidth in Hertz
C = channel capacity in bits/second
S = signal power
N = noise power
September, 2002 RF200 - 495 RF200 v3.73 (c) 2002 Scott Baxter
The Mechanics of DSSS Spreading:
Viewed as Waveforms in Time
At Originating Site:
Input A: Users Data @
19,200 bits/second
Input B: Walsh Code #23
@ 1.2288 Mcps
Output: Spread
spectrum signal
At Destination Site:
Input A: Received
spread spectrum signal
Input B: Walsh Code #23
@ 1.2288 Mcps
Output: Users Data @
19,200 bits/second just
as originally sent
Drawn to actual scale and time alignment
via air interface
XOR
Exclusive-OR
Gate
1
1
Input A: Received Signal
Input B: Spreading Code
Output: Users Original Data
Input A: Users Data
Input B: Spreading Code
Spread Spectrum Signal
XOR
Exclusive-OR
Gate
Originating Site
Destination Site
September, 2002 RF200 - 496 RF200 v3.73 (c) 2002 Scott Baxter
Bits, Symbols, and Chips
Not All 'Bits' are Equally Famous and Important
The raw information is in the form of bits
Bits are protected by error-correcting redundant
coding, producing a bigger population of more-
rugged 1s and 0s called symbols
The symbols are combined with individual 1s and
0s of CDMA codes - these are called chips
Building a
Building a
CDMA Signal
CDMA Signal
Bits
from Users Vocoder
Symbols
Chips
Forward Error
Correction
Coding and
Spreading
Sector's
Unique
Code
RF
Modulation
User Bits Protection
Channel Code
S
u
m
m
i
n
g
These
are Bits
These are
Symbols
These are
Chips
Example:
Forward Link Construction
September, 2002 RF200 - 497 RF200 v3.73 (c) 2002 Scott Baxter
Direct-Sequence Spreading
Viewed as Frequency Spectra
Traditional technologies try
to squeeze a user's signal
into a minimum required
bandwidth
CDMA uses larger
bandwidth but exploits the
resulting processing gain to
get capacity
Spread Spectrum Payoff:
Processing Gain
Spread Spectrum
TRADITIONAL COMMUNICATIONS SYSTEM
Slow
Information
Sent
TX
Slow
Information
Recovered
RX
Narrowband
Signal
SPREAD-SPECTRUM SYSTEM
Fast
Spreading
Sequence
Slow
Information
Sent
TX
Slow
Information
Recovered
RX
Fast
Spreading
Sequence
Wideband
Signal
September, 2002 RF200 - 498 RF200 v3.73 (c) 2002 Scott Baxter
The CDMA Spread Spectrum Payoff:
Would you like a lump-sum, or monthly payments?
Shannon's work suggests that a certain
bit rate of information deserves a
certain bandwidth
If one CDMA user is carried alone by a
CDMA signal, the processing gain is
large - roughly 21 db for an 8k vocoder.
Each doubling of the number of
users consumes 3 db of the
processing gain
Somewhere above 32 users, the
signal-to-noise ratio becomes
undesirable and the ultimate
capacity of the sector is reached
Practical CDMA systems restrict the
number of users per sector to ensure
processing gain remains at usable
levels
# Users Processing Gain
1 21 db
2 18 db
4 15 db
8 12 db
16 9 db
32 6 db
64..Uh, Regis, can I just
take the money I've already
won, and go home now?
CDMA Spreading Gain
Consider a user with a 9600
bps vocoder talking on a
CDMA signal 1,228,800 hz
wide. The processing gain is
1,228,800/9600 = 128, which
is 21 db. What happens if
additional users are added?
September, 2002 RF200 - 499 RF200 v3.73 (c) 2002 Scott Baxter
Practical CDMA: How it Works
From an Operating Perspective
Practical CDMA: How it Works
From an Operating Perspective
September, 2002 RF200 - 500 RF200 v3.73 (c) 2002 Scott Baxter
SWITCH &
BSC or
ACCESS
MANAGER
MOBILE BASE STATION
Building Forward Link Channels in the System
Forward Link CDMA signal includes channels of many users
Each users signal bits are scrambled for privacy and randomness
Each users signal is mixed with a unique Walsh code at the BTS
The entire signal of the sector is mixed with the Short PN code, but it has a
unique timing delay (PN offset) different from any other nearby sector
The mobile decodes in the opposite order to extract its proper channel
PILOT
PAGING
TRAFFIC
SYNC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
DATA
SCRAMBLING
MESSAGES
traffic
traffic
traffic
traffic
MESSAGE
traffic
traffic
traffic
traffic
DATA
SCRAMBLING
DATA
SCRAMBLING
DATA
SCRAMBLING
DATA
SCRAMBLING
DATA
SCRAMBLING
DATA
SCRAMBLING
DATA
SCRAMBLING
DATA
SCRAMBLING
DATA
SCRAMBLING
+
+
+
+
+
+
+
+
+
+
+
SHORT
PN CODE
Special
Offset
I Q

A
n
a
l
o
g

S
u
m
m
i
n
g

B
u
s
Different
Walsh
Codes
QPSK RF
Modulation
Receiver
RF
Section
SHORT
PN CODE
Filter
WALSH
CODE
Filter
Decoding,
DeScrambling
RF from everywhere
this sector only
this user only
scrambled
by users
Different
Long Codes
F1
T
1




w
i
t
h

p
a
c
k
e
t

p
i
p
e
s
September, 2002 RF200 - 501 RF200 v3.73 (c) 2002 Scott Baxter
MOBILE BASE STATION
Recovering One Mobiles Signal at a BTS
All mobiles transmit on the reverse link
Each mobile has its own long code PN offset which keeps its signal unique
At the BTS, a channel element recovers the signal from one mobile and
extracts the symbols and bits it is transmitting
The bits are transmitted as a packet over the T-1 to the switch, where they
are de-vocoded into DS-0 format and passed through the switch to the user
ACCESS
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
TRAFFIC
D
i
s
t
r
i
b
u
t
i
o
n

B
u
s
Different
Long Code Offsets
to match mobiles
BTS RF
Receiver
Xmtr.
RF
Section
LONG
PN CODE
WALSH
Symbol
Encoding
Data
Protection
F1
SHORT
PN 0 I&Q
SWITCH &
BSC or
ACCESS
MANAGER
traffic
traffic
traffic
traffic
traffic
traffic
traffic
traffic
T
1




w
i
t
h

p
a
c
k
e
t

p
i
p
e
s
P
a
c
k
e
t

H
a
n
d
l
e
r
s
September, 2002 RF200 - 502 RF200 v3.73 (c) 2002 Scott Baxter
Recap: What the Three Codes Do
In Each Direction
The three spreading codes are used in different ways to create the
channels on both the forward and reverse links
A forward channel is the users own Walsh Code, mixed with the Short
Code at the PN offset for that sector
A reverse channel is the mobiles Long Code at its own unique offset.
Inside it, the walsh codes are used as symbols for the actual information.
The short code is used, but at PN offset 0, just to do QPSK modulation.
BTS
WALSH CODE: Individual User
SHORT PN OFFSET: Sector
LONG CODE OFFSET:
individual handset
FORWARD CHANNELS
REVERSE CHANNELS
LONG CODE:
Data
Scrambling
WALSH CODES:
used as symbols,
making signal rugged
SHORT PN:
used at 0 offset
for tracking
One
Sector
September, 2002 RF200 - 503 RF200 v3.73 (c) 2002 Scott Baxter
Walsh Code Channels
Actual Live-Air CDMA Signal
PILOT
Walsh Code 0
PAGING
Walsh Code 1
SYNC
Walsh Code 32
Various Peoples
TRAFFIC CHANNELS
September, 2002 RF200 - 504 RF200 v3.73 (c) 2002 Scott Baxter
2G Today: IS-95 CDMA Channels
Existing IS-95A/JStd-008 CDMA offers one radio configuration
using just the channels shown above
IS-2000 CDMA is backward-compatible with this IS-95, but offers
additional radio configurations with additional channels
These additional modes are called Radio Configurations
IS-95 Rate Set 1 and 2 are IS-2000 Radio Configurations 1 & 2
FORWARD CHANNELS REVERSE CHANNELS
BTS
W0: PILOT
W32: SYNC
W1: PAGING
Wn: TRAFFIC
ACCESS
TRAFFIC
Short Code
PN Offset
Mobile ESN-derived
Long Code
PN Offset
BTS-announced
Long Code
PN Offset
September, 2002 RF200 - 505 RF200 v3.73 (c) 2002 Scott Baxter
How a BTS Sector Serves Multiple Users

if 1 =
if 0 =
1
Analog
Summing
Users
QPSK RF

Demodulated
Received
CDMA Signal
Despreading Sequence
(Locally Generated, =0)
matches
opposite
Decision:
Matches!
( = 0 )
Time
Integration
1
Opposite
( =1)
+10
-26
Received energy:
Correlation
-16
BTS
This figure illustrates the basic technique of
CDMA signal generation and recovery.
The actual coding process used in IS-95 CDMA includes
a few additional layers, as well see in following slides.
September, 2002 RF200 - 506 RF200 v3.73 (c) 2002 Scott Baxter
Basic Building Block of Voice Telephony:
The DS-0
The DS-0 is the basic building block of world telephony
Analog voice waveform is sampled 8000 times per second
Each sample is a voltage measurement, reported to a resolution of 8
bits (this allows reporting 256 different voltages)
The data rate is 8 x 8000 = 64,000 bits/second
The data is transmitted digitally over twisted pair or other circuits
At the other end, the data is converted back into voltages
A little bit like childrens connect-the-dots painting
The analog waveform is restored and sent on for the user to hear
The same process runs simultaneously in both directions
Analog Signal
Sampled Data
Each Sample is 8-bit number
8000 samples per second
Delivered Samples
Each Sample is 8-bit number
8000 samples per second
Analog Signal
64,000 bits/second
A D
64,000 bits/second
D A
September, 2002 RF200 - 507 RF200 v3.73 (c) 2002 Scott Baxter
Variable Rate Vocoding & Multiplexing
Vocoders compress speech, reduce bit
rate, greatly increasing capacity
CDMA uses a superior Variable Rate
Vocoder
full rate during speech
low rates in speech pauses
increased capacity
more natural sound
Voice, signaling, and user secondary
data may be mixed in CDMA frames
DSP QCELP VOCODER
Codebook
Pitch
Filter
Formant
Filter
Coded Result
Feed-
back
20ms Sample
Frame Sizes bits
Full Rate Frame
1/2 Rate Frame
1/4 Rt.
1/8
36
72
144
288
Frame Contents: can be a mixture of
Primary
Traffic
(Voice or
data)
Signaling
(System
Messaging)
Secondary
(On-Air
activation, etc)
September, 2002 RF200 - 508 RF200 v3.73 (c) 2002 Scott Baxter
Forward Power Control
The BTS continually reduces the strength of each users forward
baseband chip stream
When a particular handset sees errors on the forward link, it
requests more energy
The complainers chip stream gets a quick boost; afterward,
continues to diminish
Each network manufacturer uses FER-based triggers and initial,
minimum, and maximum traffic channel DGU values
Forward
RF
BSC BTS (1 sector)
Sync
Pilot
Paging
more
Short PN
Trans-
mitter,
Sector X

I Q
User 1
User 2
User 3
Vocoder/
Selector
Help!
September, 2002 RF200 - 509 RF200 v3.73 (c) 2002 Scott Baxter
Reverse Power Control
Three methods work in tandem to equalize all handset signal levels
at the BTS
Reverse Open Loop: handset adjusts power up or down based
on received BTS signal (AGC)
Reverse Closed Loop: Is handset too strong? BTS tells up or
down 1 dB 800 times/second
Reverse Outer Loop: BSC has FER trouble hearing handset?
BSC adjusts BTS setpoint
RX RF
TX RF Digital
BTS BSC
Setpoint
Bad FER?
Raise Setpoint
Stronger than
setpoint?
Reverse
RF
800 bits per second
Occasionally,
as needed
Handset
Open
Loop
Closed
Loop
Digital
September, 2002 RF200 - 510 RF200 v3.73 (c) 2002 Scott Baxter
Details of Reverse Link Power Control
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
cant exceed handsets maximum
(typ. +23 dBm)
TXGA Transmit Gain Adjust
Sum of all closed-loop power
control commands from the BTS
since the beginning of this call
TXPO
DUP x

IF
LNA
Subscriber Handset
R
R
R
S
Rake

Viterbi
Decoder
Vocoder

FEC
Orth
Mod
Long PN
x
x
x
IF Mod
I
Q
x ~
LO
Open Loop
LO
Closed Loop Pwr Ctrl
IF
Receiver>>
<<Transmitter
PA
BTS
Typical TXPO:
+23 dBm in a coverage hole
0 dBm near middle of cell
-50 dBm up close to BTS
0 dB
-10 dB
-20 dB
Typical Transmit Gain Adjust
Time, Seconds
TXPO = -(RX
dbm
) -C + TXGA
C = +73 for 800 MHz. systems
= +76 for 1900 MHz. systems
September, 2002 RF200 - 511 RF200 v3.73 (c) 2002 Scott Baxter
CDMA Network Architecture
CDMA Network Architecture
September, 2002 RF200 - 512 RF200 v3.73 (c) 2002 Scott Baxter
BASE STATION
CONTROLLER
SUPPORT
FUNCTIONS
BASE STATIONS
Mobile Telephone
Switching Office
PSTN
Local Carriers
Long Distance
Carriers
ATM Link
to other CDMA
Networks
(Future)
Structure of a Typical Wireless System
Voice Mail System
SWITCH
HLR Home Location Register
(subscriber database)
September, 2002 RF200 - 513 RF200 v3.73 (c) 2002 Scott Baxter
170 OC-192s
on One Fiber Strand!!
North American Heirarchy
in Copper Media
64,512 OC-192 10 Gb/s
32,256 OC-96 5 Gb/s
16,128 OC-48 2.5 Gb/s
8,064 OC-24 1.2 Gb/s
4,032 OC-12 622 Mb/s
2,016 OC-3 155 Mb/s
DS-0
The Heirarchy of Transmission Standards
Worldwide telecom rides
on the standard signal
formats shown at left
Lower speeds are used on
copper twisted pairs or
coaxial cable
Higher speeds are carried
on fiber
Multiplexers bundle and
unbundle channels
Channelized and
unchannelized modes are
provided
64 kb/s
DS-0
1.544 Mb/s
DS-1/T-1
= 24 DS-0
~45 Mb/s
DS-3
= 28 DS-1
= 672 DS-0
51.84 Mb/s
OC-1
= 28 DS-1
= 672 DS-0
European Heirarchy
in Copper Media
64 kb/s
DS-0
2.036 Mb/s
E-1
= 28+2 DS-0
FIBER
September, 2002 RF200 - 514 RF200 v3.73 (c) 2002 Scott Baxter
Signal Flow: Two-Stage Metamorphosis
BSC-BSM MTX BTS
Ch. Card ACC

TFU1
GPSR
BSM
CDSU
CDSU
SBS
Vocoders
Selectors
CDSU
CDSU
CDSU
CDSU
CDSU
CM SLM
LPP LPP ENET
DTCs
DMS-BUS
Txcvr
A
Txcvr
B
Txcvr
C
RFFE
A
RFFE
B
RFFE
C
TFU
GPSR
GPS
GPS
IOC
PSTN
CDSU DISCO CDSU
DISCO 1
DISCO 2
DS0 in T1
Packets
Chips
RF
Channel
Element
Vocoder
September, 2002 RF200 - 515 RF200 v3.73 (c) 2002 Scott Baxter
Sector Traffic Loading Effects
Sector Traffic Loading Effects
Case Study: Traffic Loading
September, 2002 RF200 - 516 RF200 v3.73 (c) 2002 Scott Baxter
Runaway Class turns to Dark Side of the Force
A major PCS operator often holds
technical classes in an attractive
conference center on the south side of
Kansas City
In early November, 1998, a CDMA
performance optimization class realized it
had a large number of mobiles on hand
and decided to try to push a cell to the
limit: to see just how far we could go in
cell loading, and what would happen
Data collection equipment was on hand to
record the event from the mobile side
System operations personnel were
available to retrieve system-side statistics
for the period
Lets see what happened!
September, 2002 RF200 - 517 RF200 v3.73 (c) 2002 Scott Baxter
The BTS at the BTA Conference Center
The classroom is about
500 feet northwest of
the three-sector BTS
The BTS gamma face
is the dominant sector
for the classroom, at
PN 212.
Looking northwest
212
208
204
N
Classroom
BTS
from RFCAD
from IQAnalyzer
September, 2002 RF200 - 518 RF200 v3.73 (c) 2002 Scott Baxter
What to Expect:
Loading Effects on the Forward Link
On the forward link, the
overhead channels (Pilot,
Sync, and Paging) remain
constant
Each new traffic channel
consumes additional transmit
power
Total transmit power increases
as traffic increases
Ec/Io decreases as traffic
increases (Ec stays the same,
but Io is driven up)
Light Traffic Loading
Ec/Io = (2/4)
= 50%
= -3 db.
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
0.5w
BTS
Transmit
Power
Heavily Loaded
Ec/Io = (2/10)
= 20%
= -7 db.
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
T
r
a
f
f
i
c

C
h
a
n
n
e
l
s
6w
0.5w
BTS
Transmit
Power
September, 2002 RF200 - 519 RF200 v3.73 (c) 2002 Scott Baxter
What to Expect:
Loading Effects on the Reverse Link
On a lightly-loaded sector, the
noise floor is relatively low and an
individual mobile can be heard at
comfortably low power
When the forward power goes up,
each mobiles open-loop power
control will try to decrease mobile
power output
On a heavily loaded sector each
mobile is competition against the
others, so the BTS must raise
each mobiles power to remain
competitive
Closed Loop power control takes a
double hit correcting for both
increased noise and the mobiles
incorrect power control instincts
Lightly Loaded Sector
Thermal
Noise
Mobile
BTS
Receive
Power
Heavily Loaded Sector
Thermal
Noise
O
t
h
e
r
M
o
b
i
l
e
s
BTS
Receive
Power
Mobile
I can hear it coming in the air tonight..
--Phil Collins
September, 2002 RF200 - 520 RF200 v3.73 (c) 2002 Scott Baxter
Light Traffic Loading
Heavily Loaded
BTS Loading Effects on the Reverse Link
On the reverse link, receive power
at the BTS increases when traffic
increases
BTS closed-loop power control
must counter this trend,
keeping each mobile
competitive with the rest
On the reverse link, the mobile
responds inversely to BTS power
output changes
When traffic drives BTS power
up, the mobile instinctively
tries to power down
BTS closed-loop power control
must also counter this trend
Mobile transmit power increases
substantially during heavy-traffic
periods!
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
T
r
a
f
f
i
c

C
h
a
n
n
e
l
s
6w
0.5w
2w
1.5w
Pilot
Paging
Sync
I
0
E
C
0.5w
September, 2002 RF200 - 521 RF200 v3.73 (c) 2002 Scott Baxter
All Phones
in Idle Mode
T
e
s
t

M
o
b
i
l
e

C
a
l
l

B
e
g
i
n
s
2
5
+

M
o
b
i
l
e
s
C
a
l
l
s

b
e
g
i
n
Test Mobile call has ended,
Other mobile calls continue
The Ground Shakes
September, 2002 RF200 - 522 RF200 v3.73 (c) 2002 Scott Baxter
Test Mobile Receive Power
Average
-76.5 dbm
With one user
Average
-70.5 dbm
With max users
As expected, the additional
calls increase the total power
output of the sector. This
causes received power to
increase at the test mobile.
September, 2002 RF200 - 523 RF200 v3.73 (c) 2002 Scott Baxter
Test Mobile Combined Ec/Io
Average
-3.6 db
With one user
Average
-6.8 db
With max users
Since the additional calls
increase the total power
output of the sector, but the
pilot power remains fixed,
the Ec/Io at the test mobile
decreases in proportion.
September, 2002 RF200 - 524 RF200 v3.73 (c) 2002 Scott Baxter
Test Mobile Closed-Loop Power Control (TXGA)
Average
-16 db
With only this
User active
Average
-6 db
while max users
active
Since the additional calls
increase the noise level at
the BTS receiver, the BTS
must ask the test mobile to
increase its transmit power
output to keep up with the
crowd.
About 6 db of this increase is
necessary to counteract the
mobiles own open-loop instinct
to power down due to
increased BTS power.
The rest is needed to keep the
mobiles signal competitive at
the BTS.
September, 2002 RF200 - 525 RF200 v3.73 (c) 2002 Scott Baxter
Test Mobile Transmit Power
Average
-16 dbm
With this user only
Average
-10 dbm
While max users
active
Responding to the BTS
closed-loop power control
instructions, the test mobile
operates at a higher transmit
power while competing with
many other users.
Why does all this data bounce
around so much?
1. Random motion of users
2. Rayleigh fading
3. Users varying vocoder rates
4. Interference from elsewhere
September, 2002 RF200 - 526 RF200 v3.73 (c) 2002 Scott Baxter
System-Side Data: Channel Element Usage
BTS Date
Start
Time End Time MOU CE
MOU
Traffic CE/User
MOU
Alpha
MOU
Beta
MOU
Gamma %SHO Max TCE
196 11/3/98 7:00:00 7:30:00 256.73 130.11 1.97 37.2 58.52 34.38 49.32 23
196 11/3/98 8:00:00 8:30:00 265.42 145.49 1.82 45.22 62.49 37.78 45.18 17
196 11/3/98 8:30:00 9:00:00 342.7 186.94 1.83 52.01 90.66 44.28 45.45 18
196 11/3/98 9:00:00 9:30:00 317.5 172.02 1.85 43.67 79.94 48.4 45.82 21
196 11/3/98 9:30:00 10:00:00 408.81 245.55 1.66 78.35 92.33 74.87 39.93 22
196 11/3/98 10:00:00 10:30:00 288.33 138.41 2.08 46.61 60.9 30.91 52 16
196 11/3/98 10:30:00 11:00:00 334.61 195.06 1.72 59.71 81.78 53.58 41.71 22
196 11/3/98 10:30:00 11:00:00 289.53 161.27 1.8 60.04 60.48 40.75 44.3 18
196 11/3/98 11:00:00 11:30:00 366.75 210.19 1.74 70.51 91.65 48.03 42.69 21
196 11/3/98 12:00:00 12:30:00 299.25 156.26 1.92 53.34 63.01 39.91 47.78 18
196 11/3/98 12:00:00 12:30:00 343.03 196.39 1.75 60.06 83.54 52.79 42.75 22
196 11/3/98 13:00:00 13:30:00 327.2 225.23 1.45 71.01 78.72 75.51 31.16 31
196 11/3/98 13:00:00 13:30:00 316.68 168.14 1.88 54.19 68.32 45.62 46.9 18
196 11/3/98 13:30:00 14:00:00 270.9 163.34 1.66 57.55 55.8 49.99 39.7 18
196 11/3/98 14:00:00 14:30:00 266.42 137.25 1.94 42.92 48.73 45.6 48.48 17
196 11/3/98 15:00:00 15:30:00 323.56 193.92 1.67 56.77 79.3 57.85 40.07 20
196 11/3/98 15:00:00 15:30:00 427.2 269.9 1.58 83.71 100.68 85.52 36.82 23
196 11/3/98 15:30:00 16:00:00 316.61 191.03 1.66 56.15 82.61 52.27 39.66 21
196 11/3/98 16:00:00 16:30:00 458.76 274.99 1.67 77.06 123.62 74.31 40.06 23
196 11/3/98 17:00:00 17:30:00 444.98 244.12 1.82 81.45 94.16 68.51 45.14 24
196 11/3/98 17:30:00 18:00:00 414.68 233.43 1.78 84.75 86.33 62.35 43.71 24
196 11/3/98 18:00:00 18:30:00 354.47 180.47 1.96 66.13 74.77 39.57 49.09 19
Totals for BTS 196 9783.79 5348.84 1.83 1760.71 2109.54 1478.61 45.33 31
The number of channel elements active on this BTS reaches its highest value
for the day during the 30-minute period of our experiment.
September, 2002 RF200 - 527 RF200 v3.73 (c) 2002 Scott Baxter
System-Side Data: BTS Blocks
Cell Start Date
Start
Time End Time
Blocks
No TCE
Blocks
No Fwd
Blocks
No Rev
SHO Blk
No TCE
SHO Blk
No Fwd
SHO Blk
No Rev
Succ
Calls
Succ
SHO
196 11/3/98 8:00:00 8:30:00 0 0 0 0 0 0 66 988
196 11/3/98 8:30:00 9:00:00 0 0 0 0 0 0 112 934
196 11/3/98 9:00:00 9:30:00 0 0 0 0 0 0 126 907
196 11/3/98 9:30:00 10:00:00 0 0 0 0 0 0 160 1099
196 11/3/98 10:00:00 10:30:00 0 0 0 0 0 0 77 853
196 11/3/98 10:30:00 11:00:00 0 0 0 0 0 0 121 1009
196 11/3/98 10:30:00 11:00:00 0 0 0 0 0 0 102 924
196 11/3/98 11:00:00 11:30:00 0 0 0 0 0 0 132 905
196 11/3/98 12:00:00 12:30:00 0 0 0 0 0 0 102 885
196 11/3/98 12:00:00 12:30:00 0 0 0 0 0 0 105 852
196 11/3/98 13:00:00 13:30:00 0 20 0 0 0 0 172 1018
196 11/3/98 13:00:00 13:30:00 0 0 0 0 0 0 97 913
196 11/3/98 13:30:00 14:00:00 0 0 0 0 0 0 117 744
196 11/3/98 14:00:00 14:30:00 0 0 0 0 0 0 83 953
196 11/3/98 15:00:00 15:30:00 0 0 0 0 0 0 132 924
196 11/3/98 15:00:00 15:30:00 0 0 0 0 0 0 149 1103
196 11/3/98 15:30:00 16:00:00 0 0 0 0 0 0 119 828
196 11/3/98 16:00:00 16:30:00 0 0 0 0 0 0 129 1064
196 11/3/98 17:00:00 17:30:00 0 1 0 0 0 0 128 1044
196 11/3/98 17:30:00 18:00:00 0 0 0 0 0 0 129 914
196 11/3/98 18:00:00 18:30:00 0 0 0 0 0 0 96 979
Totals for BTS 196 0 21 0 0 0 0 3140 28102
The BTS experiences 20 cases of blockage due to no forward power available
during the 30-minute period of our experiment. The only other time during the
day when it experienced ANY such blocks was 17:00-17:30, when there was
only one despite traffic levels actually higher than during our experiment.
September, 2002 RF200 - 528 RF200 v3.73 (c) 2002 Scott Baxter
System-Side Data: BTS Blocks, Access Failures
Site Call Call % Total % Tot BTS %BTS Acc. %Acc. Screen %Scr. Calls %
Att. Succ. Succ. Block Block Block Block Fail Fail Calls Calls Drop Drop
===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== =====
196X 55 54 98.18 1 1.82 0 0 0 0 0 0 0 0
196Y 111 110 99.1 0 0 0 0 1 0.9 0 0 4 3.64
196Z 95 93 97.89 1 1.05 1 1.05 1 1.05 0 0 0 0
The sector hit by our experiment shows the worst BTS blocks and Access
Failures.
September, 2002 RF200 - 529 RF200 v3.73 (c) 2002 Scott Baxter
CDMA Information Resources
Bibliography - Web Links
CDMA Information Resources
Bibliography - Web Links
September, 2002 RF200 - 530 RF200 v3.73 (c) 2002 Scott Baxter
Bibliography, 3G Air Interface Technologies
3G Wireless Demystified by Lawrence Harte, Richard Levine, and Roman Kitka
488pp. Paperback, 2001 McGraw Hill, ISSBN 0-07-136301-7 $50. For both non-technical and
technical readers. An excellent starting point for understanding all the major technologies and
the whole 3G movement. Comfortable plain-language explanations of all the 2G and 3G air
interfaces, yet including very succinct, complete, and rigorously correct technical details. You
will still want to read books at a deeper technical level in your chosen technology, and may
sometimes turn to the applicable standards for finer details, but this book will give you what you
wont find elsewhere -- how everything relates in the big picture, and probably everything you
care to know about technologies other than your own.
"Wireless Network Evolution 2G to 3G" by Vijay K. Garg. 764pp. 2002 Prentice-Hall, Inc. ISBN 0-
13-028077-1. $130. Excellent technical tutorial and reference. The most complete and
comprehensive technical detail seen in a single text on all these technologies: IS-95 2G CDMA,
CDMA2000 3G CDMA, UMTS/WCDMA, Bluetooth, WLAN standards (802.11a, b, WILAN).
Includes good foundation information on CDMA air interface traffic capacity, CDMA system
design and optimization, and wireless IP operations. Excellent level of operational detail for IS-
95 systems operating today as well as thorough explanations of 2.5G and 3G enhancements.
"3G Wireless Networks" by Clint Smith and Daniel Collins. 622pp. Paperback. 2002 McGraw-Hill,
ISBN 0-07-136381-5. $60. An excellent overview of all 3G technologies coupled with good
detail of network architectures, channel structures, and general operational details. Good
treatment of both CDMA2000 and UMTS/WCDMA systems.
WCDMA: Towards IP Mobility and Mobile Internet by Tero Ojanpera and Ramjee Prasad. 476pp.
2001 Artech House, ISSBN 1-58053-180-6. $100. The most complete and definitive work on
UMTS (excellent CDMA2000, too!). CDMA principles, Mobile Internet, RF Environment &
Design, Air Interface, WCDMA FDD standard, WCDMA TDD, CDMA2000, Performance,
Heirarchical Cell Structures, Implementation, Network Planning, Basic IP Principles, Network
Architectures, Standardization, Future Directions. This is a MUST HAVE for a one-book library!
September, 2002 RF200 - 531 RF200 v3.73 (c) 2002 Scott Baxter
More Bibliography,
3G Air Interface Technologies
The UMTS Network and Radio Access Technology by Dr. Jonathan P. Castro, 354
pp. 2001 John Wiley, ISBN 0 471 81375 3, $120. An excellent, well-organized, and
understandable exploration of UMTS. Includes radio interface, channel
explanations, link budgets, network architecture, service types, ip network
considerations, a masterful tour de force through the entire subject area. Very
readable, too!
WCDMA for UMTS by Harri Holma and Antti Toskala, 322 pp. 2000 Wiley, ISBN 0
471 72051 8, $60. Very good overall treatment of UMTS. Excellent introduction to
3G and summary of standardization activities, every level of UMTS/UTRA. Good
overview of CDMA-2000, too!
The GSM Network - GPRS Evolution: One Step Towards UMTS 2nd Edition by
Joachim Tisal, 227pp. paperback, 2001 Wiley, ISBN 0 471 49816 5, $60. Readable
but not overwhelming introduction to GSM in all its aspects (140pp), DECT (11pp),
GPRS (6pp), UMTS (7pp), WAP (25pp), EDGE (10pp).
September, 2002 RF200 - 532 RF200 v3.73 (c) 2002 Scott Baxter
Bibliography, The IP Aspect of 3G
Mobile IP: Design, Principles and Practices by Charles E. Perkins, 275 pp., 200, 1998 Addison-
Wesley, ISBN 0-201-63469-4. $60. Comprehensive view of Mobile IP including home and
foreign agents, advertisement, discovery, registration, datagrams, tunneling, encapsulation,
route optimization, handoffs, firewalls, IPv6, DHCP. Tour-de-force of mobile IP techniques.
Mobile IP Technology for M-Business by Mark Norris, 291 pp., 2001 Artech House, ISSBN 1-
58053-301-9. $67. GPRS overview and background, Mobile IP, Addressing, Routing, M-
business, future prospects, IPv4, IPv6, Bluetooth & IrDA summaries.
TCP/IP Explained by Phillip Miller, 1997 Digital Press, ISBN 1-55558-166-8, 518pp. $50. In-depth
understanding of the Internet protocol suite, network access and link layers, addressing,
subnetting, name/address resolution, routing, error reporting/recovery, network management. IF
youre not already strong in TCP/IP, youll need this to fully master Mobile IP.
Cisco Networking Academy Program: First-Year Companion Guide edited by Vito Amato, 1999
Cisco Press, ISBN 1-57870-126-0, 438pp. Textbook supporting a year-long course on
networking technologies for aspiring LAN/WAN (and 3G) technicians and engineers. It covers
every popular networking technology (including all its elements and devices) in deep and
practical detail. Excellent real-world understanding of TCP/IP, as well as the nuts-and-bolts of
everything from physical components to protocols to actual devices such as routers, switches,
etc. You might even want to take the evening courses at a local community college near you.
Cisco Networking Academy Program: Engineering Journal and Workbook, Volume I edited by
Vito Amato, 1999 Cisco Press, ISBN 1-57870-126-x, 291pp. The workbook for the First Year
Companion Guide above. If you want some external structure in your self-study, this workbook
will hold your hand as you climb every step of the ladder, and will lead you step by step through
the sister textbook, ensuring you absorb everything you need to know.
September, 2002 RF200 - 533 RF200 v3.73 (c) 2002 Scott Baxter
Bibliography - General CDMA
IS-95 CDMA and CDMA2000: Cellular/PCS Systems Implementation by Vijay K. Garg. 422 pp.
2000 Prentice Hall, ISBN 0-13-087112-5, $90. IS-95 and CDMA2000 Access technologies,
DSSS, IS-95 air interface, channels, call processing, power control, signaling, soft handoff,
netw. planning, capacity, data. CDMA2000 layers, channels, coding, comparison w/ WCDMA.
CDMA Systems Engineering Handbook by Jhong Sam Lee and Leonard E. Miller, 1998 Artech
House, ISBN 0-89006-990-5. Excellent treatment of CDMA basics and deeper theory, cell and
system design principles, system performance optimization, capacity issues. Recommended.
CDMA RF System Engineering by Samuel C. Yang, 1998 Artech House, ISBN 0-89006-991-3.
Good general treatment of CDMA capacity considerations from mathematical viewpoint.
CDMA Internetworking: Deploying the Open A-Interface by Low and Schneider. 616 pp. 2000
Prentice Hall, ISBN 0-13-088922-9, $75. A tour-de-force exposition of the networking between
the CDMA BSC, BTS, and mobile, including messaging and protocols of IS-634. Chapters on
SS7, Call Processing, Mobility Management, Supplementary Services, Authentication,
Resource Management (both radio and terrestrial), 3G A-Interface details. One-of-a-kind work!
"CDMA: Principles of Spread Spectrum Communication" by Andrew J. Viterbi. 245 p. Addison-
Wesley 1995. ISBN 0-201-63374-4, $65. Very deep CDMA Theory. Prestige collectors item.
September, 2002 RF200 - 534 RF200 v3.73 (c) 2002 Scott Baxter
Bibliography - General Wireless
Mobile and Personal Communication Services and Systems by Raj Pandya, 334 pp.
2000 IEEE Press, $60. IEEE order #PC5395, ISBN 0-7803-4708-0. Good technical
overview of AMPS, TACS< NMT, NTT, GSM, IS-136, PDC, IS-95, CT2, DECT,
PACS, PHS, mobile data, wireless LANs, mobile IP, WATM, IMT2000 initiatives by
region, global mobile satellite systems, UPT, numbers and identities, performance
benchmarks.
Wireless Telecom FAQs by Clint Smith, 2001 McGraw Hill, ISBN 0-07-134102-1.
Succint, lucid explanations of telecom terms in both wireless and landline
technologies. Includes cellular architecture, AMPS, GSM, TDMA, iDEN, CDMA.
Very thorough coverage; an excellent reference for new technical people or anyone
wishing for clear explanations of wireless terms.
"Mobile Communications Engineering" 2
nd
. Edition by William C. Y. Lee. 689 pp.
McGraw Hill 1998 $65. ISBN 0-07-037103-2 Lees latest/greatest reference work
on all of wireless; well done.
September, 2002 RF200 - 535 RF200 v3.73 (c) 2002 Scott Baxter
Web Links and Downloadable Resources
Scott Baxter: http://www.howcdmaworks.com
Latest versions of all courses are downloadable.
Category - Username - Password
Intro - (none required) - (none required)
RF/CDMA/Performance - shannon - hertz
3G - generation - third
Grayson - telecom - allen
Agilent - nitro - viper
Dr. Ernest Simos Space2000: http://www.cdmaonline.com/ and http://www.3Gonline.com/
CDG: http://www.cdg.org (check out the digivents multimedia viewable sessions)
The IS-95 and IS-2000 CDMA trade marketing webside, CDMA cheerleaders.
GSM: http://www.gsmworld.com
The GSM Association website. Worldwide GSM marketing cheerleaders but also includes some
excellent GSM and GPRS technical overview whitepapers and documents; latest user figures.
UWCC: http://www.uwcc.com
The IS-136 TDMA trade marketing website, TDMA cheerleaders.
RCR News: http://www.rcrnews.com
Wireless Industry trade publication - regulatory, technical, business, marketing news.
Subscribers can access text archives of past articles; very handy in researching events.
Wireless Week: http://www.wirelessweek.com
Wireless Industry trade publication - regulatory, technical, business, marketing news.
September, 2002 RF200 - 536 RF200 v3.73 (c) 2002 Scott Baxter
More Web Links
3GPP: http://www.3gpp.org/
The operators harmonization group concerned mainly with ETSI-related standards
3GPP2: http://www.3gpp2.org/
The operators harmonization group concerned mainly with IS-95-derived CDMA standards
ITU: http://www.itu.int/imt/
ETSI: http://www.etsi.fr/
UMTS forum: http://www.umts-forum.org/
GSM MoU: http://www.gsmworld.com/
TIA: http://www.tiaonline.org/
T1: http://www.t1.org/
ARIB: http://www.arib.or.jp/arib/english/index.html
TTC: http://www.ttc.or.jp/
TTA: http://www.tta.or.kr/
ETRI: http://www.etri.re.kr/
RAST: http://www.rast.etsi.fi/

Das könnte Ihnen auch gefallen