学习关注中。。。

可以通过调整T313、N313、N315三个定时器参数试试，无线链路失步后，由这三个参数控制。

楼上可否详细解释下

有一点补充的是，现场测试到的大部分的掉话前，位置更新请求发出后10S左右都无响应，最终产生异常掉话。


还有二楼说的可能不会起作用，希望你能仔细看再说。。。还有你的专家指数是负值。。。

专家指数 他只是说了几个参数 并没有太关注次问题的所以忽略好了

如果之前配了IUR数据，但是实际没有调通IUR接口，有可能RNC会去尝试通过IUR接口的软切换而导致切换失败。

这位仁兄说的情况应该不存在，因为没有定义IUR，也没有配置IUR数据，帖子上第7条已经说明了，并且这两个地市边界区域的站各自归属同一个RNC，且其他站的指标正常。是否还有分析此问题的其他思路？

通话过程中应该不会发生位置区更新请求吧，华为的设备定义的有RNC迁移过程，爱立信的难道有？另外你说的位置区更新请求在本市的发起的还是另外一个地市发起的，或者只要触发这一流程掉话的风险就加大？

原帖里写错了，是RA路由区更新，全部都是RA得更新请求无响应。帖子我修改了一下，不好意思。
这个掉话现象，本市的小区在和另一个地市发生切换以及反向切换都有，且全都是切换后的路由区更新请求无响应导致异常释放。在那个站发生边界切换的区域，确实是，只要触发这一流程，掉话的风险就加大，但也不是全部都掉。回放现场测试数据，几十次的通话里面，有十几次掉话的无一例外全部是RA更新无响应。
参数配置方面，核查了这个站附近的另外一个站的参数配置，以及和另外一个地市的边界小区的参数配置，都是一样的，更诡异的是，10月份的KPI里面竟然统计到C小区有3次软切换请求，而且都成功。每天的软切换请求里边也有请求。。。。但是其他边界站就没有这些的问题。
是否还有其他建议？敬请赐教

现场测试本市其他站和另一个地市切换正常吗，同样会触发RA更新请求且都成功？
方便的话发个log过来吧
aliubisi@126.com

其他站正常。LOG随后送到

路测数据上看PSC101到PSC35切换时，RNC迁移未完成，产生掉话；而PSC101到（PSC43、PSC364）时，RNC迁移成功；反过来PSC364、PSC35到PSC101的两次迁移均成功，所以排除RNC迁移功能未打开可能，具体到小区，建议先进行RF调整，尤其PSC101和PSC35，跨切换频繁，建议由PSC101覆盖.
另PSC0101和PSC59能发生软切换，（PSC43、PSC364）和PSC59也能发生软切换，为何PSC101和（PSC43、PSC101）需要通过Radio Bearer Reconfiguration来完成跨RNC硬切换流程

天线调整的工单早在半个月之前就发了，但是另外那个地市的天线调整推动的很慢，一直没给调，说是得到这个月中旬。
昨天又查了一遍参数，59这个扰码很诡异。对应的这个小区实际应该是对方地市的，但是邻区定义成了我们这边的小区号，而且我们这边的SC59的小区根本不可能和101发生切花，小区朝向不一样而且还相隔十几公里。
测试数据中，SC101SC117这两个扰码使我们这边的那个边界站。其他的35、43、59、348、364是对方地市的扰码。这样的话疑点就是，为什么这一条邻区明明定义错了，但为什么还能发生软切换？下行以扰码区分小区，难道即使配错了也能切换成功么？
还有，有人和我说通话过程中不应该有RA更新，但是我觉得像这种跨地市跨RNC的切换必然要有RA更新，即使是通话过程中也应该有的。这一点上还不太懂，需要与你讨论。
昨天看了一下对方RNC和我们这边的RNC之间配置的虚拟IUR设置，发现不同：
cellCapabilityControlStruct{4}
>>> 1.hsdschSupport = 0 (OFF)
>>> 2.edchSupport = 0 (OFF)
>>> 3.edchTti2Support = 0 (OFF)
>>> 4.enhancedL2Support = 0 (OFF)
首先请问4项都有什么影响。上述4项中，除了最后一项是OFF状态以外，前三项参数我们这边和其他的RNC以及其他地市和我们RNC之间都是ON状态。
最近事情太多，等下周抽出时间我派个人去使用终极杀器，跟个UETR。。。。然后看看把这三项修改后是什么效果。

要不要调整下T3350的时间呢。。。