搜索
问题现象MME收到MSC/VLR回复联合位置更新失败，原因值为IMSIunkwowninHLRUE发起联合位置更新后，MME下发attachaccept中附着类型为EPS-only，失败原因值为CSdomainnotavailableUE发起联合位置更新后，MME下发attachaccept中附着类型为EPS-only，失败原因值为MSCtemporarilynotreachableUE发起联合位置更新后，MME收到并转发给MSC/VLR后，没有收到对端回复“LocationUpdateResponse”消息MME在发起联合位置更新消息到MSC后，启动定时器，超时未收到MSC的回复，导致UE在LTE的附着也失败可能原因HLR上无该用户数据或VLR上寻址不到正确的HLR。具体原因请咨询CS工程师1)MME上License项“基于CSFB的语音业务”；2)LSTLICCTRL命令检查部件编码为82203905的“基于CSFB的语音业务”是否打开；3)HSS上对该用户没有开启CS功能，即网络接入模式不是“混合用户”；1）SGs链路异常，请检查IP互通性及参数一致性；2）MME系统上TAILAI或者LAIVLR漏配；3）LAIVLR映射用户到某VLR上后，该VLR上不存在这个LAI，则VLR拒绝联合位置更新；USN10.0在SGs链路故障时，默认会下发“MSCtemporarilynotreachable”。USN9.X在SGs链路故障时，默认会下发“CSdomainnotavailable”。USN9.1补丁V900R011C01SPH319和USN9.2补丁V900R011C02SPH206增加了软参可以控制下发的失败原因值为“MSCtemporarilynotreachable”还是“CSdomainnotavailable”。1）SGs接口上MME发送到VLR的LocationUpdate请求消息里，MMEname分隔符，一种是空格“”，一种是点“.”，例如：mme-Name：mmec01.mmegi8001.mme.epc.mnc012,mcc502.3gppnetwork.orgmme-Name：mmec01mmegi8001mmeepcmnc012mcc5023gppnetworkorg需要MME于MSC进行协商，USN上软参“Byte_Ex31”BIT5控制“MMEname”格式。2）VLR故障，需要咨询CS工程师3）承载网络拥塞，造成消息丢失，需要检查数通承载网MME上SGs接口UpdateLocation定时器默认是10s，eNodeB等待UE附着请求回复定时器默认是5s。MME在等待MSC消息回复的时候，由于没有给eNodeB发响应，导致eNodeB侧超时，直接下发附着失败给UE。问题现象UE在CSFB结束后，UE没有按照客户要求马上返回LTE可能原因1）GU无线站点没有配置LTE邻区频点，或是LTE领区频点没有配置更高优先级，导致UE进入Idle态后保持在GU网络上；2）3G站点系统配置中，NodeBprotocolversion为R7，需要修改成R8，才支持异系统重选回LTE；3）该区域无LTE覆盖，或信号较差，某些终端由于缺陷可能会永久驻留在GU网络上，即使回到有LTE良好覆盖的范围内也不发起LTE的附着请求；4）Iu-PS接口连接不释放，则UE保持在3G上，无法回到LTE，第一种方式：RNC上配置缩短IuPSRelNoRABTmr定时器来更快释放Iu连接，第二种方式：USNV9R10版本或CPCISGSNV8R9之前的版本，BYTE26bit6软参可以控制SGSN是否可以主动发起Iu-PS连接释放，再配合SETIUCONNPARA进行定期器的配置；USNV9R11版本开始可以直接使用SETIUCONNPARA，不再有软参配合控制。5）Iu-CS接口连接不释放，同样会导致UE无法回到LTE，第一种方式：RNC上配置缩短IuCSRelNoRABTmr定时器来更快释放Iu连接，第二种方式：MSC上通过增加License和软参P1103Bit3控制当LTE用户回落到CS域，用户业务完成时，MSOFTX3000发送的CLEARCOMMAND/IURELEASECOMMAND消息中支持携带“CSFBIndication/EndofCSFB”信元，指示用户回到LTE网络。CPCIMSCV100R007C10SPH715ATCAMSCV200R009C02SPH118问题现象MSCPool组网，UE被叫回落到GU网络后，无法发送寻呼响应到正确MSC，被叫失败CSFB寻呼无响应CSFB主叫成功，被叫失败CSFB主被叫失败终端原因导致CSFB失败终端选网模式造成客户投诉被叫失败可能原因1）MSC从SGs接口下发寻呼消息中通过IMSI进行寻呼，导致UE在回到GU网络后，通过IMSI回复寻呼响应，无线BSC/RNC通过IMSI寻找到的MSC可能不是发起寻呼的MSC，从而导致被叫失败。MSC通过软参P1156Bit7控制从SGs接口下寻呼时携带TMSI信元，确保寻呼响应时正确选择MSCServer。CPCIV100R007C10SPH711ATCAV200R009C02SPH113或者MSC开启CSFBMTRF特性(会增加时延)。2）UE做了detach流程，MSC和MME上将用户状态置为detach，同时MME上会将UE之前的TMSI信息删除，然后UE发起了一次新的联合位置更新，发现MSC在SGs上回复的LocationUpdateResponse里没有分配TMSI，但是在做被叫时，MSC又是以TMSI发起寻呼，由于MME上此用户的TMSI信息已经删除，认为该TMSI不合法，转而以IMSI寻呼，导致UE在回落到GU网络后，IMSI的寻呼响应被随机分配到了MSCPool中的任意一台，出现概率性被叫失败。但是测试发现三星S3与苹果iphone5的终端无问题，猜测其原因是虽然网络侧以IMSI寻呼，但是终端上存在TMSI，在CSFB回到GU后，仍然以TMSI做寻呼响应，所以可以寻找到正确的MSC。MSC为异厂家设备，MME为华为设备。USNV900R012C00SPC300+SPH316补丁解决，MME不检测TMSI合法性，直接转发寻呼。3）MSC通过SGs接口发起TMSI寻呼失败，后续发起IMSI寻呼，寻呼成功导致UE回落到GU后无法发送pagingresponse到正确MSC。MSC为异厂家设备，MME为华为设备。UE做联合位置更新时，MSC给MME发送的SGsAP-LOCATION-UPDATE-ACCEPT消息中的new-tmsi-or-imsi信元指示为IMSI，但是发送SGs接口pagingrequest消息里却使用TMSI寻呼，导致UE无法匹配TMSI，无法响应CSFBpaging。新增软参P677Bit5，控制当MAP功能配置表中“位置更新时分配TMSI”参数设置为“是”时，SGs口联合位置更新过程中进行TMSI重分配，确保MSOFTX3000给MME发送的SGsAP-LOCATION-UPDATE-ACCEPT消息中的new-tmsi-or-imsi信元指示为TMSI。CPCIV100R007C10SPH7141）SGs链路断链，主叫不影响，只影响被叫业务；2）E-NodeB上没有配置GU领区频点，导致无法下发CSFB目标频点给UE，导致UE回落失败。而主叫的成功是由于UE的芯片自动切换到GU进行语音业务而成功，非CSFB主叫流程；3）如下图所示，规划中一个TAlist横跨2个LA，而这2个LA分属于不同的MSC，UE在一个TAlist中移动时，未能发起TAU去刷新联合位置更新的MSC，从而导致MSCA发起SGs寻呼，而UE回复pagingresponse到的却是MSCB，导致MT失败；TA到LA的映射最好不要跨LA，或者开启WSFD-110700-2-3基于CSFB的LA&TA协同特性，或者MSC开启CSFBMTRF特性(会增加时延)。4）如下图所示，Talist进行修改，TAlist1包含TA1，TA2；TAlist2包含TA3，第一步：UE一开始在TA2附着，UE手机上保存的TAlist包含TA1，TA2，联合位置更新在MSCA上第二步：UE移动到TA3，由于跨了TAlist，发起TAU，但是MME更新下发的TAlist不仅包含TA3，还包含了lastvisitedTA，就是说这个时候UE上保存的TAlist包含的是TA2，TA3，联合位置更新在MSCB上第三步：UE从TA3移动到TA2，由于在一个TAlist内，UE不会发起新的TAU，第四步：此时有一个呼叫通过MSCB下发SGs寻呼，UE发起CSFB回落到了LA1覆盖范围内，发起pagingresponse到MSCA上，由于MSCA上没有对该用户发起寻呼，则不会创建会话资源，导致被叫失败。MME上BYTE_EX40BIT4配置为1，不将lastvisitedTA加入TAlist，或者开启WSFD-110700-2-3基于CSFB的LA&TA协同特性，或者MSC开启CSFBMTRF特性(会增加时延)。1）流程冲突，例如CSFB主叫与被叫同时发生导致SGs寻呼失败，可以检查在被叫的同时，是否有其他流程动作发生，详细解释请看“CSFB业务冲突流程处理”；2）UE状态为detached；3）GU网络上没有开启CSFB特性；4）核心网不支持RIM流程下，E-NodeB开启flashCSFB功能，导致CSFB概率性失败；5）CSFB回落方式使用切换方式，但是切换失败，导致UE无法回落到GU，CSFB失败；终端上可以设置网络模式，例如华为P1，networkmode只设置了LTE，需要修改为GSM/WCDMA/LTE；支持语音的LTE终端在发起attachrequest的消息里，会携带操作模式，共有两种：voicecentric和datacentric。如果为voicecentric，则当联合位置更新出现异常时，则终端会主动回落到GU网络，不会附着在LTE网络上。如果为datacentric，则当联合位置更新出现异常时，则终端依旧附着在LTE网络上，此时CSFB被叫失败，而主叫可以成功是由于UE的芯片自动切换到GU进行语音业务而成功，非CSFB主叫流程。BTS/NodeBeNodeBBTS/NodeBeNodeBBSC/RNCBSC/RNCBTS/NodeBeNodeBLA1MMETA1TA2TA3SGsLA2MSCAMSCBTAlist包含TA1，TA2，TA3BTS/NodeBeNodeBBTS/NodeBeNodeBBSC/RNCBSC/RNCBTS/NodeBeNodeBLA1MMETA1TA2TA3SGsLA2MSCAMSCBTAlist包含TA1，TA2，TA3问题现象CSFB结束后，UE从GU返回LTE，TAU失败，UE需要发起全新的附着才能回到LTE可能原因1）UGW与GGSN不在同一套物理设备实体上，需要对GUL融合用户指向统一节点的UGW：解决方案一：对GUL融合用户划分特定IMSI段，USN上开通特性“根据IMSI号段的前缀选择网关”解决方案二：USN上开通特性“根据UE能力选择网关”，无论该用户是否开通4G业务，只要UE能上报MSnetworkcapability包含EPC能力，则全部选择到融合网关上。2）CDR话单格式不兼容4G，UGW上cdr-versiongcdr修改为r8v850pgwcdr或者r9v950pgwcdr版本；3）CSFB回落到GU，UE发起RAU成功，但是在GU网络上的PDP更新失败，融合网关上将PDP上下文删除，CSFB接收后UE回到LTE发起TAU，由于融合网关UGW上没有相关的承载存在，UGW回复“NoEPSbearercontextactivated”；即UE在GU上只完成了附着，而没有激活PDP上下文，则TAU的时候，UGW上没有相应的承载导致失败。需要检查为什么UE在GU网络上PDP激活失败。4）