在5G系统中,UE从"NAS层面已认证"到"可以真正承载业务"之间,存在一个关键的状态跃迁——NGAP Initial Context Setup。该过程由AMF发起,经N2接口传递至gNB,完成三件事:
从协议定位看,该过程定义于 3GPP TS 38.413 Section 8.3.1(Successful Operation)和 Section 8.3.2(Unsuccessful Operation),ASN.1消息结构定义于 Section 9.2.1.1(InitialContextSetupRequest)和 Section 9.2.1.2(InitialContextSetupResponse)。
设计意图:在4G EPC中,类似功能由S1AP的"Initial Context Setup Request"承载。5G NGAP继承了这一设计哲学,但增加了切片感知(Allowed NSSAI)和更灵活的安全上下文传递机制。将上下文建立、安全激活和会话资源建立合并为一次交互,显著减少了空口时延。
下图展示了一次成功的Initial Context Setup完整流程,包含AS安全激活和RRC重配两个子过程:
sequenceDiagram
participant UE
participant gNB as gNB/NG-RAN
participant AMF
participant SMF
Note over UE,AMF: 前置条件:NAS Registration + Authentication + NAS SMC已完成
AMF->>gNB: ① NGAP: Initial Context Setup Request<br/>(AMF UE NGAP ID, RAN UE NGAP ID,<br/>GUAMI, Allowed NSSAI,<br/>UE Security Capabilities, Security Key,<br/>PDU Session Resource Setup List,<br/>NAS-PDU: Registration Accept)
Note over gNB: gNB解析IE,创建UE Context<br/>选择加密/完整性算法
gNB->>UE: ② RRC: SecurityModeCommand<br/>(selectedAlgorithms)
UE->>gNB: ③ RRC: SecurityModeComplete
Note over gNB,UE: AS层安全激活完成
gNB->>UE: ④ RRC: RRCReconfiguration<br/>(RadioBearerConfig,<br/>MasterCellGroup,<br/>dedicatedNAS-MessageList)
Note over gNB: 建立DRB/SRB<br/>配置CellGroup
UE->>gNB: ⑤ RRC: RRCReconfigurationComplete
gNB->>AMF: ⑥ NGAP: Initial Context Setup Response<br/>(AMF UE NGAP ID, RAN UE NGAP ID,<br/>PDU Session Resource Setup List CxtRes,<br/>Failed-to-Setup List [可选])
Note over AMF,SMF: 如包含PDU Session资源<br/>AMF通知SMF建立结果
AMF->>SMF: ⑦ Nsmf_PDUSession_UpdateSMContext<br/>(N2 SM Info: TEID, Transport Info)
步骤① Initial Context Setup Request(AMF → gNB)
AMF在完成NAS层认证和安全模式控制后,通过N2接口向gNB发送此消息。这是整个过程的"控制锚点",携带了gNB创建UE上下文所需的全部信息。消息中可嵌入NAS-PDU(如Registration Accept),通过gNB透传至UE。
步骤②③ AS安全激活(gNB ↔ UE)
gNB收到请求后,根据UESecurityCapabilities和SecurityKey,选择AS层加密/完整性算法,通过RRC SecurityModeCommand下发给UE。UE验证后返回SecurityModeComplete。这是AS安全的起点——在步骤②之前,SRB1上的RRC消息是未加密的。
步骤④⑤ RRC重配(gNB ↔ UE)
AS安全激活后,gNB通过RRCReconfiguration配置无线承载(DRB/SRB2)和CellGroup参数。如果Initial Context Setup Request中携带了PDU Session Resource Setup List,gNB会在此步骤中为相应PDU会话建立DRB。同时,NAS-PDU(Registration Accept)通过dedicatedNAS-MessageList捎带下发。
步骤⑥ Initial Context Setup Response(gNB → AMF)
gNB确认上下文建立结果。关键特性:即使整体成功,Response中仍可包含Failed-to-Setup List——即部分PDU会话资源建立失败的条目。这是TS 38.413中"partial success"机制的体现。
graph TD
A[Initial Context Setup Request] --> B[AMF UE NGAP ID<br/>Mandatory / Reject]
A --> C[RAN UE NGAP ID<br/>Mandatory / Reject]
A --> D[GUAMI<br/>Mandatory / Reject]
A --> E[Allowed NSSAI<br/>Mandatory / Reject]
A --> F[UE Security Capabilities<br/>Mandatory / Reject]
A --> G[Security Key<br/>Mandatory / Reject]
A --> H[PDU Session Resource<br/>Setup List CxtReq<br/>Optional / Reject]
A --> I[NAS-PDU<br/>Optional / Reject]
A --> J[UE Aggregate<br/>Maximum Bit Rate<br/>Optional / Ignore]
A --> K[Mobility Restriction List<br/>Optional / Ignore]
A --> L[Masked IMEISVN<br/>Optional / Ignore]
A --> M[UESecurityCapabilities<br/>Mandatory / Reject]
style B fill:#ff6b6b,color:#fff
style C fill:#ff6b6b,color:#fff
style D fill:#ff6b6b,color:#fff
style E fill:#ff6b6b,color:#fff
style F fill:#ff6b6b,color:#fff
style G fill:#ff6b6b,color:#fff
style H fill:#4ecdc4,color:#fff
style I fill:#4ecdc4,color:#fff
style J fill:#95e1d3,color:#333
style K fill:#95e1d3,color:#333
红色节点为强制IE(Criticality = Reject),青色为可选但高影响IE,浅色为可选且Ignore的IE。
| IE名称 | 存在性 | Criticality | 说明 |
|---|---|---|---|
| AMF UE NGAP ID | Mandatory | Reject | AMF侧UE标识,用于N2接口唯一标识UE。长度40bit,由AMF分配 |
| RAN UE NGAP ID | Mandatory | Reject | gNB侧UE标识,长度32bit,在Initial UE Message中已分配 |
| GUAMI | Mandatory | Reject | Globally Unique AMF Identifier,含PLMN ID + AMF Region ID + AMF Set ID + AMF Pointer |
| Allowed NSSAI | Mandatory | Reject | 允许的网络切片标识列表,含SST+SD。gNB据此进行切片感知的资源分配 |
| UESecurityCapabilities | Mandatory | Reject | UE支持的加密/完整性算法列表(NEA0-NEA3, NIA0-NIA3, NEA4-NEA7 for Rel-18) |
| SecurityKey | Mandatory | Reject | 256bit安全密钥(KgNB),由AMF从KAMF推演生成 |
| PDU Session Resource Setup List CxtReq | Optional | Reject | 待建立的PDU会话资源列表,含PDU Session ID + S-NSSAI + Transfer IE |
| NAS-PDU | Optional | Reject | 捎带的NAS消息(通常为Registration Accept) |
| UE Aggregate Maximum Bit Rate | Optional | Ignore | UE聚合最大比特率,用于gNB调度参考 |
| Mobility Restriction List | Optional | Ignore | 移动性限制信息(Forbidden Area, Service Area Restriction) |
| Masked IMEISVN | Optional | Ignore | 脱敏后的IMEISVN,用于设备标识 |
Security Key IE中的KgNB并非凭空产生,它遵循 TS 33.501 Section 6.9.2 定义的关键推演链:
graph TD
A["K (永久密钥)<br/>USIM + UDM"] -->|"AKA/5G AKA"| B["K<sub>SEAF</sub>"]
B -->|"KDF (TS 33.501 6.1.1.1)"| C["K<sub>AMF</sub>"]
C -->|"KDF (TS 33.501 6.9.2)"| D["K<sub>gNB</sub>"]
D -->|"KDF (TS 33.501 6.9.3)"| E["K<sub>RRCenc</sub><br/>K<sub>RRCint</sub><br/>K<sub>UPenc</sub><br/>K<sub>UPint</sub>"]
style A fill:#2d3436,color:#fff
style D fill:#ff6b6b,color:#fff
style E fill:#4ecdc4,color:#fff
关键点: - KgNB通过 KDF(Key Derivation Function) 从KAMF推演,输入参数包含UP Counter和Access Type(3GPP接入) - gNB收到KgNB后,进一步推演出RRC加密密钥、RRC完整性密钥、UP加密密钥和UP完整性密钥 - Rel-18引入了NEA4-NEA7 / NIA4-NIA7算法(基于国密算法的候选),扩展了UESecurityCapabilities的比特位
InitialContextSetupRequest ::= SEQUENCE {
protocolIEs ProtocolIE-Container {
{InitialContextSetupRequest-IEs}
},
...
}
InitialContextSetupRequest-IEs NGAP-PROTOCOL-IES ::= {
{ ID id-AMF-UE-NGAP-ID CRITICALITY reject TYPE AMF-UE-NGAP-ID PRESENCE mandatory } |
{ ID id-RAN-UE-NGAP-ID CRITICALITY reject TYPE RAN-UE-NGAP-ID PRESENCE mandatory } |
{ ID id-GUAMI CRITICALITY reject TYPE GUAMI PRESENCE mandatory } |
{ ID id-AllowedNSSAI CRITICALITY reject TYPE AllowedNSSAI PRESENCE mandatory } |
{ ID id-UESecurityCapabilities CRITICALITY reject TYPE UESecurityCapabilities PRESENCE mandatory } |
{ ID id-SecurityKey CRITICALITY reject TYPE SecurityKey PRESENCE mandatory } |
{ ID id-PDUSessionResourceSetupListCxtReq
CRITICALITY reject TYPE PDUSessionResourceSetupListCxtReq
PRESENCE optional } |
{ ID id-NAS-PDU CRITICALITY reject TYPE NAS-PDU PRESENCE optional } |
{ ID id-UEAggregateMaximumBitRate
CRITICALITY ignore TYPE UEAggregateMaximumBitRate
PRESENCE optional } |
{ ID id-MobilityRestrictionList CRITICALITY ignore TYPE MobilityRestrictionList PRESENCE optional } |
{ ID id-MaskedIMEISVN CRITICALITY ignore TYPE MaskedIMEISVN PRESENCE optional } |
...
}
Criticality语义: - Reject:如果gNB无法识别该IE,必须拒绝整个消息(返回Failure) - Ignore:如果gNB无法识别该IE,直接忽略,不影响上下文建立
以下是一次典型Registration场景中的Initial Context Setup Request解码结果:
NGAP-PDU
initiatingMessage
procedureCode: id-InitialContextSetup (15)
criticality: reject
value: InitialContextSetupRequest
protocolIEs:
id-AMF-UE-NGAP-ID: 0x000010A1 (4257)
id-RAN-UE-NGAP-ID: 0x00000041 (65)
id-GUAMI:
pLMNIdentity: 00 F1 10 (MCC: 001, MNC: 01)
aMFRegionID: 0x02
aMFSetID: 0x155
aMFPointer: 0x01
id-AllowedNSSAI:
AllowedNSSAI-Item:
s-NSSAI:
sST: 01 (eMBB)
sD: 01 02 03
id-UESecurityCapabilities:
nRencryptionAlgorithms: 0xE000 (NEA1, NEA2, NEA3)
nRintegrityProtectionAlgorithms: 0xE000 (NIA1, NIA2, NIA3)
eUTROencryptionAlgorithms: 0xE000
eUTROintegrityProtectionAlgorithms: 0xE000
id-SecurityKey: 8F 7C A2 3D ... (256 bits / 32 bytes)
id-PDUSessionResourceSetupListCxtReq:
PDUSessionResourceSetupItemCxtReq:
pDUSessionID: 10
s-NSSAI: SST=01, SD=010203
pDUSessionResourceSetupRequestTransfer: [Opaque]
id-NAS-PDU:
ProtocolDiscriminator: 5GMM (0x7E)
SecurityHeaderType: 0x02 (Integrity Protected)
MessageType: Registration Accept (0x42)
解码要点:
- GUAMI中aMFSetID: 0x155表示AMF Set ID=341,AMF Pointer=1
- nRencryptionAlgorithms: 0xE000表示bit15-13置1,对应NEA1、NEA2、NEA3
- SecurityKey长度固定256bit,是KgNB的原始值
- PDU Session Resource的Transfer部分是Opaque(透传),内容遵循TS 38.413 Section 9.3.2.2的ASN.1定义
Initial Context Setup过程涉及UE在gNB侧的状态变迁:
stateDiagram-v2
[*] --> NG_Not_Exists: UE首次接入<br/>(无NG连接)
NG_Not_Exists --> NG_Connected: Initial UE Message<br/>(RAN UE NGAP ID分配)
NG_Connected --> Context_Validating: 收到Initial Context Setup Request
Context_Validating --> Security_Activating: IE校验通过<br/>算法选择完成
Context_Activating --> Context_Active: RRCReconfigurationComplete
Context_Active --> Context_Active: PDU Session Resource<br/>后续建立/修改
Context_Active --> Context_Releasing: UE Context Release Command
Context_Releasing --> NG_Not_Exists: 资源释放完成
Context_Validating --> Context_Failed: IE校验失败/算法不匹配
Context_Activating --> Context_Failed: AS安全激活失败/RRC重配失败
Context_Failed --> NG_Not_Exists: Initial Context Setup Failure<br/>或UE Context Release Request
状态说明:
| 状态 | 含义 | 触发条件 |
|---|---|---|
| NG_Not_Exists | UE在gNB侧无任何上下文 | UE首次接入或上下文已释放 |
| NG_Connected | N2连接已建立,UE NGAP ID已分配 | Initial UE Message处理完成 |
| Context_Validating | gNB正在验证请求IE | 收到Initial Context Setup Request |
| Security_Activating | AS安全正在激活 | SecurityModeCommand已下发 |
| Context_Active | UE上下文完全激活 | RRCReconfigurationComplete收到 |
| Context_Failed | 上下文建立失败 | 任意步骤失败 |
| IE名称 | 存在性 | Criticality | 说明 |
|---|---|---|---|
| AMF UE NGAP ID | Mandatory | Ignore | 与Request中的值一致 |
| RAN UE NGAP ID | Mandatory | Ignore | 与Request中的值一致 |
| PDU Session Resource Setup List CxtRes | Optional | Ignore | 成功建立的PDU会话资源列表 |
| PDU Session Resource Failed List CxtRes | Optional | Ignore | 建立失败的PDU会话资源列表 |
| CriticalityDiagnostics | Optional | Ignore | 诊断信息 |
| IE名称 | 存在性 | Criticality | 说明 |
|---|---|---|---|
| AMF UE NGAP ID | Mandatory | Ignore | 标识失败UE |
| RAN UE NGAP ID | Mandatory | Ignore | 标识失败UE |
| Cause | Mandatory | Ignore | 失败原因码 |
| PDU Session Resource Failed List CxtRes | Optional | Ignore | 失败的PDU会话资源 |
| CriticalityDiagnostics | Optional | Ignore | 诊断信息 |
| RAN UE NGAP ID Extension | Optional | Ignore | RAN UE NGAP ID扩展 |
| Cause值 | 典型场景 | 排查方向 |
|---|---|---|
| radio-network: unspecified | 无线资源不足 | 检查gNB负载、PRB利用率 |
| radio-network: encryption-and-or-integrity-protection-algorithms-not-supported | 安全算法不匹配 | 对比UE能力与gNB配置 |
| radio-network: interference-with-higher-priority-NR-layer | 与更高优先级NR层冲突 | 检查载波配置 |
| transport: transport-resource-unavailable | 传输资源不可用 | 检查N3隧道、F1-U资源 |
| protocol: transfer-syntax-error | ASN.1编解码错误 | 抓包检查消息结构 |
| protocol: abstract-syntax-error-reject | IE无法识别 | 检查AMF/gNB版本兼容性 |
| misc: control-processing-overload | gNB处理过载 | 检查gNB CPU/内存负载 |
| misc: not-enough-user-plane-processing-resources | UP资源不足 | 检查gNB用户面处理能力 |
| 对比维度 | 5G NGAP | 4G S1AP |
|---|---|---|
| 协议规范 | TS 38.413 Section 8.3.1 | TS 36.413 Section 8.4.1 |
| 接口 | N2/NG-C | S1/S1-MME |
| UE标识 | AMF UE NGAP ID + RAN UE NGAP ID | MME UE S1AP ID + eNB UE S1AP ID |
| 切片信息 | Allowed NSSAI(新增) | 无(EPC不支持切片) |
| 安全密钥 | Security Key(256bit KgNB) | Security Key(256bit KeNB) |
| 安全算法标识 | NEA0-NEA7, NIA0-NIA7 | EEA0-EEA3, EIA0-EIA3 |
| 会话/承载建立 | PDU Session Resource Setup(透传结构) | E-RAB Setup(显式IE) |
| NAS捎带 | NAS-PDU(含Security Header) | NAS-PDU |
| Mobility Restriction | Mobility Restriction List(增强:含Service Area Restriction) | Handover Restriction List |
| UE聚合速率 | UE Aggregate Maximum Bit Rate | UE Aggregate Maximum Bit Rate |
| 设备标识 | Masked IMEISVN(新增) | 无(可选的IMEI通过NAS传递) |
| Partial Success | Response可含Failed List | 类似机制 |
关键差异解读:
PDUSessionResourceSetupRequestTransfer中由gNB解析# 过滤所有Initial Context Setup消息
ngap.procedureCode == 15
# 仅过滤Request
ngap.procedureCode == 15 && ngap.initiatingMessage
# 仅过滤Response
ngap.procedureCode == 15 && ngap.successfulOutcome
# 仅过滤Failure
ngap.procedureCode == 15 && ngap.unsuccessfulOutcome
# 检查特定AMF UE NGAP ID
ngap.procedureCode == 15 && ngap.amf_ue_ngap_id == 4257
# 提取Initial Context Setup Request中的关键IE
tshark -r trace.pcap -Y "ngap.procedureCode==15 && ngap.initiatingMessage" \
-T fields \
-e ngap.amf_ue_ngap_id \
-e ngap.ran_ue_ngap_id \
-e ngap.GUAMI \
-e ngap.AllowedNSSAI \
-e ngap.SecurityKey
# 统计Initial Context Setup成功/失败比例
tshark -r trace.pcap -Y "ngap.procedureCode==15" \
-T fields -e ngap.message_type | sort | uniq -c
场景1:Security Capability Mismatch
现象:Initial Context Setup Failure
Cause: encryption-and-or-integrity-protection-algorithms-not-supported
排查步骤:
1. 检查Initial Context Setup Request中的UESecurityCapabilities——UE支持哪些NEA/NIA算法
2. 检查gNB配置中启用的算法列表
3. 确认是否存在交集。NEA0(空加密)和NIA0(空完整性)在Rel-15中是强制支持的,但如果gNB策略禁用了NEA0,可能出现不匹配
4. 注意Rel-18引入的NEA4-NEA7——如果AMF在UESecurityCapabilities中标记了这些位但gNB不支持,也会导致失败
场景2:PDU Session Resource Partial Failure
现象:Initial Context Setup Response中包含Failed-to-Setup List
(UE Context本身成功,但部分PDU会话资源建立失败)
排查步骤:
1. 不要误判为"Initial Context Setup失败"——UE Context是正常的
2. 检查Failed List中的Cause值,常见为transport-resource-unavailable或not-enough-user-plane-processing-resources
3. 检查N3接口的TEID分配是否成功
4. 检查gNB的F1-U接口资源(CU-DU分离架构下)
场景3:AS安全激活失败(RRC SecurityModeFailure)
现象:gNB发出SecurityModeCommand后收到SecurityModeFailure
→ 随后gNB发送UE Context Release Request
排查步骤: 1. 确认gNB选择的算法在UE安全能力范围内 2. 检查SecurityKey(KgNB)是否正确推演——可对比AMF日志中的KDF输入参数 3. 检查是否存在安全上下文不同步——UE和AMF的安全计数器不一致 4. 特别注意重注册场景——如果UE从旧AMF重定向到新AMF,KAMF可能需要从旧AMF通过N14接口传递
TS 33.501 V18.x引入了4组新的加密/完整性算法(NEA4/NIA4 ~ NEA7/NIA7),对应UESecurityCapabilities中的新增比特位。这意味着:
Rel-17引入了MBS(Multicast/Broadcast Service),Initial Context Setup过程也相应扩展: - 如果UE加入了MBS多播会话,AMF可在Initial Context Setup Request中携带MBS Session信息 - gNB需为MBS会话建立相应的MRB(MBS Radio Bearer)
当UE从RRC Inactive态恢复时,gNB可能通过Retrieve UE Context过程(而非Initial Context Setup)恢复上下文。但在某些场景(如gNB间Resume),新gNB可能需要触发新的Initial Context Setup。
Q1: Initial Context Setup和PDU Session Establishment可以合并吗?
A: 可以。这是5G相比4G的一个重要优化。AMF可以在Initial Context Setup Request中携带PDU Session Resource Setup List CxtReq,将上下文建立和初始PDU会话资源建立合并为一次N2交互。这减少了空口时延,特别有利于URLLC场景。但也存在风险——如果上下文建立失败,所有PDU会话资源也会一起失败。
Q2: SecurityKey和UESecurityCapabilities中的算法有什么关系?
A: SecurityKey提供的是密钥材料(KgNB),而UESecurityCapabilities提供的是UE支持的算法列表。gNB的工作是:从UESecurityCapabilities中选择自己也支持的算法,然后用SecurityKey推演出该算法对应的密钥。两者缺一不可——没有密钥无法加密,没有匹配的算法也无法工作。
Q3: 为什么Criticality有的IE是Reject,有的是Ignore?
A: 这反映了IE的重要性分级。Reject表示该IE如果无法识别,整个消息必须被拒绝——因为这些IE(如GUAMI、SecurityKey、Allowed NSSAI)是建立合法上下文的必要条件。Ignore表示该IE即使无法识别,也不影响上下文建立——如UE Aggregate Maximum Bit Rate仅用于调度优化,不影响上下文的合法性。
Q4: Initial Context Setup Failure后AMF会怎么做?
A: 根据TS 38.413 Section 8.3.2,AMF收到Failure后应: 1. 释放为该UE分配的N2资源 2. 如果NAS层有未完成的注册流程,向UE发送Registration Reject 3. 记录失败原因,用于后续的策略决策(如是否重定向到其他gNB) 4. 在特定场景下(如transport资源不可用),AMF可能触发N2 Handover尝试
Q5: 在gNB CU-DU分离架构下,Initial Context Setup的信令路径有什么变化?
A: 在CU-DU分离架构下,AMF仍然通过N2接口与CU通信。CU收到Initial Context Setup Request后,通过F1AP的UE Context Setup Request将部分参数(DRB配置、CellGroup配置等)传递给DU。DU完成L1/L2资源配置后回复CU。CU汇总所有信息后通过N2回复AMF。从AMF的角度看,CU-DU分离是透明的——AMF只与CU交互。
本文由「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 等场景全覆盖。
