TD语音业务杂音问题优化指导书

更新时间:2023-05-08 02:15:01 阅读量: 实用文档 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

TD语音业务杂音问题优化指导书

语音业务杂音问题优化指导书

(仅供内部使用)

版权所有

大唐移动通信设备

本资料及其包含的所有内容为大唐移动通信设备(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的爱护。未经大唐移动书面授权,任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容,违者将被依法追究责任。

文档更新记录

目录

1概述 (4)

2语音杂音问题评估 (4)

2.1 语音Q O S指标要求 (4)

2.2 可能的杂音情形 (7)

3语音杂音问题CheckList (8)

4数据采集和分析 (9)

4.1 综述 (9)

4.2 N ODE B侧 (10)

4.2.1 A TP抓日志的方法 (10)

4.2.2 传输问题导致该现象的排查方法 (12)

4.2.3 NODEB侧告警抓取和分析方法 (13)

4.3 RNC侧 (14)

4.3.1 IMA物理传输的LOG抓取和分析方法 (14)

4.3.2 RNC侧QOS跟踪LOG的抓取和分析方法 (16)

4.3.3 RNC侧IUUP统计抓取和分析方法 (17)

4.3.4 语音环回使用方法介绍 (18)

4.3.5 VP环回使用方法介绍(FP层) (19)

4.3.6 VP环回使用方法介绍(IUUP层) (19)

4.4 UE侧 (20)

4.4.1 SPAN Outum软件抓取终端信令信息 (20)

4.4.2 miniPTAS软件联芯log (22)

4.5 CN侧 (25)

5案例..........................................................................................错误!未定义书签。

5.1 语音业务在切换过程中存在短暂的金属杂音 (26)

5.2 贵州省移动大楼语音质量问题 (27)

5.3 上行语音质量差 (27)

5.4 N O DA TA数据情形下显现噪音 (28)

6总结 (29)

7附录 (29)

7.1 端到端Q O S技术原理 (29)

7.2 RNC相关参数汇总 (36)

7.2.1 Iu参数配置 (36)

7.2.2 RRM算法全局参数 (41)

7.2.3 功率操纵参数 (41)

7.2.4 上行外环功率操纵参数 (47)

7.2.5 业务质量测量参数 (48)

7.2.6 业务同步参数 (51)

7.2.7 业务QoS参数调度 (54)

7.3 N ODE B相关参数汇总 (54)

7.4 其他业务Q O S保证建议 (55)

1 概述

语音业务是传统业务,衡量该业务的QoS指标有以下几个方面:

1)时延,端到端的传输时延

2)抖动

3)误码率

衡量这些指标能够用MOS来评判。

本文针对语音业务在网络优化中经常显现的杂音、甚至因为语音不清晰最终导致掉话、声音小等问题,描述了排查方法、数据采集和分析方法,并给出一些案例说明和原理、背景知识介绍。

本文定位于开局网优,比拼测试不在本文档的范畴。

本文档中所描述的内容要紧基于目前产品版本:

RNC设备,TDR2000

RNC设备,TDR3000

相关工具和命令要紧基于目前产品版本:

LDT-R(RNC告警、日志的提取和分析;传输层和无线的信令跟踪和分析;QOS跟踪分析;RNC各子系统SHELL命令的查询)。

LMT-B。

2 语音杂音问题评估

2.1 语音QoS指标要求

依照ITU相关规范,以下三个因素会阻碍话音质量:

?话音清晰度(Voice Clarity);

?话音成效,包括回声(Echo)、断续(Time-clipping)等;

?时延(Time Delay)。

由于话音成效会直截了当阻碍话音清晰度,故清晰度和时延是评估的重点。时延是一个能够精确到毫秒级的客观指标,在实际评估方面可不能有何争议;相反,人们关于清晰度一直缺乏一种统一的评判标准。依照ITU规范,清晰度应该考虑以下几个因素:?受不同网络制式中不同类型失真(Distortion)的阻碍;

?与时延无关;

?与回声无关,因为回声是对发送方而言,清晰度是对接收方而言;

在实际网络中阻碍清晰度的失真(Distortion)类型包括:

1.话音编解码(Encoding and Decoding of Voice);

2.断续(Time-Clipping,也称为Dropouts);

3.延时抖动(Jitter);

4.环境噪音(Environment Noise);

5.信号衰减(Signal Attenuation);

6.电平削波(Level Clipping);

7.传输信道误码(Transmission Channel Errors);

其中2与时延和信道质量相关,4-7都可归结为传输质量(BER/FER)

如此分解成可量化的指标要紧有3项:

(1)网络延迟:网络延迟将引起语音会话过程的空白,带来语音的变形和会话的中断。E-Model关注的是End-to-End的网络延迟。在实际应用中,一样是如下几个方面而导致了网络延迟:传播延时:取决于传播的介质和距离;传输延时:传输过程中在网络设备上所用时刻;打包解包延时:用采纳的Codec进行数模转换的时刻,不同的Codec所导致的延时是不一样的,然而关于同一种Codec,其延时差不多是固定的;抖动缓冲延时:在作用在同意端,为保持住一个或多个接收的数据包,克服网络抖动的阻碍。

(2)网络抖动:网络抖动确实是网络延时的变化,当网络抖动值大于50ms时,MOS值将急剧下降;然而在ITU-T G.107中,是如此说的:“抖动对语音传输质量的阻碍还在作进一步的研究,可通过在接收端增加抖动缓冲的量,则能够有效地降低抖动的阻碍,然而却增加了网络延时。

(3)FER或BER:FER是阻碍语音质量和MOS值的关键因素,随机出错,假如量小,对语音质量阻碍小;连续出错:这是指连续一个以上的数据包的出错,这对语音质量的阻碍是明显的。

关于语音业务QoS来说,关键三点:时延、抖动、误码率。以下是参考《MTTF E2E QoS 研究-WCDMA QoS网络KPI测试规范v1.1》以及中移动2,3期应标外厂测试得出的一些量化值。

误码率和传输抖动,在TS 23.107中有明确的定义:

AMR speech codec payload:

?Bit rate: 4,75 - 12,2 kbit/s

?Delay: end-to-end delay not to exceed 100ms (codec frame length is 20ms) ?BER:

?10-4 for Class 1 bits

?10-3 for Class 2 bits

for some applications, a higher BER class (~10-2) might be feasible.

?FER < 0,5% (with graceful degradation for higher erasure rates)

附:MPEG-4 video payload:

?Bit rate: variable, average rate scalable from 24 to 128 kbit/s and higher

?Delay:

?end-to-end delay between 150 and 400ms

?video codec delay is typically less than 200 ms

?BER:

?10-6 - no visible degradation

?10-5 - little visible degradation

?10-4 - some visible artefacts

?> 10-3 - limited practical application

关于“抖动”,一样都需要通过MOS(仪)测试,下面是宁波移动在5月份进行的抖动测试数据。另外关于IUB接口的承载要区别ATM和IP,理论分析和正常测试都说明,IP传输比ATM传输时延要小。

副本时延抖动对比

数据.xls

副本MOS数据(ATMI

P).xls

2.2 可能的杂音情形

目前差不多发觉的杂音情形如下:

?语音接入正常,音质正常(没有杂音或者间断)但不是专门清晰,通话能坚持至终止;

?语音接入正常,音质正常(没有杂音或者间断)但不是专门清晰,越来越差,但通话能坚持至终止;

?语音接入正常,音质正常(没有杂音或者间断)但不是专门清晰,越来越差,不能坚持(掉话);

?语音接入正常,一直相伴有轻微杂音,通话能坚持至终止;

?语音接入正常,一直相伴有轻微杂音,越来越差,但通话能坚持至终止;

?语音接入正常,一直相伴有轻微杂音,越来越差,不能坚持(掉话);

?语音接入正常,有突发杂音(若干次),通话能坚持至终止;

?语音接入正常,有突发杂音(若干次),不能坚持(掉话);

?语音接入正常,声音小,通话能坚持至终止;

?语音接入正常,声音小,越来越小,但通话能坚持至终止;

?语音接入正常,声音小,越来越小,不能坚持(掉话);

?语音接入正常,背景音大(超出正常范畴),通话能坚持至终止;

?语音接入正常,背景音大(超出正常范畴),不能坚持(掉话);

?语音接入正常,音质清晰但有间断;

?语音接入正常,音质不清晰相伴有间断;

?语音接入正常,音质不清晰相伴有杂音和间断;

?语音接入正常,切换时相伴金属杂音

?语音接入至响铃,振铃间隙有杂音

3 语音杂音问题CheckList

针对UE、RAN(RNC/NB分开)、CN、IU口、其他,制定CheckList,方便现场快速缩小问题范畴和定位故障。

4 数据采集和分析

4.1 综述

语音业务在接入以及通话过程中会存在各种各样的问题,然而问题定位和定位LOG的采集一样方法都专门通用;

(1) 语音业务接入过程中信令失败的定位方法

第一假如语音在接入过程中信令失败,按照哪个网元返回失败那个网元先定位的原则,假如信令过程是终端、NODEB、CN返回的失败,一样除带有明显的错误缘故外,第一需要其他网元分析失败的缘故和抓取相应的LOG进行定位。

其次假如接入过程是RNC返回失败导致业务接入失败,那样一样需要先抓取小区详细级(带有RNC内子系统的信令交互过程,能够方便定位是哪个子系统返回德失败)信令跟踪来分析,一样内部失败都会带有失败缘故,依照失败缘故查找错误码表,找到对应的错误;另外需要依照失败缘故采纳对应的SHELL命令查找核对对应的资源信息,最后是依照失败返回的子系统,在LDT上开启对应得打印消息,抓取打印分析;如此一样的RNC问题就能够得到定位和解决。

(2) 语音业务通话过程中问题的定位方法

一样语音业务保持过程中,会存在掉话、切换失败、有杂音等问题,掉话和切换失败一样同上面的信令失败的定位方法,有杂音问题是在业务保持过程中存在丢弃数据包造成的,要紧是定位在那个接口(IU、UU、IUB)或者网元内部丢弃了数据包造成,目前各个网元差不多都提供了定位的手段。

RNC能够通过QOS跟踪来定位IUB口上行的数据是否存在丢包,假如存在丢包,则需要先查传输层是否有丢包,然后再依照业务处理的IUUP统计和业务处理计数器统计来定位是否在IUB口和RNC内部存在问题;另外RNC提供了语音环回功能,能够定位接入网内是否有问题;

NODEB也提供了数据环回功能,能够定位空口到NODEB内部是否有问题,另外NODEB也提供了动态查询物理传输是否存在丢包的功能,能够方便定位物理层是否有问题。

终端问题一样比较难定位,一样方法确实是通过终端物理层抓取软件(TT)和信令抓取软件(outum)对终端物理层何信令进行分析,另外也能够通过不同厂家的网络来进行对比测试验证,来定位是否是终端的问题。

CN的问题一样接入网人员专门难定位,一样需要借助CN侧专用分析工具才能够解析LOG来分析定位,一样假如定位到CN问题,能够找CN支持人员直截了当定位即可。

语音排查流程图如下:

4.2 NodeB侧

基站侧需要做好的工作:

?查询基站软件版本、固件版本、一单开站中的时钟信息。

?查询小区的ID、频点、码字。

?理清“频点-BBU-RRU”的对应关系。

?查看小区ISCP的情形。

?提取公共日志(初始化日志、告警日志、数据一致性文件、动态配置文件)、CCU41/43号日志、BBU全部日志、ATP消息。

4.2.1 ATP抓日志的方法

1.BCP消息跟踪,打开菜单“消息跟踪->跟踪设置”:

APB-PL 、PL-APB、APS-APB、APB-APS、APB-FP,用于跟踪BBU内部信令流程。RNC-FP,用于抄出FPRNC、RNCFP的消息。

GTS-L2,用于抄出FPCC的消息。

PL-GTS,用于抄出PL的消息。

文件自动覆盖条件,按照实际需求设置,一样取默认值,能够大些50M。

2.DSP之间相关消息跟踪,打开菜单“消息跟踪->测试消息设置”:

O_M1FC_INSTANT_TS,分析物理层测量上报。

O_SJCC_DATA,分析上行数据解调结果。

O_CCBC_VRU_DATA,分析CC给BC数据。

O_FCBC_CONTROL_DATA,分析下行发送功率和上行功控命令字。

O_CCFC_RL_SYNC_IND,分析FC同步结果。

O_FPFC_SIR_TARGET,分析外环功控结果。

CC的10号FPCC。

FP的11号FPRNC。

FP的12号RNCFP。

FP的13号CCFP,option3设置为255,分析CRCI译码结果。

需要按照现场实际情形设置跟踪的频点号。

3.确认消息跟踪完整

显现问题后,不要赶忙关闭,等待10s左右关闭LOG。

在日志中搜索“CRNC_CC_ID=”,找到显现问题的ID(能够由RNC提供,也能够找到完整消息后向RNC确认CRNC-CommunicationContextID)。

确认ID(如49821)后,搜索“CRNC_CC_ID=49821”,找到第一条消息对应的消息名应该是O_APSAPB_RL_SETUP_REQ,最后一条消息对应的消息名应该是O_APSAPB_RL_DEL_REQ。如此,就找到了一个完整的消息。

截取两条消息之间的内容,搜索各关键字,看各关键消息是否抓到。如M1FC、CCBC、RNCFP、CCAPB等。

4.2.2 传输问题导致该现象的排查方法

1.提取显现问题站点的告警日志。查看告警日志,具体操作方法参见4.

2.3。

检查是否存在大量“FP下行DCH CRC校验错误”和“FP收到TFI错误”告警。

说明:少量马赛克,上述告警次数的量级在个位数的级别;明显马赛克,上述告警次数量级在100以上;大量马赛克,上述告警次数量级在1000次以上。

2.用-B连接问题NB,查询IMA信息->链路性能统计,刷新并关注各条激活IMA链路的

“帧失步”和“接收非法ICP信元”、“接收STUFF信元数”统计。

检查是否存在某条或某几条IMA链路的“帧失步”和“接收非法ICP信元”统计非零,统计值约为2个/秒的频率;”、“接收STUFF信元数”统计值为0。假如存在则记录下该IMA 链路的“逻辑链路号”。

以下是可选步骤:

3.在该站点下做VP业务,观看每次做VP业务时是否一定相伴大量NB FP 的下行DCH

CRC校验告警(注意要等待一个告警过滤周期的时刻)。

4.能够在RNC上用命令行查询RNC的IMA发送统计信息,直截了当能够看到发送stuff

计数。假如某一路发送stuff统计一直为0,而其他统计参数正常,再结合步骤2)的结果即能够确认该问题。

假如同时存在(1)(2)((3))中所描述现象,则重点怀疑是目前RNC侧IMA传输(驱动)发送的问题。

4.2.3 NODEB侧告警抓取和分析方法

使用LMT-B工具。

1)NODEB告警抓取方法如下图:

说明:登陆LMT-B后,选择文件,然后上传需要的各种日志

2)告警打开分析方法如下图:

3)NODEB常见告警分析

一样通过NODEB告警能够看出物理传输层的问题和NDOEB本地小区以及载波是否存在问题,假如NODEB本地小区或者载波有问题,在告警中也能够看到相应的告警,如此就能够判定NODEB本地小区和载波是否有问题。

4.3 RNC侧

使用LDT-R工具。

4.3.1 IMA物理传输的LOG抓取和分析方法

1)在RNC侧接口板主CPU的SHELL上查询以下信息猎取传输层IMA组和IMA链路信息

drv_ima_ldt_group_count 芯片号, IMA组号

drv_ima_ldt_imalink_count 芯片号, 链路号

drv_ima_ldt_task_count_print 芯片号, 0, 6

drv_ima_ldt_task_count_print 芯片号, 1, 9

drv_ima_ldt_imalink_event 芯片号, 链路号

drv_ima_ldt_imalink_alarm 芯片号, 链路号

2)分析方法:

drv_ima_ldt_group_count 芯片号, IMA组号

//查看打印结果是否有丢弃计数,假如IMA组存在信元丢弃统计,下一步在RNC侧才需要确认是那些链路上有信元丢弃,需要查询IMA组内各个链路的信元统计情形;假如不存在,以下链路的统计命令则不需要执行,说明该IMA组工作正常

drv_ima_ldt_imalink_count 芯片号, 链路号

//查看打印结果中发送stuff信元个数,假如IMA组工作专门,查看RNC侧STUFF 信元发送统计,假如RNC侧不发送STUFF信元(银川IMA传输问题),则说明RNC侧IMA工作专门。

drv_ima_ldt_task_count_print 芯片号, 0, 6

//查看打印结果中IMA组添加、删除的计数;当显现IMA组工作专门后,需要查询该统计以确认显现问题时是否进行过频繁的删除、添加操作依旧因为IMA闪断引起的IMA 工作专门

drv_ima_ldt_task_count_print 芯片号, 1, 9

//查看打印结果中IMA链路添加、删除的计数;当显现IMA组工作专门后,需要查询该统计以确认显现问题时是否进行过频繁的删除、添加操作依旧因为IMA闪断引起的IMA工作专门

drv_ima_ldt_imalink_event 芯片号, 链路号

drv_ima_ldt_imalink_alarm 芯片号, 链路号

//查看打印结果中IMA链路的告警计数;当IMA组统计有信元丢弃时,再采纳该命令查看IMA组内的那些IMA链路存在告警,以确认IMA组内的那些链路故障。

4.3.2 RNC侧QOS跟踪LOG的抓取和分析方法

1)QOS跟踪抓取方法如下图:

2)QOS跟踪分析方法如下图:

3)分析方法:选择QOS跟踪界面的QOS分析,RNC侧只能分析上行QOS,针对语音业务,28S内的上下行TB块数应该保持一致,一样语音业务正常的TB块数为

4200个(28s/20ms*3(语音业务块数)),假如上行有误块,说明传输或者NODEB

到RNC的处理数据有问题。如UE是否只在在切换过程中存在误码,第一在位置

不变得情形下保持通话,看QOS跟踪是否恒定在4200块,没有误码,现在移动

UE,使得UE发生切换(在UE的工程信息和OMT上的小区内UE信息查询都能

够查询UE是否进行了切换),然后看切换发生的28S内是否存在误码,然后再保

持一段时刻,看28S内的数据块和误码是否复原正常,就能够确定是否是切换引起

的误块。

4.3.3 RNC侧IUUP统计抓取和分析方法

1)从LDT信令跟踪上确认需要环回语音的用户所在RTPA和DSP号,具体方法如下:

在RAB指派后RNC本地资源分析消息中,查看倒数第二个响应消息,依照

RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,依照DSPIP的最后一个字节确认在9号CPU(DSP)。

2)在1-2-13 9CPU的模拟shell上敲:

rnc_tpss_iuup_shell

3)分析方法:一样查看语音从正常到有杂音前后IUUP统计那些错误统计项有变化。

当语音正常没有误码时,IUUP错误统计项坚持不变,当发生切换等产生误码后,

IUUP错误统计项统计发生变化,说明有误码产生。

4.3.4 语音环回使用方法介绍

1)从LDT信令跟踪上确认需要环回语音的用户所在RTPA和DSP号,具体方法如下:

在RAB指派后RNC本地资源分析消息中,查看倒数第二个响应消息,依照

RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,依照DSPIP的最后一个字节确认在9号CPU(DSP)。

2)在1-2-13 9CPU的模拟shell上敲:

rnc_tpss_iuup_sm_loop_para_set 1,UEID

如此能够打开此用户的语音环回功能,其他用户不受阻碍。

rnc_tpss_iuup_sm_loop_para_set 0,UEID

则关闭此用户的语音环回功能。

4.3.5 VP环回使用方法介绍(FP层)

1)第一依照信令跟踪分别找到主被叫用户所在DSP:

在RAB指派后RNC本地资源分析消息中,查看倒数第二个响应消息,依照

RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,依照DSPIP的最后一个字节确认在9号CPU(DSP)。

2)在RNC FP层进行环回:

打开环回:在用户所在DSP的模拟shell窗口中敲:

rnc_tpss_fp_vp_loop UeID, 0, 16777216, 0 (UEID依照信令跟踪中确定)

关闭环回:在用户所在DSP的模拟shell窗口中敲:

rnc_tpss_fp_vp_loop UeID, 0, 0, 0

4.3.6 VP环回使用方法介绍(IUUP层)

1)第一依照信令跟踪分别找到主被叫用户所在DSP

在RAB指派后RNC本地资源分析消息中,查看倒数第二个响应消息,依照

RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,依照DSPIP的最后一个字节确认在9号CPU(DSP)。

2)在RNC IUUP层进行环回:

打开环回:在用户所在DSP的模拟shell窗口中敲:

rnc_tpss_iuup_vp_loop UeID, 0, 16777216, 0 (UEID依照信令跟踪中确定)

关闭环回:在用户所在DSP的模拟shell窗口中敲:

rnc_tpss_iuup_vp_loop UeID, 0, 0, 0

4.4 UE侧

目前UE侧数据采集一样能够使用两种软件:

1.SPAN Outum 5.0

2.miniPTAS

4.4.1 SPAN Outum软件抓取终端信令信息

Outum软件(SPAN Outum 5.0)能够抓取终端的各项测量信息和层三信令抓取各项测量信息的方法。

第一步:在outum软件的选择“Line chart”->在弹出的“Line chart”窗口->点击右键选择“属性”->在弹出的“设置Chart属性”窗口->点击“修改”如下图:

第二步:在弹出的窗口中,在左侧选中需要添加的测量IE,单击“添加”->将选择的IE添加到左侧菜单中。

在例子中添加一些测量值,具体测量值能够依照需要进行添加。

第三步:单击“确定”键后,完成添加,能够在“Line chart”窗口看到测量结果,完成测试后储存LOG,能够储存测试结果,供大伙儿分析。

抓取层三信令的方法:

第一步:在outum软件的选择“UU口消息”在弹出的窗口能够看到UU口的消息,双击每条信令能够看到每条信息的详细IE,在“UU口消息”界面右键弹出列表后,点击“Export Results”能够将UU口消息名、时刻戳等储存出来。

本文来源:https://www.bwwdw.com/article/wc2e.html

Top