5G通信网络最佳实践之佛山5G演示之接入失败问题总结案例.docx
《5G通信网络最佳实践之佛山5G演示之接入失败问题总结案例.docx》由会员分享，可在线阅读，更多相关《5G通信网络最佳实践之佛山5G演示之接入失败问题总结案例.docx（13页珍藏版）》请在冰豆网上搜索。
5G通信网络最佳实践之佛山5G演示之接入失败问题总结案例
5G通信网络最佳实践之佛山5G演示之接入失败问题总结案例
【摘要】由于5G新技术刚投入使用，在业务演示中经常涌现各种各样的技术问题，对现场技术人员技能要求高。
本文以佛山电信在业务演示中定位解决某紧急技术问题的过程为例，说明演示保障中应对技术问题的思路和方法。
在这次保障中，5G手机和CPE不能附着网络，时间紧迫，现场技术人员通过更换SIM卡、更换终端设备、更换基站、核查对比参数和license、分析信令等多种手段进行快速排查，最终在业务正式演示开始前成功定位问题。
本文总结了该问题的定位过程，为演示保障中如何处理技术问题提供参考。
【关键字】5G演示
【业务类别】5G
一、问题描述
5G网络作为第五代移动通信网络，以其超高速率、超低时延和超大连接，将大大加速智能驾驶、智慧医疗、智能工业制造等新技术新应用的落地，推动构建一个全移动和全联接的社会。
因此政府和各行各业也都对5G表达了浓厚的兴趣，2019年以来5G业务演示在佛山如火如荼地进行。
佛山电信为接待政府和行业伙伴，计划5月18号在电信魁奇大楼通过5G体验车和华为5G手机Mate20X演示5G业务，组网模式为SA组网。
体验车业务包括5G速率体验、360度VR直播、16路4K高清视频直播、IPTV点播等，体现5G网络超大带宽特点；Mate20X演示业务包括5G速率体验、5G通话等。
为了关键时刻不出问题，业务演示前一天分别进行了体验车和手机业务验证，业务正常。
下图为体验车内高清视频演示屏幕示意图。
下图为高清视频演示网络组网架构示意图。
演示为5月18号下午进行，当天上午进行演示准备，现场设备和人员到位后，开始调测业务。
首先演示手机业务，一切正常。
接着调测体验车业务，发现所有业务正常。
大家刚松一口气，突然有细心的同事发现，Mate20X手机不知道什么时候已经没有了5G信号。
因为体验车上的业务还在正常进行，大家都不认为网络有什么问题，但是当多次重启手机后都没有5G信号，大家才开始紧张，因为演示手机只有一台，临时从其它地方调拨另一台演示手机也来不及。
Mate20X屏幕显示没有5G信号，说明终端注册5GSA网络失败。
二、分析过程
1
2
2.1SA组网架构和终端注册流程
SA网络引入5G标准的全新的RAN和全新的核心网，即NG-RAN和NGC。
NGC由AMF和UPF组成。
其中AMF是控制面，类似于4G核心网的MME；UPF是用户面，类似于4G核心网的S/PGW。
注册的信令流程如下。
Message1~2：
UE接受系统消息广播，获取上行初始BWP信息，初始BWP中的信道配置，TDD小区的半静态配比以及其它UE接入网络的必要信息等。
Message3~5：
RRC建立流程，在UE和eNB间建立起信令连接。
Message6~16：
UE上下文建立，完成UE初始注册流程。
该流程完成后，手机上显示网络信号，表示已经完成注册，可以正常使用该网络的信号。
2.2测试设备和SIM卡排查
由于体验车业务正常，现场人员排除了网络侧存在问题的可能，首先想到的是手机终端临时出现故障。
由于现场还有CPE终端，因此马上更换CPE终端进行验证，但是更换后发现CPE仍然不能附着网络。
CPE测试连接图如下。
此时，现场人员推测是不是SIM出现问题，因此马上更换SIM卡进行验证。
但是很快又失望了，使用新的SIM卡Mate20X和CPE仍都不能附着网络。
技术人员马上想到是否核心网做了什么修改，导致这批SIM卡不能附着网络。
得到的答复也令人失望，核心网未做任何变动。
2.3信令分析
在一些现场人员更换设备做验证的同时，另外的技术人员开始使用Probe跟踪问题终端的信令进行分析，终端注册5G网络信令失败的流程如下图。
从信令看终端正确接收系统消息，并发起注册请求。
对照2.1节的完整信令流程分析，可以看出UE已经完成RRC建立，但是没有成功发起上下文建立。
注册请求触发RRC建立，注册请求做为NAS消息封装在RRCSetupComplete消息中，需要由gNodeB转发给5G核心网AMF。
但是在RRC流程建立完成后，gNodeB马上释放了RRC连接。
UE在失败后，每10s会重新发起注册请求，但是仍然失败，失败现象每次都完全一样。
注册请求作为NAS消息封装在RRCSetupComplete消息中：
由于不清楚gNodeB在收到RRCSetupComplete消息后有没有将封装的RegistrationRequest消息转发给核心网，因此在gNodeB侧抓取UU和NG口信令进行分析。
发现gNodeB在接收到RRCSetupCompte消息后，并没有转发给核心网，而是在同一时刻就下发RRCConnectionRelease消息给终端，释放RRC连接。
技术人员通过对比协议，开始分析UE发出的信令是否有异常之处，导致eNodeB异常处理。
在这个流程中，UE共发出两条信令，RRCSetupRequest和RRCSetupComplete消息。
首先分析RRCsetupRequest消息。
3GPP38.331协议对RRCSetupRequest定义如下。
如果上层有提供5GTMSI，则在RRCSetupRequest中携带将TMSI作为ue-identity携带；如果上层没有提供，则使用一个39位的随机值作为UE-identity。
RRC建立原因值由上层提供。
由于UE是初始注册，所以不可能携带TMSI，检查信令发现终端携带了一个39位的随机值作为ueIdentity，建立原因值为mo-signalling，与协议一致，并无异常。
接下来分析UE发出的RRCSetupComplete消息。
3GPP38.331协议规定如下，在UE收到RRCSetup消息后，如果上层有提供TMSI或者RegisteredAMF，那么UE将在RRCsetupComplete消息中将携带TMSI和RegisteredAMF信息。
由于初始注册无TMSI和RegisteredAMF消息，UE将只携带从SIM1中读取的PLMN消息。
如下所示，UE在RRCsetupComplete消息中携带从SIM1中读取的PLMN消息，并无异常。
SIM1中PLMN信息准确无异常。
通过对照协议排查，终端发出的信令并无异常，不会导致gNodeB异常处理。
但是通过信令分析，基本排除了核心网的异常，因为整个异常过程中，还没有核心网的介入。
核心网的信令排查也证明了这一点，如下为核心网正常信令流程和异常信令流程的对比，从异常流程看核心网在问题时段根本没有收到UE发送的注册请求。
核心网正常注册的流程：
异常流程问题时间段信令，核心网未收到注册请求：
2.4基站对比排查
为了快速定位问题，现场人员想到在距离10多分钟车程的信息大厦，有新开的5G基站在正常运行。
因此马上安排测试人员携带相同的SIM卡、手机终端、CPE终端前往信息大厦进行验证。
信息大厦很快传回信息，使用相同的SIM卡、手机终端和CPE进行业务都正常。
现场人员怀疑魁奇大楼基站配置存在问题，开始进行两个基站的基站配置、测试信令流程、license的对比分析。
对比魁奇大楼和信息大厦两个基站的配置，并没有发现明显配置不一致的地方。
对比信令流程，RRCSetupRequest、RRCSetup和RRCSetupComplete信令的信元并无区别。
如下为信息大厦基站可以正常附着的流程，RRC建立阶段的信元并无区别，但是RRC建立完成后，往下注册流程可以正常完成。
对比两个基站的license配置，很快发现了不一致的地方，魁奇大楼的资源“RE（资源单元）license”配置为1，但是信息大厦配置为10。
查找该license项描述如下，可知该license项配置限制了RRC连接用户数的能力。
由于魁奇大楼基站将该license项数量配置为1，导致最大接入用户数为1。
在体验车TUE用户接入后，其它用户不能再接入。
2.5问题定位结论
通过以上各步骤的问题分析和排查，现场最终赶在正式演示前定位出问题原因，即魁奇电信大楼基站的license项“RE（资源单元）license”配置为1，限制了该基站最大接入用户数，同一时间只能接入一个用户，导致多业务同时演示不能进行。
在业务演示前一天做准备工作时，各业务分开准备，每次接入用户数为1，所以并没有出现问题。
正式演示当天，各业务同时演示，问题出现。
这也是在前一天做演示准备时不能发现该问题的原因。
三、解决措施
3
定位问题后，现场马上增加了魁奇电信大楼基站的“RE（资源单元）license”项数量，将该license项配置数量提升为10以后，各用户可以同时接入网络，业务演示正常。
四、经验总结
由于5G将来会应用到各行各业，为各行各业带来巨大的变化，因此行业界都对5G表达了浓厚的兴趣，掀起了一股5G业务演示的热潮。
作为一名5G技术人员，为保障业务演示的成功，必须掌握问题处理的思路和流程，才能在保障的巨大压力下碰到问题时不慌不忙沉着应对。
本案例通过对终端接入失败问题回溯总结，讲述了演示中技术问题处理的流程和思路，即使碰到不一样的问题也有很强的参考意义。
以下总结了问题处理中常用的思路和方法。
升级会员 