5G注册(Registration)是UE接入5GS后与核心网建立MM上下文的第一个NAS级过程,定义于TS 23.502 V18.x Section 4.2.2.2。与LTE Attach不同,5G将"注册"与"PDU会话建立"解耦——Registration仅建立 Mobility Management上下文,不承载任何数据面资源。这一设计哲学直接源于5G网络切片的架构需求:UE先注册获得Allowed NSSAI,再按需建立PDU会话。
本文聚焦Initial Registration(初始注册)的完整信令流,逐消息拆解NAS/NGAP层的每一个关键IE,并深入分析AMF选择、Identity Request/Response、5G-AKA认证、Security Mode Control等子过程之间的时序关系与设计意图。
以下是基于TS 23.502 Section 4.2.2.2 Figure 4.2.2.2.2-1的完整时序流,涵盖从RRC建立到Registration Complete的全部20个步骤:
sequenceDiagram
participant UE
participant gNB as gNB(NG-RAN)
participant AMF
participant AUSF
participant UDM
participant SNSSAI as NSSF
Note over UE,gNB: 阶段1: RRC连接建立
UE->>gNB: 1. RRC Setup Request (Random Access)
gNB->>UE: 2. RRC Setup
UE->>gNB: 3. RRC Setup Complete (携带NAS: Registration Request)
Note over gNB,AMF: 阶段2: NGAP Initial UE Message + AMF选择
gNB->>AMF: 4. NGAP Initial UE Message(NAS-PDU=Registration Request, RAN UE NGAP ID, UserLocationInformation, RRC Establishment Cause)
Note over AMF,AMF: 5. AMF执行Initial AMF Selection(基于GUAMI/SUCI/PLMN)
AMF->>AMF: 6. 检查UE Context是否存在(5G-GUTI)
alt UE Context不存在 或 需要Identity
AMF-->>UE: 7. NAS: Identity Request(SUCI类型)
UE-->>AMF: 8. NAS: Identity Response(SUCI=加密后的SUPI)
end
Note over AMF,AUSF: 阶段3: 5G-AKA主认证
AMF->>AUSF: 9. Nausf_UEAuthentication Authenticate(SUPI, SNN)
AUSF->>UDM: 10. Nudm_UEAuthentication Get(Authentication Vector)
UDM->>UDM: 11. 生成AV(RAND, AUTN, XRES*, KAUSF)
UDM-->>AUSF: 12. 返回5G HE AV
AUSF->>AUSF: 13. 计算HXRES*和KSEAF
AUSF-->>AMF: 14. 返回5G AV(RAND, AUTN, HXRES*)
AMF-->>UE: 15. NAS: Authentication Request(RAND, AUTN, ngKSI)
UE->>UE: 16. UE验证AUTN, 计算RES*
UE-->>AMF: 17. NAS: Authentication Response(RES*)
AMF->>AMF: 18. 比较HXRES*与H(RES*)
Note over AMF,UE: 阶段4: NAS安全模式控制
AMF-->>UE: 19. NAS: Security Mode Command(Selected Security Algorithm, ngKSI, ReplayComplete)
UE-->>AMF: 20. NAS: Security Mode Complete(IMEISV)
Note over AMF,NSSAI: 阶段5: 切片选择 + UDM注册
AMF->>SNSSAI: 21. Nnssf_NSSelection Get(Requested NSSAI, TA)
SNSSAI-->>AMF: 22. Allowed NSSAI + Configured NSSAI
AMF->>UDM: 23. Nudm_UECM_Registration(Registration Type, Access Type)
UDM-->>AMF: 24. 返回Subscription Data(AccessAndMobilitySubscriptionData)
Note over gNB,UE: 阶段6: NGAP上下文建立 + Registration Accept
AMF->>gNB: 25. NGAP Initial Context Setup Request(AMF UE NGAP ID, NAS-PDU=Registration Accept, Security Key, UE Aggregate Max Bit Rate)
gNB->>UE: 26. RRC Reconfiguration(AS Security激活 + NAS: Registration Accept)
UE-->>gNB: 27. RRC Reconfiguration Complete
gNB-->>AMF: 28. NGAP Initial Context Setup Response
UE->>gNB: 29. NAS: Registration Complete(UL NAS Transport)
gNB->>AMF: 30. NGAP Uplink NAS Transport(NAS-PDU=Registration Complete)
UE通过PRACH完成随机接入后,发起RRC连接建立(TS 38.331 Section 5.3.2)。RRC Setup Complete消息中通过 dedicatedNAS-Message 字段将NAS层的Registration Request封装并传递给gNB。
关键点在于:gNB不解码NAS消息,仅作为透明传输管道,将NAS-PDU通过NGAP Initial UE Message转发给AMF。
gNB在转发NGAP消息时,将RRC Establishment Cause映射为NGAP的RRCEstablishmentCause IE:
| RRC Establishment Cause (TS 38.331) | NGAP Cause | 典型场景 |
|---|---|---|
| emergency | emergency | 紧急呼叫 |
| highPriorityAccess | highPriorityAccess | MPS/MCS用户 |
| mt-Access | mt-Access | 被叫寻呼响应 |
| mo-Signalling | mo-Signalling | 注册/TAU |
| mo-Data | mo-Data | 主叫数据 |
| mo-VoiceCall | mo-VoiceCall | VoNR主叫 |
| mo-VideoCall | mo-VideoCall | 视频通话 |
| mo-SMS | mo-SMS | SMS over NAS |
gNB收到RRC Setup Complete后,构造NGAP Initial UE Message(TS 38.413 Section 8.6.1),核心IE如下:
| IE名称 | 来源 | 说明 |
|---|---|---|
| RAN UE NGAP ID | gNB本地生成 | gNB侧UE标识,32bit,NG连接内唯一 |
| NAS-PDU | RRC Setup Complete透传 | 封装Registration Request |
| UserLocationInformation | gNB从Cell/TAI获取 | 包含NR-CGI和TAI |
| RRCEstablishmentCause | RRC层映射 | 如上表所示 |
| UERadioCapability | 可选 | UE无线能力信息 |
| AMF Set ID(5GS TMSI解析) | 从5G-GUTI解析 | 用于路由到正确的AMF Set |
| Selected PLMN Identity | gNB广播PLMN列表中选择 | 用于AMF PLMN匹配 |
gNB首先尝试基于5G-GUTI中的GUAMI选择AMF。若GUAMI无效或无可用AMF,gNB执行Default AMF Selection:
flowchart TD
A[NGAP Initial UE Message到达gNB] --> B{5G-GUTI中GUAMI有效?}
B -->|是| C[基于GUAMI路由到对应AMF]
B -->|否| D{gNB配置了AMF Set?}
D -->|是| E[从AMF Set中选择负载最低的AMF]
D -->|否| F[基于Selected PLMN + S-NSSAI选择Default AMF]
C --> G[转发NAS-PDU至目标AMF]
E --> G
F --> G
G --> H{AMF接受?}
H -->|是| I[正常处理Registration]
H -->|否: Overload/Unavailable| J[NGAP Reroute NAS Message至备用AMF]
设计意图:5G引入GUAMI(Globally Unique AMF ID)替代LTE中MMEGI+MMEC的扁平结构,支持AMF Set内多AMF实例的负载分担,同时通过Reroute机制保障AMF故障时的业务连续性。
当AMF无法从5G-GUTI检索到UE上下文(首次注册或AMF重启后),AMF发起Identity Request请求UE提供SUCI:
| 字段 | 值 | 说明 |
|---|---|---|
| Message Type | Identity Request | 5GMM消息 |
| Identity Type | SUCI (Type 5) | 请求加密的订阅标识 |
| 5GS Identity Type | SUCI | 唯一需要的IE |
UE响应Identity Response,携带使用归属网络公钥加密的SUCI(ECIES方案,详见TS 33.501 Section 6.12)。SUCI格式为 SUPI类型- MCC-MNC-路由指示-加密输出,例如:
SUCI: 0-460-00-0-<encrypted_payload>
↑ ↑ ↑ ↑ ↑
| | | | ECIES加密的MSIN
| | | 保护方案(0=空方案,1=Profile A,2=Profile B)
| | 路由指示(可用于AUSF路由)
| PLMN(460-00=CMCC)
SUPI类型(0=IMSI, 1=NAI, 2=GMSI...)
AMF通过Nausf_UEAuthentication_Authenticate服务向AUSF请求认证(TS 29.509),AUSF调用UDM的Nudm_UEAuthentication_Get获取5G认证向量。UDM/ARPF生成认证向量的核心参数:
| 参数 | 长度 | 生成方 | 说明 |
|---|---|---|---|
| RAND | 128 bit | UDM/ARPF | 随机挑战值 |
| AUTN | 128 bit | UDM/ARPF | 网络认证令牌(含SQN⊕AK, AMF, MAC-A) |
| XRES* | 可变(最长256bit) | UDM/ARPF | 期望响应值(由XRES扩展生成) |
| KAUSF | 256 bit | UDM/ARPF | AUSF与UDM之间的共享密钥 |
| HXRES* | 可变 | AUSF | 由XRES*派生的哈希值,用于AMF本地验证 |
| KSEAF | 256 bit | AUSF | 从KAUSF派生的SEAF锚点密钥 |
UE收到Authentication Request后执行以下验证步骤:
flowchart TD
A[UE收到RAND+AUTN+ngKSI] --> B[从USIM读取K]
B --> C[计算AK=f5_K RAND]
C --> D[恢复SQN = AUTN中SQN⊕AK ⊕ AK]
D --> E[计算XMAC = f1_K SQN, RAND, AMF]
E --> F{XMAC == AUTN中MAC?}
F -->|否| G[返回Authentication Failure#cause=MAC Failure]
F -->|是| H{SQN在有效窗口内?}
H -->|否| I[返回Authentication Failure#cause=SYNC Failure,携带AUTS]
H -->|是| J[计算RES*=KDF XRES, SNN]
J --> K[返回Authentication Response携带RES*]
ngKSI(NAS Key Set Identifier):标识当前认证使用的密钥集。值为0-6标识可用密钥集,值为7标识"密钥集不可用"——AMF收到ngKSI=7时必须触发完整认证流程。
AUSF返回给AMF的是HXRES(而非XRES),AMF收到UE的RES后计算H(RES)与HXRES*比对。这样设计的核心目的是:
认证通过后,AMF发起NAS Security Mode Control(TS 24.501 Section 8.2.21),建立NAS层安全上下文:
| IE | 说明 |
|---|---|
| Selected Security Algorithm | 选定的加密+完整性保护算法对 |
| ngKSI | 安全密钥集标识(0-6) |
| Replayed Security Capability | AMF回显UE上报的安全能力(防降级攻击) |
| Replayed 5G-GUTI | 可选,回显5G-GUTI |
| IMEISV Request | 可选,请求UE设备标识 |
| Additional 5G Security Information | 可选,含EPS Security Context信息 |
TS 33.501 Section 6.7定义了5G NAS支持的加密和完整性保护算法:
| 算法 | 类型 | 说明 |
|---|---|---|
| NEA0 | 加密 | 空加密(仅用于紧急呼叫) |
| 128-NEA1 | 加密 | 基于SNOW 3G |
| 128-NEA2 | 加密 | 基于AES |
| 128-NEA3 | 加密 | 基于ZUC(国密) |
| NIA0 | 完整性 | 空完整性保护(仅紧急注册) |
| 128-NIA1 | 完整性 | 埍于SNOW 3G |
| 128-NIA2 | 完整性 | 基于AES |
| 128-NIA3 | 完整性 | 基于ZUC(国密) |
Replayed Security Capability防降级:AMF在SMC中回显UE在Registration Request中上报的Security Capability。UE验证AMF回显值是否与自己原始上报一致——若不一致说明中间人篡改了Registration Request中的安全能力字段(Bidding Down Attack),UE拒绝该SMC。
认证完成后,各层密钥通过KDF(Key Derivation Function, HMAC-SHA-256)逐层推演:
K (USIM/UDM共享根密钥)
├── CK, IK (认证向量分量)
├── KAUSF = KDF(CK||IK, SNN||SQN⊕AK) [UDM→AUSF]
├── KSEAF = KDF(KAUSF, SNN) [AUSF→SEAF(AMF)]
├── KAMF = KDF(KSEAF, SUPi||ABBA) [AMF锚点密钥]
├── KNASenc = KDF(KAMF, NAS-enc-algo)
├── KNASint = KDF(KAMF, NAS-int-algo)
├── KgNB = KDF(KAMF, access-type) [AS层锚点]
├── KRRCenc = KDF(KgNB, RRC-enc-algo)
├── KRRCint = KDF(KgNB, RRC-int-algo)
├── KUPenc = KDF(KgNB, UP-enc-algo)
└── KUPint = KDF(KgNB, UP-int-algo)
AMF调用Nnssf_NSSelection_Get(TS 29.531)获取UE的Allowed NSSAI。输入参数包括Requested NSSAI(UE在Registration Request中携带)、UE当前TAI、Subscription信息等。
S-NSSAI协商状态机:
stateDiagram-v2
[*] --> Requested: UE携带Requested NSSAI
Requested --> Allowed: NSSF匹配成功
Requested --> Rejected: 切片未订阅或TA不支持
Requested --> Configured: 需要UE更新Configured NSSAI
Allowed --> HomeRouted: S-NSSAI需Home路由
Configured --> Requested: UE重新发起Registration
Rejected --> Requested: UE修改Requested NSSAI
NSSAI的四种形态及含义:
| NSSAI类型 | 携带方向 | 说明 |
|---|---|---|
| Requested NSSAI | UE → Network | UE请求使用的切片列表 |
| Allowed NSSAI | Network → UE | 网络允许在当前RA使用的切片 |
| Configured NSSAI | Network → UE | 运营商配置UE可用的默认切片 |
| Rejected NSSAI | Network → UE | 被拒绝的切片(含拒绝原因) |
AMF向UDM注册自己为当前服务该UE的AMF(TS 29.503 Section 5.4.2),同时获取用户的AccessAndMobilitySubscriptionData。UDM会通知旧AMF(若存在)执行Deregistration,确保一个UE同一时刻只有一个Serving AMF。
AMF通过NGAP Initial Context Setup Request(TS 38.413 Section 8.4.1)通知gNB建立UE逻辑上下文,同时携带加密的Registration Accept:
| IE | 说明 |
|---|---|
| AMF UE NGAP ID | AMF侧UE标识 |
| Security Key | KAMF推演的KgNB,用于AS层安全 |
| UE Aggregate Maximum Bit Rate | UE-AMBR,限制UE所有Non-GBR QoS Flow总速率 |
| Allowed NSSAI | 允许的切片列表,gNB用于后续PDU Session验证 |
| NAS-PDU | 封装Registration Accept |
| Mobility Restriction List | 禁止漫游区域/PLMN列表 |
| RAT Restrictions | 禁止接入的RAT类型 |
| Masked IMEISV | 脱敏后的设备标识(TAC+SV) |
Registration Accept是AMF对UE注册请求的成功响应,核心IE如下:
| IE | 必选/可选 | 说明 |
|---|---|---|
| 5G-GUTI | 必选 | AMF分配的临时标识,用于后续NAS消息标识UE |
| Registration Area | 必选 | TAI列表,UE在该列表内移动无需重新注册 |
| 5GS Registration Result | 必选 | 注册结果(3GPP/Non-3GPP/both) |
| Allowed NSSAI | 条件必选 | 网络允许的切片 |
| Rejected NSSAI | 可选 | 被拒绝的切片及原因 |
| Configured NSSAI | 可选 | 运营商配置的默认切片 |
| T3512 Timer | 必选 | 周期性注册定时器(默认54分钟) |
| Service Area List | 可选 | 服务区域限制列表 |
| MICO Indication | 可选 | MICO模式指示(仅注册区外寻呼) |
| Network Slicing Indication | 可选 | 切片变更指示(触发UE重新Registration) |
| Emergency Number List | 可选 | 紧急号码列表 |
| Negotiated DRX Parameters | 可选 | 协商的DRX参数 |
| PLMN List | 可选 | 等效PLMN列表 |
| LADN Information | 可选 | 本地数据网信息(含DNN+跟踪区) |
| 5GS DRX Parameters | 可选 | 5GS DRX参数 |
UE收到Registration Accept后,通过UL NAS Transport消息发送Registration Complete,确认已收到并应用5G-GUTI和配置参数。这是一个纯粹的确认消息,不携带任何强制性IE——其作用是确保5G-GUTI分配的可靠性(类比TCP的ACK机制),防止AMF分配新GUTI后UE未收到导致标识不一致。
Registration Request的编码结构遵循TS 24.501 Section 8.2.6:
graph TD
subgraph "Registration Request NAS消息结构"
A["Protocol Discriminator (5GMM) = 0x7E<br/>4 bit"] --> B["Security Header Type = 0x00<br/>4 bit"]
B --> C["Message Type = 0x41 (Registration Request)<br/>1 octet"]
C --> D["5GS Registration Type<br/>1 octet"]
D --> E["Mobile Identity (SUCI/GUTI)<br/>可变长度"]
E --> F["Optional IEs..."]
end
subgraph "5GS Registration Type (1 octet)"
D1["bit 4: Follow-on request pending<br/>bit 3-1: Registration Type<br/>000=Initial, 001=Mobility, 010=Periodic, 011=Emergency"]
end
subgraph "Optional IEs (按O/T/V排列)"
F1["5G-GUTI (Type 5G-GUTI)<br/>5GS Tracking Area Identity<br/>5GS DRX Parameters<br/>5GMM Capability<br/>UE Security Capability<br/>Requested NSSAI<br/>Last Visited Registered TAI<br/>UE Usage Setting<br/>Update Type<br/>MICO Indication<br/>UE Status<br/>EPS NAS Message Container<br/>Payload Container"]
end
D --> D1
F --> F1
UE Security Capability IE详解(TS 24.501 Section 9.11.3.54):
| 字节位 | 字段 | 说明 |
|---|---|---|
| Octet 3 bit 8-7 | 128-NEA0/NEA1/NEA2/NEA3支持 | 加密算法位图 |
| Octet 3 bit 1 | NEA0 | 空加密支持 |
| Octet 3 bit 2-4 | NEA1/2/3 | 各算法独立bit |
| Octet 4 bit 8-7 | 128-NIA0/NIA1/NIA2/NIA3支持 | 完整性保护算法位图 |
| Octet 5 bit 8-5 | 128-NEA0-NEA3(EA for 802.11) | Non-3GPP加密 |
| Octet 6 bit 8-5 | 128-NIA0-NIA3(IA for 802.11) | Non-3GPP完整性 |
| 注册类型 | 触发条件 | 关键差异 | 携带Identity |
|---|---|---|---|
| Initial Registration | 开机/飞行模式退出 | 完整认证+SMC+上下文建立 | SUCI(首次)或5G-GUTI |
| Mobility Registration Update | 进入新RA(TAI不在列表中) | 可跳过认证(安全上下文有效) | 5G-GUTI |
| Periodic Registration Update | T3512超时 | 轻量级,通常无认证 | 5G-GUTI |
| Emergency Registration | 无USIM/受限服务 | 跳过认证或使用EAP-AKA' | IMEI或SUCI |
使用Wireshark(需5G NAS/NGAP协议插件)识别Registration流程的关键过滤表达式:
# 过滤NAS Registration消息
nas-5gs.message_type == 0x41 # Registration Request
nas-5gs.message_type == 0x42 # Registration Accept
nas-5gs.message_type == 0x43 # Registration Complete
# 过滤NGAP Initial UE Message
ngap.procedureCode == 15 # Initial UE Message
ngap.procedureCode == 15 && ngap.BearerType == "nas-pdu" # 含NAS-PDU
# 过滤完整认证流程
nas-5gs.message_type == 0x52 # Authentication Request
nas-5gs.message_type == 0x53 # Authentication Response
nas-5gs.message_type == 0x5c # Security Mode Command
nas-5gs.message_type == 0x5d # Security Mode Complete
| 故障现象 | 可能原因 | 排错方法 |
|---|---|---|
| Registration Reject #5 (Illegal UE) | USIM与网络不匹配/黑名单 | 检查IMSI与UDM订阅数据 |
| Registration Reject #11 (PLMN not allowed) | UE选择了禁止PLMN | 检查gNB广播PLMN与UE USIM PLMN |
| Authentication Failure #20 (MAC Failure) | USIM K值与UDM不一致 | 对比USIM Ki与UDM存储的密钥 |
| Authentication Failure #21 (SYNC Failure) | USIM SQN与UDM SQN不同步 | UDM执行Re-synchronization |
| SMC Reject #23 (Security Mode Rejected) | 安全能力不匹配/降级攻击 | 检查UE与AMF支持的安全算法交集 |
| Registration后立即Deregistration | AMF过载或UDM订阅数据异常 | 检查AMF日志和UDM返回的Subscription Data |
| gNB无响应Initial Context Setup | KAMF推演KgNB失败 | 检查ngKSI和密钥推演参数 |
| ## 十二、Registration状态机全貌 |
stateDiagram-v2
[*] --> RM_DEREGISTERED: UE开机
RM_DEREGISTERED --> RM_REGISTERED: Registration Accept
RM_REGISTERED --> RM_REGISTERED: Mobility/Periodic Update
RM_REGISTERED --> RM_DEREGISTERED: Deregistration
RM_REGISTERED --> RM_DEREGISTERED: Implicit Deregistration(T3502超时)
state RM_DEREGISTERED {
[*] --> PLMN_SEARCH
PLMN_SEARCH --> CELL_SELECTION
CELL_SELECTION --> RRC_CONNECTING
RRC_CONNECTING --> NAS_REGISTERING
}
state RM_REGISTERED {
[*] --> CM_IDLE
CM_IDLE --> CM_CONNECTED: Service Request/RAN Paging
CM_CONNECTED --> CM_IDLE: RRC Release/UE Context Release
CM_IDLE --> CM_IDLE: Periodic Registration(T3512)
CM_IDLE --> CM_IDLE: Mobility Registration(TAI变化)
}
state CM_CONNECTED {
[*] --> ACTIVE
ACTIVE --> INACTIVE: RRC Inactive(挂起)
INACTIVE --> ACTIVE: Resume
}
关键定时器:
| 定时器 | 值 | 作用 | TS引用 |
|---|---|---|---|
| T3512 | Registration Accept中分配 | 周期性注册间隔 | TS 24.501 Section 5.3.2 |
| T3502 | 默认12分钟(AMF可配置) | 禁止注册区域内的注册重试间隔 | TS 24.501 Section 5.3.1 |
| T3510 | 默认15秒 | Registration Request重传定时器 | TS 24.501 Section 5.3.6 |
| T3511 | 默认10秒 | Registration Attempt间重试间隔 | TS 24.501 Section 5.3.5 |
| T3504 | 默认10秒 | Identity Response等待定时器 | TS 24.501 Section 5.3.3 |
LADN(Local Area Data Network)是5G引入的概念,定义于TS 23.501 Section 5.6.5。Registration Accept可携带LADN Information IE,告知UE哪些DNN仅在特定跟踪区域内可用(典型的MEC场景)。
| IE字段 | 说明 |
|---|---|
| LADN DNN | 本地数据网的DNN(如"internet.mec.local") |
| LADN Tracking Area List | 该LADN可用的TAI列表 |
设计意图:UE仅在进入LADN覆盖区域时才发起对应DNN的PDU Session Establishment,避免无效的PDU会话建立尝试。这对园区5G、工业互联网场景尤为重要。
Q1: Initial Registration和Mobility Registration Update在信令流上的核心区别是什么? A: 最大的区别在于是否需要执行完整的认证流程。Initial Registration必须执行5G-AKA认证和Security Mode Control(除非AMF已有有效的安全上下文且选择跳过)。而Mobility Registration Update通常可复用已有安全上下文,AMF仅需通过Security Mode Command重激活即可,无需Authentication Request/Response交互。因此Mobility Registration的信令消息数可从约15条缩减至约6条。
Q2: 为什么5G要把Registration和PDU Session建立分离,而不像LTE Attach一起做? A: 三个原因:(1) 网络切片——UE必须先通过Registration获取Allowed NSSAI,才能知道可以在哪些切片上建立PDU会话;(2) 信令效率——大量IoT设备仅需注册告知网络"我在",不需要立即建立数据通道;(3) 多PDU会话独立管理——UE可以在不同切片、不同DNN上按需建立多个PDU Session,Registration只需一次。
Q3: SUCI中的Profile A和Profile B有什么区别? A: 两者都是ECIES(Elliptic Curve Integrated Encryption Scheme)保护方案,区别在于椭圆曲线选择:Profile A使用Curve25519(x-coordinate only, Montgomery曲线),Profile B使用secp256r1(NIST P-256, Weierstrass曲线)。中国运营商通常使用Profile B(配合国密算法体系)。SUCI中的保护方案标识字段指示UE使用哪种Profile,AUSF需根据该标识选择对应的解密密钥。
Q4: AMF如何在Registration过程中判断是否需要触发Identity Request? A: AMF首先从Registration Request中的Mobile Identity字段判断类型。如果是5G-GUTI,AMF尝试查找对应的UE Context。若本地无缓存(AMF重启、跨AMF移动)或通过Nudm_UECM_Get确认该GUTI不指向自己,AMF触发Identity Request请求UE提供SUCI,然后通过SUCI中的SUPI从UDM获取订阅数据。如果是SUCI则直接使用,无需Identity Request。
Q5: Registration Accept中的MICO模式对网络有什么影响? A: MICO(Mobile Initiated Connection Only)模式下,AMF不向UE发送寻呼,UE始终处于CM-IDLE状态。这意味着:(1) 网络侧无法发起下行数据推送;(2) AMF无需为MICO UE分配寻呼资源,显著节省核心网和无线侧寻呼开销;(3) 仅当UE主动发起Service Request或Periodic Registration时才建立连接。适用于智能水表、环境传感器等几乎不需要网络主动推送的场景。R18进一步增强了MICO模式,支持按切片粒度配置。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
