fundamentals of cdl analysis cdl 分析基础

Motorola Confidential Proprietary Fundamentals of CDL Analysis -- J. Hutcheson

Fundamentals of CDL Analysis

CDL 分析基础


Today’s Presentation 今天的课程介绍

• Why Do CDL Analysis? 为什么要进行 CDL 分析？• Information Available in CDLs

CDL 中的有用信息

• While learning CDL information, we will also study basic CDMA Call Processing.

• 学习 CDL 信息的时候，我们会同时学习基本的 CDMA 呼叫处理过程• “Hands-On” troubleshooting Exercises using CDLs. 使用 CDL 发现并解决“ Hands-On” 问题


Why Do CDL Analysis?为什么要做 CDL 分析？


System Performance Analysis Techniques 系统技术性能分析

PM Statistics PM （性能监测）统计表

Extremely Detailed Tables Counting Events over fixed time periods:非常详细地在确定的时间周期内从头到尾地清点事件：

• Originations （发起）• Terminations （终止）• Registrations （注册）• Failures （失败）• Handoffs （切换）• Call Final

Classes （ cfc ）• 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 下行链路 RF （无线信号）状况• 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

A+ 消息序列• SCAP Message

Sequences SCAP 消息序列• Paging/Sync Messages

寻呼 / 同步消息• and more… 更多

CallProc1 Debug 呼叫进程 1 的调试

Records of nearly every MM transaction关于几乎每一个 MM 处理的记录（包括）：

• SCAP Messages to and from Base Stations 来自和发往基站的 SCAP 消息

• A+ Messages to and from the EMX 来自和发往EMX 的 A+ 消息

• 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 从 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 地点和

CBSC （中央基站控制器）• Handoff Stats 切换统计• RF Performance Stats 无

线信号性能统计• and more… 更多


Analysis Techniques : Pros & Cons分析技巧： 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 分析，当比 PM 统计更综合时，可以提供多得多的细节

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

CDL 分析，当没有每一蜂窝的路测记录 + SMAP 分析详细时，允许为在重要区域的所有呼叫来获得性能信息。

• For these reasons, CDL Analysis has been used as the Primary FOA, RF-Field Test, and RF-crisis resolution analysis technique.

由于上述原因， CDL 分析已经用作初步的 FOA ，无线信号实地试验，和 RF-crisis resolution analysis technique.


Information contained in CDLsCDL 中包含的信息


Main Categories of CDL Data CDL 数据的主要类型

• CBSC General Info CBSC 一般信息

• XC Assignment Info 变码器分配信息

• Mobile Info 移动台信息

• BTS Tch Assign Info 收发信基站业务信道分配信息

• Access Details 接入细节

• CBSC Release InfoCBSC释放信息

• Hard Handoff Target Info硬切换目标信息

• N-way Stats N-way 统计

• N-way Final Elements N-way最终元件

• Handoff Fail Stats 切换失败统计

• Inter-CBSC Soft Handoff Stats CBSC 内部软切换统计

• Last RF BTS Connection Stats 最后无线信号收发信基站链接统计

• BTS Tch Assign Info收发信基站业务信道分配信息

• Access Details 接入细节

• CBSC Release Info

CBSC 释放信息

• Initial MAHO Stats 初始MAHO 统计


Main Categories of CDL Data (continued) CDL 数据的主要种类（续）

• 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 (New in R15) 话音

/ 数据 Toggle 统计（ R15 中新增）

• Carrier Load Management Stats (New in R15) 载波负荷管理统计（ R15 中新增）


CDL Fields CDL 字段

• There are over 330 fields in R9, and over 350 fields in R15… 在 R9 中有超过 330 个字段，而在 R15 中有超过 350 个…

• Is it necessary to know every CDL field to do CDL analysis? 是否有必要去知道每一个 CDL 字段才能做 CDL 分析呢？

– 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. 随着实践和经验的增加，你能够学到更多的字段，并且甚至成为一个更厉害的分析师

– In today’s class, we will cover CDL fields the ASE team has found useful in analyzing performance and solving problems. 在今天的课上，我们会过一遍 ASE团队在分析中找到的在性能分析和解决问题上很有用的 CDL 字段


CBSC General Fields CSBC 的常规字段

• CBSC - Identifies the CBSC controlling the call CBSC －确定控制着呼叫的 CBSC

– Numerical Value : 1, 2, 3, . . . 数值： 1, 2, 3, . . .

– Numbers are reused on different OMCs 号码可以在不同的 OMC 上重用– OMC unit + CBSC field uniquely identifies a CBSC (e.g. E1 unit, H3 unit) OMC单元＋ CBSC 字段唯一地确定一个 CBSC （例如： E1单元， H3单元 )

• CPP - Identifies the XC (Transcoder) Call Processing Processor GPROC CPP – 确定变码器呼叫进程处理器 GPROC

– OMC unit + CBSC + CPP fields uniquely identify a CPP (e.g CPP E1-8, H3-5)

OMC单元 + CBSC + CPP 字段唯一地确定一个 cpp （例如 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.

如果一个变码器被认为是问题的起因，你应该检查这个字段去看看异常呼叫是否伴随着一个特定的 GPROC.


XC Assign Info 变码器指派信息

• CIC Span - Tells which E1 span is connecting the Transcoder to the EMX.

CIC Span －表明哪一个 E1 区间把变码器连接到 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.

注意：如果 cic 为 0 ，检查该呼叫是否是一个分组数据呼叫，分组数据的呼叫并不需要连接到 EMX 。

• CIC Slot - Tells which TimeSlot on the CIC span is being used. cic 时隙－表明在 cic 区间中的哪一个时隙正被使用。

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

永远不会是 0或者 16 。除非：分组数据呼叫显示 cic 时隙＝ 0 。如果有很多 cfc21 的呼叫，总要检查这个字段。

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

XCDR －表明哪一个变码器正在处理该呼叫，如果一个变码器帧被认为是问题起因，检查是否有异常呼叫伴随着一个特定的 XCDR


MOBILE INFO 移动台信息

• MID - Mobile ID. Similar to a Mobile Phone Number MID －－移动台 ID 。和一个手机的号码相似。

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

第一个三位数字叫 MIN2 ，典型值是 440,441(DDI), 190, 191 (IDO). 192 经常被分配给原型测试电话，还没有在公开市场上销售。

– 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

－最后 7位数字叫 MIN1 。这些数字总是和手机号码的最后 7位是一样的。例如： 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.

ESN －电子序列号。一个八位的十六进制码。最后三位数字确定一个电话模式。最后一位的数字确定电话的制造商。


MOBILE INFO (continued)More on ESNs 移动（台）信息（续）关于 ESN 的更多的信息

• Last Digit (or Last 2 Digits) Tells us the Maker 最后一位的数字（或者两位数字）表明那个制造商

1 = Kyocera

2 = Sony

3 = Toshiba

4 = Hitachi

5 = Motorola (2nd to last digit is even)

5 = Tottori-Sanyo (2nd to last digit is odd)

7 = Fujitsu (2nd to last digit is even)

7 = Panasonic (2nd to last digit is odd)

8 = Sanyo

9 = Casio (2nd to last digit is even)

9 = Motorola TSU (2nd to last digit is odd)

e = Denso


MOBILE INFO (continued) 移动台信息（续）

• SCM - Station Class Mark - Tells the Infrastructure the capabilities of the phone making the call.

SCM －－配置级别标记－告诉基础设施该通话的话机的能力– 0x62006200 = Regular Single-Mode JCDMA Phone 0x62006200

0x62006200 = 规则单模 JCDMA 话机– 0x6200f300 & 0x6200e200 = Old Dual-Mode (Analog+CDMA) Phones. No

longer sold, but some people still have them. 0x6200f300 & 0x6200e200 = 旧双模（模拟＋ CDMA ）话机。不再有售，但一些用户仍在使用。

– 0x62004a00 - Test Subscriber Unit (TSU). A special phone at the BTS used for loopback and other tests.

0x62004a00 – 测试用户单元（ TSU ）。一个在收发信基站用来做环回测试和别的测试的专用话机。

– 0x6200ea00 - Motorola JCAMPS computer-controlled Drive Test phone. 0x6200ea00 - Motorola JCAMPS 计算机－控制的路测话机– NOTE: Expect Kansai City Media (KCM) band and 1X capable phones to have

new SCMs. 注意：预计 KCM 和支持 1x 的电话会有新的 SCM


MOBILE INFO (continued) 移动台信息（续）

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

拨号数字－告诉我们用户拨出的号码

– Set for Mobile Originations ( Entry Type = 0 ) only 仅为移动发起（ Entry Type = 0 ）设置

– Value of “0” indicates either: 0值表示为下列情况之一：

• Mobile Termination 移动终结

• Mobile Origination -- Packet Data Call 移动发起－分组数据呼叫

• Mobile Hard Hand-in 移动硬切换


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 BTS( 初始无线信号连接 BTS) －表明在这个 CDL 中移动台分配到的第一个 BTS 。如果 CDL 中的进入类型不是 2 （硬切换），这个就是该呼叫的第一个 BTS

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

Init RF Connect Sector( 初始无线信号连接扇区 ) －－表明这个 CDL 中分配到的第一个扇区

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

Init RF Connect MCC( 初始无线信号连接 MCC) －－表明这个 CDL 中分配到的第一个 MCC面板

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

Init RF Connect Element ( 初始无线信号连接元件 ) －表明这个 CDL 中分配到的第一个 MCC 信道元件


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.

Init RF Connect Channel( 初始无线信号连接信道 ) －表明在这个 CDL 中分配到的第一个无线信号载波。如果CDL 中的进入类型不是 2 （硬切换），这将会是该呼叫的第一个 BTS 。

– Hi Band Channels : 76, 184, 292, 400, 508, 616, 724– HI带信道： 76, 184, 292, 400, 508, 616, 724

– Lo Band Channels : 872, 968– LO带信道： 872, 968

– Marinet Band Channel : 1120– Marinet带信道： 1120


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.

接入码片偏移：这个不是指派信道中的码片偏移！Motorola或许应该选一个更好一些的名字。换言之，这是在cdma芯片中用来测量往返时延的。

– We can calculate the Mobile--BTS distance by this formula:

我们可以用下面的公式来计算移动台到 BTS 的距离 : 距离（公里）＝ [Access PN Offset - 14] / 8

Distance (in Kilometers) = [Access PN Offset - 14] / 8


Access Details (Continued) 接入细节（续）

• Access Strength -- Tells us the Initial BTS Received Signal Strength. 接入强度－表明初始 BTS 接收到的信号强度

– Typically, the base station wants to see about 0x0b00 from the mobile. 典型地，基站希望从移动台那里看到 0x0b00– Japan ASE experiments have shown that if Access_Strength is less than 0x0200,

CFC-5 (No Tch Preamble) Access Failures are very likely. 日本的 ASE 实验已经表明如果接入强度小于 0x0200 ，就很可能会发生 cfc － 5 （无

业务信道帧）接入失败– ASE has developed the following (unofficial) formula relating RX Eb/No to Access

Strength: Eb/No ~= 10 * Log [Access_Strength] - 26.5 (dB) ASE 已经研究出出下面（非官方）关于 RX 信噪比接入强度关系的公式： 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. 当调查接入失败问题的时候，除接入 PN 地点距离外，总是检查这个字段

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

接入信道－表明初始指派给该呼叫的 RF 载波。初始 RF连接信道也一样，除非当 CDL 是一个硬切换记录的时候，该字段被设为 0



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

接入 BTS －表明为一个呼叫指派的第一个 BTS ，初始无线信号连接 BTS也一样，除非当 CDL 是一个硬切换记录的时候，该字段被设为 0 。

• Access Sector -- Same as Init RF Connect Sector, except it is set to ZERO if the CDL is for a Hard Hand-in Call.

接入扇区－－和初始无线信号连接扇区一样，除非当 CDL 是一个硬切换记录的时候，该字段被设为 0

• Entry Type -- Tells us how the call started on the CBSC: 进入类型－－表明呼叫是如何在 CBSC 上开始的

0 = Mobile Origination 0＝移动发起1 = Mobile Termination 1= 移动终止2 = Hard Hand-in 2= 硬切换

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.

注意：接入信道，接入 BTS ，和接入扇区字段是多余的。准确的相同的信息可以从进入类型，初始无线信号连接信道，收发信基站，扇区中找到。



• Service Option -- Tells us what kind of call is being made• 服务选项－表明什么类型的呼叫在被处理

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

协商服务选项－表明当移动台请求服务选项被拒绝的时候，由系统分配的服务选项。如果初始移动台请求被接受，字段会设为 0xffff 。例外：当一个 CDL 是硬切换的记录的时候，显示服务选项正在使用中。

Service Option Call Type0x0003 EVRC Voice0x0004 9.6K Circuit Data0x0005 9.6K Circuit FAX0x000c 14.4K Circuit Data0x000d 14.4K Circuit FAX0x000f 14.4K Packet Data 0x0019 64K Packet Data0x1007 9.6K Packet Data



• Last MM Setup Event (LMMSE) -- Tells us how far the Mobility Manager (at the CBSC) got along trying to setup a call.

最后 MM 设置事件－－表明移动管理器（在 CBSC 上）对尝试建立一个呼叫，进行到了什么程度（步骤）

– 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, 19, 20, 21, 22, & 23

“好的” LMMSE ： 4, 5, 17, 18, 19, 20, 21, 22, & 23

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







This flow describes a call origination where all goes well.这个流程描述的是一个各步骤都进展良好的呼叫发起


进入通话状态。。。移动台－－基站呼叫进程

移动台

检测用户发起的呼叫发送（呼叫）发起消息

建立业务信道收到 N 个连续有效帧开始发送 TchPAM收到基站确认消息

移动台确认命令开始发送空业务信道数据

收到服务选项响应 /服务连接消息

移动台确认命令

服务连接完成消息

通话

基站

建立业务信道发送信道配置消息开始发送空业务信道消息请求反向业务信道给基站发送确认命令

开始发送 1/8 STRAU 给 XC

前向服务选项响应 /服务连接消息

Conversation!

> 接入信道 >

< 寻呼信道 <

< 前向业务信道 <

> 反向业务信道 >







这个流程描述的是一个各步骤都进展良好的呼叫发起


Getting to the Conversation State…Base Station - CBSC Call Processing进入通话状态。。。基站－－ CBSC 呼叫进程

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 >



进入通话状态。。。基站－－ CBSC 呼叫进程

基站

发出发起消息收到确认

建立业务信道检测业务信道前同步码给移动台发送确认命令

收到移动台确认命令回复开始给变码器发送 1/8 STRAU

给 MS 发送 SC 消息

从 MS 收到 SC 确认

通话

CBSC

收到发起消息告知 BTS建立业务信道等待基站检测前同步码向基站发送确认命令

检测 1/8 NULL STRAU

告知基站发送服务连接消息给移动台

如果 EMX 侧一切正常

通话

> 发起消息 >

< 基站确认 <

< 信道分配命令 (16) <

> 业务信道前同步码 >

< 基站确认命令 <

> 移动台确认命令 >

> 空 1/8 速率帧 >

< 服务连接消息 <

> 服务连接完成 (17) >

< 语音 >



Getting to the Conversation State…CBSC - EMX Call Processing进入通话状态。。。 CBSC －－ EMX 呼叫进程

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


进入通话状态… CBSC －－ EMX 呼叫进程

CBSC

从移动台得到发起消息告知 EMX 我们收到一个新呼叫

收到确认消息告知 TEMX 继续进行建立取得呼叫进行指示器

取得指派请求取得移动台服务连接完成（消息）

告知 EMX 移动台已连上取得发信号消息

取得 EMX 连接消息

确认连接

通话

EMX

取得 CM 服务请求确认 CM 服务请求开始建立呼叫告诉 CBSC 我们正在建立呼叫告知 CBSC 把移动台放到业务信道上

开始被叫用户响铃告知 CBSC被叫用户正在响铃被叫用户答复

一切顺利 ! 移动台和被叫用户两边的连接都建立起来了

通话

> CM 服务请求 (1) >

< 确认 SCCP连接 (2) <

> 建立 (10) >

< 呼叫进行 (11) <

< 分配请求 (15) <

> 分配完成 (18) >

< 发信号 (19) <

> 连接确认 (23) >

< 语音 >


< 连接 (22) <


Access Details (Continued) Last MM Setup Event (LMMSE)接入细节（续）最后移动管理器设置事件（ LMMSE ）LMMSE Entry Type = 0, Mobile Origination Entry Type = 1, Mobile Termination Entry Type = 2, Mobile Hard Hand- In

01 A+ CM Service Request sent A+ Page Response sent Setup TCH resources

02 SCCP Connection Confirm received TCH ready

03 A+ Handover Request Acknowledge sent

04 Reserved for authentication/ ciphering events. MS on TCH

05 A+ Handover Complete sent

06 - > 08

10 A+ Setup sent A+ Setup received

11 A+ Call P roceeding received A+ Call Confirmed sent

15 A+ Assignment Request received

16 Assignment of the MS to a TCH was initiated

17 The MS was successfully assigned to a TCH

18 A+ Assignment Complete sent

19 A+ Alerting received The MS was instructed to alert

20 A+ Alerting sent

21 The MS went offhook

22 A+ Connect received A+ Connect sent

23 A+ Connect Ack sent A+ Connect Ack received

24 Assignment of XC Resources Initiated

25Connection of Terrestrial Resources

Initiated

Good Calls : 16 < LMMSE < 24 (for Orig/Term), LMSSE=5 (for Hard HO)好呼叫： 16 < LMMSE < 24 （对于发起 / 终止）， LMSSE=5 （对硬切换）


CBSC Release Info CBSC 释放信息

• Call Final Class (CFC) -- The MOST IMPORTANT CDL Field. CFC tells us how a call finished.

呼叫最终类（ CFC ）－ CDL 字段中最重要的部分。 CFC 表明一个呼叫是如何结束的。

– Good CFCs : 1, 24, 25, 30, 31, 111 好的 CFC ： 1, 24, 25, 30, 31, 111 – If 16 < LMMSE < 24 (Orig/Term Calls). . . And if CFC-111, Init Disconnect Cause = 0x1802 or 0x1100 如果 16<LMMSE<24 （发起 / 终结）同时如果 cfc － 111 ，初始断开起因＝ 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.

模棱两可的 CFC ： 26 。有时是良好呼叫（移动台振铃 45秒还得不到回应，或者当移动台振铃时陆地连接断开）。其他情况， CFC26代表异常呼叫。

– Bad CFCs : All others! There are currently 57 types of bad call CFCs. More will be introduced in future releases.

坏的（异常） CFC ：所有其他。目前有 57种异常呼叫 CFC 。在将来的版本中将会有更多的介绍。


CBSC Release Info (Continued)The “Good” CFCs. . .CBSC 释放信息（续）良好的 CFC 。。。

• CFC 1 -- Normal Call, Land Release CFC1 －正常呼叫，陆地释放• CFC 24 -- Successful External Hard Handoff to CDMA.

CFC24 －成功的外部硬切换到 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”.

外部并非表示“一个外部的 CBSC 。它仅仅表示移动台报告一个 Tcomp 候选导频信号 , 同时 CBSC停止命令一个硬切换到不同载波上。 Motorola 应该取一个更好的名字，比如：”成功导频信号切换“

– Occurs with successful DAHO hard-handoff also. DAHO is generally not used in Japan.

同样伴随着成功 DAHO 硬切换出现。 DAHO 在日本通常是不使用的。• CFC 25 --Successful External Hard Handoff to Analog

CFC25 －成功外部硬切换到模拟– 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).

和 CFC24 一样，但在这种情况下，导频信号 (或者 DAHO) 数据库指向一个模拟的扇区 (XASECT) 而不是一个 cdma扇区(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

移动台越过一个 CBSC边界，同时对该呼叫的控制切换到一个新的 CBSC

• CFC 31 --Normal Call, Mobile Release 正常的手机发起的拆线• CFC 111 --Packet Data Normal Call Release 分组数据呼叫，正常释放或休眠


CBSC Release Info (Continued)The “Bad” CFCs. . . CBSC 释放信息（续）异常的 CFC 。。。

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

Analog

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 Limiting

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 Error

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

ReceivedCFC-15 : Negotiation FailureCFC-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注意：还有一个 CFC-255 ，表示不明原因的故障。


CBSC 释放信息（续）异常的 CFC 。。。

无可用资源的 CFCs:CFC-2 : XC 发起的拆线CFC-18 : 没有 XCDR 电路CFC-19 : 没有数据业务电路CFC-20 : 没有可用的无线资源CFC-21 : 请求的中继线路资源不可用CFC-33 : 无线资源不可用，重定向到模拟

无线信号问题的 CFC:CFC-3 : 空中接口二层信令失败CFC-4 : 无线信号丢失CFC-5 : 基站收不到手机发的业务信道空帧CFC-8 : 手机没有进入硬切换目标信道CFC-9 : 呼叫建立过程中未收到 MS 有效语

音帧CFC-10 : 硬切换过程中未收到 MS 有效语音

帧 CFC-13 : CPP 等待服务选择确认超时CFC-29 : 切换过程超时CFC-134 : 呼叫阻塞 -LPA 限

制CFC-135 : 呼叫阻塞 - 前向负载限制CFC-136 : 呼叫阻塞 - 反向负载限制

CBSC 问题的 CFC:CFC-6 : XC 和 BTS 之间不能完成 STRAU

同步CFC-7 : XC 等待 MCC 对手机的检测超时CFC-12 : CPP 呼叫建立超时CFC-60 : BSC 和 MSC 间的协议错误CFC-61 : MM 和 XC 间的协议错误 CFC-62 : XC 检测到错误CFC-13 : CPP 等待服务选择确认超时CFC-70 : 服务配置选定过程失败CFC-80 : MM 内部错误CFC-81 : MM 数据库错误

矛盾问题的 CFCs:CFC-11 : 手机报告的活动集与 XC 中的不一

致CFC-14 : 没有收到足够的手机状态信息CFC-15 : 协商失败CFC-32 : 不可用的服务选择

H/W 失败的 CFCs:CFC-23 : 无线接口失败CFC-52 : BSC 的设备失败CFC-53 : MSC 的设备失败CFC-132 : 目标 BSC 设备失

败

MSC 问题的 CFCs:CFC-26 : 异常的 MSC 发起的拆线CFC-27 : MSC 发起的拆线 /SCCP 连接拒绝CFC-28 : EMX 专用

人为导致的 CFCs:CFC-50 : BSC 级的操作维护干预CFC-51 : MSC 级的操作维护干预CFC-54 : MSC 发起的 A 接口复位CFC-131 : 目标 BSC 级的操

作维护干预

IWU 问题的 CFCs:CFC-100 : 面向电路的 IWU T1.617 建立失败CFC-101 : 面向电路的 CDP T1.617 建立失败CFC-102 : 面向电路的 IWU T1.607 建立失败CFC-103 : 面向电路的 CDP T1.607 建立失败CFC-104 : IWU T1.617 发起的拆线CFC-105 : CDP T1.617 发起的拆线CFC-106 :IWU T1.607 发起的拆线CFC-107 :CDP T1.607 发起的拆线CFC-108 :CPP Inactivity 定时器超时CFC-109 : 数据呼叫失败CFC-112 : 分组数据呼叫建立失败CFC-113 : 分组数据呼叫协议错误CFC-114 : 不能识别的分组数据呼叫释放

注意：还有一个 CFC-255 ，表示不明原因的故障。


CBSC Release Info (Continued) CBSC 释放信息（续）

CFC Count Percentage111 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.

右表显示了在凌晨 4 点左右 KCT F-unit 中取来的 10,000 个呼叫的分布。

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

即使有 64 个不同的 CFC 类，我们通常只看到了具有代表性的其中 15 个。（包括 CFC9 ，虽然 CFC9 没有在这个例子中出现）

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

• 在这 14 个类中， CFC-3, 4, 5, 9, 13, 27, 28, 29, 和 60 是“异常”的。我们将会详细学习这些异常 CFC 。让我们从 CFC-3, 5 和 13 ，无线信号建立失败开始学习。


RF Call Setup & Failure Stages RF 呼叫建立和失败进程

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.

如果 T3230 在 MaxRetry尝试前终止， CFC60 ，如果MaxRetry发生在 T3230 前， CFC3


RF Call Setup & Failure Stages (Continued)CFC-3, RF Layer 2 Failure RF 呼叫建立和失败进程（续） cfc3 ，空中接口二层信令失败

• A CFC-3 is pegged when the base station transmits the maximum number of repeats on the Forward Traffic Channel.

当基站在前向业务信道传输重复发送的最大数时，一个 CFC3就会产生。

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

CFC3 可能发生在呼叫过程中的任何部分（例如：呼叫建立，通话，等等），但通常是出现在呼叫建立阶段

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

重复发送的最大数是用 EDIT XC XCL2PARMS指定的。大部分的 JCDMA 系统使用一个 30 次重试的默认值。重试的时间间隔是从 hard-coded 到 300ms


RF Call Setup & Failure Stages(Continued)CFC-5, No TCH Preamble RF 呼叫建立和失败进程（续） cfc5 基站收不到手机发的业务信道空帧

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

业务信道前同步码是由基站用来检测移动台接上一个业务信道。对于 Rate Set 1 ， TchPAM 由以 9600bps速率传送的 192 个 0 组成。对于 Rate Set 2 ， TchPAM 由以 14400bps速率传送的 288 个 0 组成。

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

EDIT BTS TCHGEN 命令定义了MCCT1 计时器（默认是 5秒） BTS 一给发送移动台发送业务信道分配命令后， MCC就启动这个计时器。当检测到 TchPAM （业务信道前同步码）的时候，计时器就会停止。如果这个计时器终止了，结果就会出现 CFC=5

• The EDIT BTS TCHGEN command also specifies the PAMEBNO (Default = 5.27dB) and PAMIPER (Default=6) parameters. These parameters determine the MCC‘s TchPAM detection sensitivity. Japan ASE experiments have show that CFC-5 rates can be reduced, and overall call completion rates can be improved by lowering PAMEBNO to 4.27 dB.

EDIT BTS TCHGEN 命令同样指定了 PAMEBNO （默认＝ 5.27dB) 和 PAMIPER (默认 =6) 参数。这些参数决定了MCC 的业务信道前同步码的灵敏度。日本的 ASE 实验显示， cfc5 比率可以降低，并且全部的呼叫完成率可以通过把PAMEBNO降低到 4.27 dB 来改善。


RF Call Setup & Failure Stages(Continued)CFC-9, No Valid Speech RF 呼叫建立和失败进程（续） cfc9 未收到有效语音帧

• The EDIT XC XCCPPARMS command specifies the T11 (Default = 14 seconds) timer. EDIT XC XCCPPARMS 命令指定了 T11 （默认＝ 14秒）计时器• 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 在 MM 发送给移动台一个业务信道指派消息后，它会发送一个变码器信道指派消息给变码器。当变码器收到变码器信道指派消息后， T11 计时器启动。如果 T11 计数到 0 并且 1/8 STRAU 在这一次没有被检测到，就会产生cfc9 。

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

如果变码器状态计时器 4 （默认＝ 5秒），“等待有效语音帧”，终止的话，同样会产生 CFC9 。一旦业务信道前同步码被检测到， XCDR将从空闲帧转变成有效帧，同时， cpp 变成 XC CP State 4 （等待有效语音帧），同时启动变码器状态计时器 4 。这一次，一个基站 ACK 命令接着就会送到移动台。在正常情况下，移动台会确认该命令并开始发送 1/8 STRAU 。如果一切正常， XCDR 接着会转变成有效帧。但如果变码器状态计时器 4 终止了，就会产生一个 cfc9

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

前同步码错误。注意到如果EDIT BTS TCHGEN 的参数 TchPAMEbNo 设为一个低值（例如 4.27 dB) CFC9 呼叫会增加，同时 CFC5 呼叫减少。因而当分析呼叫建立失败的时候，考虑总的与无线信号相关的建立失败 CFC (3, 5, 9, and 13) 是很重要的

– Possible bad XCDR card. Note CIC and SPAN. 可能的坏的 XCDR卡，注意CIC 和 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.

CP XC State Timer 4 “等待有效语音帧”设置为低。在 Fukuoka 的 R9.0 FOA 期间，一个坏的 XCDR卡产生很多的假造的干扰。这些干扰使得 CPP cage 控制器负荷过重达到了一个 XCDR 和 KSW连接的要求得不到处理的点，带来了高 cfc9 比率。


RF Call Setup & Failure Stages (Continued)CFC-13, CP Timeout awaiting Service Option ACK RF呼叫建立和失败进程（续） cfc13,CPP 等待服务选择确认超时

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

“EDIT XC XCSOPARMS” 命令定义了 T8 计时器（默认值＝ 5秒）。当 STRAU被变码器检测到后，变码器会发送一个服务连接消息到移动台，同时会启动 T8 计时器。如果 T8 计时到 0 ，并且还没有从移动台收到服务选项确认， CFC3就会产生。

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

另外注意：当 1/8STRAU被成功检测到后， T11继续在计时，如果 T11 在从移动台收到服务选项确认之前计数到 0 ，结果会产生 CFC3

• Possible Problems

可能问题– Verify that the T8 timer is set correctly. Recommended value is 5 seconds.

核实 T8 计时器是不是设置正确。推荐值是 5秒– 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.

RF连接状况。一个呼叫可能会刚刚清除完 CFC5 和 CFC9 ，但接着又产生 CFC13 。查看接入强度字段– 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.

XCDR板显示内部错误告警。检查CIC 和 SPAN 字段去看看一个特定的板是不是与CFC13 有关。在Charlotte Bell Atlantic market 上，人们看到了了CFC13与一个 XCDR板显示内部错误告警对应。

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

可能是 BBX卡坏了。检查 INIT RF CONN BTS, SECTOR, 和 CHANNEL 字段去看看一个特定的 BBX 是不是与高CFC13 比率有关。尝试用一个多余的 BBX 去替换。


CFC-4 : RF LOSS 无线信号丢失

• CFC 4 : RF Loss. Also commonly referred to as “Dropped Call”. CFC 4 : 无线信号（无线信号）丢失，一般也叫做“掉话”

• CFC 4 is perhaps the most closely watched CFC by system operators.

CFC 4 可能是系统操作员最密切注视的 CFC了。

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

通常坏的无线信号状况带来无线信号丢失，但 DELTA BTS SPAN （三角基站间隔）延迟超过 20ms 的话，在很好的无线信号环境下也会带来很高的无线信号丢失比率，后面有更多关于这方面的介绍。


CFC-4 : RF LOSS (Continued) CFC-4 : 无线信号丢失（续）

• 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. 前向链接无线信号丢失：当移动台的前向业务信道衰落计时器终止的时候，一个无线信号丢失会发生在移动台内。前向业务信道

衰落计时器设置每个 IS-95 为 5秒。– Whenever a mobile sees 12 bad frames in a row, he starts his Forward Traffic Channel Fade timer and

stops transmitting.

只要当一个移动台在一行中看到 12 个坏帧后，他就会启动他的前向业务信道衰落计时器同时停止传送– Whenever a mobile sees two (2) good frames in a row, he resets his Forward Traffic Channel Fade timer

and resumes transmitting.

只要一个移动台在一行中看到 2 个好帧后，他就会重置他的前向业务信道衰落计时器同时重启传输。– 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.

如果移动台的前向业务信道衰落计时器运行了 5秒，移动台就会检测无线信号丢失。移动台退出业务信道并且回到空闲状态在寻呼信道上监听

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

Reverse Link RF Loss （反向链接无线信号丢失）：在这种情况下， XCDR检测多余的 STRAU语音帧并且把该呼叫拆线。以下的规则是用来确定无线信号丢失的。

– The EDIT XC XCL2PARMS command specifies LOSSCNT and ACQCNT parameters. EDIT XC XCL2PARMS 命令指定 LOSSCNT 和 ACQCNT参数 – The EDIT XC XCCPPARMS command specifies the XcCpT2 (RF Fade Timer) parameter. EDIT XC XCCPPARMS 命令指定 XcCpT2 （无线信号衰落计时器）参数– If LOSSCNT (Default=6) consecutive erased frames are detected, the XcCpT2

(Recommended Default=10seconds) GPROC timer will start running. 如果 LOSSCNT (默认 =6) 连续抹帧被检测到， XcCpT2 （推荐默认值＝ 10秒）

GPROC 计时器会开始启动– If ACQCNT (Default=3) consecutive good frames are received, the XcCpT2 will be reset,

and the call will continue normally. 如果收到 ACQCNT (默认 =3) 连续好帧， XcCpT2 会被重置，呼叫正常地继续进行– 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. 如果在计时器计时期间收不到 ACQCNT （默认＝ 3)连续的好帧， GPROC 会声明一个无

线信号丢失并把呼叫拆线


CFC-27 : MSC Disconnect with SCCP Connection Refused CFC27MSC 发起的拆线 /SCCP 连接拒绝

• The MSC refused the MM request for an SCCP connection. MSC 由于一个 SCCP连接拒绝MM请求• This can happen "normally" under the following scenario: A Land to Mobile call is placed, and the originating EMX is different from the terminating

EMX. Then, if the Land originator disconnects prior to receiving the DMX paging response, no seize transit trunk message will ever be sent to the terminating EMX. At the terminating EMX, the transit trunk expires, and the SCCP connection refused message is sent to the CBSC. CFC 27 will occur if T3230 (defined by EDIT CBSC-x APARMS3) is still running at the CBSC.

这“通常”可能发生在以下场景：一个陆地到移动的呼叫发生，并且发起的 EMX 不同于终止的 EMX 。那么，如果陆地发起者首先断开连接来接受DMX的寻呼响应，没有抓住传输中继线的消息将永远不会被送到终止的 EMX 。在终止的 EMX ，传输中继线终止，同时 SCCP连接拒绝信息被送到CBSC 。如果 T3230 （由 EDIT CBSC-x APARMS3 定义）继续在 CBSC 内运行， CFC27将会产生

• Possible Problems: 可能问题：

– Check that the terrestrial circuits on the switch are INS. If they are not INS, restore the trunk card. 检查交换机上的陆地电路是否是 INS 。如果他们不是 INS ，恢复中继线卡– Be sure that the mobile has only one MID assigned to it in the switch. 确定移动台在交换机上只有一个相关的 MID 号– Be sure that the Location Area and/or the Registration Zone parameters are set properly. (Display bts-

#secgen) 确定位置地区和 /或寄存器地区参数是否设置恰当（显示 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. 确定所有的陆地电路都在交换机上被使用（例如：非“休眠”）。在 EMX 上使用 REPORT TRUNK

CKT 命令来确定你的交换机是否显示这个问题 – 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. 在一个 CCM交换之后（无需立即），所有的呼叫发起都可能导致CFC27 。 FYI No. EMX-1999.045 详

细解释了该问题及其周围的工作。


CFC-28 : MSC Disconnect with SCCP RLSDCFC － 28 ：（ EMX 专用） MSC 和 SCCP RLSD 断开连接

• The EMX initiated call disconnect with an SCCP RLSD order without using the A+ release and clear procedures. The EMX should never do this, but if it does, the CBSC will end the call with CFC 28.

EMX 发起的呼叫和一个 SCCP RLSD order 断开而没有使用 A+ 释放和清除程序， EMX 应该永远不这样做，但如果它做了， CBSC将会以 CFC28结束该呼叫。

• Can Happen if an Unsolicited Page Ack occurs: 如果一个自发的 Page Ack 出现，可能会发生：

– Mobile is paged on EMX “A” 移动台在 EMX “A” 上 paged

– Mobile hears page on EMX “A”, rescans, and answers page on EMX “B” 移动台在 EMX “A” 上听到 page ，重新扫描，同时在 EMX “B” 上回答 page

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

在 CDL 中查找“ Toy Cell” （ BTS_ID ＝ 500+) 。有时在 MTSO附近的人（有几个 EMX ）可能从一个 co-located “Toy Cell” 看到无线信号，很可能导致一个自发的 Page 确认。


CFC-29 : Handoff Procedure Timeout 切换过程超时

• This is a failed pilot beacon or DAHO hard handoff. 这是一个失败的导频信号或者DAHO 硬切换

• CFC 29 is almost identical to CFC 8, but is triggered by a different timer. There are two timers of interest:

CFC 29 与 CFC8 最几乎一样，但区别是由不同计时器触发。有两个重要的计时器：– The CBSC APARMS t9ap A+ timer (8.0 seconds)

CBSC APARMS t9ap A+ 计时器（ 8.0秒）– The XC XCHOTIMERS XcHoT6 timer (6.5 seconds)

XC XCHOTIMERS XcHoT6 计时器（ 6.5秒） – Both timers start when the target BTS indicates it has a traffic channel ready for hard handoff.

两个计时器都在目标 BTS显示其会有一个业务信道为硬切换准备好的时候而启动– 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.

如果目标 BTS 没有检测到移动台接上业务信道，上述两个计时器之一就会终止。如果 A+ 计时器先终止， CFC29出现，如果， XcHoT6 计时器先终止， CFC8就会产生。注意如果 A+ 计时器设置得比XC 计时器的时间长的话，只有 CFC8 会出现。

– KCT F-unit has A+ timer set at 6 seconds -> No CFC 08, instead we see CFC 29.

KCT F 单元将 A+ 计时器设置在 6秒－ > 不会有 CFC08 ，取而代之的是我们看到 CFC29


CFC-60 : Protocol Error between BSC and MSCCFC-60BSC 和 MSC 间的协议错误

• The CBSC or MSC detected an A+ protocol error associated with the call. The EDIT CBSC-x APARMS3 command sets the T3230 timer. This timer is typically set to13 seconds, and specifies the maximum time to complete A+ call setup procedures between the CBSC and EMX. If this timer expires, CFC 60 is generated.

CBSC或者MSC 在呼叫中检测到一个 A+协议错误。 EDIT CBSC-x APARMS3 命令设置 T3230 计时器。典型地，这个计时器设置为 13秒，并且指定完成在 CBSC 和 EMX之间的 A+ 呼叫建立过程最长时间。

• Possible Problems 可能问题– The land party disconnects his call at the EMX side before the call is set up completely. 陆地部分在呼叫完全建立之前断开在 EMX侧断开连接– The Mobile‘s ESN doesn’t match in the subscriber file of the EMX. 移动台的 ESN 和 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.

在 EMX 间的传输中继线出现问题。例如，没有可用的传输中继线。（这种情况下 LMSSE 会等于 1 ）。如果当 EMX 放弃尝试建立传输中继线， EDIT CBSC-x APARMS3 计时器 T3230 仍然继续运行，随之有一个 CFC27产生。

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

在 EMX 中核实没有 TERCK出于“ hung” （挂起）状态。在 R9.0 FOA in Fukuoka 期间，一个 QCT操作员偶然会 simplexed 活动呼叫管理器，使到中继线状况恶化的信息从一个待命呼叫管理器那里被复制。大多数的 TERCKT 以一个挂起状态结束，仅留下少数好的电路。由于呼叫数比好的电路多，因而所有没有分配到好的电路的呼叫都会以 CFC-60 失败。双方可以重置呼叫管理器来清除这个问题。

– The DMX link for remote validation could be down, or remote validation could be taking too long. 对远端确认的 DMX 链接可能关闭，或者远端确认可能耗时过长– 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. 核实 MM 和 EMX 点以 CDF编码设置正确。注意：即使他们设置错误， A+ 链接仍会从 EMX 和 MM方面在服务上显示。– Verify that there are not multiple ESNs assigned to the same MIN. (More than 1 phone with the same number.) 核实没有多个 ESN 分配给同一个 MIN （超过一个电话有同样的号码）– Verify that the CP TRKMAP entries on the two switches connecting the transit trunks are consistent. 核实 CP TRKMAP 进入传输中继线两端的交换机是一致的。


CBSC Release Info (Continued)CBSC 释放信息（续）

• Release_Time : Tells us when the call ended 释放时间：表明呼叫结束时间

• XC_Release Time : The transcoder (XC) keeps an internal clock that increments every 20mS. Call ended on this clock tick.

变码器释放时间：变码器（ XC ）有一个每 20ms跳一次的内部时钟。呼叫以这个时钟标记结束。

– 20mS is the time duration of a CDMA frame. 20ms 是一个 CDMA 帧的持续时间– Reported in Hexadecimal 以 16 进制报告– 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.

这个例子告诉我们最后从移动台来的 PSMM （导频强度测量消息）发生在呼叫结束前 10秒



• Init_MM_Rel_Event : (IMMRE) Tells us what event triggered the Mobility Manager to Release the Call. Init_MM_Rel_Event : (IMMRE)告诉我们是什么事件触发移动管理器去释放该呼叫。

– 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. 注意： IMMRE=5 通常表示“坏”，但对于Inter-CBSC锚切换， IMMRE=5表示“好”－－移动台可能把它认作目标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=17时，目标CBSC上应该会产生一个CFC-8或29的CDL，同时源CBSC上产生一个CFC-30。

IMMRE Meaning1 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. Init_Disc_Cause_Type & Init_Disc_Cause ：告诉我们一个呼叫是如何结束的。

• Provides almost identical information as CFC! (But harder to read ) 提供了几乎和 CFC 同样的信息（但更难阅读）

• Sometimes provides more information than the CFC code. For this reason, developers prefer to look at Init_Disc_Cause (IDC) when investigating problems.

有时提供比 CFC 码更多的信息。由于这个原因，开发商在研究问题的时候更喜欢查看 Init_Disc_Cause (IDC) – 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!)

例如： R9 数据呼叫。 CFC111 表示“好的分组呼叫”，但当 R9写出来后，他们就没有时间去创造更多的详细的 CFC了

– So for Packet Data calls, you need to look at the IDC to tell whether the call was really OK or not. . .

对于分组数据呼叫也一样，你需要查看 IDC 来判断呼叫是不是 OK . . .• Good Packet IDCs : 好的分组 IDC 0x1100, 0x1802, 0x1910• Bad Packet IDCs: 坏的分组 IDC0x1801, 0x1809



• Init_Disc_Cause_Type : Tells us which interface link a disconnect event occurred. 1=SCAP, 2=A-plus, 3=A-plus Layer 3. Init_Disc_Cause_Type : 告诉我们（表明）哪一个接口链接发生了断开事件。 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: 如果 Init_Disc_Cause_Type = 0 ，这表示“非 A+, 非 SCAP, 无可用 Init_Disc_Cause ” 。然而，在大多情况下，它会发生在下列两种情况：

– The EMX kills the SCCP connection underneath A+ ( CFC 27 and 28 ) 在 A+协议下， EMX取消了 SCCP连接。– Hard-Handoff occurs (CFC 24 and 30) 发生硬切换（ CFC24 和 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.

Init_Disc_Cause :连接断开的原因代号。再次，很像CFC ，但它也可以从中找到到达或者来自 CBSC 的内部消息，这些 Init_Disc_Cause 编码可以直接观察

Aplus (2)

Aplus L3 (3)

SCCP (0?)

SCAP (1)

LAPD

EMX CBSC BTS



• The Most Famous Initial Disconnect Cause (IDC) Codes: 最有名的初始（连接）断开原因（ IDC ）编号：

IDC Link Meaning CFCs Percentage0x1100 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 : This tells us which target BTS and Sector the mobile should go on a Hard Handoff

HHO_TGT_CellID （硬切换目标蜂窝 ID ） : 表明在硬切换时移动台应该切换到哪一个目标 BTS 和扇区– Bits 0-3 : Sector in Hexadecimal 0-3 比特：十六进制表示的扇区– Bits 15-4: Cell Number in Hexadecimal 15-4 比特：十六进制表示的蜂窝号码– Example : 0x1276 > 0x127 & 0x6 : 0x127 = Cell 295 : 0x6 = Sector 6– Caution : This mapping is different from the format used in the XCSECT

database : 警告：这个映射不同于在 XCSECT 数据库使用的格式• Bits 0-2 : Sector Bits 15-3 : Cell• Yes, its confusing. But “Off by One” discrepancies are occasionally

seen in Complex Software Systems. . . 0-2 比特：扇区 15-3 比特：蜂窝。是的，有点混乱。但“ Off by One” 矛盾偶尔会在综合的软件系统中出现

– Set only in CFC-24 and 30 calls. Equals 0xffff otherwise. 仅仅在 CFC24 和 30 呼叫中规定，其他的等于 0xffff 。


Hard Handoff Target Info 硬切换目标信息

• HHO_Tgt_MM_Addr : Tells us which MM the mobile should go for an Inter-CBSC Anchor Handoff. HHO_Tgt_MM_Addr : 表明对于一个 CBSB 内部的锚切换，移动台应该切换到哪一个 MM 。

– Set only for CFC-30 calls, contains 0x00 otherwise. 仅仅为 CFC30 的呼叫中规定，其他的就是 0x00

• 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_Switch : 假设告诉我们一个硬切换的目标 EMX 。没有真正工作，为 CFC24 和 30 设为 0x00 ，其他的HHO_Tgt_Switch 设为 0xff 。

• 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_MCC1,2,3 ：这个是移动国家编号。不是一个硬切换目标的 MCC卡。为 CFC24 和 30 硬切换呼叫设为“ 0x04”,”0x04”, 和 “ 0x00” （日本的国家编号是 440) 。其他的设为“ 0xff”,”0xff”, 和 “ 0xff”

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

HHO_Tgt_MNC1,2,3 ：这是关于一个硬切换目标的移动网络编号。表明移动台切换到哪一个 CT 。例如：– KCT = “0x01”, “0x07”, “0x0f” (MNC = 0x17f) OCT = “0x00”, “0x08”, “0x0f” (MNC

= 0x08f)– HCT = 0x3f Set to “0xff”, “0xff”, “0xff” for non-Hard Handoff CDLs 对无硬切换的 CDL 设为“ 0xff”, “0xff”, “0xff”

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

HHO_Tgt_LAC:这是一个硬切换目标区域编号。与目标蜂窝的寻呼 /寄存器地区相关。对无硬切换的 CDL 设为“ 0x00”


N-Way Stats N － Way 统计

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

N_Pilot_Count (N=1..6) –这些计数器表明一个呼叫在每一个 6种可能的 N-way 状态出现了多少次。• Initial 1-way after assignment is not reported -- ALL CDLs start in one way, so we know this count

is always 1.

在任务没有被报告后的初始 1-way －－所有 CDL 以一种方法开始，所以我们知道这个数总是 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.

这个呼叫结束状态为 MAHO 3-way ，在这之前其处于 MAHO 2-way 状态，并且有一个 double-drop 。我们怎么会知道？后面将会有介绍。

Initial1-way

1-wayMAHO2-way

MAHO3-way

MAHO4-way

MAHO5-way

MAHO6-way

1 2

3 13

11

1


N-Way Stats (Continued) N 路统计（续）

• The N-Pilot Counters have an upper limit of 15: N-Pilot 计数器的上限是 15

ONEPILOT

COUNT

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.

我们知道这个呼叫在 2-way 和 3-way 中至少出现 15 次，但实际的数字可以是任意大于或等于 15 的数

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

LOC_S_ADD_COUNT & LOC_SR_ADD_COUNT 这些计数器告诉了我们在这个（本地） CBSC 控制下的各 BTS上所作的软（新 walsh 码，不同信道元件）和更软（新 walsh 码，相同信道元件）切换增加的总数。

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

EXT_S_ADD_COUNT & EXT_SR_ADD_COUNT : 这些计数器告诉了我们在连接 Inter-CBSC 的邻（外部） CBSC 所做的软和更软增加的数目



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

加入 LOC_S_ADD_COUNT, LOC_SR_ADD_COUNT EXT_S_ADD_COUNT & EXT_SR_ADD_COUNT 给了我们在这个 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.

• 掉线计数器： LOC_S_DROP_COUNT, LOC_SR_DROP_COUNT EXT_S_DROP_COUNT & EXT_SR_DROP_COUNT这些计数器给了我们关于在一个 CDL 期间本地软，本地更软，外部软，外部更软撤销总数

– Adding the Drop Counters gives us the Total Number of Drops done during the CDL

加入撤销计数器给了我们在该 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.

警告：和 N 路计数器一样，增加和撤销计数器的最大值是 15 。如果这些计数器设为 15 ，我们并不能知道实际增加或撤销的数目：我们只知道那数字至少是 15 。



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

N 路计数器和增加 /撤销计数器之间的联系：总数应该总是一样的。例如：

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总计： 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.

Release_L_WC and Release_E_WC : 告诉我们在呼叫结束时分配的本地和外部Walsh 码（导频）。在这个呼叫中是 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.

所有呼叫从 1-way 状态开始，这里， 1 + Adds - Drops = 1 + 8 - 5 = 4 。但呼叫结束在 3-way 而不是 4-way 。所以我们知道有一个 double drop 。



• Last_MAHO_ActN_Bts (N=1..6) : Tells us the Active BTSes before the Last Soft Handoff of the CDL. 0 = No BTS Last_MAHO_ActN_Bts (N=1..6) : 表明在CDL中最后软切换之前的活动BTS。0=没有BTS

• Last_PSMM_ActN_Bts (N=1..6) : Tells us the Active BTSes after the Last Soft Handoff of the CDL. 0 = No BTS Last_PSMM_ActN_Bts (N=1..6) : 表明在CDL中最后软切换之后的的BTS。0=没有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.)

在这个例子中，最后一个切换转变是在459站加入另外一个Walsh码，从2-way变到3-way。（这是一个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.

Init_MAHO_CandN_Bts (N=1..3) : 表明 CDL 中移动台想要增加的第一个 BTS 。

• In this example, the mobile started on BTS 459, and asks to add another BTS 459 Walsh Code (Sector) to his Active Set.

在这个例子中，移动台在 459 号 BTS开始，并且要求增加另一个 459 号 BTS 的 Walsh 码（扇区）作为他的活动调整

• First SHO Result : Tells us whether or not this handoff was executed. 第一个 SHO结果：表明这个切换是否被执行：

– 1 = Handoff Executed 1 ＝切换被执行– 2 = Handoff Not Executed 2 = 切换没有被执行– 0 = Call Disconnected before Decision could be made 0= 做出决定前呼叫连接已断开

• 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

在这个例子中，我们看到切换能执行，并且相应的第一个 N-way转变是从 1-way 到 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. 集合整理一个 N-way转变历史图表有几分困难。即使 CDL 没有告诉我们发生过的每一个切换，通常还是有足够的

信息去集合整理一个关于发生了什么事件的准确的图表的

• Zero Values in N-way statistics are also very informative.

N-way 统计表中的 0值也包含着很多信息– Most calls never go into 1-way. This means RF is good

大多数呼叫从未进入过 1-way ，这表示RF良好。– We see that the chance of RF Loss goes up nearly 5X for calls that

enter 1-way

我们看到无线信号丢失的机会对于进入 1-way 的呼叫上升了将近 5X– Most calls never go into 5-way or 6-way. This means WC and CE

are being used efficiently

大多数的呼叫永远也不会进入 5-way 或者 6-way 。这意味这WC 和CE正被有效地使用

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 RateCalls 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 with Release_L_WC and Release_E_WC to calculate Soft and Softer Handoff Factors: Release_L_CE & Release_E_CE : 在 CDL 的末尾告诉了我们有多少本地（同一 CBSC ）和外部（ Inter CBSC SHO ） MCC 信道元件在使用。可以和 Release_L_WC 与 Release_E_WC 结合使用来计算软和更软切换因数。

RELEASEL_CE

Calls withCount

WeightedCount

RELEASEE_CE

Calls withCount

WeightedCount

TotalWeighted

Count0 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 1386Average Channel Element/ Call : SOFTER HANDOFF FACTOR - > 1.386

RELEASEL_WC Count

WeightedCount

RELEASEE_WC Count

WeightedCount

TotalWeighted

Count0 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 2095Average Walsh Codes/ Call : SOFT HANDOFF FACTOR - > 2.095

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

使用更软切换因数去为一个系统设计MCC卡的数目

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

使用软切换因数去估算使用的 Walsh码的总数

• System Engineering Design Guidelines :

系统工程设计指导：更软切换因数＝ 1.5 软切换因数＝ 2.5

Softer Handoff Factor = 1.5. Soft Handoff Factor = 2.5

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

左表中的数据来自 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. Num_SR_Shuffle : 这是一个 Softer shuffle 在 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).

EDIT CBSC HOCONSTR 定义了MaxBTSLegs 参数（当 1或 2 个 BTS 进行 SHO （软交换）的时候默认值＝ 3 ，当有3geBTS 进行 SHO 时，默认值＝ 3 ）

– If a Softer Add would cause MaxBTSLegs to be exceeded, the weakest pilot at that BTS replaced with the new one. 如果一个 Softer Add 会导致MaxBTSLegs溢出，在 BTS 最弱的导频会由一个新的替换。– Happens in roughly 1.2 percent of calls. ( Source: KCT F-unit ) 大约在 1.2% 的呼叫会发生（来源： KCT F-unit )

• Num_BTS_Shuffle : This is the number of times a BTS shuffle occurred during the CDL. Num_BTS_Shuffle :这是在该CDL 期间一个 BTSshuffle出现的次数。

– EDIT CBSC HOCONSTR defines the parameter MaxCEPerCall (default=3). Means same thing as “Maximum Cell Sites per Call”.

EDIT CBSC HOCONSTR 定义了MaxCEPerCall参数（默认＝ 3 ）。表示和“每一个呼叫的最大蜂窝站点数”一样的东西– If a Soft Add would cause MaxCEPerCall to be exceeded, the weakest BTS is replaced with the new one. 如果一个 Soft Add 会引起 MaxCEPerCall溢出，最弱的 BTS 会被一个新的替换– Happens in roughly 1.5 percent of calls. ( Source: KCT F-unit ) 大约在 1.2% 的呼叫会发生（来源： KCT F-unit )

• Num_S_Shuffle : This is the number of times a Soft shuffle occurred during the CDL.• Num_S_Shuffle ：这是在该CDL 期间一个 soft shuffle出现的次数

– EDIT CBSC HOCONSTR defines the parameter MaxActSetSz (default=6). EDIT CBSC HOCONSTR 定义了MaxActSetSz 参数 (默认=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 ) 如果一个软或者更软 Add 会引起 MaxActSize溢出，最弱的 Walsh 码会被撤销同时一个新的码加进来。几乎从来没有出现过（来源： 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. Num_SHO_Failures :这是在一个 CDL 中软 / 更软切换的失败次数。发生在大约0.3% 的呼叫里当有 SPAN DELAY 问题时会爬升到一个高值。如果在 LAST_SHO_BTS 和任何LAST_MAHO_Act_BTS之间的三角延迟大

于 20ms 时，软增加很可能会失败，同时很可能发生一个无线信号丢失Last SHO Fail Reason

5120 No MCC Response (Check SPAN DELAY!)5121 MS Did Not Accept Handoff5122 No MS Response (Check SPAN DELAY!)5123 No Handoff Recognized5125 No MM Response5127 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_Cause : 这个编码表明了最后的软切换失败的原因。很多 5120或者 5122 的话就间接表明发生一个 DELTA SPAN DELAY 问题

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

Last_SHO_Fail_Time : 表明最后的软切换失败的时间。如果这个值总是发生在一个特定站点上的一个无线信号丢失引发的释放时间的几秒钟内，始终要猜测在该站点可能存在一个 DELTA SPAN DELAY 问题。

• 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

特别注意：切换失败并非和切换阻塞一样。一个切换失败是当系统批准了一个切换，但没有成功的时候才出现的。一个切换阻塞是当移动台发起请求，但被系统拒绝了的时候而发生的



• Last_HO_Blocked_Cause (LHOBC): This code tells us why the System decided not to allow a Handoff requested by the mobile:

Last_HO_Blocked_Cause (LHOBC): 这个编码表明为什么系统不允许由移动台请求的切换

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

如果有许多 LHOBC ＝ 7 ，进行过滤并看他们的无线信号丢失对比其他呼叫是不是高了。如果正是这种情况，你应该考虑提高在 EDIT CBSC HOCONSTR 表里定义的 Aggr_Active_Set_Strength 阈值

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

35% 的阻塞的切换是由于 LHOBC=7引起的（来源： KCT F-unit ) • 26% are Blocked because no more than 3 BTSs can be added.

(LHOBC=14)

26%阻塞是由于不多于 3 个 BTS 可以加进来。 (LHOBC=14)• 20% are Blocked because no more than 3 sectors at a site can be added.

(LHOBC=13)

20%阻塞是因为在一个站里没有 3 个扇区可以加进来。 (LHOBC=13)• 18% are Blocked because the Mobile is reporting a Pilot not in the

Neighbor List. (LHOBC=5)

18% 的阻塞是因为移动台在报告一个不在邻居列表上的导频。 (LHOBC=5)• 0.75% are Blocked because the call is in 6-way. (LHOBC=15) 0.75%阻塞

是因为呼叫处于 6-way. (LHOBC=15) • 0.25% are Blocked by the EMX (LHOBC=2)

0.25%阻塞是有 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)



• 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_Time : 表明最后阻塞的切换发生的时间。如果一个切换阻塞被怀疑是一个呼叫掉线的起因，请与Release_Time对比阻塞时间来看看两个时间点是否在彼此的附近

• 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.• Last_HO_Block_PN : 表明被拒绝切换的导频的PN偏置量。如果因为LHOBC=5 （PN不在邻居列表）而使到有很多切换被阻塞，一定要检查这个字段。这个信息可以用来制作更好的邻居列表。

– The CDL does not tell us the active set at the time of Blocked Handoff. CDL没有告诉我们在切换阻塞时刻的活动set– But, we can often accurately guess the active set if the Last_HO_Block_Time is near either the Access_Time or Release_Time. 但我们经常可以正确推测活动调整如果Last_HO_Block_Time 在Access_Time 或 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. 如果阻塞时间在CDL开始的附近，查看Init_RF_Connect_BTS 和Init_MAHO_Cand_BTS– 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. 如果阻塞时间在CDL末尾的附近，查看Last_RF_Connect_BTS, Last_MAHO_Act_BTS 和Last_PSMM_Act_BTS.



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

Last_SHO_Time （最后软切换时间）：表明最后的软切换尝试的时间，不管该切换是否成功，阻塞或者失败。

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

总是检查这个字段，并且在如果怀疑有 SPAN DELAY 问题的时候，拿来和释放时间对比。

• Last_SHO_Cause & Result : These tells us the type and result of the final Soft Handoff attempt. Last_SHO_Cause & Result （最后软切换起因及结果）：表明最后的软切换尝试的类型和结果

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

Last_Post_SHO_Agst （最后提交的软切换 Agst ）：非常重要的字段，表明作为完成最后异彩软切换的结果，移动台应该接收到的下行链路信号的质量（合计强度）。

– ALWAYS CHECK when investigating dropped calls. 当调查掉话时总要检查这字段。– THE FORMULA : Mobile RX Ec/Io = - (Last_Post_SHO_Agst / 2) 公式： 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 Meaning0 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

Result Meaning0 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…)

Shuffle_Type : 表明最后的软切换是否是一个 shuffle操作（在 KCT F-unit （统计中），每 70 次切换中仅有一次发生 shuffle ）

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

Last_SHO_Num_Sect_Det & Exec :这些（字段）表明在最后的切换中增加（或者撤销）的导频数目。 “ Det” 指的是检测到的导频数目， “ Exec”指的是处理的导频的数目。两者应该总是一样的

– Special Note: Sometimes there will be a non-Zero Last_Sho_Time with 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)

特别注意：有时会出现一个无 0 的 Last_Sho_Time 伴随着0 Det” 和“Exec” 字段，并且没有 PSMM 记录。这些是从没有发生切换但却增加了补充信道的 HSPD 呼叫。

• Last_SHO_MMAddr_BTS/Sector/MCC/Element - These fields identify the final channel element being added/dropped. Last_SHO_MMAddr_BTS/Sector/MCC/Element – 这些字段确定了最后被增加 /撤销的信道元件

ShuffleType Meaning

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 StatsCBSC 内部软切换统计

Target CSBCSource (Anchor) CSBC

Remote Legs

EMX Local Leg

IC-Span

Target CBSC AreaSource (Anchor) CBSC Area

• Picture Overview of Inter-CBSC Soft Handoff CBSC 内部软切换的纵览图

Note: Anchor Hard Handoff occurs after ALL legs are

Remote. 注意：锚硬切换在所有 leg都在远端（非本地）之后


Inter-CBSC Soft Handoff Stats (Continued)CBSC 内部软切换统计（续）


Remote Leg

EMX Local Leg

IC-Span

Target CBSC Area目标 CBSC 区域

Source (Anchor) CBSC Area源（锚） CBSC 区域

• An IC-SHO BEGINS when the first remote leg is added. 当增加第一个远端 leg 后，一个 IC 软切换就开始了




Remote Leg

EMX Local Leg

IC-Span

Target CBSC Area目标 CBSC 区域

Source (Anchor) CBSC Area源（锚） CBSC 区域

• An IC-SHO ENDS when the mobile makes a U-turn and last remote leg is dropped. 当移动台做了一个 U 型掉头，同时远端 leg 断开的时候，一个 IC 软切换结束

Cut!Cut!

Cut!



New Source (Anchor) CSBCOld Source CSBC

New Local Leg

EMX Old Local Leg

IC-Span

New Source CBSC Area新的源 CBSC 区域

Old Source CBSC Area旧的源 CBSC 区域

• An IC-SHO DISCONNECTS when Anchor Handoff (or Hangup) Occurs• 当发生锚切换（或者挂起）的时候，一个 IC 软切换断开

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

pilots. 注意：锚切换是一个硬切换。之后呼叫立刻处于 1-way 状态，然后就可以重新增加导频了

Cut!Cut!

Cut!Cut!

Cut!



CBSC “B” Area CBSC”B” 区CBSC “A” Area CBSC”A” 区

• Because of RF Overlap, CBSC and Anchor Boundaries are Different. 由于无线信号重叠， CBSC 和 Anchor 的边界是不同的

CBSC Boundary CBSC边界

/ IC-SHO ZONE / IC 软切换地带

A->B Anchor Handover BoundaryA->B锚切换边界

B->A Anchor Handover BoundaryB->A锚切换边界



• CDL contains ICSHO “Begin” and “End” Records CDL 中包含 IC 软切换“开始”和“结束”记录• These are not “First” and “Last” Records, instead they work as follows: 这些不是“最先”和“最后”的记录，实际上他们的运作如下：

| ICSHO Zone |

^

CBSC Boundary

Generate ICSHO Begin Record发生 IC 软切换，开始记录Generate ICSHOEnd Record 发生 IC 软切换，结束记录

OVERWRITE ICSHO Begin Record盖写 IC 软切换，开始记录

OVERWRITE ICSHO End Record盖写 IC 软切换，结束记录

| ICSHO Zone |

^

CBSC Boundary

Generate ICSHOBegin Record发生 IC 软切换，开始记录

Generate ICSHO End Record发生 IC 软切换，结束记录

OVERWRITE ICSHO Begin Record盖写 IC 软切换，开始记录

CLOSE CDL 关闭 CDL

| ICSHO Zone |

^

CBSC Boundary

Generate ICSHOBegin Record发生 IC 软切换，开始记录

CLOSE CDL NO END Record!

关闭 CDL ，无结束记录

Case 1: Both “Begin” and “End” Records describe the final Inter-CBSC Soft Handoff 例 1: 同时具有开始和结束的记录描述最后的 CBSC 内部软切换

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

例 2:结束记录描述“第二到最后”的 cbsc 内部切换。开始记录描述了最后的情况

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

例3:开始记录描述了最后的 CBSC 内部软切换。结束记录为空白（全0)

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





• ICS_Begin_Time & ICS_End_Time : Tells us when the last “Begin” and “End” ICBSC Handoff events occurred.

ICS_Begin_Time 和 ICS_End_Time : 表明最后开始和结束的 ICBSC 切换事件出现时间。– If End_Time < Begin_Time, it’s a Case 2 call --------------------->如果 End_Time < Begin_Time ，这是第二种情况的呼叫。

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

如果 End_Time 和 Begin_Time ＝ 0 ，呼叫不可能发生 CBSC 内部软切换

– If Begin_Time is set, but End_Time is 0, it’s a Case 3 call ---->如果 Begin_Time 调整了，但 End_Time 为 0 ，就是第三种情况的呼叫

– (On the KCT F-unit, only 1 in 9 calls does Inter-CBSC Soft Handoff). ( 在 KCT F-unit 统计中 , 每 9 个呼叫中只有一个会发生 CBSC 内部软切换 ).

| ICSHO Zone |

^

CBSC Boundary

| ICSHO Zone |

^

CBSC Boundary



• ICS_Begin_Tgt_MMAddr & ICS_End_Tgt MMAddr : Tells us the adjacent CBSC going into Soft Handoff.

ICS_Begin_Tgt_MMAddr 和 ICS_End_Tgt MMAddr : 表明进入到软切换中的邻CBSC

– For Case 1 “U-turn type” Soft Handoffs, “Begin” and “End” MM will always be the same.

对于例 1 的“ U 型掉头类型”的软切换，“开始”和“结束”的 MM （移动管理器）总是一样的

• 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_BTS 和 ICS_End_Tgt_BTS : 表明当移动台进入 IC 软切换地带时加入的 BTS 和当移动台离开 IC 软切换地带时删除的 BTS

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

ICS_Begin_Tgt_Sector 和 ICS_End_Tgt_Sector : 表明当移动台进入 IC 软切换地带时加入的 BTS扇区和当移动台离开 IC 软切换地带时删除的 BTS扇区

– “Begin” and “End” BTS-Sector are sometimes the same (especially for short Inter-CBSC handoffs) and sometimes different.

开始和结束的 BTS扇区有时候是一样的（尤其对于短的 CBSC 内部切换），有时候是不同的

| ICSHO Zone |

^

CBSC Boundary CBSC边界



• 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_BTS 和 ICS_End_SrcN_BTS (N=1 or 2) : 告诉我们当一个 CBSC 内部切换开始和结束时，在源（锚） CBSC里的一个或者两个 BTS

• ICS_Begin_SrcN_Sector & ICS_End_SrcN_Sector (N=1 or 2) : Tells us the sectors of the above BTSes.

ICS_Begin_SrcN_Sector 和 ICS_End_SrcN_Sector (N=1 or 2) : 告诉我们上述 BTS 的扇区。

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

在 KCT F-unit 统计中，每 3 个 CBSC 内部软切换中有 1 个在源侧仅有一个 BTS扇区。

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

ICS_Begin_Src_Count 和 ICS_End_Src_Count :开始计数告诉我们在呼叫进入 CBSC 内部软切换状态之前的 N-way 状态。结束计数告诉我们在一个“ U 型掉头类型”的 CBSC 内部软切换之后，源侧的 N-way 状态

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

End Count =0 表示出现锚切换（之前没有任何 U-turn CBSC 内部软交换）。

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



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

FOREIGN PILOT FEATURE –这个特征支持在 CBSC 内部软切换期间对外部导频的处理。– 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.

一旦移动台进入 CBSC 内部切换， CBSC就会给移动台作一张邻居列表，这个列表是源邻居列表和目标 BTS 列表的的混合。

– Foreign Pilots can occur when the target BTS neighbor lists contains cells (Pilots) not listed in the source (anchor) BTS lists.

当目标 BTS邻居列表包含没有在源（锚） BTS 列表中列出的蜂窝（导频）时，外部导频可以出现。

– Note that for this feature to work, there must be InterCBSC trunk connections between the “Foreign Pilot” CBSC and Anchor (Source) CBSC.

注意对于工作中的这个特征，一定会在“外部导频”CBSC 和锚（源） CBSC之间有CBSC 内部中继线连接

– Introduced in Release 8.1 在 8.1版本中有介绍。



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

ICS_Begin_Tgt_Count 和 ICS_End_Tgt_Count :开始计数告诉我们当一个CBSC 内部软切换启动的时候，在目标侧加入的导频数目。结束计数告诉我们在一个“ U-turn type” 的 CBSC 软切换完成后，目标侧的撤销的导频数。

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

End Count ＝ 0 表示出现锚切换（之前没有任何的 U-turn CBSC 内部软切换）

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

ICS_Count : 表明呼叫进入 CBSC 内部软切换模式有多少次。计数到 15就停止• ICS_CBSCs : Tell us how many different target CBSCs were used by the call.

Counts up to 15 and stops. ICS_CBSCs : 表明呼叫使用了多少个不同的目标 CBSC 。计数到 15就会停止

ICS_BEGINTGT_COUNT Percentage

1 98.62 1.4

Total 100ICS_END

TGT_COUNT Percentage0 69.61 302 0.4

Total 100ICS_COUNT Percentage

1 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.1Total 100

ICS_CBSCS Percentage1 96.92 3.1

Total 100



• FOREIGN PILOT FEATURE - Only rarely used! • FOREIGN PILOT FEATURE －仅在少数情况下使用

– In KCT Funit, only 1 out of 9 of Calls go into Inter-CBSC Soft Handoff 据 KCT Funit 统计，每 9 个呼叫中有 1 个会进入 CBSC 内部软切换– Of these calls, only 1 out of 80 calls generate neighbor lists with FOREIGN PILOTS 在这些呼叫当中，每 80 个呼叫中只有 1 个会产生有外部导频的邻居列表– Of these FOREIGN PILOT calls, only 1 out of 5 calls get a FOREIGN PILOT add attempt. 在这些外部导频的呼叫中，每 5 个呼叫中只有 1 个有增加外部导频的尝试– In summary, that’s only 1 in 3600 calls! 总计起来，每 3600 个呼叫中只有 1 个！– 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_Tgt_MMAddr/Bts/Sector –这三个字段告诉了我们 MM ， BTS ，和候选的外部导频扇区。• 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_SrcN_BTS/Sector (N=1 or 2) –这些字段告诉我们当外部导频报告上来的时候，在源（锚）侧的一个或两个基站和

扇区



• ICS_FP_Time - This is the time the most recent FOREIGN PILOT was reported in the call. ICS_FP_Time –这是在呼叫中最新的外部导频报告的时间。

– 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_Begin_Time. 一样，这几乎总指示着： TARGET XCSECT 的邻居列表包含一个没有出现在 SECTOP邻居列表中的入口（ entry ）。

这不一定代表“坏”。然而，如果你看到一大堆这些东西，你可能会考虑更新源 SECTOP 列表，来把这个导频加进去。

• 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_Tgt_Count －这字段告诉我们有多少个外部导频加入到 CBSC 内部软切换中。但它看起来总是对每一个呼叫都就外来报告的设为 0 。这字段是否没有被正确 peg 呢？或者外部导频从没有被增加？

• 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_Src_Count –这个字段看起来是无命名的。这个计数器似乎对源和目标导频都计数，而不是在一个外部导频事件发生时刻报告 N-way 源导频的数目。（我们有时在这里会看到“ 6” ，如果只有一个源导频被计数，这是可能的。如果有 6 个源导频和 1 个或者多个目标导频， MaxActiveSet=6 被干扰）

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

ICS_FP_Att – 当一个呼叫处于 CBSC 内部软切换状态的时候，这个字段计算尝试增加一个外部导频的次数，


Last RF_Connect, MAHO, & PSMM Sites 最后无线信号连接， MAHO ， PSMM Sites

• These are BTS sites involved at the end of the call. WHATS THE DIFFERENCE?

这些是在呼叫末尾相关的 BTS 。区别是什么？

• Some pictures will help. . . 下面的图片可以帮助理解 . . .

Site “A”

• Here the call starts and ends using only Site “A”

• The mobile never reported any other candidate pilots

这里，呼叫开始和结束都使用站点 A

移动台从不报告任何别的候选导频• Last_RF_Conn_BTS1 = “A”

• Last_MAHO_Act_BTS1 = NULL

• Last_PSMM_Act_BTS1 = NULL


Last RF_Connect, MAHO, & PSMM Sites 最后无线信号连接， 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)

（ B 比 A离呼叫近，所以把 B 列为 conn1 （首选连接））• Last_MAHO_Act2_BTS = A, Last_MAHO_Act1_BTS =B

– (B was stronger than A, so B was listed as Act1)

（ B 信号比 A强，所以 B 列作 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.)

• （作为最后 PSMM 的结果， A断开了，只剩下 B ）• Last_SHO_BTS = A

– (Last SHO event was to drop A) （最后软切换事件是断开 A ）

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

Site “A” Site “B”

Step 1) Mobile Starts call on Site “A” 步骤 1 ）移动台在 A 站开始呼叫

Step 2) Mobile Sends in a PSMM indicating he wants to Add Site “B”. Site “B” is added.Signal from “B” is stronger.步骤 2 ）移动台在一个 PSMM 中发送其想加入 B 站的指示。 B 站加入。从B 来的信号更强。

Step 3) Mobile Sends in a PSMM indicating he wants to Drop Site “A”. Site “A” is dropped. Call Ends.步骤 3 ）移动台在一个PSMM 中发送其想断开A 站的指示。断开 A 站，呼叫结束


Last RF_Connect, MAHO, & PSMM Sites [ KEY POINTS] 最后无线信号连接， MAHO ， PSMM Sites （要点）

• Last_RF_Connect_BTSes– Arranged in Time 及时安排– Last_RF_Conn1_BTS is always active at the end of the call. Last_RF_Conn1_BTS 总是在呼叫的末尾很活跃– 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.

Conn2 和 Conn3 BTS 在呼叫的末尾可能活跃也可能不活跃。这个取决于呼叫结束时的 N-way 状态。

• Last_MAHO_Act_BTSes– Arranged by Signal Strength. 由信号强度安排– Lists the sites that were in the Active Set before the final PSMM was processed.

列出在最后的 PSMM 处理之前的处于活跃调整状态的站点– 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 consider

ed to be a “Handoff” state.

如果呼叫在最后的 PSMM 处理之前处于 1-way 状态。 Last_MAHO_Act_BTSes = 全 0 。这是因为 1-way 并不被视为一个“切换”状态。

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

l (if there actually was a PSMM sent). 列出在最后的 PSMM 处理之后的处于活跃调整状态的站点。换言之，这些站点是该呼叫的真正的最后站点（如果实际上有一个 PSMM 发送）

– If no PSMM ever occurred during the call, Last_PSMM_Act_BTSes = All zeros.– 如果在呼叫期间没有 PSMM出现， Last_PSMM_Act_BTSes = 全 0

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

O_BTS will always equal Last_RF_Conn1_BTS.

作为最后的 PSMM 的结果，列出增加或是撤销的站点。注意如果 Last_SHO_Cause = 8 or 12 （ Add ）， Last_SHO_BTS 总是等于 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.

Last_RF_ConnN_BTS/Sector/MCC/Element (N=1..3) –这些字段确定呼叫中最后三个 BTS 的信道元件– One Channel Element can support up to six simultaneous sectors. These Sectors are listed in

Sector, SSector (Softer Sector), Sector3, Sector4, Sector5, and Sector6. 一个信道元件可以同时支持多达 6 个扇区。这些扇区列作： Sector, SSector (Softer Sector),

Sector3, Sector4, Sector5, 和 Sector6.– Sector=0 means the sector was not assigned. Sector=0 表示扇区没有被分配。– 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. 因为 CBSC HOCONSTR MaxBTSLegs 设为 3 （并且 2 是当在一个呼叫中有 3 个 BTS 的时候）

，我们永远不会看到 Sector4, Sector5, or Sector6 被分配。• MccN_Release_Time (N=1..3) - Tells us when each of the Last_RF_ConnN BTSes were released from the call. MccN_Release_Time (N=1..3) 表明每一个 Last_RF_ConnN BTS 从呼叫释放的时间

– Measurement Units are Speech Frames ( 1 frame = 20 milliseconds ) 度量单位是语音帧（ 1 帧等于 20毫秒）– 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. 这表示 Last_RF_Conn3_BTS 在呼叫结束前 10.24秒被释放。

– BTSes still connected when the call ends are typically cleared 9~10 frames (200 milliseconds) after the XC_Release_Time.

典型地，当在 XC_Release_Time 后，清除了 9~10 帧（ 200毫秒），呼叫结束， BTS仍是连接着的。


Last RF Connection Stats (Continued)最后无线信号连接统计（续）

• HIGA (Hi Gain) Stats - These stats give us information on the forward (Base-to-Mobile) RF Link.

• HIGA (Hi Gain) Stats （高增益统计）－这些统计给了我们在前向无（基站到移动台）线信号链接的信息

• Quick Review of Forward Power Control: 前向功率控制的快速回顾：

– Every 20 frames (TargetFER=FERB) (400 milliseconds), the base station decreases the forward digital gain by 1 point.

每 20 帧（目标 FER=FERB ）（ 400ms ），该基站减少前向数字增益 1 点。– 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. 如果一个移动台在一圈 PwrRepFrames (默认 =9 -> 113 帧 ) 收到 PwrRepThresh （默认＝ 2 ）

坏帧。他会通过发送一个 PMRM 消息来要求得到更多的前向功率。– The base station will then increase digital gain by 20 points (TargetFER=FERB) 基站将会把数字增益调高 20 点（目标 FER=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). 当有要求的时候，基站总是试着给移动台发送更多的增益。但如果数字增益超过 MaxGainNWay (默认 =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.

如果CdlThresh (默认 t=1) 功率增加的要求在一行里收到，而业务信道正处于最大增益，一个HIGA （高增益）事件发生。



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

Last_RF_HigaN_Intervals (N=1..3) – 表明这个呼叫发生了多少次 HIGA 事件。如果这个值很高，则可能存在下列问题：

– Mobile with bad receiver - Search CDLs for the mobile’s ESN and see whether there are many HIGAs on different cells.

移动的接收机很差－在 CDL 中搜索移动台的 ESN ，并且看看是在不同的蜂窝里否有很多的HIGA 。

– Bad TX coverage - Search CDLs for the suspect BTS/Sector and see whether there are consistently many HIGAs on that BTS/Sector.

TX覆盖差－在 CDL 中搜索怀疑 BTS/扇区，并且看看在那个 BTS/扇区中是否有连续的很多 HIGA 。– Bad BBX - Search for CDLs for the suspect BTS/Sector/Channel. BBX差－在 CDL 中搜索怀疑 BTS/扇区 / 信道。

• Last_RF_HigaN_End/Begin (N=1..3) - These timepoints tell us when, and for how long the most recent HIGA event lasted.

Last_RF_HigaN_End/Begin (N=1..3) －这些时间点告诉我们大多数最近的 HIGA 事件发生在什么时候和持续了多久

– Example: 例：• XC_Release_Time = 0x1000• Last_RF_Higa1_End = 0x0e00 ( 10.24 seconds before call ended) （呼叫结束前 10.24秒）• Last_RF_Higa1_Begin = 0x0c00 ( 15.36 seconds before call ended) （呼叫结束前 15.36秒）



• SETP (Set Point) Stats - These stats give us information on the Reverse (Mobile-to-Base) RF Link.

SETP (Set Point) Stats （调整点）统计 - 这些统计给了我们关于反向（移动台到基站）无线信号链接的信息

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

每秒 800 次，基站发送一个功率控制比特（ PCB ）给移动台，告诉移动台逐步调高或者调低移动台 TX （发射）功率。

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

然而，一旦基站从移动台接收的电平达到 RPCMaxEbNo (默认 =11dB Eb/No) 基站会停止增加移动台 TX 功率。这是为了防止移动台使用多余的反向链接能力

– If high errors persist while BaseRX = RPCMaxEbNO for more than CdlThresh (Default=128 frames=2.56 seconds), a SETP (Set Point) event occurs.

如果当 BaseRX = RPCMaxEbNO ，高错误率持续超过 CdlThresh (默认 =128 帧 =2.56 秒 )，一个 SETP （调整点）事件发生。



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

Last_RF_SetpN_Intervals (N=1..3) – 告诉我们这个呼叫中发生了多少次 SETP 事件。如果这个值很高，则可能存在下列问题：

– Mobile with noisy transmitter - Search CDLs for the mobile’s ESN and see whether there are many SETPs on different cells.

移动台的发射机噪声大－在 CDL 中搜索移动台的 ESN 并且看看在不同的蜂窝中是否有很多的SETP

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

RX覆盖差：－查找使用怀疑出问题的 BTS/扇区的 CDL ，看看在那 BTS/扇区上是否有连续的许多SETP 。同样检查“ Bandits” （ BBX 反向噪声很高的告警）

– Bad BBX -- Search for CDLs using the suspect BTS/Sector/Carrier. BBX差－查找使用怀疑有问题 BTS/扇区 / 载波的 CDL

• Last_RF_SetpN_End/Begin (N=1..3) - These timepoints tell us when, and for how long the most recent SETP event lasted.

Last_RF_SetpN_End/Begin (N=1..3) –这些时间点告诉我们最新近 SETP 事件的发生时间和持续了多久。– Example: 例：

• XC_Release_Time = 0x1000• Last_RF_Setp1_End = 0x0e00 ( 10.24 seconds before call ended) （呼叫结束前 10.24秒）• Last_RF_Setp1_Begin = 0x0c00 ( 15.36 seconds before call ended) （呼叫结束前 15.36秒）


Initial MAHO, First MAHO Stats 初始 MAHO ，第一个 MAHO 统计

• What’s the Difference between the “First” and “Initial” MAHO Sites? “第一个”和“初始”MAHO 站之间有什么区别？

– Answer : Most of the time, NOTHING! 回答：大多数时候：没有区别– First MAHO is associated with the first Mobile PSMM received. 第一个 MAHO伴随着收到第一个 Mobile PSMM 而产生– Initial MAHO is associated with the first Mobile PSMM processed. 初始 MAHO伴随着处理第一个 Mobile PSMM 而产生

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

但… 如果呼叫没有完全建立（检查 LMMSE 来确认），第一个 MAHO （ PSMM ）保持在队列里但不作处理。这种情况下，初始 MAHO 信息将会为空。

•If no MAHO ever occurred, First_MAHO_Cause is set to 255 (Meaning: No MAHO) & Init_MAHO_Cause is set to 0 (Meaning: No MAHO). This is the only difference between “First” and “Initial” MAHO stats 如果从没 MAHO出现， First_MAHO_Cause 被设为 255 （表示：无 MAHO ）。这是“ First”与“ Initial”MAHO 统计之间的唯一差别



• First_MAHO_Time - Tells us when the first Handoff request (PSMM) was received from the mobile.

First_MAHO_Time – 告诉我们从移动台收到的第一个切换请求（ PSMM ）的时间– Measured in XC frame time. 以 XC 帧时间为单位计量

• Example : 例： XC_Release_Time = 0xf000• First_MAHO_Time = 0xa000• Delta = 0x5000 = 20480 frames （帧）• = 490.6 seconds before call

ended

＝呼叫结束前 490.6秒

• First_MAHO_Cause - Tells us the reason the mobile is asking for a Handoff. (First MAHO should never be a Tdrop!)

First_MAHO_Cause – 告诉了我们移动台请求一个切换的理由（第一个 MAHO永远不能是一个 Tdrop ）

FirstMAHOCause Meaning

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.

First_MAHO_Act_Strength – 告诉我们当移动台请求其第一个切换时收到的信噪比

– Always refers to the signal from the Init_RF_Connect BTS/Sector/Channel

总是与来自 Init_RF_Connect 的 BTS/扇区 / 信道有关。– 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_Cand_Count – 告诉我们在移动台的第一次切换中，其想加入多少个导频。• First_MAHO_CandN_PN (N=1..3) - These tell us the PN Offsets of the candidates the mobile wishes to add.

First_MAHO_CandN_PN (N=1..3) –这些字段告诉我们移动台希望增加的候选的 PN偏置• First_MAHO_CandN_Str (N=1..3) - These tell us the mobile RX Ec/Io for each of the above candidates.

First_MAHO_CandN_Str (N=1..3) –这些字段告诉我们对每一个上面的候选 PN偏置中移动台的 RX （接收）信噪比。

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

Init_MAHO_CandN_MMAddr/BTS/Sector (N=1..3) –这些字段告诉我们哪些站点和扇区是移动台在其第一个切换中想要增加的

– The CBSC is able to determine these sites from just the PNs reported in the PSMM using the SECTOP database

CBSC 能使用 SECTOP 数据库仅从在 PSMM 的 PN报告中够确定这些站点。

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

Init_MAHO_CandN_Str (N=1..3) – 和 First_MAHO_CandN_Str 一样，告诉我们由移动台报告的每一个其想加入的候选站点的信噪比。

– 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) –十分强大的统计，可以用来定位移动台，请看下一张幻灯片。



• Init_MAHO_CandN_Phase (N=1..3) - The Distance Indicator Init_MAHO_CandN_Phase (N=1..3) –距离指示器。

– Multiply the PN of the candidate by 0x0040将候选的 PN值乘以 0x0040 ，例如，候选 PN ＝ 8 ， 8×0x0040 = 0x0x200

• For example, Candidate PN = 8, 8 times 0x0040 = 0x0x200

– Subtract this product from the MAHO PHASE从 MAHO PHASE 中减去这个乘积，例如， MAHO_Phase = 0x0202, 差值 = 0x0002

• Example, MAHO_Phase = 0x0202, Difference = 0x0002

– Multiply this difference by 244 meters 将这个差值乘以 244米例如： 0x0002 ×244 = 488米

• Example, 0x0002 times 244 = 488 meters

• THIS TELLS US THE MOBILE IS 488 meters CLOSER to the ACTIVE site than the CANDIDATE site. For example:

这告诉我们移动台离活跃站点比候选站点近了 488米，例如：

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! 移动台可以在这曲线上的任何地方！曲线上的所有点他们的三角差值都是 488米



• Luckily, we know the distance from the Access BTS! 幸运地，我们知道离接入 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”.我们知道移动台不应该在这个点，否则，接入扇区应该是“ 2 ：，并且候选扇区应该是” 6“1.992 Km

1.476 Km

Candidate PN= 0x0200

Candidate Phase=0x202

Candidate Sector=5

Mobile is Here!移动台在这儿

S6

S6 S2

S3S5S4

1.476 KmRadius Line

Delta0.488 KmHyperbola Line



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

在大多数情况下， Access Time 和 Init_MAHO_Time 相隔在几秒内。但如果不是，同时如果移动台被撤掉，位置误差被引入：


True Mobile Location at Access Time 接入时移动台的真正位置

Radius Line at Access Time ( In CDL ) 接入时（离接入站点）的半径（非 CDL里的）

Radius Line at Init_MAHO Time( Not In CDL ) 在 Init_MAHO 时（离接入站点）的半径（非 CDL里的）

HyperBola Line at Init_Maho Time( In CDL ) 在 Init_Maho 时候的双曲线（ CDL里的）

True Mobile Location at Init_Maho Time 在 Init_Maho 时候移动台的真实位置

Calculated Mobile Position. (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.

如果在 Init_MAHO 时候有两个（或更多）的候选站点，我们可以作个三角形然后得到一个十分准确的位置。我们不必担心移动台在移动，因为 PSMM是在单个时间点的多个站点的瞬时值

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”移动台到 A 和 B 站点的距离相同

Candidate PN * 0x40 = 0x1900

Candidate Phase =0x18ff

Delta = -1 -> Mobile is 244 meterscloser to site “C” than “B”移动台离 C 站比离 B 站近了 244米

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…

如果一个候选 MAHO 是同一个站点（不同扇区）一个更软的 Add ，候选状态信息帮助不大…

– Why?

为什么？– We calculate [(Phase - PN x 0x40) * 244] meters and get 0 meters.

我们计算 [(Phase - PN x 0x40) * 244] 米得到的结果是 0米– 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 关于使用 MAHO_PHASE 去定位移动台的一些要点

– Location can be done only when at least one MAHO candidate is a different site 仅当至少有一个候选 MAHO 是不同站点时才能够定位。– One site is good enough if the MAHO occurs quickly after call setup. In most cases this is true. 如果MAHO 在呼叫建立后很快就出现，一个站点并不足够好。在大多情况下都是这样的。– 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. 如果一个移动台在接入时间和初始 MAHO这段时间内移动了很大一段距离，同时如果只有一个不

同站点的时候，位置误差被引入。• Some “Real World” Data taken from KCT‘s F-unit Site 20: 一些从 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.

35% 的包含一个不同站点的呼叫会有包含一个不同站点的一个 Init_MAHO ，我们可以为这些呼叫做还算好的移动台定位

– 7% of all calls do an Init_MAHO including more than one different candidate sites. We can do great mobile locations on these calls.

7％的包含不知一个候选站点的呼叫会做一个包含不知一个候选站点的的 Init_MAHO ，我们可以为这些呼叫做很好的移动台定位



• Being able to locate 35% percent of calls is probably not good enough for police work.

对于警察工作来说，只能够定位 35% 的呼叫似乎并不足够。

• BUT… 35% (or even just 7%) is FANTASTIC for System Optimization Work! 但… 35% (或者甚至仅仅 7%)对于系统优化工作来说听起来就想是个幻想！

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

移动台的信噪比测试图可以通过 CDL 做出来！而无需路测。更好的地方是，我们可以获得真实用户，而不再仅仅是我们路测员，所去的地方的信息！

– Base site RX Eb/No plots can be made from CDLs! Cant even make these today with Drive Testing unless SMAP is used!

基站 RX （接收）信噪比图可以通过 CDL 中做出来！除非使用 SMAP ，现时的路测是做不出来的（ Cant －－ can’t ？）

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

使用 LAST_PSMM Phase 和 MeasCount Stats ，移动台前向 FER （误帧率）图可以通过CDL 做出来


Last MAHO Stats 最后 MAHO 统计

• Last_MAHO Stats refer to the Last PSMM Processed Last_MAHO Stats指的是最后的 PSMM 处理

– Not every PSMM is processed (resulting in SHO) due to XC filtering or other SHO_Blocked reasons.

并非每一个 PSMM被处理（导致软切换）归因于变码器过滤或者其他SHO_Blocked （软切换阻塞）。

• Last_MAHO_Time - Tells when the final MAHO was performed Last_MAHO_Time – 表明最后的 MAHO执行的最后时间

– Measured in XC Time (20 millisecond frames) 以变码器时间计量（ 20毫秒帧）– Compare with XC_Release_Time to learn when the MAHO occurred relative to the end of the call. 对比 XC_Release_Time 来得到相对于呼叫结束的 MAHO出现时间

• Last_MAHO_Cause - Tells us the reason the last MAHO occurred Last_MAHO_Cause – 表明最后 MAHO出现的原因• Last_MAHO_Cand_Count - Tells us how many pilots are being added (or dropped). Last_MAHO_Cand_Count – 表明有多少导频正被增加（或撤销）。

LastMAHOCause Meaning

0 or 255 No SHO14 Tdrop17 Tadd18 Tcomp


Last MAHO Stats 最后 MAHO 统计

• 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_ActN_MMAddr/BTS/Sector (N=1..6) –这些字段表明在最后处理的 PSMM之前哪些扇区处于活跃（ set ）。

• 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_CandN_MMAddr/BTS/Sector (N=1..6) -这些字段表明在最后处理的 PSMM之前哪些扇区处于候选 set 。

• 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_ActN_Str/Phase (N=1..6) - -这些字段表明在最后处理的 PSMM之前活跃 Set 导频的强度和相位。

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

Last_MAHO_CandN_Str/Phase (N=1..3) - -这些字段表明在最后处理的 PSMM之前候选 Set 导频的强度和相位。

– Note: Active & Candidate Phase measurements are relative to the Active Site reporting 0x0000 Phase.

注意：活跃和候选相位的度量是相对于活动站点报告的 0x0000相位– As always, Active & Candidate Strengths are Ec/Io = - [Str/2] dB 大多数情况下，活跃和候选强度是 Ec/Io = - [Str/2] dB、


Last PSMM Stats 最后 MAHO 统计

• The Last_PSMM fields contain either (depending on what happened last):

Last_PSMM 字段包含了以下两种情况之一（取决于那个发生在后头）： – Case “A” : The expected state of the active & candidate sites after the last processed PSMM.

(This is a “fake” PSMM)

情形“ A” ：在最后处理的 PSMM之后，活跃和候选站点的期望状态。（这是一个“假的” PSMM ）

Or 或者– Case “B” : The contents of the last (unprocessed) PSMM received from the mobile.

情形“ B” ：从移动台那里收到的最后（没被处理）的 PSMM 的内容。• Last_PSMM_Time - Tells us when the last PSMM was received.

Last_PSMM_Time – 表明收到最后的 PSMM 的时间 – If Last_PSMM_Time = Last_MAHO_Time, we know no new PSMMs were received after the l

ast processed MAHO, and that the Last_PSMM fields contain the CBSC‘s expected active and candidate sites (Case “A”)

如果 Last_PSMM_Time = Last_MAHO_Time ，我们就会知道在最后处理的 MAHO 后没有收到新的 PSMM ，并且， Last_PSMM 字段包含了 CBSC 期望的活动和候选站点（例“ A” ）

– Otherwise, Last_PSMM CDL fields reflect the last PSMM received (Case “B”).

然而， Last_PSMM CDL 字段反映的是最后收到的 PSMM （例“ B” ）



• Last_PSMM_Cause - Always ZERO because only PSMMs which are NOT processed (Case “B”) or “fake PSMMs” (Case “A”) are written into these fields.

Last_PSMM_Cause – 始终是 0 ，因为只有那些没被处理（例“B” ）或者“假的 PSMM” （例“A” ）写进了这些字段。– If the CBSC chooses to process the last PSMM, that PSMM‘s data gets written into the L

ast_MAHO CDL fields instead, and the expected outcome, the “fake PSMM”, gets written into the Last_PSMM CDL fields.

如果CBSC 选择去处理最后的 PSMM ，那个 PSMM 的数据会写进 Last_MAHO CDL 字段，同时期望的结果，“假的 PSMM” ，会写进 Last_PSMM CDL 字段

• Last_PSMM_Cand_Count - Tells us how many sites are in the Mobile‘s Candidate set at the end of the call.

Last_PSMM_Cand_Count – 表明在呼叫结束时在移动台的候选 set里有多少个站点



• 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_ActN_MMAddr/BTS/Sector (N=1..6) －这些字段告诉我们哪些扇区在最后处理的 PSMM之后处于活跃 set 。

• 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_CandN_MMAddr/BTS/Sector (N=1..6) –这些字段表明哪些扇区在最后处理的 PSMM之后处于候选 set 。

• 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_ActN_Str/Phase (N=1..6) –这些字段告诉我们在最后处理的 PSMM之后活跃 set 导频的强度和相位。

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

Last_PSMM_CandN_Str/Phase (N=1..3) –这些字段告诉我们在最后处理的 PSMM之后候选的 set 导频的强度和相位。

– Note: Active & Candidate Phase measurements are relative to the Active Site reporting 0x0000 Phase.

注意：活跃和候选字段相位是相对于活跃站点报告的 0x0000相位度量的– As always, Active & Candidate Strengths are Ec/Io = - [Str/2] dB 大多数情况下，活跃和候选强度是 Ec/Io = - [Str/2] dB


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.

当无线信号业务量在 CDMA 上链或者下链容量接近饱和的时候，话音质量的下降归因于高语音帧删除率。

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

CDL 有几个对于检测 RF容量瓶颈和他们相关的话音质量问题十分有用的字段。我们可以看看在繁忙时段这些统计的下降

• Systems Engineering and DDI use these statistics to identify and predict RF capacity bottlenecks. The RFLD package is based upon these stats.

系统工程师和 DDI 使用这些统计去确定和预计 RF （无线信号）容量的瓶颈。 RFLD 包就是基于这些统计得出的。

• These stats can also be used to understand the impact RF parameter changes have upon speech quality. The ASE team has used these stats to optimize Forward Power Control, BTS Shuffling, and the RF Loss detection process.

这些统计也可以用来理解 RF参数变化对语音质量的影响。 ASE工作组已经使用这些统计表去优化前向功率控制， BTS Shuffling ，和无线信号丢失检测处理



• Fwd_Quality - Tells us how many FORWARD QUALITY events occurred during the call.

Fwd_Quality – 表明在呼叫中发生多少次 FORWARD QUALITY （前向质量）事件– A FORWARD QUALITY event occurs whenever there are 3 or more Power Increase requests fro

m a Mobile during a 10* second period. The subscriber may notice an “Audio Hole” when a FORWARD QUALITY event occurs.

只要一个 10秒期间内，一个移动台发送 3 个或更多的增加功率的请求，一个前向质量事件发生。当一个前向质量事件发生时，用户可能注意到一个“ Audio Hole” （话音断续？）。

– 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 = Forward Audio Quality Events per Minute （每分钟发生的前向话音质量事件）。 . 通过将 Fwd_Quality 除于呼叫持续事件计算得出。我们可以从 FAQEM估计总的呼叫 FER （帧删除率）。

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

FAQEM 和系统业务量经常要计算。系统工程师可以通过分析 FAQEM 和业务量（ Erlangs ，爱尔兰）趋势去预计什么时候需要给CDMA 系统增加一个新的载频。•FORWARD QUALITY definition assumes XcCpT5 is set at the Default value of 10,000 (10 seconds) and FwdQualityThres set at 3.

•前向质量定义是假设 XcCpT5 计时器是设为默认值 10,000 （ 10秒），并且 FwdQualityThres 设为 3 。



• Last_Fwd_Incr - Tells when the last FORWARD QUALITY event occurred. Last_Fwd_Incr – 表明最后前向质量事件发生的时间

– Measured in XC time (number of speech frames) 以 XC （变码器）时间度量（语音帧的数目）– Compare with XC_Release_Time to determine when the last FORWARD QUALITY event occurred. 和 XC_Release_Time 比较来确定最后前向质量事件发生的时间– 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 :

Meas_Count – 非常有用！表明呼叫中的最后 0..10 秒期间增加功率的请求数。我们可以通过下面的公式计算最后前向 FER ( 帧删除率）。

– Final Forward FER* = Meas_Count X 0.8 (Percent).– Excellent Indicator of Downlink Audio Quality and Capacit

y. 最后前向误帧率＝Meas_Count X 0.8 (Percent). 下链话音质量和容量的卓越的指示器。

•FER Formula assumes XcCpT5 is set at the Default value of 10,000 (10 seconds)•FER公式是假设 XcCpT5 计时器是设为默认值 10,000 （ 10秒）



• Rvs_Quality - Tells us how many REVERSE QUALITY events occurred during the call.

Rvs_Quality – 表明在呼叫期间发生了多少次 REVERSE QUALITY （反向质量）事件– A REVERSE QUALITY event occurs when 14 or more uplink frame erasures occur during a 2.56 second (

128 speech frame) period.

当在一个 2.56秒（ 128 个语音帧）期间，有 14 个或者更多的上链帧发生抹帧时，一个反向质量事件产生。– Indicates the number of Uplink “Audio Holes” -- Bursts of uplink erasures in excess of 10 percent.

显示上链“ Audio Holes” （话音断续）的数目－－突发的上链抹帧超过 10% 。– RAQEM - Reverse Audio Quality Events per Minute. Calculated by dividing Rvs_Quality by Call Hold Tim

e. We can estimate Reverse Frame Erasure rates from RAQEM.

RAQEM - Reverse Audio Quality Events per Minute （每分钟反向话音质量事件）。用 Rvs_Quality 除于通话持续时间计算得出。我们可以从 RAQEM 中估计反向帧抹帧率。

– RAQEM and System Traffic are often correlated. Systems Engineering can do RAQEM vs. Traffic trending, and make predictions when more uplink capacity is required.

RAQEM 和系统业务量经常要计算。系统工程师可以做 RAQEM vs. Traffic 趋势分析，并且当请求更多上链容量的时候做一个预计。

• Note: In most cases, especially Urban areas, FAQEM tends to degrade quicker than RAQEM under high traffic. We say such areas are “Forward Link Capacity Limited”. For this reason, we are usually more interested in FAQEM and Meas_Count stats.

注意：在大多数情况下，尤其是在城市区域，在高业务量时 FAQEM倾向于下降得比 RAQEM快。我们说

这样的区域是“前向链接容量极限”。由于这个原因，我们常常更加关注 FAQEM 和 Meas_Count 统计



• Last_Rvs_Incr - Tells us when the last REVERSE QUALITY event occurred. Last_Rvs_Incr – 告诉我们最后反向质量事件发生的时间。

– Measured in XC time (number of speech frames)

以 XC （变码器）时间度量（语音帧的数目）– Compare with XC_Release_Time to determine when the last FORWARD QUALITY event occurred.

和 XC_Release_Time 比较来确定最后反向质量事件发生的时间– If the difference (DELTA) is less than 128 frames, we know that there was Bad Audio at the end of the

call

如果差值（ DELTA ）少于 128 帧，我们知道在呼叫结束时话音质量差• Rvs_Erase_Count - Tells us the number of reverse erasures during the final 0..127 frames of the ca

ll. Rvs_Erase_Count – 表明在呼叫中最后的 0..127 帧期间的反向抹帧数。

– If DELTA (calculated above) is less than 128, we can calculate Final Reverse FER:

如果DELTA （上面计算的）少于 128 ，我们可以计算最后的反向 FER 。 Final Reverse FER = 100 * Rvs_Erase_Count / DELTA (Percent)

最后反向 FER ＝ 100 * Rvs_Erase_Count / DELTA （％）– 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).

如果这个值比 20%大，我们就说这个呼叫是“以很差上链话音结束的呼叫”。如果你延长无线信号衰减计时器 (XcCpT2) ，注意这个比率。



• RF_Fade_Count - Tells us how many times the Reverse RF (Uplink) went “dead” during the call.

RF_Fade_Count – 告诉我们在呼叫期间反向 RF （上链）进入“ dead” 状态（失灵）的次数。

– The EDIT XC XCL2PARMS command specifies LOSSCNT and ACQCNT parameters.

The EDIT XC XCL2PARMS 命令指定了 LOSSCNT 和 ACQCNT参数 – The EDIT XC XCCPPARMS command specifies the XcCpT2 (RF Fade Timer) parameter.

The EDIT XC XCCPPARMS 命令指定了 XcCpT2 （ RF衰落计时器）参数。– If LOSSCNT (Default=6) consecutive erased frames are detected, the XcCpT2 (Recommended

Default=10seconds) GPROC timer will start running and RF_Fade_Count CDL value will be raised.

如果 LOSSCNT (默认 =6)连续抹帧被检测到。 XcCpT2 (推荐默认值 =10 秒 ) GPROC 计时器会开始启动同时 RF_Fade_Count 的 CDL值会升高。

– If ACQCNT (Default=3) consecutive good frames are received, the XcCpT2 will be reset, and the call will continue normally.

如果收到 ACQCNT (默认 =3)连续好帧， XcCpT2 计时器会重置，同时呼叫继续正常进行。– 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.

如果在计时器计时期间收不到 ACQCNT (默认 =3)连续好帧， GPROC 会声明一个 RF丢失，同时给呼叫拆线。


Vocoder Bypass Stats 声音合成机旁路统计

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

Vocoder_Bypass –给我们一个呼叫中声音合成机旁路行为“迷你历史记录”的位图

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.

比特 0 ： Bypass-Failed – 如果在呼叫期间至少发生一次， XCDR 试图进入旁路模式，但计时结束等待获得旁路同步，则置位

• Bit 1: Bypass Success - Set if bypass mode was active at least once during the call. 比特 1 ：旁路成功 - 如果在呼叫期间至旁路模式至少有一次除于活跃则置位。

• Bit 2: Bypass Enabled - Set if bypass mode was enabled at the end of the call (may or may not be active).

比特 2: 旁路被激活－如果在呼叫结束时旁路模式被激活（或者活跃，或者不是 )则置位• Bit 3: Bypass Active - Set if bypass mode was active at the end of the call. 比特 3 ：旁路活跃－如果旁路模式在呼叫结束时是活跃的则置位。• Range: 0x0 - 0xf 范围： 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.

0x00 －无分组呼叫，或者移动台在分组会晤完全建立之前释放的分组呼叫。– 0x01 - new packet-oriented data call.

0x01 －新的面向分组的数据呼叫– 0x02 - mobile initiated reactivation of a packet-oriented data call.

0x02 －移动台发起的一个面向分组的数据呼叫的再生– 0x03 - network initiated reactivation of a packet-oriented data call.

0x03 – 网络发起的一个面向分组的数据呼叫的再生– 0x04 - 0x0F - Reserved

0x04 - 0x0F －保留• 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.

IWU_ID – 告诉我们服务分组呼叫的分组数据 IWU 的 ID 。如果呼叫不是一个分组呼叫。这个字段设为 0 。如果该呼叫是一个分组呼叫，但移动台断开早 (CFC-111 并且 Pkt_Data_Type=0x00) ，这个字段有时也包含 0 。

fundamentals of cdl analysis cdl 分析基础

Documents