中兴TD UCIU_error问题缓解方案.doc

UCIU-ERROR掉话问题 现在UCIU-ERROR导致的掉话问题大量存在，因此结合23日10：00-12：00时间段内RNC3的统计，我们整理了前期测试过程中的特殊案例，对其中比例较大的挂机过程的UCIU-ERROR问题提出缓解的思路。 11月23日10：00-12：00时间段RNC3统计 时间段内共掉话45次，其中UCIU-ERROR 33次，比例73.3%。UICU-ERROR事件发生的信令过程分布如下表所示 流程 挂机过程 接入过程 切换过程 接入 切换并发 总计 次数 20 8 3 2 33 比例 60.61% 24.24% 9.09% 6.06% 100.00% 在测试过程中，我们发现有切换过程、挂机过程导致的UCIU-ERROR掉话，与大家分享。 切换过程掉话radio link restore indication 现象描述 优化方案 可能IUB口信令存在问题，或者在处理过程中存在信令丢失。 挂机过程UE掉话-UCIU-ERROR 现象描述 路测的log 1、主叫挂机 2、被叫收到”disconnect”同时上报“release”流程正常。 3、RNC（CN）未收到UE的“release”，2秒后UE收到CN下发“release”。信令正常。 优化建议 优化核心网定时器设置，核心网RELEASE下发过快。使得UE上报2次RELEASE（核心网计数器、定时器）的机制无效。 前期测试中挂机过程（定时器设置与此不同） 根据统计，近期UCIU-ERROR导致的掉话比例有所提高，西南海淀区9月份-11月10日掉话原因统计如下表所示。因此我们怀疑可能与部分参数的修改或者用户量增加导致的干扰有关。 提取前期的测试案例，发现可能存在核心网定时器、计数器的调整使得UCIU-ERROR的比例增加。 测试案例 UE在收到“alerting”后，然后收到“disconnect”原因值为“no user responding”。可能是被叫原因造成的接入失败，见下图。 观察被叫UE状态，被叫UE正在进行上次呼叫的链路释放，收到“disconnect”后，未收到“release”消息，因此30秒后发送“release”消息，而且主叫起呼期间，被叫未收到“paging”消息。 属于链路释放慢造成的接入失败。 案例启发 由此案例可以看出，在终端UE收到“disconnect”后，可以发送2次“release”请求，时间间隔为30秒 在UCIU-ERROR的掉话案例中，可以看出，CN发送““disconnect”后2秒，下发了“release”，也导致终端UE不会发送第二次“release”。 如果合理设置挂机过程的核心网计时器、计数器，可能可以避免部分UCIU-ERROR导致的掉话。 总结 核心网现在设置定时器，使得终端UE无法正常上报2次“release”请求。 如果合理设置相关的定时器，使得核心网在下发“disconnect”后，在下发第一次“release”前，UE可以上报两次“release”请求，可能可以极大的缓解UCIU-ERROR导致的掉话现象。建议核心网定时器设置如下图所示。 上图中，实线是现在看到UCIU-ERROR掉话过程的信令流程图，实线和虚线是期望调整的信令流程图。 在掉话的信令中，CN收不到UE上行的“release”或者“release complete”消息，导致掉话。 如果调整定时器设置：T1t1+t2，则，在CN下发“release”前，UE有两次上报“release”请求机会，可以减少掉话。 如果在T1内，UE不能与CN正常通信，则T2、T3设置过大也无实际意义，可能用户已经主动进行了释放。 建议： 核实核心网定时器设置2s/5s的设置理由，在设置定时器时，核心网、接入网、UE必须综合考虑。核心网在下发“disconnect”后，在下发 “release”定时器设置可能影响核心网指标“来电接通率”。 与核心网人员咨询所有与挂机过程相关的定时器、计数器设置，从信令流程上规避该类问题。 经核查，协议定义， 与T1相关计时器：T305,T306,T338(≤T306) 与T2相关计时器：T308 与t2相关计时器：T308 建议： T1（T305,T306,T338）设置3～5秒，T2设置2秒，T3（T308）设置1～2秒，t2（T308）设置2秒。