917016c6

Fundamentals of CDL
Analysis
Motorola Japan
V6.0
Motorola Confidential Proprietary Fundamentals of CDL Analysis
1
Revised History
• Created V0.0 – V3.0 by J. Hutchison

• V4.0 - Added tools section by Takemura Daigo
• V5.0 - Updated for R16.0 by Chang Choi
• V6.0 – Updated for R16.1 by Keisuke Kato

2
Today’s Presentation
• Why Do CDL Analysis?
• Information Available in CDLs
• While learning CDL information, we will also study

basic CDMA Call Processing.
• “Hands-On” troubleshooting Exercises using CDLs.

3
Why Do CDL Analysis?

4
System Performance Analysis
Techniques
PM Statistics DriveTest/DM/Compass Logs
Extremely Detailed Tables Per-call Records of everything

Counting Events over fixed that happens at the mobile:
time periods:
• Infrastructure Orders
• Originations sent to Mobiles
• Terminations • Mobile Responses
• Registrations • Downlink RF Conditions
• Failures • Uplink RF Transmit
• Handoffs Power
• Call Final Classes • Control Channel
• and more... Messages
• and more...

5
Techniques (continued)
SMAP CallProc1 Debug
Per-Call Records of Records of nearly every MM

Infrastructure events: transaction
• Forward Transmit Power • SCAP Messages to and

• Reverse FER from Base Stations
• A+ Message Sequences • A+ Messages to and
• SCAP Message from the EMX
Sequences • Messages to and from
• Paging/Sync Messages the Transcoders
• and more...

6
Techniques (continued)
Event Logs & Alarm Manager Call Detail Records (CDLs)
Hourly records of all bad and Per-call records containing

unusual events seen by the detailed information regarding:
OMC-R
• Setup Events
• Major, Minor, and • TearDown Events
Critical Alarm Sets • Type of Call
• Major & Critical Alarm • Sites and CBSCs
Clears • Handoff Stats
• Incomplete/Failed • RF Performance Stats
Transactions between • and more...
Network Elements

7
Analysis Techniques : Pros & Cons
Analysis Technique Pros Cons

Excellent System-wide Performance
Summaries. Can estimate device utilizations
and do Capacity Planning. No impact to the PM stats can tell you what is wrong, but
PM Statistics system. often do not tell you *WHY*
Absolutely the Best Way to Debug RF
Coverage Problems in Specific Area. No Very time consuming. Small Samples.
Drive Test / DM / Compass Logs impact to the system. Area specific.
Provides an Excellent Per-call view of what is Small Samples. Bad Reputation of
SMAP happening at the base station. causing Outages in the past.
Dangerous to Use on a Live System.
Best Way to characterize and Debug CBSC Requires developer level understanding of
CallProc1 Debug Call Processing Problems. Call Processing SFS to be of any use.
Poor Indicator of Performance Trends:
Best Way to piece together timelines of Events tell you only what is bad, not what
failures and recoveries. No impact to the is good. Not very useful for debugging
Event Logs / Alarm Manager system. RF-related problems.
Great General Purpose technique for both
debugging problem AND characterizing Stats computation is more complex and
system performance. No impact to the Time Consuming than PM. Level of detail
system Many types of stats impossible to is *slightly* less than that of Drive Test &
Call Detail Records calculate with PM can be derived from CDLs. SMAP Logs.

8
Analysis Techniques : Conclusion
• CDL Analysis, while more complex than PM Stats, can

provide much more detail.
• CDL Analysis, while not as detailed as per-Call Drive

Test Log + SMAP analysis, allows performance
information to be derived for ALL CALLS in the area of
interest.
• For these reasons, CDL Analysis has been used as the

Primary FOA, RF-Field Test, and RF-crisis resolution
analysis technique.

9
Information contained in CDLs

10
Main Categories of CDL Data
• CBSC General Info • Handoff Fail Stats

• XC Assignment Info • Inter-CBSC Soft
• Mobile Info Handoff Stats
• BTS Tch Assign Info • Last RF BTS
• Access Details Connection Stats
• CBSC Release Info • BTS Tch Assign Info
• Hard Handoff Target • Access Details
Info • CBSC Release Info
• N-way Stats • Initial MAHO Stats
• N-way Final Elements

11
Main Categories of CDL Data
(continued)
• Next-to-Final Active • Forward & Reverse
Set Stats Quality Stats
• Next-to-Final • Vocoder Bypass Stats
Candidate Set Stats • Packet Data Stats
• Final Active Set Stats • Voice/Data Toggle Stats
• Final Candidate Set • Carrier Load
Stats Management Stats
• First Soft Handoff • 1X Packet Data Stats
Stats
• Setup Event List

12
CDL Fields
• There are over 330 fields in R9, over 350 fields in R15,
and around 490 fields in R16.0 (Six more new fields were
added in the later version of R16.0). For R16.1, the total number is
up to 536.
• Is it necessary to know every CDL field to do CDL
analysis?
– Answer : No. You can be an effective analyst knowing just
a few important fields.
– With practice and experience, you will learn more fields,
and become an even more powerful analyst.
– Various tools are/can be available to analyze call/system
status by applying a few fields in CDL.

13
CBSC General Fields
• CBSC - Identifies the CBSC controlling the call (From

R16.0, it is called TCBSC and contained more information than just
MM number).
– In JCDMA, five digits numerical value are used for the
CBSC number. The following table shows the information
for each digit.
DIGIT MEANING
1st digit Always “1”
2nd digit Area such as auK
3nd and 4th digit “00 –99” OMCR ID
5th digit MM number

14
CBSC General Fields
• CPP - Identifies the XC (Transcoder) Call Processing

Processor GPROC
– OMC unit + CBSC + CPP fields uniquely identify a CPP
(e.g CPP E1-8, H3-5)
– If a Transcoder is suspected to be causing problems, you
should check this field to see if a particular GPROC is
associated with the bad calls.
• CIC Span - Tells which E1 span is connecting the

Transcoder to the EMX.
– Note: If the CIC is ZERO, check if the call is a Packet Data call. Packet
Data calls do not require connection to EMX.

15
XC Assign Info
• CIC Slot - Tells which TimeSlot on the CIC span is being

used.
– Should never be 0 or 16. Exception: Packet Data calls show
CIC_SLOT=0. If there are many CFC-21 calls, always check this field.
• XCDR - Tells which Transcoder is handling the call. If a

Transcoder frame is suspected of causing problems,
check if bad calls are associated with a particular XCDR.

16
MOBILE INFO
• MID - Mobile ID. Similar to a Mobile Phone Number

– 1st three digits are called MIN2. Typical values are 440,
441 (DDI), 190, 191 (IDO). 192 is often assigned to
prototype test phones not yet for sale on the open market.
– Last seven digits are called MIN1. These are always the
same as the last seven digits of the Mobile Phone
Number. For example, MIN1(0903-724-0888) = 7240888
• ESN - Electronic Serial Number. An eight digit

hexadecimal code. Last three digits identifies a phone
model. Last digit identifies the phone maker.

17
MOBILE INFO (continued)
More on ESNs
• Last Digit (or Last 2 Digits) Tells us the Maker
1 = Kyocera
2 = Sony
3 = Toshiba
4 = Hitachi
5 = Motorola (2nd to last digit is even)
5 = Tottori-Sanyo (2nd to last digit is odd)
7 = Fujitsu (2nd to last digit is even)
7 = Panasonic (2nd to last digit is odd)
8 = Sanyo
9 = Casio (2nd to last digit is even)
9 = Motorola TSU (2nd to last digit is odd)
e = Denso

18
• SCM - Station Class Mark - Tells the Infrastructure the

capabilities of the phone making the call.
– 0x62006200 = Regular Single-Mode JCDMA Phone
– 0x6200f300 & 0x6200e200 = Old Dual-Mode (Analog+CDMA) Phones. No

longer sold, but some people still have them.
– 0x62004a00 - Test Subscriber Unit (TSU). A special phone at the BTS used for
loopback and other tests.
– 0x6200ea00 - Motorola JCAMPS computer-controlled Drive Test phone.
– NOTE: Expect Kansai City Media (KCM) band and 1X capable phones to have
new SCMs.

19
• Dialed Digits -- Tells us the Number Dialed by the

Subscriber
– Set for Mobile Originations ( Entry Type = 0 ) only
– Value of “0” indicates either:

• Mobile Termination
• Mobile Origination -- Packet Data Call
• Mobile Hard Hand-in
– May include the ‘*’ and ‘#’ signs.

20
BTS Tch Assign Info
• Init RF Connect BTS -- Tells us the first BTS the mobile assigned in
this CDL. If the CDL entry type is not 2 (Hard Hand-in), this will be
the first BTS of the call.
• Init RF Connect Sector -- Tells us the first Sector assigned in this

CDL.
• Init RF Connect MCC -- Tells us the first MCC panel assigned in

this CDL.
• Init RF Connect Element -- Tells us the first MCC Channel Element

assigned in this CDL

21
BTS Tch Assign Info (continued)
• Init RF Connect ELEMENT TYPE -- Tells us the first channel

element type the mobile assigned in this CDL. 1 if the ELEMENT is
a 1x channel element, 0 otherwise.
• Init RF Connect IP ADDRESS – The IP address of MCC Channel

Element, if it has one (IP Address format).
• Init RF Connect PSICE IP ADDRESS -- IP Address of the PSI-CE

associated with the call (IP Address format).
• Init RF Connect PSICE PORT – The port of the PSI-CE associated

with the call (Decimal format).

22
BTS Tch Assign Info (Continued)
• Init RF Connect Channel -- Tells us the first RF carrier assigned in

this CDL. If the CDL entry type is not 2 (Hard Hand-in), this will be
the first BTS of the call.
– Hi Band Channels : 76, 184, 292, 400, 508, 616, 724
– 1X Carrier Channel : 508 (The Channel 508 is initially used for 1X
carrier for KDDI Systems).
– Lo Band Channels : 872, 968
– Marinet Band Channel : 1120
NEW!
• Init RF Connect BTS Signalling Type R16.1
– Signalling type of the BTS associated with the TCH assigned. Options are:
• 1: BTS with Packet Signalling
• 0: BTS with Circuit Signalling

23
Access Details
• Access Time - Tells us when the call started
• Access PN Offset -- This is NOT the PN offset of the assigned

channel! Motorola should have probably chosen a better name.
Instead, this is the ROUND TRIP RF delay measured in CDMA
chips. In dense urban areas with high buildings, the estimated
distance in below equation might not be too accurate due to multi-
paths problem.
– We can calculate the Mobile--BTS distance by this formula:
Distance (in Kilometers) = [Access PN Offset - 14] / 8

24
Access Details (Continued)
• Access Strength -- Tells us the Initial BTS Received Signal

Strength.
– Typically, the base station wants to see about 0x0b00 from the mobile.
– Japan ASE experiments have shown that if Access_Strength is less than
0x0200, CFC-5 (No Tch Preamble) Access Failures are very likely.
– ASE has developed the following (unofficial) formula relating RX Eb/No to
Access Strength: Eb/No ~= 10 * Log [Access_Strength] - 26.5 (dB)
– When investigating Access Failure problems, always check this field as well as
the Access PN site distance.
• Access Channel -- Tells us the RF carrier initially assigned to the

call. Same as Init RF Connect Channel except it is set at ZERO
when the CDL is for an HHO.

25
• Access BTS -- Tells us the first BTS assigned for a call. Same as
Init RF Connect BTS, except it is set to ZERO if the CDL is for a
Hard Hand-in call.
• Access Sector -- Same as Init RF Connect Sector, except it is set

to ZERO if the CDL is for a Hard Hand-in Call.
• Entry Type -- Tells us how the call started on the CBSC:

0 = Mobile Origination
1 = Mobile Termination
2 = Hard Hand-in
3 - CDMA to CDMA soft handoff (A+)
Note:Access Channel, Access BTS, and Access Sector fields are redundant. The exact same information can be
obtained from Entry Type, and Init RF Connect Channel, BTS, and sector.

26
• Service Option -- Tells us what kind of call is being made

27
• Negotiated Service Option -- Shows Service Option

assigned by system when mobile requested service
option is rejected. If initial mobile request is accepted, it
is set to 0xffff. Exception: When a CDL is for Hard
Hand-In, shows Service Option in use.

28
• Last MM Setup Event (LMMSE) -- Tells us how far the Mobility

Manager (at the CBSC) got along trying to setup a call.
– We want to be sure the Mobile gets onto an RF traffic

channel. If this happens, we consider the setup as
“good”.
– “Good” LMMSEs : 4, 5, 17, 18, 20, 21, 22
– But what do these numbers really mean? We need to

now review Basic Call Processing to answer this. . .

29
Getting to the Conversation State…
Mobile-Base Station Call Processing
Mobile Base Station
Detect User-Initiated Call
> Access Channel >
Send Origination Message Set up Traffic Channel
< Paging Channel <
Sets Up Traffic Channel Send Channel Assignment Message
< Forward Traffic Channel <
Receives N consecutive valid frames Begin Sending Null Tch Data
> Reverse Traffic Channel >
Begin sending TchPAM Acquires the Reverse Traffic Channel
< Forward Traffic Channel <
Receive Base Acknowledgement Send Base Station Ack Order
Mobile Station Ack Order
Begin sending null Tch Data Start Sending 1/8 STRAU to XC
Receive Service Option Response/ < Forward Traffic Channel < Forward Service Option Response/
Service Connect Message Service Connect Message
Mobile Station Ack Order
Service Connect Complete Message > Reverse Traffic Channel >
Conversation! Conversation!
This flow describes a call origination where all goes well.

30
Base Station - CBSC Call Processing
Base Station CBSC
> Origination Message >

Send Origination Message
< Base Ack <
Get the ACK Acknowledge the Origination
< Channel Assignment Order (16) <
Sets Up Traffic Channel Tell BTS to setup a Channel
> Tch Preamble >
Detect Tch Preamble Wait for Base to detect Preamble
< Base Station Ack Order <
Send ACK Order to Mobile Send Base Station Ack Order
> Mobile Station Ack Order >
Get Mobile ACK Order Reply
> NULL 1/8 Rate Frame >
Start Sending 1/8 STRAU to XC Detect 1/8 NULL STRAU
< Service Connect Message <
Send SC Message to MS Tell Base to Send Service Connect
Message to Mobile
Receive SC ACK from MS > Service Connect Complete (17) >
And if everything on the EMX side Ok
< Speech >


31
CBSC - EMX Call Processing
CBSC EMX
Get Origination Message for Mobile
> CM Service Request (1) >
Tell EMX we have a new call Get the CM Service Request
< SCCP Connection Confirmed (2) <
Get the ACK Acknowledge CM Service Request
> Setup (10) >
Tell EMX to proceed with Setup Start Setting up the Call
< Call Proceding (11) <
Get the Call Proceeding Indicator Tell CBSC we are setting up Call
< Assignment Request (15) <
Get the Assignment Request Tell CBSC its OK to put Mob on Tch
Get Mob Service Connect Complete
> Assignment Complete (18) >
Tell EMX Mobile is Connected Start Ringing Called Party
< Alerting (19) <
Get the Alerting Message Tell CBSC Called Party is Ringing
< Connect (22) <
Get the EMX Connect Message Called Party Answers
> Connect Ack (23) >
Acknowledge the Connect All is Well! Both the Mobile and
Called Party connections are up
< Speech >


32
Last MM Setup Event (LMMSE)
• Mobile Origination ---

Entry Type = 0
• Good Calls ---
16 < LMMSE < 24

33
• Mobile Termination ---

Entry Type = 1
• Good Calls ---
16 < LMMSE < 24

34
• Hard Handoff --- Entry Type = 2
• Good Calls --- LMMSE = 5

35
Access Details (Continued) NEW!
R16.1
SDU Call Setup Events (1)
• A bitmap of call setup events from the SDU’s perspective. It has 64 possibilities, 23
of which are unused at the moment. (events do not necessarily occur in order listed)
• These may apply to Hard Hand-ins, originations, terminations etc.

36
R16.1

37
R16.1
• The events mentioned in the last 2 slides are
represented in the CDL in the following 2 fields .
• SDU_SETUP_EVENTS1
– The LSB corresponds to setup event 0 and the MSB 31.
• SDU_SETUP_EVENTS1
– The LSB corresponds to setup event 32 and the MSB 63.
Note: Need to show how to read these fields

38
R16.1
SDF_TYPE
• Applies to call setup and the target side of a hard
handoff.
• Indicates whether the call’s selection/distribution function
was performed at the XCDR or the SDU-SDF.
• The available options are:
– 1: Selection/Distribution Carried out at the XC Platform.
– 2: Selection/Distribution Carried out at the SDU Platform.
– 0: Call ended before selecting the platform.

39
R16.1
Access Handoff (FR4078) Fields
• ACCESS_CBSC
– The external CBSC ID to which the BTS belongs to that received the access
probe.
• ADD_PROBES_RCVD
– The number of additional access probes received by the call setup MM for the
same call. (includes those received from both remote and local BTSs)
• LAST_PROBE_TIME
– The time the last access probe was received. If only 1 probe was received, this
field is equivalent to the ACCESS_TIME field.
• SILENT_RETRY_IND
– Indicates whether a silent retry access attempt occurred and whether the TCH
that was allocated from the initial attempt re-used for the silent retry. The fields
can have the following:
• 0 – no silent retry probe received.
• 1 – received a silent retry probe and resulted in reusing an allocated TCH.
• 2 - received a silent retry probe and the TCH allocated was not re-used.

40
NEW!
R16.1
Access Probe Handoffs
ACTI VE PILOT PN 12
ACTI VE_PILOT_STR -5 MSC-1
FIRST_I S_ACTI VE 0
FIRST_I S_PTA 0
NUM_ADD_PILOTS 3
PILOT_PN_PH PILOT_STR ACC_HO_EN ACC_ATT
CBSC-2 examines the
PN- 4 -6 1 1 8 RER and determines
PN - 8 -10 1 1 PN-4 is the first pilot.
PN - 24 -2 0 0 First Sector CBSC-2 uses the
of access Cell Id-1 Neighbor list of cell
Id-3, PN-12 to
CBSC-1 CBSC-2 translate PN-4 to
CBSC-1&Cell Id-
IC FWD Channel Required 1.Therefore CBSC-1 is
the call-setup CBSC.
CBSC-2 forwards the
Channel Required and
Cell-Id 1 info. to
Channel CBSC-1
7 Required
Cell Id-1 Cell Id-2 Cell Id-3

PN-4 PN-8 PN-12
6
r1 2 Origination
r 3
4
Origination
5
Layer 2
Ack.
Access Access
Probe HO Probe HO

41
CBSC Release Info
• Call Final Class (CFC) -- The MOST IMPORTANT CDL Field. CFC
tells us how a call finished.
– Good CFCs : 1, 24, 25, 30, 31, 111

If 16 < LMMSE < 24 (Orig/Term Calls). . .
And if CFC-111, Init Disconnect Cause = 0x1802 or 0x1100
– Ambiguous CFC : 26. Sometimes a good call (Mobile rings for

45 seconds with no answer, or land disconnects while mobile is
ringing. Other cases, CFC 26 is a bad call.
– Bad CFCs : All others! There are currently 63 types of bad call
CFCs. More will be introduced in future releases.

42
CBSC Release Info (Continued)
The “Good” CFCs. . .
• CFC 1 -- Normal Call, Land Release
• CFC 24 -- Successful External Hard Handoff to CDMA.
– “External” does not mean “an external CBSC”. It simply means the mobile reports a Tcomp candidate Pilot
Beacon, and the CBSC ends up ordering a Hard-Handoff to a different carrier. Motorola could have picked
a better name, for example, “Successful Pilot Beacon Handoff”.
– Occurs with successful DAHO hard-handoff also. DAHO is generally not used in Japan.
• CFC 25 -- Successful External Hard Handoff to Analog

– Same as a CFC-24, but in this case, the Pilot Beacon (or DAHO) database points to an an analog sector
(XASECT) instead of a CDMA sector (XCSECT).
• CFC 30 -- Successful Anchor Hard Handoff

– The mobile crossed over a CBSC boundary, and control of the call was passed to the new CBSC
• CFC 31 -- Normal Call, Mobile Release

• CFC 111 -- Packet Data Normal Call Release

43
The “Bad” CFCs. . .
RF Trouble CFCs: MSC Trouble CFCs: No Resource CFCs:
CFC-3 : RF Layer 2 Failure CFC-26 : Abnormal MSC Disconnect CFC-2 : Tch Disabled
CFC-4 : RF Loss CFC-27 : MSC Disconnect with SCCP CFC-18 : No Xcdr Circuit
CFC-5 : No Tch Preamble Connection Refused CFC-19 : No DTC
CFC-8 : MS Did not Arrive on HHO Target CFC-28 : MSC Disconnect with SCCP RLSD CFC-20 : No Radio Resources
Channel CFC-21 : Requested Terrestrial Resource
CFC-9 : No Valid Speech from MS during Call Unavailable
Setup CFC-33 : No Radio Resources - Redirect to Analog
CFC-10 : No Valid Speech from MS during Hard Discrepancy CFCs: CFC-138: No PSI_SDU Available
Handoff CFC-11 : Active Set Mismatch CFC-139: No PSI_CE Available
CFC-13 : CP Timeout Awaiting Service Option Ack CFC-14 : Not Enough Mobile Status Information CFC-142: PSDN Resources not Available
CFC-29 : Handoff Procedure Timeout Received CFC-143: PCF Resources not Available
CFC-134 : Call Blocked - ELPA Fixed Limit CFC-15 : Negotiation Failure
CFC-135 : Call Blocked - Forward Load Limiting CFC-22 : Terrestrial Circuit Already Allocated
CFC-136 : Call Blocked - Reverse Load Limiting CFC-32 : Disabled Service Option
CFC-146: Call Blocked – LPA Self Calibrating limit
IWU Trouble CFCs:
CFC-100 : Circuit Data IWU T1.617 Setup Failure
H/W Failure CFCs: CFC-101 : Circuit Data CDP T1.617 Setup Failure
CBSC Trouble CFCs: CFC-23 : Radio Interface Failure CFC-102 : Circuit Data IWU T1.607 Setup Failure
CFC-6 : No STRAU Synch CFC-52 : Equipment Failure at BSC CFC-103 : Circuit Data CDP T1.607 Setup Failure
CFC-7 : CP Timeout Awaiting MS Acquistion CFC-53 : Equipment Failure at MSC CFC-104 : Circuit Data IWU T1.617 Initiated
CFC-12 : CPP Call Setup Timeout CFC-132 : Equipment Failure at Target BSC Disconnect of Stable Call
CFC-60 : Protocol Error between BSC and MSC CFC-105 : Circuit Data CDP T1.617 Initiated
CFC-61 : Protocol Error between MM and XC Disconnect of Stable Call
CFC-106 : Circuit Data IWU T1.607 Initiated
CFC-62 :
CFC-13 :
XC Detected Error
CP Timeout Awaiting Service Option Ack
Human-Caused CFCs: Disconnect of Stable Call
CFC-70 : Service Configuration Toggle Procedure CFC-50 : O&M Intervention at BSC CFC-107 : Circuit Data CDP T1.607 Initiated
Failure CFC-51 : O&M Intervention at MSC Disconnect of Stable Call
CFC-80 : MM Internal Error CFC-54 : Reset or Reset Circuit from MSC CFC-108 : Circuit Data CPP Inactivity timer Timeout
CFC-81 : MM Database Error CFC-131 : O&M Intervention at Target BSC CFC-109 : Circuit Dat Call Failure
CFC-130: Target XC Failure CFC-112 : Packet Data Setup Failure
CFC-133: Internal Target MM Failure CFC-113 : Packet Data Protocol Violation
CFC-114 : Packet Data Unresolved IWU Release
Note : There is also CFC-255 for “Unknown” Failures
44
NEW!
NEW R16.1 CFCs R16.1
• CFC-34: BTS Call Setup Timeout

– The packet BTS timed out waiting for a message during call setup.
• CFC-35: Resource Allocation Timeout
– Denotes that one Network Element timed out while waiting for another Network Element to
allocate resources.
• CFC-36: No SDU Resource Available
– The MM received an indication from the SDU that there was no SDF resource available for
the call.
• CFC-40: Target CBSC Call Setup Failure
– Occurs when a remote MM is unable to allocate RF resources for the call during call setup,
and the causes are not RF related.
• CFC-82: BTS Internal Error
– An error within the packet BTS occurred.
• CFC-83: Lack of 1X Resources and Support for Downgrade Disabled
– Generated when the MM detected an invalid Service Option from the Service Option
Database parameter 1X HSPD Downgrade.
• CFC-146: A11 Registration Denied
– Generated when the PCF fails to register with the PDSN.
• CFC-149: No Backhaul Capacity
– Generated when calls are blocked due to the lack of bandwidth capacity, determined by
admission control function at the packet BTS.
NOTE: some existing CFCs have been modified as well (mainly

Motorola Confidential Proprietary new detailed causes associated with them) Fundamentals of CDL Analysis
45
• The table to the left shows CFC distribution

taken from 10,000 calls from the KCT F-unit
CFC Count Pe rc e n tage
at about 4am. 111 5006 50.06
31 2400 24
1 1956 19.56
27 303 3.03
• Even though there are 64 different CFC 5 128 1.28
4 79 0.79
classes, we typically only see 15 classes 13 50 0.5
30 37 0.37
normally ( including CFC-9, although CFC-9 24 21 0.21
did not appear in this sample.) 3 12 0.12
28 4 0.04
26 2 0.02
29 1 0.01
60 1 0.01
• Of these 14 classes, CFC-3, 4, 5, 9, 13, 27, Total 10000 100
28, 29, and 60 are “Bad” ones. We will
study these ones in detail. Lets begin with
CFC-3, 5, and 13, the RF setup failure
CFCs.

46
RF Call Setup & Failure Stages
Start
MCC XC Wait for

Wait for 1/8 Null
TchPAM STRAU
Detected? No
CFC=5 Detected? No
CFC=9
XC Wait for XC Wait for

Mobile ACK Service
Order Option ACK
If T3230 expires before MaxRetry
attempts occur, CFC60 is pegged.
If MaxRetry attempts occur before
T3230 expires, CFC3 is pegged.
Detected? No
CFC=3 or 60 Detected? No
CFC=13
Conversation

47
RF Call Setup & Failure Stages (Continued)
CFC-3, RF Layer 2 Failure
• A CFC-3 is pegged when the base station transmits the maximum

number of repeats on the Forward Traffic Channel.
• CFC-3 may happen at any part of the call (e.g. Call Setup,
Conversation, etc.), but is usually seen during the Call Setup Phase.
• The maximum number of repeats is specified using EDIT XC

XCL2PARMS. Most JCDMA systems use a default value of 30
retries. Time between retries is hard-coded to 300ms.

48
RF Call Setup & Failure Stages(Continued)
CFC-5, No TCH Preamble
• The Tch Preamble (TchPAM) is used by the base station to detect mobile arrival on a
traffic channel. For Rate Set 1, TchPAM consists of 192 zeros that are transmitted at
the 9600 bps rate. For Rate Set 2, TchPAM consists of 288 zeros that are transmitted
at the 14400 bps rate.
• The EDIT BTS TCHGEN command defines the MCCT1 timer (Default=5 seconds).
As soon as the BTS sends the MOBILE as Traffic Channel Assignment order, the
MCC starts this timer. This timer is stopped when TchPAM is detected. If this timer
expires, CFC=5 results.
• The EDIT BTS TCHGEN command also specifies the PAMEBNO (Default = 5.27dB)
and PAMIPER (Default=6) parameters. These parameters determine the MCC's
TchPAM detection sensitivity. Japan ASE experiments have show that CFC-5 rates
can be reduced, and overall call completion rates can be improved by lowering
PAMEBNO to 4.27 dB.

49
RF Call Setup & Failure Stages(Continued)
CFC-9, No Valid Speech
• The EDIT XC XCCPPARMS command specifies the T11 (Default = 14 seconds) timer.
• After the MM sends a Tch CHANNEL assignment to the mobile, it sends a XC Channel Assigned message to the
XC. When the XC gets the XC Channel Assigned message, T11 starts. If T11 reaches ZERO and 1/8 STRAU
has not been detected at this time, CFC-9 results
• A CFC 9 will also be generated if XC State Timer 4 (Default=5 seconds), "Wait for Valid Speech", expires. Once
Tch Preamble has been detected, the XCDR transitions from Idle frames to Invalid frames, and the CPP changes
to XC CP State 4 (Wait for Valid Speech) and starts XC State Timer 4. At this time, a Base station Ack order is
then sent down to the mobile. In normal cases, the mobile will ACK the order, and the begin sending up 1/8
STRAU. If all goes well, the XCDR will then transition to valid frames. But if XC State Timer 4 expired, a CFC 9
occurs.
• POSSIBLE PROBLEMS:
– RF link conditions
– Falsing on preamble. Note if the EDIT BTS TCHGEN parameter TchPAMEbNo is set to a low value (e.g. 4.27 dB)
CFC 9 calls will increase and CFC 5 calls will decrease. Therefore when analyzing call setup failures, it is important
to consider the total RF-related setup failure CFCs (3, 5, 9, and 13).
– Possible bad XCDR card. Note CIC and SPAN.
– CP XC State Timer 4 "Wait for Valid Speech" is set to low. During the R9.0 FOA in Fukuoka, a bad XCDR card was
generating many Spurious Interrupts. These interrupts were loading down the CPP cage controller to the point that
XCDR to KSW connection requests were not being processed causing high CFC 9.

50
RF Call Setup & Failure Stages (Continued)
CFC-13, CP Timeout awaiting Service Option ACK
• The "EDIT XC XCSOPARMS" command defines the T8 (Default = 5 seconds) timer. After
STRAU is detected by the XC, the XC will send a SERVICE CONNECT MESSAGE to the mobile,
and will start T8. If T8 reaches ZERO, and the Service Option ACK has NOT been received from
the mobile, CFC-13 results.
• ANOTHER NOTE: After 1/8 STRAU has been successfully detected, T11 continues to run. If
T11 reaches ZERO before the Service Option ACK is received from the mobile, CFC-13 results.
• Possible Problems
– Verify that the T8 timer is set correctly. Recommended value is 5 seconds.
– RF Link conditions. A call may have just barely cleared the CFC-5 and CFC-9 gates, and then fail the CFC-
13 gate. Look at the ACCESS STRENGTH field.
– XCDR board exhibiting Internal Fault alarms. Check CIC and SPAN fields to see if a particular board is
associated with CFC-13. It was seen in the Charlotte Bell Atlantic market that CFC 13s corresponded to an
XCDR board exhibiting Internal Fault alarms. The board was replaced to fix the problem.
– Possible Bad BBX card. Check the INIT RF CONN BTS, SECTOR, and CHANNEL fields to see if a
particular BBX is associated with high CFC-13s. Try swapping to the redundant BBX.

51
CFC-4 : RF LOSS
• CFC 4 : RF Loss. Also commonly referred to as “Dropped Call”.
• CFC 4 is perhaps the most closely watched CFC by system

operators.
• RF Loss can occur on either the uplink or the downlink.
• Usually bad RF conditions cause RF Loss, but DELTA BTS SPAN

Delays in excess of 20 milliseconds can cause very high RF loss
with GOOD RF conditions. More on this later.

52
CFC-4 : RF LOSS (Continued)
• Forward Link RF Loss: A RF Loss occurs inside the mobile when the
mobile Forward TCH Fade timer expires. The Forward TCH Fade timer is
set per IS-95 to 5 seconds.
– Whenever a mobile sees 12 bad frames in a row, he starts his Forward Traffic
Channel Fade timer and stops transmitting.
– Whenever a mobile sees two (2) good frames in a row, he resets his Forward Traffic
Channel Fade timer and resumes transmitting.
– If the mobile Forward Traffic Channel Fade timer runs for five (5) seconds, the mobile
detects RF loss. The mobile exits the Traffic channel and goes back to the idle state
listening on the Paging channel.
– The base will detect the loss of the uplink signal and declare an RF loss based on the
Reverse Traffic Channel RF loss criteria (explained in the next slide.)

53
RF LOSS (Continued)
• Reverse Link RF Loss: In this case, the XCDR detects excessive erased
STRAU speech frames and tears down the call. The rules below are used
to determine RF LOSS:
– The EDIT XC XCL2PARMS command specifies LOSSCNT and ACQCNT parameters.
– The EDIT XC XCCPPARMS command specifies the XcCpT2 (RF Fade Timer) parameter.
– If LOSSCNT (Default=6) consecutive erased frames are detected, the XcCpT2

(Recommended Default=10seconds) GPROC timer will start running.
– If ACQCNT (Default=3) consecutive good frames are received, the XcCpT2 will be reset, and
the call will continue normally.
– If ACQCNT (Default=3) consecutive good frames are not received during the duration of the
timer, the GPROC will declare a RF loss and tear down the call.

54
CFC-27 : MSC Disconnect with SCCP
Connection Refused
• The MSC refused the MM request for an SCCP connection.
• This can happen "normally" under the following scenario: A Land to Mobile call is placed, and the
originating EMX is different from the terminating EMX. Then, if the Land originator disconnects
prior to receiving the DMX paging response, no seize transit trunk message will ever be sent to
the terminating EMX. At the terminating EMX, the transit trunk expires, and the SCCP connection
refused message is sent to the CBSC. CFC 27 will occur if T3230 (defined by EDIT CBSC-x
APARMS3) is still running at the CBSC.
• Possible Problems:
– Check that the terrestrial circuits on the switch are INS. If they are not INS, restore the trunk card.
– Be sure that the mobile has only one MID assigned to it in the switch.
– Be sure that the Location Area and/or the Registration Zone parameters are set properly. (Display
bts-#secgen)
– Be sure that all the trunk circuits are being used at the switch (i.e. not "sleeping"). Use the REPORT
TRUNK CKT command at the EMX to determine if your switch is exhibiting this problem.
– Following a CCM swap (not necessarily immediately) all call originations might result in a CFC 27.
FYI No. EMX-1999.045 explains the problem in detail as well as the work around.

55
CFC-28 : MSC Disconnect with SCCP RLSD
• The EMX initiated call disconnect with an SCCP RLSD order without
using the A+ release and clear procedures. The EMX should never
do this, but if it does, the CBSC will end the call with CFC 28.
• Can Happen if an Unsolicited Page Ack occurs:
– Mobile is paged on EMX “A”
– Mobile hears page on EMX “A”, rescans, and answers page on EMX “B”
– Check CDL for “Toy Cell” (BTS_ID = 500+). Sometimes someone near
an MTSO (with several EMXs) might pick up the RF from a co-located
“Toy Cell”, possibly leading to an Unsolicited Page Ack.

56
CFC-29 : Handoff Procedure Timeout
• This is a failed pilot beacon or DAHO hard handoff.
• CFC 29 is almost identical to CFC 8, but is triggered by a

different timer. There are two timers of interest:
– The CBSC APARMS t9ap A+ timer (8.0 seconds)

– The XC XCHOTIMERS XcHoT6 timer (6.5 seconds)
– Both timers start when the target BTS indicates it has a traffic channel ready for hard
handoff.
– If the the target BTS does not detect mobile arrival onto the Traffic channel, one of the
above timers will expire. If the A+ timer expires first, CFC 29 occurs. If the XcHoT6
timer expires first, CFC 8 occurs. Note that if the A+ timer is set longer than the XC
timer , only CFC 08 should be generated.
– KCT F-unit has A+ timer set at 6 seconds -> No CFC 08, instead we see CFC 29.

57
CFC-60 : Protocol Error between BSC and MSC
• The CBSC or MSC detected an A+ protocol error associated with the call. The EDIT
CBSC-x APARMS3 command sets the T3230 timer. This timer is typically set to13
seconds, and specifies the maximum time to complete A+ call setup procedures
between the CBSC and EMX. If this timer expires, CFC 60 is generated.
• Possible Problems
– The land party disconnects his call at the EMX side before the call is set up completely.
– The Mobile's ESN doesn't match in the subscriber file of the EMX.
– Transit trunks among EMXs have problem. For example, no transit trunks are available. (LMSSE will equal 1 for this
scenario). If however the EDIT CBSC-x APARMS3 timer T3230 is still running when the EMX gives up trying to setup
transit trunks, a CFC 27 will be generated instead.
– Verify at the EMX that there are not TERCKTs in “hung” states. During the R9.0 FOA in Fukuoka, a QCT operator
accidentally simplexed the active Call Manager, causing corrupt trunk status information to be copied from the standby
call manager. Most of the TERCKTs ended up in a hung state, leaving just a few good circuits. There were more
calls than good circuits, and any call which could not be assigned a good circuit failed as CFC-60. Duplex reset of the
Call Manager cleared the problem.
– The DMX link for remote validation could be down, or remote validation could be taking too long.
– Verify that the MM and EMX point codes in the CDF are set correctly. Note: Even with them set incorrectly the A+ link
will show in service from both the EMX and MM perspective.
– Verify that there are not multiple ESNs assigned to the same MIN. (More than 1 phone with the same number.)
– Verify that the CP TRKMAP entries on the two switches connecting the transit trunks are consistent.

58
• Release_Time : Tells us when the call ended
• SDF/XC_Release Time : The XC/SDF keeps an internal clock that

increments every 20mS. Call ended on this clock tick.
– 20mS is the time duration of a CDMA frame.

– Reported in Hexadecimal
– We can do time frame calculations using this field:
• Release_Time = 0x08FB
• Last_PSMM_Time = 0x0707
• Delta = 0x01F4 = 500 frames = 10 seconds
– This example tells us the last Pilot Strength Measurement Message
from the mobile happened 10 seconds before the end of the call.

59
• Init_MM_Rel_Event : (IMMRE) Tells us what event triggered the

Mobility Manager to Release the Call.
IMMRE Me an in g
1 Normal Land Release
3 Normal MS Release
5 Abnormal MSC Disconnect
7 Abnormal CBSC Disconnect
13 Good Pilot Beacon Handoff
I-CBSC Anchor Handoff,
Successful left source,
17 Failed to Reach Target
– Note : IMMRE=5 is usually “bad”, but for Inter-CBSC Anchor Handoff,

IMMRE=5 is “good” -- the mobile probably made it to the target BTS.
– When IMMRE=17 occurs, there should be a CFC-8 or 29 CDL

generated on the target CBSC and a CFC-30 on the source CBSC.

60
• Init_Disc_Cause_Type & Init_Disc_Cause : Tells us how a call

finished.
• Provides almost identical information as CFC! (But harder to read )
• Sometimes provides more information than the CFC code. For this
reason, developers prefer to look at Init_Disc_Cause (IDC) when
investigating problems.
– Example : R9 Data Calls. CFC-111 means “Good Packet Call”, but when
R9 was written, they didn’t have time to create more detailed CFCs.
(There are 9 circuit data CFCs in R9, but only 3 packet data CFCs!)
– So for Packet Data calls, you need to look at the IDC to tell whether the
call was really OK or not. . .
• Good Packet IDCs : 0x1100, 0x1802, 0x1910
• Bad Packet IDCs: 0x1801, 0x1809

61
Aplus (2)
Aplus L3 (3) SCAP (1)
SCCP (0?) LAPD
EMX CBSC BTS

• Init_Disc_Cause_Type : Tells us which interface link a disconnect event occurred. 1=SCAP, 2=A-plus,
3=A-plus Layer 3.
• If Init_Disc_Cause_Type = 0, this means “Not A+, Not SCAP, no Init_Disc_Cause available”. However, in
most cases, it is usually occurs when either:
– The EMX kills the SCCP connection underneath A+ ( CFC 27 and 28 )

– Hard-Handoff occurs (CFC 24 and 30)
• Init_Disc_Cause : Reason code for the disconnect. Again, very much like CFC, but is it also can be found
inside messages to and from the CBSC. By monitoring the A+ or SCAP links using test equipment or debug
commands, these Init_Disc_Cause codes can be directly observed.

62
• The Most Famous Initial Disconnect Cause (IDC) Codes:

ID C Lin k Me an in g CFCs Pe rc e n tage
0x1100 SCAP (1) Normal Mobile Release 31, 111 50.02
0x1802 SCAP (1) Data Call Normal Network Release 111 27.50
0x0010 SCAP (1) Voice Call Normal Land Release 1 16.88
Not Scap,
0x0000 Not A+ SCCP Disconnect or Hard Handoff 24,27,28,30 1.98
0x111b SCAP (1) No Tch Preamble 5 1.32
0x111a SCAP (1) RF Loss 4 0.66
0x1123 SCAP (1) Service Option ACK TimeOut 13 0.56
0x1801 SCAP (1) Data Call, Abnornal CBSC Release 111! 0.38
0x1809 SCAP (1) Data Call, Abnormal EMX Release 111! 0.24
0x1402 SCAP (1) Good Inter-CBSC Anchor Handoff 30 0.20
0x1119 SCAP (1) RF Layer 2 Failure 3 0.12
0x0060 A-plus (2) A+ Protocol Error 60 0.10
0x0009 A-plus (2) Abnormal EMX Disconnect 26 0.04
0x1122 SCAP (1) No Valid Speech Detected 9,10 0.02
0x8000 SCAP (1) BTS Device taken OOS by Human 50 0.02
0x007f A-plus (2) Hard Handoff Target Failure 29 0.02
• If you discover strange codes in your work, ask a

developer! You may have found a new problem!
63
Hard Handoff Target Info
• HHO_TGT_CellID (1-6): This tells us which target BTS

and Sector the mobile should go on a Hard Handoff
– Bits 0-3 : Sector in Hexadecimal
– Bits 15-4 : Cell Number in Hexadecimal
– Example : 0x1276 > 0x127 & 0x6
: 0x127 = Cell 295
: 0x6 = Sector 6
– Caution : This mapping is different from the format used in the XCSECT
database :
• Bits 0-2 : Sector Bits 15-3 : Cell
• Yes, its confusing. But “Off by One” discrepancies are occasionally
seen in Complex Software Systems. . .
– Set only in CFC-24 and 30 calls. Equals 0xffff otherwise.

64
Hard Handoff Target Info
• HHO_Tgt_MM_Addr : Tells us which MM the mobile should go for an Inter-CBSC Anchor
Handoff.
– Set only for CFC-30 calls, contains 0x00 otherwise.
• HHO_Tgt_Switch : Supposed to tell us the target EMX for a Hard Handoff. Doesn’t really work.
Set at 0x00 for CFC-24 and 30, 0xff otherwise
• HHO_Tgt_MCC1,2,3 : This is the MOBILE COUNTRY CODE, not the MCC card for a hard-
handoff target. Set to “0x04”,”0x04”, and “0x00” for CFC-24 and 30 Hard-Handoff calls (Japan
Mobile Country Code is 440…). Set to “0xff”,”0xff”, and “0xff” otherwise.
• HHO_Tgt_MNC1,2,3 : This is the MOBILE NETWORK CODE for a hard-handoff target. Tells us
which CT the mobile is going. For example:
– KCT = “0x01”, “0x07”, “0x0f” (MNC = 0x17f) OCT = “0x00”, “0x08”, “0x0f” (MNC = 0x08f)
– HCT = 0x3f
– Set to “0xff”, “0xff”, “0xff” for non-Hard Handoff CDLs
• HHO_Tgt_LAC : This is the Location Area Code for a hard-handoff target. Related to the
Paging/Registration zones of the target cell. Set to “0x00” for non-Hard Handoff CDLs.

65
N-Way Stats
• N_Pilot_Count (N=1..6) - These counters tell us how many times a

call was in each of the 6 possible N-way states.
• Initial 1-way after assignment is not reported -- ALL CDLs start in
one way, so we know this count is always 1.
ONE TWO THREE FOUR FIVE SIX
PILOT PILOTS PILOTS PILOTS PILOTS PILOTS
COUNT COUNT COUNT COUNT COUNT COUNT
0 3 5 4 1 0
3 3 1
MAHO MAHO MAHO MAHO MAHO
1-way
2-way 3-way 4-way 5-way 6-way
1 1 2 1
Initial 1
1-way This Call ended in MAHO 3-way. And it was in MAHO 2-way
before that. And there was a double-drop. How do we know
this? We will cover that later.

66
N-Way Stats (Continued)
• The N-Pilot Counters have an upper limit of 15:

0 15 15 0 0 0
We know this call was in 2-way and 3-way at least 15 times.

But, the true number could be anything 15 or greater.
• LOC_S_ADD_COUNT & LOC_SR_ADD_COUNT : These counters tell us

the total number of Soft (New Walsh Code, Different Channel Element) and
Softer (New Walsh Code, Same Channel Element) Handoff ADDS done on
BTSes under this (local) CBSC.
• EXT_S_ADD_COUNT & EXT_SR_ADD_COUNT : These counters tell us

the number of Soft and Softer Adds done on BTSes under a neighboring
(external) CBSC connected via Inter-CBSC links.
67
• Adding LOC_S_ADD_COUNT, LOC_SR_ADD_COUNT

EXT_S_ADD_COUNT & EXT_SR_ADD_COUNT gives us the Total Number
of Adds done during this CDL.
• Drop Counters : LOC_S_DROP_COUNT, LOC_SR_DROP_COUNT

EXT_S_DROP_COUNT & EXT_SR_DROP_COUNT. These counters give
us the total number of local soft, local softer, external soft, and external
softer drops done during a CDL.
– Adding the Drop Counters gives us the Total Number of Drops done
during the CDL
• Caution: Just like the N-way counters, the Add and Drop counter maximum
value is 15. If any of these counters are set at 15, we cannot know the true
number of adds or drops : We can only know the number was at least 15.

68
• Relation between N-way counters and Add/Drop Counters: Sums should

always be the same. Example:
0 3 5 4 1 0 Total Count: 13
LOC_S LOC_SR LOC_S LOC_SR EXT_S EXT_SR EXT_S EXT_SR
ADD ADD DROP DROP ADD ADD DROP DROP
COUNT COUNT COUNT COUNT COUNT COUNT COUNT COUNT
2 6 1 4 0 0 0 0 Total Count: 13
• Total Adds = 2 + 6 + 0 + 0 = 8, Total Drops = 1 + 4 + 0 + 0 = 5
• Release_L_WC and Release_E_WC : Tells us the

RELEASE RELEASE
number of local and external Walsh Codes (Pilots) L_WC E_WC
3 0
assigned at the end of the call. In this call, there are 3.
• All calls start in 1-way. Here, 1 + Adds - Drops = 1 + 8 - 5 = 4. But the call
ended in 3-way, not 4-way, so we KNOW there was one double drop.

69
• Last_MAHO_ActN_Bts (N=1..6) : Tells us the Active BTSes before

the Last Soft Handoff of the CDL. 0 = No BTS
• Last_PSMM_ActN_Bts (N=1..6) : Tells us the Active BTSes after

the Last Soft Handoff of the CDL. 0 = No BTS
LAST LAST LAST LAST LAST LAST LAST LAST LAST LAST LAST LAST
MAHO MAHO MAHO MAHO MAHO MAHO PSMM PSMM PSMM PSMM PSMM PSMM
ACT1 ACT2 ACT3 ACT4 ACT5 ACT6 ACT1 ACT2 ACT3 ACT4 ACT5 ACT6
BTS BTS BTS BTS BTS BTS BTS BTS BTS BTS BTS BTS
459 266 0 0 0 0 459 266 459 0 0 0
• In this example, we the final handoff transition was to

add another Walsh code at Site 459, changing from 2-
way to 3-way. (This is a Softer-Add.)

70
• Init_MAHO_CandN_Bts (N=1..3) : INIT INIT INIT

MAHO MAHO MAHO FIRST
Tells us the very first BTSes of the ACCESS CAND1 CAND2 CAND3 SHO
BTS BTS BTS BTS RESULT
CDL which the Mobile wants to Add. 459 459 0 0 1
• In this example, the mobile started on BTS 459, and asks to add
another BTS 459 Walsh Code (Sector) to his Active Set.
• First SHO Result : Tells us whether or not this handoff was executed.
– 1 = Handoff Executed
– 2 = Handoff Not Executed
– 0 = Call Disconnected before Decision could be made
• In this example, we see that the Hand-off could be made, and

therefore the very first N-way transition was from 1-way to 2-way

71
• Assembling a N-way transition history diagram is a kind of puzzle.

Even though the CDL doesn’t tell us every handoff that occurred,
there is usually enough information to assemble a reasonably
accurate picture of what happened.
• Zero Values in N-way statistics are also Percentage of All

Calls with Zero Percentage of All
very informative. Pilot Count "N" Pilot Count=N Calls using N-way
– Most calls never go into 1-way. This 1 93.1 6.9
2 56.2 43.8
means RF is good 3 58 42
– We see that the chance of RF Loss 4 86.1 13.9
5 95.6 4.4
goes up nearly 5X for calls that enter 6 98.4 1.6
1-way
– Most calls never go into 5-way or 6- Call Type RF-Loss Rate
Calls that went into
way. This means WC and CE are 1-way at least once 2.39%
being used efficiently Calls that never fell
into 1-way 0.50%

72
• Release_L_CE & Release_E_CE : Tells us how many local (same CBSC) and external (Inter
CBSC SHO) MCC Channel Elements were in use at the end of the CDL. Can be used with
Release_L_WC and Release_E_WC to calculate Soft and Softer Handoff Factors:
Total
RELEASE Calls with Weighted RELEASE Calls with Weighted Weighted • Use the Softer Handoff
L_CE Count Count E_CE Count Count Count Factor to plan the number of
0 36 0 0 918 0 0 MCC cards for a system.
1 677 677 1 77 77 754
2 239 478 2 5 10 488 • Use the Soft Handoff Factor
3 48 144 3 0 0 144
to estimate the Total Number
Total 1000 1299 1000 87 1386
of Walsh Codes Used
Average Channel Element/Call : SOFTER HANDOFF FACTOR -> 1.386
Total • System Engineering Design
RELEASE Weighted RELEASE Weighted Weighted Guidelines :
L_WC Count Count E_WC Count Count Count
0 36 0 0 918 0 0 Softer Handoff Factor = 1.5.
1 277 277 1 66 66 343 Soft Handoff Factor = 2.5
2 409 818 2 15 30 848
3 224 672 3 1 3 675 • Data on tables to the left
4 45 180 4 0 0 180 come from KCT F-Unit.
5 5 25 5 0 0 25
6 4 24 6 0 0 24
Total 1000 1996 1000 99 2095 It is operating more efficiently
Average Walsh Codes/Call : SOFT HANDOFF FACTOR -> 2.095 than designed.

73
• Num_SR_Shuffle : This is the number of times a Softer shuffle occurred during the CDL.
– EDIT CBSC HOCONSTR defines the parameter MaxBTSLegs (default=3 when 1 or 2 BTSes
are in SHO, default=2 when 3 BTSes are in SHO).
– If a Softer Add would cause MaxBTSLegs to be exceeded, the weakest pilot at that BTS
replaced with the new one.
– Happens in roughly 1.2 percent of calls. ( Source: KCT F-unit )
• Num_BTS_Shuffle : This is the number of times a BTS shuffle occurred during the CDL.
– EDIT CBSC HOCONSTR defines the parameter MaxCEPerCall (default=3). Means same
thing as “Maximum Cell Sites per Call”.
– If a Soft Add would cause MaxCEPerCall to be exceeded, the weakest BTS is replaced with
the new one.
• Num_S_Shuffle : This is the number of times a Soft shuffle occurred during the CDL.
– EDIT CBSC HOCONSTR defines the parameter MaxActSetSz (default=6).
– If a Soft or Softer Add would cause MaxActSize to be exceeded, the weakest Walsh Code is
dropped and the new one added.
– Almost never seen! ( Source: KCT F-unit )

74
• Num_SHO_Failures : This is the number of times a Soft/Softer Handoff fails in a CDL
– Climbs to High Value when there are SPAN DELAY problems. If the delta delay between the
LAST_SHO_BTS and any of the LAST_MAHO_Act_BTSes is greater than 20mS, the Soft
Add will likely fail, and an RF LOSS will likely occur.
Last SH O Fail Re ason
5120 No MCC Response (Check SPAN DELAY!)
• Last_SHO_Fail_Cause : This code tells the 5121 MS Did Not Accept Handoff
failure reason for the last SHO. Many 5120 or 5122 No MS Response (Check SPAN DELAY!)
5122 suggests a DELTA SPAN DELAY 5123 No Handoff Recognized
problem. 5125 No MM Response
5127 XC Timer Expired
• Last_SHO_Fail_Time : Tells us when the last SHO failed. If this value is always within a few
seconds of the Release_Time of an RF Loss call at a certain site, always suspect a DELTA
SPAN DELAY problem at that site.
• SPECIAL NOTE : FAILED Handoffs are not the same thing as BLOCKED Handoffs. A Failed
Handoff occurs when the System approved a Handoff, but it did not succeed. A Blocked Handoff
is a Handoff requested by the mobile, but denied by the system

75
• Last_HO_Blocked_Cause (LHOBC): This code tells us why the System decided not to allow a
Handoff requested by the mobile:
• If there are many LHOBC=7, filter them and see if SHO

their RF LOSS is high compared to other calls. If this B locke d
Cau se Re ason
is the case, you should consider raising the
2 MSC rejected handoff request
Aggr_Active_Set_Strength thresholds defined in 3 No response from MSC
EDIT CBSC HOCONSTR table. 4 Call was in HOLD condition
5 Target pilot not in neighbor list
No mutual service option
• 35% of Blocked handoffs are Blocked for LHOBC=7. 6 configuration
( Source : KCT F-unit ) 7 XC Filtering : PSMM Discarded
8 Service option not supported at target
• 26% are Blocked because no more than 3 BTSs can 9 No channel available
be added. (LHOBC=14) No local inter-CBSC subrate channel
• 20% are Blocked because no more than 3 sectors at 10 available
Inter-CBSC handoff request received
a site can be added. (LHOBC=13) 11 a no-ack from external CBSC
• 18% are Blocked because the Mobile is reporting a 12 No response from external CBSC
Pilot not in the Neighbor List. (LHOBC=5) 13 Max softer legs already connected
14 Max Channel Elements
• 0.75% are Blocked because the call is in 6-way. 15 Max Active Set
(LHOBC=15) No handoffs were blocked (or none
255 were attempted)
• 0.25% are Blocked by the EMX (LHOBC=2)

76
• Last_HO_Block_Time : Tells us when the Last Blocked Handoff occurred. If a
blocked handoff is suspected to be a cause of a dropped call, compare the block time
with the Release_Time to see if the two timepoints are near each other.
• Last_HO_Block_PN : Tells us the PN Offset of the Pilot which was denied handoff.
If there are many handoffs being blocked because LHOBC=5 (PN not in neighbor
list), be sure to check this field. This information can then be used to make BETTER
NEIGHBOR LISTS.
– The CDL does not tell us the active set at the time of Blocked Handoff.
– But, we can often accurately guess the active set if the Last_HO_Block_Time is
near either the Access_Time or Release_Time.
– If the block time is near the beginning of the CDL, look at the
Init_RF_Connect_BTS and Init_MAHO_Cand_BTSes.
– If the block time is near the end of the CDL, look at the Last_RF_Connect_BTS,
the Last_MAHO_Act_BTSes and the Last_PSMM_Act_BTSes.

77
• Last_SHO_Time : Tells us when the final Soft Handoff was Last
SHO
attempted, irrespective of whether it was successful, blocked, or Cau se Me an in g
failed. 0 No SHO
8 Soft Add
– Always check this and compare with Release_Time if SPAN 9 Soft Drop
DELAY problems are suspected. 11 Hard Handoff
12 Softer Add
13 Softer Drop
• Last_SHO_Cause & Result : These tells us the type and result of 32 Multi Pilot Add
33 Multi Pilot Drop
the final Soft Handoff attempt. MAHO Supp
34 Chan Add/Drop
Initial Site Supp
• Last_Post_SHO_Agst : VERY IMPORTANT FIELD. Tells us the 35 Chan Add
downlink signal quality (Aggregate Strength) the mobile should get Last
as the result of completing the last Soft Handoff. SHO
Re su lt Me an in g
– ALWAYS CHECK when investigating dropped calls. 0 Disconnected
– THE FORMULA : Mobile RX Ec/Io = - (Last_Post_SHO_Agst / 2) 1 OK
2 NG
– Last_Post_SHO_Agst < 0x14 ( -10dB ) : Excellent Downlink
– Last_Post_SHO_Agst ~= 0x18 ( -12dB ) : So-so Downlink
– Last_Post_SHO_Agst > 0x1e ( -15dB ) : Poor Downlink

78
• Shuffle_Type : Tells us whether the Last Soft Handoff
was a shuffle operation. (On the KCT F-unit, Shuffles Sh u ff le
Type Me an in g
occur only in 1 out of 70 Handoffs…) 0 No Shuffle Occurred
Incomplete BTS Shuffle,
Old BTS Dropped,
• Last_SHO_Num_Sect_Det & Exec : These tells us Disconnect before New
number of pilots being added (or dropped) in the final 3 BTS Added
Completed BTS Shuffle,
handoff. “Det” refers to the number of pilots detected, Old BTS Dropped, New
and “Exec” refers to the number of pilots processed. 4 BTS Added
Incomplete Softer Shuffle,
SHOULD ALWAYS BE THE SAME. New Pilot Added,
Disconnect before Old
5 Pilot Dropped
– Special Note: Sometimes there will be a non-Zero Last_Sho_Time Completed Softer Shuffle,
with Zero “Det” and “Exec” fields and no PSMM record. These are New Pilot Added, Old Pilot
HSPD calls which never did a handoff, but did add supplemental 6 Dropped
channels (Last_Sho_Cause=35)
• Last_SHO_MMAddr_BTS/Sector/MCC/Element -
These fields identify the final channel element being
added/dropped.

79
Inter-CBSC Soft Handoff Stats
• Picture Overview of Inter-CBSC Soft Handoff
Source (Anchor)
CSBC Target CSBC
IC-Span
EMX Local Leg
Remote Legs
Note: Anchor Hard

Handoff occurs
after ALL legs are
Remote.
Source (Anchor) CBSC Area Target CBSC Area

80
(Continued)
• An IC-SHO BEGINS when the first remote leg is added.
Source (Anchor)
CSBC Target CSBC
IC-Span
EMX Local Leg
Remote Leg

81
(Continued)
• An IC-SHO ENDS when the mobile makes a U-turn and last remote leg
is dropped.
Source (Anchor)
CSBC Target CSBC
Cut!
IC-Span
EMX Local Leg
Remote Leg
Cut!
Cut!

82
(Continued)
• An IC-SHO DISCONNECTS when Anchor Handoff (or Hangup) Occurs
Old Source CSBC New Source (Anchor) CSBC

Cut!
Cut!
IC-Span
EMX Old Local Leg
New Local Leg
Cut!
Cut!
Note: Anchor
Handoff is a Hard
Cut!
Handoff. Call is in
1-way immediately
afterwards, and
then can re-add
pilots.
Old Source CBSC Area New Source CBSC Area

83
(Continued)
• Because of RF Overlap, CBSC and Anchor Boundaries are Different.
CBSC Boundary
B->A Anchor Handover Boundary A->B Anchor Handover Boundary
CBSC “A” Area CBSC “B” Area

/ IC-SHO ZONE /
84
(Continued)
• CDL contains ICSHO “Begin” and “End” Records
• These are not “First” and “Last” Records, instead they work as follows:
| ICSHO Zone | | ICSHO Zone | | ICSHO Zone |

Generate ICSHO Generate ICSHO
Begin Record Begin Record Generate ICSHO
Begin Record
Generate ICSHO
End Record
Generate ICSHO
End Record
OVERWRITE ICSHO
Begin Record
OVERWRITE ICSHO CLOSE CDL
Begin Record NO END Record!
OVERWRITE ICSHO
End Record CLOSE CDL
^ ^ ^
19% of all ICSHOs are 11% of all ICSHOs are 74% of all ICSHOs are
CBSC Boundary this kind. (KCT Funit) CBSC Boundary this kind. (KCT Funit) CBSC Boundary this kind. (KCT Funit)
Case 1: Both “Begin” and “End” Case 2:The “End” Record describes Case 3: The “Begin” Record Describes
Records describe the final Inter-CBSC the second-to-last Inter-CBSC handoff. the Last Inter-CBSC Soft Handoff.
Soft Handoff The “Begin” Record describes the last. The “End” Record is blank (all zeros).

85
(Continued)
• ICS_Begin_Time & ICS_End_Time : Tells us when the
last “Begin” and “End” ICBSC Handoff events occurred. | ICSHO Zone |
– If End_Time < Begin_Time, it’s a Case 2 call --------------------->
^
CBSC Boundary
– If Begin_Time & End_Time = 0, the Call never had an Inter-
CBSC Soft Handoff | ICSHO Zone |
– If Begin_Time is set, but End_Time is 0, it’s a Case 3 call ---->

^
CBSC Boundary
– (On the KCT F-unit, only 1 in 9 calls does Inter-CBSC Soft Handoff).

86
(Continued)
• ICS_Begin_Tgt_MMAddr & ICS_End_Tgt MMAddr : Tells us the
adjacent CBSC going into Soft Handoff. | ICSHO Zone |
– For Case 1 “U-turn type” Soft Handoffs, “Begin” and “End” MM will
always be the same.
^
• ICS_Begin_Tgt_BTS & ICS_End_Tgt_BTS : Tells us the BTS CBSC Boundary
that was added when the mobile entered the ICSHO zone and the
BTS that was dropped when the mobile departed the ICSHO zone.
• ICS_Begin_Tgt_Sector & ICS_End_Tgt_Sector : Tells us the

BTS Sector that was added when the mobile entered the ICSHO
zone and the BTS Sector that was dropped when the mobile
departed the ICSHO zone.
– “Begin” and “End” BTS-Sector are sometimes the same (especially for
short Inter-CBSC handoffs) and sometimes different.

87
(Continued)
• ICS_Begin_SrcN_BTS & ICS_End_SrcN_BTS (N=1 or 2) : Tells
us the one or two BTS which are on the Source (Anchor) CBSC
when an Inter-CBSC handoff begins and ends
• ICS_Begin_SrcN_Sector & ICS_End_SrcN_Sector (N=1 or 2) :
Tells us the sectors of the above BTSes.
ICS_B EGIN
– On the KCT F-unit, 1 out of 3 Inter-CBSC soft handoffs have just one SRC_ CO UN T Pe rc e n tage
BTS-Sector on the source side. 1 47.1
2 40.9
3 9.8
4 2.1
• ICS_Begin_Src_Count & ICS_End_Src_Count : Begin count 5 0.1
tells us the N-way state of the call just before it entered the Inter- Total 100
CBSC Soft Handover state. End count tells us the N-way state on ICS_END
the source side after a “U-turn type” InterCBSC Soft Handover SRC_ CO UN T Pe rc e n tage
0 69.6
ended. 1 7.7
2 15.2
3 5.6
– End Count = ZERO means Anchor Handover occurred (without 4 1.9
any previous U-turn InterCBSC Soft Handover). Total 100

88
(Continued)
• ICS_Begin_Tgt_Count & ICS_End_Tgt_Count : Begin count ICS_B EGIN
TGT_ CO UN T Pe rc e n tage
tells us number of pilots on the Target side added when an 1 98.6
InterCBSC Soft Handover starts. End count tells us the number 2 1.4
Total 100
of target side pilots that were dropped after a “U-turn type” ICS_END
InterCBSC Soft Handover completed. TGT_ CO UN T Pe rc e n tage
0 69.6
1 30
– End Count = ZERO means Anchor Handover occurred (without 2 0.4
Total 100
any previous U-turn InterCBSC Soft Handover).
ICS_CO U N T Pe rc e n tage
1 80.8
2 10
• ICS_Count : Tells us how many times the call went into InterCBSC 3 4.1
Soft Handover Mode. Counts up to 15 and stops. 4 1.3
5 1.1
6 0.5
• ICS_CBSCs : Tell us how many different target CBSCs were used by 7 0.1
8 0.3
the call. Counts up to 15 and stops.
9 0.1
10 0.2
12 0.2
ICS_ CB SCS Pe rc e n tage 13 0.1
1 96.9 14 0.1
2 3.1 15+ 1.1
Total 100 Total 100

89
(Continued)
• FOREIGN PILOT FEATURE -This feature supports the handling of the
foreign pilots during InterCBSC Soft Handoff. A “foreign pilot” is an external
pilot which is not listed in the Source (Anchor) XCSECT database.
– Once the mobile goes into InterCBSC Soft Handoff, the CBSC makes the mobile a
neighbor list that is a mixture of the neighbor lists of the Source and Target BTS
lists.
– Foreign Pilots can occur when the target BTS neighbor lists contains cells (Pilots)
not listed in the source (anchor) BTS lists.
– Note that for this feature to work, there must be InterCBSC trunk connections
between the “Foreign Pilot” CBSC and Anchor (Source) CBSC.
– Introduced in Release 8.1

90
(Continued)
• FOREIGN PILOT FEATURE - Only rarely used!
– In KCT Funit, only 1 out of 9 of Calls go into Inter-CBSC Soft Handoff
– Of these calls, only 1 out of 80 calls generate neighbor lists with FOREIGN PILOTS
– Of these FOREIGN PILOT calls, only 1 out of 5 calls get a FOREIGN PILOT add attempt.
– In summary, that’s only 1 in 3600 calls!
– And . . . Of these attempts, we almost never see them execute to completion.
– Therefore, it is not clear how well this feature actually works. . .
• ICS_FP_Tgt_MMAddr/Bts/Sector - These three fields tell us the MM, BTS,

and Sector of the foreign pilot candidate.
• ICS_FP_SrcN_BTS/Sector (N=1 or 2) - These fields tell us the one or two

BTSes and Sectors on the Source (Anchor) side when the FOREIGN PILOT
was reported.

91
(Continued)
• ICS_FP_Time - This is the time the most recent FOREIGN PILOT was reported in the call.
– Sometimes identical to ICS_Begin_Time. This is almost always an indication that the
neighbor list of the TARGET XCSECT contains an entry not contained in the source SECTOP
neighbor list.
– Not necessarily bad. However, if you see a lot of these, you may want to consider updating
the source SECTOP list to include the pilot.
• ICS_FP_Tgt_Count - This field is supposed to tell us how many foreign pilots got added to the
InterCBSC Soft Handoff. But it is always seems to be set at zero for every call with Foreign Pilots
reported… Is this field not being pegged correctly? Or are foreign pilots never being added?
• ICS_FP_Src_Count - This field appears to be mis-named. Rather than reporting the number of N-
way source pilots at the time of a foreign pilot event, this counter appears to count both source and
target pilots. (We sometimes see “6” here, which is impossible if only source pilots are being
counted. If there are 6 source pilots and 1 or more target pilots MaxActiveSet=6 would be violated!)
• ICS_FP_Att - This field counts the number of times a foreign pilot add was attempted while a call is
in the InterCSBC Soft Handover state.

92
Last RF_Connect, MAHO, & PSMM
Sites
• These are BTS sites involved at the end of the call.
WHATS THE DIFFERENCE?
• Some pictures will help. . .

Site “A”
• Here the call starts and ends using only Site “A”
• The mobile never reported any other candidate pilots
• Last_RF_Conn_BTS1 = “A”
• Last_MAHO_Act_BTS1 = NULL
• Last_PSMM_Act_BTS1 = NULL

93
Sites
Site “A” Site “B” Site “A” Site “B”
Step 2) Mobile Sends

in a PSMM indicating
he wants to Add Site
“B”. Site “B” is added.
Signal from “B” is

Step 1) Mobile Starts stronger.
call on Site “A”
• Last_RF_Conn2_BTS = A, Last_RF_Conn1_BTS = B
Site “A” Site “B”
– (B entered the call more recently than A, so B was listed as Conn1)
• Last_MAHO_Act2_BTS = A, Last_MAHO_Act1_BTS =B
– (B was stronger than A, so B was listed as Act1)
Step 3) Mobile Sends
in a PSMM indicating
he wants to Drop Site • Last_PSMM_Act2_BTS = NULL, Last_PSMM_Act1_BTS = B
“A”. Site “A” is – (As a result of the final PSMM, A was dropped and only B remained.)
dropped. Call Ends.
• Last_SHO_BTS = A
– (Last SHO event was to drop A)

94
Sites [ KEY POINTS]
• Last_RF_Connect_BTSes
– Arranged in Time
– Last_RF_Conn1_BTS is always active at the end of the call.
– Conn2 and Conn3 BTSes may or may not be active at the end of the call. This depends upon the N-
way state when the call ended.
• Last_MAHO_Act_BTSes
– Arranged by Signal Strength.
– Lists the sites that were in the Active Set before the final PSMM was processed.
– If the call was in 1-way before the final PSMM was processed, Last_MAHO_Act_BTSes = All zeros.
This is because 1-way is not considered to be a “Handoff” state.
• Last_PSMM_Act_BTSes
– Arranged by Signal Strength.
– Lists the sites that were in the Active Set after the final PSMM was processed. In other words, these
sites were the true final sites of the call (if there actually was a PSMM sent).
– If no PSMM ever occurred during the call, Last_PSMM_Act_BTSes = All zeros.
• Last_SHO_BTS
– Lists the site that was either added or dropped as a result of the final PSMM. Note that if the
Last_SHO_Cause = 8 or 12 (Add), Last_SHO_BTS will always equal Last_RF_Conn1_BTS.

95
Last RF Connection Stats
• Last_RF_ConnN_BTS/Sector/MCC/Element (N=1..3) - These fields identify the Channel

Elements of the Final Three BTSes of the call.
– One Channel Element can support up to six simultaneous sectors. These Sectors are listed
in Sector, SSector (Softer Sector), Sector3, Sector4, Sector5, and Sector6.
– Sector=0 means the sector was not assigned.
– Because CBSC HOCONSTR MaxBTSLegs is set at 3 ( and 2 for when three BTSs are in a
call ), we will never see Sector4, Sector5, or Sector6 being assigned.
• MccN_Release_Time (N=1..3) - Tells us when each of the Last_RF_ConnN BTSes were

released from the call.
– Measurement Units are Speech Frames ( 1 frame = 20 milliseconds )

– Example: XC_Release_Time = 0x0900, Mcc3_Release_Time = 0x0700
• Delta = 0x0900 - 0x0700 = 0x0200 = 512 frames = 10.24 seconds.
• This means Last_RF_Conn3_BTS was released 10.24 seconds before the call ended.
– BTSes still connected when the call ends are typically cleared 9~10 frames (200
milliseconds) after the XC_Release_Time.

96
Last RF Connection Stats (Continued)
• HIGA (Hi Gain) Stats - These stats give us information on the

forward (Base-to-Mobile) RF Link.
• Quick Review of Forward Power Control:
– Every 20 frames (TargetFER=FERB) (400 milliseconds), the base station

decreases the forward digital gain by 1 point.
– If a Mobile gets PwrRepThresh (Default=2) Bad Frames within a run of
PwrRepFrames (Default=9 -> 113 frames), he will request more forward power
by issuing a PMRM message.
– The base station will then increase digital gain by 20 points (TargetFER=FERB)
– The base station will always try to give the mobile more gain when requested.
But if the digital gain will not be raised above MaxGainNWay (Default=110).
– If CdlThresh (Default=1) power increase requests in a row are received while
the Traffic Channel is at Maximum Gain, a HIGA (High Gain) event occurs.

97
• Last_RF_HigaN_Intervals (N=1..3) - Tells us how many times HIGA

events occurred for this call. If this value is High, the following problems are
possible:
– Mobile with bad receiver - Search CDLs for the mobile’s ESN and see
whether there are many HIGAs on different cells.
– Bad TX coverage - Search CDLs for the suspect BTS/Sector and see
whether there are consistently many HIGAs on that BTS/Sector.
– Bad BBX - Search for CDLs for the suspect BTS/Sector/Channel.
• Last_RF_HigaN_End/Begin (N=1..3) - These timepoints tell us when, and

for how long the most recent HIGA event lasted.
– Example:
• XC_Release_Time = 0x1000
• Last_RF_Higa1_End = 0x0e00 ( 10.24 seconds before call ended)
• Last_RF_Higa1_Begin = 0x0c00 ( 15.36 seconds before call ended)

98
• SETP (Set Point) Stats - These stats give us information on the

Reverse (Mobile-to-Base) RF Link.
• Quick Review of Reverse Power Control:
– 800 times every second, the Base Station sends the mobile a Power Control Bit
(PCB) telling him to either step-up or step-down the Mobile TX power.
– When reverse errors are high, the base station will keep sending step-up bits
until the errors are reduced.
– However, the base station will stop increasing Mobile TX power once the Base
RX level from the mobile hits RPCMaxEbNo (Default=11dB Eb/No). This is to
prevent mobiles from using excessive reverse link capacity.
– If high errors persist while BaseRX = RPCMaxEbNO for more than CdlThresh
(Default=128 frames=2.56 seconds), a SETP (Set Point) event occurs.

99
• Last_RF_SetpN_Intervals (N=1..3) - Tells us how many times SETP

events occurred for this call. If this value is High, the following problems are
possible:
– Mobile with noisy transmitter - Search CDLs for the mobile’s ESN and see
whether there are many SETPs on different cells.
– Bad RX coverage - Search for CDLs using the suspect BTS/Sector and see
whether there are consistently many SETPs on that BTS/Sector. Also check for
“Bandits” (BBX Reverse Noise Very High Alarms)
– Bad BBX -- Search for CDLs using the suspect BTS/Sector/Carrier .
• Last_RF_SetpN_End/Begin (N=1..3) - These timepoints tell us when, and

for how long the most recent SETP event lasted.
– Example:
• XC_Release_Time = 0x1000
• Last_RF_Setp1_End = 0x0e00 ( 10.24 seconds before call ended)
• Last_RF_Setp1_Begin = 0x0c00 ( 15.36 seconds before call ended)

100
NEW!
Last RF Connection Stats (Cnt) R16.1
• LAST_RF_CONN(x)_FWD_CNT where x is 1, 2 or 3
– The forward frame loss count of the “x” most recently dropped MCCce
in the call.
• LAST_RF_CONN(x)_BTS_SIGTYPE where x is 1, 2 or 3
– The BTS signalling type of the BTS associated with the “x” most
recently dropped MCCce in a call. The options are:
• 1 – the call is assigned to a Packet BTS.
• 0 – the call is assigned to a Circuit BTS.
• Otherwise, set to a default value of 0.

101
Initial MAHO, First MAHO Stats
• What’s the Difference between the “First” and “Initial” MAHO Sites?
– Answer : Most of the time, NOTHING!
– First MAHO is associated with the first Mobile PSMM received.
– Initial MAHO is associated with the first Mobile PSMM processed.
– First_MAHO_Time = Init_MAHO_Time
* If no MAHO ever occurred, First_MAHO_Cause is
– First_MAHO_Cause* = Init_MAHO_Cause* set to 255 (Meaning: No MAHO) & Init_MAHO_Cause
is set to 0 (Meaning: No MAHO). This is the only
– First_MAHO_Act_Str = Init_MAHO_Act_Str difference between “First” and “Initial” MAHO stats
– First_MAHO_Cand_Count = Init_MAHO_Cand_Count
– First_MAHO_Cand1_Str = Init_MAHO_Cand1_Str
• But… If the call is not set up completely (Check LMMSE to confirm), the
First MAHO (PSMM) is held in queue but not processed. In this case, the
Initial MAHO information will be NULL.

102
• First_MAHO_Time - Tells us when the first Handoff request (PSMM) was

received from the mobile.
– Measured in XC frame time.
• Example : XC_Release_Time = 0xf000
• First_MAHO_Time = 0xa000
• Delta = 0x5000 = 20480 frames
• = 490.6 seconds before call ended
• First_MAHO_Cause - Tells us the reason the mobile is asking for a

Handoff. (First MAHO should never be a Tdrop!)
First
MAH O
Cau se Me an in g
0 or 255 No SHO
14 Tdrop
17 Tadd
18 Tcomp

103
• First_MAHO_Act_Strength - Tells us the Ec/Io that was received by the

mobile at the time he requested his very first Handoff.
– Always refers to the signal from the Init_RF_Connect
BTS/Sector/Channel
– Formula : Ec/Io = - [ First_MAHO_Act_Strength / 2 ]
• First_MAHO_Cand_Count - Tells us how many new pilots the mobile wants

added in his first handoff.
• First_MAHO_CandN_PN (N=1..3) - These tell us the PN Offsets of the

candidates the mobile wishes to add.
• First_MAHO_CandN_Str (N=1..3) - These tell us the mobile RX Ec/Io for

each of the above candidates.
– Formula : Ec/Io = - [ First_MAHO_CandN_Str / 2 ] dB
104
• Init_MAHO_CandN_MMAddr/BTS/Sector (N=1..3) - These tell us which

Sites and Sectors (and their parent MMs) the mobile wants to add in his very
first Handoff.
– The CBSC is able to determine these sites from just the PNs reported in
the PSMM using the SECTOP database
• Init_MAHO_CandN_Str (N=1..3) - Same as First_MAHO_CandN_Str. Tells

us the Ec/Io reported by the mobile for each of the candidate sites he wants
to add.
– Formula : Ec/Io = - [ First_MAHO_CandN_Str / 2 ] dB
• Init_MAHO_CandN_Phase (N=1..3) - VERY POWERFUL STAT! Can be

used to locate the mobile! See next slide!

105
• Init_MAHO_CandN_Phase (N=1..3) - The Distance Indicator
– Multiply the PN of the candidate by 0x0040

• For example, Candidate PN = 8, 8 times 0x0040 = 0x0x200
– Subtract this product from the MAHO PHASE
• Example, MAHO_Phase = 0x0202, Difference = 0x0002
– Multiply this difference by 244 meters
• Example, 0x0002 times 244 = 488 meters
• THIS TELLS US THE MOBILE IS 488 meters CLOSER to the ACTIVE site
than the CANDIDATE site. For example:
Active Site “A” Candidate Site “B”

1.0 Km 1.488 Km

106
• OK, OK. “What good is knowing just the difference?” you say. . .
– After all, the difference only gives us a hyperbola curve where the Mobile
might be located. . .
Mobile could be ANYWHERE on this curve!

These are ALL points whose DELTA difference
is 488 meters!

1.0 Km 1.488 Km
1.476 Km 1.992 Km

107
S6
• Luckily, we know the distance from the Access BTS! S6 S2
S5 S3
S4
Distance from Access Site =

[ Access_PN_Offset - 14 ] * 244 meters =
We know the Mobile should not be at this
1.476 kilometers
point. Otherwise, Access Sector should be
“2”, and Candidate Sector should be “6”.
1.992 Km
1.476 Km
Delta 1.476 Km
0.488 Km Radius Line
Hyperbola
Active Site “A” Line Candidate Site “B”
1.0 Km 1.488 Km
Access_PN_Offset Candidate PN
= 20 Chips = 0x0200
1.476 Km 1.992 Km
Access Sector Candidate Phase
=3 =0x202
Mobile is Here! Candidate Sector
=5

108
• In most cases, the Access Time & Init_MAHO_Time are within seconds of one
another. But, if not, and if the mobile has moved, location error is introduced:
HyperBola Line at
Init_Maho Time
( In CDL )
Radius Line at Radius Line at

Access Time Init_MAHO Time
( In CDL ) ( Not In CDL )
Calculated Mobile
Position. (Its Wrong!)
True Mobile
Location at
True Mobile
Access Time
Location at
Init_Maho Time

109
• If there are two (or more) Candidates in the Init_MAHO, we can triangulate and
get a very accurate location! We don’t need to worry about the mobile moving,
since the PSMM is a snapshot of multiple sites at a single timepoint.
Active Site “A” Candidate PN * 0x40 = 0x1900
Candidate Site “C” Candidate Phase =0x18ff
1.0 Km Delta = -1 -> Mobile is 244 meters

1.244 Km closer to site “C” than “B”
1.244 Km Candidate PN * 0x40 = 0x0200
Candidate Site “B” Candidate Phase =0x0200
Delta = 0 -> Mobile is same distance

from sites “A” and “B”

110
• If a MAHO Candidate is a Softer Add ( Different sector ) at the same site, the
Candidate Phase Information is not very helpful…
– Why?
– We calculate [(Phase - PN x 0x40) * 244] meters and get 0 meters.
– We learn that the difference in mobile distance between the two sectors is
zero meters.
– But we already knew that ! The sectors are at the same site!

111
• Some Key Points about using MAHO_PHASE to locate mobiles
– Location can be done only when at least one MAHO candidate is a different site
– One site is good enough if the MAHO occurs quickly after call setup. In most cases this is true.
– If a mobile moves a significant distance between the Access Time and Initial MAHO time,
location error is introduced if there is just one different site.
– If there are two different MAHO sites, location error cause by motion is eliminated.
• Some “Real World” Data taken from KCT‘s F-unit Site 20:
– 35% of all calls do an Init_MAHO including a different site. We can do fairly good mobile
locations on these calls.
– 7% of all calls do an Init_MAHO including more than one different candidate sites. We can do
great mobile locations on these calls.

112
• Being able to locate 35% percent of calls is probably not good enough for
police work.
• BUT… 35% (or even just 7%) is FANTASTIC for System Optimization Work!
– Mobile Ec/Io plots can be made from CDLs! NO DRIVE TEST. And
even better, we get information on where the REAL SUBSCRIBERS GO,
not just our drive testers!
– Base site RX Eb/No plots can be made from CDLs! Cant even make
these today with Drive Testing unless SMAP is used!
– Using LAST_PSMM Phase & MeasCount Stats, Mobile Forward FER

plots can be made with CDLs!

113
Last MAHO Stats
• Last_MAHO Stats refer to the Last PSMM Processed

– Not every PSMM is processed (resulting in SHO) due to
XC filtering or other SHO_Blocked reasons.
• Last_MAHO_Time - Tells when the final MAHO was Last

performed MAH O
Cau se Me an in g
– Measured in XC Time (20 millisecond frames) 0 or 255 No SHO
– Compare with XC_Release_Time to learn when the 14 Tdrop
17 Tadd
MAHO occurred relative to the end of the call. 18 Tcomp
• Last_MAHO_Cause - Tells us the reason the last MAHO
occurred
• Last_MAHO_Cand_Count - Tells us how many pilots are
being added (or dropped).

114
Last MAHO Stats
• Last_MAHO_ActN_MMAddr/BTS/Sector (N=1..6) - These tell us which

Sectors were in the Active Set before the final processed PSMM.
• Last_MAHO_CandN_MMAddr/BTS/Sector (N=1..6) - These tells which

Sectors were in the Candidate Set before the final processed PSMM.
• Last_MAHO_ActN_Str/Phase (N=1..6) - These tell us the Strength and

Phases of the Active Set Pilots before the final processed PSMM.
• Last_MAHO_CandN_Str/Phase (N=1..3) - These tell us the Strength and

Phases of the Candidate Set Pilots before the final processed PSMM.
– Note: Active & Candidate Phase measurements are relative to the Active
Site reporting 0x0000 Phase.
– As always, Active & Candidate Strengths are Ec/Io = - [Str/2] dB

115
Last PSMM Stats
• The Last_PSMM fields contain either (depending on what happened last):
– Case “A” : The expected state of the active & candidate sites after the
last processed PSMM. (This is a “fake” PSMM)
Or
– Case “B” : The contents of the last (unprocessed) PSMM received from
the mobile.
• Last_PSMM_Time - Tells us when the last PSMM was received.
– If Last_PSMM_Time = Last_MAHO_Time, we know no new PSMMs were

received after the last processed MAHO, and that the Last_PSMM fields contain
the CBSC‘s expected active and candidate sites (Case “A”)
– Otherwise, Last_PSMM CDL fields reflect the last PSMM received (Case “B”).

116
Last PSMM Stats
• Last_PSMM_Cause - Always ZERO because only PSMMs which are NOT

processed (Case “B”) or “fake PSMMs” (Case “A”) are written into these
fields.
– If the CBSC chooses to process the last PSMM, that PSMM‘s data gets
written into the Last_MAHO CDL fields instead, and the expected
outcome, the “fake PSMM”, gets written into the Last_PSMM CDL
fields.
• Last_PSMM_Cand_Count - Tells us how many sites are in the Mobile‘s

Candidate set at the end of the call.

117
Last PSMM Stats
• Last_PSMM_ActN_MMAddr/BTS/Sector (N=1..6) - These tell us which

Sectors were in the Active Set after the final processed PSMM.
• Last_PSMM_CandN_MMAddr/BTS/Sector (N=1..6) - These tells which

Sectors were in the Candidate Set after the final processed PSMM.
• Last_PSMM_ActN_Str/Phase (N=1..6) - These tell us the Strength and

Phases of the Active Set Pilots after the final processed PSMM.
• Last_PSMM_CandN_Str/Phase (N=1..3) - These tell us the Strength and

Phases of the Candidate Set Pilots after the final processed PSMM.
– Note: Active & Candidate Phase measurements are relative to the Active
Site reporting 0x0000 Phase.
– As always, Active & Candidate Strengths are Ec/Io = - [Str/2] dB

118
NEW!
Last PSMM Stats R16.1
• Given the conditions below, this field will contain information that is different
from the conventional.
– FR4078: Access Handoff is enabled and mobile also compliant.
– F9 in the GenCpFlags is set to 1 or ON
• The result of this is that the last Radio Environment Report (RER) received
by the mobile will be stored in the Last PSMM field.
• The RER contains information of the Radio Environment when attempting
an access to the system. This report is used by the MM to put together an
Access Handoff List.
• The MM then selects the best candidate and assigns the mobile a TCH from
it.

119
Forward/Reverse Quality Stats
• When RF traffic on either the CDMA uplink or downlink approaches capacity,

Audio Quality degrades due to high speech frame erasures.
• The CDLs contain several fields useful in detecting RF capacity bottlenecks

and their related Audio Quality problems. We can see these stats degrade
during busy hour.
• Motorola Network Performance Engineering and KDDI use these statistics to

identify and predict RF capacity bottlenecks. The RFLD package is based
upon these stats.
• These stats can also be used to understand RF capacity for each area. The
NWPE team has used these stats to monitor RF performance, RF capacity,
also to plan for RF growth for the future.

120
• Fwd_Quality - Tells us how many FORWARD QUALITY events occurred

during the call.
– A FORWARD QUALITY event occurs whenever there are 3 or more Power Increase requests
from a Mobile during a 10* second period. The subscriber may notice an “Audio Hole” when a
FORWARD QUALITY event occurs.
– Simply put, FORWARD QUALITY estimates the number of times during a call that downlink
Audio Quality was poor.
– FAQEM = Forward Audio Quality Events per Minute. Calculate by dividing Fwd_Quality by
the Call Hold Time. We can estimate the total call FER (Frame Erasure Rate) from FAQEM.
– FAQEM and system traffic are often correlated. Systems Engineering can trend FAQEM
against traffic (Erlangs) to predict when it will be necessary to add new carriers to a CDMA
system.
* FORWARD QUALITY definition assumes XcCpT5 is set at the Default value of 10,000 (10 seconds) and FwdQualityThres set at 3.

121
• Fwd_Quality – This parameter can be used to estimate Ave. FER for entire
duration of a call with a few changed in system parameter settings.
– Set XcCpT5 = 40 msec, PwdRepDelay = 0, and PwdQualityThres = 1
– If we change “PwrRepDelay = 4” (Default) to zero, which means mobiles do not have to wait
between issuing PMRM, Power Measurement Report Message”. And a mobile can issue
“PMRM” whenever it gets 2 bad frame where 2 frame = 40 msec ( matchs with XcCpT2
setting). Taking those two parameters change in the count , the “Fwd_Quality” value at the
end of call becomes the exact number of PMRM message sent by a mobile during the entire
call. Now, it is possible to estimate Ave. FER for each call. Please refer to the following
example.
Example 1:
Conditions: Duration of a call is 10 seconds and Fwd_Quality value is 12.
FER = (Fwd_Quality * 2 bad Frames) / (Total number of Frames)
= (12 *2) / (500) = 0.048
= 4.8 %

122
• Last_Fwd_Incr - Tells when the last FORWARD QUALITY event occurred.
– Measured in XC time (number of speech frames)

– Compare with XC_Release_Time to determine when the last FORWARD
QUALITY event occurred.
– Example: XC_Release_Time = 0xf000, Last_Fwd_Incr = 0xe000
– Delta = 0x1000 = 4096 frames = 81.92 seconds before call ended.
• Meas_Count - VERY Useful! Tells us the number of Power Increase requests during
the final 0..10 seconds of the call. We can calculate FINAL Forward FER (Frame
Erasure Rate) by this formula :
– Final Forward FER = (Number of Bad Frames/ Total Frames) *100

= (Meas_Count X 2) X 100/ [(Release_Time – Access_Time) mod 10 X (1/0.02)]
= [(Meas_Count / (Call Hold Time* mod 10)) X 4]
– Excellent Indicator of Downlink Audio Quality and Capacity.
* Call Hold Time = Release_Time – Access_Time (in unit of seconds).

123
• Enabling “Mea_Count” Parameter

– After installing R16.0, XcCpT5 default value was set to 50 milliseconds and
PwdDelayReport as 4 frame delay, which caused NO Values in “Mea_Count” peg
in CDL. The reason for this problem is due to the window for meas_count peg
becomes too short to report any PMRM messages. One PMRM required to see
two bad frames which equals to 40 milliseconds in time. Having less than the 40
milliseconds, for the mea_count time, will not report any values except for “0”.
– At same time a mobile waits PwdDelayReport Time (4 frames) after it sends a
PMRM message before it sends another PMRM, which make even more difficult
to have any PMRM in Mea_Count parameter.
Last PMRM
Release time
Access time WINDOW for Mes_Count
= 0 to XcCpT5 (50 msecc)
PwdRepDelay = 4 Frames

124
• Enabling “Mea_Count” Parameter (Continued)

– In order to obtain some values (rather than 0) for Mea_Count, following
two parameters should be changed as an example in below.
Parameter Setting CLI Command

PwdReportDelay 0 or 1 EDIT BTS-# MSFPC
XcCpT5 10 seconds EDIT XC-# XCHOPARMS

125
• Last_Rvs_Incr - Tells us when the last REVERSE QUALITY event occurred.
– Measured in XC time (number of speech frames)

– Compare with XC_Release_Time to determine when the last FORWARD
QUALITY event occurred.
– If the difference (DELTA) is less than 128 frames, we know that there was Bad
Audio at the end of the call
• Rvs_Erase_Count - Tells us the number of reverse erasures during the final 0..127
frames of the call.
– If DELTA (calculated above) is less than 128, we can calculate Final Reverse FER:
Final Reverse FER = 100 * Rvs_Erase_Count / DELTA (Percent)
– If this value is greater than 20%, we declare the call a “Call that ended with Poor Uplink
Audio”. Watch this rate on CFC-1 calls if you extend the RF Fade timer (XcCpT2).

126
• RF_Fade_Count - Tells us how many times the Reverse RF (Uplink) went “dead”
during the call.
– The EDIT XC XCL2PARMS command specifies LOSSCNT and ACQCNT parameters.
– The EDIT XC XCCPPARMS command specifies the XcCpT2 (RF Fade Timer) parameter.
– If LOSSCNT (Default=6) consecutive erased frames are detected, the XcCpT2

(Recommended Default=10seconds) GPROC timer will start running and RF_Fade_Count
CDL value will be raised.
– If ACQCNT (Default=3) consecutive good frames are received, the XcCpT2 will be reset, and
the call will continue normally.
– If ACQCNT (Default=3) consecutive good frames are not received during the duration of the
timer, the GPROC will declare a RF loss and tear down the call.

127
Carrier Load Management Stats
• Carr_Load_BTS/SECTOR/CHANNEL - Tells us the bts-sec-carrier being reported at

the end of each call. The cell information is similar to Last_RF_Conn_BTS/SECTOR
field.
• Carr_Load_Time – The end of the 30 second period during which all measurements
in this et were taken. More than one call may report the same set of measurements.
• LPA_Fixed_Protect_Active – When the value indicates “1”, the LPA protection with
fixed limit feature has activated power limiting at the BTS when the call ended, and “0”
means BTS was not in power limiting mode.
• Exciter_Power – Total carrier power in 100ths of a dBm as measured at the output of

the CDMA transceiver exciter.
• FWD_EC_IOR – The pilot channel power expressed as a fraction of total carrier

power.

128
• The figure to the right is to help

understanding the Ec/Ior parameter.
• Ec - Average energy per PN chip for
the Pilot Channel, Synch Channel,
Paging Channel, power control
subchannel, or Forward Traffic
Channel.
•Ior -The total transmit power spectral
density of the Forward CDMA
Channel at the base station antenna
connector.
• Îor - The received power spectral
density of the Forward CDMA
Channel as measured at the mobile
station antenna connector.

129
• REV_RISE – Reverse link noise rise in 100 ths of a dB as measured by the CDMA
transceiver.
• FWD/REV_High_FER – Percent of traffic channel elements with forward/reverse

frame erasure rate exceeding the forward/reverse bad FER threshold (Threshold is
configured per service option). “DISPLAY CARRIER-bts#-Sect#-carr#
CARRLOADMGT” – CLI command to display actual settings for the threshold.
• FWD/REV_Load_Limit_Orig
FWD/REV_Load_Limit_Term
– The forward/reverse link load limits from the configuration database (in 100ths of a dB)
with limit adjustment (if any) applied. There is one limit for blocking originations and a
different one for blocking terminations.

130
Vocoder Bypass Stats
• Vocoder_Bypass - Bitmap that Bit 3 Bit 2 Bit 1 Bit 0

gives us a “Mini-History” of Vocoder Bits 4-7 Unused Bypass
Active
Bypass
Enabled
Bypass
Success
Bypass
Failed
ALL ZERO
bypass activity for the call.
• Bit 0: Bypass-Failed - Set if at least once during the call, the XCDR attempted to enter
bypass mode, but timed out waiting to acquire bypass sync.
• Bit 1: Bypass Success - Set if bypass mode was active at least once during the call.
• Bit 2: Bypass Enabled - Set if bypass mode was enabled at the end of the call (may or
may not be active).
• Bit 3: Bypass Active - Set if bypass mode was active at the end of the call.
• Range: 0x0 - 0xf

131
Packet Data Stats
• Pkt_Data_Type - Tells us what kind of Packet Data Call was placed
– 0x00 - Non-Packet call. OR Packet-Call with Mobile release before Packet Session
fully established.
– 0x01 - new packet-oriented data call.
– 0x02 - mobile initiated reactivation of a packet-oriented data call.
– 0x03 - network initiated reactivation of a packet-oriented data call.
– 0x04 - 0x0F - Reserved
• IWU_ID - Tells us the ID of the Packet Data IWU serving the Packet Call. If the call is
not a Packet Call, this field is set to 0. If the call is a Packet call, but the Mobile
disconnected early (CFC-111 with Pkt_Data_Type=0x00), this field may also
sometimes contain 0.

132
1X Packet Data Stats
• PSI_SDU_ID - Tell us the identify of the PSI_SDU associated to 1X call by the XC sub-
system. The value 0xFFFF is the default value since it is not assigned to any PSI_SDU_ID.
• 00 – 07: 8bits – PSI SDU CARD ID
• 08 – 11: 4bits – DSP ID
• 12 – 15: 4bits – logical channel number
• PDSN/PCF/PCF_RA IP ADDRESS - IP Address of each device for a packet-oriented call (

Display in IP address format).
• BYTES_SENT_FWD/RVRS_DIR – Total number of bytes transmitted in the forward/reverse

direction in 1K increments per call (Display in decimal).
• BURST_TIME_FWD/RVRS_CH – Total transmitted burst time on the forward/reverse channel in

seconds rounded up to nearest second (Display in decimal).
• DATA_BURST_ATTEMPTS – Total number of Data Burst attempts (for on-demand

supplemental channel assignment).

133
NEW!
SDU-SDF Resources R16.1
• SDU_ID (Decimal Display)

The ID of the SDU shelf that contains the SDU–SDF resources assigned to the call.
• SDF_ID (Decimal Display)
The ID of the SDU–SDF resource in the SDU shelf assigned to the call.
SDF_SIG_IPADDR (IP Address Format)
The signalling IP address of the SDU Selection and Distribution
resource assigned to the call..
• SDF_SIG_PORT (Decimal)
The signalling IP port of the SDU Selection and Distribution resource assigned to the call.
• SDF_BEARER_IPADDR (IP Address Format)
The bearer IP address of the SDU Selection and Distribution resource assigned to the call.
• SDF_BEARER_PORT (Decimal)
The bearer IP port of the SDU Selection and Distribution resource assigned to the call.
• SDU_RA_IPADDR (IP Address Format)
The IP address of the SDU resource allocator used to assign SDF resources to the call.

134
NEW!
Lost BTS Leg Information R16.1
• CBSC_LOST_LEG
– External CBSC ID associated with the MM under which the
MCCce was operational when lost.
• BTS_LOST_LEG
The BTS_ID associated with the MM under which the MCCce
was operational when lost.
• MCC_LOST_LEG
The MCC_ID associated with the MM under which the MCCce
was operational when lost.
• CE_LOST_LEG
The Channel Element number of the lost MCCce.
NOTE: need to quantify “LOST”

135
Appendix
• Tools to analyze CDL log files

– CDL Browser Tools
• Download the Package
http://cdma.gtss.mot.com/~saxon/brw.html
• Manual
http://cdma.gtss.mot.com/~saxon/brw.pdf
– Windows
• PIPE BRO
http://www.tcsg.japan.mot.com/atrndc/members/jonathan/pipebro.htm
• CDL2CSV
http://www.tcsg.japan.mot.com/cseg/members/narukami/index.htm
– Unix
• XCAT
http://www.rochellepark.pamd.cig.mot.com/software/cat/

136

917016c6

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

917016c6

Uploaded by

Copyright:

Available Formats

Fundamentals of CDL

• Created V0.0 – V3.0 by J. Hutchison

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• Why Do CDL Analysis?

• Information Available in CDLs

• While learning CDL information, we will also study

• “Hands-On” troubleshooting Exercises using CDLs.

Motorola Confidential Proprietary Fundamentals of CDL Analysis

Motorola Confidential Proprietary Fundamentals of CDL Analysis

PM Statistics DriveTest/DM/Compass Logs

Extremely Detailed Tables Per-call Records of everything

Motorola Confidential Proprietary Fundamentals of CDL Analysis

SMAP CallProc1 Debug

Per-Call Records of Records of nearly every MM

• Forward Transmit Power • SCAP Messages to and

Motorola Confidential Proprietary Fundamentals of CDL Analysis

Event Logs & Alarm Manager Call Detail Records (CDLs)

Hourly records of all bad and Per-call records containing

Motorola Confidential Proprietary Fundamentals of CDL Analysis

Analysis Technique Pros Cons

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• CDL Analysis, while more complex than PM Stats, can

• CDL Analysis, while not as detailed as per-Call Drive

• For these reasons, CDL Analysis has been used as the

Motorola Confidential Proprietary Fundamentals of CDL Analysis

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• CBSC General Info • Handoff Fail Stats

Motorola Confidential Proprietary Fundamentals of CDL Analysis

Motorola Confidential Proprietary Fundamentals of CDL Analysis

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• CBSC - Identifies the CBSC controlling the call (From

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• CPP - Identifies the XC (Transcoder) Call Processing

• CIC Span - Tells which E1 span is connecting the

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• CIC Slot - Tells which TimeSlot on the CIC span is being

• XCDR - Tells which Transcoder is handling the call. If a

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• MID - Mobile ID. Similar to a Mobile Phone Number

• ESN - Electronic Serial Number. An eight digit

Motorola Confidential Proprietary Fundamentals of CDL Analysis

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• SCM - Station Class Mark - Tells the Infrastructure the

– 0x62006200 = Regular Single-Mode JCDMA Phone

– 0x6200f300 & 0x6200e200 = Old Dual-Mode (Analog+CDMA) Phones. No

– 0x6200ea00 - Motorola JCAMPS computer-controlled Drive Test phone.

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• Dialed Digits -- Tells us the Number Dialed by the

– Set for Mobile Originations ( Entry Type = 0 ) only

– Value of “0” indicates either:

– May include the ‘*’ and ‘#’ signs.

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• Init RF Connect Sector -- Tells us the first Sector assigned in this

• Init RF Connect MCC -- Tells us the first MCC panel assigned in

• Init RF Connect Element -- Tells us the first MCC Channel Element

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• Init RF Connect ELEMENT TYPE -- Tells us the first channel

• Init RF Connect IP ADDRESS – The IP address of MCC Channel

• Init RF Connect PSICE IP ADDRESS -- IP Address of the PSI-CE

• Init RF Connect PSICE PORT – The port of the PSI-CE associated

Motorola Confidential Proprietary Fundamentals of CDL Analysis

• Init RF Connect Channel -- Tells us the first RF carrier assigned in

Motorola Confidential Proprietary Fundamentals of CDL Analysis