CDL Analysis v6 - Eefocusdata.eefocus.com/myspace/15/79650/bbs/2009-06-03/1243990143_917… · Fundamentals of CDL Analysis Motorola Japan V6.0. ... Motorola Confidential Proprietary

Motorola Confidential Proprietary Fundamentals of CDL Analysis1

Fundamentals of CDL Analysis

Motorola Japan

V6.0


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


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.


Why Do CDL Analysis?


System Performance Analysis Techniques

PM Statistics

Extremely Detailed Tables Counting Events over fixed time periods:

• Originations• Terminations• Registrations• Failures• Handoffs• Call Final Classes• and more...

DriveTest/DM/Compass Logs

Per-call Records of everything that happens at the mobile:

• Infrastructure Orders sent to Mobiles

• Mobile Responses• Downlink RF Conditions• Uplink RF Transmit

Power• Control Channel

Messages• and more...


System Performance Analysis Techniques (continued)

SMAP

Per-Call Records of Infrastructure events:

• Forward Transmit Power• Reverse FER• A+ Message Sequences• SCAP Message

Sequences• Paging/Sync Messages• and more...

CallProc1 Debug

Records of nearly every MM transaction

• SCAP Messages to and from Base Stations

• A+ Messages to and from the EMX

• Messages to and from the Transcoders


System Performance Analysis Techniques (continued)

Event Logs & Alarm Manager

Hourly records of all bad and unusual events seen by the OMC-R

• Major, Minor, and Critical Alarm Sets

• Major & Critical Alarm Clears

• Incomplete/Failed Transactions between Network Elements

Call Detail Records (CDLs)

Per-call records containing detailed information regarding:

• Setup Events• TearDown Events• Type of Call• Sites and CBSCs• Handoff Stats• RF Performance Stats• and more...


Analysis Techniques : Pros & Cons

Analysis Technique Pros Cons

PM Statistics

Excellent System-wide PerformanceSummaries. Can estimate device utilizationsand do Capacity Planning. No impact to thesystem.

PM stats can tell you what is wrong, butoften do not tell you *WHY*

Drive Test / DM / Compass Logs

Absolutely the Best Way to Debug RFCoverage Problems in Specific Area. Noimpact to the system.

Very time consuming. Small Samples.Area specific.

SMAPProvides an Excellent Per-call view of what ishappening at the base station.

Small Samples. Bad Reputation ofcausing Outages in the past.

CallProc1 DebugBest Way to characterize and Debug CBSCCall Processing Problems.

Dangerous to Use on a Live System.Requires developer level understanding ofCall Processing SFS to be of any use.

Event Logs / Alarm Manager

Best Way to piece together timelines offailures and recoveries. No impact to thesystem.

Poor Indicator of Performance Trends:Events tell you only what is bad, not whatis good. Not very useful for debuggingRF-related problems.

Call Detail Records

Great General Purpose technique for bothdebugging problem AND characterizingsystem performance. No impact to thesystem Many types of stats impossible tocalculate with PM can be derived from CDLs.

Stats computation is more complex andTime Consuming than PM. Level of detailis *slightly* less than that of Drive Test &SMAP Logs.


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.


Information contained in CDLs


Main Categories of CDL Data

• CBSC General Info• XC Assignment Info• Mobile Info• BTS Tch Assign Info• Access Details• CBSC Release Info• Hard Handoff Target

Info• N-way Stats• N-way Final Elements

• Handoff Fail Stats• Inter-CBSC Soft

Handoff Stats• Last RF BTS

Connection Stats• BTS Tch Assign Info• Access Details• CBSC Release Info• Initial MAHO Stats


Main Categories of CDL Data (continued)

• Next-to-Final Active Set Stats

• Next-to-Final Candidate Set Stats

• Final Active Set Stats• Final Candidate Set

Stats• First Soft Handoff

Stats• Setup Event List

• Forward & Reverse Quality Stats

• Vocoder Bypass Stats• Packet Data Stats• Voice/Data Toggle Stats• Carrier Load

Management Stats• 1X Packet Data Stats


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.


CBSC General Fields

• CBSC - Identifies the CBSC controlling the call (FromR16.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.

MM number5th digit

“00 –99” OMCR ID3nd and 4th digit

Area such as auK2nd digitAlways “1”1st digitMEANINGDIGIT


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.


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.


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.


MOBILE INFO (continued)More on ESNs• Last Digit (or Last 2 Digits) Tells us the Maker

1 = Kyocera2 = Sony3 = Toshiba4 = Hitachi5 = 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 = Sanyo9 = Casio (2nd to last digit is even)9 = Motorola TSU (2nd to last digit is odd)e = Denso


MOBILE INFO (continued)

• 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.


MOBILE INFO (continued)

• 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.


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


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).


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

• Init RF Connect BTS Signalling Type – Signalling type of the BTS associated with the TCH assigned. Options are:

• 1: BTS with Packet Signalling • 0: BTS with Circuit Signalling

NEW! R16.1


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


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.



• 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 Origination1 = Mobile Termination2 = Hard Hand-in3 - 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.



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

lihy

lihy



• 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.



• 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. . .


Getting to the Conversation State…Mobile-Base Station Call Processing

Mobile

Detect User-Initiated CallSend Origination Message

Sets Up Traffic ChannelReceives N consecutive valid frames

Begin sending TchPAMReceive Base Acknowledgement

Mobile Station Ack OrderBegin sending null Tch Data

Receive Service Option Response/Service Connect Message

Mobile Station Ack Order

Service Connect Complete Message

Conversation!

Base Station

Set up Traffic ChannelSend Channel Assignment MessageBegin Sending Null Tch DataAcquires the Reverse Traffic ChannelSend Base Station Ack Order

Start Sending 1/8 STRAU to XC

Forward Service Option Response/Service Connect Message

Conversation!

> Access Channel >

< Paging Channel << Forward Traffic Channel <

> Reverse Traffic Channel >

< Forward Traffic Channel <> Reverse Traffic Channel >


< Forward Traffic Channel <



This flow describes a call origination where all goes well.


Getting to the Conversation State…Base Station - CBSC Call Processing

Base Station

Send Origination MessageGet the ACK

Sets Up Traffic ChannelDetect Tch Preamble

Send ACK Order to MobileGet Mobile ACK Order Reply

Start Sending 1/8 STRAU to XC

Send SC Message to MS

Receive SC ACK from MS

Conversation!

CBSC

Acknowledge the OriginationTell BTS to setup a ChannelWait for Base to detect PreambleSend Base Station Ack Order

Detect 1/8 NULL STRAU

Tell Base to Send Service Connect Message to Mobile

And if everything on the EMX side Ok

Conversation!

> Origination Message >

< Base Ack << Channel Assignment Order (16) <

> Tch Preamble >

< Base Station Ack Order <> Mobile Station Ack Order >

> NULL 1/8 Rate Frame >

< Service Connect Message <

> Service Connect Complete (17) >

< Speech >



Getting to the Conversation State…CBSC - EMX Call Processing

CBSC

Get Origination Message for MobileTell EMX we have a new call

Get the ACKTell EMX to proceed with Setup

Get the Call Proceeding Indicator Get the Assignment Request

Get Mob Service Connect CompleteTell EMX Mobile is Connected

Get the Alerting MessageGet the EMX Connect Message

Acknowledge the Connect

Conversation!

EMX

Get the CM Service RequestAcknowledge CM Service RequestStart Setting up the CallTell CBSC we are setting up CallTell CBSC its OK to put Mob on Tch

Start Ringing Called PartyTell CBSC Called Party is RingingCalled Party Answers

All is Well! Both the Mobile and Called Party connections are up

Conversation!

> CM Service Request (1) >

< SCCP Connection Confirmed (2) <> Setup (10) >

< Call Proceding (11) <

< Assignment Request (15) <

> Assignment Complete (18) >

< Alerting (19) <

> Connect Ack (23) >

< Speech >


< Connect (22) <


Access Details (Continued) Last MM Setup Event (LMMSE)

• Mobile Origination ---Entry Type = 0

• Good Calls ---

16 < LMMSE < 24



• Mobile Termination ---Entry Type = 1

• Good Calls ---

16 < LMMSE < 24



• Hard Handoff --- Entry Type = 2

• Good Calls --- LMMSE = 5


Access Details (Continued)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.

NEW! R16.1


Access Details (Continued)SDU Call Setup Events (2)

NEW! 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

Access Details (Continued)SDU Call Setup Events (3)

NEW! R16.1


Access Details (Continued)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.

NEW! R16.1


Access Details (Continued)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.

NEW! R16.1


Access Probe Handoffs

AccessProbe HO

Origination Origination

CBSC-2CBSC-1

IC FWD Channel Required

MSC-1

8

541

7

2r

Cell Id-1PN-4

Cell Id-2PN-8

Cell Id-3PN-12

rAccess

Probe HO

Layer 2 Ack.

36

Channel Required

CBSC-2 examines the RER and determines PN-4 is the first pilot. CBSC-2 uses the Neighbor list of cell Id-3, PN-12 to translate PN-4 to CBSC-1&Cell Id-1.Therefore CBSC-1 is the call-setup CBSC. CBSC-2 forwards the Channel Required and Cell-Id 1 info. to CBSC-1

First Sector of access Cell Id-1

PILOT_PN_PH PILOT_STR ACC_HO_EN ACC_ATTPN- 4 -6 1 1PN - 8 -10 1 1PN - 24 -2 0 0

NUM_ADD_PILOTS 3

FIRST_IS_ACTIVE 0FIRST_IS_PTA 0

ACTIVE_PILOT_STR -5ACTIVE PILOT PN 12

NEW! R16.1


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 callCFCs. More will be introduced in future releases.


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


CBSC Release Info (Continued)The “Bad” CFCs. . .

No Resource CFCs:CFC-2 : Tch DisabledCFC-18 : No Xcdr CircuitCFC-19 : No DTCCFC-20 : No Radio ResourcesCFC-21 : Requested Terrestrial Resource

UnavailableCFC-33 : No Radio Resources - Redirect to AnalogCFC-138: No PSI_SDU AvailableCFC-139: No PSI_CE AvailableCFC-142: PSDN Resources not Available CFC-143: PCF Resources not Available

RF Trouble CFCs:CFC-3 : RF Layer 2 FailureCFC-4 : RF LossCFC-5 : No Tch PreambleCFC-8 : MS Did not Arrive on HHO Target

ChannelCFC-9 : No Valid Speech from MS during Call

SetupCFC-10 : No Valid Speech from MS during Hard

HandoffCFC-13 : CP Timeout Awaiting Service Option AckCFC-29 : Handoff Procedure TimeoutCFC-134 : Call Blocked - ELPA Fixed LimitCFC-135 : Call Blocked - Forward Load LimitingCFC-136 : Call Blocked - Reverse Load LimitingCFC-146: Call Blocked – LPA Self Calibrating limit

CBSC Trouble CFCs:CFC-6 : No STRAU SynchCFC-7 : CP Timeout Awaiting MS AcquistionCFC-12 : CPP Call Setup TimeoutCFC-60 : Protocol Error between BSC and MSCCFC-61 : Protocol Error between MM and XCCFC-62 : XC Detected ErrorCFC-13 : CP Timeout Awaiting Service Option AckCFC-70 : Service Configuration Toggle Procedure

FailureCFC-80 : MM Internal ErrorCFC-81 : MM Database ErrorCFC-130: Target XC FailureCFC-133: Internal Target MM Failure

Discrepancy CFCs:CFC-11 : Active Set MismatchCFC-14 : Not Enough Mobile Status Information

ReceivedCFC-15 : Negotiation FailureCFC-22 : Terrestrial Circuit Already AllocatedCFC-32 : Disabled Service Option

H/W Failure CFCs:CFC-23 : Radio Interface FailureCFC-52 : Equipment Failure at BSCCFC-53 : Equipment Failure at MSCCFC-132 : Equipment Failure at Target BSC

MSC Trouble CFCs:CFC-26 : Abnormal MSC DisconnectCFC-27 : MSC Disconnect with SCCP

Connection RefusedCFC-28 : MSC Disconnect with SCCP RLSD

Human-Caused CFCs:CFC-50 : O&M Intervention at BSCCFC-51 : O&M Intervention at MSCCFC-54 : Reset or Reset Circuit from MSCCFC-131 : O&M Intervention at Target BSC

IWU Trouble CFCs:CFC-100 : Circuit Data IWU T1.617 Setup FailureCFC-101 : Circuit Data CDP T1.617 Setup FailureCFC-102 : Circuit Data IWU T1.607 Setup FailureCFC-103 : Circuit Data CDP T1.607 Setup FailureCFC-104 : Circuit Data IWU T1.617 Initiated

Disconnect of Stable CallCFC-105 : Circuit Data CDP T1.617 Initiated

Disconnect of Stable CallCFC-106 : Circuit Data IWU T1.607 Initiated

Disconnect of Stable CallCFC-107 : Circuit Data CDP T1.607 Initiated

Disconnect of Stable CallCFC-108 : Circuit Data CPP Inactivity timer TimeoutCFC-109 : Circuit Dat Call FailureCFC-112 : Packet Data Setup FailureCFC-113 : Packet Data Protocol ViolationCFC-114 : Packet Data Unresolved IWU Release

Note : There is also CFC-255 for “Unknown” Failures


NEW R16.1 CFCs

• 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.

NEW! R16.1

NOTE: some existing CFCs have been modified as well (mainly new detailed causes associated with them)


CBSC Release Info (Continued)

CFC Count Percentage

111 5006 50.0631 2400 241 1956 19.56

27 303 3.035 128 1.284 79 0.79

13 50 0.530 37 0.3724 21 0.213 12 0.12

28 4 0.0426 2 0.0229 1 0.0160 1 0.01

Total 10000 100

• The table to the left shows CFC distribution taken from 10,000 calls from the KCT F-unit at about 4am.

• Even though there are 64 different CFC classes, we typically only see 15 classes normally ( including CFC-9, although CFC-9 did not appear in this sample.)

• Of these 14 classes, CFC-3, 4, 5, 9, 13, 27, 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.


RF Call Setup & Failure Stages

Start

MCCWait forTchPAM

CFC=5

XC Wait for Mobile ACK

Order

Detected?

Detected? CFC=3 or 60

Detected? CFC=9

XC Wait for 1/8 Null STRAU

XC Wait for Service

Option ACK

Detected? CFC=13

Conversation

No

No No

No

If T3230 expires before MaxRetryattempts occur, CFC60 is pegged.If MaxRetry attempts occur beforeT3230 expires, CFC3 is pegged.


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.


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'sTchPAM 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.


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.


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.


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.


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.)


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.


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-xAPARMS3) 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.


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 neverdo 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.


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.


CFC-60 : Protocol Error between BSC and MSC

• The CBSC or MSC detected an A+ protocol error associated with the call. The EDITCBSC-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.



• 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.



• Init_MM_Rel_Event : (IMMRE) Tells us what event triggered the Mobility Manager to Release the Call.

– 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.

IMMRE Mean ing1 Normal Land Release3 Normal MS Release5 Abnormal MSC Disconnect7 Abnormal CBSC Disconnect13 Good Pilot Beacon Handoff

17

I-CBSC Anchor Handoff,Successful left source,Failed to Reach Target



• 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



• 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.

Aplus (2)

Aplus L3 (3)

SCCP (0?)

SCAP (1)

LAPD

EMX CBSC BTS



• The Most Famous Initial Disconnect Cause (IDC) Codes:IDC Link Mean ing CFCs Percentage

0x1100 SCAP (1) Normal Mobile Release 31, 111 50.020x1802 SCAP (1) Data Call Normal Network Release 111 27.500x0010 SCAP (1) Voice Call Normal Land Release 1 16.88

0x0000Not Scap,Not A+ SCCP Disconnect or Hard Handoff 24,27,28,30 1.98

0x111b SCAP (1) No Tch Preamble 5 1.320x111a SCAP (1) RF Loss 4 0.660x1123 SCAP (1) Service Option ACK TimeOut 13 0.560x1801 SCAP (1) Data Call, Abnornal CBSC Release 111! 0.380x1809 SCAP (1) Data Call, Abnormal EMX Release 111! 0.240x1402 SCAP (1) Good Inter-CBSC Anchor Handoff 30 0.200x1119 SCAP (1) RF Layer 2 Failure 3 0.120x0060 A-plus (2) A+ Protocol Error 60 0.100x0009 A-plus (2) Abnormal EMX Disconnect 26 0.040x1122 SCAP (1) No Valid Speech Detected 9,10 0.020x8000 SCAP (1) BTS Device taken OOS by Human 50 0.020x007f 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!


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.


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.


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.

ONEPILOT

COUNT

TWOPILOTSCOUNT

THREEPILOTSCOUNT

FOURPILOTSCOUNT

FIVEPILOTSCOUNT

SIXPILOTSCOUNT

0 3 5 4 1 0

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.

Initial1-way

1-way MAHO2-way

MAHO3-way

MAHO4-way

MAHO5-way

MAHO6-way

1 2

3 13

11

1


N-Way Stats (Continued)

• The N-Pilot Counters have an upper limit of 15: ONE

PILOTCOUNT

TWOPILOTSCOUNT

THREEPILOTSCOUNT

FOURPILOTSCOUNT

FIVEPILOTSCOUNT

SIXPILOTSCOUNT

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.



• 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 doneduring 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.



• Relation between N-way counters and Add/Drop Counters: Sums should always be the same. Example:

LOC_SADD

COUNT

LOC_SRADD

COUNT

LOC_SDROP

COUNT

LOC_SRDROP

COUNT

EXT_SADD

COUNT

EXT_SRADD

COUNT

EXT_SDROP

COUNT

EXT_SRDROP

COUNT2 6 1 4 0 0 0 0

ONEPILOT

COUNT

TWOPILOTSCOUNT

THREEPILOTSCOUNT

FOURPILOTSCOUNT

FIVEPILOTSCOUNT

SIXPILOTSCOUNT

0 3 5 4 1 0 Total Count: 13

Total Count: 13

• Total Adds = 2 + 6 + 0 + 0 = 8, Total Drops = 1 + 4 + 0 + 0 = 5

RELEASEL_WC

RELEASEE_WC

3 0

• Release_L_WC and Release_E_WC : Tells us the number of local and external Walsh Codes (Pilots) 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.



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

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

• 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.)

LASTMAHOACT1BTS

LASTMAHOACT2BTS

LASTMAHOACT3BTS

LASTMAHOACT4BTS

LASTMAHOACT5BTS

LASTMAHOACT6BTS

LASTPSMMACT1BTS

LASTPSMMACT2BTS

LASTPSMMACT3BTS

LASTPSMMACT4BTS

LASTPSMMACT5BTS

LASTPSMMACT6BTS

459 266 0 0 0 0 459 266 459 0 0 0



• Init_MAHO_CandN_Bts (N=1..3) : Tells us the very first BTSes of the CDL which the Mobile wants to Add.

• 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

ACCESSBTS

INITMAHOCAND1

BTS

INITMAHOCAND2

BTS

INITMAHOCAND3

BTS

FIRSTSHO

RESULT459 459 0 0 1



• 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 very informative.

– Most calls never go into 1-way. This means RF is good

– We see that the chance of RF Loss goes up nearly 5X for calls that enter 1-way

– Most calls never go into 5-way or 6-way. This means WC and CE are being used efficiently

Pilot Count "N"

Percentage of AllCalls with ZeroPilot Count=N

Percentage of AllCalls using N-way

1 93.1 6.92 56.2 43.83 58 424 86.1 13.95 95.6 4.46 98.4 1.6

Call Type RF-Loss Rate

Calls that went into1-way at least once 2.39%Calls that never fell

into 1-way 0.50%



• 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 withRelease_L_WC and Release_E_WC to calculate Soft and Softer Handoff Factors:

RELEASEL_CE

Calls withCount

WeightedCount

RELEASEE_CE

Calls withCount

WeightedCount

TotalWeightedCount

0 36 0 0 918 0 01 677 677 1 77 77 7542 239 478 2 5 10 4883 48 144 3 0 0 144

Total 1000 1299 1000 87 1386

Average Channel Element/Call : SOFTER HANDOFF FACTOR -> 1.386

RELEASEL_WC Count

WeightedCount

RELEASEE_WC Count

WeightedCount

TotalWeightedCount

0 36 0 0 918 0 01 277 277 1 66 66 3432 409 818 2 15 30 8483 224 672 3 1 3 6754 45 180 4 0 0 1805 5 25 5 0 0 256 4 24 6 0 0 24

Total 1000 1996 1000 99 2095

Average Walsh Codes/Call : SOFT HANDOFF FACTOR -> 2.095

• Use the Softer Handoff Factor to plan the number of MCC cards for a system.

• Use the Soft Handoff Factor to estimate the Total Number of Walsh Codes Used

• System Engineering Design Guidelines : Softer Handoff Factor = 1.5. Soft Handoff Factor = 2.5

• Data on tables to the left come from KCT F-Unit.

It is operating more efficiently

than designed.



• 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.– Happens in roughly 1.5 percent of calls. ( Source: KCT F-unit )

• 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 )



• Num_SHO_Failures : This is the number of times a Soft/Softer Handoff fails in a CDL– Happens in roughly 0.3 percent of calls. ( Source: KCT F-unit )– 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 SHO Fail Reason5120 No MCC Response (Check SPAN DELAY!)5121 MS Did Not Accept Handoff5122 No MS Response (Check SPAN DELAY!)

5123 No Handoff Recognized

5125 No MM Response

5127 XC Timer Expired

• Last_SHO_Fail_Cause : This code tells the failure reason for the last SHO. Many 5120 or 5122 suggests a DELTA SPAN DELAY problem.

• 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


N-Way Stats (Continued)• 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 their RF LOSS is high compared to other calls. If this is the case, you should consider raising the Aggr_Active_Set_Strength thresholds defined in EDIT CBSC HOCONSTR table.

• 35% of Blocked handoffs are Blocked for LHOBC=7. ( Source : KCT F-unit )

• 26% are Blocked because no more than 3 BTSs can be added. (LHOBC=14)

• 20% are Blocked because no more than 3 sectors at a site can be added. (LHOBC=13)

• 18% are Blocked because the Mobile is reporting a Pilot not in the Neighbor List. (LHOBC=5)

• 0.75% are Blocked because the call is in 6-way. (LHOBC=15)

• 0.25% are Blocked by the EMX (LHOBC=2)

SHOBlockedCause Reason

2 MSC rejected handoff request3 No response from MSC4 Call was in HOLD condition5 Target pilot not in neighbor list

6No mutual service option

configuration7 XC Filtering : PSMM Discarded8 Service option not supported at target9 No channel available

10No local inter-CBSC subrate channel

available

11Inter-CBSC handoff request received

a no-ack from external CBSC12 No response from external CBSC13 Max softer legs already connected14 Max Channel Elements15 Max Active Set

255No handoffs were blocked (or none

were attempted)

lihy

5 Target pilot not in neighbor list

lihy

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



• 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.



• Last_SHO_Time : Tells us when the final Soft Handoff was attempted, irrespective of whether it was successful, blocked, or failed.

– Always check this and compare with Release_Time if SPAN DELAY problems are suspected.

• Last_SHO_Cause & Result : These tells us the type and result of the final Soft Handoff attempt.

• Last_Post_SHO_Agst : VERY IMPORTANT FIELD. Tells us the downlink signal quality (Aggregate Strength) the mobile should get as the result of completing the last Soft Handoff.

– ALWAYS CHECK when investigating dropped calls.– THE FORMULA : Mobile RX Ec/Io = - (Last_Post_SHO_Agst / 2)– 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

LastSHO

Cause Mean ing0 No SHO8 Soft Add9 Soft Drop11 Hard Handoff12 Softer Add13 Softer Drop32 Multi Pilot Add33 Multi Pilot Drop

34MAHO Supp

Chan Add/Drop

35Initial Site Supp

Chan Add

LastSHO

Resu lt Mean ing0 Disconnected1 OK2 NG



• Shuffle_Type : Tells us whether the Last Soft Handoff was a shuffle operation. (On the KCT F-unit, Shuffles occur only in 1 out of 70 Handoffs…)

• Last_SHO_Num_Sect_Det & Exec : These tells us number of pilots being added (or dropped) in the final handoff. “Det” refers to the number of pilots detected, and “Exec” refers to the number of pilots processed. SHOULD ALWAYS BE THE SAME.

– Special Note: Sometimes there will be a non-Zero Last_Sho_Timewith Zero “Det” and “Exec” fields and no PSMM record. These are HSPD calls which never did a handoff, but did add supplemental channels (Last_Sho_Cause=35)

• Last_SHO_MMAddr_BTS/Sector/MCC/Element -These fields identify the final channel element being added/dropped.

Shuff leType Mean ing

0 No Shuffle Occurred

3

Incomplete BTS Shuffle,Old BTS Dropped,

Disconnect before NewBTS Added

4

Completed BTS Shuffle,Old BTS Dropped, New

BTS Added

5

Incomplete Softer Shuffle,New Pilot Added,

Disconnect before OldPilot Dropped

6

Completed Softer Shuffle,New Pilot Added, Old Pilot

Dropped


Inter-CBSC Soft Handoff Stats

Target CSBCSource (Anchor) CSBC

Remote LegsEMX Local Leg

IC-Span

Target CBSC AreaSource (Anchor) CBSC Area

• Picture Overview of Inter-CBSC Soft Handoff

Note: Anchor Hard Handoff occurs after ALL legs are Remote.


Inter-CBSC Soft Handoff Stats (Continued)


Remote LegEMX Local Leg

IC-Span


• An IC-SHO BEGINS when the first remote leg is added.




Remote LegEMX Local Leg

IC-Span


• An IC-SHO ENDS when the mobile makes a U-turn and last remote leg is dropped.

Cut!Cut!

Cut!



New Source (Anchor) CSBCOld Source CSBC

New Local LegEMX Old Local Leg

IC-Span

New Source CBSC AreaOld Source CBSC Area

• An IC-SHO DISCONNECTS when Anchor Handoff (or Hangup) Occurs

Note: Anchor Handoff is a Hard Handoff. Call is in 1-way immediately afterwards, and then can re-add pilots.

Cut!Cut!

Cut!Cut!

Cut!



CBSC “B” AreaCBSC “A” Area

• Because of RF Overlap, CBSC and Anchor Boundaries are Different.

CBSC Boundary

/ IC-SHO ZONE /

A->B Anchor Handover BoundaryB->A Anchor Handover Boundary


Inter-CBSC Soft Handoff Stats (Continued)• CDL contains ICSHO “Begin” and “End” Records • These are not “First” and “Last” Records, instead they work as follows:

| ICSHO Zone |

^CBSC Boundary

Generate ICSHO Begin Record

Generate ICSHOEnd Record

OVERWRITE ICSHO Begin Record

OVERWRITE ICSHO End Record

| ICSHO Zone |

^CBSC Boundary

Generate ICSHOBegin Record

Generate ICSHO End Record

OVERWRITE ICSHO Begin Record

CLOSE CDL

| ICSHO Zone |

^CBSC Boundary

Generate ICSHOBegin Record

CLOSE CDL NO END Record!

Case 1: Both “Begin” and “End”Records describe the final Inter-CBSC Soft Handoff

Case 2:The “End” Record describes the second-to-last Inter-CBSC handoff. The “Begin” Record describes the last.

Case 3: The “Begin” Record Describes the Last Inter-CBSC Soft Handoff. The “End” Record is blank (all zeros).

74% of all ICSHOs are this kind. (KCT Funit)




Inter-CBSC Soft Handoff Stats (Continued)• ICS_Begin_Time & ICS_End_Time : Tells us when the

last “Begin” and “End” ICBSC Handoff events occurred.

– If End_Time < Begin_Time, it’s a Case 2 call --------------------->

– If Begin_Time & End_Time = 0, the Call never had an Inter-CBSC Soft Handoff

– If Begin_Time is set, but End_Time is 0, it’s a Case 3 call ---->

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

| ICSHO Zone |

^CBSC Boundary

| ICSHO Zone |

^CBSC Boundary


Inter-CBSC Soft Handoff Stats (Continued)• ICS_Begin_Tgt_MMAddr & ICS_End_Tgt MMAddr : Tells us the

adjacent CBSC going into Soft Handoff.

– 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 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.

| ICSHO Zone |

^CBSC Boundary



• 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.

– On the KCT F-unit, 1 out of 3 Inter-CBSC soft handoffs have just one BTS-Sector on the source side.

• ICS_Begin_Src_Count & ICS_End_Src_Count : Begin count tells us the N-way state of the call just before it entered the Inter-CBSC Soft Handover state. End count tells us the N-way state on the source side after a “U-turn type” InterCBSC Soft Handover ended.

– End Count = ZERO means Anchor Handover occurred (without any previous U-turn InterCBSC Soft Handover).

ICS_BEGINSRC_COUNT Percentage

1 47.12 40.93 9.84 2.15 0.1

Total 100

ICS_ENDSRC_COUNT Percentage

0 69.61 7.72 15.23 5.64 1.9

Total 100



• ICS_Begin_Tgt_Count & ICS_End_Tgt_Count : Begin count tells us number of pilots on the Target side added when an InterCBSC Soft Handover starts. End count tells us the number of target side pilots that were dropped after a “U-turn type”InterCBSC Soft Handover completed.

– End Count = ZERO means Anchor Handover occurred (without any previous U-turn InterCBSC Soft Handover).

• ICS_Count : Tells us how many times the call went into InterCBSCSoft Handover Mode. Counts up to 15 and stops.

• ICS_CBSCs : Tell us how many different target CBSCs were used by the call. Counts up to 15 and stops.

ICS_BEGINTGT_COUNT Percentage

1 98.62 1.4

Total 100

ICS_ENDTGT_COUNT Percentage

0 69.61 302 0.4

Total 100

ICS_COUNT Percentage1 80.82 103 4.14 1.35 1.16 0.57 0.18 0.39 0.110 0.212 0.213 0.114 0.115+ 1.1

Total 100

ICS_CBSCS Percentage1 96.92 3.1

Total 100



• 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



• 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.



• 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.


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


Last RF_Connect, MAHO, & PSMM Sites

• Last_RF_Conn2_BTS = A, Last_RF_Conn1_BTS = 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)

• Last_PSMM_Act2_BTS = NULL, Last_PSMM_Act1_BTS = B – (As a result of the final PSMM, A was dropped and only B remained.)

• Last_SHO_BTS = A – (Last SHO event was to drop A)

Site “A” Site “B” Site “A” Site “B”

Site “A” Site “B”

Step 1) Mobile Starts call on Site “A”

Step 2) Mobile Sends in a PSMM indicating he wants to Add Site “B”. Site “B” is added.

Signal from “B” is stronger.

Step 3) Mobile Sends in a PSMM indicating he wants to Drop Site “A”. Site “A” is dropped. Call Ends.


Last RF_Connect, MAHO, & PSMM 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.


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.


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.



• 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)



• 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.



• 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)


Last RF Connection Stats (Cnt)

• 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.

NEW! R16.1


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– First_MAHO_Cause* = Init_MAHO_Cause*– First_MAHO_Act_Str = Init_MAHO_Act_Str– First_MAHO_Cand_Count = Init_MAHO_Cand_Count– First_MAHO_Cand1_Str = Init_MAHO_Cand1_Str– First_MAHO_Cand2_Str = Init_MAHO_Cand2_Str– First_MAHO_Cand3_Str = Init_MAHO_Cand3_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.

* If no MAHO ever occurred, First_MAHO_Cause is set to 255 (Meaning: No MAHO) & Init_MAHO_Causeis set to 0 (Meaning: No MAHO). This is the onlydifference between “First” and “Initial” MAHO stats



• 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!)

FirstMAHOCause Mean ing

0 or 255 No SHO14 Tdrop17 Tadd18 Tcomp



• 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



• 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!



• 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 sitethan the CANDIDATE site. For example:

Active Site “A” Candidate Site “B”

1.0 Km 1.488 Km



• 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. . .


1.0 Km 1.488 Km

1.992 Km1.476 Km

Mobile could be ANYWHERE on this curve!These are ALL points whose DELTA differenceis 488 meters!



• Luckily, we know the distance from the Access BTS!


1.0 Km 1.488 Km

1.992 Km1.476 Km

Distance from Access Site =[ Access_PN_Offset - 14 ] * 244 meters =1.476 kilometers

Access_PN_Offset= 20 Chips

Access Sector= 3

We know the Mobile should not be at thispoint. Otherwise, Access Sector should be “2”, and Candidate Sector should be “6”.

1.992 Km1.476 Km

Candidate PN= 0x0200

Candidate Phase=0x202

Candidate Sector=5

Mobile is Here!

S6S6 S2

S3S5S4

1.476 KmRadius Line

Delta0.488 KmHyperbolaLine



• 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:


True MobileLocation atAccess Time

Radius Line atAccess Time( In CDL )

Radius Line atInit_MAHO Time( Not In CDL )

HyperBola Line atInit_Maho Time( In CDL )

True MobileLocation atInit_Maho Time

Calculated MobilePosition. (Its Wrong!)



• 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 Site “C”

Candidate Site “B”

Candidate PN * 0x40 = 0x0200

Candidate Phase =0x0200

Delta = 0 -> Mobile is same distancefrom sites “A” and “B”

Candidate PN * 0x40 = 0x1900

Candidate Phase =0x18ff

Delta = -1 -> Mobile is 244 meterscloser to site “C” than “B”1.244 Km

1.244 Km

1.0 Km



• 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!



• 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.



• 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 makethese today with Drive Testing unless SMAP is used!

– Using LAST_PSMM Phase & MeasCount Stats, Mobile Forward FER plots can be made with CDLs!


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 performed– Measured in XC Time (20 millisecond frames)– Compare with XC_Release_Time to learn when the

MAHO occurred relative to the end of the call.• 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).

LastMAHOCause Mean ing

0 or 255 No SHO14 Tdrop17 Tadd18 Tcomp


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


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”).


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.


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


Last PSMM Stats

• 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.

NEW! R16.1


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.



• 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.

lihy

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.

lihy

* FORWARD QUALITY definition assumes XcCpT5 is set at the Default value of 10,000 (10 seconds) and FwdQualityThres set at 3.

lihy

FAQEM = Forward Audio Quality Events per Minute.

lihy

lihy

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.



• 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 %

lihy

PwdRepDelay = 0, and PwdQualityThres = 1

lihy

Set XcCpT5 = 40 msec, PwdRepDelay = 0, and PwdQualityThres = 1

lihy

4”



• 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).

lihy

Meas_Count - VERY Useful!

lihy

Tells us the number of Power Increase requests during the final 0..10 seconds of the call.

lihy

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]



• 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.

Access timeRelease time

WINDOW for Mes_Count= 0 to XcCpT5 (50 msecc)

Last PMRM

PwdRepDelay = 4 Frames



• 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.

XcCpT5PwdReportDelay

Parameter CLI CommandSetting

EDIT XC-# XCHOPARMS10 secondsEDIT BTS-# MSFPC 0 or 1

lihy

XcCpT5 EDIT XC-# XCHOPARMS 10 seconds EDIT BTS-# MSFPC

lihy

PwdReportDelay 0 or 1

lihy

Setting



• 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).



• 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_CountCDL 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.


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.



• 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.



• REV_RISE – Reverse link noise rise in 100ths 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_OrigFWD/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.

lihy

FWD/REV_

lihy

FER

lihy

High_

lihy

–

lihy

Percent

lihy

DISPLAY CARRIER-bts#-Sect#-carr# CARRLOADMGT”


Vocoder Bypass Stats

• Vocoder_Bypass - Bitmap that gives us a “Mini-History” of Vocoder bypass activity for the call.

Bit 0BypassFailed

Bit 1BypassSuccess

Bit 2BypassEnabled

Bit 3BypassActive

Bits 4-7 UnusedALL ZERO

• 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


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.

lihy

0x00 - Non-Packet call.

lihy

0x01 - new packet-oriented data call.

lihy

0x02 - mobile initiated reactivation of a packet-oriented data call.

lihy

0x03 - network initiated reactivation of a packet-oriented data call.

lihy

0x04 - 0x0F - Reserved

lihy

ID


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).

lihy

FWD/RVRS_DIR – Total number of bytes transmitted in the forward/reverse direction in 1K increments per call (Display

lihy

BYTES_SENT_FWD/

lihy

DATA_BURST_ATTEMPTS – Total number of Data Burst attempts (for on-demand supplemental channel assignment).


SDU-SDF Resources

• 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 Distributionresource 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.

NEW! R16.1

lihy

BEARER_


Lost BTS Leg Information

• 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 MCCcewas operational when lost.

• MCC_LOST_LEGThe MCC_ID associated with the MM under which the MCCcewas operational when lost.

• CE_LOST_LEGThe Channel Element number of the lost MCCce.

NOTE: need to quantify “LOST”

NEW! R16.1


Appendix

• Tools to analyze CDL log files– CDL Browser Tools

• Download the Packagehttp://cdma.gtss.mot.com/~saxon/brw.html

• Manualhttp://cdma.gtss.mot.com/~saxon/brw.pdf

– Windows• PIPE BRO

http://www.tcsg.japan.mot.com/atrndc/members/jonathan/pipebro.htm

• CDL2CSVhttp://www.tcsg.japan.mot.com/cseg/members/narukami/index.htm

– Unix• XCAT

http://www.rochellepark.pamd.cig.mot.com/software/cat/

Documents

CDL Analysis v6 - Eefocusdata.eefocus.com/myspace/15/79650/bbs/2009-06-03/1243990143_917… · Fundamentals of CDL Analysis Motorola Japan V6.0. ... Motorola Confidential Proprietary