5G SA接入信令流程日常指标处理思路
sa组网接入信令流程包括：
1 . 系统消息广播 系统消息广播是ue获得网络基本服务信息的第一步， 通过系统消息广播过程， ue 可以获得基本的as（access stratum） 层和nas（non-access stratum） 层信息。
2. （可选） 寻呼 当网络侧需要和ue建立连接时， 网络侧发起寻呼流程找到ue，仅被叫ue涉及寻 呼过程， 主叫ue不涉及寻呼过程。
3. 随机接入 随机接入（ra, random access） 是指从ue发送随机接入前导开始尝试接入网络 到ue与网络间建立起rrc连接之前的过程。
4. rrc连接管理 rrc连接管理包括ue和gnodeb之间的rrc连接建立、 重配、 释放、 重建过程， 以 及上行失步管理、ue不活动性管理。
5. 上下文管理 rrc连接建立完成后， gnodeb向5gc发送initial ue message， 触发ng-c连接 建立并接收ue上下文。上下文管理过程包括ue上下文建立、 修改和释放过程。
6. pdu会话管理 pdu会话是指ue与数据网络（dn， datanetwork） 之间的数据连接。一个pdu 会话包括若干个qos流。pdu会话管理是指gnodeb按照qos要求， 为qos流建立、 修改和释放无线数据承载和ng-u传输隧道的过程。
sa接入类故障分析思路
sa接入类问题与传统lte接入类问题分析思路类似， 都是依照接入的整体信令流程来进行分析， 逐段确认接入异常出现的信令节点进行核查定界， 以确认最终问题：
接入异常分析阶段1——用户不发起rrc连接过程
判断方法：
基站侧uu口跟踪没有rrcsetupreq消息， 需要在终端侧观察， 终端侧是否有发起rrc连接过程。
比如如下， 终端侧日志显示终端已解析到mib， sib， 但是驻留失败， 导致没有发起rrc连接。
常见原因：
1 .基站配置非合法gscn ssb频点时， 终端侧未配置优先接入频点.
2.nr小区状态配置异常（重点分析mib消息中的cell bar信元值）.
3.usim卡开卡问题， 设置了fplmn等导致终端不发起接入.
接入异常分析阶段2——随机接入失败
判断方法：
随机接入过程仍然需要通过终端侧进行观察。
ue的probe跟踪中还可以从event list看到接入失败的打印， rar超时等：
常见原因：
弱覆盖或干扰导致随机接入失败
超小区半径接入
prach参数等配置异常或者物理层原因导致接入失败
接入异常分析阶段3——rrc建立失败
判断方法：
rrc建立失败主要包括如下三种：
rrc rej：uu口检查收到rrcsetuprequest， 没有下发rrcsetup， 下发了rrcsetuprej， 如图1 ；
rrc noreply：uu口检查收到rrcsetuprequest， 下发了rrcsetup， 但是等待rrcsetupcpmplete超时；或者下发
rrcsetup后又立即下发了rrcrel， 如图2；
rrc丢弃：uu口检查收到rrcsetuprequest后， 直接丢弃， 没有进行下一步的处理， 如图3。
常见原因：
干扰、 弱覆盖原因导致 rrc noreply
srs/pucch等资源申请失败导致rrc rej
超规格接入导致rrc丢弃
接入异常分析阶段4——ngsig建立及nas异常
判断方法：
查看ng口， 基站是否有向amf发送initial ue message， amf是否有向gnodeb下发initial context setuprequest、 downlink nas transport、 ue context release command的任一条消息。
常见原因：
基站收到msg5后， 未向amf发送 initial ue message， 需要基站排查原因.
对于未收到amf的initial context setup request， 排查sctp是否异常， 以及找amf确认是否有下发.
对于nas过程异常（rej， detach等） ， 需要找amf和终端进一步定位.
接入异常分析阶段5——上下文建立失败
判断方法：
查看ng口， 当gnodeb收到amf发送的initial context setup request消息后， 在处理过程中产生错误， 导致上下文建立失败， 在向amf发送initial context setup failure消息时， 根据不同原因统计对应指标。
常见原因：
针对n.uecntx.failest.noradiores无线资源不足场景， 需要进一步排查空口资源情况.
针对n.uecntx.failest.uenoreply ue无响应场景， 需要进一步排查空口覆盖、 干扰、 top终端等情况.
传输原因导致的上下文建立失败， 需要排查ng-u链路情况.
接入异常分析阶段6——pdu session建立失败
判断方法：
qosflow建立过程一般由ue在需要向无线网络申请服务时主动发起， 并通过初始ue上下文建立流程或pdu session建立流程完成建立。
常见原因：
1 .传输原因导致qosflow建立失败， 排查ng-u链路及path是否配置
2.ue不回复重配置完成消息导致pdu session建立失败：终端版本不配套或存在干扰、 弱覆盖情况.
接入问题案例——传输链路故障导致pdu session建立失败
问题现象：
5g sa场景， 终端反馈无法接入5g。
问题分析
1 、 跟踪信令消息， 基站收到pdu session rsrc setup req后， 直接给核心网返回了pdu session rsrc setup rsp， 里面携带原因值“transport resource unavailable” 。
2、 一般查看ng-u传输是否正常， 以及ng-u链路是否正常配置。经排查在问题时间点存在gnbng的用户面故障告警。
问题解决
传输侧原因导致用户面不通， 传输侧处理后恢复.
eps fb原理介绍
驻留在nr的终端有语音业务且nr不能提供vonr时， 由网络侧发起eps fallback流程， 使终端通过psho or redirection（携带目标频点） 的方式回落到lte， 建立volte业务提供语音服务。
基于redirection方式的eps fallback回落， 终端回落到lte之后需要读取4g侧系统消息， 然后再建立volte业务；并且如果在eps fallback之前有数据业务， 也需要在lte侧重新建立承载以恢复数据业务；
基于psho方式的eps fallback回落， 终端的语音业务与数据业务（如果存在） 一起切换至lte侧，语音建立时延与数据业务中断时延相对较短；
ims需要支持信令面功能；
eps fallback基本呼叫流程
nr用户始发呼叫：
1 . nr用户发起语音呼叫请求,向ims网络发送invite消息， 网络侧通知其回落到lte网络.
2. nr用户回落到lte 网络.
3. nr用户进行volte呼叫流程， 和普通volte用户无异.
nr用户终结呼叫：
主叫cn在拨打nr被叫用户时， 被叫路由分析找到nr被叫用户所对应的i-cscf地址， 然后呼叫请求通过i-cscf最终转移到amf， amf生成寻呼消息发送给gnb。
1 . 被叫amf在收到呼叫请求消息后， 向nr下发寻呼
2. 寻呼成功后， 被叫侧进行媒体专有承载建立过程， nr触发
eps fallback回落， 通知nr用户回落到lte网络
3. nr用户回落到lte 网络
4. nr用户进行volte呼叫流程， 和普通volte用户无异
eps fb信令流程
现网出现的语音类问题， 多集中在语音不通， 包括主叫的异常导致的失败， 也有被叫的异常或者寻呼异常导致的失败，定位此类问题主要熟悉相应的信令流程， 看异常流程出现在哪里， 从而进行问题的隔离定界。以下是eps fb的信令流程，供对比参考：
1 、 终端（mo&mt） 驻留在5g， 并建立5qi5；
2、 当终端发起语音需求时， 核心网侧会指示基站建立5qi1 ；
3、 基站会根据终端能力信息、 配置等决定进行eps fb以及是否测量；
4、 基站侧拒绝5qi1 建立， 并触发eps fb；
5、 基站侧决定以重定向/切换的方式回落到lte；
6、 回落到lte接入后， 只要n26接口存在， 则需要进行tau流程， 如果是基于无n26接口的eps fb， 则需要进行attach流程；
7、 切换完成后， 网络侧将建立qci5用于承载ims信令；
8、 在lte侧继续接续volte呼叫；
eps fb关键信元
rrc建立阶段关键信元
初始上下文阶段关键信元
拒绝5qi1阶段关键信元
eps fb问题案例——5gc问题导致eps fb被叫高概率无响应
问题现象：
某局点测试时发现epsfb被叫存在高概率失败问题， 即主叫正常回落到4g， 但被叫高概率无响应， 导致呼叫无法接通.
问题分析
1 、 upf看到sbc向被叫终端发送了invite消息， 但终端无回应消息.
2、 但通过基站侧虚用户跟踪及空口log分析发现被叫侧gnb并未收到呼叫请求.
3、 5gc侧进一步核查呼叫信令流程进行情况， 发现smf收到了invite请求， 但未发送至amf， 经判断， 是由于smf与amf版本不一致导致.
问题解决
smf版本升级后问题解决.
原文标题：业务天天学| 5g sa日常指标处理思路
文章出处：【微信公众号：通信头条】欢迎添加关注！文章转载请注明出处。
如何选用高性价比的led光源
在后疫情时代 华为携生态伙伴打造数字世界内核
关于挖掘机快速连接器，你知道多少？
区块链技术在未来5-10年内可能颠覆互联网
华为平板M6搭载了麒麟980芯片和更多的黑科技为用户带来了极致体验
5G SA接入信令流程日常指标处理思路
别惊讶！未来70％的工作会被人工智能替代
几个555定时器应用电路图
微细粉末超声波振动筛换能器振子设计
中国芯片发展整体看好,自制比重偏低
CheckPoint以安全技术来巩固在云安全领域的领导地位
纳米技术如何影响晶体管
柔性屏竟然可以弯成这样
购买笔记本电脑时怎样注意避免亮点
5G基站的电磁辐射可能会威胁到人类健康? 辟谣了
AN7113S音频功率放大电路
调压器的工作原理 调压器怎么接线？
JavaScript 是脚本还是编程语言？看了这文章就懂了
降低音频设备噪音的策略
苹果iPhone信号差到底是为什么
1 . 系统消息广播 系统消息广播是ue获得网络基本服务信息的第一步， 通过系统消息广播过程， ue 可以获得基本的as（access stratum） 层和nas（non-access stratum） 层信息。
2. （可选） 寻呼 当网络侧需要和ue建立连接时， 网络侧发起寻呼流程找到ue，仅被叫ue涉及寻 呼过程， 主叫ue不涉及寻呼过程。
3. 随机接入 随机接入（ra, random access） 是指从ue发送随机接入前导开始尝试接入网络 到ue与网络间建立起rrc连接之前的过程。
4. rrc连接管理 rrc连接管理包括ue和gnodeb之间的rrc连接建立、 重配、 释放、 重建过程， 以 及上行失步管理、ue不活动性管理。
5. 上下文管理 rrc连接建立完成后， gnodeb向5gc发送initial ue message， 触发ng-c连接 建立并接收ue上下文。上下文管理过程包括ue上下文建立、 修改和释放过程。
6. pdu会话管理 pdu会话是指ue与数据网络（dn， datanetwork） 之间的数据连接。一个pdu 会话包括若干个qos流。pdu会话管理是指gnodeb按照qos要求， 为qos流建立、 修改和释放无线数据承载和ng-u传输隧道的过程。
sa接入类故障分析思路
sa接入类问题与传统lte接入类问题分析思路类似， 都是依照接入的整体信令流程来进行分析， 逐段确认接入异常出现的信令节点进行核查定界， 以确认最终问题：
接入异常分析阶段1——用户不发起rrc连接过程
判断方法：
基站侧uu口跟踪没有rrcsetupreq消息， 需要在终端侧观察， 终端侧是否有发起rrc连接过程。
比如如下， 终端侧日志显示终端已解析到mib， sib， 但是驻留失败， 导致没有发起rrc连接。
常见原因：
1 .基站配置非合法gscn ssb频点时， 终端侧未配置优先接入频点.
2.nr小区状态配置异常（重点分析mib消息中的cell bar信元值）.
3.usim卡开卡问题， 设置了fplmn等导致终端不发起接入.
接入异常分析阶段2——随机接入失败
判断方法：
随机接入过程仍然需要通过终端侧进行观察。
ue的probe跟踪中还可以从event list看到接入失败的打印， rar超时等：
常见原因：
弱覆盖或干扰导致随机接入失败
超小区半径接入
prach参数等配置异常或者物理层原因导致接入失败
接入异常分析阶段3——rrc建立失败
判断方法：
rrc建立失败主要包括如下三种：
rrc rej：uu口检查收到rrcsetuprequest， 没有下发rrcsetup， 下发了rrcsetuprej， 如图1 ；
rrc noreply：uu口检查收到rrcsetuprequest， 下发了rrcsetup， 但是等待rrcsetupcpmplete超时；或者下发
rrcsetup后又立即下发了rrcrel， 如图2；
rrc丢弃：uu口检查收到rrcsetuprequest后， 直接丢弃， 没有进行下一步的处理， 如图3。
常见原因：
干扰、 弱覆盖原因导致 rrc noreply
srs/pucch等资源申请失败导致rrc rej
超规格接入导致rrc丢弃
接入异常分析阶段4——ngsig建立及nas异常
判断方法：
查看ng口， 基站是否有向amf发送initial ue message， amf是否有向gnodeb下发initial context setuprequest、 downlink nas transport、 ue context release command的任一条消息。
常见原因：
基站收到msg5后， 未向amf发送 initial ue message， 需要基站排查原因.
对于未收到amf的initial context setup request， 排查sctp是否异常， 以及找amf确认是否有下发.
对于nas过程异常（rej， detach等） ， 需要找amf和终端进一步定位.
接入异常分析阶段5——上下文建立失败
判断方法：
查看ng口， 当gnodeb收到amf发送的initial context setup request消息后， 在处理过程中产生错误， 导致上下文建立失败， 在向amf发送initial context setup failure消息时， 根据不同原因统计对应指标。
常见原因：
针对n.uecntx.failest.noradiores无线资源不足场景， 需要进一步排查空口资源情况.
针对n.uecntx.failest.uenoreply ue无响应场景， 需要进一步排查空口覆盖、 干扰、 top终端等情况.
传输原因导致的上下文建立失败， 需要排查ng-u链路情况.
接入异常分析阶段6——pdu session建立失败
判断方法：
qosflow建立过程一般由ue在需要向无线网络申请服务时主动发起， 并通过初始ue上下文建立流程或pdu session建立流程完成建立。
常见原因：
1 .传输原因导致qosflow建立失败， 排查ng-u链路及path是否配置
2.ue不回复重配置完成消息导致pdu session建立失败：终端版本不配套或存在干扰、 弱覆盖情况.
接入问题案例——传输链路故障导致pdu session建立失败
问题现象：
5g sa场景， 终端反馈无法接入5g。
问题分析
1 、 跟踪信令消息， 基站收到pdu session rsrc setup req后， 直接给核心网返回了pdu session rsrc setup rsp， 里面携带原因值“transport resource unavailable” 。
2、 一般查看ng-u传输是否正常， 以及ng-u链路是否正常配置。经排查在问题时间点存在gnbng的用户面故障告警。
问题解决
传输侧原因导致用户面不通， 传输侧处理后恢复.
eps fb原理介绍
驻留在nr的终端有语音业务且nr不能提供vonr时， 由网络侧发起eps fallback流程， 使终端通过psho or redirection（携带目标频点） 的方式回落到lte， 建立volte业务提供语音服务。
基于redirection方式的eps fallback回落， 终端回落到lte之后需要读取4g侧系统消息， 然后再建立volte业务；并且如果在eps fallback之前有数据业务， 也需要在lte侧重新建立承载以恢复数据业务；
基于psho方式的eps fallback回落， 终端的语音业务与数据业务（如果存在） 一起切换至lte侧，语音建立时延与数据业务中断时延相对较短；
ims需要支持信令面功能；
eps fallback基本呼叫流程
nr用户始发呼叫：
1 . nr用户发起语音呼叫请求,向ims网络发送invite消息， 网络侧通知其回落到lte网络.
2. nr用户回落到lte 网络.
3. nr用户进行volte呼叫流程， 和普通volte用户无异.
nr用户终结呼叫：
主叫cn在拨打nr被叫用户时， 被叫路由分析找到nr被叫用户所对应的i-cscf地址， 然后呼叫请求通过i-cscf最终转移到amf， amf生成寻呼消息发送给gnb。
1 . 被叫amf在收到呼叫请求消息后， 向nr下发寻呼
2. 寻呼成功后， 被叫侧进行媒体专有承载建立过程， nr触发
eps fallback回落， 通知nr用户回落到lte网络
3. nr用户回落到lte 网络
4. nr用户进行volte呼叫流程， 和普通volte用户无异
eps fb信令流程
现网出现的语音类问题， 多集中在语音不通， 包括主叫的异常导致的失败， 也有被叫的异常或者寻呼异常导致的失败，定位此类问题主要熟悉相应的信令流程， 看异常流程出现在哪里， 从而进行问题的隔离定界。以下是eps fb的信令流程，供对比参考：
1 、 终端（mo&mt） 驻留在5g， 并建立5qi5；
2、 当终端发起语音需求时， 核心网侧会指示基站建立5qi1 ；
3、 基站会根据终端能力信息、 配置等决定进行eps fb以及是否测量；
4、 基站侧拒绝5qi1 建立， 并触发eps fb；
5、 基站侧决定以重定向/切换的方式回落到lte；
6、 回落到lte接入后， 只要n26接口存在， 则需要进行tau流程， 如果是基于无n26接口的eps fb， 则需要进行attach流程；
7、 切换完成后， 网络侧将建立qci5用于承载ims信令；
8、 在lte侧继续接续volte呼叫；
eps fb关键信元
rrc建立阶段关键信元
初始上下文阶段关键信元
拒绝5qi1阶段关键信元
eps fb问题案例——5gc问题导致eps fb被叫高概率无响应
问题现象：
某局点测试时发现epsfb被叫存在高概率失败问题， 即主叫正常回落到4g， 但被叫高概率无响应， 导致呼叫无法接通.
问题分析
1 、 upf看到sbc向被叫终端发送了invite消息， 但终端无回应消息.
2、 但通过基站侧虚用户跟踪及空口log分析发现被叫侧gnb并未收到呼叫请求.
3、 5gc侧进一步核查呼叫信令流程进行情况， 发现smf收到了invite请求， 但未发送至amf， 经判断， 是由于smf与amf版本不一致导致.
问题解决
smf版本升级后问题解决.
原文标题：业务天天学| 5g sa日常指标处理思路
文章出处：【微信公众号：通信头条】欢迎添加关注！文章转载请注明出处。
如何选用高性价比的led光源
在后疫情时代 华为携生态伙伴打造数字世界内核
关于挖掘机快速连接器，你知道多少？
区块链技术在未来5-10年内可能颠覆互联网
华为平板M6搭载了麒麟980芯片和更多的黑科技为用户带来了极致体验
5G SA接入信令流程日常指标处理思路
别惊讶！未来70％的工作会被人工智能替代
几个555定时器应用电路图
微细粉末超声波振动筛换能器振子设计
中国芯片发展整体看好,自制比重偏低
CheckPoint以安全技术来巩固在云安全领域的领导地位
纳米技术如何影响晶体管
柔性屏竟然可以弯成这样
购买笔记本电脑时怎样注意避免亮点
5G基站的电磁辐射可能会威胁到人类健康? 辟谣了
AN7113S音频功率放大电路
调压器的工作原理 调压器怎么接线？
JavaScript 是脚本还是编程语言？看了这文章就懂了
降低音频设备噪音的策略
苹果iPhone信号差到底是为什么