葫芦岛课题研究呼叫时延问题验证分析报告Word格式文档下载.docx

葫芦岛课题研究呼叫时延问题验证分析报告Word格式文档下载.docx

《葫芦岛课题研究呼叫时延问题验证分析报告Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《葫芦岛课题研究呼叫时延问题验证分析报告Word格式文档下载.docx（21页珍藏版）》请在冰豆网上搜索。

8.28

鞍山

8.39

辽阳

8.59

锦州

8.94

葫芦岛

9.04

抚顺

9.1

大连

9.16

丹东

9.86

营口

9.87

本溪

10.63

查看大唐与华为的UE测试LOG，大唐与华为的整体呼叫流程一致，通过对比各个信令点时延直观发现大唐的RB建立周期（UE收到RADIOBEARERSETUP到UE回复RADIOBEARERSETUPCOMPLETE）比华为长500ms左右.

而爱立信的核心网的RAB指派是主被叫串行执行，CN收到被叫CALLCONFIRM后先进行主叫RAB指派，主叫完成后进行被叫RAB指派，RAB主被叫串行处理机制导致在RB建立周期和华为拉出500MS*2=1s左右的差距，放大了RB建立时长对呼叫时延的影响。

所以目前来看目前主要分为两个问题：

1.大唐RNC的RB建立时长较长

2.爱立信核心网RAB指派为主被叫串行执行进一步拉大主被叫的整体RAB建立时长

2呼叫时延问题分析

2.1大唐RNC的RB建立时长分析

在TDD系统中，为了保证RNC和UE能够同时使新配置参数生效，RNC在发送重配置命令时，一般会携ActivationTime参数，设置新配置的生效时间。

ActivationTime定义了操作和变化的生效时间，以CFN为参考时间，取值为[0,255]。

终端接收到的重配置命令中携带ActivationTime参数，该参数如果不为“Now”，那么UE需要在ActivationTime时刻指定的TTI边界完成配置转换。

RNC在计算这个时间时，需要获得发送信令时刻的NowCFN，考虑处理时延（包括传输时延），通过如下公式计算出生效时刻：

ActiveTime=（NowCFN+CfnOffset）%256

CFNOffset与发送信令的长度，信令采用的速率和承载方式，已经无线环境都有关系。

CFNOffset的配置需要保证在激活时间超时前，网络和UE的配置操作已经完成，否则可能会导致UE无法正确获得重配置信令，从而引起同步配置过程的失败。

但是，如果这个参数配置过大，有会延长配置过程的时间，影响呼叫时延等网络性能指标。

现在系统中，对CFNOffset参数，是采用静态配置方式处理的。

采用静态配置方式为了避免信令无法被UE正确收到，一般都采用了较保守的配置，是造成MMC呼叫过程中RB建立时间较长的主要原因。

2.2核心网RAB指派机制分析

2.2.1爱立信核心网RAB指派机制分析

葫芦岛CS域核心网厂家为爱立信。

下图2为RNC侧的CallTrace跟踪，可以跟踪到IU、UU、IUB口的信令流程。

由图表2中可以看到RNC向核心网回复被叫（UEID=32782）直传消息CALLCONFIRMED后未收到核心网下发被叫的RAB指派消息，只收到核心网10：

33：

42对主叫UE的RAB指派消息，主叫UE（UEID=32781）RB建立完成后10:

33:

44RNC向核心网回复RABASSIGNMENTRESPONSE，核心网收到主叫的RABASSIGNMENTRESPONSE后对被叫进行RAB指派，可以看到目前网络中主被叫的RAB指派消息是串行的，整个过程将会多出1个RAB指派周期，目前的RAB指派周期在2S左右，所以串行的RAB指派机制将会大幅加大接续时长的开销。

图表2主被叫的RAB指派过程

下图3为相关的UU口信令截图，可以看到主被叫的RB建立为串行执行，主叫在10：

30：

24：

328向网络侧上发RBSETUPComplete，被叫在10：

421收到网络侧下发的的RBSETUP消息。

图表3UU口主被叫RB建立串行执行

下图4、5为在新疆现场抓取的CallTrace跟踪，CS域核心网为爱立信。

图表4为主叫，图表5为被叫，在图中可以看到，11：

45：

30主叫UE收到CN下发的CallProceeding消息进入等待，图表5可以看到被叫UE在11：

33CN收到被叫的CallConfirm消息进入等待，图表4中主叫UE侧RNC在11：

33收到CN下发RABASSIGNMENTREQUEST，随后在11：

35完成RAB指派向核心网回复RABASSIGNMENTRESPONSE，图标5中被叫UE在11：

35收到CN下发的RABASSIGNMENTREQUEST，在11：

37完成RAB指派，整个过程和辽宁现场的爱立信核心网RAB指派过程一样，主被叫的RAB指派过程为串行，主被叫UE需要各自等待对方RAB指派周期，严重影响呼叫时延。

图表4主叫UE的CallTrace跟踪

图表5被叫UE的CallTrace跟踪

爱立信的MMC的整理流程可以简单描述如下：

图表6爱立信MMC流程图

2.2.2中兴核心网RAB指派机制分析

下图7为保定现网抓取的呼叫流程CallTrace跟踪，CS域核心网厂家为中兴。

可以看到主被叫的RAB建立为并发执行的，主被叫（主叫UEID=35961、被叫UEID=36016）在12：

09：

35同时收到核心网的RABASSIGNMENTREQUEST指派消息，在12：

37几乎同时完成RB建立，整个主被叫的RAB周期一共2S，将大幅节省呼叫时延开销。

图表7主被叫RAB指派并行执行

中兴整体MMC流程图可以简单描述如下：

图表8中兴MMC流程图

2.2.3华为核心网RAB指派机制分析

下图9为兰州现网抓取的CallTrace跟踪，核心网厂家为华为。

由图中可以看到，主叫UE（UEID=102020）在11：

48：

55收到CN下发的CallProceeding，500ms后RNC侧立刻收到CN下发的针对主叫的RAB指派请求，800ms后被叫UE（UEID=100463）开始寻呼响应，主叫RB建立和被叫的寻呼响应为并发执行的，在被叫的寻呼响应过程中主叫UE完成了RAB指派，随后主叫UE等待被叫UE的RAB指派完成收到ALERTING完成起呼。

整个过程同样比爱立信核心网实现流程节省一个RAB指派周期，大幅缩短呼叫时延。

图表9华为RAB指派实现机制

华为整体MMC流程图可以简单描述如下图所示：

图表10华为MMC整体流程图

2.2.4各个厂家爱核心网RAB指派机制总结

各个厂家核心网的RAB指派机制在相关协议里面并没有明确规定，所以各个厂家RAB指派机制不同直接影响到下挂RAN的呼叫时延，中兴和华为的RAB指派机制整体比爱立信减少一次RAB建立时长，所以爱立信核心网大幅增加MMC情况下的呼叫时延。

3呼叫时延问题处理

通过前期沟通了解到爱立信厂家暂时无法更改MMC情况下的RAB指派流程，所以在大唐公司导入辽宁移动需求,在40版本进行导入,在后台支持的情况下，现场确定如下处理方法：

1.RNC进行Uu接口消息瘦身，减少消息中不必要的可选IE减少消息长度，可配置更低信令传输时延，降低RB建立过程。

2.目前RNC产品继承TDR2000产品时对于寻呼处理内部保留了小于100ms的保护时间，经过评估该保护时间可以删除该保护时间改善MMC呼叫试延。

经过试验室测试可减少300ms~400ms之间。

3.RNC侧参数修改：

SYNC算法和T2定时器

在省公司的协调下计划于7月中旬进行版本升级，升级后完成处理方法1、2.，随后进行参数修改验证，在修改前后进行拉网测试和KPI观察，确保网络的持续稳定。

3.1RNC版本升级

7月21日现场进行RNC版本升级为40版本，升级后进行测试对比升级前后的RadioBearerSetu消息的解析内容，发现升级后RadioBearerSetup已经不携带“rb-nformationAffectedList”，整个解码消息较升级前大幅缩减。

，如下图所示:

解码消息原始文件列表：

下表1为升级前，下表2为升级后

升级后进行区域内拉网测试，发现呼叫时延较升级前有大幅下降，测试呼叫时延为8.26S。

试呼次数

接通次数

掉话次数

PCCPCH总采样点

PCCPCHRSCP>

=-95dBm&

C/I>

=-3采样点

DPCH总采样点

DPCHC/I>

接续时长（s）

主叫

被叫

15

6081

6062

6072

6006

3012

2859

3011

8.26

3.2SYNC算法和T2定时器

在40版本基础上，进行现网参数优化调整，呼叫时延的优化主要涉及2个参数修改：

1.修改小区中的SYNC算法参数

2.修改RNC的T2定时器

3.2.1修改小区中的SYNC算法参数

目前小区SYNC算法中SRB传输时延设置1.2秒，导致呼叫时延比其它厂家的呼叫时延多出1秒左右，经实验室初步测试减小这个时延可以减小呼叫接入时延，所以建议标参、ODG、OMC同步修改此值为0.46～0.60秒内。

由于早期的网络覆盖和终端的不稳定，因此这些值取的比较大，尽量减少呼叫失败的发生次数。

目前的网络覆盖已经很好，终端的稳定性也有很大的提高，因此有条件修改这些参数。

修改后，接续时延预计优化600ms左右。

现场SRB传输时延设置如下图所示：

现场将SRB传输时延由120帧修改为90帧，如下图所示：

3.2.2修改T2定时器

以前设计该定时器用于等待因为配置不支持等情况的UE失败消息，实际使用中，因为分资源时已经考虑了UE能力，所以已经规避此种情况；

而且，ToUEDelay里面包括T2的时长，如果T2长，ToUeDlay也需要相应增加。

因此，这个参数对系统的影响不大，主要是起保护作用。

修改方法如下图所示：

3.3DT和KPI情况

现场在8月16日完成RNC版本升级和参数修改，随后进行拉网测试和KPI指标观察确保现场网络情况的持续稳定，通过路测发现呼叫时延有300MS左右改善，没有异常事件发生，KPI指标也保持稳定。

3.3.1路测情况

修改现场组织进行测试，接续时长为：

7.99S，较修改前有300MS左右改善，没有异常事件发生。

10

8262

9963

8244

9944

5700

6291

5679

6285

7.99

呼叫时延UU口信令截图如下图所示，可以看到RRCConnectionRequest到Alerting时延为7.64S

3.3.2KPI情况

8月份正月指标情况如下图所示，8月底的时候由于个别营业厅异常上网行为导致的指标波动外，其它时间KPI指标保持持续稳定

8月16日完成参数修改，观察8月份平均指标情况，如下图所示：

PS掉话率指标在8月26日到8月30日指标异常是有由于个别营业厅异常上网行为导致，已经确认处理。

语音掉话率在8月31日指标异常也是由于个别营业厅异常上网行为导致，已经确认处理。

3.4葫芦岛验证情况

在以上基础上，葫芦岛于9月19日进一步修改小区的SYNC算法参数。

现场将SRB传输时延由120帧修改为60帧，如下图所示：

3.4.1路测情况

21

7.33

呼叫时延UU口信令截图如下图所示，可以看到RRCConnectionRequest到Alerting时延为7.28s

与9月10日葫芦岛3方测试呼叫时延进行对比

各信令阶段所用时间

修改参数前

时间/s

修改参数后

对比差异值/s

rrcConnectionRequest—Setup

1.22

1.15

0.07

Setup—CallProceeding

0.24

0.22

0.02

CallProceeding—radioBearSetup

2.91

2.84

radioBearSetup—radioBearSetupComplete

1.26

0.58

0.64

radioBearSetupComplete—Alerting

3.20

2.51

0.69

呼叫时延总时间

8.83

7.33

1.50

从时间差异对比发现主要呼叫时延缩短在RB建立时间和RB建立完成后到振铃Alerting时间。

符合参数修改预期目的。

3.4.2KPI情况

修改该参数后9月份后半月到10月8日的KPI情况如下，指标保持稳定，没有异常波动。