1 / 116

Fundamentals of CDL Analysis CDL 分析基础

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呼叫处理过程

march
Télécharger la présentation

Fundamentals of CDL Analysis CDL 分析基础

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fundamentals of CDL Analysis CDL分析基础

  2. 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” 问题

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

  4. System Performance Analysis Techniques系统技术性能分析 • 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…还有更多 • PM Statistics PM（性能监测）统计表 • Extremely Detailed Tables Counting Events over fixed time periods: • 非常详细地在确定的时间周期内从头到尾地清点事件： • Originations （发起） • Terminations （终止） • Registrations （注册） • Failures （失败） • Handoffs （切换） • Call Final Classes（cfc） • and more... 还有更多

  5. System Performance Analysis Techniques (continued)系统技术性能分析（续） • 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来自和发往变码器的消息 • 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…更多

  6. System Performance Analysis Techniques (continued)系统技术性能分析（续） • 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…更多 • 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网元间未完成/失败的事务处理

  7. Analysis Techniques : Pros & Cons分析技巧：Pros & Cons（正反两面）

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

  9. Information contained in CDLs CDL中包含的信息

  10. 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 InfoCBSC释放信息 • Initial MAHO Stats初始MAHO统计

  11. 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中新增）

  12. 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字段

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

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

  15. 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－电子序列号。一个八位的十六进制码。最后三位数字确定一个电话模式。最后一位的数字确定电话的制造商。

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

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

  18. 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 移动硬切换

  19. 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信道元件

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

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

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

  23. Access Details (Continued)接入细节（续） • 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，和接入扇区字段是多余的。准确的相同的信息可以从进入类型，初始无线信号连接信道，收发信基站，扇区中找到。

  24. Access Details (Continued)接入细节（续） • 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是硬切换的记录的时候，显示服务选项正在使用中。

  25. Access Details (Continued)接入细节（续） • 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. . . 但是这些数字真正表示什么意思？我们现在需要重温基础的呼叫进程去回答这个问题. . .

  26. > Access Channel > < Paging Channel < < Forward Traffic Channel < > Reverse Traffic Channel > < Forward Traffic Channel < > Reverse Traffic Channel > > Reverse Traffic Channel > > Reverse Traffic Channel > > Reverse Traffic Channel > < Forward Traffic Channel < Getting to the Conversation State…Mobile-Base Station Call Processing进入通话状态。。。移动台－－基站呼叫进程 Base Station基站 Set up Traffic Channel Send Channel Assignment Message Begin Sending Null Tch Data Acquires the Reverse Traffic Channel Send Base Station Ack Order Start Sending 1/8 STRAU to XC Forward Service Option Response/ Service Connect Message Conversation! 移动台Mobile Detect User-Initiated Call Send Origination Message Sets Up Traffic Channel Receives N consecutive valid frames Begin sending TchPAM Receive Base Acknowledgement Mobile Station Ack Order Begin sending null Tch Data Receive Service Option Response/ Service Connect Message Mobile Station Ack Order Service Connect Complete Message Conversation! This flow describes a call origination where all goes well. 这个流程描述的是一个各步骤都进展良好的呼叫发起

  27. > 接入信道 > < 寻呼信道 < < 前向业务信道 < > 反向业务信道 > < 前向业务信道 < > 反向业务信道 > > 反向业务信道 > > 反向业务信道 > > 反向业务信道 > < 前向业务信道 < 进入通话状态。。。移动台－－基站呼叫进程 基站 建立业务信道 发送信道配置消息 开始发送空业务信道消息 请求反向业务信道给基站发送确认命令 开始发送 1/8 STRAU 给XC 前向服务选项响应/ 服务连接消息 Conversation! 移动台 检测用户发起的呼叫 发送（呼叫）发起消息 建立业务信道 收到N个连续有效帧 开始发送TchPAM 收到基站确认消息 移动台确认命令 开始发送空业务信道数据 收到服务选项响应/ 服务连接消息 移动台确认命令 服务连接完成消息 通话 这个流程描述的是一个各步骤都进展良好的呼叫发起

  28. > Origination Message > < Base Ack < < Channel Assignment Order (16) < > Tch Preamble > < Base Station Ack Order < > Mobile Station Ack Order > > Service Connect Complete (17) > > NULL 1/8 Rate Frame > < Speech > < Service Connect Message < Getting to the Conversation State…Base Station - CBSC Call Processing进入通话状态。。。基站－－CBSC呼叫进程 CBSC Acknowledge the Origination Tell BTS to setup a Channel Wait for Base to detect Preamble Send 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! Base Station Send Origination Message Get the ACK Sets Up Traffic Channel Detect Tch Preamble Send ACK Order to Mobile Get Mobile ACK Order Reply Start Sending 1/8 STRAU to XC Send SC Message to MS Receive SC ACK from MS Conversation! This flow describes a call origination where all goes well. 这个流程描述的是一个各步骤都进展良好的呼叫发起

  29. > 发起消息 > < 基站确认 < < 信道分配命令 (16) < > 业务信道前同步码 > < 基站确认命令 < > 移动台确认命令 > > 服务连接完成 (17) > > 空1/8 速率帧 > < 语音 > < 服务连接消息 < 进入通话状态。。。基站－－CBSC呼叫进程 基站 发出发起消息 收到确认 建立业务信道 检测业务信道前同步码 给移动台发送确认命令 收到移动台确认命令回复 开始给变码器发送1/8 STRAU 给MS发送SC消息 从MS收到SC 确认 通话 CBSC 收到发起消息 告知BTS建立业务信道 等待基站检测前同步码 向基站发送确认命令 检测1/8 NULL STRAU 告知基站发送服务连接消息给移动台 如果EMX 侧一切正常 通话 这个流程描述的是一个各步骤都进展良好的呼叫发起

  30. > CM Service Request (1) > < SCCP Connection Confirmed (2) < > Setup (10) > < Call Proceding (11) < < Assignment Request (15) < > Assignment Complete (18) > >Connect Ack (23) > < Speech > < Connect (22) < < Alerting (19) < Getting to the Conversation State…CBSC - EMX Call Processing进入通话状态。。。CBSC－－EMX呼叫进程 EMX Get the CM Service Request Acknowledge CM Service Request Start Setting up the Call Tell CBSC we are setting up Call Tell CBSC its OK to put Mob on Tch Start Ringing Called Party Tell CBSC Called Party is Ringing Called Party Answers All is Well! Both the Mobile and Called Party connections are up Conversation! CBSC Get Origination Message for Mobile Tell EMX we have a new call Get the ACK Tell EMX to proceed with Setup Get the Call Proceeding Indicator Get the Assignment Request Get Mob Service Connect Complete Tell EMX Mobile is Connected Get the Alerting Message Get the EMX Connect Message Acknowledge the Connect Conversation! This flow describes a call origination where all goes well. 这个流程描述的是一个各步骤都进展良好的呼叫发起

  31. > CM 服务请求 (1) > < 确认SCCP连接 (2) < > 建立 (10) > < 呼叫进行 (11) < < 分配请求 (15) < >连接确认 (23) > > 分配完成(18) > < 语音 > < 发信号 (19) < < 连接 (22) < 进入通话状态…CBSC－－EMX呼叫进程 EMX 取得CM 服务请求 确认CM 服务请求 开始建立呼叫 告诉CBSC 我们正在建立呼叫 告知CBSC 把移动台放到业务信道上 开始被叫用户响铃 告知CBSC被叫用户正在响铃 被叫用户答复 一切顺利! 移动台和被叫用户两边的连接都建立起来了 通话 CBSC 从移动台得到发起消息 告知EMX 我们收到一个新呼叫 收到确认消息 告知TEMX 继续进行建立 取得呼叫进行指示器 取得指派请求 取得移动台服务连接完成（消息） 告知EMX 移动台已连上 取得发信号消息 取得EMX 连接消息 确认连接 通话 这个流程描述的是一个各步骤都进展良好的呼叫发起

  32. Access Details (Continued) Last MM Setup Event (LMMSE)接入细节（续） 最后移动管理器设置事件（LMMSE） Good Calls : 16 < LMMSE < 24 (for Orig/Term), LMSSE=5 (for Hard HO) 好呼叫： 16 < LMMSE < 24 （对于发起/终止）， LMSSE=5 （对硬切换）

  33. 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。在将来的版本中将会有更多的介绍。

  34. 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分组数据呼叫，正常释放或休眠

  35. RF Trouble CFCs: CFC-3 : RF Layer 2 Failure CFC-4 : RF Loss CFC-5 : No Tch Preamble CFC-8 : MS Did not Arrive on HHO Target Channel CFC-9 : No Valid Speech from MS during Call Setup CFC-10 : No Valid Speech from MS during Hard Handoff CFC-13 : CP Timeout Awaiting Service Option Ack CFC-29 : Handoff Procedure Timeout CFC-134 : Call Blocked - ELPA Fixed Limit CFC-135 : Call Blocked - Forward Load Limiting CFC-136 : Call Blocked - Reverse Load Limiting CBSC Trouble CFCs: CFC-6 : No STRAU Synch CFC-7 : CP Timeout Awaiting MS Acquistion CFC-12 : CPP Call Setup Timeout CFC-60 : Protocol Error between BSC and MSC CFC-61 : Protocol Error between MM and XC CFC-62 : XC Detected Error CFC-13 : CP Timeout Awaiting Service Option Ack CFC-70 : Service Configuration Toggle Procedure Failure CFC-80 : MM Internal Error CFC-81 : MM Database Error Discrepancy CFCs: CFC-11 : Active Set Mismatch CFC-14 : Not Enough Mobile Status Information Received CFC-15 : Negotiation Failure CFC-32 : Disabled Service Option H/W Failure CFCs: CFC-23 : Radio Interface Failure CFC-52 : Equipment Failure at BSC CFC-53 : Equipment Failure at MSC CFC-132 : Equipment Failure at Target BSC MSC Trouble CFCs: CFC-26 : Abnormal MSC Disconnect CFC-27 : MSC Disconnect with SCCP Connection Refused CFC-28 : MSC Disconnect with SCCP RLSD Human-Caused CFCs: CFC-50 : O&M Intervention at BSC CFC-51 : O&M Intervention at MSC CFC-54 : Reset or Reset Circuit from MSC CFC-131 : O&M Intervention at Target BSC No Resource CFCs: CFC-2 : Tch Disabled CFC-18 : No Xcdr Circuit CFC-19 : No DTC CFC-20 : No Radio Resources CFC-21 : Requested Terrestrial Resource Unavailable CFC-33 : No Radio Resources - Redirect to Analog IWU Trouble CFCs: CFC-100 : Circuit Data IWU T1.617 Setup Failure CFC-101 : Circuit Data CDP T1.617 Setup Failure CFC-102 : Circuit Data IWU T1.607 Setup Failure CFC-103 : Circuit Data CDP T1.607 Setup Failure CFC-104 : Circuit Data IWU T1.617 Initiated Disconnect of Stable Call CFC-105 : Circuit Data CDP T1.617 Initiated Disconnect of Stable Call CFC-106 : Circuit Data IWU T1.607 Initiated Disconnect of Stable Call CFC-107 : Circuit Data CDP T1.607 Initiated Disconnect of Stable Call CFC-108 : Circuit Data CPP Inactivity timer Timeout CFC-109 : Circuit Dat Call Failure CFC-112 : Packet Data Setup Failure CFC-113 : Packet Data Protocol Violation CFC-114 : Packet Data Unresolved IWU Release CBSC Release Info (Continued)The “Bad” CFCs. . . CBSC释放信息（续） 异常的CFC。。。 Note : There is also CFC-255 for “Unknown” Failures 注意：还有一个CFC-255，表示不明原因的故障。

  36. 无线信号问题的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级的操作维护干预 无可用资源的CFCs: CFC-2 : XC发起的拆线 CFC-18 : 没有XCDR 电路 CFC-19 : 没有数据业务电路 CFC-20 : 没有可用的无线资源 CFC-21 : 请求的中继线路资源不可用 CFC-33 : 无线资源不可用，重定向到模拟 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 :不能识别的分组数据呼叫释放 CBSC释放信息（续） 异常的CFC。。。 注意：还有一个CFC-255，表示不明原因的故障。

  37. CBSC Release Info (Continued) CBSC释放信息（续） • 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，无线信号建立失败开始学习。

  38. XC Wait for 1/8 Null STRAU MCC Wait for TchPAM XC Wait for Service Option ACK XC Wait for Mobile ACK Order Start RF Call Setup & Failure StagesRF呼叫建立和失败进程 Detected? Detected? CFC=9 CFC=5 No No 如果T3230在MaxRetry尝试前 终止，CFC60，如果MaxRetry 发生在T3230前，CFC3 If T3230 expires before MaxRetry attempts occur, CFC60 is pegged. If MaxRetry attempts occur before T3230 expires, CFC3 is pegged. Detected? Detected? CFC=3 or 60 CFC=13 No No Conversation

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

  40. 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来改善。

  41. 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比率。

  42. 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去替换。

  43. 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的话，在很好的无线信号环境下也会带来很高的无线信号丢失比率，后面有更多关于这方面的介绍。

  44. 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.) 基站会检测上链信号的丢失并声明一个基于反向业务信道无线信号丢失标准（在下一幻灯片中会有解释）

  45. 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 notreceived during the duration of the timer, the GPROC will declare a RF loss and tear down the call. 如果在计时器计时期间收不到ACQCNT（默认＝3)连续的好帧，GPROC会声明一个无线信号丢失并把呼叫拆线

  46. 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 详细解释了该问题及其周围的工作。

  47. 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确认。

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

  49. 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 进入传输中继线两端的交换机是一致的。

  50. 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秒

More Related