MSC统计数据分析.doc

二、统计数据分析 ESTS-G32 V2.0一、 统计数据分析的原始统计数据按其功能的不同可分为接口统计、呼叫统计、杂项等三大类。其中接口统计又分为BSS内部接口（OML、RSL和XBL）统计、MTL接口统计等。呼叫统计分为连接建立统计、TCH分配统计、使用率/拥塞统计、呼叫清除统计和切换统计。杂项统计包括处理器利用率统计、下行BER统计、信道上下行平衡（Path_Balance）统计、发射功率电平统计、空闲信道干扰统计等。原始统计数据还可按照其统计范围来分类：BSS统计、Cell统计、邻小区统计、载频和时隙统计、GPROC统计、MTL统计、CBL，OML，RSL和XBL统计。l 按功能的不同l 接口统计（interface statistics）l 内部接口（OML、RSL和XBL）统计l MTL接口统计l 呼叫统计（call statistics）l 连接建立统计（connection eastablishment statistics）l TCH分配统计（TCH assignment statistics）l 使用率/拥塞统计（usage/congestion statistics）l 呼叫清除统计（call clearing statistics）l 切换统计（handover statistics）l 杂项统计（miscellaneous statistics）l 处理器利用率统计（processor utilisation statistics）l 下行BER统计（downlink BER monitoring statistics）l 信道上下行平衡统计（Path_Balance）l 发射功率电平统计（transmit power levels statistics）l 空闲信道干扰统计（idle interference monitoring statistics）等等l 按统计范围的不同l BSS统计（BSS statistics）l Cell统计（cell statistics）l 邻小区统计（neighbour statistics）l 载频和时隙统计（carrier and timeslot statistics）l GPROC统计（GPROC statistics）l MTL统计（MTL statistics）l CBL，OML，RSL和XBL统计（CBL, OML, RSL and XBL statistics）1、指标性数据前面已经提到原始统计数据共有100多项，因此又定义了关键统计数据（key statistics），对最主要的系统性能进行监控，它是用原始统计数据通过一些预先定义的公式组合计算出来的。另外从用户的角度出发，系统定义了网络状态（Network Health）统计，它是由原始统计和关键统计组合计算得到的。下面介绍的一些常用统计数据主要就是从这两种统计数据提取出来的，我们重点关心的是BSS呼叫处理方面的统计。我们要介绍的常用统计（以小区为统计基础）有：呼叫建立成功率（call_setup_success_rate）TCH阻塞率（tch_congestion_key）掉话率（drop_call_rate）TCH话务量（tch_traffic）SDCCH阻塞率（sdcch_congestion_key）SDCCH射频丢失率（sddch_rf_loss_key）SDDCH话务量（sdcch_traffic）切换成功率（handover_success_rate）切换失败率（handover_failure_rate）l 指标性数据l 呼叫建立成功率（call_setup_success_rate）l TCH阻塞率（tch_congestion_key）l 掉话率（drop_call_rate）l TCH话务量（tch_traffic）l SDCCH阻塞率（sdcch_congestion_key）l SDCCH射频丢失率（sddch_rf_loss_key）l SDDCH话务量（sdcch_traffic）l 切换成功率（handover_success_rate）l 切换失败率（handover_failure_rate）（1）呼叫建立成功率该统计项表示的是在呼叫建立过程中成功分配TCH的比率，包括一般的呼叫、紧急呼叫、短消息业务、寻呼响应和重建呼叫，不需要TCH的呼叫排除在外，例如在SDCCH上完成的短消息服务。阻塞、射频丢失和其它妨碍移动台接入系统服务的一些原因会影响该统计项。该统计是百分数。它涉及以下原始统计数据：TOTAL_CALLS. （总呼叫次数）OK_ACC_PROCCM_SERV_REQ_CALL.（一般主叫成功接入次数） OK_ACC_PROCCM_SERV_REQ_SMS. （短消息服务成功接入次数）OK_ACC_PROCCM_SERV_REQ_EMERG. （紧急呼叫成功接入次数）OK_ACC_PROCCM_REESTABLISH.（呼叫重建成功接入次数） OK_ACC_PROCPAGE_RESPONSE. （被叫成功接入次数）SMS_INIT_ON_SDCCH. （在SDCCH上建立的短消息服务次数）CONGEST_ASSIGN_HO_SUC. （由于标准直接重试-standard directed retry而引起的成功切换次数）通过此统计项，可监控该cell（BSC、System-视统计范围而定）的服务质量、发现故障、衡量服务接入能力等。CALL_SETUP_SUCCESS_RATEcall_setup_success_rate(%)=（2）TCH阻塞率该统计项表示的是由于TCHs拥塞而导致的呼叫建立和小区内切换被拒绝的比率。该统计是百分数。它涉及以下原始统计数据：ALLOC_TCH. （分配TCH成功的次数）ALLOC_TCH_FAIL. （分配TCH不成功的次数）通过此统计项，可监控该cell（BSC、System-视统计范围而定）的服务质量、发现故障、进行网络规划等。TCH_CONGESTION_KEYtch_congestion_key (%)=（3）TCH掉话率该统计项表示的是成功分配TCH 的移动台由于射频或设备等问题而导致的对TCH的非正常释放的比率。它包括射频丢失和切换失败两方面引起的掉话。该统计项对cell、BSS和network的计算公式略有不同。该统计项为百分数，它涉及以下原始统计数据：IN_INTER_BSS_HOIN_INTER_BSS_HO_SUC.（BSC之间成功切入的次数）IN_INTRA_BSS_HOIN_INTRA_BSS_HO_SUC.（BSC内部成功切入的次数） OUT_INTER_BSS_HOOUT_INTER_BSS_HO_ATMPT.（尝试进行BSC之间切换切出的次数）OUT_INTER_BSS_HOOUT_INTER_BSS_HO_RETURN.（进行BSC之间切换切出未成功又返回原TCH的次数）OUT_INTRA_BSS_HOOUT_INTRA_BSS_HO_LOSTMS. （进行BSC内部切换切出未成功又没返回原TCH即丢失的次数）INTRA_CELL_HOINTRA_CELL_HO_LOSTMS.（小区内部切换丢失的次数） OUT_INTER_BSS_HOOUT_INTER_BSS_HO_SUC.（进行BSC之间切换切出成功的次数）RF_LOSSES_TCH.（TCH射频丢失的次数）TOTAL_CALLS.（总呼叫次数）该统计项可用于故障检查、优化等方面。DROP_CALL_RATECell level：Drop_call_rate(%)=%其中：inter_bss_ho_lostms= out_inter_bss_hoout_inter_bss_ho_atmpt- out_inter_bss_hoout_inter_bss_ho_suc- out_inter_bss_hoout_inter_bss_ho_returnBSS level：Drop_call_rate(%)=%其中：inter_bss_ho_lostms= out_inter_bss_hoout_inter_bss_ho_atmpt- out_inter_bss_hoout_inter_bss_ho_suc- out_inter_bss_hoout_inter_bss_ho_returnNetwork level：Drop_call_rate(%)=%其中：inter_bss_ho_lostms= out_inter_bss_hoout_inter_bss_ho_atmpt- out_inter_bss_hoout_inter_bss_ho_suc- out_inter_bss_hoout_inter_bss_ho_return（4）TCH话务量该统计项表示的是小区TCH上承担的总话务量。它的单位为爱尔兰（Erlangs）。对单载频小区其值应在0-7之间， 2个载频应在0-15之间等等，即在0到该小区的TCH数目之间。它涉及以下原始统计数据：BUSY_TCH.（BUSY_TCH_MEAN统计时段内占用TCH的平均值）该统计项可用于网络规划、系统优化等方面。TCH_TRAFFICtch_traffic=busy_tch_mean（5）SDCCH阻塞率该统计项表示的是由于SDCCHs拥塞而导致的呼叫建立被拒绝的比率。该统计是百分数。它涉及以下原始统计数据：ALLOC_SDCCH. （分配SDCCH成功的次数）ALLOC_SDCCH_FAIL. （分配SDCCH不成功的次数）通过此统计项，可监控该cell（BSC、System-视统计范围而定）的服务质量、进行网络规划等。SDCCH_CONGESTION_KEYsdcch_congestion_key (%)=（6）SDCCH射频丢失率该统计项是统计在SDCCH上发生射频丢失的比率。该统计项可用来衡量小区/系统对呼叫的保持能力。该统计是百分数。它涉及以下原始统计数据：RF_LOSSES_SD. （SDCCH上发生射频丢失的次数）OK_ACC_PROC. （成功接入次数，即分配SDCCH成功的次数。它是该Counter Array统计中所有组成项的总和）通过此统计项，可监控该cell（BSC、System-视统计范围而定）的服务质量、故障检查、硬件安装检查等。SDCCH_RF_LOSS_RATEsdcch_rf_loss_rate (%)=（7）SDCCH话务量该统计项表示的是小区SDCCH上承担的总话务量。它的单位为爱尔兰（Erlangs）。它涉及以下原始统计数据：BUSY_SDCCH.（BUSY_SDCCH_MEAN统计时段内占用SDCCH的平均值）该统计项可用于网络规划、系统优化等方面。SDCCH_TRAFFICsdcch_traffic=busy_sdcch_mean（8）切换成功率该统计项表示的是某源小区（该统计项表示的小区）成功切换到目标小区的比率。该统计项包括了BSC之间的切换。它涉及以下原始统计数据：OUT_INTER_BSS_HOOUT_INTER_BSS_HO_SUC.（进行BSC之间切换切出成功的次数）INTRA_CELL_HOINTRA_CELL_HO_SUC.（小区内部切换成功的次数）OUT_INTRA_BSS_HOOUT_INTRA_BSS_HO_SUC.（进行BSC内部切换切出成功的次数）OUT_INTER_BSS_HOOUT_INTER_BSS_HO_ATMPT.（尝试进行BSC之间切换切出的次数） INTRA_CELL_HOINTRA_CELL_HO_ATMPT.（尝试进行小区内部切换的次数）OUT_INTRA_BSS_HOOUT_INTRA_BSS_HO_ATMPT.（尝试进行BSC内部切换切出的次数）该统计项可用于服务质量监控、优化、故障检查等方面。HANDOVER_SUCCESS_RATEhandover_success_rate (%)=（9）切换失败率该统计项表示的是某源小区（该统计项表示的小区）到目标小区的切换失败比率。该统计项包含了切换失败后未能返回源小区信道导致的掉话。它涉及以下原始统计数据：INTRA_CELL_HOINTRA_CELL_HO_LOSTMS.（小区内部切换丢失的次数） OUT_INTRA_BSS_HOOUT_INTRA_BSS_HO_LOSTMS.（进行BSC内部切换切出未成功又没返回原TCH即丢失的次数） OUT_INTER_BSS_HOOUT_INTER_BSS_HO_SUC.（进行BSC之间切换切出成功的次数） OUT_INTER_BSS_HOOUT_INTER_BSS_HO_RETURN.（进行BSC之间切换切出未成功又返回原TCH的次数） OUT_INTER_BSS_HOOUT_INTER_BSS_HO_ATMPT.（尝试进行BSC之间切换切出的次数） INTRA_CELL_HOINTRA_CELL_HO_ATMPT.（尝试进行小区内部切换的次数）OUT_INTRA_BSS_HOOUT_INTRA_BSS_HO_ATMPT.（尝试进行BSC内部切换切出的次数） 该统计项可用于服务质量监控、优化、故障检查等方面。注意handover_success_rate+handover_failure_rate100%，因为上述两项统计均未包含切换失败后又返回源小区信道的那部分。HANDOVER_FAILURE_RATEhandover_failure_rate (%)=2、数据分析流程在日常的维护和优化工作中，我们通常关心的是以下几个问题：硬件问题、频率干扰问题、呼叫建立问题、阻塞问题、掉话问题。这些问题在OMCR统计数据中都有直接或间接的体现。事实上，这几个问题之间也互有关联，例如某个小区的某个（或几个）载频存在硬件故障仍继续工作，可能会导致该小区出现呼叫建立成功率降低，掉话率升高等问题。因此要使一个系统始终处于平稳的运行状态中，我们要学会从统计数据中发现这些问题，分析问题发生的可能原因，并结合路测、频率规划检查、基站检查、数据库检查等手段拿出解决方案来。我们分析问题的顺序一般可按照下页列出的流程顺 序进行，当然也并非绝对要按照这种顺序，因为问题的出现都是互为关联的，处理前面的问题有时也要看看后面问题涉及的指标，例如一个载频各时隙的BER都很大，除了载频硬件问题外，还应考虑是否存在频率干扰问题；无线接通率低，可看看本小区TCH阻塞率是否很高等等。总之在排除了前面的问题后，后面问题发生的原因范围 就缩小了，相对容易对问题进行定位。关心的问题：l 硬件问题l 频率干扰问题l 呼叫建立问题l 阻塞问题l 掉话问题l 问题分析顺序流程硬件问题分析频率干扰分析呼叫建立分析阻塞分析掉话分析（1）硬件问题分析此处所指的硬件问题主要是指BTS 射频方面存在的故障，包括载频校准值、射频各部件产品本身、天线安装等方面的问题。总的说来，基站的接收部分产生的问题对系统指标的影响更大一些。这些问题主要反映在关于载频的统计指标中，我们常用的三个观察指标为：BER、PATH_BALANCE、和RF_LOSSES_TCH。硬件问题范围：基站射频方面易发生的故障：l 基站调测问题l 天线安装连接问题（天线方位角、倾角、扇区定义等）l 射频器件本身质量问题（主要是载频）l 硬件问题分析观察数据l BERl Path_balancel RF_LOSSES_TCHBER：BER是比特误码率（Bit Error Rate）的简写，它是一个normal distribution统计，每个SACCH复帧（480ms）上报一次，反应了激活信道（时隙）的下行接收质量。我们都知道，在TCH上一个SACCH复帧内移动台接收100个下行帧，得出每帧的BER。这100个BER通过非加权的算法得出一个该SACCH复帧内的总体平均BER，并把该平均值转换为GSM定义的八个质量级别（quality bands）之一，把上行测量报告中报告给BSS。BSS在进一步交由HDPC平均处理前可将服务级别转化成相应的假定值。在数据库参数中可定义不采用假定值，而直接采用报告的服务级别值Page: 17数据库参数alt_qual_proc=0采用BER，alt_qual_proc=1采用quality bands。来进行处理。HDPC决定了MS是否需要进行功率控制（Power Control）或切换（Handover）。一般观察较长时间后，若该载频的每个时隙的BER一直都较高（BER值的正常范围应视系统而定，系统市区平均（BER_MEAN）值比郊区高，一般正常值在1.6以下，当BER_MEAN值较高时）时，反映该载频的下行链路质量存在问题，需检查该载频的校准、频率干扰及载频本身是否存在问题。PATH_BALANCE:path_balance是每480ms更新一次的反映链路平衡情况的normal distribution统计。路径损耗（path loss）等于发射台的发射功率与接收台的接收功率的差值。基于每sacch复帧基础上计算该统计的公式如下：Path_balance = uplink Pathloss- downlink Pathloss其中：uplink Pathloss = actual MS txpwr rxlev_uldownlink Pathloss = actual BTS txpwr rxlev_dlrxlev_ul/dl是当前报告的最新值，而不是平均值。上面的结果再以110为基准衡量，即实际的path_balance统计项等于上面的Path_balance加上110。一般理论上上行和下行的路径损耗应相同，考虑到分集接收的增益，上行路径损耗应低一些，所以该统计项应低于110。考虑到无线信号在一般空间传播的不稳定性和多径效应，根据实际经验，该统计项在100-115之间时，我们认为都是正常的。该统计的平均值高于115表明BTS接收通路可能存在 问题，如天线、射频电缆、接收分路器等等，低于100表明BTS发射通路可能存在问题，如天线、射频电缆、滤波器、合路器等等。 RF_LOSSES_TCH:RF_LOSSES_TCH和RF_LOSSES_SD都属于呼叫清除统计。我们知道在专用模式下，MS每480ms向BSS发送一次测量报告。当在规定时间未收到测量报告时，HDPC中的计数器link_fail将减1。Link_fail的最大值可在数据库中利用add_cell命令定义。如果一段时间的测量 报告未送达BSS则明显表明MS的上行连接丢失了。在这种情况下，link_fail连续减1，并最终达到0，当达到0时，RSS宣布链路连接失败，并送一个错误指示信息来通知RRSM。RRSM则指示RRS停用此TCH，并发送一无线信道释放（Radio Channel released）消息给SSM。SSM向MSC发送一清除请求（Clear Request）。RF_ LOSSES_TCH属于counter统计类型，是当RRSM接收到信道类型为TCH的错误指示信息时基于每时隙统计的。它统计了由于RF问题导致通话非正常结束的次数。当一个载频的RF LOSS次数比同一小区的其它载频远远多时，基本可判断该载频存在硬件问题。除此之外，导致RF LOSS的原因还有频率干扰、基站覆盖、错误邻小区、邻小 区阻塞、切换速度过慢、软件问题等。 分析流程：一般优化时或工程结束后，我们会观察告警、Path_balance等指标来发现一些硬件设备问题。实际上在日常维护中也应经常关注告警和Path_balance等统计指标，及时发现问题并解决，使系统保持平稳运行。本书主要介绍统计数据的分析流程，关于告警的分析请参考本技术资料系列中的BSS高级维护。如果我们发现某个小区不正常（根据统计数据、DRIVETEST或用户投诉），首先应确定该小区是否存在硬件问题。检查硬件问题，首先可观察告警消息和基站状态，然后可按照下面的分析流程进行。如果我们观察到某个载频的统计数据（PATH_BALANCE、BER或RF_LOSSES_TCH之一、二甚至三）不正常，先应观察同一小区的其它载频相应的统计项，若均不正常说明该小区存在问题，若有两三个不正常，可观察其是否连接同一合路器等，以此来判断硬件问题的范围。若其它载频正常，则说明该载频存在问题，在OMC端可通过复位、改频等手段，在BTS端可通过检查载频的收发校准、更换器件、载频硬复位等手段。分析流程图不正常见PATH_BALANCE分析同一小区其它载频的此值正常否？BER分析：（PB为PATH_BALANCE简称）正常不正常改变频点检查载频的PB值某载频的BER 值不正常见PATH_BALANCE分析不正常RF_LOSSES分析：（PB为PATH_BALANCE简称）不正常某载频的RF_LOSSES_TCH 值不正常检查天线、馈线、双工器、滤波器、CBF或HC（合路器）等、DLNB、IADU等正常检查载频的PB值正常改变频点载频硬复位更换载频检查天线、馈线、双工器、滤波器、CBF或HC（合路器）等，重点驻波比正常更换载频PATH_BALANCE分析：（PB为PATH_BALANCE简称 ）同一小区其它载频的此值正常否？偏小检查载频的发射校准；偏大检查载频的接收校准均偏小检查天线、馈线、双工器、滤波器、CBF或HC（合路器）等；均偏大检查天线、馈线、双工器、DLNB、IADU等同一小区的其它载频的PB值正常否？某载频的PB值不正常检查载频射频电缆正常不正常更换载频（2）频率干扰分析我们知道无线覆盖和频率干扰是移动网建设的两大难题。GSM系统对同频干扰的要求是C/I912dB，对邻频干扰的要求是载频偏离200KHz时C/I9dB，偏离400KHz时C/I41dB。当频率干扰，特别是同频干扰大于这些值时，不仅会影响到通话的质量，还会影响掉话率、呼叫建立成功率等统计指标。频率干扰从信号方向上分为上行干扰Page: 24频率规划不合理、小区切换边界过大、neighbour list不对、邻小区阻塞、邻小区OOS等均可导致上行干扰。和下行干扰两种Page: 24频率规划不合理、小区天线倾角和方位角不合理、小区参数设置（最大发射功率）不合理等均可导致下行干扰。，从来源上分为系统内干扰、系统外干扰两种。系统内干扰较为普遍的是由于小区覆盖问题导致的上行干扰，我们可通过控制小区覆盖范围、修改频率规划等手段加以解决；系统外干扰从时间上分为突发性的干扰Page: 24汽车启动时引擎点火噪声、电车的火花噪声等和固定时段的干扰Page: 24直放站、电视台、雷达站等大功率无线电发射台的干扰、霓虹灯干扰等，从干扰的频率来看分为针对个别信道的窄带干扰和全频带的宽噪声干扰。对固定时段出现的外来窄带干扰我们可通过改频等方法暂时避开干扰，对宽带干扰我们只有在找到干扰源后才能决定下一步的策略。在MOTOLORA 系统中，我们通常借助统计数据INTF_ON_IDLE和BER来找到受干扰小区和载频,其中INTF_ON_IDLE反映了上行的干扰情况，BER一定程度上反映了下行的干扰情况。一般来说，由于上行信号比下行信号更容易受到干扰，我们更多地从INTF_ON_IDLE统计项来发现干扰问题。BER分析前面已有介绍，INTF_ON_IDLE分析见下面。l 频率干扰：l 干扰保护比：9-12dB(同频)；-9dB(频率偏离200KHz), -41dB (频率偏离400KHz)l 信号方向：上行干扰、下行干扰l 来源：系统内干扰和系统外干扰l 频率干扰问题分析观察数据l INTF_ON_IDLEl BERINTF_ON_IDLE:INTF_ON_IDLE是每480ms更新一次的反映上行环境噪声情况的基于时隙的normal distribution统计。当一个TCH时隙处于空闲状态时，它不断地监测任何上行环境噪声。在一个SACCH复帧时间里，将对每个时隙提供104次监测值，这些抽样值每480ms被处理为一个平均噪声电平值。该值报告给HDPC，并被HDPC进一步做平均和处理。HDPC周期性地向CRM报告每个空闲时隙的干扰电平。CRM把此项统计作为信道分配顺序的依据。若某载频的INTF_ON_IDLE异常（INTF_ON_IDLE值的范围应视系统而定，一般系统市区的平均值比郊区高，一般正常值应小于10），否则反映了该载频上行信道干扰较大，需要检查频率规划、基站接收和发射、是否有外载波干扰等。分析流程图前面已经介绍了BER和INTF_ON_IDLE的定义。根据这两个统计项，特别是INTF_ON_IDLE，我们可以确定受到干扰的小区和载频，从而相应地分析可能导致干扰的原因。一般来说，如果干扰来自GSM系统，则INTF_ON_IDLE和BER值都会异常；若来自非GSM系统，则两者之一或全部均可能异常；若基站过覆盖，则其BER值可能正常而INTF_ON_IDLE值不正常。若干扰是由于系统内非硬件原因造成的，可通过调整相应基站覆盖、调整天线方位角、频率规划修改及修改小区参数等手段加以解决，需要说明的是应该特别注意系统内直放站的规划和调测。若干扰来自系统外，先根据统计数据找到被干扰的大致区域，对相应小区或载频进行改频或改方位角看能否解决，若避不开干扰，则先观察区域内存在的大功率无线发射站，然后利用路测设备或扫频仪确定干扰源。找到干扰源后，与其制造者协商解决。分析流程图检查天线、馈线、双工器、DLNB、IADU等，重点天线环境检查和驻波比检查干扰问题分析：（PB为PATH_BALANCE简称，INTF为INTF_ON_IDLE简称）同一小区其它载频的此值正常否？某载频的INTF值不正常正常正常正常不正常见前面PB分析不正常不正常见前面BER分析检查载频的BER值检查载频的PB值寻找系统外干扰源更改天线方位角更改频点INTF仍不正常INTF仍不正常与干扰源制造者协商解决（3）呼叫建立分析我们前面介绍的Call_Setup_Success_Rate（呼叫建立成功率）是评价系统性能的一项重要指标。它反映了成功接入SDCCH且要求建立TCH的呼叫请求中成功分配TCH的比例。实际上根据呼叫流程，MS在接入TCH前首先需接入SDCCH，所以未能接入SDCCH也应该算不成功的呼叫建立。对于呼叫建立的分析我们应立足于对呼叫流程的理解上，通过对呼叫建立过程中一些原始数据的分析，特别是与呼损有关的数据来发现问题，从而提高呼叫建立成功率。下页就给出呼叫建立流程及相应统计点（以MS主叫为例，MS被叫比主叫多了个寻呼流程；其中呼叫建立失败的情况和统计在图中用斜黑体字标出）。更详细的呼叫流程见附录一。下面将呼叫建立不成功的情况一一说明。BTS收到MS在RACH上发出的呼叫请求，但呼叫建立的原因未被证实，由此产生的统计为INV_EST_CAUSE_ON_RACH（位于RSS Abis）。MS请求分配SDCCH，但由于SDCCH拥塞，BTS发出一条Immediate assign reject消息给手机，分配失败。相关的统计项为ALLOC_SDCCH_FAIL（位于CRM）、CHAN_REQ_MS_BLK（位于RSS）。MS请求分配SDCCH，BTS通过AGCH给手机指配了SDCCH，但在规定的时间内没有得到响应（超时失败）。统计项为CHAN_REQ_MS_FAIL（位于RRSM），对应的计时器为rr_t3101。呼叫建立流程：MSBSSMSCCHANNEL REQUESTACCESS_PER_RACHOK_ACC_PROC_SUC_RACHINV_EST_CAUSE_ON_RACHCHAN_REQ_CAUSE_ATMPTACCESS_PER_AGCHIMMEDIATE ASSIGNMENT REJECTALLOC_SDCCH_FAILCHAN_REQ_MS_BLKIMMEDIATE ASSIGNMENT(AGCH)ALLOC_SDCCHCHAN_REQ_MS_FAIL(TIME OUT)rr_t3101SABM+INITIAL LAY3 MESSAGE(SD)OK_ACC_PROCCM SERV.REQ.-CALLor CM REESTABLISHMENTor PAGE RESPONSEor LOCATION UPDATEor IMSI DETACHCONNECTION REQUEST CONN_REQ_TO_MSCCONNECTION CONFIRM ORCONNECTION REFUSED CONN_REFUEDASSIGNMENT REQUESTMA_REQ_FROM_MSCALLOC_TCH_FAILMA_CMD_TO_MS_BLKDALLOC_TCHASSIGNMENT COMMAND(SDCCH)MA_CMD_TO_MSASSIGNMENT FAILURE(SDCCH)MA_FAIL_FROM_MSASSIGNMENT FAILUREASSIGNMENT COMPLETE(TCH)ASSIGNMENT COMPLETETOTAL_CALLSMA_COMPLETE_TO_MSCMSBSSMSCBSC向MSC发出建立呼叫的请求，MSC向BSC回送一条SCCP连接拒绝消息，这种情况统计在CONN_REFUSED（位于SSM）中,若该项数据值过大，表明BSC和MSC之间的信令配合有问题。（注意有些交换机在Location Update、呼叫重建失败、IMSI DETACH时也向BSS端发CREF消息，而由BSS统计在CONN_REFUSED中。）BSC向MSC发出建立呼叫的请求得到证实后，MSC向BSS发一要求分配TCH消息，但由于资源不足而失败。统计在ALLOC_TCH_FAIL（位于CRM）和MA_CMD_TO_MS_BLKD（位于RRSM，还包括Intra_cell切换阻塞的情况）中。BSC通过SDCCH向MS发出一条分配TCH的消息，MS在SDCCH上回送一分配失败消息，BSC再把该消息送到MSC，呼叫建立失败。相关的统计为MA_FAIL_FROM_MS（位于RRSM，还包括Intra_cell切换失败的情况）。此种情况可由下列原因引起：BTS的无线信号覆盖问题；频率干扰；功率控制设置不当等。其中前三种就是未建立SDCCH的情况，虽与呼叫建立成功率的计算无关，但从流程来看，显然本次呼叫没有完成。MS做被叫时多一寻呼过程，随后的过程与主叫相同，如下页所示。在此过程中，呼叫失败产生于以下情况：MSC向BSC发出寻呼请求，但寻呼消息在BTS发出前就由于队列过长被取消，计入PCH_Q_PAGE_DISCARD统计中（位于RSS）。对用户投诉和路测过程中发现的难打电话的小区，根据呼叫流程我们可通过利用OMCR的数据统计功能定量地分析各种情况所占的比重，从而抓住重点，迅速而有效地解决问题。被叫比主叫多一寻呼过程，如下图所示（随后的过程与主叫同）：MSBSSMSCPAGINGPAGE_REQ_FROM_MSCPCH_Q_PAGE_DISCARDPAGING REQUESTACCESS_PER_PCH前面已经提出呼叫建立实际上包含两阶段：MS成功占用SDCCH和MS成功占用TCH。后一个阶段我们有统计数据呼叫建立成功率（Call_Setup_Success_Rate）、TCH阻塞率（TCH_CONGESTION_KEY）、TCH分配失败丢失率（ASSIGN_FAILURE_RATE_LOST）和TCH分配失败恢复率（ASSIGN_FAILURE_RATE_RECONER）；前一个阶段我们除了一些统计项，如SDCCH射频丢失率（SDCCH_RF_LOSS_RATE）、SDCCH阻塞率（SDCCH_CONGESTION_KEY）外，还可以自己组合一些原始统计数据来分析小区的SDCCH接入性能。下面将前面常用指标数据中未介绍到的作一解释，同时介绍两个我们自定义的统计数据。OMCR中已有的统计项：TCH分配失败丢失率（ASSIGN_FAILURE_RATE_LOST）：表示BTS发出分配命令（Assignment Commands）给MS，但MS未能到达分配TCH且未将分配失败（Assignament failure）消息返回给BTS，导致连接丢失的比例。信号电平过低、干扰、小区覆盖问题和基站硬件问题均可导致此项统计值偏高。计算公式如下：ASSIGN_FAILURE_RATE_LOST(%)=TCH分配失败恢复率（ASSIGN_FAILURE_RATE_RECOVER）：表示BTS发出分配命令（Assignment Commands）给MS，但MS未能到达分配TCH返回到原SDCCH，并将分配失败（Assignament failure）消息返回给BTS所占的比例。其导致原因与TCH分配失败丢失率类似，且如果某小区此项指标太高，表明此小区存在DRI问题。计算公式如下：ASSIGN_FAILURE_RATE_LOST(%)=自定义的统计项：SDCCH接入率（SDCCH_ACCESS_RATE）：表示MS成功接收到BTS在SDCCH上发送的SABM L2 消息的比例。该统计值偏低的原因有干扰、覆盖问题、帧时钟不匹配等。Page: 32还有数据库参数的设置，rr_t3101计算公式如下：SDCCH_ACCESS_RATE(%)=CIC分配成功率（CIC_ALLOC_SUC_RATE）：表示交换机向BSS发送分配请求（建立TCH）占所有需建立TCH（MS主叫、MS被叫和呼叫重建）的呼叫请求的比例。该统计值偏低的原因有CIC阻塞、BSS和MSC信令配合问题、MSC阻塞和其它MSC问题等，同一BSC下的各小区此值偏低可能为CIC阻塞，同一MSC下的各小区此值偏低可能为BSS和MSC信令配合问题、MSC阻塞和其它MSC问题。计算公式如下：CIC_ALLOC_SUC_RATE(%)=以上介绍的统计数据中除SDCCH阻塞率和SDCCH接入率反映的是SDCCH的性能与呼叫建立成功率（Call_Setup_Success_Rate）无关外，其它均有关。因此我们分析呼叫建立问题时，一般从对呼叫建立成功率（Call_Setup_Success_Rate）的分析着手，然后分析相应的TCH阻塞率、SDCCH射频丢失率等数据，结合路测、BTS优化、数据库参数检查等手段，找到问题所在并解决之。分析流程图呼叫建立成功率分析：CONN_REFUSED是否异常，MSC方面有无阻塞及其它问题，如属信令配合问题与MSC工程师协商解决同一MSC下小区是否正常？不正常正常检查CIC分配成功率同一BSC下小区是否正常？该小区的TCH阻塞率正常否？不正常降低小区TCH阻塞（见下面的TCH阻塞分析）某小区的呼叫建立成功率偏低不正常正常不正常正常是否有CIC阻塞及检查BSC方面A接口参数设置及硬件检查BSC方面A接口参数设置及硬件降低小区的SDCCH射频丢失率，参见下面掉话分析检查小区的SDCCH射频丢失率值路测检查小区的覆盖、信号电平、干扰情况、下站检查硬件问题，检查小区数据库等不正常正常不正常正常不正常正常降低小区的SDCCH射频丢失率，参见下面掉话分析检查小区的TCH分配丢失率和恢复率正常不正常更换MCU（GPROC）、TCU等SDCCH性能分析：小区的SDCCH阻塞率过高降低小区SDCCH阻塞（见下面的SDCCH阻塞分析）小区的SDCCH接入率过低更换SDCCH所在载频检查小区的SDCCH射频丢失率值检查数据库参数设置特别是rr_t3101等定时器参数降低小区的SDCCH射频丢失率，参见下面掉话分析（4）阻塞分析阻塞率和掉话率是我们日常维护和优化中最关心的两个指标。分析阻塞我们一般观察两个指标：TCH阻塞率（TCH_Congestion_Key）和SDCCH阻塞率（SDCCH_Congestion_key）。小区阻塞可能出现三种情况： SDCCH和TCH都出现阻塞；SDCCH无阻塞，而TCH出现阻塞；SDCCH阻塞高，而TCH阻塞低或无阻塞。在某小区出现阻塞后，首先要确认该小区无载频退服问题和相邻小区无退服问题，再分析其它的原因。下面针对每种情况进行分析。SDCCH和TCH都出现阻塞：如果相邻小区的SDCCH和TCH的都出现阻塞，则只有通过增加载频或基站来达到降低阻塞的目的。如果相邻小区未出现阻塞，可采取均衡业务量的办法，次序依次是调整天线、修改切换门限、调整小区选择参数，基站其他小区无阻塞，也可考虑小区重新配置。SDCCH无阻塞，而TCH出现阻塞：可通过调整切换门限、调整天线、调整小区参数、小区重新配置的方法加以解决。SDCCH阻塞高，而TCH阻塞低或无阻塞。首先观察SDCCH的干扰和射频丢失情况，如果在SDCCH频点上存在较严重射频干扰，一方面会造成无效试呼次数和SDCCH射频丢失次数的增加；另一方面，由于移动台频繁占用SDCCH或占用SDCCH的时长增加，会造成SDCCH的阻塞，可采用修改频率规划或倒换SDCCH载频的方法。再观察位置更新完成次数（OK_ACC_PROCLOCIATIAON_UPDIATE）是否过多，如果位置登记区的边界位于城市主要道路的两侧，或是其他人群密集的区域，会造成该区域内移动台发生频繁的位置登记，加重SDCCH的负荷，产生阻塞。可采用调整小区覆盖Page: 35调整天线，增大或减小个别基站发射功率，使该区域有一明显占优势的小区，优化位置登记区（LAC）边界、增加SDCCH数量、改变小区参数Page: 35提高位于LAC边缘小区的重选滞后参数（cell_reselect_hysteresis）；增大T3212（t3212=0-255）位置登记消息需要上报至VLR，延长移动台周期性位置更新时间，可以大大降低系统负荷,包括BSC，MTL，SDCCH等等的负荷；如将T3212=60 增大到T3212120，使周期性位置更新时间由6小时变为12小时，大大降低系统负荷。系统内各小区T3212 应一致。当BSC处理器过载时，也可考虑增大t3212；提高发送分布时隙数（tx_integer）=0-15,默认值为4。前面已经介绍，这是以延长接续时间为代价的。以时间换空间，这是最后的办法；调整最大重发次数（max_retran）=0-3 RACH是一个ALOHA信道,网络允许移动台在收到立即指配消息前,发送多个信道请求,以提高接通率，但同时增加了RACH和SDCCH信道的负荷。取值范围03。0 最大重发次数11 最大重发次数22 最大重发次数43 最大重发次数7、位置登记区重新分区等方法优化位置登记区边界。其它原因导致的SDCCH阻塞也可采用调整小区覆盖、增加SDCCH数量和改变小区参数的方法加以解决。分析流程图观察一段时间的阻塞统计数据，确定不是载频OOS或邻小区OOS导致的阻塞，再根据具体情况进行分析。SDCCH和TCH均阻塞：其它情况正常偏高位置更新次数是否偏高偏高正常SDCCH上的干扰与射频丢失情况如何降低小区的SDCCH射频丢失率，参见下面掉话分析小区的SDCCH阻塞TCH无阻塞率邻小区的阻塞率正常否本小区加载频或在小区方向上增加基站偏高正常降低小区的SDCCH射频丢失率，参见下面掉话分析调整天线、修改切换门限、调整小区选择参数、小区重新配置与邻小区均衡业务量小区的SDCCH和TCH阻塞率均高SDCCH无阻塞，TCH阻塞的情况与两者均阻塞处理方法类似。SDCCH阻塞，TCH无阻塞：换SDCCH载频、修改频率规划调整小区覆盖、增加SDCCH数