文档介绍：起呼问题的处理流程:信号快衰造成未接通:【事件描述】国力大酒店 3小区在丰潭路上有快衰现象,在该路段国力大酒店 3小区信号迅速衰减至-90dBm,造成起呼失败。信号快衰导致重选不及时【解决措施】现场调整国力大酒店 3小区的机械下倾角由原来的 6°→10°【优化结果】调整之后在丰潭路复测多次,此问题路段已不会切至国力大酒店 3小区。调整后切换关系图跨RNC迁移时,被叫connect消息没有直传导致未接通【事件描述】在中河北路上,主叫呼被叫,被叫响应寻呼。 22:33:26,被叫向网络侧发起 connect消息时,被叫正在从同发财富1小区跨RNC迁移到文苑宾馆2小区,而导致主叫未接通。被叫路测截图被叫在源 RNC上没有上报 connect 直传消息,如下:被叫在目标 RNC上没有上报 connect 直传消息,如下:【事件原因】在起呼过程中,主被叫完成 RAB建立,但是被叫发生了跨 RNC切换,被叫在目标 RNC发出送的connect消息,主叫在源 下发的connect 消息。【解决措施】需针对RNC边界进行优化(也即进行 LAC区优化)。RNC规划的推荐原则:IMSIUnknownin在规划RNC区时,需要尽可能的利用环境因素, 减少RNC间的信令/数据流量,避免出现频繁的跨 RNC间切换。(注:此种情况一定要注意,像杭州一个RNC一个MSC出现频繁的跨RNC重选或切换会带来主叫在起呼过程中RAB建立完成发生切换至另外一个RNC导致收不到被叫发送的connect而导致未接通)如果存在两个以上的RNC区,在高话务的大城市,可以利用市区中山体、河流等地形因素来作为RNC区的边界,减少两个RNC区下不同小区的交叠深度。如果不存在这样的地理环境,RNC区的划分尽量不要以街道为界,边界不要放在话务量很高的地方(比如商场)。一般要求RNC区边界不与街道平行或垂直,而是斜交。在市区和城郊交界区域,一般将 RNC区的边界放在城郊区域外围一线话务量相对小的基站处,而不是放在话务密集的城郊结合部,避免结合部用户出现频繁的跨 RNC间切换。IMSIUNKNOWNINVLR导致未接通【事件描述】车辆由南向北行驶在丰谭路上,在丰谭路左转至天目山路路口处,主叫UE由亚洲城2(40701)重选至国力大酒店2(40262),未能及时进行位置更新即起呼,造成CMSERVICEREJECT,cause为IMSIUNKNOWNINVLR。主叫路测截图【事件原因】该用户在其他的Server上做了位置更新,且HLR通知了本Server删除掉用户数据。由于该用户没有在本Server上做位置更新,也就是说,本Server上是没有该用户的数据的,所以当该用户在本 Server上发起呼叫时,核心网直接拒掉,拒绝原因值为”VLR”。【解决措施】关于该问题,核心网的 MAP功能配置里有个选项可以解决此问题:该开关的说明如下:当漫游到本局的移动用户向网络发起主叫业务接入请求时,如果MSOFTX3000在向本局VLR查询该移动用户的用户数据时发现该数据支持主叫无处于“未证实”状态,该参数用于指示MSOFTX3000是否重新发起位用户数据时置更新操作以获取用户数据,系统初始设置值为“不支持”。IFVLRLU对于上述情况下的呼叫,若将该参数设为“不支持”,则MSOFTX3000发起独立位置更新操作将直接拒绝该移动用户的业务接入请求;若将该参数设为“支持”,则MSOFTX3000将重新发起位置更新操作以获取该移动用户的用户数据、在获取用户数据后将继续接续本次呼叫。使用的效果如下:若将该参数设为“是”,则当移动用户向网络发起位置更新请求时,如果正常的由HLR执行的位置更新操作出现失败的情况,MSOFTX3000可以直接通过VLR继续执行位置更新流程。确保了UE进行重新登记。即:如果遇到”IMSIUnknowninVLR”的现象,则本次呼叫不会直接拒绝掉,而是由VLR发起一次位置更新,位置更新成功后,呼叫继续,确保了用户可以正常接入。因此,该参数的修改是可以提高AMR和VP的接通率的。注:此开关的打开只适用于华为的交换,此开关的打开可能会带来充值出错、串话的问题,此开关的打开要慎重,此可以在集团测试期间打开即可2/3G位置更新导致主叫未接通【事件描述】测试车辆沿文二西路由西向东行驶, UE在西湖区政府服务中心 2(频点:10096,扰码:67)起呼成功,进入振铃状态,持续 20秒钟未与被叫建立通话,导致主叫未接通。【事件原因】通过对主被叫信令分析知,在起呼的过程中,被叫正在从 GSM重选回 TD,未完成位置区更新导致收不到网络侧下发的 Paging消息导致起呼失败。【解决及规避措施】增强覆盖,较小23G重选和切换次数如果是华为交换可以采取以下的方法来进行规避将TD同GSM割接到同一个目标交换上