华为话务统计含义.ppt

基本信令流程和话务统计含义 无线院 金江新2006年5月 手机在RACH信道上发送 ChannelRequest 消息请求接入 BTS把该消息发送给BSC 如果BSC能够准确的解码上行的 ChannelRequest 消息 且小区有空闲SDCCH信道 则准备在AGCH信道 接入允许信道 上发送 ImmediateAssignCommand 消息为手机分配信令信道 如果手机能够成功占上SDCCH信道 则发送SABM 设置异步平衡模式 消息 通知小区成功占上信令信道 同时小区把建链指示消息 含建链原因CMServiceRequest 发送给BSC 在SDCCH信令信道上 需要手机和交换之间交互鉴权加密等安全信息 一旦MSC证实该次呼叫合法 则BSC请求交换发送 ConnectRequest CR 以建立电路连接 如果在A接口有空闲的电路时隙 则回复BSC ConnectConfirmed 消息 通知BSC在A接口上已经为该次呼叫分配了电路了 同时MSC给手机发送 CMServiceAccepted 手机收到交换的 CMAccepted 消息以后 开始把被叫的呼叫信息发给MSC以建立和被叫用户的连接 MSC收到该消息以后给手机回复一个 CallProceeding 消息 告诉手机正在建立和被叫用户的连接 同时通知BSC发送 AssignmentRequest 消息以准备TCH信道 如果BSC有空闲的TCH信道 则把 AssignmentCommand 消息发送给手机 以建立TCH信道的连接 如果MSC已经发送 Assignment Req 但BSC没有发送 AssignmentCMD 而是发送 Assignment Fail 消息 则可能是 BSC没有有效的空闲TCH信道 被MSC分配的CIC电路在BSC侧没有空闲 传输或者干扰导致消息无法正确解码 手机在正确解码指派命令消息以后 占上TCH信道同时发送SABM给小区 说明已经成功占上TCH信道 小区则把该消息包含在TCH信道建链指示消息里上报给BSC BSC则把该消息上报给MSC表明手机已经占上TCH信道了 如果BSC已经发送 AssignmentCMD 但手机发送 AssignmentFail 消息 可能下行无法过高导致手机无法正确解码信息 MSC一旦收到主叫用户和被叫用户都已经占上话音信道 则发送 Alerting 消息 主叫听到 嘟嘟 的振铃声 被叫听到 铃铃 的被叫铃声 建立主叫和被叫手机之间的连接 被叫听到铃声摘机 发送 Connect 消息回主叫手机 会话过程建立 会话过程结束以后 任何一方挂机 都将给对方手机发送 Disconnect 消息 以表明会话结束 系统将指示手机释放信道以回收信道资源 手机在释放无线信道资源以后 发送 ReleaseComplete 消息通知手机已经释放无线信道资源 最后交换回收A接口的电路资源 主叫信令流程 被叫手机的呼叫流程和主叫手机类似 以下几点和主叫流程有区别 手机在空闲信道不断侦听系统在下行PCH 寻呼信道 上下发的寻呼消息 被叫手机一旦解码有寻呼自己的信息 则在RACH信道上发送 ChannelRequest 消息 以请求接入 在手机占上SDCCH信道以后发送的建链指示里的原因为 PagingResponse 在收到系统下发的 Setup 起呼消息以后 回复系统 CallConfirmed 消息 以证实该次被叫 上下行的交互信息和主叫手机的呼叫流程正好相反 被叫信令流程 源小区向目标小区发送内部切换 IntercellHandoverReques t请求 在发送切换请求消息前 手机根据测量报告和切换判决确定什么时候切换 哪种类型的切换 目标小区如果有空闲信道 则通过目标小区所在的基站来激活给该次切换的TCH信道 同时发送 IntercellHandoverResponse 通知目标小区已经为该次切换准备好 源小区收到该信息以后 发送切换命令 HandoverCommand 手机在收到切换命令以后 给目标小区发送 HandoverAccess 消息 通知切换开始 如果成功的占上目标小区的信道以后 手机在目标小区上给系统发送 HandoverComplete 消息通知切换已经成功 目标小区向源小区发送 HandoverSuccess 通知源小区释放原有信道 内部小区切换流程 外部小区切换和内部小区切换的主要区别在于需要MSC和各自所属的BSC的参与 源小区所在的BSC向MSC发送切换请求 HandoverRequired 消息 MSC收到该消息以后 向目标小区所在的BSC请求切换 HandoverRequest 目标BSC如果有空闲的信道 则回复MSC切换确认 HandoverRequestACK 消息 MSC收到目标BSC发回的切换确认消息以后 发送 HandoverCommand 消息命令源BSC和源小区切换 手机在尝试占上目标小区的信道时 向MSC发送 HandoverDetect 消息通知切换开始 在手机成功占上目标小区的信道时 向目标MSC发送切换完成消息 MSC收到切换完成的信息以后 通知源BSC回收信道资源 外部小区切换流程 发生小区内切换的主要原因是源信道不能提供足够好的服务质量 在满足小区内切换的触发条件下 通过变更同小区的不同信道 为手机用户提供更好的完构哦服务质量 在满足小区内切换的条件下 BSC给使用源信道的手机发送 AssignmentCommand 消息命令小区内切换 如果手机能够及时占上目标信道 则在目标信道上给BSC发送 AssignmentComplete 消息 通知已经完成小区内切换 BSC收到小区内切换完成消息以后 向交换发送 HandoverPerformed 通知MSC完成了一次小区内切换 小区内切换流程 BscleveltaskBSCmeasurementperformanceCellleveltaskCellmeasurementperformance themostimportant cell Drop incommonused cell SDCCH cell TCH cell Handover cell TRXleveltaskPathbalanced PB TRX ReceivedLevel TRX ReceivedQuality TRX Channelallocation TRX OthertaskA interfaceperformanceMTPstatisticsGPRS EGPRSresourceFrequencyscanOutgoinginter cellhandoverTA RQIEspecialabnormalcelltask accordingusers need 话统任务 ImmediateassignmentrequestsSuccessfulimmediateassignmentsAttemptedSDCCHseizures all SuccessfulSDCCHseizures all SDCCHcalldropAttemptedSDCCHseizuresmeetingSDCCHoverflowSDCCHtrafficvolume excludingveryearlyassignment ERL AttemptedTCHseizures all SuccessfulTCHseizures all TCHcalldropAttemptedTCHseizuresmeetingTCHoverflowTCHtrafficvolume excludingveryearlyassignment ERL AttemptedintercellhandoversSuccessfulintercellhandoversAvailableTCHsTCHcongestionrate excludinghandover TCHcongestionrate includinghandover Someresultscancalculatefromtheseoriginalstatisticsitems 小区级常用话务统计 常用话统公式1 UnsuccessHOtimes Attemptedintercellhandovers SuccessfulintercellhandoversUnsuccessTCHtimes AttemptedTCHseizures all SuccessfulTCHseizures all TCHtrafficvolume excludingveryearlyassignment ERL Trafficperchannel AvailableTCHs 常用话统公式2 DroptaskitemsAverageuplinklevelatSDCCHcalldropAveragedownlinklevelatSDCCHcalldropAverageuplinkqualityatSDCCHcalldropAveragedownlinkqualityatSDCCHcalldropAveragetimingadvanceatSDCCHcalldropAverageuplinklevelatFullRateTCHcalldropAveragedownlinklevelatFullRateTCHcalldropAverageuplinkqualityatFullRateTCHcalldropAveragedownlinkqualityatFullRateTCHcalldropAveragetimingadvanceatFullRateTCHcalldrop PathbalanceitemsRank1 downlinklevel uplinklevel 6db 15db 常用统计项1 BERitemsquality0 biterrorrate0 00 0 20 average0 14 quality1 biterrorrate0 20 0 40 average0 28 quality2 biterrorrate0 40 0 80 average0 57 quality3 biterrorrate0 80 1 60 average1 13 quality4 biterrorrate1 60 3 20 average2 26 quality5 biterrorrate3 20 6 40 average4 53 quality6 biterrorrate6 40 12 80 average9 05 quality7 biterrorrate 12 80 average18 10 ChannelallocationitemAveragenum ofidleSDCCHsinInterf band1 5Averagenum ofidleTCHsinInterf band1 5Otherstatisticsitem SDCCH TCH HO RFloss ofeachTRX 常用统计项2 典型经验值和话统考核举例 在放号以后2天内 运营商接到全网范围内大量的用户投诉反应手机很难接入 现场网优人员通过基于呼叫流程跟踪分析的话务统计方法 做了以下步骤的工作 迅速定位到EDGE的RSSI 无线信号强度指示 版本问题上 及时采取规避措施 最大限度的减少用户投诉 立即检查了全网的所有小区参数 检查以后所有的参数都符合H公司的网规开网推荐参数 同时频率规划也满足绝大部分区域的C I C A保护门限 因此排除了在网络数据配置和频率规划上的问题 由于全网性的投诉 排除了基站硬件故障引起的接入困难 对于典型投诉小区进行的Trace跟踪功能 发现大部分的手机测量报告消息的上行电平解码都是在0 对应 110dBm以下 左右 通过基于信令流程的话务统计结果来进一步明确 通过分析多个时段的热点问题小区的ImmediateAssignment成功率 上下行接收电平统计 上下行链路平衡统计结果以后 发现大部分投诉小区的ImmediateAssignment成功率正常 而上行接收电平测量值普遍分布在0 5 对应 110 105dBm 下行分布基本正常 而上下行链路平衡统计大部分都集中在1级 对应上行衰耗比下行衰耗大15db以上 从这两个异常现象分析 接入困难案例发生时由于上行链路衰耗过大 系统根本没有收到或者无法正确解码手机上报的 ImmediateRequest ChannelRequest 消息 导致直接把该消息丢弃 因此可以基本确定和上行接收电平过小有关 由于在投诉的热点区域的基站大约120个左右的900基站 80个左右的1800基站 可以确定该问题没有频段的分布 为验证上行接入电平衰耗过大引起的接入困难问题 在热点投诉区域同时进行了适量的CQT测试 发现测试手机在下行 85dBm以下的弱覆盖区域的未接通次数明显比 85dBm以上正常覆盖区域要多的多 手机在 85dBm以下的弱覆盖基本上处于无法正常接通状态 现象就是在接通失败以后 手机屏幕上显示 ErrorConnection 信息 没有进入TCH分配阶段 而考虑到上下行的路径衰耗的差值主要在于手机和基站天线增益 以及灵敏度的区别 因此在下行 85dBm以下的电平时 上行接收电平应该在 97dBm左右 用流程和话统确定版本缺陷案例 对比同一区域两个运营商CTBC和TELEMIG网络的所有无线开网参数都相同 只有载频类型不同 TELEMIG网络全部载频都是EDGE载频 而CTBC网络的载频是大部分的普通载频 BCCH载频配置普通载频 小部分的EDGE载频 配置PDCH信道 因此在接入过程中只有普通载频和EDGE载频的区别 问题可能和载频类型有关 决定在第二天选择4个基站 2个900基站 2个1800基站 部分小区的BCCH载频替换成普通载频 其余小区替换CDU来做现场对比 其他参数都不变 对比替换以后发现 BCCH载频由EDGE载频替换成普通载频以后 在上行的电平统计值比替换前提升大约8db左右 14 在现场测试中 这部分小区的覆盖区域在手机接收电平 85dBm以下时的未接通次数比替换前明显减少 可见载频类型的替换是有效果的 而CDU替换的小区无论在上行电平 上下行链路平衡统计上 还是拨打测试效果上 都无明显的变化 于是定位基本上是EDGE载频的问题了 当天把这个对比测试结果信息反馈回H公司国际技术支持中心后定位EDGE载频的软件版本在计算RSSI无线信号强度指示的时候 人为的增加13dBm的衰耗造成上行接入困难 需要通过打软件补丁和升级版本才能解决 于是现场将上行最小接入参数RACHMin AccessLevel由默认的5 105dBm 调整到0 110dBm 的手段来临时规避 当天进行大量的拨测 基本消除上行接入困难的问题 但同时由于上行接入电平门限的减少 使得大量上行电平恶劣条件下的用户的接入请求 同时引起SDCCH和TCH掉话率的上升 05年9月 针对EDGE网络的上行RSSI版本补丁推出 在TELEMIG网络上升级以后 即使在 100dBm左右的苛刻下行接收电平的情况下 接通率基本上保持在95 以上 上行接入问题彻底消除 通过对比上行接收电平和上下行链路平衡统计 发现版本补丁升级以后 上行电平的统计值提升了大约8 12dB左右 问题处理总结 基于呼叫流程的话务统计分析方法 根据话务流程的RandomAccess接入成功率 同时结合TraceCall的上行测量报告 很容易确定由于上行接入电平原因导致的接入困难 为下一步的工作做决定性的判断 大大减轻传统分析方法中对硬件排障 在这个案例中根本无法确定硬件故障 路测等方面工作的依赖程度 Telemig网络开网以后 定位了上行RSSI问题 以及临时通过参数规避了大部分的接入困难问题 在用户的投诉单汇总中 还是发现有部分区域的上行接入困难 这次的接入困难集中在900M基站覆盖区域 结合上行RSSI接入问题的处理经验 很快就定位到900M小区的塔放上 由于TELEMIG网络做覆盖规划时作为广覆盖网络来规划上行衰耗的 因此每个900基站上都配置了塔放 而现网中的所有塔放没有统一的网管 无法确定塔放是否正常工作 在RSSI接入问题没有完全处理好以前 局方用户对于所有的塔放能够正常的工作持有怀疑态度 塔放问题应该是RSSI接入问题带来的附加问题 塔放正常工作需要三个条件同时满足 如果两个开关没有同时打开 则塔放馈电旁路 不能正常工作 而如果衰减因子设置过大 则容易认为的抬高底噪 容易引入干扰带 而如果衰减因子设置过小 则起不到上行放大的作用 Tower TopAmplifierflag需要打开 塔放开关 软开关 CDU背部的塔放供电开关需要拨到100mA位置 塔放开关 硬开关 PowerAttenuationFactor的值需要设置 TTA增益 馈线损耗4db 在检查数据库设置时 发现很多的TTA软开关没有打开 功率衰减因子的值基本上都是0 因此在硬件上配置TTA的CDU数据上统一配置了TTAflag ON 功率衰减因子 8 CDU背部的馈电开关打开还是未打开的问题上 根据硬件安装和软调的合作方工程师介绍已经全部打开 后本地工程师随机抽检10个900M基站 发现都没有打开馈电开关 后安排本地工程师对每一个900M基站CDU背部的TTA馈电开关逐个检查 发现有100来个900M基站的TTA馈电开关没有打开 用话统确定TTA配置和开关问题 在CTBC的日常话务统计过程中发现几个小区的部分载频的TCH分配失败率比较高 通过观察多个时段的TCH信道分配话统任务 发现个别载频的一旦分配上TCH就失败 分配多少次就失败多少次 导致这几个小区的TCH分配失败率 呼叫建立成功率 入切换成功率都比较差 严重情况下 长时间无信道占用 导致RadioLinkAlarm告警信息的产生 RadioLinkAlarm告警信息产生的主要原因就是长时间没有信道占用导致的 其告警产生的原因有多种 主要原因有 处于空旷地段 覆盖区域本来没有什么话务量 导致长时间的信道空闲造成 这种情况一般只要把载频复位重启 或者在该载频信道上多打几个电话就可以消除 不是严重问题 由于载频或硬件故障导致的载频长时间不能正常分配信道 产生无线链路告警 这种情况只能更换载频和故障设备 由于BSS软件版本出现的信道分配进程吊死产生无线链路告警 这种情况通过复位释放吊死的信道分配进程 在短时间内可以消除 但一段时间过后 告警重现 最终的办法只能通过升级版本或者打软件补丁的方式解决 05Q3以前大部分的无线链路告警属于这种情况 干扰导致的手机长时间无法占上载频信道 产生无线链路告警 这种情况 只要消除了干扰即可解决 载频和CDU或SCU 简单合路单元 之间的跳线错误或者跳线问题 产生无线链路告警 这种情况只要正确连接或者更换问题载频的跳线就可以解决 用话统确定硬件故障1 URJDG 3小区的TRX8载频 该小区第1块载频 基站配置2 2 2 单机柜 TRX8载频对几乎所有的TCH分配全部失败 并且有RadioLinkAlarm告警 在基站现场对该小区的两块载频倒换 更换槽位 都不能消除故障和告警 后更换载频 告警消除 信道分配成功性能正常 入切换正常 用话统确定硬件故障2 NSRDG 2小区的TRX12载频 本小区第5载频 基站配置3 5 3 两个机柜 TRX12载频对几乎所有的TCH分配全部失败 并且有radiolinkalarm告警 现网数据配置检查 该小区为SCU 2CDU的形式组合 4块载频通过SCU简单合路以后 连接到一个CDU的TX DUP端口 以减少一级合路 估计在载频和CDU之间的连线错误导致某一块载频的TCH信道分配成功率为0 后到基站现场检查 发现该小区第5块载频通过TX1端口连接到另外一个CDU 但TX COM和TX DUP的连线没有连接 导致该这载频直接发射在机房而没有发射到天线 造成这块载频的TCH