企业官网建设流程全解析

简介：这份Word文档详细梳理5G（NR）网络中用户注册与初始注册流程，面向5G网络优化、核心网维护和信令分析人员，帮助读者理清终端从开机到成功接入服务的完整信令链路。内容先区分三类注册场景，包括终端首次接入时的初始注册、移动到新跟踪区后的更新注册、定时器触发的周期性注册，并分别说明触发条件；随后拆解初始注册的四个阶段，即无线资源控制连接建立、鉴权加密、注册请求上报和注册完成响应，并补充基站将NAS消息转发至接入管理功能时的关键参数。文档还附有注册报文字段逐项解析，展示注册类型、订阅永久标识符、网络切片选择辅助信息、安全头类型等内容，便于对照现网信令进行排障。整个压缩包为1个docx文件，约224KB，上线以来已有1138人学习，适合5G网络优化与故障排查人员作为随身查阅的流程手册。

1. 5G网络优化从哪里下手：注册流程就是第一块硬骨头

做过4G网络优化的都知道，UE开机附着流程是定位接入问题的起点。到了5G(NR)里，这个逻辑没变，但名字从ATTACH换成了Registration，流程细节却比4G复杂了不止一档。很多刚转5G优化的人拿着信令log却不知道从哪一段开始看，就是因为注册流程里塞进了SUCI加密、NSSAI切片选择、AMF重选这些4G时代没有的概念。这份5G(NR)网络用户注册及初始注册流程文档，核心价值就是把注册类型、四大步流程和NAS报文解码串成了一条线，适合做5G网络优化、信令分析、以及核心网对接测试的工程师拿来当排查手册用。

2. UE注册的三种类型与四大步：从RRC建连到上下文建立

2.1 三种注册类型怎么区分，边界条件在哪里

5G注册和4G附着最大的区别在于：注册类型不是只有“开机注册”一种。文档里明确列出了三种：开机初始注册、移动更新注册、周期性注册。网络优化中判断UE到底发了哪种请求，不能只看NAS层的registration-type字段值，还要结合触发场景来看。

开机初始注册的触发条件是终端刚开机、从飞行模式恢复、或者从EPS fallback回到5G后重新注册。它的特征是AMF里没有该UE的有效上下文，所以网络侧必须完整执行鉴权、NAS安全上下文建立、注册接受这套流程。移动更新注册则是在UE移动到新TAC、且新TAC不在UE已注册的TA列表里时触发，此时AMF要重新分配注册区域，并决定是否给UE下发新的TAC列表。周期性注册是T3512定时器超时后触发的，它的作用不是建上下文，而是让网络侧确认UE还活着、还在同一个注册区域内。

实战中排障要特别注意：周期性注册失败通常不是空口问题，而是核心网侧UE上下文被异常释放或者AMF无法找到UDM中的签约数据。而移动更新注册失败，先查TA列表规划和N2接口的AMF可达性。我一般会让测试UE在不同的TAC边界反复移动，抓NAS消息看注册类型字段跳变，以此验证TA规划是否有冲突。

2.2 初始注册的四大步拆解：无线接入、鉴权加密、请求转发、上下文字成

文档把初始注册拆成了PART1到PART4四步，这个拆法很适合对应到log分段排查。

PART1无线接入：UE发起RRC Setup Request，gNB回RRC Setup，UE回RRC Setup Complete。这一步完成后UE和gNB之间有了RRC连接，但核心网还不知道这个UE存在。优化时看这一步主要量RRC建立时延，常见的劣化原因包括随机接入前导冲突、上行干扰、以及gNB的RRC配置里SRB1资源分配不当。

PART2鉴权加密：RRC连接建立后，AMF收到初始UE消息会触发鉴权流程。NAS层会进行SEcurity Mode Command和Security Mode Complete的交互，gNB侧同步开启用户面和控制面的加密。这一步在log里容易和RRC重配置混在一起，判断标准是看gNB是否下发了携带安全算法的RRC Reconfiguration，以及UE有没有回RRC Reconfiguration Complete。

PART3注册请求：UE在RRC Setup Complete里带上初始NAS消息，gNB封装成Initial UE Message发给AMF。这条消息的关键字段是Registration Request和gNB分配的那个AMF的N2关联ID。很多“UE注册不上”的现场问题，其实卡在这一步之前的AMF选择上。

PART4注册完成：AMF完成鉴权和签约校验后，给gNB回Initial Context Setup Request，gNB给UE下发RRC Reconfiguration激活AS安全，UE回RRC Reconfiguration Complete，随后gNB回Initial Context Setup Response。此时UE才算真正在5GC里建立了上下文，可以申请PDU会话。

2.3 四种注册失败场景怎么从流程图上定位

基于四步流程图，基本把注册失败归成四类：RRC建立失败、NAS鉴权失败、AMF未响应、上下文建立失败。RRC建立失败看RRC Setup Request有没有被gNB送回RRC Reject，常见原因是小区接入控制barring或者RACH资源不足。NAS鉴权失败看AMF回不回Authentication Failure，常伴随cause code。AMF未响应的特征是gNB发出Initial UE Message后一直没有收到任何下行NAS，这时问题大概率在核心网侧。上下文建立失败则体现在Initial Context Setup Request发下去了，但gNB回的是Failure，需要查gNB侧的UE上下文资源和无线承载分配。

注意：四步划分不是严格的时序串行。实际上鉴权加密和注册请求在NAS层是有交叠的，gNB收到Initial Context Setup Request时，UE可能还在等Security Mode Command。排查时要看完整流程的时间戳，别只看单个信元。

3. 初始注册报文逐字段拆解：从NrnasOtaMsg到SUCI信元

3.1 报文结构先分层：外层ASN和内层NAS要分开看

文档里给了一段完整的NrnasOtaMsgInterface-MSG报文，这是gNB侧或核心网侧抓到的ASN.1编码后的信令。这个报文的坑在于它有两层结构：外层是NGAP或者站内接口的ASN封装，内层才是真正的NAS消息。初学者最容易犯的错是把外层长度当成NAS长度来解析，结果偏移错位。

回到报文本身：08 00 04 00是NrnasOtaMsgInterface的头部，其中08是消息ID，表示nRMM-OTA-MSG-REGISTRATION-REQUEST，也就是注册请求；00是上下行标志；04是协议版本。ulLengthASN:0x23表示外层ASN编码长度为35字节，ulNasMsgSize:0x17表示内层NAS消息长度为23字节。这两个长度必须分开校验，外层长度包含NGAP头部和NAS消息体，内层长度只包含NAS消息本身。

对信令分析工具不够熟的时候，我建议手动把这段hex复制出来，按ASN.1语法做一次解析。不要求全会，但至少要把extended-protocol-discriminator、sec-header-type、registration-type、mobile-identity这几个关键字段认出来。看到7E要立刻反应出这是5G NAS的消息标识，看到41要能想到这是Registration Request消息，并且41的bit位同时携带了NAS key set identifier和注册类型。

# 手工校验NAS消息长度的示例：用hexdump从抓包里提取单条NAS消息 # 假定log line已经过滤出Registration Request这条消息，去掉ASN外层头后为： # 7E 00 41 79 0D 01 70 00 00 00 00 00 00 echo "7E0041790D0170000000000000" | xxd -r -p | wc -c # 输出13字节，对比ulNasMsgSize=0x17(23)，说明还有其他信元或分隔符未计入

这个校验的意义在于：如果wc -c统计的长度和报文字段写的不一致，说明你提取的起始偏移错了，或者中间夹了别的信元。实际抓包中NGAP的PDU经常把多个NAS消息封装在一个包里，必须靠消息边界来切分。

3.2 registrationType字段：初始注册的NAS指示怎么读

Registration Request里的registration-type-value字段是关键。报文里两个字节79和41分别表示安全相关信息。79这个字节拆开来看：bit7是0表示native安全上下文，bit0到bit2是NAS key set identifier，值为7时表示“无有效密钥”。这一点对排查很有用——当UE发Initial Registration时key set id为7说明UE侧没有缓存任何5G安全上下文，后续网络必须完整走一遍鉴权流程。

41字节的bit0到bit2是注册类型，报文里显示registration-type-value:initial-registration (1)，值为1。常见取值是：1为初始注册，2为移动更新注册，3为周期更新注册。注意Registration Request这个字段不是必选项，但3GPP TS 24.501要求在初始注册时填1。如果UE在初始注册时填了2或者没填，gNB和AMF的处理逻辑会走更新分支，可能引发后续上下文的异常。

3.3 SUCI移动身份：从IMSI到SUCI的变化

报文第17字节开始是NR移动身份：0D是长度，01是类型标识。type-of-identity:suci (1)说明这条注册请求里携带的是SUCI而不是5G-GUTI。supi-format:sUPI-Format-IMSI (0)又说明SUCI内部保护的原始标识是IMSI格式。对于初始注册，UE必须携带SUCI，因为AMF还没有给它分配5G-GUTI。如果携带的是5G-GUTI，那就有问题了——初始注册场景下AMF无法解析这个GUTI。

SUCI结构里值得关注的是protection-Scheme-ID:0，表示使用Null保护方案，也就是说这个SUCI里没有做加密。测试终端和商用终端在真实商用网络里一般会用Profile A或Profile B的加密方案，但很多测试仪表默认走Null方案。按文档里的报文，看到protection-Null-Scheme (0)时不用紧张，这只是说明IMEI或SUPI没有做隐私保护，不代表网络有安全风险，只说明这条信令发生在公共测试环境或特定配置模式下。

这个表是排查注册请求时最常要对照的内容。建议存成笔记，看到log里某个字段异常时直接对照。

4. AMF选择、跟踪区更新与注册失败重发：参数和边界

4.1 gNB怎么选AMF：NSSAI和权重配置

UE在Registration Request里携带了NSSAI，gNB收到后要根据这个NSSAI来选择AMF。文档里提到“gNB根据UE提供的NSSAI或者根据配置选择相应的AMF”，这是5G一个非常核心的机制。实际网络中AMF选择分两步：先是gNB根据配置的AMF weight和capacity选出候选AMF集合，然后在候选集合里按UE的NSSAI过滤出支持对应S-NSSAI的AMF。如果UE没有提供NSSAI，gNB就按默认配置选。

网络优化中AMF选择的问题表现得很隐蔽：UE注册请求正常发到了gNB，但注册总是超时。这时优先查gNB到AMF的NGAP连接配置，特别是AMF的weight值。如果某个AMF weight配的是0，gNB不会往它上面分流量；如果所有AMF的weight都配成65535，那流量可能都打到一个AMF上导致过载。我处理过一个案例：某地市的gNB在AMF set里配了两个AMF，但一个weight写65535一个写1，UE全部被分到第一个AMF上，核心网侧持续告警过载，把weight改成均匀的数值后注册成功率立刻恢复正常。

如果UE注册携带的NSSAI里S-NSSAI在核心网里根本不存在，AMF会回Registration Reject，cause是#5 5GS Cause里的“no network slices available”。此时gNB是没法做兜底的，必须从签约数据入手，要么让核心网给该用户配置默认切片，要么让UE不要请求不存在的切片。

4.2 跟踪区更新：TAC边界和注册区域的博弈

移动更新注册触发条件是UE进入一个新TAC，而这个TAC不在AMF分配给他的TA列表里。5G的TA列表可以同时包含多个TAC，所以不是每次跨TAC都会触发更新。如果TA列表规划不合理，UE在TAC边界来回穿越时会频繁触发注册更新，信令负荷飙升。

初始化定位“TA更新频繁”的时候，先把UE的注册接受消息里TAI list拉出来看一下。常见的规划缺陷是相邻TAC没放进同一个TA列表，导致UE在两个TAC之间做乒乓更新。解决办法是调整AMF的TA list配置，尽量把连续覆盖区域内的相邻TAC聚合到一个注册区域里。这里有一个容易忽略的点：TAC和gNB并不是一对一的关系，一个gNB的小区可以属于多个TAC，配置时如果用了错误的TAC，UE到了这个小区就触发不必要的更新注册。

4.3 注册失败后的重发：T3502定时器和NAS重发计数

UE在注册请求发出后如果没有收到Registration Accept，会启动T3502定时器，超时后再次发起注册请求。T3502的值在UE里设置，默认一般是12分钟，但网络侧可以在注册拒绝消息里通过GPRS定时器IE修改这个值。

排查“UE注册失败后要等很久才能再次注册”的问题时，必须检查两条：一是T3502配置是否被核心网改成了较大的值，二是注册尝试次数是否已经达到了NAS层的最大值。如果UE连续多次注册失败，NAS层会进入5GMM-DEREGISTERED状态，这时只有重新开关机或者手动选择网络才能恢复。从优化角度看，如果某个区域注册失败率高，要尽可能在参数上缩短T3502，等网络稳定后再恢复默认值，否则终端一旦达到最大尝试次数，用户投诉就来了。

4.4 注册接受里的显式拒绝和隐式拒绝

注册接受消息正常会携带5G-GUTI、TA list、NSSAI等信息。但5GS也会出现拒绝注册的情况。显式拒绝是在注册拒绝消息里直接带cause值，比如#3 IMSI unknown in HSS或#6 Illegal ME，这类容易定位。隐式拒绝则是AMF不发任何消息，gNB的Initial UE Message出去后就石沉大海。

隐式拒绝是5G网络优化里最让人头疼的场景之一，因为无线侧看不到任何失败信息。通常只能靠核心网侧跟踪AMF日志。从我的经验看，隐式拒绝十有八九是NGAP层SCTP链路异常或者AMF向UDM取签约数据超时。排查时先从gNB的SCTP连接状态入手，确认有没有偶发断连；再看AMF到UDM的接口时延，如果超过了AMF内部等待时间，AMF就会丢弃这条注册请求。

5. 5G注册流程排查避坑：几个常见翻车现场与排查顺序

5.1 现象：注册请求发到gNB但AMF不回任何消息

现象：gNB侧接口信令能看到Initial UE Message已经发出，tcpdump显示SCTP包已经送到AMF，但AMF侧没有任何响应，也没有Registration Reject。原因是N2链路配置里gNB的PLMN ID和TAC组合在AMF的路由表中没有对应项，AMF收包后找不到匹配的上下文直接丢弃。解决办法是核对gNB和AMF两侧的PLMN、TAC、gNB ID配置是否完全一致，尤其注意TAC的十进制和十六进制写法的坑。我见过某厂商网管里TAC按十六进制填写，而另一个厂商按十进制解析，结果同一个TAC值两边差了十万八千里。

提示：排查顺序不要先查核心网。先确认SCTP链路状态、再确认NGAP配置、最后才去看AMF侧日志，这个顺序能省下大量联调时间。

5.2 现象：UE在鉴权阶段反复失败，看log是MAC匹配失败

现象：Security Mode Command发下去后UE一直回MAC failure。原因是核心网侧的AUSF和UDM中保存的签约数据里的共享密钥K和UE侧不一致。常见诱因是老测试卡被复制过或者某核心网升级后同步错了签约数据。解决方法是找核心网核对用户在UDM里的鉴权向量，拿UE的USIM卡重写一次鉴权参数。无线侧没有太多可以调整的参数，不要把时间耗在gNB的算法配置上。

实际排查时，把UE插到另一个同款终端上测试，如果还失败说明卡的数据有问题，不测就换卡。这种方法能快速区分是UE问题还是网络侧问题。这类问题在现网中占比不高，但每次出现都是硬骨头。

5.3 现象：大范围UE注册成功但VoNR/VoLTE呼叫建立时延异常

现象：注册流程正常，但后续PDU会话建立时延明显偏高。原因是注册时携带的NSSAI和后续PDU会话请求携带的S-NSSAI不一致，AMF需要向NRF额外执行一次切片发现流程，多出了几百毫秒的时延。解决方法是核对该UE签约的默认S-NSSAI是否和业务实际使用的S-NSSAI一致，如果业务使用多个切片，注册时就要一并携带，避免AMF在会话建立阶段临时查切片配置。

这类问题在配合业务联调时经常被忽视，因为注册本身是成功的，时延异常只会在感知类测试中被发现。

5.4 现象：UE从4G重选到5G后注册失败，但开机直登5G正常

现象：UE在LTE附着状态下切换到5G时注册失败，而直接从5G开机注册是好的。原因是该区域没有部署N26接口，或者N26接口虽然开了但MME和AMF之间的切换协商失败。UE在LTE侧拿到的是4G GUTI，切换时无法用5G-GUTI做注册，网络侧若没有N26做上下文转发，UE就必须回到初始注册流程，而初始注册要重新做鉴权，如果UE刚好处于弱覆盖区域，流程就失败。

解决方法是先观察该场景下UE发起的是哪种注册类型。如果发的是initial-registration而目标网络支持N26接口，可以调整网络参数让UE走mobility-registration-update类型。如果N26没有部署，需要在核心网侧配置UE上下文重建策略，降低切换注册的失败率。

5.5 现象：网管上看到RRC连接建立成功率很高但注册成功率低

现象：RRC建立成功率在99.5%以上，但核心网统计的注册成功率只有95%左右，差距很大。原因往往在NAS层超时参数上。gNB转发Initial UE Message后，AMF需要在规定时间内完成鉴权和注册接受，但这个时间受UDM响应时延的影响很大，如果超过了gNB或AMF的内部定时器，就会产生部分失败。

排查方法是分别统计RRC建立到Initial UE Message的时延、Initial UE Message到Authentication Request的时延、Authentication Response到Registration Accept的时延。哪一段超过目标值就去查哪一段。这类问题通常不是无线参数导致的，但优化时容易被误判成因是覆盖或干扰。

6. 把注册流程知识落到日常优化：一个定位注册慢的实操模板

日常优化中，注册流程相关问题的排查不需要每次都从头开始抓包分析。我习惯用一套固定的三板斧流程，能覆盖八成以上的注册慢和注册失败问题。

第一步，过滤NAS消息并确认注册类型。在路测log里筛选Registration Request和Registration Accept，把两者的时间戳差值记为总注册时延。如果这个差值超过1.5秒，就进入第二步。第二步，分段量时延。从RRC Setup Request到RRC Setup Complete量空口接入时延，从Initial UE Message到Authentication Request量AMF启动鉴权的时延，从Authentication Response到Security Mode Command量核心网算法协商的时延。第三步，哪个段超时就查哪个段的配置。空口接入超时查PRACH参数和上行干扰，AMF启动鉴权超时查UDM时延和AMF过载，安全算法协商超时查S-NSSAI切片配置和AMF间的UE上下文迁移。

# 用文本log快速做时延分段（假设一行一个信令事件，格式如下） # time|message_type|ue_id # 通过grep过滤出关键消息后做时间差计算 grep "Initial UE Message" ue_log.txt | awk -F'|' '{print $1, $2}' > init_ue.txt grep "Authentication Request" ue_log.txt | awk -F'|' '{print $1, $2}' > auth_req.txt # 把两个文件按UE ID做关联，计算时间差 paste init_ue.txt auth_req.txt | awk '{print "delay_ms=" ($3 - $1), "ue=" $2}'

执行完这个脚本后，如果delay_ms稳定大于500毫秒，就可以判断为核心网内部或NRF/UDM接口问题，需要拉上核心网侧一起看时延了。如果delay_ms很小，那问题在空口，回到gNB侧查接入参数。

最后说一个真实的排障习惯：某次做某地市5G站点验证，UE注册时延整体偏高，但每一段单独看都正常，后来发现是测试终端设置了特殊的PDU会话偏好，在注册完成后额外发起了一轮网络切片更新流程。从那以后，我每次核查注册问题都会强制先看一眼UE型号和终端配置，确认不是测试终端的额外行为干扰，再往网络侧排查。这个习惯帮我避掉了不少弯路，希望帮到你。

本文还有配套的精品资源，点击获取