葫芦岛-课题-研究呼叫时延问题验证分析报告.doc

葫芦岛呼叫时延问题分析处理报告 ——进一步验证分析报告 呼叫时延问题背景 辽宁目前6个地市的呼叫时延均在9S左右，CS域核心网均为爱立信，华为RNC在爱立信核心网下呼叫时延为7.3S左右，华为的RNC配合华为的CS域核心网呼叫时延在6S左右，辽宁省华为和爱立信核心网接入区域存在较大差距。 在日常测试中爱立信核心网接入区域的呼叫时延总体大于8S，影响客户使用感知度，下表为7月份省公司第三方拉网测试的各个城市的接入时延情况。 测试省份 测试城市 TD平均接入时长 核心网厂家 辽宁 铁岭 6.61 华为 阜新 6.72 朝阳 6.75 沈阳 8.24 爱立信 盘锦 8.28 鞍山 8.39 辽阳 8.59 锦州 8.94 葫芦岛 9.04 抚顺 9.1 大连 9.16 丹东 9.86 营口 9.87 本溪 10.63 查看大唐与华为的UE测试LOG，大唐与华为的整体呼叫流程一致，通过对比各个信令点时延直观发现大唐的RB建立周期（UE收到RADIO BEARER SETUP到UE回复RADIO BEARER SETUP COMPLETE）比华为长500ms左右. 而爱立信的核心网的RAB指派是主被叫串行执行，CN收到被叫CALL CONFIRM后先进行主叫RAB指派，主叫完成后进行被叫RAB指派，RAB主被叫串行处理机制导致在RB建立周期和华为拉出500MS*2=1s左右的差距，放大了RB建立时长对呼叫时延的影响。 所以目前来看目前主要分为两个问题： 大唐RNC的RB建立时长较长 爱立信核心网RAB指派为主被叫串行执行进一步拉大主被叫的整体RAB建立时长 呼叫时延问题分析 大唐RNC的RB建立时长分析 在TDD系统中，为了保证RNC和UE能够同时使新配置参数生效，RNC在发送重配置命令时，一般会携Activation Time参数，设置新配置的生效时间。Activation Time定义了操作和变化的生效时间，以CFN为参考时间，取值为[0,255]。终端接收到的重配置命令中携带Activation Time参数，该参数如果不为“Now”，那么UE需要在Activation Time时刻指定的TTI边界完成配置转换。 RNC在计算这个时间时，需要获得发送信令时刻的NowCFN，考虑处理时延（包括传输时延），通过如下公式计算出生效时刻： Active Time =（NowCFN + CfnOffset）% 256 CFNOffset与发送信令的长度，信令采用的速率和承载方式，已经无线环境都有关系。CFNOffset的配置需要保证在激活时间超时前，网络和UE的配置操作已经完成，否则可能会导致UE无法正确获得重配置信令，从而引起同步配置过程的失败。但是，如果这个参数配置过大，有会延长配置过程的时间，影响呼叫时延等网络性能指标。 现在系统中，对CFNOffset参数，是采用静态配置方式处理的。采用静态配置方式为了避免信令无法被UE正确收到，一般都采用了较保守的配置，是造成MMC呼叫过程中RB建立时间较长的主要原因。 核心网RAB指派机制分析 爱立信核心网RAB指派机制分析 葫芦岛CS域核心网厂家为爱立信。下图2为RNC侧的Call Trace 跟踪，可以跟踪到IU、UU、IUB口的信令流程。由图表2中可以看到RNC向核心网回复被叫（UE ID=32782）直传消息CALL CONFIRMED 后未收到核心网下发被叫的RAB指派消息，只收到核心网10：33：42对主叫UE的RAB指派消息，主叫UE（UE ID=32781） RB建立完成后10: 33: 44 RNC向核心网回复RAB ASSIGNMENT RESPONSE，核心网收到主叫的RAB ASSIGNMENT RESPONSE后对被叫进行RAB指派，可以看到目前网络中主被叫的RAB指派消息是串行的，整个过程将会多出1个RAB指派周期，目前的RAB指派周期在2S左右，所以串行的RAB指派机制将会大幅加大接续时长的开销。 图表 2主被叫的RAB指派过程 下图3为相关的UU口信令截图，可以看到主被叫的RB建立为串行执行，主叫在10：30：24：328向网络侧上发RB SETUP Complete，被叫在10：30：24：421收到网络侧下发的的RB SET UP消息。 图表 3UU口主被叫RB建立串行执行 下图4、5为在新疆现场抓取的Call Trace跟踪，CS域核心网为爱立信。图表4为主叫，图表5为被叫，在图中可以看到，11：45：30主叫UE收到CN下发的Call Proceeding消息