2024年5月2日发(作者：郗黛娥)
S1接口MME IP地址冗余配置导致手机4G用户业务
失败
案例名称： S1接口MME IP地址冗余配置导致手机4G用户业务失败
现象描述： 收到客户投诉FDD室外宏站XX邮政附近4G手机终端概率性语音业务无法正常使用。
随后派测试人员去现场复现测试时发现同一张测试卡使用E392数据卡测试时可以
占上4G并做业务，使用手机测试终端时自由模式无法占上4G信号，手动锁上4G后几
分钟就自动返回3G。
告警信息： 不涉及
原因分析：
1. 检查告警信息，无；
2. 数据卡可以正常上传下载而手机终端不行，怀疑是手机终端出现问题，
更换手机终端后依然无法长时间驻留4G，排除手机终端问题；
3. 核查基站CSFB配置数据，确认CSFB数据已经配置；
4. 因为数据卡做数据业务成功而手机进行联合附着后立即释放，故怀疑是
联合附着出现问题。
通过分析前台测试信令，查看Attach request信令发现是联合附着。
通过查看Attach accept发现失败的原因是MSC temporarily not reachable
且MME下发attach accept中附着类型为EPS-only
对于UE发起联合附着后，MME下发attach accept中附着类型为EPS-only，失败原
因值为MSC temporarily not reachable的可能原因一般有三种：
1）SGs链路异常，请检查IP互通性及参数一致性；
2）MME系统上TAILAI或者LAIVLR漏配；
3）LAIVLR映射用户到某VLR上后，该VLR上不存在这个LAI，则VLR拒绝联合位置
更新；
之前TAC和LAC的配置和对应关系已经核查过没有问题，因此怀疑是MME IP地址配
置问题。
通过查询SCTPLNK发现该站点配置了两个MME地址，10.100.1.6和10.100.1.3。其
中10.100.1.6是目前S市现网使用的， 10.100.1.3是现网N市使用的IP地址，为
冗余地址。
再通过查看前台测试Attach request信令，发现请求中的MME CODE是130，而现
网中其他正常站点的请求MME CODE应该是138，可以确定是MME地址配置问题导致
业务失败。
基站侧配置MME IP地址错误，数据卡没有语音业务，能够通过错误的MME进行业
务，但是手机既要进行数据业务，又要进行语音业务，需要在MME和MSC上进行联
合附着，但手机通过之前错误配置的N地市的MME进行业务时，核心网并没有配置
N市MME和S市MSC之间的SGs接口数据，因此联合附着失败，导致手机无法驻留4G。
处理过程： 核查并删除掉该基站基站侧冗余的的N市MME SCTPLNK IP地址后，前台测试发现
手机能够驻留4G并且CSFB成功。随后联系投诉客户进行反馈，客户反映问题解决，
用户体验正常。
随后将基站侧MME SCTPLNK IP地址改成N市的10.100.1.3，再让前台测试兄弟进
行复测发现仍然无法驻留4G并无法完成语音业务，确认问题定位无误。
考虑到SCTPLNK链路是根据SCTPPEER自建立得到，故核查基站SCTPPEER参数，发
现该站配置的是N市MME IP，这应该是该问题出现的根因，立即修改回正确IP。
随后核查了全网站点的SCTPPEER和SCTPLNK参数，发现十个站点有类似情况，
经过处理后已经全部正常。
建议与总
结：
基站配置错误原因查明是该站点在开站时督导使用N市的开站模板开通了S市的
LTE基站，导致基站侧MME的对端IP配置错误，单验时发现无法基站业务失常，通
过手动修改SCTPLNK地址后业务正常。因为目前S1端口自建立采用的是End Point
方式，该方式只需配置SCTPPEER参数，SCTPLNK链路即可自建立完成。而当时开
站单验时督导处理该问题只修改了SCTPLNK参数，没有修改SCTPPEER参数。在
2014.12.31日凌晨S市有过一次全网的站点版本升级，升级后因为SCTPPEER参数
中的对端地址仍然是N市的，故重新建立了一条SCTPLNK冗余链路，导致基站业务
无法正常进行。
所以当出现MME IP地址配置错误类问题时，不仅要修改SCTPLNK参数，还要修改
SCTPPEER参数。如果只修改SCTPLNK参数，当时问题是可以解决，基站业务正常，
但是如果基站重启或升级就会出现现在S市的这种MME IP地址冗余的情况。
附件：
相关资料：
2024年5月2日发(作者：郗黛娥)
S1接口MME IP地址冗余配置导致手机4G用户业务
失败
案例名称： S1接口MME IP地址冗余配置导致手机4G用户业务失败
现象描述： 收到客户投诉FDD室外宏站XX邮政附近4G手机终端概率性语音业务无法正常使用。
随后派测试人员去现场复现测试时发现同一张测试卡使用E392数据卡测试时可以
占上4G并做业务，使用手机测试终端时自由模式无法占上4G信号，手动锁上4G后几
分钟就自动返回3G。
告警信息： 不涉及
原因分析：
1. 检查告警信息，无；
2. 数据卡可以正常上传下载而手机终端不行，怀疑是手机终端出现问题，
更换手机终端后依然无法长时间驻留4G，排除手机终端问题；
3. 核查基站CSFB配置数据，确认CSFB数据已经配置；
4. 因为数据卡做数据业务成功而手机进行联合附着后立即释放，故怀疑是
联合附着出现问题。
通过分析前台测试信令，查看Attach request信令发现是联合附着。
通过查看Attach accept发现失败的原因是MSC temporarily not reachable
且MME下发attach accept中附着类型为EPS-only
对于UE发起联合附着后，MME下发attach accept中附着类型为EPS-only，失败原
因值为MSC temporarily not reachable的可能原因一般有三种：
1）SGs链路异常，请检查IP互通性及参数一致性；
2）MME系统上TAILAI或者LAIVLR漏配；
3）LAIVLR映射用户到某VLR上后，该VLR上不存在这个LAI，则VLR拒绝联合位置
更新；
之前TAC和LAC的配置和对应关系已经核查过没有问题，因此怀疑是MME IP地址配
置问题。
通过查询SCTPLNK发现该站点配置了两个MME地址，10.100.1.6和10.100.1.3。其
中10.100.1.6是目前S市现网使用的， 10.100.1.3是现网N市使用的IP地址，为
冗余地址。
再通过查看前台测试Attach request信令，发现请求中的MME CODE是130，而现
网中其他正常站点的请求MME CODE应该是138，可以确定是MME地址配置问题导致
业务失败。
基站侧配置MME IP地址错误，数据卡没有语音业务，能够通过错误的MME进行业
务，但是手机既要进行数据业务，又要进行语音业务，需要在MME和MSC上进行联
合附着，但手机通过之前错误配置的N地市的MME进行业务时，核心网并没有配置
N市MME和S市MSC之间的SGs接口数据，因此联合附着失败，导致手机无法驻留4G。
处理过程： 核查并删除掉该基站基站侧冗余的的N市MME SCTPLNK IP地址后，前台测试发现
手机能够驻留4G并且CSFB成功。随后联系投诉客户进行反馈，客户反映问题解决，
用户体验正常。
随后将基站侧MME SCTPLNK IP地址改成N市的10.100.1.3，再让前台测试兄弟进
行复测发现仍然无法驻留4G并无法完成语音业务，确认问题定位无误。
考虑到SCTPLNK链路是根据SCTPPEER自建立得到，故核查基站SCTPPEER参数，发
现该站配置的是N市MME IP，这应该是该问题出现的根因，立即修改回正确IP。
随后核查了全网站点的SCTPPEER和SCTPLNK参数，发现十个站点有类似情况，
经过处理后已经全部正常。
建议与总
结：
基站配置错误原因查明是该站点在开站时督导使用N市的开站模板开通了S市的
LTE基站，导致基站侧MME的对端IP配置错误，单验时发现无法基站业务失常，通
过手动修改SCTPLNK地址后业务正常。因为目前S1端口自建立采用的是End Point
方式，该方式只需配置SCTPPEER参数，SCTPLNK链路即可自建立完成。而当时开
站单验时督导处理该问题只修改了SCTPLNK参数，没有修改SCTPPEER参数。在
2014.12.31日凌晨S市有过一次全网的站点版本升级，升级后因为SCTPPEER参数
中的对端地址仍然是N市的，故重新建立了一条SCTPLNK冗余链路，导致基站业务
无法正常进行。
所以当出现MME IP地址配置错误类问题时，不仅要修改SCTPLNK参数，还要修改
SCTPPEER参数。如果只修改SCTPLNK参数，当时问题是可以解决，基站业务正常，
但是如果基站重启或升级就会出现现在S市的这种MME IP地址冗余的情况。
附件：
相关资料：