Date post: | 09-May-2015 |
Category: |
Documents |
Upload: | koppisetti-kameswarrao |
View: | 3,235 times |
Download: | 13 times |
Course RF200
Wireless CDMA RF Performance Optimization
Wireless CDMA RF Performance Optimization
November, 2004 RF200 - 1RF200 v4.0 (c) 2004 Scott Baxter
Contents
Chapter Slide #1. Introduction 12. Foundation Topics
Layer-3 Messaging 9Call Processing 14Performance Indicators and Problem Signatures 95PN Planning and Search Windows 116
2. Analyzing System Performance 138System Data and Analysis Techniques 141
3. Mobile Field Tools and Data Analysis 191Autonomous Mobile Data Collection 196Conventional Field Data Collection Tools 201
4. Multiple Carrier Systems: Operating Principles and Analysis 2625. Applied Optimization 2926. 1xRTT Optimization Issues 334Appendix I. Cell Loading Example 405Appendix II. CDMA/3g1x Books, Publications, Web Resources 419
November, 2004 RF200 - 2RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Introduction to Performance Optimization
Introduction to Performance Optimization
November, 2004 RF200 - 3RF200 v4.0 (c) 2004 Scott Baxter
Welcome to Course RF200
Course RF100 is an introduction to RF and CDMA principles. Aftercompleting it, you should be familiar with:
• General RF system design principles• CDMA technology - principles, channels, network basics• key fundamentals of Messaging and Call Processing
Course RF200 covers how to recognize and deal with system performance problems
• key performance indicators and what they mean• what tools are available for discovering and analyzing
problems• mechanisms and situations that cause trouble• how to solve many of the problems you’ll see
November, 2004 RF200 - 4RF200 v4.0 (c) 2004 Scott Baxter
Good Performance is so Simple!!
One, Two, or Three good signals in handoff• Composite Ec/Io > -10 db
Enough capacity• No resource problems – I’ve got what I
need
BTS BTS
BTS
Pilot
Paging
TrafficChannels
In use
availablepower
Sync
BTS
A
BTS
B
BTS
C
Ec/Io -10
FORWARDLINK
November, 2004 RF200 - 5RF200 v4.0 (c) 2004 Scott Baxter
Bad Performance
BTS BTS
BTS
Pilot PollutionWeak SignalScarce Resources
• BTS forward power• BTS receive power • channel elements• packet pipes
Poor System Statistics• High Dropped Calls• High Access
Failures
Pilot
Paging
TrafficChannels
In use
availablepower
SyncBTS Rx Pwr
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
Perc
ent
%Drops
November, 2004 RF200 - 6RF200 v4.0 (c) 2004 Scott Baxter
What is Performance Optimization?
The words “performance optimization” mean different things to different people, viewed from the perspective of their own jobsSystem Performance Optimization includes many different smaller processes at many points during a system’s life
• recognizing and resolving system-design-related issues (can’t build a crucial site, too much overlap/soft handoff, coverage holes, etc.)
• “cluster testing” and “cell integration” to ensure that new base station hardware works and that call processing is normal
• “fine-tuning” system parameters to wring out the best possible call performance
• identifying causes of specific problems and customer complaints, and fixing them
• carefully watching system traffic growth and the problems it causes - implementing short-term fixes to ease “hot spots”, and recognizing problems before they become critical
November, 2004 RF200 - 7RF200 v4.0 (c) 2004 Scott Baxter
Performance Optimization Phases/Activities
hello
RF Design and Cell Planning
New Cluster Testing and
Cell Integration
Solve SpecificPerformance
Problems
Well-System Performance Management
Capacity Optimization
Growth Management:
Optimizing both Performance and Capital
Effectiveness
Cover desired area; have capacity for anticipated traffic
Ensure cells properly constructed and
configured to give normal performance
Identify problems from complaints or statistics; fix them!
Ensure present ‘plant’is giving best possible
performance
Manage congested areas for most
effective performance
Overall traffic increases and congestion;
competition for capital during tight times
Phase Drivers/Objectives Activities Main Tools Success Indicators
Plan cells to effectively cover as needed and divide traffic
load appropriately
Drive-test: coverage, all handoff boundaries, all call
events and scenarios
Detect, Investigate, Resolve performance problems
Watch stats: Drops, Blocks, Access Failures; identify/fix hot
spots
Watch capacity indicators; identify problem areas, tune parameters & configuration
Predict sector and area exhaustion: plan and validate effective growth plan, avoid
integration impact
Prop. Models,Test Transmitters,
planning tools Model results
Drive-test tools;cell diagnostics and
hardware test
All handoffs occur; all test cases
verified
Drive-test tools, system stats,
customer reports
Identified problems are
resolved
System statisticsAcceptable levels and good trends for all indicators
Smart optimization of parameters;
system statistics
Stats-Derived indicators; carried
traffic levels
Traffic analysis and trending tools;
prop. models for cell spliiting; carrier
additions
Sectors are expanded soon
after first signs of congestion;
capital budget remains within
comfortable bounds
November, 2004 RF200 - 8RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
CDMA2000 Layer 3 MessagesCDMA2000 Layer 3 Messages
November, 2004 RF200 - 9RF200 v4.0 (c) 2004 Scott Baxter
Messages in CDMA
In CDMA, most call processing events are driven by messagesSome CDMA channels exist for the sole purpose of carrying messages; they never carry user’s voice traffic
• Sync Channel (a forward channel)• Paging Channel (a forward channel)• Access Channel (a reverse channel)• Forward or Reverse Dedicated Control Channels• On these channels, there are only messages, not voice or data
Some CDMA channels exist just to carry user traffic• Forward Fundamental and Supplemental Channels• Reverse Fundamental and Supplemental Channels• On these channels, most of the time is filled with traffic and
messages are sent only when there is something to doAll CDMA messages have very similar structure, regardless of thechannel on which they are sent
November, 2004 RF200 - 10RF200 v4.0 (c) 2004 Scott Baxter
The Basic Format of CDMA Messages
MSG_TYPE (‘00000110’)
ACK_SEQ
MSG_SEQ
ACK_REQ
ENCRYPTION
ERRORS_DETECTED
POWER_MEAS_FRAMES
LAST_HDM_SEQ
NUM_PILOTS
PILOT_STRENGTH
RESERVED (‘0’s)
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 MESSAGECDMA messages on both forward and reverse traffic channels are normally sent via dim-and-burstMessages include many fields of binary dataThe first byte of each message identifies message type: this allows the recipient to parse the contentsTo ensure no messages are missed, all CDMA messages bear serial numbers and important messages contain a bit requesting acknowledgmentMessages not promptly acknowledged are retransmitted several times. If not acknowledged, the sender may release the callField data processing tools capture and display the messages for study t
November, 2004 RF200 - 11RF200 v4.0 (c) 2004 Scott Baxter
Message Vocabulary: Acquisition & Idle StatesSync Channel
Sync Channel Msg
Pilot Channel
No Messages
Paging Channel
Access Parameters Msg
System Parameters Msg
CDMA Channel List Msg
Extended SystemParameters Msg
Extended NeighborList Msg
Global ServiceRedirection Msg
Order Msg•Base Station Acknowledgment
•Lock until Power-Cycled• Maintenance required
many others…..
AuthenticationChallenge Msg
Status Request Msg
Feature Notification Msg
TMSI Assignment Msg
Channel AssignmentMsg
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 Confirmationmany others…..
Origination Msg
Page Response Msg
Authentication ChallengeResponse Msg
Status Response Msg
TMSI AssignmentCompletion Message
Data Burst Msg
BTS
November, 2004 RF200 - 12RF200 v4.0 (c) 2004 Scott Baxter
Message Vocabulary: Conversation State
Reverse Traffic Channel
Order Message• Mobile Sta. Acknowledgment
•Long Code Transition Request
• SSD Update Confirmation• Connect
Authentication ChallengeResponse Msg
Flash WithInformation Msg
Data Burst Message
Pilot StrengthMeasurement Msg
Power MeasurementReport Msg
Send Burst DTMF Msg
OriginationContinuation Msg
Handoff Completion Msg
Parameters ResponseMessage
Service Request Msg
Service Response Msg
Service ConnectCompletion Message
Service Option ControlMessage
Status Response Msg
TMSI AssignmentCompletion Message
Forward Traffic ChannelOrder Msg
• Base Station Acknowledgment • Base Station Challenge
Confirmation• Message Encryption Mode
AuthenticationChallenge Msg
Alert WithInformation Msg
Data Burst Msg
Analog HandoffDirection Msg
In-Traffic SystemParameters Msg
Neighbor ListUpdate Msg
Send Burst DTMF Msg
Power ControlParameters Msg.
Retrieve Parameters Msg
Set Parameters Msg
SSD Update Msg
Flash WithInformation Msg
Mobile StationRegistered Msg
Status Request Msg
Extended HandoffDirection Msg
Service Request Msg
Service Response Msg
Service Connect Msg
Service OptionControl Msg
TMSI Assignment Msg
November, 2004 RF200 - 13RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
CDMA Call Processing BasicsCDMA Call Processing Basics
November, 2004 RF200 - 14RF200 v4.0 (c) 2004 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.
– What’s missing or wrong? Why did it happen?Messaging is a major blow-by-blow troubleshooting toolRF indications reveal the transmission risks and the channel configurations
Bottom Line: To troubleshoot effectively, you’ve got to know call processing steps and details AND the RF basis of the transmission
November, 2004 RF200 - 15RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Let's Acquire The System!Let's Acquire The System!
November, 2004 RF200 - 16RF200 v4.0 (c) 2004 Scott Baxter
What’s In a Handset? How does it work?
ReceiverRF SectionIF, Detector
TransmitterRF Section
Vocoder
Digital Rake Receiver
Traffic CorrelatorPN xxx Walsh xx ΣTraffic CorrelatorPN xxx Walsh xxTraffic CorrelatorPN xxx Walsh xx
Pilot SearcherPN xxx Walsh 0
Viterbi Decoder,Convl. Decoder,Demultiplexer
CPUDuplexer
TransmitterDigital Section
Long Code Gen.
Open Loop Transmit Gain Adjust
Messages
Messages
Audio
Audio
Packets
Symbols
SymbolsChips
RF
RF
AGC
time-
alig
ned
su
mm
ing
pow
er
Traffic CorrelatorPN xxx Walsh xx
∆tcont
rol
bits
November, 2004 RF200 - 17RF200 v4.0 (c) 2004 Scott Baxter
The Task of Finding the Right System
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.5825
890
891.5
Paging, ESMR, etc.A B A B
800 MHz. Cellular Spectrum
Reverse Link Frequencies(Mobile Transmit)
Mobile scans forward link frequencies:(Cellular or PCS, depending on model)
History List (MRU)Preferred Roaming List (PRL)
until a CDMA signal is found.Use PRL to find best signal in area.NO CDMA? Try AMPS. No AMPS? Standby
HISTORYLIST/MRU
Last-used:FreqFreqFreqFreqFreqetc.
FREQUENCY LISTS:PREFERREDROAMINGLIST/PRL
System1System2System3System4System5etc.
November, 2004 RF200 - 18RF200 v4.0 (c) 2004 Scott Baxter
The System Determination AlgorithmAt turnon, Idle mobiles use proprietary System Determination Algorithms (SDA) to find the initial CDMA carrier intended for them to useThe 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
SyncIs SID
permitted?
No Signal
Preferred Only Bit 0
Denied SIDRead
Paging Channel
Is better SID
available?
PRLMRU Acq IdxYes
No
Steps from the CDMA standards
Steps from proprietary
SDAs
Proprietary SDA
databases
Start
LegendTypical MobileSystem Determination Algorithm
Best System Found! Begin Normal Paging Channel Operation
Last Resort:GEO escape
Or Analog
November, 2004 RF200 - 19RF200 v4.0 (c) 2004 Scott Baxter
1xRTT Acquisition On the Current Frequency: Find Strongest Pilot, Read Sync Channel
Rake Fingers
Reference PN
Active Pilot
Ec/
Io
00
32K512
ChipsPN
1. Pilot Searcher Scans the Entire Range of PNs
All PN Offsets0
-20
MSG_LENGTH, 28, 28 octetsMSG_TYPE, 1, Sync Channel MessageP_REV, 6, IS-2000 Revision 0MIN_P_REV, 1, J-STD-008SID 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:54LP_SEC, 13, LTM_OFF, 54, -660 minutesDAYLT, 1, YesPRAT, 1, 4800 bpsCDMA_FREQ, 274 (IS-95) EXT_CDMA_FREQ, 274 (1xRTT) SR1_BCCH_SUPPORTED, 0SR3_INCL, 0, NoRESERVED, 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 W32F2 PN168 W32F3 PN168 W32
Is this the right system to use?Check the PRL!
November, 2004 RF200 - 20RF200 v4.0 (c) 2004 Scott Baxter
PRL Database Guides System DeterminationHandsets 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
Preferred Only Bit TRUEFALSE
when available.
Acquisition Index0 CDMA channels
CDMA channelsAnalog BlockAnalog Block
123
350,40050, 100AB
System RecordsSID Priority4139
NID65535
PREFPref
GEONew
Index Roam IndicatorMore 0 Off
59 65535 Pref Same More 2 On52 65535 Pref Same More 3 Flash67 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.
November, 2004 RF200 - 21RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 22RF200 v4.0 (c) 2004 Scott Baxter
Climbing the GEO Group
When traveling the first signal found is usually not the best one to useWhen the SID and NID are looked up in the PRL, they are far down the list of available choicesThe starts at the top of the GEO group and works down to the first (most preferred) system it can find
• the Acquisition Table is the list of frequencies used by the various systems, so the mobile knows where to search
ROAMING LIST
Roaming List Type: IS-683APreferred Only: FALSEDefault Roaming Indicator: 0Preferred List ID: 10018
ACQUISITION TABLE
INDEX ACQ TYPE CH1 CH2 CH3 CH4 CH5 CH6 CH7 CH8 CH90 6 500 425 825 575 850 325 6251 6 575 625 500 4252 6 50 100 75 475 825 850 175 2503 6 25 200 350 375 725 50 475 175 2504 1 Both5 6 450 500 350 575 6506 6 675 500 600 575 4757 6 250 50 1758 6 550 375 425 6259 6 75 50 175 250
10 6 200 250 175 5011 6 425 500 575 25 325 65012 6 500 575 475 25 67513 6 500 625 350 50 375 775 575 725 42514 6 650 500 675 25 75 425 50 57515 6 25 50 375 350 250 17516 6 425 550 225 725 750 77517 6 200 50 175 375 25018 6 825 850 92519 6 350 325 375 675 25 1175 725 600 10020 6 750 725 77521 6 325 725 350 750 375 775 425 575 62522 6 1150 117523 6 350 875 325 375 117524 6 25 1175 825 200 75 175 25025 6 50 200 25 100 250 7526 6 500 1075 850 82527 1 A28 1 B29 5 A30 5 B31 5 C32 5 D33 5 E34 5 F35 4 A36 4 B37 4 Both38 6 350 82539 6 25 10040 6 675 600 750 850 1175 77541 6 85042 6 65043 6 450 47544 6 325 350 375 1025 1050 107545 6 150 475 625 67546 6 1025 1050 1075
SYSTEM TABLE
INDEX SID NIDNEG/ PREF GEO PRI
ACQ INDEX
ROAM IND
296 4144 65535 Pref NEW SAME 13 1297 4812 65535 Pref SAME MORE 21 1298 205 65535 Pref SAME SAME 4 0299 208 65535 Pref SAME MORE 37 0300 208 65535 Pref SAME SAME 4 0301 342 65535 Pref SAME MORE 37 0302 342 65535 Pref SAME SAME 4 0303 478 65535 Pref SAME SAME 4 0304 1038 65535 Pref SAME SAME 4 0305 1050 65535 Pref SAME SAME 4 0306 1058 65535 Pref SAME SAME 4 0307 1375 65535 Pref SAME SAME 4 0308 1385 65535 Pref SAME MORE 4 0309 143 65535 Pref SAME MORE 37 0310 143 65535 Pref SAME MORE 4 0311 4103 65535 Pref NEW SAME 3 1312 4157 65535 Pref SAME MORE 2 1313 312 65535 Pref SAME SAME 4 0314 444 65535 Pref SAME MORE 37 0315 444 65535 Pref SAME SAME 4 0316 1008 65535 Pref SAME SAME 4 0317 1012 65535 Pref SAME SAME 4 0318 1014 65535 Pref SAME SAME 4 0319 1688 65535 Pref SAME MORE 4 0320 113 65535 Pref SAME MORE 37 0321 113 65535 Pref SAME SAME 4 0322 179 65535 Pref SAME MORE 37 0323 179 65535 Pref SAME SAME 4 0324 465 65535 Pref SAME SAME 4 0325 2119 65535 Pref SAME MORE 4 0326 2094 65535 Pref SAME MORE 4 0327 1005 65535 Pref SAME SAME 4 0328 1013 65535 Pref SAME SAME 4 0
a G
EO G
RO
UP
a G
EO G
RO
UP
Clim
b!
PRL: Preferred Roaming ListProgrammed into each phone by the system
operator; can be updated over the air.
November, 2004 RF200 - 23RF200 v4.0 (c) 2004 Scott Baxter
Found it! Now we’re on the Right System
November, 2004 RF200 - 24RF200 v4.0 (c) 2004 Scott Baxter
Rake Fingers
Ref.PN
Active Pilot
Ec/
Io
00
32K512
ChipsPN
1. Pilot Searcher Scans the Entire Range of PNs
All PN Offsets0
-20
98/05/24 23:14:09.817 [SCH] MSG_LENGTH = 208 bitsMSG_TYPE = Sync Channel MessageP_REV = 3MIN_P_REV = 2SID = 179NID = 0PILOT_PN = 168Offset IndexLC_STATE = 0x0348D60E013SYS_TIME = 98/05/24 23:14:10.160LP_SEC = 12LTM_OFF = -300 minutesDAYLT = 0PRAT = 9600 bpsRESERVED = 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 W32F2 PN168 W32F3 PN168 W32
If PRL shows:This is the Best
Available System!
Go to thePaging
Channel!
Course RF200
After finding the right system:Normal Paging Channel Operation
After finding the right system:Normal Paging Channel Operation
November, 2004 RF200 - 25RF200 v4.0 (c) 2004 Scott Baxter
The Configuration Messages
After reading the Sync Channel, the mobile is now capable of reading the Paging Channel, which it now monitors constantlyBefore it is allowed to transmit or operate on this system, the mobile must collect a complete set of configuration messagesIn IS-95, the configuration messages are sent on the Paging Channel, repeated every 1.28 secondsIn CDMA2000 systems, the configuration messages may be sent on the separate F-BCH channel
• This would be indicated as SR1_BCCH_SUPPORTED = 1There are six possible types of configuration messages; some areoptional; and they may happen in any orderThe 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
November, 2004 RF200 - 26RF200 v4.0 (c) 2004 Scott Baxter
Reading the Configuration Messages
November, 2004 RF200 - 27RF200 v4.0 (c) 2004 Scott Baxter
Rake Fingers
Reference PN
Active Pilot
Ec/
Io
00
32K512
ChipsPN
All PN Offsets0
-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 SystemParameters Msg (*opt.)
(Extended*) NeighborList Msg
Global ServiceRedirection Msg (*opt.)
Now we’re ready to operate!!
Handset Rake Receiver
RF≈ x ≈
LO Srch PN??? W0
F1 PN168 W01F2 PN168 W01F3 PN168 W01
1xRTT Access Parameters MessageACCESS PARAMETERS MESSAGE
BTS
Any Access Msg
MSProbing
Basic Access Procedure
a Probe Sequencean Access Attempt
Success!
an Access Probe
000035, Time 15:28:37.709, Record 6408, QcpCdmaLogMsgPagingChanPD: P_REV_IN_USE < 6MSG_TYPE: Access Parameters MessagePILOT_PN: 36ACC_MSG_SEQ: 2ACC_CHAN: 1 Access Channel(s)NOM_PWR: 3 dBINIT_PWR: -13 dBPWR_STEP: 5 dBNUM_STEP: 4 Probe(s)MAX_CAP_SZ: 6 ACH FramesPAM_SZ: 3 ACH Frame(s)PSIST(0-9): 0PSIST(10): 0PSIST(11): 0PSIST(12): 0PSIST(13): 0PSIST(14): 0PSIST(15): 0MSG_PSIST: 1.00REG_PSIST: 1.00PROBE_PN_RAN: 0 PN chip(s)ACC_TMO: 240 msPROBE_BKOFF: 1 Slot(s)BKOFF: 1 Slot(s)MAX_REQ_SEQ: 3MAX_RSP_SEQ: 3AUTH_MODE: 0NOM_PWR_EXT: -8 to 7 dB inclusivePSIST_EMG_INCL: NoRESERVED: 0
The Access Parameters message controls all the steps mobiles must perform when they transmit on the Access ChannelMobiles perform a trial-and-error process called “Probing” to get their messages through
November, 2004 RF200 - 28RF200 v4.0 (c) 2004 Scott Baxter
Phone Operation on the Access Channel
A sector’s Paging Channel announces 1 (typ) to 32 (max) Access Channels: PN Long Code offsets for mobiles to use if accessing the system.
• For mobiles sending Registration, Origination, Page Responses
• Base Station always listening!On the access channel, phones are not yet under BTS closed-loop power control!Phones access the BTS by “probing” at power levels determined by receive power and an open loop formula
• If “probe” not acknowledged by BTS within ACC_TMO (~400 mS.), phone will wait a random time (~200 mS) then probe again, stronger by PI db.
• There can be 15 max. (typ. 5) probes in a sequence and 15 max. (typ. 2) sequences in an access attempt
• most attempts succeed on first probe!The Access Parameters message on the paging channel announces values of all related parameters
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!
MSProbing
PAGING
FW TFC
PAGING
RV TFC
FW FC
RV TFC
FW TFC
FW TFC
Successful Basic Access Attempt
a Probe Sequencean Access Attempt
Success!
an Access Probe
November, 2004 RF200 - 29RF200 v4.0 (c) 2004 Scott Baxter
1xRTT System Parameters MessageSYSTEM PARAMETERS MESSAGE
000029, Time 15:28:37.607, Record 6330, QcpCdmaLogMsgPagingChanPD: P_REV_IN_USE < 6MSG_TYPE: System Parameters MessagePILOT_PN: 36CONFIG_MSG_SEQ: 1SID: 4379 NID: 15 REG_ZONE: 6TOTAL_ZONES: 3 ZONE_TIMER: 1 minMULT_SIDS: No MULT_NIDS: No BASE_ID: 2155BASE_CLASS: Public PCS SystemPAGE_CHAN: 1 MAX_SLOT_CYCLE_INDEX: 1HOME_REG: Yes FOR_SID_REG: Yes FOR_NID_REG: YesPOWER_UP_REG: Yes POWER_DOWN_REG: YesPARAMETER_REG: NoREG_PRD: 30.89 minBASE_LAT: 37D18'35.00NBASE_LONG: 079D15'19.00WREG_DIST: 0 SRCH_WIN_A: 60 chipsSRCH_WIN_N: 60 chips SRCH_WIN_R: 80 chipsNGHBR_MAX_AGE: 0PWR_REP_THRESH: 2 Bad Frame(s)PWR_REP_FRAMES: 113 frame(s)PWR_THRESH_ENABLE: YesPWR_PERIOD_ENABLE: NoPWR_REP_DELAY: 4 framesRESCAN: No T_ADD: -14.0 dB T_DROP: -16.0 dBT_COMP: 4.0 T_TDROP: 4 secEXT_SYS_PARAMETER: Yes EXT_NGHBR_LIST: YesGEN_NGHBR_LIST: No GLOBAL_REDIRECT: YesPRI_NGHBR_LIST: No USER_ZONE_ID: NoEXT_GLOBAL_REDIRECT: NoEXT_CHAN_LIST: YesRESERVED: 0
Who Registers?Why & When?
Search WindowWidths
Handoff Thresholds
# Paging Channels, Slotted Mode period
What other optionalconfiguration messages
exist?
November, 2004 RF200 - 30RF200 v4.0 (c) 2004 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 NumberDifferent Networks may request different identification modes; the phones simply comply
• IMSI and ESN• IMSI only• ESN only
Intelligent soft handoff parameters are also included
000021, Time 15:28:37.421, Record 6188, QcpCdmaLogMsgPagingChanPD: P_REV_IN_USE < 6MSG_TYPE: Extended System Parameters MessagePILOT_PN: 36CONFIG_MSG_SEQ: 1DELETE_FOR_TMSI: NoUSE_TMSI: NoPREF_MSID_TYPE: IMSI and ESNMCC: 1134IMSI_11_12: 813TMSI_ZONE_LEN: 1 octetTMSI_ZONE: 0BCAST_INDEX: Disable Periodic Broadcast PagingIMSI_T_SUPPORTED: NoP_REV: IS-2000 Revision 0MIN_P_REV: J-STD-008SOFT_SLOPE: 18ADD_INTERCEPT: 6 dBDROP_INTERCEPT: 6 dBPACKET_ZONE_ID: Base Station Does Not Support A Packet Data Service ZoneMAX_NUM_ALT_SO: 0RESELECT_INCLUDED: NoPILOT_REPORT: NoNGHBR_SET_ENTRY_INFO: NoNGHBR_SET_ACCESS_INFO: NoBROADCAST_GPS_ASST: NoQPCH_SUPPORTED: NoSDB_SUPPORTED: NoRLGAIN_TRAFFIC_PILOT: 0.000000 dBREV_PWR_CNTL_DELAY_INCL: NoAUTO_MSG_SUPPORTED: NoRESERVED: 0
EXTENDED SYSTEM PARAMETERS
November, 2004 RF200 - 31RF200 v4.0 (c) 2004 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 boundariesDuring 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
000017, Time 15:28:37.381, Record 6158, QcpCdmaLogMsgPagingChanPD: P_REV_IN_USE < 6MSG_TYPE: Extended Neighbor List MessagePILOT_PN: 36CONFIG_MSG_SEQ: 1PILOT_INC: 4NGHBR_CONFIG: 0, NGHBR_PN: 32SEARCH_PRIORITY: Very High, FREQ_INCL: No NGHBR_CONFIG: 0 NGHBR_PN: 28SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 308SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 432SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 20SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 24SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 260SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 196SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 392SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 312SEARCH_PRIORITY: Very High FREQ_INCL: NoNGHBR_CONFIG: 0 NGHBR_PN: 316SEARCH_PRIORITY: Very High FREQ_INCL: NoRESERVED: 0
EXTENDED NEIGHBOR LIST
November, 2004 RF200 - 32RF200 v4.0 (c) 2004 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 mobile’s 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
000005, Time 15:28:37.056, Record 5910, QcpCdmaLogMsgPagingChanPD: P_REV_IN_USE < 6MSG_TYPE: Extended CDMA Channel List MessagePILOT_PN: 36CONFIG_MSG_SEQ: 1NUM_FREQ: 1CDMA_FREQ: 600RC_QPCH_SEL_INCL: NoTD_SEL_INCL: NoRESERVED: 0
EXTENDEDCDMA CHANNEL LIST MESSAGE
CDMA Ch List Message
HASH using IMSI F1
F2F3
Fnow
November, 2004 RF200 - 33RF200 v4.0 (c) 2004 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 listedWhenever 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
November, 2004 RF200 - 34RF200 v4.0 (c) 2004 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-shadedHow 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
November, 2004 RF200 - 35RF200 v4.0 (c) 2004 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
000011, Time 15:28:37.118, Record 5957, QcpCdmaLogMsgPagingChanPD: P_REV_IN_USE < 6MSG_TYPE: Global Service Redirection MessagePILOT_PN: 36CONFIG_MSG_SEQ: 1REDIRECT_ACCOLC (ACCOLC_0): NoREDIRECT_ACCOLC (ACCOLC_1): NoREDIRECT_ACCOLC (ACCOLC_2): NoREDIRECT_ACCOLC (ACCOLC_3): NoREDIRECT_ACCOLC (ACCOLC_4): NoREDIRECT_ACCOLC (ACCOLC_5): NoREDIRECT_ACCOLC (ACCOLC_6): NoREDIRECT_ACCOLC (ACCOLC_7): NoREDIRECT_ACCOLC (ACCOLC_8): NoREDIRECT_ACCOLC (ACCOLC_9): NoREDIRECT_ACCOLC (ACCOLC_10): NoREDIRECT_ACCOLC (ACCOLC_11): NoREDIRECT_ACCOLC (ACCOLC_12): NoREDIRECT_ACCOLC (ACCOLC_13): NoREDIRECT_ACCOLC (ACCOLC_14): NoREDIRECT_ACCOLC (ACCOLC_15): NoRETURN_IF_FAIL: NoDELETE_TMSI: NoEXCL_P_REV_MS: NoRECORD_TYPE: Redirection to An Analog SystemRECORD_LEN: 3 octetsEXPECTED_SID: 0IGNORE_CDMA: NoSYS_ORDERING: Attempt To Obtain Service On Either System A Or System B. If Unsuccessful, Attempt Alternate SystemMAX_REDIRECT_DELAY: 0 sec
GLOBAL SERVICE REDIRECTION
November, 2004 RF200 - 36RF200 v4.0 (c) 2004 Scott Baxter
Summary: How Idle Mobiles Choose CDMA CarriersAt turnon, Idle mobiles use proprietary System Determination Algorithms (SDA) to find the initial CDMA carrier intended for them to useOn the paging channel of the idle mobile’s newly-found home signal, the mobile might be sent to a different frequency if it hears
• CDMA Channel List Message• Global Service Redirection Message (GSRM)
Go to last frequency from MRU
Strongest PN, read
SyncIs SID
permitted?
No Signal
Preferred Only Bit 0
Denied SIDRead
Paging Channel
CDMA Ch List Message
Global Svc Redir Msg
HASH using IMSI
my ACCOLC? redirect
Is better SID
available?
PRLMRU Acq IdxYes
NoF1F2F3
to Analog
to another CDMA frequency or system
ConfigMessages:
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
November, 2004 RF200 - 37RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Let’s Do An Idle ModeHandoff!
Let’s Do An Idle ModeHandoff!
November, 2004 RF200 - 38RF200 v4.0 (c) 2004 Scott Baxter
Idle Mode Handoff
An idle mobile always demodulates the best available signal• In idle mode, it isn’t possible to do soft handoff and listen to
multiple sectors or base stations at the same time -- the paging channel information stream is different on each sector, not synchronous -- just like ABC, NBC, CBS, and CNN TV news programs aren’t in word-sync for simultaneous viewing
• Since a mobile can’t combine signals, the mobile must switch quickly, always enjoying the best available signal
The mobile’s pilot searcher is constantly checking neighbor pilotsIf the searcher notices another signal at least 3 db better than the present one, and it remains so for 5 seconds, the mobile starts listening to it at the beginning of the next paging slot.
• The mobile doesn’t automatically say anything to the system, so system doesn’t know about the idle mode handoff
On the new paging channel, if the mobile learns that registration is required, it re-registers on the new sector
November, 2004 RF200 - 39RF200 v4.0 (c) 2004 Scott Baxter
Idle Mode on the Paging Channel: Meet the Neighbors, track the Strongest Pilot
Ec/
IoAll PN Offsets
00
32K512
ChipsPN
0
-20
Neighbor Set
The phone’s pilot searcher constantly checks the pilots listed in the Neighbor List Message
Rake Fingers
Reference PN
Active Pilot
SRCH_WIN_A
SRCH_WIN_N
Mobile Rake RX
Srch PN??? W0
F1 PN168 W01F2 PN168 W01F3 PN168 W01
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.
November, 2004 RF200 - 40RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Let’s Register!Let’s Register!
November, 2004 RF200 - 41RF200 v4.0 (c) 2004 Scott Baxter
Registration
Registration is the process by which an idle mobile lets the system know it’s awake and available for incoming calls
• this allows the system to inform the mobile’s home switch of the mobile’s current location, so that incoming calls can be delivered
• registration also allows the system to intelligently page the mobile only in the area where the mobile is currently located, thereby eliminating useless congestion on the paging channels in other areas of the system
There are many different conditions that could trigger an obligation for the mobile to register
• there are flags in the System Parameters Message which tell the mobile when it must register on the current system
November, 2004 RF200 - 42RF200 v4.0 (c) 2004 Scott Baxter
Registration
PagingChannel
AccessChannel
BTS
Registration Message (by PROBING)
Base Station Acknowledgment Order
November, 2004 RF200 - 43RF200 v4.0 (c) 2004 Scott Baxter
An Actual 1xRTT Registration
IS-95 Message Type: Registration ACK_SEQ: 7 MSG_SEQ: 5 ACK_REQ: 1 VALID_ACK: 0ESN (Electronic Serial Number):0xB38092BC IMSI Class: 0 IMSI Class 0 Type: IMSI_S only IMSI_S: 694 582 9500 Pilot Strength: -8.0 dBActive 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 1REG_ZONE: 0 TOTAL_ZONES: 0 Zone timer length (min): 1MULT_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 0°00´00.00¨ Lon., 0°00´00.00° Lat. REG_DIST: 0SRCH_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: 1Address 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 mobile’s registration message was received. We’re officially registered!
November, 2004 RF200 - 44RF200 v4.0 (c) 2004 Scott Baxter
Example 4
Let’s Receive an IncomingCall!
Let’s Receive an IncomingCall!
November, 2004 RF200 - 45RF200 v4.0 (c) 2004 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 other’s traffic channel signals and confirm their presence by exchanging acknowledgment messages.The base station and the mobile negotiate what type of call this will be -- I.e., 13k voice, etc.The mobile is told to ring and given a “calling line ID” to display.When the human user presses the send button, the audio path is completed and the call proceeds.
November, 2004 RF200 - 46RF200 v4.0 (c) 2004 Scott Baxter
Incoming Call Delivery ScenarioGeneral Page Message
PagingChannel
AccessChannel
BTS
Page Response Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Continuous frames of all 000’s
ForwardTraffic
Channel
ReverseTraffic
Channel
Traffic Channel Preamble: Frames of 000’s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
November, 2004 RF200 - 47RF200 v4.0 (c) 2004 Scott Baxter
An Actual Page and Page Response
98/05/24 23:14:46.425 [ACH] Page Response MessageMSG_LENGTH = 216 bitsMSG_TYPE = Page Response MessageACK_SEQ = 1 MSG_SEQ = 2 ACK_REQ = 1VALID_ACK = 1 ACK_TYPE = 2MSID_TYPE = IMSI and ESN MSID_LEN = 9 octetsESN = 0xD30E415C IMSI_CLASS = 0IMSI_CLASS_0_TYPE = 0 RESERVED = 0IMSI_S = 6153300644AUTH_MODE = 1AUTHR = 0x307B5 RANDC = 0xC6 COUNT = 0MOB_TERM = 1 SLOT_CYCLE_INDEX = 0MOB_P_REV = 3 SCM = 106REQUEST_MODE = Either Wide Analog or CDMA OnlySERVICE_OPTION = 32768 PM = 0NAR_AN_CAP = 0 RESERVED = 0
PAGE RESPONSE MESSAGE
98/05/24 23:14:46.127 [PCH] General Page MessageMSG_LENGTH = 128 bits MSG_TYPE = General Page MessageCONFIG_MSG_SEQ = 1 ACC_MSG_SEQ = 20CLASS_0_DONE = 1CLASS_1_DONE = 1 RESERVED = 0BROADCAST_DONE = 1 RESERVED = 0ADD_LENGTH = 0 bits ADD_PFIELD = Field OmittedPAGE_CLASS = 0 PAGE_SUBCLASS = 0MSG_SEQ = 1 IMSI_S = 6153300644SPECIAL_SERVICE = 1SERVICE_OPTION = 32768RESERVED = Field Omitted
GENERAL PAGE MESSAGE
98/05/24 23:14:46.768 [PCH] Order MessageMSG_LENGTH = 112 bitsMSG_TYPE = Order MessageACK_SEQ = 2 MSG_SEQ = 0 ACK_REQ = 0VALID_ACK = 1 ADDR_TYPE = IMSI ADDR_LEN = 40 bitsIMSI_CLASS = 0 IMSI_CLASS_0_TYPE = 0 RESERVED = 0 IMSI_S = 6153300644ORDER = Base Station Acknowledgement OrderADD_RECORD_LEN = 0 bitsOrder-Specific Fields = Field Omitted RESERVED = 0
BASE STATION ACKNOWLEDGMENT
The system pages the mobile, 615-330-0644.
The base station confirms that the mobile’s page response was received. Now the
mobile is waiting for channel assignment,expecting a response within 12 seconds.
The mobile responds to the page.
November, 2004 RF200 - 48RF200 v4.0 (c) 2004 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: 0Mobile 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: 1MSID_TYPE: 2 IMSI: (Class: 0, Class_0_type: 0) [0x 01 f8 39 6a 15] 615-330-0644 ASSIGN_MODE: Traffic Channel AssignmentADD_RECORD_LEN: 5 FREQ_INCL: 1 GRANTED_MODE: 2CODE_CHAN: 43 FRAME_OFFSET: 2ENCRYPT_MODE: Encryption disabledBAND_CLASS: 800 MHz cellular bandCDMA_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: 0Base 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 mobile’s preamble.
The mobile station acknowledges the base station’s acknowledgment.
Everybody is ready!
November, 2004 RF200 - 49RF200 v4.0 (c) 2004 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: 0USE_TIME: 0 ACTION_TIME: 0 SERV_CON_SEQ: 0Service 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 MESSAGENow 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: 0SIGNAL_TYPE = IS-54B Alerting ALERT_PITCH = Medium Pitch (Standard Alert)SIGNAL = Long RESERVED = 0RECORD_TYPE = Calling Party NumberRECORD_LEN = 96 bitsNUMBER_TYPE = National NumberNUMBER_PLAN = ISDN/Telephony Numbering PlanPI = Presentation Allowed SI = Network ProvidedCHARi = 6153000124 RESERVED = 0 RESERVED = 0
ALERT WITH INFORMATION MESSAGE
The base station orders the mobile to ring, and gives it the calling party’s number to display.
18:14:48.018 Reverse Traffic Channel: Order ACK_SEQ: 1 MSG_SEQ: 4 ACK_REQ: 0ENCRYPTION: 0 Mobile Station Acknowledgement Order
The mobile says it’s 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.
November, 2004 RF200 - 50RF200 v4.0 (c) 2004 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.
18:14:54.758 Reverse Traffic Channel: Order ACK_SEQ: 6 MSG_SEQ: 0 ACK_REQ: 1 ENCRYPTION: 0 Connect Order
CONNECT ORDER
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
Now the switch completes the audio circuit and the two callers can talk!
November, 2004 RF200 - 51RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Let’s Make An Outgoing Call!Let’s Make An Outgoing Call!
November, 2004 RF200 - 52RF200 v4.0 (c) 2004 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 other’s traffic channel signals and confirm their presence by exchanging acknowledgment messages.The base station and the mobile negotiate what type of call this will be --I.e., 13k voice, etc.The audio circuit is completed and the mobile caller hears ringing.Supplemental channels can be requested for data bursts as needed
November, 2004 RF200 - 53RF200 v4.0 (c) 2004 Scott Baxter
Mobile-Originated Call Scenario
PagingChannel
AccessChannel
BTS
Origination Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Continuous frames of all 000’s
ForwardTraffic
Channel
ReverseTraffic
Channel
Traffic Channel Preamble: Frames of 000’s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
November, 2004 RF200 - 54RF200 v4.0 (c) 2004 Scott Baxter
1xRTT OriginationMSG_LENGTH 36 octets PD, 1, P_REV_IN_USE >= 6MSG_ID, 4, Origination Message LAC_LENGTH 13 octetsACK_SEQ 7 MSG_SEQ 0 ACK_REQ 1 VALID_ACK 0 ACK_TYP, 0 MSID_TYPE, 3, IMSI and ESN MSID_LEN, 9, 9 octetsESN, 0x9F 5C BB F5, 2673654773IMSI_CLASS, 0, IMSI_CLASS_0_TYPE, 0, IMSI_S includedRESERVED, 0, IMSI_S, 0x03 C8 87 79 AF, 9132209814AUTH_MODE, 0, 0 LAC_PADDING, 0, ACTIVE_PILOT_STRENGTH, 5, -2.50 dBFIRST_IS_ACTIVE, 1, Yes MOB_TERM, 1, YesSLOT_CYCLE_INDEX 2 512 MOB_P_REV 6 IS-2000 Rev 0SCM 234 BandClass 1DualMode Slotted Continuous Class IIIREQUEST_MODE, 1, CDMA Only SPECIAL_SERVICE YesSERVICE_OPTION, 33, Std: 144kbps PacketData, IP or ISOPM, 0, No DIGIT_MODE, 0, 4-bit DTMF CodesMORE_FIELDS, 0, No NUM_FIELDS, 4, Character, CHARi, 12, #, 7, 7, 7, 7 7, 7NAR_AN_CAP, 0, No PACA_REORIG, 0, User Directed OriginationRETURN_CAUSE, 0, Normal AccessMORE_RECORDS, 0, PACA_SUPPORTED, 0, NoNUM_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, YesENHANCED_RC, 1, Yes FOR_RC_PREF, 3, REV_RC_PREF, 3, FCH_SUPPORTED, 1, YesFCH_FRAME_SIZE, 0, Supports only 20 ms Frame SizesFOR_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, NoREV_FCH_LEN, 2, R-RC1, 1, Yes R-RC2, 1, Yes R-RC3, 1, Yes R-RC4, 1, Yes R-RC5, 0, NoDCCH_SUPPORTED, 0, No ENC_INFO_INCL, 0, NoSYNC_ID_INCL, 1, Yes SYNC_ID, error, error: 16 bit field, 6 bits available RESERVED, 0,
ORIGINATION MESSAGE
MSG_LENGTH, 16, 16 octetsPD, 0, P_REV_IN_USE < 6MSG_TYPE, 7, Order MessageACK_SEQ, 0, MSG_SEQ, 0, ACK_REQ, 0, NoVALID_ACK, 1, YesADDR_TYPE, 2, IMSIADDR_LEN, 7, 7 octetsIMSI_CLASS, 0, IMSI_CLASS_0_TYPE, 3, IMSI_S, IMSI_11_12, and MCC includedRESERVED, 0, MCC, 209, 310IMSI_11_12, 99, 00IMSI_S, 0x03 C8 87 79 AF, 9132209814ORDER, 16, Base Station Acknowledgement OrderADD_RECORD_LEN, 0, 0 octetsRESERVED, 0,
BASE STATION ACKNOWLEDGMENT
The mobile sends an origination message
on the access channel.
The base station confirms that the
origination message was
received.
November, 2004 RF200 - 55RF200 v4.0 (c) 2004 Scott Baxter
Traffic Channel Assignment
EXTENDEDCHANNEL ASSIGNMENT MESSAGE
MSG_LENGTH, 30, 30 octetsPD, 0, P_REV_IN_USE < 6MSG_TYPE, 21, Extended Channel Assignment MessageACK_SEQ, 0, MSG_SEQ, 1, ACK_REQ, 0, NoVALID_ACK, 1, Yes ADDR_TYPE, 2, IMSIADDR_LEN, 7, 7 octets IMSI_CLASS, 0, CLASS_0_TYPE, 3, IMSI_S, IMSI_11_12, and MCC includedRESERVED, 0, MCC, 209, 310 IMSI, IMSI_11_12, 99, 00IMSI_S, 0x03 C8 87 79 AF, 9132209814RESERVED_1, 0, ADD_RECORD_LEN, 14, 13 octetsASSIGN_MODE, 0, Traffic Channel AssignmentRESERVED_2, 0, FREQ_INCL, 1, YesDEFAULT_CONFIG, 4, ReservedBYPASS_ALERT_ANSWER, 0, NoRESERVED, 0, NUM_PILOTS, 0, 1 PilotsGRANTED_MODE, 0, FRAME_OFFSET, 15, 18.75 msENCRYPT_MODE, 0, Encryption DisabledBAND_CLASS, 1, 1.850 to 1.990 GHz BandCDMA_FREQ, 274, PILOT_PN, 240, PWR_COMB_IND, 0, No CODE_CHAN, 17, FOR_FCH_RC, 3, RC 3 REV_FCH_RC, 3, RC 3FPC_FCH_INIT_SETPT, 56, 7.000 dBFPC_FCH_FER, 0, 0.2%FPC_FCH_MIN_SETPT, 2, 0.250 dBFPC_FCH_MIN_SETPT, 4, 0.500 dBFPC_SUBCHAN_GAIN, 7, 0 dBRLGAIN_ADJ, 8, 8 dBREV_FCH_GATING_MODE, 0, No RESERVED, 0,
The base station sends a Channel Assignment
Message and the mobile goes to the traffic channel.
November, 2004 RF200 - 56RF200 v4.0 (c) 2004 Scott Baxter
Traffic Channel Confirmation
MSG_LENGTH, 8, 8 octets MSG_TYPE, 1, Order MessageACK_SEQ, 0, MSG_SEQ, 1, ACK_REQ, 1, YesENCRYPTION, 0, Encryption DisabledUSE_TIME, 0, No ACTION_TIME, 0, 0 msORDER, 16, Mobile Station Acknowledgement OrderADD_RECORD_LEN, 0, 0 octets RESERVED, 0,
MOBILE STATION ACKNOWLEDGMENTMSG_LENGTH, 8, 8 octets MSG_TYPE, 1, Order MessageACK_SEQ, 7, MSG_SEQ, 0, ACK_REQ, 1, YesENCRYPTION, 0, Encryption DisabledUSE_TIME, 0, No ACTION_TIME, 0, 0 msORDER, 16, Base Station Acknowledgement OrderADD_RECORD_LEN, 0, 0 octets RESERVED, 0,
BASE STATION ACKNOWLEDGMENT
The base station is alreadysending 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 mobile station acknowledges the base station’s acknowledgment.
Everybody is ready!
The base station acknowledges receiving the mobile’s preamble.
November, 2004 RF200 - 57RF200 v4.0 (c) 2004 Scott Baxter
Status Request/Response
MSG_LENGTH 44 MSG_TYPE, 16, Status Response MessageACK_SEQ, 1, MSG_SEQ, 0, ACK_REQ, 0 ENCRYPTION 0 QUAL_INFO_TYPE, 0, None QUAL_INFO_LEN 0 octetsRECORD_TYPE 27, Reserved RECORD_LEN 9 octetsOTD_SUPPORTED, 0, No FCH_SUPPORTED, 1, YesFCH_FRAME_SIZE, 0, FOR_FCH_LEN 2 RC1:1 RC2:1 RC3:1 RC4:1 RC5:1 RC6: 0REV_FCH_LEN 2 RC1:1RC2:1 RC3:1 RC4:1 RC5:0 RC6: 0DCCH_SUPPORTED 0 No FOR_SCH_SUPPORTED 1 Yes FOR_SCH_LEN 2 RC1:0 RC2:0 RC3:1 RC4:1 RC5:0 RC6:0FOR_SCH_NUM, 1, FOR_TURBO_SUPPORTED 0 FOR_CONV_SUPPORTED 1FOR_MAX_CONV_BLOCK_SIZE 4 RS1: 3048, RS 2: 4584FOR_FRAME_40_SUPPORTED 0 FOR_FRAME_80_SUPPORTED 0FOR_MAX_RATE, 0, 9.6 kbps or 14.4 kbpsREV_SCH_SUPPORTED, 1, YesREV_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: 4584REV_FRAME_40_SUPPORTED 0 REV_FRAME_80_SUPPORTED 0REV_MAX_RATE, 0, 9.6 kbps or 14.4 kbpsNONOCTET_ALIGNED_DATA 0 OCTET_ALIGNED_DATA 0STS_SUPPORTED, 0, No 3X_CCH_SUPPORTED, 0, NoRECORD_TYPE 14 Band Class Information RECORD_LEN 12BAND_CLASS_0:0 BAND_CLASS_1: 0 BAND_CLASS_2: 0BAND_CLASS_3: 1 BAND_CLASS_4: 0 BAND_CLASS_5: 0BAND_CLASS_6: 0 BAND_CLASS_7: 0RECORD_TYPE, 0, Reserved RECORD_LEN, 15, 15 octetsRESERVED128 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 MESSAGEMSG_LENGTH, 9 octets MSG_TYPE, 16, Status Request MessageACK_SEQ, 7, MSG_SEQ, 1, ACK_REQ, 1, YesENCRYPTION, 0, Encryption DisabledQUAL_INFO_TYPE, 0, None QUAL_INFO_LEN, 0, 0 octetsNUM_FIELDS, 2, RECORD_TYPE, 27, ReservedRECORD_TYPE, 28, Channel Configuration Capability Information
STATUS REQUEST
MSG_LENGTH, 7, 7 octets MSG_TYPE, 1, Order MessageACK_SEQ 3, MSG_SEQ 4, ACK_REQ 0, ENCRYPTION 0ORDER, 16, Base Station Acknowledgement OrderADD_RECORD_LEN, 0 CON_REF_INCL, 0, No RESERVED, 0,
BASE STATION ACKNOWLEDGMENT
November, 2004 RF200 - 58RF200 v4.0 (c) 2004 Scott Baxter
Status Response MessageSTATUS RESPONSE MESSAGE
MSG_LENGTH 66 MSG_TYPE, 16, Status Response MessageACK_SEQ 2, MSG_SEQ 3, ACK_REQ 0, ENCRYPTION 0QUAL_INFO_TYPE 2, BAND_CLASS+OP_MODE QUAL_INFO_LEN 2BAND_CLASS, 0, 800 MHz Cellular BandOP_MODE, 1, TIA/EIA/IS-95 CDMA Mode In Band Class 0RESERVED, 0, RECORD_TYPE, 8, Terminal Info RECORD_LEN 55MOB_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 IIILOCAL_CTRL, 0, No SLOT_CYCLE_INDEX, 2, 5.12SERVICE_OPTION, 32770, QUALCOMM: 8K Markov OldSERVICE_OPTION, 32796, QUALCOMM: 13K Markov OldSERVICE_OPTION, 32798, QUALCOMM: 8K Markov NewSERVICE_OPTION, 32799, QUALCOMM: 13K Markov NewSERVICE_OPTION, 2, Standard: 8K LoopbackSERVICE_OPTION, 9, Standard: 13K LoopbackSERVICE_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 13KSERVICE_OPTION, 17, Standard: High Rate Voice (13 kbps)SERVICE_OPTION, 3, Standard: EVRC (8 kbps)SERVICE_OPTION, 32776, AT&T: UnknownSERVICE_OPTION, 32, Standard: Test Data Service Option (TDSO)SERVICE_OPTION, 33, Standard: 144kbps PacketData, Internet or ISO ProtocolSERVICE_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 StackSERVICE_OPTION, 7, Standard: PDS Internet or ISO Protocol StackSERVICE_OPTION, 4, Standard: Asynchronous Data ServiceSERVICE_OPTION, 12, Standard: DataSERVICE_OPTION, 5, Standard: Group 3 Facsimile (9.6kbps)SERVICE_OPTION, 13, Standard: Group 3 Facsimile (14.4 or 9.6kbps)RESERVED, 0, RESERVED, 0,
November, 2004 RF200 - 59RF200 v4.0 (c) 2004 Scott Baxter
Service RequestSERVICE REQUEST MSG.
MSG_LENGTH 38 MSG_TYPE, 12, Service Request MessageACK_SEQ 0 MSG_SEQ 0 ACK_REQ 1 ENCRYPTION 0SERV_REQ_SEQ 0 REQ_PURPOSE 2 Propose A Service ConfigurationRECORD_TYPE 19 Service Configuration Information RECORD_LEN 30FOR_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 ProtocolFOR_TRAFFIC, 1, SO Uses Primary Traffic On FTCREV_TRAFFIC, 1, SO Uses Primary Traffic On RTCUI_ENCRYPT_MODE, 0, User Information Encryption DisabledSR_ID, 1, RLP_INFO_INCL, 1, Yes RLP_BLOB_LEN, 5, 5 octetsRLP_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 msFOR_FCH_RC, 3, RC 3 REV_FCH_RC, 3, RC 3DCCH_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 octetsSCH_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 allowedCoding Type, CODING, 0, Convolutional CodingFRAME_40_USED, 0, No FRAME_80_USED, 0, NoMAX_RATE, 0, 9.6 kbps or 14.4 kbps REV_SCH_CC_INCL, 1, YesNUM_REV_SCH, 1, REV_SCH_ID, 0, REV_SCH_MUX, 2321, SCH_REC_LEN, 2, 2 octetsSCH_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 pilotCoding Type, CODING, 0, Convolutional CodingFRAME_40_USED, 0, No FRAME_80_USED, 0, NoMAX_RATE, 0, 9.6 kbps or 14.4 kbps RESERVED, 0,
November, 2004 RF200 - 60RF200 v4.0 (c) 2004 Scott Baxter
Service Connect/Service Connect Complete
MSG_LENGTH 6 MSG_TYPE 14 Service Connect Completion MessageACK_SEQ 4, MSG_SEQ 1, ACK_REQ 1, ENCRYPTION 0RESERVED, 0, SERV_CON_SEQ, 0, RESERVED, 0,
SERVICE CONNECT COMPLETE
MSG_LENGTH 42 MSG_TYPE, 20, Service Connect MessageACK_SEQ 0 MSG_SEQ 4 ACK_REQ 1 ENCRYPTION 0USE_TIME 0 ACTION_TIME 0ms SERV_CON_SEQ 0 RESERVED, 0, USE_OLD_SERV_CONFIG, 0, RECORD_TYPE, 7, Service Configuration RECORD_LEN 30FOR_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 1RESERVED 0 NUM_CON_REC 1 RECORD_LEN 12 CON_REF, 1, SERVICE_OPTION 33 Std:144kbps PacketData Internet or ISO ProtocolFOR_TRAFFIC, 1, SO Uses Primary Traffic On FTCREV_TRAFFIC, 1, SO Uses Primary Traffic On RTCUI_ENCRYPT_MODE, 0, User Information Encryption DisabledSR_ID, 1, RLP_INFO_INCL, 1, Yes RLP_BLOB_LEN, 5, 5 octetsRLP_BLOB, 0x2C 0D 94 CA 60, QOS_PARMS_INCL, 0, NoRESERVED, 0, FCH_CC_INCL, 1, Yes FCH_FRAME_SIZE, 0, NoFOR_FCH_RC 3 RC 3 REV_FCH_RC 3 RC 3 DCCH_CC_INCL, 0,NoFOR_SCH_CC_INCL, 1, Yes NUM_FOR_SCH, 1, FOR_SCH_ID, 0, FOR_SCH_MUX, 2321, SCH_REC_LEN, 2, 2 octetsSCH_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 allowedCODING, 0, Convolutional CodingFRAME_40_USED, 0, No FRAME_80_USED, 0, NoMAX_RATE, 0, 9.6 kbps or 14.4 kbpsREV_SCH_CC_INCL, 1, Yes NUM_REV_SCH, 1, REV_SCH_ID, 0, REV_SCH_MUX, 2321, SCH_REC_LEN, 2, 2 octetsSCH_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 pilotCoding Type, CODING, 0, Convolutional CodingFRAME_40_USED, 0, No FRAME_80_USED, 0, NoMAX_RATE, 0, 9.6 kbps or 14.4 kbps RESERVED, 0, RECORD_TYPE, 19, Non-Negotiable Service ConfigurationRECORD_LEN1 FPC_INCL 0 GATING_RATE_INCL 0FOR_SCH_INCL, 0, No USE_FLEX_NUM_BITS, 0, NoUSE_VAR_RATE, 0, No LTU_INFO_INC, 0, No RESERVED, 0, CC_INFO_INCL, 0, No
SERVICE CONNECT MESSAGE
November, 2004 RF200 - 61RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Let's Upload Data!Let's Upload Data!
November, 2004 RF200 - 62RF200 v4.0 (c) 2004 Scott Baxter
Reverse Supplemental Channel Assignment
November, 2004 RF200 - 63RF200 v4.0 (c) 2004 Scott Baxter
BTS
W1
W32
W0
PAGING
SYNC
PILOT
W23 F-FCH
ACCESS CHANNEL
R-FCH
SSSSSSSSSSSSSSSSSSSSSSSSSSS
GK KS P C GP K KSAGK KSAK
Mobile: Send Walsh Code 1
Starting in 320 ms For 1000 ms.
Mobile: Send Walsh Code 1
Starting in 320 ms For 1000 ms.
ESCAM ESCAM
NNKG K SGP SA GK KS P C GP K KSAGK KSAK NNKG K SGP SA GK KS P CP KGK KSAK NNKG K SGP SA
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSPN 168
TIME
R-SCH SupplementalChannel Burst
SupplementalChannel Burst
SCRM SCRM
System: I need toSend you the
Following blocks:
System: I need toSend you the
Following blocks:
Reverse Link Supplemental Channel BurstSUPPLEMENTAL CHANNEL
REQUEST MESSAGE
November, 2004 RF200 - 64RF200 v4.0 (c) 2004 Scott Baxter
000281, Time 17:26:11.217, Record 2810, QcpCdmaLogMsgForTrafChanMSG_TYPE: Extended Supplemental Channel Assignment MessageACK_SEQ: 5 MSG_SEQ: 2 ACK_REQ: NoENCRYPTION: Encryption DisabledSTART_TIME_UNIT: 0 msREV_SCH_DTX_DURATION: 200 msUSE_T_ADD_ABORT: No USE_SCRM_SEQ_NUM: NoADD_INFO_INCL: YesFPC_PRI_CHAN: Forward Fundamental Channel inner loop estimationREV_CFG_INCLUDED: YesNUM_REV_CFG_RECS: 0 REV_SCH_ID: 0REV_WALSH_ID: Forward Dedicated Control Channel inner loop estimationREV_SCH_NUM_BITS_IDX: RC 1,3,5=1512; RC 2,4,6=2280; 12 CRC bitsNUM_REV_SCH: 1 REV_SCH_ID: 0REV_SCH_DURATION: ReservedREV_SCH_START_TIME_INCL: YesREV_SCH_START_TIME: 21REV_SCH_NUM_BITS_IDX: RC 1,3,5=1512; RC 2,4,6=2280; 12 CRC bitsFOR_CFG_INCLUDED: NoNUM_FOR_SCH: 0FPC_INCL: No RPC_INCL: Yes RPC_NUM_SUP: 0 SCH_ID: 0RLGAIN_SCH_PILOT: 1.000000 dB3X_SCH_INFO_INCL: NoCCSH_INCLUDED: NoFOR_SCH_CC_INCL: error: 1 bit field, 0 bits availableREV_SCH_CC_INCL: error: no bits available
EXTENDED SUPPLEMENTALCHANNEL ASSIGNMENT
MESSAGE000280, Time 17:26:11.063, Record 2783, QcpCdmaLogMsgRevTrafChanMSG_TYPE: Supplemental Channel Request MessageACK_SEQ: 1MSG_SEQ: 6ACK_REQ: NoENCRYPTION: Encryption DisabledSIZE_OF_REQ_BLOB: 3 bytesREQ_BLOB: 228REQ_BLOB: 39REQ_BLOB: 255USE_SCRM_SEQ_NUM: NoREF_PN: 236PILOT_STRENGTH: -4.50 dBNUM_ACT_PN: 0NUM_NGHBR_PN: 0RESERVED: 0
000284, Time 17:26:11.691, Record 2893, QcpCdmaLogMsgRevTrafChanMSG_TYPE: Supplemental Channel Request MessageACK_SEQ: 1MSG_SEQ: 6ACK_REQ: YesENCRYPTION: Encryption DisabledSIZE_OF_REQ_BLOB: 0 bytesUSE_SCRM_SEQ_NUM: NoRESERVED: 0
Course RF200
Let's Download Data!Let's Download Data!
November, 2004 RF200 - 65RF200 v4.0 (c) 2004 Scott Baxter
Forward Supplemental Channel Assignment
November, 2004 RF200 - 66RF200 v4.0 (c) 2004 Scott Baxter
BTS
W1
W32
W0
PAGING
SYNC
PILOT
W23 F-FCH ESCAM
W2 F-SCH SupplementalChannel Burst
ESCAM
SupplementalChannel Burst
Mobile: Watch Walsh Code 2
Starting in 320 ms For 1000 ms.
Mobile: Watch Walsh Code 2
Starting in 320 ms For 1000 ms.
SSSSSSSSSSSSSSSSSSSSSSSSSSS
GK KS P C GP K KSAGK KSAK NNKG K SGP SA GK KS P C GP K KSAGK KSAK NNKG K SGP SA GK KS P CP KGK KSAK NNKG K SGP SA
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSPN 168
TIME
ACCESS CHANNEL
R-FCH
Assigning a Forward Supplemental Channel BurstEXTENDED SUPPLEMENTAL
CHANNEL ASSIGNMENTMESSAGE
005878, Time 17:34:48.913, Record 105364, QcpCdmaLogMsgForTrafChanMSG_TYPE: Extended Supplemental Channel Assignment MessageACK_SEQ: 0 MSG_SEQ: 1 ACK_REQ: NoENCRYPTION: Encryption DisabledSTART_TIME_UNIT: 0 msREV_SCH_DTX_DURATION: 200 msUSE_T_ADD_ABORT: NoUSE_SCRM_SEQ_NUM: NoADD_INFO_INCL: YesFPC_PRI_CHAN: Forward Fundamental Channel inner loop estimationREV_CFG_INCLUDED: No NUM_REV_SCH: 0FOR_CFG_INCLUDED: Yes FOR_SCH_FER_REP: YesNUM_FOR_CFG_RECS: 0 FOR_SCH_ID: 0 SCCL_INDEX: 0FOR_SCH_NUM_BITS_IDX: RC 1,3,4,6,7=3048; RC 2,5,8,9=4584; 12 CRC bitsNUM_SUP_SHO: 0 PILOT_PN: 112 ADD_PILOT_REC_INCL: NoCODE_CHAN_SCH: 3 QOF_MASK_ID_SCH: 0 (rot 256 bit)NUM_FOR_SCH: 1 FOR_SCH_ID: 0 FOR_SCH_DURATION: 320 msFOR_SCH_START_TIME_INCL: Yes FOR_SCH_START_TIME: 17SCCL_INDEX: 0 FPC_INCL: Yes FPC_MODE_SCH: 1FPC_SCH_INIT_SETPT_OP: FPC_SCH_INIT_SETPT has Offset value of initial F-SCH Eb/Nt setpoint FPC_SEC_CHAN: 0 NUM_SUP: 1 SCH_ID: 0FPC_SCH_FER: 0.5% - 10% (in units of 0.5%)FPC_SCH_INIT_SETPT: 5.000 dBFPC_SCH_MIN_SETPT: 2.000 dBFPC_SCH_MAX_SETPT: 8.000 dBFPC_THRESH_SCH_INCL: No RPC_INCL: No3X_SCH_INFO_INCL: No CCSH_INCLUDED: NoFOR_SCH_CC_INCL: No REV_SCH_CC_INCL: NoRESERVED: 0
November, 2004 RF200 - 67RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Let’s End A Call!Let’s End A Call!
November, 2004 RF200 - 68RF200 v4.0 (c) 2004 Scott Baxter
A Beautiful End to a Normal Call
MOBILE RELEASE ORDER008091, Time 17:39:26.108, Record 167760, QcpCdmaLogMsgRevTrafChanMSG_TYPE: Order MessageACK_SEQ: 4MSG_SEQ: 1ACK_REQ: NoENCRYPTION: Encryption DisabledORDER: Release Order (Normal Release)ADD_RECORD_LEN: 0 octetsRESERVED: 0
BASE STATION ACKNOWLEDGMENT008090, Time 17:39:26.020, Record 167747, QcpCdmaLogMsgForTrafChanMSG_TYPE: Order MessageACK_SEQ: 5MSG_SEQ: 2ACK_REQ: NoENCRYPTION: Encryption DisabledUSE_TIME: NoACTION_TIME: 0 msORDER: Release Order (No Reason Given)ADD_RECORD_LEN: 0 octetsRESERVED: 0
SYNC CHANNEL MESSAGEThe mobile left the traffic channel,
scanned to find the best pilot, and read the Sync Channel Message.
008092, Time 17:39:26.514, Record 167820, QcpCdmaLogMsgSyncChanMSG_TYPE: Sync Channel MessageP_REV: IS-95BMIN_P_REV: IS-95ASID: 179NID: 0PILOT_PN: 468LC_STATE: 0x02 87 7C F3 7F BASYS_TIME: 06/29/2002 06:15:19LP_SEC: 13LTM_OFF: -660 minutes
November, 2004 RF200 - 69RF200 v4.0 (c) 2004 Scott Baxter
An Aeronautical Analogy: Investigation Tools
Control & Parameters Messaging
BTS
1150011500
114.50118.25130.75
AeronauticalInvestigations
CDMAInvestigations
Flight Data Recorder Cockpit Voice Recorder
Temporal Analyzer Data Layer 3 Message Files
To study the cause of an aeronautical accident, we try to recover the Flight Data Recorder and the Cockpit Voice Recorder.
To study the cause of a CDMA call processing accident, we review data from the Temporal Analyzer and the Layer 3 Message Files -- for the same reasons.
November, 2004 RF200 - 70RF200 v4.0 (c) 2004 Scott Baxter
Example 8
Let’s Do A Handoff!Let’s Do A Handoff!
November, 2004 RF200 - 71RF200 v4.0 (c) 2004 Scott Baxter
Basic 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
65
Remaining
ActiveCandidateNeighbor 20
PILOT SETS
Min. M
embers
Req’d. B
y Std.
T_COMPT_ADD T_DROPT_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.
November, 2004 RF200 - 72RF200 v4.0 (c) 2004 Scott Baxter
The Call is Already Established. What Next?E
c/Io
All PN Offsets
0
032K
512Chips
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.
T_ADD
Rake Fingers
Reference PN
Active Pilot
10752
16832002
50014080
220
! !
Mobile Rake RX
Srch PN??? W0
F1 PN168 W61F2 PN168 W61F3 PN168 W61
If we ever notice a neighbor with Ec/Io above T_ADD,ask to use it! Send a Pilot Strength Measurement Message!
November, 2004 RF200 - 73RF200 v4.0 (c) 2004 Scott Baxter
ForwardTraffic
Channel
ReverseTraffic
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 fromanother 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
November, 2004 RF200 - 74RF200 v4.0 (c) 2004 Scott Baxter
Mobile Requests the Handoff!
PILOT STRENGTH MEASUREMENT MESSAGE98/05/24 23:14:02.205 [RTC] Pilot Strength Measurement MessageMSG_LENGTH = 128 bitsMSG_TYPE = Pilot Strength Measurement MessageACK_SEQ = 5 MSG_SEQ = 0 ACK_REQ = 1ENCRYPTION = Encryption Mode DisabledREF_PN = 168 Offset Index (the Reference PN)PILOT_STRENGTH = -6.0 dBKEEP = 1PILOT_PN_PHASE = 14080 chips (PN220+0chips)PILOT_STRENGTH = -12.5 dBKEEP = 1PILOT_PN_PHASE = 32002 chips (PN500 + 2 chips)PILOT_STRENGTH = -11.0 dBKEEP = 1RESERVED = 0
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.
98/05/24 23:14:02.386 [FTC] Order MessageMSG_LENGTH = 64 bitsMSG_TYPE = Order MessageACK_SEQ = 0 MSG_SEQ = 0 ACK_REQ = 0ENCRYPTION = Encryption Mode DisabledUSE_TIME = 0 ACTION_TIME = 0ORDER = Base Station Acknowledgment OrderADD_RECORD_LEN = 0 bitsOrder-Specific Fields = Field Omitted RESERVED = 0
BASE STATION ACKNOWLEDGMENT
The base station acknowledges receiving the Pilot Strength Measurement Message.
November, 2004 RF200 - 75RF200 v4.0 (c) 2004 Scott Baxter
System Authorizes the Handoff!
98/05/24 23:14:02.926 [FTC] Extended Handoff Direction MessageMSG_LENGTH = 136 bitsMSG_TYPE = Extended Handoff Direction MessageACK_SEQ = 0 MSG_SEQ = 6 ACK_REQ = 1ENCRYPTION = Encryption Mode DisabledUSE_TIME = 0 ACTION_TIME = 0 HDM_SEQ = 0SEARCH_INCLUDED = 1 SRCH_WIN_A = 40 PN chipsT_ADD = -13.0 dB T_DROP = -15.0 dB T_COMP = 2.5 dBT_TDROP = 4 secHARD_INCLUDED = 0 FRAME_OFFSET = Field OmittedPRIVATE_LCM = Field Omitted RESET_L2 = Field OmittedRESET_FPC = Field Omitted RESERVED = Field OmittedENCRYPT_MODE = Field Omitted RESERVED = Field OmittedNOM_PWR = Field Omitted NUM_PREAMBLE = Field OmittedBAND_CLASS = Field Omitted CDMA_FREQ = Field OmittedADD_LENGTH = 0PILOT_PN = 168 PWR_COMB_IND = 0 CODE_CHAN = 61PILOT_PN = 220 PWR_COMB_IND = 1 CODE_CHAN = 20PILOT_PN = 500 PWR_COMB_IND = 0 CODE_CHAN = 50RESERVED = 0
HANDOFF DIRECTION MESSAGEThe base station sends a HandofDirection 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 MessageMSG_LENGTH = 56 bits MSG_TYPE = Order MessageACK_SEQ = 6 MSG_SEQ = 6 ACK_REQ = 0ENCRYPTION = Encryption Mode DisabledORDER = Mobile Station Acknowledgment OrderADD_RECORD_LEN = 0 bitsOrder-Specific Fields = Field Omitted RESERVED = 0
MOBILE STATION ACKNOWLEDGMENT
November, 2004 RF200 - 76RF200 v4.0 (c) 2004 Scott Baxter
Mobile Implements the Handoff!
98/05/24 23:14:02.985 [RTC] Handoff Completion MessageMSG_LENGTH = 72 bits MSG_TYPE = Handoff Completion MessageACK_SEQ = 6 MSG_SEQ = 1 ACK_REQ = 1ENCRYPTION = Encryption Mode DisabledLAST_HDM_SEQ = 0PILOT_PN = 168 Offset IndexPILOT_PN = 220 Offset IndexPILOT_PN = 500 Offset IndexRESERVED = 0
HANDOFF COMPLETION MESSAGE
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 ACKNOWLEDGMENTThe base station confirms it has received the mobile’s 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
November, 2004 RF200 - 77RF200 v4.0 (c) 2004 Scott Baxter
Neighbor List Updated, Handoff is Complete!
98/05/24 23:14:03.245 [RTC] Order MessageMSG_LENGTH = 56 bits MSG_TYPE = Order MessageACK_SEQ = 7 MSG_SEQ = 7 ACK_REQ = 0ENCRYPTION = Encryption Mode DisabledORDER = Mobile Station Acknowledgement OrderADD_RECORD_LEN = 0 bitsOrder-Specific Fields = Field OmittedRESERVED = 0
MOBILE STATION ACKNOWLEDGMENT
98/05/24 23:14:03.166 [FTC] Neighbor List Update MessageMSG_LENGTH = 192 bitsMSG_TYPE = Neighbor List Update MessageACK_SEQ = 1 MSG_SEQ = 7 ACK_REQ = 1ENCRYPTION = Encryption Mode DisabledPILOT_INC = 4 Offset IndexNGHBR_PN = 164 Offset IndexNGHBR_PN = 68 Offset IndexNGHBR_PN = 52 Offset IndexNGHBR_PN = 176 Offset IndexNGHBR_PN = 304 Offset IndexNGHBR_PN = 136 Offset IndexNGHBR_PN = 112 Offset IndexNGHBR_PN = 372 Offset IndexNGHBR_PN = 36 Offset IndexNGHBR_PN = 8 Offset IndexNGHBR_PN = 384 Offset IndexNGHBR_PN = 216 Offset IndexNGHBR_PN = 328 Offset IndexNGHBR_PN = 332 Offset IndexNGHBR_PN = 400 Offset IndexNGHBR_PN = 96 Offset IndexRESERVED = 0
NEIGHBOR LIST UPDATE MESSAGE
In response to the mobile’s 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.
November, 2004 RF200 - 78RF200 v4.0 (c) 2004 Scott Baxter
Handoff Now In Effect, but still check Pilots!E
c/Io
All PN Offsets
0
032K
512Chips
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
Reference PN
Active Set
10752
16832002
50014080
220
T_DROP
Mobile Rake RX
Srch PN??? W0
F1 PN168 W61F2 PN500 W50F3 PN220 W20
November, 2004 RF200 - 79RF200 v4.0 (c) 2004 Scott Baxter
The Complete Picture of Handoff & Pilot Sets
T_ADD
Ec/
IoAll PN Offsets
00
32K512
ChipsPN
0
-20
Neighbor Set
SRCH_WIN_N
Active Set
Candidate SetT_DROP
SRCH_WIN_A
Remaining SetT_ADD
SRCH_WIN_R
SRCH_WIN_A
T_DROP
Rake Fingers
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 W61F2 PN500 W50F3 PN220 W20
November, 2004 RF200 - 80RF200 v4.0 (c) 2004 Scott Baxter
Improved Handoff Controlin 1xRTT
Improved Handoff Controlin 1xRTT
November, 2004 RF200 - 81RF200 v4.0 (c) 2004 Scott Baxter
The IS-95 Situation
IS-95 handoff is driven by fixed thresholds of pilot strength (Ec/Io)If the mobile notices a new pilot stronger than T_Add, it asks for it immediatelyIf an active pilot drops below T_Drop and stays below for T_Tdrop seconds, the mobile asks for permission to stop using itThe mobile has no discretion – the T_Addand T_Drop values apply no matter what
0
-5
-10
-15
-20
Ec/Io
TH
RES
HO
LDS,
db
T_ADD
T_DROP
November, 2004 RF200 - 82RF200 v4.0 (c) 2004 Scott Baxter
Disadvantages of Standard Handoff Triggers
Pilo
t Stre
ngth
(Ec/
Io, d
b)
-3
-20
All Six sectors in
soft handoff!
T_AddActive
Active
ActiveActiveActiveActive
Mobile requests soft handoff with all pilots above T_Add• This occasionally leads to some
rigid, less-than-optimum decisions!Problem Situation 1• One dominant, strong signal and a
lot of weak ones:– Mobile asks for them all, but
only one is really needed!Problem Situation 2• Heavy pilot pollution, many signals
lurk barely below the threshold– Mobile starts call on the best
one, but never asks for handoffs with any others
– mobile needs handoff to survive! Four -16 signals are as good as a single -10 signal!!
Pilo
t Stre
ngth
(Ec/
Io, d
b)
-3
-20
Only One Sector in soft
handoff!
T_AddActive
November, 2004 RF200 - 83RF200 v4.0 (c) 2004 Scott Baxter
1xRTT Allows Dynamic Handoff Thresholds
A handoff process more intelligent than fixed thresholds• Handoff events driven by smarter, situation-influenced triggers
Candidate Set Removal: if that sector isn’t worth adding anymore
Neighbor-to-Active transition: only if it’s a worthwhile improvement
Removal from Active Set: if that sector isn’t needed anymore
November, 2004 RF200 - 84RF200 v4.0 (c) 2004 Scott Baxter
Standard Equation of a Line
The equation of a straight line is pretty simple. It includes
• y, the vertical-axis value• m, the slope of the line
– the ratio of rise/run• x, the horizontal-axis value• b, the y intercept
– the value of y where the line crosses the y axis
y = mx + b
slop
e
inte
rcep
t
x
y
b
November, 2004 RF200 - 85RF200 v4.0 (c) 2004 Scott Baxter
The Dynamic Handoff Threshold Line
CombinedEc/Io
of ExistingActive Pilots
0
-5
-10
-15
-20
-5-10-15-20COMBINED Ec/Io, db
Ec/Io
TH
RES
HO
LDS,
db
+5
+10
AddIntercept
T_Add
November, 2004 RF200 - 86RF200 v4.0 (c) 2004 Scott Baxter
The Dynamic Handoff Threshold Line
CombinedEc/Io
of ExistingActive Pilots
0
-5
-10
-15
-20
-5-10-15-20COMBINED Ec/Io, db
Ec/Io
TH
RES
HO
LDS,
db
+5
+10
DropIntercept
T_Drop
November, 2004 RF200 - 87RF200 v4.0 (c) 2004 Scott Baxter
The Dynamic Handoff Threshold Line
CombinedEc/Io
of ExistingActive Pilots
0
-5
-10
-15
-20
-5-10-15-20COMBINED Ec/Io, db
Ec/Io
TH
RES
HO
LDS,
db
+5
+10
AddIntercept
T_Add
DropIntercept
T_Drop
November, 2004 RF200 - 88RF200 v4.0 (c) 2004 Scott Baxter
Section G
Deeper Handoff Details:Search Windows & TimingDeeper Handoff Details:
Search Windows & Timing
November, 2004 RF200 - 89RF200 v4.0 (c) 2004 Scott Baxter
The Pilot Searcher’s Measurement Process
The searcher checks pilots in nested loops, much like meshed gears. Actives and candidatesoccupy the fastest-spinning wheel. Neighbors are next, advancingone pilot for each Act+Cand. revolution.Remaining is slowest, advancing one pilot each time the Neighbors revolve.
CURRENT PILOT SET CONTENTSA 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
31
12112
PILOT SEARCHER VIEWED IN SEQUENCE: Typical Elapsed Time = 4 secondsA 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 CN 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 CN N N N N
A A A CN A A A C A A A C A A A C A A A C A A A C A A A CN N N N N N
N A A A C A A A C A A A CN N N R A A A C N A A A C A A A C A A AN N
C A A A C A A A CN N N
R
A A A C N A A A C A A A C A A AN N C A A AN
C A A A CN N Only 3 of 112 remaining set pilots have been checked thus far!
A
N
R
R
R
R
R
R
R
NN
N
N
NN N N
AA
November, 2004 RF200 - 90RF200 v4.0 (c) 2004 Scott Baxter
A Quick Primer on Pilot Search WindowsPROPAGATION DELAY
SKEWS APPARENT PN OFFSETS
BTSBTSA
B
33Chips
4 Chips
If the phone is locked to BTS A, thesignal from BTS B will seem 29 chipsearlier than expected.If the phone is locked to BTS B, thesignal from BTS A will seem 29 chipslater than expected.
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 PNsPropagation delay “skews” the apparent PN offsets of all other sectors, making them seem earlier or later than expectedTo 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 offsetSearch 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
November, 2004 RF200 - 91RF200 v4.0 (c) 2004 Scott Baxter
Setting Pilot Search Window SizesWhen 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 intercelldistances which a mobile might experience
SEARCH WINDOW SETTINGSAND PROPAGATION DISTANCES
Window Size (Chips)
14 (±7)
DatafillValue
N,R Delta Distance
4 1.0620 (±10)
40 (±20)28 (±14)
Miles KM.
56789101112131415
60 (±30)80 (±40)
100 (±50)130 (±65)160 (±80)226 (±113)320 (±160)452 (±226)
1.711.52 2.442.12 3.423.03 4.884.55 7.326.07 9.777.59 12.29.86 15.912.1 19.517.1 27.624.3 39.134.3 55.2
November, 2004 RF200 - 92RF200 v4.0 (c) 2004 Scott Baxter
Handoff Problems: “Window” Dropped Calls
A
B
1 mi.7 Chips
BTS
BTS
SITUATION 1 Locked to distant site, can’t see
one nearby12 miles80 ChipsSRCH_WIN_N = 130BTS A is reference.BTS B appears (7-80) chipsearly due to its closer distance.This is outside the 65-chip window.Mobile can’t see BTS B’s pilot, but its strong signal blinds us and the call drops.
Travel
mountains
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 2Locked to nearby
site, can’t see distant one12 miles80 Chips
Travel
SRCH_WIN_N = 130BTS B is reference.BTS A appears (80-7) chipslate due to its farther distance.This is outside the 65-chip window.Mobile can’t see BTS A’s pilot.
mountains
November, 2004 RF200 - 93RF200 v4.0 (c) 2004 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/sectorsIf 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)
November, 2004 RF200 - 94RF200 v4.0 (c) 2004 Scott Baxter
Meet the CDMA Performance Indicators
Meet the CDMA Performance Indicators
November, 2004 RF200 - 95RF200 v4.0 (c) 2004 Scott Baxter
CDMA Performance IndicatorsA 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
November, 2004 RF200 - 96RF200 v4.0 (c) 2004 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 100Forward
Reverse
FER is the end-result of the whole transmission link• if FER is good, then any other problems aren’t having much
effect• if FER is bad, that’s not the problem - it is just the end-result of
the problem– we must investigate other indicators to get a clue what is
going on
November, 2004 RF200 - 97RF200 v4.0 (c) 2004 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, notjust RF from serving BTS
-40
-90
-105
<<to
o w
eak
ove
rload
>>
RX Level
≈ x
LO
≈
RX Level(from AGC)
IFLNA
BW~30
MHz.
BW1.25MHz.
Handset Receiver
R
R
R
S
Rake
Receive power is important, but it’s exact value isn’t critical• too much received signal (-35 dbm or higher) could drive the
phone’s sensitive first amplifier into overload, causing intermodand 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
November, 2004 RF200 - 98RF200 v4.0 (c) 2004 Scott Baxter
Indicator #3, Ec/Io - What does it mean?
Why can’t we just use the handset’s received power level to guide handoffs?
• Because it is a simple total RF power measurement, the total of all sectors reaching the mobile
≈ x
LO
≈
RX Level(from AGC)
IFLNA
BW~30
MHz.
BW1.25MHz.
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 simplyThe solution is to use each sector’s pilot (Walsh 0) as a test signal to guide handoffs
• At the mobile, if the pilot of a certain sector is very strong and clean, that means we also should be able to hear a traffic channel on that sector, so handoff would be a good idea
• if the pilot of a certain sector is weak, then we probably won’t be able to get much benefit from using a traffic channel on thatsector
November, 2004 RF200 - 99RF200 v4.0 (c) 2004 Scott Baxter
How Ec/Io Varies with Traffic Loading
Light Traffic LoadingEach sector transmits a certain amount of power, the sum of:
• pilot, sync, and paging• any traffic channels in use
at that momentEc/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.
2w
1.5w
Pilot
PagingSync I0EC
0.5w
Heavily Loaded
Ec/Io = (2/10)= 20%
= -7 db.
2w
1.5w
Pilot
PagingSync
I0
EC
Traffic Channels
6w
0.5w
November, 2004 RF200 - 100RF200 v4.0 (c) 2004 Scott Baxter
How Ec/Io varies with RF Environment
Many Sectors, Nobody Dominant
One Sector DominantIn a “clean situation”, one sector is dominant and the mobile enjoys an Ec/Io just as good as it was when transmittedIn “pilot pollution”, too many sectors overlap and the mobile hears a “soup” made up of all their signals
• Io is the power sum of all the signals reaching the mobile
• Ec is the energy of a single sector’s pilot
• The large Io overrides the weak Ec; Ec/Io is low!
Io = -90 dbmEc = -96 dbmEc/Io = -6 db
Io = 10 signalseach -90 dbm
= -80 dbmEc of any onesector = -96
Ec/Io = -16 db
2w
1.5w
Pilot
PagingSync
I0
ECTraffic
Channels
4w
0.5w
BTS1
I0
EC
BTS2
BTS3
BTS4
BTS5
BTS6
BTS7
BTS8
BTS9
BTS10
PilotSync & Paging
TrafficPilot
Sync & PagingTraffic
PilotSync & Paging
TrafficPilot
Sync & PagingTraffic
PilotSync & Paging
TrafficPilot
Sync & PagingTraffic
PilotSync & Paging
TrafficPilot
Sync & PagingTraffic
PilotSync & Paging
TrafficPilot
Sync & PagingTraffic
November, 2004 RF200 - 101RF200 v4.0 (c) 2004 Scott Baxter
Indicator #4: Handset Transmitter Power
TXPODUP x ≈ IF
LNA
Subscriber Handset
R
R
R
S
Rake
Σ ViterbiDecoder
Vocoder
∼
FECOrthMod
Long PN
xx
xIF Mod
I
Q
x ~LO Open Loop
LO
Closed Loop Pwr Ctrl
IF
Receiver>>
<<Transmitter
PA
BTSTXPO Handset Transmit Power• Actual RF power output of the
handset transmitter, including combined effects of open loop power control from receiver AGC and closed loop power control by BTS
• can’t exceed handset’s maximum (typ. +23 dBm)
Typical TXPO:+23 dBm in a coverage hole0 dBm near middle of cell-50 dBm up close to BTS
TXPO = -(RXdbm) -C + TXGAC = +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 phone’s opinion
isn’t the last word. Just do what the BTS wants!!• However, if the BTS ever asks the phone to do the impossible,
something is wrong (lower than -60 dbm, higher than +23 dbm)
November, 2004 RF200 - 102RF200 v4.0 (c) 2004 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 station’s latest new
decision: mobile is too strong, or mobile is too weak -- there is no cumulative error, since each decision is “fresh”
0 dB
-10 dB
-20 dB
Typical Transmit Gain Adjust
Time, Seconds
TXPO = -(RXdbm) -C + TXGAC = +73 for 800 MHz. systems= +76 for 1900 MHz. systems
November, 2004 RF200 - 103RF200 v4.0 (c) 2004 Scott Baxter
Closed Loop Power Control Dynamics
The figures at right show the power control reactions to a sudden change in path lossThe sudden change in path loss causes a sudden change in handset received signalBoth open loop and closed loop control race to get the phone back to the right new power and succeed in about 10 millisecondsOpen loop continues to approach the correct value better and better on its own40 milliseconds later, no net closed loop correction is needed.
November, 2004 RF200 - 104RF200 v4.0 (c) 2004 Scott Baxter
Section Identification
Problem “Signatures”Problem “Signatures”
November, 2004 RF200 - 105RF200 v4.0 (c) 2004 Scott Baxter
“Signatures” of Common Conditions
SIGNATURE: GOOD CALL
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
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.
November, 2004 RF200 - 106RF200 v4.0 (c) 2004 Scott Baxter
Signature of a Successful Call
SIGNATURE: GOOD CALL
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
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.
November, 2004 RF200 - 107RF200 v4.0 (c) 2004 Scott Baxter
Signature of a Dropped Call in Poor Coverage
SIGNATURE: DROPPED CALL, BAD COVERAGE
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
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
November, 2004 RF200 - 108RF200 v4.0 (c) 2004 Scott Baxter
Signature of Forward Link Interference
SIGNATURE: FORWARD LINK INTERFERENCE
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
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.
November, 2004 RF200 - 109RF200 v4.0 (c) 2004 Scott Baxter
A CDMA Drop Example: Forward Link Case
A
BBTS
BTS
FORWARD LINK DIES
Obstructio
ns
Travel
B grows stronger and stronger.Mobile’s open-loop instinct is to transmit weaker; closed-loop correction from A goes higher and higher, maintaining the mobile at the right power.Finally B obscures A, which disappears in an explosion of FER. The mobile mutes since it can’t hear power control bits, and a fade timer or message timer kills the call in a few seconds.
A mobile using Site A comes down the highway and suddenly begins to see the signal of Site BIf the mobile begins soft handoff with site B, everything continues to go wellIf the mobile cannot begin handoff with B for any reason, the call is doomed
• site B’s signal will override site A’s signal, making it unreadable
• as soon as the FER goes too high, a fade timer will start the the mobile will eventually die
November, 2004 RF200 - 110RF200 v4.0 (c) 2004 Scott Baxter
Signature of Reverse Link Interference
SIGNATURE: REVERSE LINK INTERFERENCE
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
Characteristics of data for a phone whose BTS has a raised noise floor due to reverse link interference
• Good forward FER• Good receive power (> -100 dBm)• Good Ec/Io (> -10 dB)• Higher-than-normal Transmit Gain
Adjust• Higher-than-normal transmit power
(< +20 dBm)• Poor reverse link messaging
– in the message files, you’ll see repeats of messages on the forward link and reverse link
November, 2004 RF200 - 111RF200 v4.0 (c) 2004 Scott Baxter
A CDMA Drop Example: Reverse Link Case
BBTS
Obstructio
ns
Travel
It was a beautiful day in the neighborhood for all the mobiles on site B until the grim reaper arrived, transmitting at high power to maintain its link with distant Cell A.Cell B tried to power up each of its individual mobiles so they would be received as strong as the new interferor, but mobiles more distant than the interferor just couldn’t keep up, and died.Eventually the interferor died from forward link interference, too.If only the interferor had a soft handoff, all of this violence could have been avoided.
REVERSE LINK DIESWhen 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
November, 2004 RF200 - 112RF200 v4.0 (c) 2004 Scott Baxter
Solving the #1 Death Scenario: Failed Handoff
Why didn’t the mobile ask for handoff?• New sector not on neighbor list• Neighbor Search Window too Small?• BTS in “island mode”, wrong PN?
Why didn’t the BTS set up the handoff?• Old BTS didn’t hear mobile – rev link
interf?• No resources available on new BTS?• T-1 unstable, messages lost
Why didn’t the mobile do the handoff?• Couldn’t hear BTS, Fwd link interf?
BBTS Obstru
ctions
Travel
REVERSE LINK DIESAB
BTS
BTS
FORWARD LINK DIES
Obstructio
ns
TravelSteps in the Handoff ProcessMobile’s searcher notices the needed new pilot
Mobile sends PSMM requesting handoff
System sets up the handoff:•channel elements•forward power•space in packet pipesSimulcasting begins!
System tells mobile how to hear the new sectors: Handoff Direction Message
Mobile confirms completion:Handoff Completion MessageSystem 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??!
November, 2004 RF200 - 113RF200 v4.0 (c) 2004 Scott Baxter
Pilot Pollution
Io
Ec/Io value at each BTS TX
-80.0 -3
Signal Strength Ec/Io
-90 -13.0 1-90 -13.0 2-90 -13.0 3-90 -13.0 4-90 -13.0 5-90 -13.0 6-90 -13.0 7-90 -13.0 8-90 -13.0 9-90 -13.0 10
-80.0 Sum Power
Ec/Io of Multiple CDMA Signals
1 2 3 4 5 6 7 8 9 10
When a large number of CDMA signals are received at about the same strength, they cause severe interference to each other
• this is called Pilot Pollution
The cure for pilot pollution is to eliminate unneeded signals which really weren’t intended to serve this location anyway, and to boost the one or a few signals which were intended to serve this locationSee the first page of the workbook ECIOPLAY.XLS
Io
Ec/Io value at each BTS TX
-73.9 -3
Signal Strength Ec/Io
-90 -19.1 1-90 -19.1 2-90 -19.1 3-90 -19.1 4-75 -4.1 5-90 -19.1 6-90 -19.1 7-90 -19.1 8-90 -19.1 9-90 -19.1 10
-73.9 Sum Power
Ec/Io of Multiple CDMA Signals
1 2 3 4 5 6 7 8 9 10
November, 2004 RF200 - 114RF200 v4.0 (c) 2004 Scott Baxter
Pilot Pollution/Handoff/Composite Ec/Io Demo
See the second page of the workbook ECIOPLAY.XLS
Ec/Io, Handoff, and Rake Finger Pilot Status
%Pilot Power
% Over-head Power
Nominal Max Power W
Sum RF Power Io
Composite Ec/Io
Max # Lockable Rake Fingers
Max # Pilots in Soft Handoff T_ADD
10% 20% 12 -86.2 -3.0 3 6 -12
Traffic Loading %
Transmitted Ec/Io
Path Loss, dB
Signal Strength Ec/Io
0% -3.0 120 -86.2 -3.0 Rake Locked Handoff 10% -3.0 200 -166.2 -83.0 Interferor 20% -3.0 200 -166.2 -83.0 Interferor 30% -3.0 200 -166.2 -83.0 Interferor 40% -3.0 200 -166.2 -83.0 Interferor 50% -3.0 200 -166.2 -83.0 Interferor 60% -3.0 200 -166.2 -83.0 Interferor 70% -3.0 200 -166.2 -83.0 Interferor 80% -3.0 200 -166.2 -83.0 Interferor 90% -3.0 200 -166.2 -83.0 Interferor 100% -3.0 200 -166.2 -83.0 Interferor 110% -3.0 200 -166.2 -83.0 Interferor 120% -3.0 200 -166.2 -83.0 Interferor 130% -3.0 200 -166.2 -83.0 Interferor 14
Only grey-shaded fields can be changed. Other fields calculate automatically.To unlock all cells, select TOOLS>PROTECTION>UNPROTECT SHEET.
Relative Energies of Multiple CDMA Signals
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ind ivid ual Sig nals
Pilot Energy Sync, Paging, Traf f ic
November, 2004 RF200 - 115RF200 v4.0 (c) 2004 Scott Baxter
System Performance Optimization
Basic PN Planning andSearch Window Considerations
Basic PN Planning andSearch Window Considerations
November, 2004 RF200 - 116RF200 v4.0 (c) 2004 Scott Baxter
Introduction to PN Planning and Search Windows
In PN planning and setting Search Windows, several pitfalls mustbe avoided. These slides explain most of the basic facts, background, principles, and practical considerations involved.
November, 2004 RF200 - 117RF200 v4.0 (c) 2004 Scott Baxter
Short PN Basics: PN Offsets Distinguish Sectors
A
B
C
D
≈ x
LO
IFLNA
BPF
PhoneRake Receiver
≈BPF
PN A Walsh X
PN B Walsh Y
PN C Walsh Z
Pilot Searcher
∑ Decoding Vocoderx
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 offsetsIn 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
November, 2004 RF200 - 118RF200 v4.0 (c) 2004 Scott Baxter
A Practical "Rule of Thumb" to RememberTransmitted:PN 100
6,400 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 later than what the mobile sees. So the base station's signal at the mobile seems to be one PN lower than it was actually transmitted.
Received:PN 101
6,464 chips delay
The signal of a base station roughly 10 miles distant will SEEM to be one PN higher than it was transmitted
November, 2004 RF200 - 119RF200 v4.0 (c) 2004 Scott Baxter
Propagation Delay changes apparent PN Offset
10 KM41 chips
2 KM8 chips
PN200
PN360
Base stations transmit signals on assigned, fixed short PN delays called PN OffsetsTransmitted signals encounter additional delay traveling to the mobile
• ~6.7 chips/mile = ~4.1 chips/kilometerThese 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
November, 2004 RF200 - 120RF200 v4.0 (c) 2004 Scott Baxter
Mobile Timing: the Reference PN
Mobile System Acquisition ProcessScan entire range of PNsLock 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
Reference PN
Active Pilot
Ec/
Io
00
32K512
ChipsPN
Pilot Searcher Scans All PNs
All PN Offsets0
-20
98/05/24 23:14:09.817 [SCH] MSG_LENGTH = 208 bitsMSG_TYPE = Sync Channel MsgP_REV = 3, MIN_P_REV = 2SID = 179 NID = 0PILOT_PN = 168 Offset IndexLC_STATE = 0x0348D60E013SYS_TIME = 98/05/24 3:14:10.160LP_SEC = 12LTM_OFF = -300 minutesDAYLT = 0, PRAT = 9600 bps
SYNC CHANNEL MESSAGE
UNKNOWN EXTRA PROPAGATION DELAY
How many chips????
November, 2004 RF200 - 121RF200 v4.0 (c) 2004 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 measureThese "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 KM41 chips
2 KM8 chips
PN200
PN360
360
+41
+8
360+33c
SRCH_WIN_N
November, 2004 RF200 - 122RF200 v4.0 (c) 2004 Scott Baxter
What Search Window Values Can Be Set?
SRCH_WIN_val0123456789
101112131415
Width, Chips4 (±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)
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 rightRemember 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
November, 2004 RF200 - 123RF200 v4.0 (c) 2004 Scott Baxter
Search Window Settings: Neighbor SetNeighbor Search Window
Example
10 KM41 chips
2 KM8 chips
PN200
PN360
360
+41
+8
360+33c
SRCH_WIN_N
The neighbor search window must be set wide enough to include the energy of any needed neighbor pilotThe mobile at right is using PN200 as its reference (and only active) pilotTo 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 mobileThe closest search window setting above 66 chips is SRCH_WIN_N = 9, which is 80 chips wide
ActiveSector
NeighborSector
November, 2004 RF200 - 124RF200 v4.0 (c) 2004 Scott Baxter
Worst-Case Wide Neighbor Window Situation
BTS A
BTS B
12 miles
1/2mile
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 handoffThis 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
November, 2004 RF200 - 125RF200 v4.0 (c) 2004 Scott Baxter
Safe Initial Neighbor Search Window ValueExamine a cell map for an area of your systemIdentify 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
skewRefer to table to convert required window size in chips to required value of SRCH_WIN_NAfter 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 = 10If 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
FD
November, 2004 RF200 - 126RF200 v4.0 (c) 2004 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 windowRecommended SRCH_WIN_R is one or two steps greater than SRCH_WIN_NRemaining 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 stationsThere 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
FD
November, 2004 RF200 - 127RF200 v4.0 (c) 2004 Scott Baxter
Search Window Initial Settings: Active Set
Neighbor and Remaining search window centers are indexed against the mobile’s Reference PNEach active search window is different – a “floating” window centered over the earliest observed multipath energy during the previous mobile searcher scan of that individual pilotActive 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 spreadsMultipath delay spreads are determined by terrain and clutter-driven scattering and reflection of the signalMeasurements are better than predictions to set SRCH_WIN_A
The earliest arriving multipathseen 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
Ec/Io
November, 2004 RF200 - 128RF200 v4.0 (c) 2004 Scott Baxter
SRCH_WIN_A Settings from Measurements
Typical active set delay spread from actual drive-testsNotice the narrow distribution of energy!28-chip width, SRCH_WIN_A = 6, is enough for this caseDrive-test your own system to determine your own value of spread• It is determined by the signal-scattering characteristics of your terrain
November, 2004 RF200 - 129RF200 v4.0 (c) 2004 Scott Baxter
SRCH_WIN_A Special Consideration
There is a dynamic relationship between mobile reference timing stability and the active and neighbor search window sizesThe chart above shows which combinations of SRCH_WIN_A and SRCH_WIN_N are safe and stable for all mobiles
SRCH_WIN_A, Chips
2010No
14No
20No
28No
40No
60No
28 No No No No No No40 No No No No Yes No60 No No No Yes Yes Yes80 No No No Yes Yes Yes100 No Yes Yes Yes Yes Yes130 Yes Yes Yes Yes Yes Yes160 Yes Yes Yes Yes Yes Yes226 Yes Yes Yes Yes Yes Yes
SR
CH
_WIN
_N, C
hips
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
November, 2004 RF200 - 130RF200 v4.0 (c) 2004 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 FERCombining unintended signals into the handoff mix being heard
• The new signals cause interference instead of helpingMistaken identity of signals when requesting handoff
• The wrong base station is added, the mobile can't hear itRunning out of available PNs due to bad parameter choices
Fortunately, these problems can be avoided by careful planning!
November, 2004 RF200 - 131RF200 v4.0 (c) 2004 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 indistinguishableIt would be smart to assign PNs farther apart!If properly set, PILOT_INC can prevent this problem
• Only PNs divisible by PILOT_INC are allowed to be assigned to sectors
PILOT_INC can be chosen from 1 to 16• If too small, interfering PNs can be assigned• If too large, the pool of available PNs is small
PILOT_INC is set based on the density of cells• 3 or 4 in typical cities with suburban density• 2 in dense urban environments• 6 or 8 in very rural areas
D
November, 2004 RF200 - 132RF200 v4.0 (c) 2004 Scott Baxter
Co-Active PN Demodulation Errors
BTS BPN 142
BTS APN 142
x miles x miles
ACTIVE SEARCH WINDOW
Mobile is midway between two BTSs with the same PN, in a call on BTS APN energy of BTS A and B is indistinguishable in active search windowRake fingers may be assigned to both A and B energy
• If the walsh code used on A also happens to be in use by someone on BTS B, demodulation of B will cause severe FER
• The mobile audio will frequently clip and mute, and the call may drop• All the while, the phone will see very good Ec/Io since both A and B
are recognized as good energy!Solution: Two different BTS covering the same area should never have the same PN offset. Change the PN offset for one of the sectors involved.
November, 2004 RF200 - 133RF200 v4.0 (c) 2004 Scott Baxter
Adjacent-Active-PN Demodulation ErrorsBTS BPN 99
BTS APN 100
1 mile 11 miles
ACTIVE SEARCH WINDOW
Mobile is in a call on BTS A from 1 mile away; A is the reference PNThe signal from BTS B on PN 99 travels 11 miles to the mobile and is approximately as strong as BTS A due to terrain effectsDue 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 callSolution: The PNs of the two BTSs are too close together. Use a different PN offset for BTS B.
November, 2004 RF200 - 134RF200 v4.0 (c) 2004 Scott Baxter
Adjacent-Neighbor PN Recognition ErrorsBTS A
PN 100
BTS
BTS
mountains
BTS
BTS FPN 200
BTS GPN 198
X
20 miles
NEIGHBOR SEARCH WINDOW
Mobile is in a call on BTS A, PN 100Mobile checks neighbor PN 200 to see if handoff needed with BTS FEnergy 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 FThe 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
November, 2004 RF200 - 135RF200 v4.0 (c) 2004 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 cellsAssign PNs in sequence to the sectors of all the base stationsCommon Usage: This is the typical default method used in Nortel and Motorola CDMA networksAdvantage
• 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
November, 2004 RF200 - 136RF200 v4.0 (c) 2004 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 incrementCommon Usage: default in Lucent networksAdvantage: 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
November, 2004 RF200 - 137RF200 v4.0 (c) 2004 Scott Baxter
Course RF200 Section II.
Introduction to CDMAPerformance Data
Introduction to CDMAPerformance Data
November, 2004 RF200 - 138RF200 v4.0 (c) 2004 Scott Baxter
What Data is Available for Performance Study?
Access Mgr./BSC-BSMSwitch BTS
CDSU DISCO
Ch. Card ACC
ΣαΣβΣχ
TFU1GPSR
CDSUCDSU
DISCO 1DISCO 2
SBSVocodersSelectors
CDSUCDSUCDSUCDSUCDSUCDSU
CMSLM
LPP LPPENET
DTCs
DMS-BUS
Txcvr ATxcvr BTxcvr C
RFFE ARFFE BRFFE C
TFU1GPSR
IOC
BSM
Data AnalysisPost-Processing
Tools
IS-95/J Std 8 Messages
IS-95/J Std 8 Messages
NOIS Messages
QC-Specific Messages
Switch OMs,pegs, logs
Mobile DataPost-Processing
Tools
Mobile Data Capture ToolsSelector
Logs
NMIS Messages
HandsetMessages
ExternalAnalysis
Tools
PC-based
PC-based
Unix-based,PC-basedVarious
CDMA NETWORK EQUIPMENT HANDSET
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 dataData contains messages and various indicators of RF performance
November, 2004 RF200 - 139RF200 v4.0 (c) 2004 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 softwareThe 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
November, 2004 RF200 - 140RF200 v4.0 (c) 2004 Scott Baxter
System Data andStatistical AnalysisSystem Data and
Statistical Analysis
November, 2004 RF200 - 141RF200 v4.0 (c) 2004 Scott Baxter
Statistical CDMA Performance Indicators
Dropped Call StatisticsFailed Access AttemptsBlocking 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.
November, 2004 RF200 - 142RF200 v4.0 (c) 2004 Scott Baxter
Typical Network Performance
MTA
-Nam
e
Per
iod
Cel
ls
Cal
l-Att.
Cal
l-Suc
c.
%-S
ucc.
Tot
al-B
lock
%To
t-Blo
ck
RF
Acc-
Fail s
%R
F A
cc-F
ail
Cal
ls-D
rop
%-D
rop
Scr
een
Calls
% S
cree
n Ca
l
Example H Week ALL 1,147,447 1,123,308 97.9% 443 0.04% 12,429 1.1% 20,015 1.7% 11,229 1.0%Average of Others 96.1% 2.1% 2.8% 2.1% 0.6%
Comparing All Systems Sorted By Daily Traffic LevelExample System D Day All 1,338,386 1,240,937 92.7% 44,593 3.33% 35,329 2.64% 30,576 2.28% n/a n/aExample System E Day All 355,247 347,325 97.8% n/a n/a 7,922 2.23% n/a n/a n/a n/aExample System B Day All 227,257 222,425 97.9% 388 0.17% 4,444 1.96% n/a n/a n/a n/aExample System C Day All 220,707 205,766 93.2% 6,312 2.86% 6,090 2.76% 5,088 2.31% n/a n/aExample System A Day All 209,621 205,461 98.0% n/a n/a n/a n/a 3,297 1.60% 1,327 0.6%Example System F Day All 206,482 198,945 96.4% n/a n/a 7,537 3.65% 4,556 2.29% n/a n/aExample System H Day ALL 163,921 160,473 97.9% 63 0.04% 1,776 1.1% 2,859 1.7% 1,604 1.0%Example System G Day All 148,765 143,633 96.6% n/a n/a 5,132 3.45% 3,074 2.14% n/a n/a
Here is a comparison of typical network performance in the industry against a new rural wireless system with light loadingHow does your system compare against the industry norms? Against the lightly loaded rural system?
November, 2004 RF200 - 143RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 144RF200 v4.0 (c) 2004 Scott Baxter
Another Network Performance Example
Lucent System Data Examples
Lucent System Data Examples
November, 2004 RF200 - 145RF200 v4.0 (c) 2004 Scott Baxter
Lucent System Data Examples
Sys/ECP/Ce ll/Name/Labe l TOTALS
179 2 67 SMIT HSPRING
S 179 2 10 BOBCAT
179 2 28 INGLEWOO
D
179 2 30 NOLENSVIL
LE
179 2 121 CLARKSVILLE/BRILEY
179 2 1 T EXT RON
179 2 45 FARMERS
%CDMA Est Ca lls 96.83 93.55 93.58 94.18 94.36 94.44 94.67 94.73ReAcquir e d_Ca lls 2.84 3.22 2.61 3.89 2.38 5.26 2.65 2.06
CCE erlangs 6,580.44 62.60 128.68 71.45 63.54 36.16 76.37 115.21CDMA_CE Usage 2,368,959 22,535 46,323 25,722 22,873 13,016 27,494 41,476Prim_CS CE_Use 1,451,816 9,300 19,788 13,689 11,113 8,448 15,965 23,219
%Prim_CS CE_Use 61.28 41.27 42.72 53.22 48.59 64.90 58.07 55.98Sec_CS CE_Use 917,143 13,235 26,535 12,033 11,760 4,568 11,529 18,257%CDMA SoftHO Use 38.72 58.73 57.28 46.78 51.41 35.10 41.93 44.02%CDMA SUFa il 2.79 6.14 5.68 5.44 3.62 3.68 4.64 5.04CDMA Lost_Ca ll 1,722 15 42 20 10 64 15 35
%CDMA Lost Ca lls 1.17 1.67 2.18 1.18 0.89 5.98 0.98 1.44T otCDMA Fa ilures 7,856 95 208 143 77 108 102 206CDMAT otl Origins 5,069 65 143 89 47 73 67 141CDMAT otl T ermins 2,787 30 65 54 30 35 35 65
CDMA Maint Busy 0 0 0 0 0 0 0 0CDMAOnly PrfSz 80 0 0 0 1 0 0 0CDMA_Org T rm_Ovf 713 0 0 0 0 0 0 0
CDMA Org_Sz 109,076 680 1,500 1,236 771 828 1,229 1,862CDMA Org_Asn 105,970 659 1,454 1,197 752 786 1,192 1,824CDMA Pg_Rsp_Sz 46,720 313 611 640 445 369 430 755CDMA T rm_Asn 44,951 301 590 603 412 329 414 736CDMA Req_Alg 4,426 32 55 73 29 63 44 54
November, 2004 RF200 - 146RF200 v4.0 (c) 2004 Scott Baxter
Lucent Overload Data Examples from Autopace
Sys/ECP/Ce ll/Name /Ante nna ID/Ant_Na me TOTALS
179 2 1 T EXT RON 1
Ante nna :1
179 2 1 T EXT RON
2 Ante nna:2
179 2 1 T EXT RON
3 Antenna :3
179 2 2 BELMONT
1 Ante nna:1
179 2 2 BELMONT
2 Ante nna:2
179 2 2 BELMONT
3 Antenna :3CDMA_Acs Chn_Oc 5,921 30 28 10 27 13.00 13.00CDMA_Avg Sq_DG 1,123,466 6,187 6,157 6,088 6,168 5,016.00 4,818.00CDMA_Fwd PCOLdur 581 12 4 2 0 0.00 0.00CDMA_Fwd PCOLcnt 339 4 4 1 0 0.00 0.00
CDMA Intcpt_Msg 0 0 0 0 0 0.00 0.00CDMA_Pg Ch_Ocpn 489,506 2,771 2,763 2,754 2,795 2,756.00 2,766.00CDMA_Pk Acs_ChOc 91,989 985 563 281 563 422.00 281.00CDMA_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.00CDMA_Re v PCOLcnt 6 0 0 0 0 0.00 0.00
CDMA Re orde r_Msg 2 0 0 0 0 0.00 0.00CDMA_T f CdCh_Usg 245,143 1,360 1,188 980 953 821.00 862.00
CDMA_Jmr Det_Dur 0 0 0 0 0 0.00 0.00
November, 2004 RF200 - 147RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Data Examples
Nortel System Data Examples
November, 2004 RF200 - 148RF200 v4.0 (c) 2004 Scott Baxter
Nortel BTSC MO Attributes
Attribute Name DataType
Seq.Number
Access,Range Description
BlockedOriginationsNoTCE word16 0x0002A42
Pfull
Number of originations blocked because no idle channel elements were available
BlockedOriginationsNoFwdCap 0x0002B43
Number of originations blocked due to lack of BTS forward link excess capacity
BlockedOriginationsNoRevCap 0x0002C44
Number of originations blocked due to lack of reverse link capacity
BlockedHandoffsNoTCE 0x0002D45
Number of handoffs blocked because no idle channel elements were available
BlockedHandoffsNoFwdCap 0x0002E46
Number of handoffs blocked due to lack of BTS forward link excess capacity
BlockedHandoffsNoRevCap 0x0002F47
Number of handoffs blocked due to lack of reverse link capaicty
SuccessfulOriginations 0x0003048 Number of successful originations
SuccessfulHandoffs 0x0003149 Number of successful handoffs
word16
word16
word16
word16
word16
word16
word16
Pfull
Pfull
Pfull
Pfull
Pfull
Pfull
Pfull
Each attribute is a periodic counter maintained during the 15-minute automatic logging period.
November, 2004 RF200 - 149RF200 v4.0 (c) 2004 Scott Baxter
Nortel FA MO AttributesEach 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 soft4softer1Alpha17 NumOfTCsConfigured 2E soft4softer1Beta18 soft1softer1Alpha 2F soft4softer1Gamma19 soft1softer1Beta 30 soft4softer2AlphaBeta1A soft1softer1Gamma 31 soft4softer2BetaGamma1B soft1softer2AlphaBeta 32 soft4softer2GammaAlpha1C soft1softer2BetaGamma 33 soft4softer31D soft1softer2GammaAlpha 34 soft5softer1Alpha1E soft1softer3 35 soft5softer1Beta1F soft2softer1Alpha 36 soft5softer1Gamma20 soft2softer1Beta 37 soft5softer2AlphaBeta21 soft2softer1Gamma 38 soft5softer2BetaGamma22 soft2softer2AlphaBeta 39 soft5softer2GammaAlpha23 soft2softer2BetaGamma 3A soft6softer1Alpha24 soft2softer2GammaAlpha 3B soft6softer1Beta25 soft2softer3 3C soft6softer1Gamma26 soft3softer1Alpha 3D TimeNotInUse27 soft3softer1Beta28 soft3softer1Gamma29 soft3softer2AlphaBeta2A soft3softer2BetaGamma2B soft3softer2GammaAlpha2C soft3softer3
November, 2004 RF200 - 150RF200 v4.0 (c) 2004 Scott Baxter
Nortel BTSC MO Events
Event Report Name TypeEvent 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 TypeEvent 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.
November, 2004 RF200 - 151RF200 v4.0 (c) 2004 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|
November, 2004 RF200 - 152RF200 v4.0 (c) 2004 Scott Baxter
Nortel Selector Log File Example
=====================================================Status : OLFLR_OKRecord Type : NEIGHBOR_LIST_TUNING_DATA_ARRAYFile Offset : 414 (octal)Time Stamp : 97/10/29-00:29:25.380Record Length : 72Header Length : 51Source 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 0x2cfe821IMSI : NumDigits 15 Digits 134006043294814 (123-63-251-3692bf)ESN : 0x9f0d02acPFFlags : 0x1fSecondary Agent Id : 0x8a40FramingBytes : 0xfaaeSequence Number : 57AttributeType : 0x0256AttributeInstance : 0x0030
Log Attr -> Type : LogSBSNeighborListTuningDataArray Seq Num : 0030
LogData object contents:Data Type : NEIGHBOR_LIST_TUNING_DATA_ARRAYResource Type : OCC_SBS_RESOURCETimeStamp : 97/10/29-00:29:25.380Count : 2
Ext'dBaseId PowerCombineBit PilotStrength PNOffset+++++=========================++++=========================+++++0x018002a3 1 8 0x01040x018002a1 1 19 0x01a4=====================================================
November, 2004 RF200 - 153RF200 v4.0 (c) 2004 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|
November, 2004 RF200 - 154RF200 v4.0 (c) 2004 Scott Baxter
Motorola System Data Examples
Motorola System Data Examples
November, 2004 RF200 - 155RF200 v4.0 (c) 2004 Scott Baxter
Motorola System Data Examples
Usage OOS Orig Orig Orig Term Term Term RF RF UsaCell 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.088 1 3 426.3 146.2 154 150 2.6 10 10 0.0 3 1.9 156.088 1 4 456.9 146.2 160 156 2.5 22 22 0.0 7 3.9 150.688 1 5 448.2 146.2 163 162 0.6 18 18 0.0 4 2.2 148.688 1 6 439.5 146.2 162 159 1.9 20 20 0.0 2 1.1 144.988 1 7 439.9 146.2 160 157 1.9 14 14 0.0 5 2.9 151.788 1 8 351.6 146.2 186 182 2.2 23 23 0.0 5 2.4 100.988 1 9 397.4 146.2 164 161 1.8 20 20 0.0 3 1.7 129.688 1 10 422.5 146.2 177 174 1.7 15 15 0.0 2 1.1 132.088 1 11 402.2 146.2 183 179 2.2 22 22 0.0 1 0.5 117.788 1 12 398.2 146.2 179 176 1.7 13 13 0.0 5 2.6 124.488 1 13 447.5 146.2 163 161 1.2 26 26 0.0 11 5.9 142.188 1 14 263.5 146.2 290 83 71.4 31 19 38.7 5 4.9 49.388 1 15 307.8 146.2 264 68 74.2 36 9 75.0 3 3.9 61.588 2 2 403.1 105.9 165 162 1.8 14 14 0.0 1 0.6 135.188 2 3 477.0 105.9 163 158 3.1 18 18 0.0 3 1.7 158.188 2 4 419.4 105.8 166 161 3.0 24 24 0.0 2 1.1 132.488 2 5 445.8 105.8 174 171 1.7 14 14 0.0 7 3.8 142.388 2 6 525.1 105.8 157 155 1.3 17 17 0.0 3 1.7 181.188 2 7 422.0 105.8 165 161 2.4 18 17 5.6 1 0.6 138.488 2 8 430.3 105.8 188 183 2.7 14 14 0.0 7 3.6 127.888 2 9 419.9 105.8 167 166 0.6 12 11 8.3 6 3.4 140.788 2 10 391.0 105.3 165 164 0.6 22 22 0.0 4 2.2 125.588 2 11 443.5 105.3 174 168 3.4 11 11 0.0 5 2.8 143.888 2 12 412.5 105.3 177 171 3.4 21 21 0.0 4 2.1 125.088 2 13 394.2 105.3 196 192 2.0 16 16 0.0 6 2.9 111.688 2 14 432.0 105.3 141 139 1.4 18 18 0.0 5 3.2 163.088 2 15 388.5 105.3 178 176 1.1 17 17 0.0 2 1.0 119.5
November, 2004 RF200 - 156RF200 v4.0 (c) 2004 Scott Baxter
Metrica ExamplesMetrica Examples
November, 2004 RF200 - 157RF200 v4.0 (c) 2004 Scott Baxter
Metrica: Forward Power Overload Reports
DAILY SECTOR POWER OVERLOAD REPORTON 10/26/98 FOR ALL SECTORS IN REGION
(DAILY TOTALS)
Sector RPwrOvldDur RPwrOvlds FPwrOvldDur FPwrOvldsId. (min) Incidents (min) Incidents-------------------------------------------------------------------------------------------------VX2-ECP:2-CELL:3-SECT:3 0.85 1 0.03 1VX2-ECP:2-CELL:4-SECT:1 0.00 0 0.00 0VX2-ECP:2-CELL:4-SECT:2 0.00 0 0.35 15VX2-ECP:2-CELL:4-SECT:3 0.00 0 0.62 13VX2-ECP:2-CELL:5-SECT:1 0.00 0 0.00 0VX2-ECP:2-CELL:5-SECT:2 0.00 0 0.02 1VX2-ECP:2-CELL:6-SECT:2 0.00 0 0.00 2VX2-ECP:2-CELL:7-SECT:2 0.00 0 0.33 8VX2-ECP:2-CELL:7-SECT:3 0.00 0 0.60 18VX2-ECP:2-CELL:11-SECT:3 0.00 0 0.02 1VX2-ECP:2-CELL:12-SECT:1 0.67 1 0.00 0VX2-ECP:2-CELL:12-SECT:2 0.52 1 0.05 1VX2-ECP:2-CELL:14-SECT:1 0.00 0 0.00 1VX2-ECP:2-CELL:15-SECT:3 1.02 1 0.02 1VX2-ECP:2-CELL:16-SECT:1 0.00 0 0.28 8VX2-ECP:2-CELL:16-SECT:2 0.00 0 0.00 0VX2-ECP:2-CELL:16-SECT:3 0.00 0 0.00 0
November, 2004 RF200 - 158RF200 v4.0 (c) 2004 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)
November, 2004 RF200 - 159RF200 v4.0 (c) 2004 Scott Baxter
Metrica: Switch Traffic Statistics
DAILY MSC SWITCHED TRAFFIC REPORTON 10/26/98
(DAILY NORMALISED TOTALS/AVERAGES)
-------- Switched ------MSC Calls Failures Failure DataId. (%) (%)------------------------------------------VX1-ECP:1 158556 10637 6.71 100
MSC Traffic Calls Failures Failure DataId. Type (%) (%)--------------------------------------------------------------------------------------------VX1-ECP:1 Mobile-to-Mobile Originating (Lucent) 111 2 1.80 100VX1-ECP:1 Mobile-to-Mobile Terminating (Lucent) 2157 913 42.33 100VX1-ECP:1 Mobile Originating 128034 5772 4.51 100VX1-ECP:1 Roamer Mobile Originating (Lucent) 104015 155 0.15 100VX1-ECP:1 Roamer Mobile Terminating (Lucent) 27197 8 0.03 100VX1-ECP:1 Mobile Terminating 30522 4865 15.94 100
November, 2004 RF200 - 160RF200 v4.0 (c) 2004 Scott Baxter
Metrica: Traffic Engineering Counts
Traffic EngineeringReport Run Date: 10/27/98 Time(GMT-0): 21:02
DAILY CELL TRAFFIC REPORTON 10/26/98 FOR ALL CELLS IN REGION
(DAILY NORMALIZED TOTALS/AVERAGES)Sorted by Traffic (E)
RF ------- Traffic ------- ResvCell Channels Blk RF Loss Channel Soft Code HO HO Pwr TCC Max Fwd Rev DataID 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 100VX2020050 40 40.0 6159 0 0.0 6120 72 1.2 228.4 82.0 289.4 0 0 202 171 31 80 0 100VX2020057 42 42.0 5082 0 0.0 5037 52 1.0 215.6 97.8 267.6 1 0 199 185 31 99 0 100VX2020062 42 42.0 4755 0 0.0 4716 54 1.1 207.2 91.9 257.2 1 0 72 150 27 29 0 100VX2020011 28 28.0 3685 0 0.0 3670 38 1.0 160.8 69.5 201.3 3 0 1 75 27 1 0 100VX2020112 28 28.0 2512 0 0.0 2496 20 0.8 158.4 92.8 181.6 0 0 5 81 23 2 0 100VX2020004 42 42.0 3845 0 0.0 3822 32 0.8 154.0 47.1 208.0 1 0 58 60 26 28 0 100VX2020073 30 30.0 4182 0 0.0 4137 26 0.6 152.3 55.6 192.4 0 0 4 91 24 2 0 100VX2020078 28 28.0 3429 0 0.0 3379 26 0.8 151.1 68.7 179.3 1 0 148 65 25 3 2 100VX2020060 28 28.0 2978 0 0.0 2965 28 0.9 150.4 69.5 190.4 2 0 0 93 24 0 0 100VX2020051 42 42.0 3193 0 0.0 3174 24 0.8 144.3 66.6 172.8 0 0 0 58 24 0 0 100VX2020023 54 54.0 3330 0 0.0 3307 27 0.8 139.6 43.8 197.8 0 0 4 67 23 4 0 100VX2020007 28 28.0 3520 0 0.0 3502 28 0.8 131.6 47.9 165.9 1 0 97 74 26 26 1 100VX2020017 30 30.0 2902 0 0.0 2889 24 0.8 130.0 45.9 181.7 1 0 51 70 23 0 1 100VX2020076 28 28.0 2888 0 0.0 2867 25 0.9 129.6 54.8 174.5 0 0 312 74 22 4 1 100VX2020012 28 28.0 3313 0 0.0 3297 21 0.6 122.1 37.8 166.2 1 0 74 61 23 1 2 100VX2020016 28 28.0 3049 0 0.0 3027 18 0.6 120.8 46.5 162.1 2 0 17 44 22 8 0 100VX2020067 28 28.0 2537 0 0.0 2519 30 1.2 118.3 51.2 145.9 0 0 0 46 19 0 0 100VX2020001 28 28.0 2746 0 0.0 2737 25 0.9 114.9 42.2 150.6 0 0 0 37 22 0 0 100VX2020003 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
November, 2004 RF200 - 161RF200 v4.0 (c) 2004 Scott Baxter
Metrica: Daily Sector Traffic Reports
Traffic EngineeringReport Run Date: 10/27/98 Time(GMT-0): 21:02
DAILY SECTOR TRAFFIC REPORTON 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 OverloadName 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 8VX2-ECP:2-CELL:57-SECT:1 17:00 183 158 25 180 2 1.11 2464 10.07 51VX2-ECP:2-CELL:53-SECT:1 17:00 251 205 46 251 6 2.39 2336 9.57 4VX2-ECP:2-CELL:62-SECT:1 18:00 193 144 49 193 5 2.59 2507 9.32 8VX2-ECP:2-CELL:50-SECT:3 17:00 289 243 46 284 4 1.41 2042 8.82 74VX2-ECP:2-CELL:4-SECT:2 16:00 165 131 34 164 4 2.44 2203 8.67 15VX2-ECP:2-CELL:4-SECT:3 16:00 120 86 34 118 1 0.85 2653 8.31 36VX2-ECP:2-CELL:50-SECT:1 17:00 184 148 36 183 0 0.00 2174 8.23 2VX2-ECP:2-CELL:23-SECT:3 11:00 194 140 54 193 1 0.52 2282 8.11 0VX2-ECP:2-CELL:53-SECT:2 18:00 143 111 32 143 5 3.50 2060 8.02 2VX2-ECP:2-CELL:78-SECT:3 15:00 133 99 34 133 3 2.26 2198 7.94 1VX2-ECP:2-CELL:17-SECT:3 15:00 201 143 58 200 1 0.50 1853 7.75 0VX2-ECP:2-CELL:12-SECT:2 16:00 144 91 53 144 2 1.39 1662 7.29 3VX2-ECP:2-CELL:7-SECT:3 17:00 191 133 58 188 0 0.00 2375 7.21 28VX2-ECP:2-CELL:3-SECT:3 15:00 144 99 45 143 1 0.70 2144 7.07 2VX2-ECP:2-CELL:57-SECT:2 20:00 155 116 39 151 1 0.66 1884 7.01 2VX2-ECP:2-CELL:11-SECT:1 17:00 132 98 34 132 2 1.52 1800 6.84 0
November, 2004 RF200 - 162RF200 v4.0 (c) 2004 Scott Baxter
Metrica: Forward Power Overload Reports
DAILY SECTOR POWER OVERLOAD REPORTON 10/26/98 FOR ALL SECTORS IN REGION
(DAILY TOTALS)
Sector RPwrOvldDur RPwrOvlds FPwrOvldDur FPwrOvldsId. (min) Incidents (min) Incidents-------------------------------------------------------------------------------------------------VX2-ECP:2-CELL:3-SECT:3 0.85 1 0.03 1VX2-ECP:2-CELL:4-SECT:1 0.00 0 0.00 0VX2-ECP:2-CELL:4-SECT:2 0.00 0 0.35 15VX2-ECP:2-CELL:4-SECT:3 0.00 0 0.62 13VX2-ECP:2-CELL:5-SECT:1 0.00 0 0.00 0VX2-ECP:2-CELL:5-SECT:2 0.00 0 0.02 1VX2-ECP:2-CELL:6-SECT:2 0.00 0 0.00 2VX2-ECP:2-CELL:7-SECT:2 0.00 0 0.33 8VX2-ECP:2-CELL:7-SECT:3 0.00 0 0.60 18VX2-ECP:2-CELL:11-SECT:3 0.00 0 0.02 1VX2-ECP:2-CELL:12-SECT:1 0.67 1 0.00 0VX2-ECP:2-CELL:12-SECT:2 0.52 1 0.05 1VX2-ECP:2-CELL:14-SECT:1 0.00 0 0.00 1VX2-ECP:2-CELL:15-SECT:3 1.02 1 0.02 1VX2-ECP:2-CELL:16-SECT:1 0.00 0 0.28 8VX2-ECP:2-CELL:16-SECT:2 0.00 0 0.00 0VX2-ECP:2-CELL:16-SECT:3 0.00 0 0.00 0
November, 2004 RF200 - 163RF200 v4.0 (c) 2004 Scott Baxter
Metrica: RF Overload Blocking Estimation
DAILY ESTIMATION OF BLOCKING DUE TO RF OVERLOADON 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 overloadOrgPwrBlk = SUM(CDMA_PAF26) - OrgCS7
- Total blocked originations/terminations due to RF power overloadTotPwrBlk = (OrgPwrBlk * %Term) + OrgPwrBlk
- Percentage of call attempts blocked at the cell due to RF power overloadPwr%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 overloadTot%Blk = (TotPwrBlk + CS7 + TotTCC) / (SUM(CDMA_PAF2) + SUM(CDMA_PAF3) - CDMA_CP8 -
SUM(CDMA_PAF25)) * 100
November, 2004 RF200 - 164RF200 v4.0 (c) 2004 Scott Baxter
Metrica: RF Overload Blocking Indications
DAILY ESTIMATION OF BLOCKING DUE TO RF OVERLOADON 10/26/98 FOR ALL CELLS IN REGION
(DAILY TOTALS)
Org TotCell Rev Rev Fwd Fwd Org Ter Tot Re- Org Ter Tot Ter Org Pwr Pwr Pwr TotId. 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 0VX2020002 0 0 0 0 809 373 1182 31.6 2 18 2 20 0 0 0 2 3 0.2 1.9 0 0VX2020003 1 1 1 0 1428 603 2031 29.7 4 27 14 41 0 0 0 4 5 0.3 2.3 0 0VX2020004 0 0 28 1 2780 1065 3845 27.7 7 40 20 60 0 0 0 7 9 0.2 1.8 0 2VX2020005 0 0 1 0 544 182 726 25.1 0 6 0 6 0 0 0 0 0 0.0 0.8 0 0VX2020006 0 0 2 0 731 339 1070 31.7 0 8 7 15 0 0 0 0 0 0.0 1.4 0 0VX2020007 1 1 26 1 2493 1027 3520 29.2 5 59 15 74 0 0 0 5 6 0.2 2.3 0 1VX2020008 0 0 0 0 2056 998 3054 32.7 0 23 19 42 0 0 0 0 0 0.0 1.4 0 0VX2020009 0 0 0 0 626 212 838 25.3 3 10 2 12 0 0 0 3 4 0.4 1.9 0 0VX2020010 0 0 0 0 877 349 1226 28.5 1 31 3 34 0 0 0 1 1 0.1 2.9 0 0VX2020011 0 0 1 0 2577 1108 3685 30.1 1 60 15 75 0 0 0 1 1 0.0 2.1 0 0VX2020012 2 2 1 0 2364 949 3313 28.6 4 45 16 61 0 0 0 4 5 0.2 2.0 0 0VX2020014 0 0 1 0 670 245 915 26.8 3 11 4 15 0 0 0 3 4 0.4 2.1 0 0VX2020015 1 1 1 0 1275 596 1871 31.9 4 24 9 33 0 0 0 4 5 0.3 2.0 0 0VX2020016 0 0 8 0 2156 893 3049 29.3 4 36 8 44 0 0 0 4 5 0.2 1.6 0 0VX2020017 1 1 0 0 2091 811 2902 27.9 1 54 16 70 0 0 0 1 1 0.0 2.4 0 0VX2020018 0 0 0 0 950 393 1343 29.3 1 28 1 29 0 0 0 1 1 0.1 2.2 0 0VX2020019 0 0 1 0 1254 513 1767 29.0 0 32 9 41 0 0 0 0 0 0.0 2.3 0 0
November, 2004 RF200 - 165RF200 v4.0 (c) 2004 Scott Baxter
Analyzing System DataAnalyzing System Data
November, 2004 RF200 - 166RF200 v4.0 (c) 2004 Scott Baxter
Total Blocked Call Percentage Example
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
Perc
ent
Blkd
This is an example of a cumulative system-wide total blocked call percentage chart maintained in one market
November, 2004 RF200 - 167RF200 v4.0 (c) 2004 Scott Baxter
Dropped Call Percentage Tracking Example
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
Perc
ent
%Drops
Dropped call percentage tracking by one market
November, 2004 RF200 - 168RF200 v4.0 (c) 2004 Scott Baxter
Total System Daily MOU Example
Daily Total System MOU
0
50000
100000
150000
200000
250000
300000
Date
MO
U
Daily Total System MOU
Total system daily MOU plotted by one market
November, 2004 RF200 - 169RF200 v4.0 (c) 2004 Scott Baxter
“Top Ten” Performance Tracking ExampleCall 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.72.1 2X 2244 2017 89.9 101 4.5 101 4.5 93 4.11.2 1Y 1922 1743 90.7 83 4.3 83 4.3 66 3.464.3 93Z 1833 1549 84.5 137 7.5 136 7.4 110 6.0108.2 30Y 1740 1589 91.3 46 2.6 45 2.6 83 4.81.3 1Z 1630 1495 91.7 31 1.9 31 1.9 81 5.063.2 57Y 1623 1486 91.6 49 3.0 49 3.0 66 4.1102.2 4Y 1615 1495 92.6 18 1.1 18 1.1 70 4.3108.1 30X 1490 1387 93.1 27 1.8 27 1.8 54 3.643.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
64.3
108.
2
1.3
63.2
102.
2
108.
1
43.3
Sector
Cal
ls
% Blocked Calls September 5, 1997Eng 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.06.1 13X 2561 2234 87.2 130 5.1 130 5.1 145 5.763.3 57Z 1282 1098 85.7 65 5.1 65 5.1 90 7.02.1 2X 2244 2017 89.9 101 4.5 101 4.5 93 4.11.2 1Y 1922 1743 90.7 83 4.3 83 4.3 66 3.463.2 57Y 1623 1486 91.6 49 3.0 49 3.0 66 4.164.1 93X 1027 926 90.2 30 2.9 30 2.9 58 5.726.3 35Z 855 698 81.6 24 2.8 24 2.8 112 13.1108.2 30Y 1740 1589 91.3 46 2.6 45 2.6 83 4.81.3 1Z 1630 1495 91.7 31 1.9 31 1.9 81 5.0
0.01.02.03.04.05.06.07.08.0
64.3 6.1
63.3 2.1
1.2
63.2
64.1
26.3
108.
2
1.3
Sector%
Many markets use scripts or spreadsheet macros to produce ranked lists of sites with heavy traffic, performance problems, etc.
November, 2004 RF200 - 170RF200 v4.0 (c) 2004 Scott Baxter
“Bracketing”: Fault Notification and Alarming
SMTWT F S SMTWT F S SMTWT F S SMTWT F S SMTWT F S SMTWT F S SMTWT F S23222120191817161514131211109876543210Historic Performance Data and Automatic Alarming
Some operators develop their own software for monitoring and tracking performance dataEach new 30-minute period is compared against a six-week average for that day and timeIf the new value is outside user-selectable tolerances (typically +/- 30%), an alarm is sent to operations personnel
• By SMS or pagerThe tolerance values can be adjusted to produce reasonable numbers of alarms
• Typically 20-40 alarms per day If an important performance statistic varies
outside a user-specified range, an alarm message is sent automatically to the performance specialist
responsible for that base station.
+30%
-30%
+30%
-30%
+30%
-30%
TOO LOW NORMAL TOO HIGH
6-week average
November, 2004 RF200 - 171RF200 v4.0 (c) 2004 Scott Baxter
CDMA System ParametersCDMA System Parameters
November, 2004 RF200 - 172RF200 v4.0 (c) 2004 Scott Baxter
Lucent System ParametersLucent System Parameters
November, 2004 RF200 - 173RF200 v4.0 (c) 2004 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 179ECPID 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2CellID 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2Antenna 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 1 1 1CDMAPilotPN 4 4 4 4 4 4 172 172 172 172 172 172 340 340 340 340 340 340 8 8 8CDMAPilotDrpThrsh -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15 -15CDMAPilotDetThrsh -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13 -13CDMACompThrsh 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 2CDMADropTimer 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3CDMASrchWinActCand 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7CDMASrchWinNbr 9 9 9 9 9 9 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7CDMASrchWinRemain 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0CDMAPilotGain 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108 108CDMAPageGain 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64CDMASyncGain 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34 34CDMABCRAtt 6 6 6 6 6 6 6 6 6 6 6 6 8 8 8 8 8 8 8 8 8SectorSize_ceqfaceBBAMaxPower 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 25CDMAMinTrfChnlGain_R2CDMAMaxTrfChnlGain_R2CDMATrafGain_R2CDMAFwdFrmErrRate_R2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1CDMARevFrmErrRate_R2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1CDMANomEbNoSetPt_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.8CDMAMinEbNoSetPt_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.8CDMAMaxEbNoSetPt_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.8Srchwincell 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
November, 2004 RF200 - 174RF200 v4.0 (c) 2004 Scott Baxter
Nortel System ParametersNortel System Parameters
November, 2004 RF200 - 175RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Parameters Example
Proto type datafill for 1900 CDMA System Parameters
Parameter Name Range Recommended Value Remarks
1. CDMA Channel ParametersSystem Determination and Acquisition
CDMA_ AVAIL 0 - 1 1CDMA_FREQ (CDMA_CHAN) 0 - 2047 See Remarks As determined by the local MTABAND_CLASS 0 - 31 1 1900 MHz
System Acquisition (Sync channel Information)P_REV 0-255 1MIN_P_REV 0-255 1SID 0 - 32,767 See Remarks As determined by the local MTANID 0 - 65,535 See Remarks As determined by the local MTAPILOT_PN 0 - 511 See Remarks As determined by the local MTALC_STATE See Remarks Determined by the system. TBASYS_TIME TFU_1 or TFU_2 See Remarks As detetermined by the System timePRAT 0-3 1 LP_SEC 0-255 13 TBALTM_OFF 0-63 16 TBADAYLT 0 - 1 0 or 1 Depending on whether Daylight saving is On/Off
Nortel parameters are built in files on the BSM, then downloadedto BTS and SBS locations
November, 2004 RF200 - 176RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Parameters Example2. Access ParametersRequest Response Parameters
PSIST(0-9) 0 - 63 0 ACCOLC(0 -9) are all permitted to transmitPSIST(10-15) 0 - 7 0 ACCOLC(10 -15) are all permitted to transmitMAX_CAP_SZ 0 - 7 3 3 Frames messagePAM_SZ 0 - 15 4 4 Frames preambleREG_PSIST 0 - 7 0MSG_PSIST 0 - 7 0PROBE_PN_RAN 0 - 15 0ACC_CHAN 0 - 31 0 1 Access channelACC_TMO 0 - 15 (x80 ms) 3 (2+1), 240 msPROBE_BKOFF 0 - 15 0 (0 + 1) slot delayBKOFF 0 - 15 1 (0 + 1) slot delayMAX_REQ_SEQ 0 - 15 2MAX_RSP_SEQ 0 - 15 2AUTH 0 - 3 0 No standard AuthenticationRAND 0-(232-1) 0 Not applicable without Authentication
Parameters here determine contents of Access Parameters Message on the Paging Channel
November, 2004 RF200 - 177RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Parameters ExampleRegistaration Parameters
SID 0 - 32,767 See Remarks As determined by the local MTANID 0 - 65,535 See Remarks As determined by the local MTAREG_ZONE 0 - 4095 As determined by the network Zone Registration not currently supportedTOTAL_ZONES 0 - 7 0 Zone Registration not currently supportedZONE_TIMER 0 - 7 0 Zone Registration not currently supportedMULTI_SIDS 0 - 1 0 If roaming is permitted, this should be set to 1 MULTI_NIDS 0 - 1 0 If roaming or more than one NID in the MTA, set to 1BASE_ID 0 - 65,535 See Remarks As determined by the local MTABASE_CLASS 0 - 15 0 Public macro cellular systemPAGE_CHAN 0 - 7 1 One paging channelMAX_SLOT_CYCLE_INDEX 0 - 7 5HOME_REG 0 - 1 1FOR_SID_REG 0 - 1 1FOR_NID_NEG 0 - 1 1POWER_UP_REG 0 - 1 1POWER_DOWN_REG 0 - 1 1PARAMETER_REG 0 - 1 1REG_PRD 0 - 127 0 Periodic registration every 2621 sec (43 min)BASE_LAT -1296000, +1296000 See Remarks As determined by the local MTABASE_LONG -2592000, +2592000 See Remarks As determined by the local MTAREG_DIST 0 No distance based registrationRESCAN 0-2047 0
Parameters here determine the contents of the registration fields of the System Parameters Message on the paging channel
November, 2004 RF200 - 178RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Parameters Example3. Power Control ParametersOpen Loop
NOM_PWR 0 -15 8 8' = 0 dBINIT_PWR 0 - 31 16 16' = 0 dBPWR_STEP 0 - 7 3 3 dBNUM_STEP 0 - 15 6 (6 +1) access probes per sequence
Forward Power ControlPWR_REP_THRESH 0 - 31 2 Only applicable to RateSet1 (8 kbps) dataPWR_REP_FRAMES 0 - 15 7 Only applicable to RateSet1 (8 kbps) dataPWR_THRESH_ENABLE 0 - 1 1 Only applicable to RateSet1 (8 kbps) dataPOWER_PERIOD_ENABLE 0 -1 0 Only applicable to RateSet1 (8 kbps) dataPOWER_REP_DELAY 0 - 31 1 4 frames, only applicable to RateSet1 (8 kbps) data
4. Handoff ParametersPilot Search Parameters
PILOT_PN 0-1 1 As determined by the local MTASEARCH_WIN_A 0 - 15(4 - 452 PN Chps) 8 60 PN chipsSEARCH_WIN_N 0 - 15(4 - 452 PN Chps) 10 100 PN chipsSEARCH_WIN_R 0 - 15(4 - 452 PN Chps) 10 100 PN chipsNGHBR_MAX_AGE 0 - 15 2PILOT_INC 0 - 15 4NGHBR_CONFIG 0 - 7 0
Pilot Strength ParametersT_ADD 0 - 63(-0.5x dB) 28 -14 dBT_DROP 0 - 63(-0.5x dB) 32 -16 dBT_TDROP 0 - 15 (=< 0.1 - 319 sec) 3 4 secT_COMP 0 - 15 (x0.5 dB) 5 2.5 dB
These parameters are communicated to the mobile in the overhead messages on the Paging Channel.
November, 2004 RF200 - 179RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Parameters ExampleNMIS Parameter Range Recommended Value Remarks
Acquisition
AccessChannelAcquisitionSearchWidth 25 - 4095 TBA Used by the BTS for the revese linkAccessChannelDemodulationSearchWidth 25 - 4095 TBA Used by the BTS for the revese linkTrafficChannelAcquisitionSearchWidth 25 - 4095 TBA Used by the BTS for the revese linkTrafficChannelDemodulationSearchWidth 25 - 4095 TBA Used by the BTS for the revese link
PowerControl 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%RRXincreaseFull 1/256 - 4095/256 42/256Half 1/256 - 4095/256 7/256Quarter 1/256 - 4095/256 7/256Eighth 1/256 - 4095/256 7/256Unknown 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 PRXstart (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 PRXstart (Ew/Nt) 1/256 - 4095/256 3149/256 (12.5 - 10log3) = 7.7 dB Eb/Nt
RateSet1Data PrTXerror 1/16 - 256/16 16 1% RTXincrease 1/256 - 4095/256 20/256 PTXlower -4095/256 - 0/256 -2304/256 -9 dB PTXupper -4095/256 - 0/256 -768/256 -3 dB PTXstart -4095/256 - 0/256 -1536/256 -6 dB
RateSet2Data PrTXerror 1/16 - 256/16 16 1% RTXincrease 1/256 - 4095/256 133/256 PTXlower -4095/256 - 0/256 -3072/256 -12 dB PTXupper -4095/256 - 0/256 -256/256 -1 dB PTXstart -4095/256 - 0/256 -1536/256 -6 dB
PowerControlGainOffset -127 to 128 0
November, 2004 RF200 - 180RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Parameters Example
Wilting, Blossoming and Breathing Parameters
WiltBlossStepSize 0/16 - 255/16 dB (0-255) 4/16 dB (4) Rate should be 1 dB/secWiltBlossStepTime 1 - 20 (units of 100 ms) 1 100 msecWiltBlossEnabled 0 - 1 1BreathingStepSize 1/16 - 255/16 dB/ms 4/16 dB/ms Rate should be 1 dB/secBreathingStepTime 1 - 20 (units of 100 ms) 1 100 msecBreathingDelta 0/16 - 255/16 dB (0-255) 192/16 (4 dB [64] or more) 12 dB rise over the noise floorBreathingEnabled 0 - 1 0 DisabledRecPowerEstimationFilterRate 2 - 40 (units of 5 ms) 4 Steps of 5 ms. 4 =20 msRecPowerDecayExponential 0 - 16 6TXAttenNormal 0-70 (0/16 - 1120/16 dB) See Remarks As given by the installtion & calibrationTXPowerMax 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 process. As measureTPEFilterDecayExponential 0 - 16 5ReverseLinkCapacityEstimationRate 20*5 to 255*5 ms 100 (20*5) Not supportedHandoffBlockingThreshold 0-100 % 5? Not supportedCallBlockingThreshold 0-100 % 10? Not supportedRXFEGain RcvrA 0/16 - 480/16 dB See Remarks As given by the installtion & calibration RCVRB 0/16 - 480/16 dB See Remarks As given by the installtion & calibrationRXFENoiseFigure RCVRA 0/16 - 160/16 dB See Remarks As given by the installtion & calibration RCVRB 0/16 - 160/16 dB See Remarks As given by the installtion & calibrationRXCableAtten According to above cable loss of antenna path for the specific ap RcvrA 0/16 - 480/16 dB See Remarks As given by the installtion & calibration RCVRB 0/16 - 480/16 dB See Remarks As given by the installtion & calibrationRXCableNoiseFigure Close to RxCableAtten According to noise figure intro'd due to cable loss of antenna pat RCVRA 0/16 - 160/16 dB See Remarks As given by the installtion & calibration RCVRB 0/16 - 160/16 dB See Remarks As given by the installtion & calibrationRXCardNoiseFigureMin 0/16 - 1120/16 5 dB for 800, 4 dB for 1900 As given by the Rx card calibrationRXCardNoiseFigureMax 0/16 - 1120/16 960/16 60 dB
Wilting and blossoming are techniques for gracefully taking a sector from service or returning it to service without dropping traffic.
November, 2004 RF200 - 181RF200 v4.0 (c) 2004 Scott Baxter
Nortel System Parameters ExamplePilot Data BasePilotChannel
CDMACenterFrequency ?? See Remarks As determined by the Preferred Channel SetExtendedBaseId word32 See Remarks BandClass, CDMAFreq,BASE_ID,SectorAvailable 0 -1 1QuickRepeat 0 -1 0 disabledBlankAndBurst 0 -1 0 Not usedForwardGain 0 - 255 TBAPilotGain 0 - 255 216 216 for 800 MHzMinPilotToTotalPwrRatio -255/16 to 0/16 dB -7 20% of HPA powerNeighborList word32Array, up to 20 nieghb See Remarks As determined by the RF designCellType CELL_STANDARD, CELL_P CELL_STANDARD If no HHO in the cell
CELL_BORDERSyncChannel
SyncGain 0 - 255 68 10 dB down from pilot for 800 MHz
PagingChannelPagingGain 0 - 255 130 4.4 dB down from pilot for 800 MHz
These parameters set the power levels of the overhead channels.
November, 2004 RF200 - 182RF200 v4.0 (c) 2004 Scott Baxter
Motorola System Parameters
Motorola System Parameters
November, 2004 RF200 - 183RF200 v4.0 (c) 2004 Scott Baxter
Motorola System Parameters
MM2List all BTSs for MM1 .
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
November, 2004 RF200 - 184RF200 v4.0 (c) 2004 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.
November, 2004 RF200 - 185RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 186RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 187RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 188RF200 v4.0 (c) 2004 Scott Baxter
Motorola System ParametersTCH 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 FrmStepDownDel 21 21 21 21 FrmOrigDelay 100 100 100 100 FrmTchWCCnt 42 42 42 42 TCH
November, 2004 RF200 - 189RF200 v4.0 (c) 2004 Scott Baxter
Motorola System ParametersN-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
November, 2004 RF200 - 190RF200 v4.0 (c) 2004 Scott Baxter
Course RF200 Section III
Introduction toOptimization Tools
Introduction toOptimization Tools
November, 2004 RF200 - 191RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 192RF200 v4.0 (c) 2004 Scott Baxter
Department Store Analogy: Tops-Down, Bottoms-Up
Profits
Complex!!! Simpler
Management Test Shopper
Labor Relations
Cost
sTaxe
s Insurance
Suppliers
Leases
Capital
Stocking
Distribution
Loss
esAdvertis
ing
Selection
ConveniencePrice
Service
Complex!!! Simpler
System Phone
Neighbor ListsData Analysis
SoftwareTrans-
mission
Configuration
Provisioning
PSTN Trunking
Dropped Calls
CoverageAccess Failures
Switch
BTS
CBSC
InterferenceAdministration
Data CaptureField Tools
Some things are easier to measure from the customer side!
November, 2004 RF200 - 193RF200 v4.0 (c) 2004 Scott Baxter
Aeronautical Analogy: Tools for Problem Investigation
Control & Parameters Messaging
BTS
1150011500
114.50118.25130.75
AeronauticalCase
CDMA Case
Flight Data Recorder Cockpit Voice Recorder
Temporal Analyzer Data Layer 3 Message Files
To study the cause of an aeronautical accident, we try to recover the Flight Data Recorder and the Cockpit Voice Recorder.
To study the cause of a CDMA call processing accident, we review data from the Temporal Analyzer and the Layer 3 Message Files -- for the same reasons.
November, 2004 RF200 - 194RF200 v4.0 (c) 2004 Scott Baxter
Sources of CDMA Data and Tools for ProcessingCBSCSwitch BTS
CDSU DISCO
Ch. Card ACC
ΣαΣβΣχ
TFU1GPSR
CDSUCDSU
DISCO 1DISCO 2
SBSVocodersSelectors
CDSUCDSUCDSUCDSUCDSUCDSU
CMSLM
LPP LPPENET
DTCs
DMS-BUS
Txcvr ATxcvr BTxcvr C
RFFE ARFFE BRFFE C
TFU1GPSR
IOC
BSM
Data AnalysisPost-Processing
Tools
IS-95/J-STD-008 Messages
IS-95/J-STD-8 Messages
Switch Datapegs, logs
Mobile DataPost-Processing
Tools
Mobile Data Capture Tools
HandsetMessages
ExternalAnalysis
Tools
PC-based
PC-based
Unix-based,PC-basedVarious
CDMA NETWORK EQUIPMENT HANDSET
System Internal Messages
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
November, 2004 RF200 - 195RF200 v4.0 (c) 2004 Scott Baxter
Autonomous Data CollectionBy Subscriber Handsets
Autonomous Data CollectionBy Subscriber Handsets
November, 2004 RF200 - 196RF200 v4.0 (c) 2004 Scott Baxter
Autonomous Collection:A New Way to See Network Performance
t1t1 v SEL
t1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELS
AuthenticationAuthorization
AccountingAAA
BTS
(C)BSC/Access ManagerSwitch
Collection Server•software download•collected data upload•data management, analysis
BTS
BTS
BTS
An exciting new trend in network RF performance is to embed datacollection software on mobile platformsOffers big advantages for RF optimization cost/effectiveness
November, 2004 RF200 - 197RF200 v4.0 (c) 2004 Scott Baxter
Using Autonomous Collection
t1t1 vSELt1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELSAuthentication
AuthorizationAccounting
AAABTS
(C)BSC/Access ManagerSwitch
Collection Server•software download•collected data upload•data management, analysis
BTS
BTS
BTS
A Server downloads software to a large population of subscriber mobilesMobiles collect on custom profiles
• all or groups of mobiles can be enabled/disabled• new triggers can be rapidly developed and downloaded when desired
Mobiles upload compacted packets to server driven by custom triggers• may be immediately if needed, or at low-traffic pre-programmed times• collected data can include location/GPS/call event/L3
messaging/timestamps/etc.Server manages data, provides filtering and reportingPerformance optimizers use terminals and post-processing software
November, 2004 RF200 - 198RF200 v4.0 (c) 2004 Scott Baxter
Advantages of Autonomous Collection
Mobile-reported data can be location-binned
• post-processing provides visual identification of problem areas
Collection can be rapidly enabled per cell or area for immediate investigation of problem reportsRequires less employee drive time for collectionCustomer mobiles cover area more densely than drivetestersCustomer mobiles include in-building populationsIndividual mobile identification can be included with customer permission for direct customer service interaction
November, 2004 RF200 - 199RF200 v4.0 (c) 2004 Scott Baxter
Current Issues in Autonomous Collection
t1t1 vSELt1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELSAuthentication
AuthorizationAccounting
AAABTS
(C)BSC/Access ManagerSwitch
Collection Server•software download•collected data upload•data management, analysis
BTS
BTS
BTS
Requires extensive software capability to develop/manage• current progress is from specialty application consulting houses
Requires cooperation of handset vendor to effectively integrate software onto handset platform
• caution required to avoid negative call processing side-effectsPrivacy issues involved if any user-specific data trackingAdditional network capacity required for large-scale reporting
November, 2004 RF200 - 200RF200 v4.0 (c) 2004 Scott Baxter
Conventional Field ToolsConventional Field Tools
November, 2004 RF200 - 201RF200 v4.0 (c) 2004 Scott Baxter
CDMA Field Test ToolsField Collection Tools using Handset Data PN Scanners
QualcommMDM, CAIT
Grayson
Comarco
Willtech
EricssonTEMS
Motorola Agilent(HP + SAFCO)
BerkeleyVaritronics
Grayson Qualcomm
DTI Willtech
Agilent(HP + SAFCO)
There are many commercial CDMA field test toolsCharacteristics 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!
November, 2004 RF200 - 202RF200 v4.0 (c) 2004 Scott Baxter
Qualcomm’s MDM: Mobile Diagnostic Monitor
The Qualcomm Mobile Diagnostic Monitor was the industry’s first field diagnostic tool
• used industry-wide in the early deployment of CDMA
• pictures at right from Sprint’s first 1996-7 CDMA trials in Kansas City
Qualcomm’s Mobile Diagnostic Monitor • CDMA handset (customer provided)• Proprietary connecting cable• PC software for collection and field pre-
analysis– Temporal analyzer display mode– Messaging
November, 2004 RF200 - 203RF200 v4.0 (c) 2004 Scott Baxter
Grayson’s Invex3G Tool
100 MB ethernet connection to PCthe eight card slots can hold receivers or dual-phone cardsthere’s also room for two internal PN scannersMultiple Invex units can be cascaded for multi-phone load-test applicationsCards are field-swappable -Users can reconfigure the unit in the field for different tasks without factory assistance
November, 2004 RF200 - 204RF200 v4.0 (c) 2004 Scott Baxter
November, 2004RF200 v4.0 (c) 2004 Scott BaxterTechnical Introduction to Wireless -- ©1997 Scott Baxter - V0.0 205
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.8kb/s
Grayson Invex Playback Example
November, 2004 RF200 - 206RF200 v4.0 (c) 2004 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.6kb/s
Grayson Invex Playback Example
November, 2004RF200 v4.0 (c) 2004 Scott BaxterTechnical Introduction to Wireless -- ©1997 Scott Baxter - V0.0 207
F-SCH rates 153.6 kbps; R-SCH 76.8kbps
PN Scanner Data
Grayson Invex Playback Example
Current Data Task StatusLayer-3 Messages
CDMA Status
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
November, 2004 RF200 - 208RF200 v4.0 (c) 2004 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 modesPN Scanner
• Fast, GPS-locked, can scan two carrier frequencies
Spectrum Analyzer• Can scan entire 800 or 1900
mHz. BandsBase-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: OPAS32November, 2004 RF200 - 209RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 210RF200 v4.0 (c) 2004 Scott Baxter
IS-95 Busy SectorSnapshot of Walsh Usage
November, 2004 RF200 - 211RF200 v4.0 (c) 2004 Scott Baxter
1xRTT Busy SectorWalsh Code Usage
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
November, 2004 RF200 - 212RF200 v4.0 (c) 2004 Scott Baxter
PN Scanners
Why PN scanners? Because phones can’t scan remaining set fast enough, miss transient interfering signalsBerkeley 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 toolGrayson Wireless
• New digital receiver provides CDMA PN searcher and and sector walsh domain displays
November, 2004 RF200 - 213RF200 v4.0 (c) 2004 Scott Baxter
Post-Processing ToolsPost-Processing tools display drive-test files
for detailed analysis - Faster, more effective than studying data playback with collection tools aloneActix 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 dataWavelinkComarco "Workbench" ToolVerizon/Airtouch internal tool “DataPro”
OPAS32
COMARCO
November, 2004 RF200 - 214RF200 v4.0 (c) 2004 Scott Baxter
Drive-Testing
Some General GuidelinesSome General Guidelines
November, 2004 RF200 - 215RF200 v4.0 (c) 2004 Scott Baxter
Safety Considerations
Don’t worry for the company’s loss due to your accidental death• Qualified and eager replacements have resumes on file• We’re constantly buying more drive-test vehicles• We were going to replace that old drive-test equipment soon• We’re not really sure we needed your last drive test, anyway• Your death will serve as a warning to others, so it’s not in vain
It’s OK to be careful and continue living for your own sake if you wish!Always start and stop drive test file collection in a safe place off the road and out of traffic patterns
• Set up a graph window, message window, etc., whose motion can provide a quick-glance visual reassurance that collection is running OK
While on the road, do not attempt to start or stop files, open or close windows, or review results - just glance occasionally for signs of activityIf the PC freezes, the power cord pops out, or any other problem occurs while collecting, don’t try to deal with it or correct it while driving
• Just pull over to the next really safe place to assess and correct
November, 2004 RF200 - 216RF200 v4.0 (c) 2004 Scott Baxter
Physical Considerations
Be sure the connections (power, phone, PC and GPS cables) are secure so they won’t dislodge during collection and distract youBe sure the equipment is physically restrained so it won’t go flying around and hit you in case of a panic stop or sudden swerveSome GPS antennas are not weatherproof. Try to avoid getting them drenched in heavy rainThe GPS antennas should be mounted where they have a view of the sky as unobstructed as possibleExternal 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
November, 2004 RF200 - 217RF200 v4.0 (c) 2004 Scott Baxter
Operational Concerns
The ideal length for drive-test files is 30 minutes to an hour• You’d hate to lose bigger files in case the PC locks up!• Larger files are a hassle to move around, load, and analyze• When interesting call processing events occur, it’s nice if they are in
small files that can be easily processed and storedAlways make sure you have at least 2 or 3 GB of free hard drive space before you start a new drive-test collection
• Don’t open other programs while collecting data - they can tie up all your free space in swap files and cause a crash
• Check your hard drive for errors and defragment it every week or so if you’re collecting and transferring big files
Don’t retrace large parts of your travel path during a drive-test run• It’s harder to distinguish what happened on each run when analyzing
drives that cruise the same road multiple timesAlways stop the test call before you stop recording -- otherwise, post-processing software may misinterpret calling events
November, 2004 RF200 - 218RF200 v4.0 (c) 2004 Scott Baxter
Some Manufacturer-Specific Concerns
When using Agilent drive-test equipment, data accumulates very quickly. A day’s driving can easily produce a 500 MB data file (data.mdb), or even larger.
• Don’t 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 itreaches a few hundred MB, and do your next collection in a new file.
• Without caution, this file can grow so large that it can’t 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 aren’t 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, don’t create unnecessary measurements that you won’t ordinarily use. But be careful since unlike the Grayson, you can’t open a display window during playback unless that display windowexisted during collection.
November, 2004 RF200 - 219RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 220RF200 v4.0 (c) 2004 Scott Baxter
GPS BasicsGPS (Global Positioning System) was funded and implemented by the US military and serves both civilian and military users
• approved military users use a high precision signal (“C/A”)• civilian users use a lower-precision component of the signal• GPS signals are spread-spectrum at 1.545 and 1.2 GHz.
Other Global Navigation Systems:• Europe: Galileo (not yet launched) • Russia: GLONASS (in poor repair)
GPS uses 21 active satellites and 3 parked spares, all in mid-level orbits at about 10,000 KM
• Hour-by-hour, 5 to 7 satellites are usually in view anywhere• Reception of four satellites is enough to fix determine location• Three satellites are enough if user’s elevation already known• GPS reception is often blocked in cities, under bridges, dense forests,
or wherever obstacles interrupt the signal pathDead Reckoning is a method of supplementing GPS with independentlocation information when GPS can’t be receivedDifferential GPS is a technique adding independent corrections to received GPS data for better accuracy. GPS civilian accuracy wasimproved in May, 2000. DGPS hasn’t been widely used since then
November, 2004 RF200 - 221RF200 v4.0 (c) 2004 Scott Baxter
Dead-Reckoning Systems
Dead-reckoning systems normally use a combination of magnetic compass and wheel rotation sensors to augment GPSThe manufacturer’s instructions should be followed for installation. Major factors requiring attention are:
• If used, Wheel sensors must be securely mounted to prevent accidental breakaway while driving (major injury hazard)
• Magnetic compasses should be located as far as possible from magnetic field sources in or on the vehicle
– example: mag-mount antennas– (experimentation is often required)
• Calibration by actual test is required to achieve workable accuracy for dead-reckoning systems
November, 2004 RF200 - 222RF200 v4.0 (c) 2004 Scott Baxter
Drive-Tests: Phones
Maintenance Features of CDMA Handsets
Maintenance Features of CDMA Handsets
November, 2004 RF200 - 223RF200 v4.0 (c) 2004 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 keystrokesDisplayed Parameters
• PN Offset, Handset Mode, Received RF Level , Transmit Gain AdjustMaintenance 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
November, 2004 RF200 - 224RF200 v4.0 (c) 2004 Scott Baxter
Older Qualcomm/Sony Maintenance Displays
November, 2004 RF200 - 225RF200 v4.0 (c) 2004 Scott Baxter
MAIN MENU 1:Volume2:Call Info3:Security
D
FEATURES 41:AutoAnswer2:AutoRetry3:Scratch
D
Menu
4
0
ENTER FIELDSERVICE CODE
******
D
00000 0(* or correct code, if different)
Press This: See This:
*
*
DEBUG 01:Screen2:Test Calls3:CDMA Only
D
DEBUG 04:Errors5:Clr Errors6:13K Voice
D
318 2 9DX A 7F
D
1
See following legend for
maintenance display values
continue: See This:
Qualcomm & Sony Phones with Jog Dials
Enter 111111Press dial in for OPTIONSDial to FIELD DEBUG, pressenter Field Debug Security Codepress Screen
November, 2004 RF200 - 226RF200 v4.0 (c) 2004 Scott Baxter
Interpreting the QCP Maintenance Display
318 2 94X A 7F
D
PN Offset
0 - Pilot Channel Acquisition Substate1 - Sync Channel Acquisition Substate2 - MS Idle State3 - System Access State4 - Traffic Channel State
Receive State
Receive Power
UnsupportedA = active pilotsX = exit reason
Transmit Adjust80 -10980 -10900 00A -514 -101E -1528 -20
FFF5E6D7C8B9AA9B8C80
-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:RXdbm=XXDEC / 3 - 63.25 (800 MHz)RXdbm=XXDEC / 3 - 66.25 (1900 MHz)(if XX>7F, use XX = XXDEC-256)Transmit Gain Adjust Conversion:TXADJdb=XXDEC / 2Transmit Power Output Conversion:TXdbm= -73 -RXDBM - TXADJdb (800 MHz)TXdbm= -76 -RXDBM - TXADJdb (1900 MHz)
November, 2004 RF200 - 227RF200 v4.0 (c) 2004 Scott Baxter
Kyocera 2035 Maintenance Mode
Steps to enter maintenance mode:111111EnterOptions: DebugEnterEnter Field Debug Code
• 000000Field DebugDebug ScreenEnterBasicEnter
November, 2004 RF200 - 228RF200 v4.0 (c) 2004 Scott Baxter
Kyocera 6035 Maintenance Mode
111111Jog > OptionsJog > DebugOpen flip to continueEnter Code
• 0 0 0 0 0 0OKSCREEN
November, 2004 RF200 - 229RF200 v4.0 (c) 2004 Scott Baxter
Early Samsung Maintenance Display
November, 2004 RF200 - 230RF200 v4.0 (c) 2004 Scott Baxter
8
0
00000 0(* or correct code, if different)
Press This: See This:
*
*
1
See following legend for
maintenance display values
continue: See This:
Menu Main Menu ↑1:Call Logs2:Phone Book
SVC
Setup ↑1:Auto Retry2:Anykey Ans
SVC
Service Code??????
SVC
Debug Menu ↑1:Screen2:Test Calls
SVC
Debug Menu ↑3:Errors4:Erase Error
SVC
S04379 SI0 1T-63 D105-06P016 CH0600
SVC
Samsung SCH-3500 Maintenance Display
Here are the steps to enter maintenance mode:MENUSETUP0 (undocumented “trap door”)000000 (operator’s code)Screen
See the Samsung idle and in-call maintenance screens at the end of the Samsung phones.
November, 2004 RF200 - 231RF200 v4.0 (c) 2004 Scott Baxter
Samsung SCH-8500 Maintenance Display
November, 2004 RF200 - 232RF200 v4.0 (c) 2004 Scott Baxter
Here are the steps to enter maintenance mode:[Menu] [down][down][down][down] [down][down][down] Setup/Tool [OK] [0] Service Code ?????? [0] [4] [0] [7] [9] [3] Screen [OK]
See the Samsung idle and in-call maintenance screens at the end of the Samsung phones.
Samsung SCH-A500 Maintenance Display
Here are the steps to enter maintenance mode:Select settingsselect displayselectenter 0enter 040793
See the Samsung idle and in-call maintenance screens at the end of the Samsung phones.
November, 2004 RF200 - 233RF200 v4.0 (c) 2004 Scott Baxter
Interpreting Samsung Maintenance Display:Acquisition, Idle, and Access States
Transmit Power Output Calculation:TXdbm= -73 -RXDBM - TXADJdb (800 MHz)TXdbm= -76 -RXDBM - TXADJdb (1900 MHz)
S04379 SI0 1T-63 D085-06P016 CH0600
svc
PN Offset
0 - Pilot Channel Acquisition Substate1 - Sync Channel Acquisition Substate2 - MS Idle State3 - System Access State4 - Traffic Channel State5,6,7 - various call service options
Processing StateReceive Power,
dbmTransmit
Gain Adjust,db
Display toggles between:System Identifier (SID)Network Identifier (NID)
Frequency(channel #)
Ec/Io, db(primary PN only)
Slot Cycle Index
November, 2004 RF200 - 234RF200 v4.0 (c) 2004 Scott Baxter
Interpreting Samsung Maintenance Display:Traffic Channel State
Transmit Power Output Calculation:TXdbm= -73 -RXDBM - TXADJdb (800 MHz)TXdbm= -76 -RXDBM - TXADJdb (1900 MHz)
TV1 RV8 08 7T-63 D085-06P016 CH0600
svc
PN Offset
0 - Pilot Channel Acquisition Substate1 - Sync Channel Acquisition Substate2 - MS Idle State3 - System Access State4 - Traffic Channel State5,6,7 - various call service options
Processing StateReceive Power,
dbmTransmit Gain Adjust,
db
TransmitVocoder Rate
1 = 1/82 = 1/44 = 1/28 = Full
Frequency(channel #)
Walshcode
assigned
Receive Vocoder
Rate
Ec/Io, db(primary PN only)
November, 2004 RF200 - 235RF200 v4.0 (c) 2004 Scott Baxter
Entering Denso Debug Mode
CBV: 3957ABU: 3954 ABT: 031ARF: 0000 CCL: 01SID: 04157NID: 00001CH: 0100 RSSI: 093DPN: 084 TX:-46BFRM:0000000968TFRM:0000135712FER:% 000.71LT: 036:06:36LG: -086:45:36EC: -16 -63 -63PN: 084 084 084FNGLK: Y Y NWLSH: 01 01 01ACT: 084 484 096-01 -01 200CND: 220 332 200200 332 NGH: 076080 340 068 196O56 320 220 316344 488 196 200392 124 128 084224 008 084
DEnter ##DEBUG (##33284)Scroll down to SAVEPress OKHighlight SERVICE SCREENPress OK
If you want to make a test call, dial the digits and press OK while in idle mode
November, 2004 RF200 - 236RF200 v4.0 (c) 2004 Scott Baxter
Denso Maintenance Display
CBV: 3957ABV: 3954 ABT: 031ARF: 0000 CCL: 01SID: 04157NID: 00001CH: 0100 RSSI: 093DPN: 084 TX:-46BFRM:0000000968TFRM:0000135712FER:% 000.71LT: 036:06:36LG: -086:45:36EC: -16 -63 -63PN: 084 084 084FNGLK: Y Y NWLSH: 01 01 01ACT: 084 484 096-01 -01 200CND: 220 332 200200 332 NGH: 076080 340 068 196O56 320 220 316344 488 196 200392 124 128 084224 008 084
DCharging Battery Voltage
Average Battery Voltage Average Battery Temperature
System IDNetwork ID
RF Channel FrequencyDigital PN Offset
Received Signal StrengthEstimated Transmitter
Power OutputNumber of Bad Frames
Number of Good Frames Frame Erasure Rate, PercentBase Station coordinates
Current status of Rake Fingers
Active Pilot Set
Candidate Pilot SetNeighbor Pilot Set
November, 2004 RF200 - 237RF200 v4.0 (c) 2004 Scott Baxter
Early Sanyo Dual-Band Phones
7
0
4823
Press This:
Menupress menu 7, 0enter in DEBUGM (332846) screens are similar to QCP phones
318 2 94X A 7F
D
3 6
November, 2004 RF200 - 238RF200 v4.0 (c) 2004 Scott Baxter
Sanyo SPC-4500 Maintenance Display
Choose the following:DISPLAYOK0OKEnter Code: 0 0 0 0 0 0Debug MenuSCREENOK
November, 2004 RF200 - 239RF200 v4.0 (c) 2004 Scott Baxter
Sanyo SPC-4900 Maintenance Display
PN offset
Call Proc. StateReceivePower
Io
ChannelFrequency
##040793select MENU/OK buttonscroll to save Phone #select
November, 2004 RF200 - 240RF200 v4.0 (c) 2004 Scott Baxter
Entering Maintenance Mode: Motorola StarTacContact your service provider to obtain your phone’s 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. Don’t 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!
November, 2004 RF200 - 241RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 242RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 243RF200 v4.0 (c) 2004 Scott Baxter
RX Power BatteryCondition
N5 N5M failureBS BS Ack failureWO L3 WFO State TimeoutMP Max Probe FailurePC Paging Channel lossRR Reorder or Release on PCH?? Unknown Condition
ChannelNumber
#Neighbors
Local Time#
ActivesStrongest Active
PN Ec/IoStrongest NeighborPN Ec/Io
# Cand-idates Call Proc
StateLast Call
Exit Reason# Drops
# CallsLast Call FER%
NIDSIDRx Powerdbm (Io)
Tx Powerdbm
CurrentService Option
Last Call IndicatorNI No Indication yetMR Mobile ReleaseBR Base Sta. ReleaseTC Traffic Channel LostL2 Layer 2 Ack FailNC No Channel Assn Msg
Current Service Option8V 8K voice originalIL 8K loopback8EV 8K EVRC8S 8K SMS13L 13K loopback
13S 13K SMS8MO 8K Markov OldDAT Data8M 8K Markov New13M 13K Markov New13V 13K Voice
Call Processing StatesCP CP ExitRST CP RestartRTC RestrictedPLT Pilot AcquisitionSYN Sync AcquisitionTIM Timing ChangeBKS Background SchIDL IdleOVD OverheadPAG Paging
ORG Call OriginationSMS Short Message SvcORD Order ResponseREG RegistrationTCI Tfc Ch InitializationWFO Waiting for OrderWFA Waiting for AnswerCON Conversation stateREL ReleaseNON No State
Motorola V120C Series
MENU 073887* Enter 000000 for security code. Scroll down to Test Mode. Enter subscriber entity lock code if required by your phone
Same maintenance display as shown for Startac
November, 2004 RF200 - 244RF200 v4.0 (c) 2004 Scott Baxter
Motorola V60C
MENU 073887* Enter 000000 for security code. Scroll down to Test Mode. Enter subscriber entity lock code if required by your phone
Same maintenance display as shown for Startac
November, 2004 RF200 - 245RF200 v4.0 (c) 2004 Scott Baxter
Audiovox 8100, 9155
Press ##27732726 [End] Select the Debug screen.PN, channel#, SID, NID, mode (13K, EVRC, etc) Ec/Io, RX Level, TX Level.You cannot make a call while in any of the maintenance screens.
November, 2004 RF200 - 246RF200 v4.0 (c) 2004 Scott Baxter
NeoPoint Phones
Although NeoPoint went out of business in June, 2001, there are still some NeoPointhandsets in general usePress the M (menu) keySelect Preferences (using the up-arrow key)Enter 040793Choose Debug Screen [Select]Now you’re in maintenance mode!
November, 2004 RF200 - 247RF200 v4.0 (c) 2004 Scott Baxter
GoldStar TouchPoint
To enter maintenance mode, just key in: # # D E B U G SAVE
November, 2004 RF200 - 248RF200 v4.0 (c) 2004 Scott Baxter
Nokia 6185 Maintenance Display
Enter *3001#12345# MENUScroll down to Field testPress SelectScroll up to EnabledPress OKPower the phone off and onYou should now be in Field test mode
November, 2004 RF200 - 249RF200 v4.0 (c) 2004 Scott Baxter
Older Nokia Models Maintenance Display
Enter *3001#12345# MENUScroll down to Field testPress SelectScroll up to EnabledPress OKPower the phone off and onYou should now be in Field test mode and the following screens will be available:
November, 2004 RF200 - 250RF200 v4.0 (c) 2004 Scott Baxter
Maintenance Display Screens of Nokia Handsets
The following screens appear in field test mode on Nokia HD881 series of Handsets:
November, 2004 RF200 - 251RF200 v4.0 (c) 2004 Scott Baxter
CSST
XXXXX
RSSICCCC
RXTX
CS StateIdle: PN Offset
TFC: #Actv, FERRSSI dBm
Paging Channel #RX power, dbmTX power, dbm
Screen 1: GeneralPrimary Channel A
Secondary Channel APPCASPCA
Screen 5: NAM Info
Primary Channel BSecondary Channel B
PPCBSPCB
Local UseAccess Overload Class
LA
CSSTPGCH
CURSOFER
CS StatePaging Channel #
Current Service OptionFrame Error Rate
Screen 2: Paging CH Info Current SIDCurrent NID
SIDNID
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
Mobile MINMobile Station ESN
Preferred Sys 1=AMPS, 2=CDMA
OwnNumberESN
P
A Operator Selected(1=A, 2=B, 3=both
Screen 4: NAM InfoMIN_P_REV (sync msg.MIN_P_REV
CS StateDate from System Time
CSSTMMDDYY
Screen 8: Time Information
System TimeHHMMSS
Nokia Maintenance Display Screens (continued)
November, 2004 RF200 - 252RF200 v4.0 (c) 2004 Scott Baxter
TADDTDROP
TATD
Screen 9: Acquisition InformationPilot PN Offset
Ec/Io in 1/2 db unitsPPNEC
Screen 11: Active Set (#4-6)
TCOMPTCTTDROPTT
Active WindowWW1Neighbor WindowWW2
Remaining WindowWW3
Keep? 1KPilot PN Offset
Ec/Io in 1/2 db unitsPPNEC
Keep? 1KPilot PN Offset
Ec/Io in 1/2 db unitsPPNEC
Keep? 1KPilot PN Offset
Ec/Io in 1/2 db unitsPPNEC
Screen 10: Active Set (#1-3)
Keep? 1KPilot PN Offset
Ec/Io in 1/2 db unitsPPNEC
Keep? 1KPilot PN Offset
Ec/Io in 1/2 db unitsPPNEC
Keep? 1K
Nokia Maintenance Display Screens (continued)
November, 2004 RF200 - 253RF200 v4.0 (c) 2004 Scott Baxter
NBR 1 PN OffsetEc/Io in 1/2 db units
PPNEC
Screen 12: Neighbor Set (#1-5) NBR 11 PN Offset
Ec/Io in 1/2 db unitsPPNEC
Screen 14: Neighbor Set (#11-15)
NBR 2 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 3 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 4 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 5 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 12 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 13 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 14 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 15 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 6 PN OffsetEc/Io in 1/2 db units
PPNEC
Screen 13: Neighbor Set (#6-10) NBR 16 PN Offset
Ec/Io in 1/2 db unitsPPNEC
Screen 15: Neighbor Set (#16-20)
NBR 7 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 8 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 9 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 10 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 17 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 18 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 19 PN OffsetEc/Io in 1/2 db units
PPNEC
NBR 20 PN OffsetEc/Io in 1/2 db units
PPNEC
Nokia Maintenance Display Screens (continued)
CAND 1 PN OffsetEc/Io in 1/2 db units
PPNEC
Screen 16: Candidate Set (#1-5)
CAND 2 PN OffsetEc/Io in 1/2 db units
PPNEC
CAND 3 PN OffsetEc/Io in 1/2 db units
PPNEC
CAND 4 PN OffsetEc/Io in 1/2 db units
PPNEC
CAND 5 PN OffsetEc/Io in 1/2 db units
PPNEC
Task NameWorst-Cs Stack Free Sp
TASKNFREE
Screen 17-22: Task Stack Ck Info
Overflow ind. by shift2=sys stack overflow
Task StackSys Stack
Screen 23: Stack Status Info.
Screen 24: Codec Registers
November, 2004 RF200 - 254RF200 v4.0 (c) 2004 Scott Baxter
New CDMA Phones
November, 2004 RF200 - 255RF200 v4.0 (c) 2004 Scott Baxter
New CDMA Phones
November, 2004 RF200 - 256RF200 v4.0 (c) 2004 Scott Baxter
New CDMA Phones
November, 2004 RF200 - 257RF200 v4.0 (c) 2004 Scott Baxter
New CDMA Phones
November, 2004 RF200 - 258RF200 v4.0 (c) 2004 Scott Baxter
New CDMA Phones
November, 2004 RF200 - 259RF200 v4.0 (c) 2004 Scott Baxter
Novatel Merlin C201 Card
Enter # # D E B U G to enter maintenance mode.To exit, just click “OK” box in the Debug window.
November, 2004 RF200 - 260RF200 v4.0 (c) 2004 Scott Baxter
Audiovox Thera Maintenance Mode Screens
How to enterDebug Mode:
[ctrl] [D] [enter]
Advanced Usr Pwd:##DEBUG [enter]
Protocol Statistics
November, 2004 RF200 - 261RF200 v4.0 (c) 2004 Scott Baxter
RF200 Section IV
Multi-Carrier Operationand Its Complications
Multi-Carrier Operationand Its Complications
November, 2004 RF200 - 262RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 263RF200 v4.0 (c) 2004 Scott Baxter
A CDMA network with 5 carriers
It’s A Multi-Carrier/Multi-System/Multi-Manufacturer
World!
Systems are forced to use multiple carriers to achieve needed traffic capacity
• It’s important that the traffic load be divided between carriersPhysically adjacent friendly systems often desire to allow seamless mobile operation across their borders, although they use different carrier frequenciesEven within one large network, seamless mobile operation is desired across serving switch boundariesThese situations are not completely solved in the original IS-95 CDMA vision, so additional standards documents and additional proprietary processes provide the needed functionality
• IS-95: hashing or GSRMs can distribute idle mobiles among carriers• IS-41 - provides intersystem handoffs and call delivery• Proprietary algorithms can distribute in-call traffic among carriers• RF tricks and network proprietary algorithms can support inter-carrier
handoffMulti-Carrier Operation is a complex sport
November, 2004 RF200 - 264RF200 v4.0 (c) 2004 Scott Baxter
Transitions at System Boundaries
IDLE
IN-CALL
IDLE
IN-CALL
Boundary types• between different operators
– same frequency, different frequency, even different band• between different BSCs or Switches of Same Operator
– same frequency, different frequency, even different band• between different carriers where number of carriers changes
– same frequency, different frequency, even different band!A reliable transition method must be planned for users in all circumstances
• all directions of approach• all modes of operation (idle, active voice call, dormant data session,
active data session)
November, 2004 RF200 - 265RF200 v4.0 (c) 2004 Scott Baxter
Foundation for Transition Troubleshooting
Multi-carrier and intersystem boundary transitions are complex relationships between mobile, air interface, and system
• to solve problems, it’s necessary to understand the basic actions of mobile and the system
– this information comes from the standard, summarized in the nextfew slides
The mobile’s actions are generic, defined by the standards, and simpler/more specific than the steps taken by the system
• A thorough knowledge of the mobile side is the easiest-to-get resource for general troubleshooting of problems
For in-call transition troubleshooting, the system’s generic and proprietary algorithms must also be understood
• artificial proprietary trigger mechanisms and internal system order communications and IS-41 implementation
– this information comes from manufacturer documentation• trunking and networking between adjoining systems
– this information comes from operator’s own network design
November, 2004 RF200 - 266RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
MultiCarrier Operation:Big-Picture View of Frequency Changes
MultiCarrier Operation:Big-Picture View of Frequency Changes
November, 2004 RF200 - 267RF200 v4.0 (c) 2004 Scott Baxter
Multi-Carrier Operation:Mobiles Change Frequencies. When/Why/How?
f5
f4
f3
f2
f1
SystemAcquisition
Idle ModeReselection
Call Start:Ch. Assignment
In Call:Hard Handoff
MRUSDAPRL-AI
Hashing:IS-95 or1xRTT
GSRMMulti-FreqNbrs
ProprietaryNetwork
AlgorithmsNortel: MCTA
Lucent:Motorola:
AuxiliaryHandoff Triggers
•Beacons•Ec/Io, RTDProprietaryProcesses
Remember: Different Mechanisms Apply at Different Stages
November, 2004 RF200 - 268RF200 v4.0 (c) 2004 Scott Baxter
Many Network/Carrier Configurations are Possible!
f1
f2
f3
f4
Basic Multi-CarrierOperation
IS-95
IS-95
IS-95
IS-95 f1
f2
f3
f4
Non-originating carrierscan carry more traffic!
IS-95
IS-95
IS-95
IS-95 f1
f2
f3
f4
Some Carriers maysupport 1xRTT
1xRTT
IS-95
IS-95
IS-95
w32
Sync
wa
Traf
fic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
fic
W0
Pilo
t
w32
Sync
w1
Pagi
ngw
aTr
affic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
ficw
32Sy
nc
wa
Traf
fic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
ficw
32Sy
nc
wa
Traf
fic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
fic
wa
Traf
fic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
ficw
aTr
affic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
ficw
aTr
affic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
fic
w32
Sync
wa
Traf
fic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
ficw
cTr
affic
wd
Tra
ffic
wc
Traf
ficw
d T
raffi
cw
cTr
affic
wd
Tra
ffic
w32
Sync
wa
Dat
a
wx
Traf
ficw
yTr
affic
wz
Traf
fic
w32
Sync
wa
Traf
fic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
fic
wa
Traf
fic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
ficw
aTr
affic
wx
Traf
ficw
yTr
affic
wz
Traf
fic
wb
Traf
ficw
cTr
affic
wd
Tra
ffic
wc
Traf
ficw
d T
raffi
c
W0
Pilo
tw
1Pa
ging
W0
Pilo
tw
1Pa
ging
W0
Pilo
tw
1Pa
ging
W0
Pilo
tW
0 P
ilot
W0
Pilo
tW
0 P
ilot
w1
Pagi
ng
W0
Pilo
tW
0 P
ilot
W0
Pilo
tW
0 P
ilot
w1
Pagi
ngw
1Pa
ging
November, 2004 RF200 - 269RF200 v4.0 (c) 2004 Scott Baxter
Within My Systems
The Adjoining Network View:Different Common Configurations
The Adjoining Network View:Different Common Configurations
November, 2004 RF200 - 270RF200 v4.0 (c) 2004 Scott Baxter
The Big Picture:CDMA Multicarrier System Overlaying Analog System
CDMA F2CDMA F3
CDMA F1
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?
November, 2004 RF200 - 271RF200 v4.0 (c) 2004 Scott Baxter
Adjoining CDMA Networks of Different Manufacturers
F2F3
F1F2
Brand X System Brand Y System
PSTNOrdinary Interswitch Trunks
(can’t transmit packets, so soft handoff impossible)
At present, only Hard Handoffs work between different manufacturersImportant 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
November, 2004 RF200 - 272RF200 v4.0 (c) 2004 Scott Baxter
Adjoining CDMA Networks of the Same Manufacturer
F2F3
F1 F1
F4
Brand X System Brand X System
PSTNATM links
between CDMA packet networks(soft handoffs are desired)
At present, most manufacturers support intersystem soft handoffImportant 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
November, 2004 RF200 - 273RF200 v4.0 (c) 2004 Scott Baxter
My Mobile
The Mobile View:When Do I Change Frequencies?
The Mobile View:When Do I Change Frequencies?
November, 2004 RF200 - 274RF200 v4.0 (c) 2004 Scott Baxter
Multi-Carrier Operation:Mobiles Change Frequencies. When/Why/How?
f5
f4
f3
f2
f1
SystemAcquisition
Idle ModeReselection
Call Start:Ch. Assignment
In Call:Hard Handoff
MRUSDAPRL-AI
Hashing
GSRMMulti-FreqNbrs
ProprietaryNetwork
AlgorithmsNortel: MCTA
Lucent methodsMotorola methods
AuxiliaryHandoff Triggers
•Beacons•Ec/Io, RTDProprietaryProcesses
Remember: Different Mechanisms Apply at Different Stages
November, 2004 RF200 - 275RF200 v4.0 (c) 2004 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 systemPaging channel messages can cause idle mode carrier or system reselection
f5
f4
f3
f2
f1
SystemAcquisition
Idle ModeReselection
MRUSDAPRL-AI
Hashing
GSRMMulti-FreqNbrs
Mobiles find the proper system through both standard-definedacquisition steps and a proprietary System Determination AlgorithmNovember, 2004 RF200 - 276RF200 v4.0 (c) 2004 Scott Baxter
Basic Principles:System Determination in Idle Mode
CDMA Idle ModeMobile has control, follows the System Determination AlgorithmLook at most recently used frequency.Find Strongest Pilot > Read Sync >If system denied or not preferred, check other frequencies in PRL.Read Paging/Config MessagesIf Multiple Frequencies appear in CDMA Channel List Message, Hash and go to proper frequencyIf GSRM transmitted, go wherever directedMonitor Paging Channel
Analog Idle ModeMobile has control, follows procedures of the StandardFind Strongest CCHMonitor Paging ChannelEvery 3 minutes, rescan for CDMA signal
November, 2004 RF200 - 277RF200 v4.0 (c) 2004 Scott Baxter
Summary: How Idle Mobiles Choose CDMA CarriersAt turnon, Idle mobiles use proprietary System Determination Algorithms (SDA) to find the initial CDMA carrier intended for them to useOn the paging channel of the idle mobile’s newly-found home signal, the mobile might be sent to a different frequency if it hears
• CDMA Channel List Message• Global Service Redirection Message (GSRM)
Go to last frequency from MRU
Strongest PN, read
SyncIs SID
permitted?
No Signal
Preferred Only Bit 0
Denied SIDRead
Paging Channel
CDMA Ch List Message
Global Svc Redir Msg
HASH using IMSI
my ACCOLC? redirect
Is better SID
available?
PRLMRU Acq IdxYes
NoF1F2F3
to Analog
to another CDMA frequency or system
ConfigMessages:
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
November, 2004 RF200 - 278RF200 v4.0 (c) 2004 Scott Baxter
Avoiding Unwanted Acquisition of Supplemental CDMA Carriers
CDMA Carrier Frequency 2
CDMA Carrier Frequency 1
GSRM GSRM
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
November, 2004 RF200 - 279RF200 v4.0 (c) 2004 Scott Baxter
Frequency Change at Initial Channel Assignment
When a new call is about to be assigned to its first traffic channel - it’s an ideal time to change carrier frequencies for intercarriertraffic distribution purposes
• No call yet exists, so no muting occursEach 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
ProprietaryNetwork
AlgorithmsNortel: MCTA
Lucent methodsMotorola methods
Call Start is a painless time to change to a different frequency.Different networks have different proprietary triggers to distribute traffic.
November, 2004 RF200 - 280RF200 v4.0 (c) 2004 Scott Baxter
System Determination During Call Setup and Call Continuation
CDMA Conversation StateSystem 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 StateSystem 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
November, 2004 RF200 - 281RF200 v4.0 (c) 2004 Scott Baxter
Interfrequency Hard Handoff
Mobiles in a call are receiving only their current operating frequency
• They’re unaware of the presence or absence of signals on different carrier frequencies, so they don’t 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
AuxiliaryHandoff Triggers
•Beacons•Ec/Io, RTDProprietaryProcesses
Mobiles in conversation can’t see pilots on different carrier frequencies.We must “trick” these mobiles into handoff by artificial means.
November, 2004 RF200 - 282RF200 v4.0 (c) 2004 Scott Baxter
Intersystem Hard HandoffSame Frequency causes Interference Problems!
BSC1 SW1
SW2 BSC2
Frequency 1
City 2
City 1Interference
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 problemHandoff 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
November, 2004 RF200 - 283RF200 v4.0 (c) 2004 Scott Baxter
Intersystem Soft Handoff:Avoids Border Area Interference Problems
BSC1 SW1
SW2 BSC2
Frequency 1
City 2
City 1Intersystem Soft Handoff
ATM link
no 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 problemsNovember, 2004 RF200 - 284RF200 v4.0 (c) 2004 Scott Baxter
Avoid Interference, Use Different Frequencies?Hard Handoff Logistical Problems
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
F2 Mobiles can’t see F1 pilots!
F1 Mobiles can’t see F2 pilots!
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 complicationsConversation-State Handoff Logistical Problems:
• Mobiles on one system can’t 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.)
November, 2004 RF200 - 285RF200 v4.0 (c) 2004 Scott Baxter
One Solution to the Multi-Frequency Problem2-Frequency Trigger Method: Beacon Cells
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
F2 Mobiles can see F2 beacon
F1 Mobiles can see F1 beacon
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, it’s 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
November, 2004 RF200 - 286RF200 v4.0 (c) 2004 Scott Baxter
Another Solution for Multi-Frequency HandoffsBridge Cells, RTD Trigger in Boundary Sectors
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
Boundary Sector
Boundary Sector
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 mobile’s round trip delay (RTD).
• When the mobile’s 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 highprobability of success
– disadvantage: more BTS hardware needed than otherwiseNovember, 2004 RF200 - 287RF200 v4.0 (c) 2004 Scott Baxter
Another Solution for Multi-Frequency HandoffsArbitrary Ec/Io Trigger Mechanisms
Frequency 1
Frequency 2
BSC1 SW1
SW2 BSC2
City 2
City 1
Boundary Sector
Boundary Sector
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 measurementrequest messages
• When the mobile’s reports the boundary sector’s Ec/Io is below a preset threshold, the system immediately commands a hard handoffto 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
November, 2004 RF200 - 288RF200 v4.0 (c) 2004 Scott Baxter
CDMA/Analog Overlay ConsiderationsCDMA/Analog Overlay Considerations
November, 2004 RF200 - 289RF200 v4.0 (c) 2004 Scott Baxter
CDMA/AMPS Overlays: Idle CDMA AcquisitionCDMA Overlay
AMPS Existing System
GSRM GSRM
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
November, 2004 RF200 - 290RF200 v4.0 (c) 2004 Scott Baxter
CDMA/AMPS Overlays: Analog HanddownCDMA Overlay
AMPS Existing System
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)
November, 2004 RF200 - 291RF200 v4.0 (c) 2004 Scott Baxter
Course RF200 Section V.
Applied OptimizationApplied Optimization
November, 2004 RF200 - 292RF200 v4.0 (c) 2004 Scott Baxter
Good Performance is really Simple!!
Although there are many phases of optimization activities, good performance is really just compliance with a very simple ideaOne, Two, or Three good signals in handoff
• Composite Ec/Io > -10 dbEnough capacity for the offered traffic
• No resource problems
BTS BTS
BTS
Pilot
Paging
TrafficChannels
In use
availablepower
Sync
BTS
A
BTS
B
BTS
C
Ec/Io -10
FORWARDLINK
In principle, A COW next door can solve almost any CDMA problem!
Reality Check:1. But who has enough regular cells OR cows or money to
fix every problem location?!!2. Problems occur in the areas between cells’ dominant
coverage. Adding a cow only pushes the problems out to its own boundary with other cells.
Conclusion: We need to design better, and to use our existing cells more effectively. We need to provide one, two, or three dominant signals everywhere.
November, 2004 RF200 - 293RF200 v4.0 (c) 2004 Scott Baxter
Bad Performance Has Many CausesWeak Signal / Coverage HolePilot Pollution
• Excessive Soft HandoffHandoff Failures, “Rogue” mobiles
• Missing Neighbors• Search Windows Too Small• BTS Resource Overload / No Resources
– No Forward Power, Channel Elements
– No available Walsh Codes– No space in Packet Pipes
Pilot “Surprise” ambush; Slow HandoffsPN Plan errorsSlow Data Problems: RF or IP congestionImproper cell or reradiator configurationHardware and software failuresBut on analysis, all of these problems’ bad effects happen because the simple few-signal ideal CDMA environment isn’t possible.
360
+41
+8
360+33cA
BBTS
BTS
BTS BPN 99
BTS APN 100
1 mile 11 miles
ACTIVE SEARCH WINDOW
xPilot
PagingSync
TrafficChannels
In Use
NoAvailablePower!B
TS Sector Transmitter
CEsVocodersSelectors
BTS Rx PwrOverload
November, 2004 RF200 - 294RF200 v4.0 (c) 2004 Scott Baxter
Starting Optimization on a New SystemRF Coverage Control
• try to contain each sector’s coverage, avoiding gross spillover into other sectors
• tools: PN Plots, Handoff State Plots, Mobile TX plotsNeighbor List Tuning
• try to groom each sector’s neighbors to only those necessary but be alert to special needs due to topography and traffic
• tools: PSMM data from mobiles; propagation predictionSearch 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 speedAccess 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.
November, 2004 RF200 - 295RF200 v4.0 (c) 2004 Scott Baxter
Performance Monitoring/Growth ManagementBenchmark Existing Performance
• Dropped Call %, Access Failure %, traffic levelsIdentify Problem Cells and Clusters
• weigh cells and clusters against one anotherLook 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.
November, 2004 RF200 - 296RF200 v4.0 (c) 2004 Scott Baxter
CDMA Problems, Causes, and Cures
PROBLEMSExcessive Access FailuresExcessive Dropped CallsForward Link InterferenceSlow HandoffHandoff Pilot Search Window IssuesPN Planning ConsiderationsExcessive Soft HandoffGrooming Neighbor ListsSoftware Bugs, Protocol Violations
EXAMPLESNormal CallDropped Call - CoverageDropped Call - Neighbor ListDropped Call - Search Window
November, 2004 RF200 - 297RF200 v4.0 (c) 2004 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.
November, 2004 RF200 - 298RF200 v4.0 (c) 2004 Scott Baxter
Normal Call ProcessingEvent Templates
Normal Call ProcessingEvent Templates
November, 2004 RF200 - 299RF200 v4.0 (c) 2004 Scott Baxter
Registration
PagingChannel
AccessChannel
BTS
Registration Message (by PROBING)
Base Station Acknowledgment Order
November, 2004 RF200 - 300RF200 v4.0 (c) 2004 Scott Baxter
Voice Mail Notification
PagingChannel
AccessChannel
BTS
Feature Notification Message
Mobile Station Ack’mt. (by PROBING)
Base Station Acknowledgment Order
November, 2004 RF200 - 301RF200 v4.0 (c) 2004 Scott Baxter
Incoming Call Delivery ScenarioGeneral Page Message
PagingChannel
AccessChannel
BTS
Page Response Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Continuous frames of all 000’s
ForwardTraffic
Channel
ReverseTraffic
Channel
Traffic Channel Preamble: Frames of 000’s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
November, 2004 RF200 - 302RF200 v4.0 (c) 2004 Scott Baxter
Mobile-Originated Call Scenario
PagingChannel
AccessChannel
BTS
Origination Message (by PROBING)
Base Station Acknowledgment Order
Channel Assignment Message
Continuous frames of all 000’s
ForwardTraffic
Channel
ReverseTraffic
Channel
Traffic Channel Preamble: Frames of 000’s
Base Station Acknowledgment Order
Mobile Station Acknowledgment Order
Service Connect Message
Service Connect Complete Message
The Call is now officially Established!
November, 2004 RF200 - 303RF200 v4.0 (c) 2004 Scott Baxter
ForwardTraffic
Channel
ReverseTraffic
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 fromanother 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
November, 2004 RF200 - 304RF200 v4.0 (c) 2004 Scott Baxter
Troubleshooting Access FailuresTroubleshooting Access Failures
November, 2004 RF200 - 305RF200 v4.0 (c) 2004 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 seenChannel Assignment Message seen at mobile but mobile station does not acquire Forward Traffic ChannelMobile station acquires Forward Traffic Channel but system does not acquire Reverse Traffic ChannelSystem 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!
MSProbing
ACCESS
PAGING
FW TFC
PAGING
RV TFC
FW FC
RV TFC
FW TFC
RV TFC
FW TFC
Successful Access Attempt
November, 2004 RF200 - 306RF200 v4.0 (c) 2004 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 easyRarely, circumstantial evidence points clearly to the problemUsually, 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 failThis 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
eventNovember, 2004 RF200 - 307RF200 v4.0 (c) 2004 Scott Baxter
Troubleshooting Access Failures (1)
Paging Channel Access ChannelSteps in the Access ProcessBTS
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 can’t hear the BTS acknowledging, Ec/Io is likely quite poor. If so, check whether this is due to weak signal (poor coverage) or pilot pollution (lots of pilots all weak but no dominant server)
Collect system logs if necessary to determine definitely whether the system heard the mobile’s origination or not
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.
November, 2004 RF200 - 308RF200 v4.0 (c) 2004 Scott Baxter
Troubleshooting Access Failures (2)
Paging Channel Access ChannelThe Access ProcessBTS
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:
November, 2004 RF200 - 309RF200 v4.0 (c) 2004 Scott Baxter
Troubleshooting Access Failures (3)
Paging Channel Access ChannelThe Access ProcessBTS
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 AssignmentMessage
Base StationAcknowledgment
STOP! Leave the Paging Channel, and don’t transmit again on the access channel.The mobile now goes to try to hear the Forward Traffic Channel.
November, 2004 RF200 - 310RF200 v4.0 (c) 2004 Scott Baxter
Troubleshooting Access Failures (4)
FWD Traffic Channel REV Traffic ChannelThe Access ProcessBTS
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”
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
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 StationAcknowledgment
Mobile StationAcknowledgment
If the BTS does NOT hear the mobile’s access preamble within a prescribed delay, it will abort the process and release all the resources, and the mobile will reacquire the system. . This is what Lucent terms a “Traffic Channel Confirmation Failure (TCCF).”
If the BTS DOES hear the mobile’s access preamble, it will send an acknowledgment.The mobile responds with an acknowledgment, or maybe even a pilot strength measurement message if it already needs a handoff.
November, 2004 RF200 - 311RF200 v4.0 (c) 2004 Scott Baxter
Troubleshooting Access Failures (5)
FWD Traffic Channel REV Traffic ChannelThe Access ProcessBTS
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 ConnectMessage
Service ConnectComplete Message
This is still just an ongoing access attempt
Base StationAcknowledgment
Now this is officially a call in progress
November, 2004 RF200 - 312RF200 v4.0 (c) 2004 Scott Baxter
Access Failure/TCCF TroubleshootingAccess 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
BlockingForward Power
Channel ElementsRev. Link Noise
Optmz Fpwr DGUsAdd 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_Stepappropriate?
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 blockingDid mobile see N5M good
frames on F-TCH?
yes
no
Check System Logs.CH EL initialized OK?
noyes
Check System Logs. DidBTS 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 coverageIdentify, eliminate
Report/repair
F-TFC Channel faded, lostyes
Check System Logs.Did BTS see mobile Ack?
OK
no Weak Signal/Coverage Hole?Strong Rev Noise?
Is T-1unstable/blocking?
Improve coverageIdentify, eliminate
Report/repair
R-TFC Channel faded, lost
Init TCH DGU large enough? Raise DGU
November, 2004 RF200 - 313RF200 v4.0 (c) 2004 Scott Baxter
Reducing Access Failures
1. If the failures occur in areas where one BTSis dominant, suspect BTS hardware problems.2. Plot the access failures to see if they correlatewith areas of BTS overlap. If so, suspectforward link problems. This is probablebecause the mobile does not have the normaladvantage it would get from soft handoff on atraffic channel. During access, it must successfully demodulate all five BTS messageswithout the benefit of soft handoff. If thehandset is in an area of multiple BTS overlapsor 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 mobile’s probes,the cause is probably coverage-related. If it happensin strong signal areas, suspect BTS hardware. Alsocheck datafill for proper NOM_PWR and PWR_INC.Be sure the BTS datafill access channel acquisition and demodulation search windows are adequate.
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!
MSProbing
ACCESS
PAGING
FW TFC
PAGING
RV TFC
FW FC
RV TFC
FW TFC
RV TFC
FW TFC
Access Attempt
November, 2004 RF200 - 314RF200 v4.0 (c) 2004 Scott Baxter
Troubleshooting Dropped CallsTroubleshooting Dropped Calls
November, 2004 RF200 - 315RF200 v4.0 (c) 2004 Scott Baxter
Dropped Call Troubleshooting - Mobile SideJust 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 PNActive 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 didn’t 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?
noAdd PN to Neighbor List!
BlockingForward Power
Channel ElementsRev. 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?
noWiden 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 OverlapSpeed up searcher
Optmz Fpwr DGUsAdd chan cards
Identify, fix source
Report/repair
November, 2004 RF200 - 316RF200 v4.0 (c) 2004 Scott Baxter
Investigating Dropped Calls
BAD COVERAGE
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
+100
FWD. INTERFERENCE
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
+100
REV. INTERFERENCE
FFER RXL EC/IO TxGa TxPo
BTS Messaging
FFER RXL EC/IO TxGa TxPo
-110
-30100%
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
+100
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
November, 2004 RF200 - 317RF200 v4.0 (c) 2004 Scott Baxter
Handoff Problems: “Window” Dropped Calls
A
B
1 mi.7 Chips
BTS
BTS
SITUATION 1 Locked to distant site, can’t see
one nearby12 miles80 ChipsSRCH_WIN_N = 130BTS A is reference.BTS B appears (7-80) chipsearly due to its closer distance.This is outside the 65-chip window.Mobile can’t see BTS B’s pilot, but its strong signal blinds us and the call drops.
Travel
mountains
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 2Locked to nearby
site, can’t see distant one12 miles80 Chips
Travel
SRCH_WIN_N = 130BTS B is reference.BTS A appears (80-7) chipslate due to its farther distance.This is outside the 65-chip window.Mobile can’t see BTS A’s pilot.
mountains
November, 2004 RF200 - 318RF200 v4.0 (c) 2004 Scott Baxter
Optional: Quick Primer on Pilot Search WindowsPROPAGATION DELAY
SKEWS APPARENT PN OFFSETS
BTSBTSA
B
33Chips
4 Chips
If the phone is locked to BTS A, thesignal from BTS B will seem 29 chipsearlier than expected.If the phone is locked to BTS B, thesignal from BTS A will seem 29 chipslater than expected.
The phone chooses one strong sector and “locks” to it, accepting its offset at “face value”and interpreting all other offsets by comparison to itIn messages, system gives to handset a neighbor list of nearby sectors’ PNsPropagation delay “skews” the apparent PN offsets of all other sectors, making them seem earlier or later than expectedTo 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 datafilledindividually 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
November, 2004 RF200 - 319RF200 v4.0 (c) 2004 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 don’t miss any important neighbors!
Remaining Set: pay your dues, but get no reward• You must spend time checking them, but the system can’t assign one to you
Rem
aini
ng
Act
ive+
Can
d
Nei
ghbo
rPILOT 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 SIZEIN 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)
DatafillValue
4
5
7
8
9
10
11
12
13
6
14
15
November, 2004 RF200 - 320RF200 v4.0 (c) 2004 Scott Baxter
Treating Drops with Poor-Coverage SymptomsUsing 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.
November, 2004 RF200 - 321RF200 v4.0 (c) 2004 Scott Baxter
Treating Drops with Forward-Link ProblemsThe 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 Messagep_rev 1, bit_len: 170min_p_rev 1sid 4139 nid 41pilot_pn 0x164 = 356 ( RMCZ )lc_state 1ED595B9632sys_time 189406BE8lp_sec 13ltm_off 0x10 (8.0 hours)daylt 0 prat 1cdma_freq 50
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 conflictsAnother 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)
November, 2004 RF200 - 322RF200 v4.0 (c) 2004 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 Ec/Io and high forward FER. The call will drop unless it gets help quickly.Several steps which must occur without delay:
• The mobile search correlatormust 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
November, 2004 RF200 - 323RF200 v4.0 (c) 2004 Scott Baxter
Sources of Delay Causing Slow Handoff
Every step in the handoff process can suffer delay if we’re 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 handoffsMobile reports PSMM to system.
• Reverse link noisy, PSMM must be re-requested & repeatedSystem sets up handoff, sends EHDM to mobile
• Resource congestion: no TCEs, or other problems• Forward link is noisy, mobile doesn’t hear EHDM, must repeat
Fortunately, these problems do not have to happen.
November, 2004 RF200 - 324RF200 v4.0 (c) 2004 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 5000%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Time (milliseconds)
Cum
ulat
ive
Dis
trib
utio
n Fu
nctio
n
Typical Handoff Setup Time
November, 2004 RF200 - 325RF200 v4.0 (c) 2004 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 doesn’t need to be very large, since the searcher has already found them and is tracking them very frequently. We need only enough width to accommodate all multipath components of these pilots.
• This greatly speeds up the overall pilot search management!Most post-processing tools deliver statistics on the spread (in chips) between fingers locked to the same pilot. These statistics literally show us how wide the SRCH_WIN_A should be set.Neighbor and Remaining search windows should be set based on intercelldistances as described in a preceding slide.
November, 2004 RF200 - 326RF200 v4.0 (c) 2004 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 berecognized. Search windows are the main concern.The BTS uses acquisition and demodulation search windows much like the pilot search windows used by the mobile. The maximum setting is 4095/8 chips (512 chips -1/8 chip). A mobile 38.8 miles from the site would be at the edge of this maximum window setting, and could not originate or be acquired during handoff beyond this distance.The mobile is not restricted on acquiring the system forward channels but its pilot search windows are limited to 452 chips. Neighbor pilots couldn’t be recognized if coming from a cell more than 34.3 miles closer or farther than the cell to which the mobile is locked.The IS-95 and J-Std008 specify a maximum of 350 µsec maximum round trip delay, BTS-Handset. This is a distance of 32.6 miles.General Observation: If your cell radius exceeds 30 miles, be careful.
November, 2004 RF200 - 327RF200 v4.0 (c) 2004 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 bestavailable 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, don’t fear. “Use the force, Luke!” And to our GSM friends, “Resistance is futile…...”
November, 2004 RF200 - 328RF200 v4.0 (c) 2004 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 sector’s area is within the last 4 dB. of coverage where soft handoff occurs.
– In typical markets, terrain irregularities scatter RF beyond cleanly designed cell edges; soft handoff is typically 50-60%
– In rough terrain, proper soft handoff may rise to 70% or more In a system not yet well-tuned, soft handoff may be clearly excessive
• The main cause is usually excessive RF overlap between cells • RF coverage control is the most effective means of reducing and
managing soft handoff (BTS attenuation, antenna downtilting)• Thresholds T_ADD and T_DROP can be adjusted to reduce soft handoff,
but this penalizes mobiles that need soft handoff to escape interference from the excessively overlapping sites
Controlling soft handoff percentage with T_ADD and T_DROP is like limiting allowed hospital days for various illnesses. Works, but some patients may drop.
November, 2004 RF200 - 329RF200 v4.0 (c) 2004 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.
November, 2004 RF200 - 330RF200 v4.0 (c) 2004 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 sector’s 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.
November, 2004 RF200 - 331RF200 v4.0 (c) 2004 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, you’ll 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 don’t 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).
November, 2004 RF200 - 332RF200 v4.0 (c) 2004 Scott Baxter
TX Gain Adjust as a Per-Site Debugging ToolCollect Transmit Gain Adjust StatisticsFor an unloaded system, the average should be -7 to -12 db. and should be fairly constant throughout the coverage areaLook 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, SecondsNovember, 2004 RF200 - 333RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
CDMA2000 1xRTTSystem Performance Optimization
CDMA2000 1xRTTSystem Performance Optimization
November, 2004 RF200 - 334RF200 v4.0 (c) 2004 Scott Baxter
The Big Picture:
IP D
ata
Envir
onm
entCDMA RF Environment
CDMA IOS PPPTraditional Telephony
IP Data Environment
t1t1 v CESEL
t1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELS
AuthenticationAuthorization
Accounting AAA
BTS
(C)BSC/Access ManagerSwitch WirelessMobile Device
•Coverage Holes•Pilot Pollution•Missing Neighbors•Fwd Pwr Ovld•Rev Pwr Ovld•Search Windows•Island Cells•Slow Handoff
1xRTT services may include both traditional circuit-switched voice and new fast IP data connections
• A User's link is in multiple jeopardy, both radio and packet worldsRadio 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
November, 2004 RF200 - 335RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 336RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 337RF200 v4.0 (c) 2004 Scott Baxter
Managing Forward Link Sector Loading vs. TimeSe
ctor
Tot
al T
X Po
wer
or T
hrou
ghpu
t
Time, Seconds
Sector Maximum TX Power, Maximum Throughput
Voice Traffic
Packet Data Traffic
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
November, 2004 RF200 - 338RF200 v4.0 (c) 2004 Scott Baxter
Starting Optimization on a New SystemRF Coverage Control
• try to contain each sector’s coverage, avoiding gross spillover into other sectors
• tools: PN Plots, Handoff State Plots, Mobile TX plotsNeighbor List Tuning
• try to groom each sector’s neighbors to only those necessary but be alert to special needs due to topography and traffic
• tools: PSMM data from mobiles; propagation predictionSearch 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 speedAccess 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.
November, 2004 RF200 - 339RF200 v4.0 (c) 2004 Scott Baxter
Performance Monitoring/Growth ManagementBenchmark Existing Performance
• Dropped Call %, Access Failure %, traffic levelsIdentify Problem Cells and Clusters
• weigh cells and clusters against one anotherLook 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.
November, 2004 RF200 - 340RF200 v4.0 (c) 2004 Scott Baxter
#6 Indicator: Data Latency
IP D
ata
Envir
onm
entCDMA RF Environment
CDMA IOS PPPTraditional Telephony
IP Data Environment
t1t1 v CESEL
t1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELS
AuthenticationAuthorization
Accounting AAA
BTS
(C)BSC/Access ManagerSwitch WirelessMobile Device
•Coverage Holes•Pilot Pollution•Missing Neighbors•Fwd Pwr Ovld•Rev Pwr Ovld•Search Windows•Island Cells•Slow Handoff
Latency can occur because of RF channel congestion or from IP network causes
• RF overload can delay availability of supplemental channels• IP network congestion can delay availability of packets
Ping and loopback tests with local PDSN and servers can identify whether problem is in backbone networkDoes latency correlate with independent evidence of RF congestion?
November, 2004 RF200 - 341RF200 v4.0 (c) 2004 Scott Baxter
#7 Indicator: Data Throughput
IP D
ata
Envir
onm
entCDMA RF Environment
CDMA IOS PPPTraditional Telephony
IP Data Environment
t1t1 v CESEL
t1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELS
AuthenticationAuthorization
Accounting AAA
BTS
(C)BSC/Access ManagerSwitch WirelessMobile Device
•Coverage Holes•Pilot Pollution•Missing Neighbors•Fwd Pwr Ovld•Rev Pwr Ovld•Search Windows•Island Cells•Slow Handoff
Throughput can be limited by RF and IP causes• Traditional RF problems limit capacity of the channel• Congestion in the IP network can limit speed of data available
Does low throughput correlate with independent RF indicators?Does low throughput correlate with independent IP pings and tests?
November, 2004 RF200 - 342RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
System-Side 1xRTT ToolsSystem-Side 1xRTT Tools
November, 2004 RF200 - 343RF200 v4.0 (c) 2004 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 requiredIn-Class activity: view manufacturer documentation and examples
November, 2004 RF200 - 344RF200 v4.0 (c) 2004 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 GuideMotorola
• “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
November, 2004 RF200 - 345RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Mobile-Side 1xRTT ToolsMobile-Side 1xRTT Tools
November, 2004 RF200 - 346RF200 v4.0 (c) 2004 Scott Baxter
Sources of CDMA Data and Tools for ProcessingCBSCSwitch BTS
CDSU DISCO
Ch. Card ACC
ΣαΣβΣχ
TFU1GPSR
CDSUCDSU
DISCO 1DISCO 2
SBSVocodersSelectors
CDSUCDSUCDSUCDSUCDSUCDSU
CMSLM
LPP LPPENET
DTCs
DMS-BUS
Txcvr ATxcvr BTxcvr C
RFFE ARFFE BRFFE C
TFU1GPSR
IOC
BSM
Data AnalysisPost-Processing
Tools
IS-95/J-STD-008 Messages
IS-95/J-STD-8 Messages
Switch Datapegs, logs
Mobile DataPost-Processing
Tools
Mobile Data Capture Tools
HandsetMessages
ExternalAnalysis
Tools
PC-based
PC-based
Unix-based,PC-basedVarious
CDMA NETWORK EQUIPMENT HANDSET
System Internal Messages
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
November, 2004 RF200 - 347RF200 v4.0 (c) 2004 Scott Baxter
CDMA Field Test ToolsField Collection Tools using Handset Data PN Scanners
Qualcomm
Grayson
Comarco
SAFCO
LCC
Motorola Agilent(formerly HP)
BerkeleyVaritronics
Grayson Qualcomm
Safeco Willtech
Agilent(formerly HP)
There are many commercial CDMA field test toolsCharacteristics 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!
November, 2004 RF200 - 348RF200 v4.0 (c) 2004 Scott Baxter
Grayson’s 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
• there’s 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
November, 2004 RF200 - 349RF200 v4.0 (c) 2004 Scott Baxter
November, 2004RF200 v4.0 (c) 2004 Scott BaxterTechnical Introduction to Wireless -- ©1997 Scott Baxter - V0.0 350
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.8kb/s
Grayson Invex Playback Example
November, 2004 RF200 - 351RF200 v4.0 (c) 2004 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.6kb/s
Grayson Invex Playback Example
November, 2004RF200 v4.0 (c) 2004 Scott BaxterTechnical Introduction to Wireless -- ©1997 Scott Baxter - V0.0 352
F-SCH rates 153.6 kbps; R-SCH 76.8kbps
PN Scanner Data
Grayson Invex Playback Example
Current Data Task StatusLayer-3 Messages
CDMA Status
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
November, 2004 RF200 - 353RF200 v4.0 (c) 2004 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 modesPN Scanner
• Fast, GPS-locked, can scan two carrier frequencies
Spectrum Analyzer• Can scan entire 800 or 1900
mHz. BandsBase-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: OPAS32November, 2004 RF200 - 354RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 355RF200 v4.0 (c) 2004 Scott Baxter
IS-95 Busy SectorSnapshot of Walsh Usage
Forward Link Walsh Codes in 1xRTTThis way of arranging Walsh codes is called “bit reversal order”. It shows each
Walsh code’s parents and children. Remember, we cannot use any Walsh code if
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
Paging 7
Paging 3
Paging 5
Paging
PCH
6
PCH
2
PCH
4
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
76.8ksps
another Walsh code directly above it or below it is in use.
November, 2004 RF200 - 356RF200 v4.0 (c) 2004 Scott Baxter
IS-95 Today Typical Usage:Pilot, Paging Sync, up to 61 Voice Users
November, 2004 RF200 - 357RF200 v4.0 (c) 2004 Scott Baxter
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.
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
19.2k19.2kS
yncPilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k ???????Traffic Channels
Voice or Data9.6k/14.4k
76.8ksps
38.4k
Mixed IS-95 / 1xRTT RC3 Voice Typical Usage: Pilot, Paging Sync, up to 61 Voice Users
FCHs of 1xRTT RC3 users consume less power, so more total users are possible than inIS-95. The BTS will probably have enough forward power to carry calls on all 61 walsh codes!
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
19.2k19.2kS
yncPilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-FCHs mixedRC1,2,3 Voice
76.8ksps
??
November, 2004 RF200 - 358RF200 v4.0 (c) 2004 Scott Baxter
A Possible 1xRTT RC3 BTS Dynamic State:1 F-SCH, 27 Voice IS-95/1xRTT RC3 Users, 16 Active Data Users
November, 2004 RF200 - 359RF200 v4.0 (c) 2004 Scott Baxter
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!
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-SCH 153K RC3
F-FCHs 9.6kRC3 Data
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
76.8ksps
A Possible 1xRTT RC3 BTS Dynamic State:1 F-SCH, 39 IS-95/1xRTT RC3 Voice Users, 4 Active+12 Dormant Data Users
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.
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCH
sD
ata
F-SCH 153K RC3
76.8ksps
November, 2004 RF200 - 360RF200 v4.0 (c) 2004 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
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.
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCH
sD
ata
F-SCH 153K RC3
F-DC
CH
s76.8ksps
November, 2004 RF200 - 361RF200 v4.0 (c) 2004 Scott Baxter
Heavy Data 1xRTT RC3 BTS Dynamic State:2 F-SCH, 21 IS-95/1xRTT RC3 Voice Users, 4 Active+12 Control-Hold Data Users
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!
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCH
sD
ata
F-SCH 153K RC3
F-DC
CH
s
F-SCH 153K RC3
76.8ksps
November, 2004 RF200 - 362RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 363RF200 v4.0 (c) 2004 Scott Baxter
1xRTT Busy SectorWalsh Code Usage
1xRTT RC3 BTS with Different User Data Rates:3 F-SCH, 37 IS-95/1xRTT RC3 Voice Users, 4 Active+12 Control-Hold RC3 Data Users
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.
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCH
sD
ataF-SCH
76K RC3F-D
CC
Hs
F-SCH
38K
F-SCH
38K76.8ksps
November, 2004 RF200 - 364RF200 v4.0 (c) 2004 Scott Baxter
1xRTT RC4 Voice Only:Pilot, Paging Sync, up to 118 Voice Users
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.
November, 2004 RF200 - 365RF200 v4.0 (c) 2004 Scott Baxter
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-FCHs 9.6k RC4 Voice
F-FCHs 9.6k RC4 Voice
F-FCHs 9.6k RC4 Voice
F-FCHs 9.6k RC4 Voice???????
76.8ksps
1xRTT RC4 Voice and Data:1 F-SCH, 80 1xRTT RC4 Voice Users, 4 Active+12 Control-Hold RC4 Data Users
November, 2004 RF200 - 366RF200 v4.0 (c) 2004 Scott Baxter
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!
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
Sync
Pilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-SCH 307K RC4
F-FCHs 9.6k RC4 Voice
F-FCHs 9.6k RC4 Voice
F-FCHs 9.6k RC4 Voice????
F-FCH
sF-D
CC
Hs
76.8ksps
Mature 1xRTT Mixed-Mode Voice and Data:1 RC3/RC4 Shared F-SCH, 20 RC3 Voice Users, 38 RC4 Voice Users,
3 Active+12 Control-Hold RC3 and RC4 Data Users16 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!
9,6004,8002,400sps
307200sps
153,600sps
76,800sps
38,400sps
19,200sps
Code#
Code#
Code#
Code#
Code#
Code#
128 chips4 chips
8 chips16 chips
32 chips64 chips
Code#
Code#
Code#
Code#
Code#
Code#
73516240
3120
1571131359114610212480
311523727111932913215259171301422626101822812204248160
54
12763953111147791511955872310339717123599127107437511115518319993567312561932910945771311753852110137695121578925105417391134981189733651126629430110467814118862210238706122589026106427410114508218983466212460922810844761211652842010036684120568824104407281124880169632640
0 32 16 48 8 40 24 56 4 36 20 52 12 44 28 60 2 34 18 50 10 42 26 58 6 38 22 54 14 46 30 62 1 33 17 49 9 41 25 57 5 37 21 53 13 45 29 61 3 35 19 51 11 43 27 59 7 39 23 55 15 47 31 63
QPC
HQ
PCH
QPC
HTX
Div PIlot
19.2k
19.2k
19.2k
19.2k
Paging
19.2k
19.2k
19.2k
19.2k19.2kS
yncPilot
38.4k
38.4k38.4k
38.4k
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
76.8ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH153.6 ksps
F-SCH307.2 ksps
F-SCH307.2 ksps
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
38.4k
19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k19.2k19.2k19.2k
19.2k19.2k19.2k19.2k
F-SCH 153K RC3or
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.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCHs 9.6kRC3 Voice
F-FCH
sF-D
CC
Hs
Or Combinations
????
76.8ksps
November, 2004 RF200 - 367RF200 v4.0 (c) 2004 Scott Baxter
PN ScannersWhy PN scanners? Because phones can’t scan remaining set fast enough, miss transient interfering signalsBerkeley 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 toolGrayson 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
November, 2004 RF200 - 368RF200 v4.0 (c) 2004 Scott Baxter
OPAS32
COMARCO
Post-Processing ToolsPost-Processing tools display drive-test files
for detailed analysis - Faster, more effective than studying data playback with collection tools aloneActix 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 dataWavelinkComarco "Workbench" ToolVerizon/Airtouch internal tool
November, 2004 RF200 - 369RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Data Flow Management:MAC/LAC Layer OperationData Flow Management:
MAC/LAC Layer Operation
November, 2004 RF200 - 370RF200 v4.0 (c) 2004 Scott Baxter
System MAC/LAC Parameters
The answers to all these questions are determined by MAC & LAC layer processes and parametersEach network manufacturer implements some subset of the MAC/LAC states and parameters specified in the IS-2000 standardEach manufacturer has its own unique parameter set to control state transitionsMost 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 orRelease
Initialization
Null
Reconnect
Dormant
Control Hold
Suspended
Packet ServiceRequest
Packet ServiceDeactivated
PPP TerminatedRelease Sent!
PPP TerminatedRelease Sent!
Service OptionConnected
Control Channel Exists
Service OptionConnected
Control ChannelExists
Traffic channelExists
Active
T_hold
Control Channelexists
T_suspend
Have New Datato 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 can’t 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?
November, 2004 RF200 - 371RF200 v4.0 (c) 2004 Scott Baxter
MAC StatesState
R-CCCH
R-EACH
F-TRAFFICF-FCH
F-SCH
R-TRAFFICR-FCH
R-SCHSCH driven
by trafficSCH driven
by traffic
F-TRAFFIC R-TRAFFIC
intermittent
F-DCCH R-DCCH
CESELt1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs T TSECURE TUNNELSAuthentication
AuthorizationAccounting AAA
BTS
(C)BSC/Access Manager
CESELt1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs T TSECURE TUNNELSAuthentication
AuthorizationAccounting AAA
BTS
(C)BSC/Access Manager
CESELt1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs T TSECURE TUNNELSAuthentication
AuthorizationAccounting AAA
BTS
(C)BSC/Access Manager
SELt1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs T TSECURE TUNNELSAuthentication
AuthorizationAccounting AAA
BTS
(C)BSC/Access Manager
PAGING
R-CCCH
R-EACH
PAGING
intermittent
intermittent
ChannelElement
Selector/Svc Cfg (RLP) PPPIP
Session
ACTIVEexit timer:
a few seconds
CONTROLHOLD
(Optional State)exit timer: a few seconds
very fast return to active state
SUSPENDED(Optional State)
exit timer: a few secondsbetween data bursts
DORMANTexit timer: minutes, hours
between data bursts
November, 2004 RF200 - 372RF200 v4.0 (c) 2004 Scott Baxter
Forward Link SCH Scheduling
CESELt1
R-PInterface
PDSN/Foreign Agent
BTS
(C)BSC/Access ManagerWireless
Mobile Device
data
FCH orFCH + SCH?
Buffer
BTSC
My F-SCHData Rate
PCF
The main bottleneck is the forward link itself: restricted by available transmitter power and walsh codesEach 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
November, 2004 RF200 - 373RF200 v4.0 (c) 2004 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-FCHFCH setup only occurs if necessary resources are available
• Walsh Codes, Forward Power, Reverse Power, backhaul, hardwareIf 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 resourcesNetworks today give same priority to new F-FCHs -- voice or dataWhen 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!
DormantState
Active State DormantState
Active State
38.4k76.8
k
153.6k
153.6k
153.6k 76.8
k
DownloadTACC TACCTDORM
TNET+TQUEUE+TSCH
A 1xRTT Web-Browsing Session
F-SCH F-SCHF-FCH F-FCH
UserReads
Web Page
November, 2004 RF200 - 374RF200 v4.0 (c) 2004 Scott Baxter
Forward Link Events in a Typical User SessionData volume in PDSNbuffer triggers SCH assignment. SCH rate isdriven 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.
1.2
9.6
19.2
38.4
76.8
153.6
0
Dat
a R
ate,
kbp
s
November, 2004 RF200 - 375RF200 v4.0 (c) 2004 Scott Baxter
Channel Legend:
DataIdle Data
FundamentalSupplemental
Session begins.No data, FCH idle, 1200 bps
Data in PDSNbuffer. Data flow beginson FCH
Data in PDSNbuffer. Data flow beginson FCH
No data, FCH idle,1200 bps
FCHidle1200bps
Data volume in PDSNbuffer triggers SCH assignment. SCH rate isdriven by amount of data in buffer and available TX power sector can allocate.
Data volume in buffer low, SCH released. Flow continues on FCH.
Activetimerruns out!FCH drops.Session isdormant.
TA
Data volume in PDSNbuffer triggers SCH assignment. SCH rate isdriven 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
Mobileendssession.
Init
NullRcon
Dorm
CHldSusp
Act
STATE
No data, FCH idle,1200 bps
Data in PDSNbuffer. Data flow beginson FCH
QOS algorithmgives SCH to another userbriefly. Datameanwhileflows on FCH.
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 asoftware 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
November, 2004 RF200 - 376RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 377RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 378RF200 v4.0 (c) 2004 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 cellECP-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
November, 2004 RF200 - 379RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 380RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
1x Data Tests and Optimization1x Data Tests and Optimization
November, 2004 RF200 - 381RF200 v4.0 (c) 2004 Scott Baxter
So S L O W ! ! Where’s My Data?!!
IP D
ata
Envir
onm
entCDMA RF Environment
CDMA IOS PPPTraditional Telephony
IP Data Environment
t1t1 v CESEL
t1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELS
AuthenticationAuthorization
AccountingAAA
BTS
(C)BSC/Access ManagerSwitch WirelessMobile Device
•Coverage Holes•Pilot Pollution•Missing Neighbors•Fwd Pwr Ovld•Rev Pwr Ovld•Search Windows•Island Cells•Slow Handoff
Some sessions are tormented by long latency and slow throughputWhere is the problem? Anywhere between user and distant host:
• Is the mobile user’s data device mis-configured and/or congested?• Is the BTS congested, with no power available to produce an SCH?• Poor RF environment, causing low rates and packet retransmission?• Congestion in the local IP network (PCU, R-P, PDSN FA)?• Congestion in the wireless operator’s backbone (‘OSSN’) network?• Congestion in the PDSN HA?• Congestion in the outside-world internet or Private IP network?• Is the distant host congested, with long response times?
November, 2004 RF200 - 382RF200 v4.0 (c) 2004 Scott Baxter
Finding Causes of Latency and Low Throughput
IP D
ata
Envir
onm
entCDMA RF Environment
CDMA IOS PPPTraditional Telephony
IP Data Environment
t1t1 v CESEL
t1
R-P Interface
PDSN/Foreign Agent
PDSNHome Agent
BackboneNetworkInternet
VPNs
PSTN
T TSECURE TUNNELS
AuthenticationAuthorization
AccountingAAA
BTS
(C)BSC/Access ManagerSwitch WirelessMobile Device
•Coverage Holes•Pilot Pollution•Missing Neighbors•Fwd Pwr Ovld•Rev Pwr Ovld•Search Windows•Island Cells•Slow Handoff
TestServer
TestServer
TestServer
IP network performance can be measured using test serversProblems 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.
November, 2004 RF200 - 383RF200 v4.0 (c) 2004 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.
November, 2004 RF200 - 384RF200 v4.0 (c) 2004 Scott Baxter
Basic Network Data Test ScenariosNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
IP tests can be originated from the mobile side to identify & trap problemsTest servers can be positioned where needed in the network
• At PDSN FA, at PDSN HA, or at other end of IP or VPN networkTest 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)
November, 2004 RF200 - 385RF200 v4.0 (c) 2004 Scott Baxter
Data Task: ConnectNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
November, 2004 RF200 - 386RF200 v4.0 (c) 2004 Scott Baxter
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 mobile’s 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
Data Task: PingNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
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 identifiedby variation in ping responses involving a single test server
November, 2004 RF200 - 387RF200 v4.0 (c) 2004 Scott Baxter
Data Task: Raw DownloadNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
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
November, 2004 RF200 - 388RF200 v4.0 (c) 2004 Scott Baxter
Data Task: Raw UploadNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
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
November, 2004 RF200 - 389RF200 v4.0 (c) 2004 Scott Baxter
Data Task: Http GETNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
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
November, 2004 RF200 - 390RF200 v4.0 (c) 2004 Scott Baxter
Data Task: Http POSTNetwork View
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
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
November, 2004 RF200 - 391RF200 v4.0 (c) 2004 Scott Baxter
Data Task: Ftp GETNetwork View
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
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 canproceed automatically without requiring manual intervention
November, 2004 RF200 - 392RF200 v4.0 (c) 2004 Scott Baxter
Data Task: Ftp PUTNetwork View
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
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 canproceed automatically without requiring manual intervention
November, 2004 RF200 - 393RF200 v4.0 (c) 2004 Scott Baxter
Data Task: WaitNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
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
November, 2004 RF200 - 394RF200 v4.0 (c) 2004 Scott Baxter
Course RF200
Protocol-Layer-Specific DataProtocol-Layer-Specific Data
November, 2004 RF200 - 395RF200 v4.0 (c) 2004 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 toolNovember, 2004 RF200 - 396RF200 v4.0 (c) 2004 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
November, 2004 RF200 - 397RF200 v4.0 (c) 2004 Scott Baxter
Mobile Tool IP Throughput CalculationsApplication 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 receivedTX 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 requestTX Transfer Time: from first request byte sent to last request byte sentRX 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
November, 2004 RF200 - 398RF200 v4.0 (c) 2004 Scott Baxter
TCP Application Flow and Timing Measurements
Send ConnectRequest
ConnectResponseReceived?
Start
Timeout?
Transfer Data(Application-Specific)
Send TerminateRequest
TerminateResponseReceived?
Timeout?
Finish
Application throughput amount and timing begins and ends within
this block
Task Timing Ends Here
Task Timing Begins Here
Test equipment tools include software for automatically attempting IP connectionsProcesses 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
November, 2004 RF200 - 399RF200 v4.0 (c) 2004 Scott Baxter
Data Measurement: TCP ThroughputNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
November, 2004 RF200 - 400RF200 v4.0 (c) 2004 Scott Baxter
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 sentTCP 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
Data Measurement: ICMP ThroughputNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
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
November, 2004 RF200 - 401RF200 v4.0 (c) 2004 Scott Baxter
Data Measurement: IP ThroughputNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
Internet Protocol (IP) is below upper layer (application) protocolsIP throughput is the content actually processed by lower layersIf 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?
November, 2004 RF200 - 402RF200 v4.0 (c) 2004 Scott Baxter
Data Measurement: PPP ThroughputNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
Point-to-Point Packet (PPP) throughput is the volume of packets transmitted between peer layer-2 entities in the 1xRTT systemPPP throughput may be higher or lower than the throughput of other layers, depending on transmission conditions and configuration
November, 2004 RF200 - 403RF200 v4.0 (c) 2004 Scott Baxter
Data Measurement: PL ThroughputNetwork View Protocol Stack View
APP
LLA
CPL
ICF
PLD
CF
PLD
CF
MU
X/Q
OS
SYSTEM
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
Frames
MOBILE
Inst 3L3 Sig
SRBP SRLP RBP RLP
PLDCF MUX / QoS
Physical - RLAC
Inst 2User Pkts
Inst 1Voc Bits
IS95L2Sig
1xL2Sig
OtherL2Sig
PktDataL2
NullL2
CktDataL2
IS95L3Sig
1xL3Sig
OtherL3Sig
PktDataSvc
VoiceSvc
CktDataSvc
t1t1v CESEL
t1
R-P
PDSNFA
PDSN HA AAA BSC
USER
BTS
SW
IP/VPN
PSTN
TestServer
TestServer
TestServer
Backbone
Physical Layer (PL) throughput is the actual bit content of the frames carrying information over the 1xRTT linksPL throughput can be higher or lower than the throughput of other layers depending on configuration and transmission conditions
November, 2004 RF200 - 404RF200 v4.0 (c) 2004 Scott Baxter
RF200 Appendix I
Case Study: Heavy Sector Loading
Case Study: Heavy Sector Loading
November, 2004 RF200 - 405RF200 v4.0 (c) 2004 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 CityIn 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 happenData collection equipment was on hand to record the event from the mobile sideSystem operations personnel were available to retrieve system-side statistics for the periodLet’s see what happened!
November, 2004 RF200 - 406RF200 v4.0 (c) 2004 Scott Baxter
The BTS at the BTA Conference Center
Classroom
BTS
from RFCAD
The classroom is about 500 feet northwest of the three-sector BTSThe BTS’ gamma face is the dominant sector for the classroom, at PN 212.
Looking northwest
212
208
204
N
from IQAnalyzer
November, 2004 RF200 - 407RF200 v4.0 (c) 2004 Scott Baxter
What to Expect:Loading Effects on the Forward Link
Light Traffic Loading
Ec/Io = (2/4)= 50%
= -3 db.
2w
1.5w
Pilot
PagingSync I0EC
0.5w
BTSTransmit
Power
On the forward link, the overhead channels (Pilot, Sync, and Paging) remain constantEach new traffic channel consumes additional transmit powerTotal transmit power increases as traffic increasesEc/Io decreases as traffic increases (Ec stays the same, but Io is driven up)
Heavily Loaded
Ec/Io = (2/10)= 20%
= -7 db.
2w
1.5w
Pilot
PagingSync
I0
EC
Traffic Channels
6w
0.5w
BTSTransmit
Power
November, 2004 RF200 - 408RF200 v4.0 (c) 2004 Scott Baxter
What to Expect:Loading Effects on the Reverse Link
Lightly Loaded Sector
ThermalNoise
Mobile
BTSReceivePower
On a lightly-loaded sector, the noise floor is relatively low and an individual mobile can be heard at comfortably low powerWhen the forward power goes up, each mobile’s open-loop power control will try to decrease mobile power outputOn a heavily loaded sector each mobile is competition against the others, so the BTS must raise each mobile’s power to remain competitiveClosed Loop power control takes a “double hit” – correcting for both increased noise and the mobile’s incorrect power control instincts
Heavily Loaded Sector
ThermalNoise
Other
Mobiles
BTSReceivePower
Mobile
“I can hear it coming in the air tonight…..”--Phil Collins
November, 2004 RF200 - 409RF200 v4.0 (c) 2004 Scott Baxter
BTS Loading Effects on the Reverse Link
Light Traffic LoadingOn 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
PagingSync I0EC
0.5w
Heavily Loaded
2w
1.5w
Pilot
PagingSync
I0
EC
Traffic Channels
6w
0.5w
November, 2004 RF200 - 410RF200 v4.0 (c) 2004 Scott Baxter
November, 2004 RF200 - 411RF200 v4.0 (c) 2004 Scott Baxter
All Phones in Idle Mode
Test Mobile C
all Begins
25+ Mobiles
Calls begin
Test Mobile call has ended,Other mobile calls continue
The Ground Shakes
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.
November, 2004 RF200 - 412RF200 v4.0 (c) 2004 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.
November, 2004 RF200 - 413RF200 v4.0 (c) 2004 Scott Baxter
Test Mobile Closed-Loop Power Control (TXGA)
Average-16 db
With only thisUser active
Average-6 db
while max usersactive
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
mobile’s own open-loop instinct to power down due to increased BTS power.
The rest is needed to keep the mobile’s signal competitive at
the BTS.
November, 2004 RF200 - 414RF200 v4.0 (c) 2004 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 users2. Rayleigh fading
3. Users’ varying vocoder rates4. Interference from elsewhere
November, 2004 RF200 - 415RF200 v4.0 (c) 2004 Scott Baxter
System-Side Data: Channel Element Usage
BTS DateStart 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 23196 11/3/98 8:00:00 8:30:00 265.42 145.49 1.82 45.22 62.49 37.78 45.18 17196 11/3/98 8:30:00 9:00:00 342.7 186.94 1.83 52.01 90.66 44.28 45.45 18196 11/3/98 9:00:00 9:30:00 317.5 172.02 1.85 43.67 79.94 48.4 45.82 21196 11/3/98 9:30:00 10:00:00 408.81 245.55 1.66 78.35 92.33 74.87 39.93 22196 11/3/98 10:00:00 10:30:00 288.33 138.41 2.08 46.61 60.9 30.91 52 16196 11/3/98 10:30:00 11:00:00 334.61 195.06 1.72 59.71 81.78 53.58 41.71 22196 11/3/98 10:30:00 11:00:00 289.53 161.27 1.8 60.04 60.48 40.75 44.3 18196 11/3/98 11:00:00 11:30:00 366.75 210.19 1.74 70.51 91.65 48.03 42.69 21196 11/3/98 12:00:00 12:30:00 299.25 156.26 1.92 53.34 63.01 39.91 47.78 18196 11/3/98 12:00:00 12:30:00 343.03 196.39 1.75 60.06 83.54 52.79 42.75 22196 11/3/98 13:00:00 13:30:00 327.2 225.23 1.45 71.01 78.72 75.51 31.16 31196 11/3/98 13:00:00 13:30:00 316.68 168.14 1.88 54.19 68.32 45.62 46.9 18196 11/3/98 13:30:00 14:00:00 270.9 163.34 1.66 57.55 55.8 49.99 39.7 18196 11/3/98 14:00:00 14:30:00 266.42 137.25 1.94 42.92 48.73 45.6 48.48 17196 11/3/98 15:00:00 15:30:00 323.56 193.92 1.67 56.77 79.3 57.85 40.07 20196 11/3/98 15:00:00 15:30:00 427.2 269.9 1.58 83.71 100.68 85.52 36.82 23196 11/3/98 15:30:00 16:00:00 316.61 191.03 1.66 56.15 82.61 52.27 39.66 21196 11/3/98 16:00:00 16:30:00 458.76 274.99 1.67 77.06 123.62 74.31 40.06 23196 11/3/98 17:00:00 17:30:00 444.98 244.12 1.82 81.45 94.16 68.51 45.14 24196 11/3/98 17:30:00 18:00:00 414.68 233.43 1.78 84.75 86.33 62.35 43.71 24196 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.
November, 2004 RF200 - 416RF200 v4.0 (c) 2004 Scott Baxter
System-Side Data: BTS Blocks
Cell Start DateStart 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 988196 11/3/98 8:30:00 9:00:00 0 0 0 0 0 0 112 934196 11/3/98 9:00:00 9:30:00 0 0 0 0 0 0 126 907196 11/3/98 9:30:00 10:00:00 0 0 0 0 0 0 160 1099196 11/3/98 10:00:00 10:30:00 0 0 0 0 0 0 77 853196 11/3/98 10:30:00 11:00:00 0 0 0 0 0 0 121 1009196 11/3/98 10:30:00 11:00:00 0 0 0 0 0 0 102 924196 11/3/98 11:00:00 11:30:00 0 0 0 0 0 0 132 905196 11/3/98 12:00:00 12:30:00 0 0 0 0 0 0 102 885196 11/3/98 12:00:00 12:30:00 0 0 0 0 0 0 105 852196 11/3/98 13:00:00 13:30:00 0 20 0 0 0 0 172 1018196 11/3/98 13:00:00 13:30:00 0 0 0 0 0 0 97 913196 11/3/98 13:30:00 14:00:00 0 0 0 0 0 0 117 744196 11/3/98 14:00:00 14:30:00 0 0 0 0 0 0 83 953196 11/3/98 15:00:00 15:30:00 0 0 0 0 0 0 132 924196 11/3/98 15:00:00 15:30:00 0 0 0 0 0 0 149 1103196 11/3/98 15:30:00 16:00:00 0 0 0 0 0 0 119 828196 11/3/98 16:00:00 16:30:00 0 0 0 0 0 0 129 1064196 11/3/98 17:00:00 17:30:00 0 1 0 0 0 0 128 1044196 11/3/98 17:30:00 18:00:00 0 0 0 0 0 0 129 914196 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.
November, 2004 RF200 - 417RF200 v4.0 (c) 2004 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 0196Y 111 110 99.1 0 0 0 0 1 0.9 0 0 4 3.64196Z 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.
November, 2004 RF200 - 418RF200 v4.0 (c) 2004 Scott Baxter
RF200 Appendix II
CDMA Information ResourcesBibliography - Web Links
CDMA Information ResourcesBibliography - Web Links
November, 2004 RF200 - 419RF200 v4.0 (c) 2004 Scott Baxter
Bibliography, 3G Air Interface Technologies"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 Demystified” by Lawrence Harte, Richard Levine, and Roman Kitka488pp. 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. This book will give you how your technology relates in the big picture, and probably all you care to know about technologies other than your own.
"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 RamjeePrasad. 476pp. 2001 Artech House, ISSBN 1-58053-180-6. $100. A complete and definitive work on UMTS (good CDMA2000, too!). CDMA principles, Mobile Internet, RF Design, Air Interface, WCDMA FDD standard, WCDMA TDD, CDMA2000, Performance, Hierarchical Cell Structures, Implementation, Network Planning, Basic IP Principles, Network Architectures, Standardization, Future Directions.
November, 2004 RF200 - 420RF200 v4.0 (c) 2004 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, ipnetwork 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).
November, 2004 RF200 - 421RF200 v4.0 (c) 2004 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 you’re not already strong in TCP/IP, you’ll 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.
November, 2004 RF200 - 422RF200 v4.0 (c) 2004 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 ArtechHouse, 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 collector’s item.
November, 2004 RF200 - 423RF200 v4.0 (c) 2004 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" 2nd. Edition by William C. Y. Lee. 689 pp. McGraw Hill 1998 $65. ISBN 0-07-037103-2 Lee’s latest/greatest reference work on all of wireless; well done.
November, 2004 RF200 - 424RF200 v4.0 (c) 2004 Scott Baxter
Web Links and Downloadable ResourcesScott Baxter: http://www.howcdmaworks.com
Latest versions of all courses are downloadable. Category - Username - PasswordIntro - (none required) - (none required)RF/CDMA/Performance - shannon - hertz3G - generation - thirdGrayson - telecom - allenAgilent - nitro - viper
Dr. Ernest Simo’s Space2000: http://www.cdmaonline.com/ andhttp://www.3Gonline.com/
CDG: http://www.cdg.org (check out the digiventsmultimedia viewable sessions)The IS-95 and IS-2000 CDMA trade marketing webside, CDMA cheerleaders.
GSM: http://www.gsmworld.comThe GSM Association website. Worldwide GSM marketing cheerleaders but also includes some excellent GSM and GPRS technical overview whitepapers and documents; latest user figures.
RCR News: http://www.rcrnews.comWireless Industry trade publication - regulatory, technical, business, marketing news.Subscribers can access text archives of past articles; very handy in researching events.
November, 2004 RF200 - 425RF200 v4.0 (c) 2004 Scott Baxter
More Web Links3GPP: 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/
November, 2004 RF200 - 426RF200 v4.0 (c) 2004 Scott Baxter