5GC实践篇之切片篇第15篇：PCF签约信息变更触发切片重选（CM-IDLE与CM-CONNECTED场景对比）

看到AMF返回202而非200，可能误以为AMF处理失败；
看到策略更新延迟了数秒，可能误认为网络故障；
看到额外的Paging和Service Request消息，可能误认为UE触发了不需要的注册。

本篇将系统对比两种状态下的差异，帮助读者准确诊断PCF策略推送相关的网络问题。

1.1 为什么需要对比这两种状态

CM-IDLE和CM-CONNECTED的差异是5G核心网中一个基础但关键的概念。在策略推送场景中，这种差异被放大了：

对比维度	CM-IDLE	CM-CONNECTED
UE与RAN的连接	无	有
AMF能否直接下发NAS	不能（需要先寻呼）	可以
N1N2MessageTransfer响应	202 Accepted	200 OK
策略下发时延	较长（需等待寻呼）	短（直接下发）
额外信令	Paging + Service Request	无
失败风险	较高（UE可能不可达）	较低

2 协议规范与关键技术

2.1 相关协议规范

本篇继续引用第14篇的协议规范，重点补充CM状态相关的协议：

TS 23.501 第5.3.3节：连接管理（Connection Management），定义了CM-IDLE和CM-CONNECTED状态。
TS 23.502 第4.2.3节：Service Request流程，CM-IDLE状态下触发UE进入CM-CONNECTED的完整流程。
TS 23.502 第4.2.4节：UE Configuration Update流程。
TS 29.507：Namf_N1N2MessageTransfer接口，定义了AMF在CM-IDLE和CM-CONNECTED下的不同响应行为。
TS 38.413：NGAP协议，定义了Paging消息和Initial Context Setup消息。

2.2 CM-IDLE与CM-CONNECTED状态模型

5G系统中的连接管理状态模型如下：


CM-IDLE                               CM-CONNECTED

  |                                       |

  |   <-- Service Request (UE发起) -->    |

  |   <-- Paging (网络发起) -->           |

  |                                       |

  |   <-- Registration Accept -->         |

  |                                       |

状态特征	CM-IDLE	CM-CONNECTED
RRC状态	RRC_IDLE	RRC_CONNECTED
N2连接	无	有
N3连接	无	有
AMF侧UE上下文	保留（轻量级）	完整
网络能否主动联系UE	仅能通过Paging	直接通过N2下发
UE位置精度	TAI级别	Cell级别

2.3 AMF对N1N2MessageTransfer的不同响应

根据TS 29.507的规定，AMF在收到N1N2MessageTransfer请求后，根据UE的CM状态返回不同的响应码：

CM-CONNECTED（200 OK）：


HTTP/1.1 200 OK

Content-Type: application/json

{

  "cause": "200",

  "n1MessageTransferCause": "N1_MSG_TRANSFERRED"

}

含义：NAS消息已成功通过N2接口发送给RAN，RAN将转发给UE。

CM-IDLE（202 Accepted）：


HTTP/1.1 202 Accepted

Content-Type: application/json

{

  "cause": "202",

  "n1MessageTransferCause": "ATTEMPTING_TO_REACH_UE"

}

含义：NAS消息已接受，但UE当前不可达。AMF将触发寻呼，等待UE可达后下发消息。

这两种响应码的区分是诊断策略推送问题的关键。

3 消息流程与详细解读

3.1 CM-CONNECTED场景

当UE处于CM-CONNECTED状态时，策略推送流程最为简洁：


sequenceDiagram

    participant PCF as PCF

    participant AMF

    participant RAN as NG-RAN

    participant UE as UE终端

    Note over UE: UE处于CM-CONNECTED状态<br/>N2连接已建立

    Note over PCF: 检测到策略变更<br/>生成新URSP策略

    PCF->>AMF: Namf_N1N2MessageTransfer<br/>新URSP策略

    Note over PCF,AMF: AMF检查UE状态<br/>发现UE为CM-CONNECTED

    AMF-->>PCF: 200 OK<br/>N1_MSG_TRANSFERRED

    Note over AMF,PCF: 立即返回成功响应

    AMF->>RAN: NGAP Downlink NAS Transport<br/>DL NAS Transport(type=5)

    Note over AMF,RAN: 直接通过N2下发

    RAN->>UE: NAS DL NAS Transport<br/>Updated URSP

    Note over UE: 处理并更新URSP

    UE->>RAN: NAS UL NAS Transport<br/>UE Policy Update Ack

    RAN->>AMF: NGAP Uplink NAS Transport

    AMF->>PCF: Namf_Communication_N1MessageNotify<br/>UE Policy Update Ack

    PCF-->>AMF: 200 OK

    Note over PCF,UE: 策略更新完成<br/>总时延：约100-300ms

关键特征：

AMF立即返回200 OK；
无需Paging和Service Request；
策略直接通过已有的N2连接下发；
端到端时延短（通常100-300ms）。

3.2 CM-IDLE场景

当UE处于CM-IDLE状态时，策略推送需要额外的寻呼流程：


sequenceDiagram

    participant PCF as PCF

    participant AMF

    participant RAN as NG-RAN

    participant UE as UE终端

    Note over UE: UE处于CM-IDLE状态<br/>无N2连接

    Note over PCF: 检测到策略变更<br/>生成新URSP策略

    PCF->>AMF: Namf_N1N2MessageTransfer<br/>新URSP策略

    Note over PCF,AMF: AMF检查UE状态<br/>发现UE为CM-IDLE

    AMF-->>PCF: 202 Accepted<br/>ATTEMPTING_TO_REACH_UE

    Note over AMF,PCF: 返回202表示需要等待UE可达

    AMF->>RAN: NGAP Paging

    Note over AMF,RAN: 在UE注册区域内寻呼

    RAN->>UE: RRC Paging

    Note over UE,RAN: 寻呼延迟：1-5秒<br/>取决于DRX周期

    UE->>RAN: RRC Connection Request

    UE->>RAN: RRC Connection Setup Complete<br/>携带NAS Service Request

    RAN->>AMF: NGAP Initial UE Message<br/>NAS Service Request

    Note over AMF: UE进入CM-CONNECTED<br/>AMF缓存URSP消息现在可以下发

    AMF->>RAN: NGAP Initial Context Setup Request<br/>携带NAS DL NAS Transport(type=5)

    Note over AMF,RAN: 通过新建的N2连接下发

    RAN->>UE: NAS DL NAS Transport<br/>Updated URSP

    Note over UE: 处理并更新URSP

    UE->>RAN: NAS UL NAS Transport<br/>UE Policy Update Ack

    RAN->>AMF: NGAP Uplink NAS Transport

    AMF->>PCF: Namf_Communication_N1MessageNotify<br/>UE Policy Update Ack

    PCF-->>AMF: 200 OK

    Note over PCF,UE: 策略更新完成<br/>总时延：约2-10秒

关键特征：

AMF返回202 Accepted；
需要Paging触发UE进入CM-CONNECTED；
策略在UE Service Request之后通过Initial Context Setup下发；
端到端时延较长（通常2-10秒，取决于DRX周期和空口条件）。

3.3 两种场景的详细对比

对比1：N1N2MessageTransfer响应

对比项	CM-CONNECTED	CM-IDLE
HTTP状态码	200 OK	202 Accepted
cause值	N1_MSG_TRANSFERRED	ATTEMPTING_TO_REACH_UE
含义	消息已成功传输	正在尝试寻呼UE
PCF是否等待	不需要（已成功）	需要等待（异步）

对比2：AMF内部处理

对比项	CM-CONNECTED	CM-IDLE
URSP消息缓存	不需要（直接发送）	需要缓存，等待UE可达
Paging触发	不需要	需要
N2连接状态	已建立	需要通过Service Request建立
NAS下发方式	Downlink NAS Transport	Initial Context Setup Request

对比3：时序特征

对比项	CM-CONNECTED	CM-IDLE
PCF发送到AMF	T0	T0
AMF响应	T0 + ~10ms	T0 + ~10ms
NAS消息下发	T0 + ~50ms	T0 + 2-10秒
UE确认	T0 + ~100-300ms	T0 + 2-10.5秒
PCF收到确认	T0 + ~200-400ms	T0 + 2-11秒

对比4：失败场景

失败类型	CM-CONNECTED	CM-IDLE
NAS下发失败	N2传输失败，AMF可重试	Paging无响应，AMF等待超时
UE未确认	AMF等待超时后通知PCF	AMF等待超时后通知PCF
RAN故障	可能导致N2连接中断	可能导致Paging无法发送

3.4 AMF处理N1N2MessageTransfer的决策流程


flowchart TD

    A[AMF收到N1N2MessageTransfer] --> B[解析N1消息内容]

    B --> C[查找UE上下文]

    C --> D{UE的CM状态}

    D --> E[CM-CONNECTED]

    D --> F[CM-IDLE]

    E --> G[缓存N1消息]

    G --> H[通过N2直接发送DL NAS Transport]

    H --> I[返回200 OK给PCF]

    F --> J[缓存N1消息]

    J --> K[返回202 Accepted给PCF]

    K --> L[触发Paging寻呼UE]

    L --> M{UE是否响应寻呼}

    M --> N[响应：Service Request]

    M --> O[无响应：等待超时]

    N --> P[UE进入CM-CONNECTED]

    P --> Q[下发缓存的N1消息]

    Q --> R[等待UE确认]

    R --> S[通知PCF策略更新完成]

    O --> T[通知PCF策略下发失败]

4 关键信令参数分析

4.1 N1N2MessageTransfer请求（两种场景相同）

两种场景中，PCF发送的N1N2MessageTransfer请求完全相同：


{

  "n1MessageContainer": {

    "n1MessageClass": "5GMM",

    "n1MessageContent": {

      "contentType": "application/nas",

      "content": "<UE Policy Container with Updated URSP>"

    }

  },

  "policyAssociationId": "pa-4608800000XXXXXX-001"

}

4.2 AMF响应对比

CM-CONNECTED响应：


HTTP/1.1 200 OK

{

  "n1MessageTransferCause": "N1_MSG_TRANSFERRED",

  "n1MessageTransferStatus": "TRANSFERRED"

}

CM-IDLE响应：


HTTP/1.1 202 Accepted

{

  "n1MessageTransferCause": "ATTEMPTING_TO_REACH_UE",

  "n1MessageTransferStatus": "BUFFERED"

}

4.3 NGAP消息对比

CM-CONNECTED场景（直接下发）：

参数名称	值	说明
AMF UE NGAP ID	0x1001	已存在的N2连接
RAN UE NGAP ID	0x0003	已存在的N2连接
NAS PDU	DL NAS Transport(type=5)	URSP策略

CM-IDLE场景（通过Initial Context Setup下发）：

参数名称	值	说明
AMF UE NGAP ID	0x1002	新分配
RAN UE NGAP ID	0x0004	RAN新分配
NAS PDU	DL NAS Transport(type=5)	URSP策略
Security Key	<新密钥>	安全上下文
UE Aggregate Maximum Bit Rate	UL/DL	QoS参数

4.4 NAS DL NAS Transport消息（两种场景相同）

两种场景中，最终下发给UE的NAS消息内容完全相同：

参数名称	值	说明
Protocol Discriminator	5GMM	NAS消息类型
Message Type	DL NAS Transport	下行NAS传输
Payload Container Type	5	UE Policy Container
Payload Container	Updated URSP Rules	新的URSP策略

4.5 AMF CLI验证数据

CM-CONNECTED场景日志（脱敏）：


# AMF UE Policy Distribution Log (CM-CONNECTED)

Time: 2026-04-17 18:00:01.100

SUPI: imsi-4608800000XXXXXX

GPSI: 86138000XXXXXX

Received N1N2MessageTransfer from PCF:

  Policy Association ID: pa-4608800000XXXXXX-001

  N1 Message Type: UE Policy Container

UE Connection State Check:

  CM State: CM-CONNECTED

  N2 Connection: Active (AMF UE NGAP ID: 0x1001)

  Action: Direct transfer via N2

Response to PCF:

  HTTP Status: 200 OK

  Cause: N1_MSG_TRANSFERRED

DL NAS Transport Sent:

  Time: 2026-04-17 18:00:01.150

  Payload Container Type: 5 (UE Policy)

  Via: Existing N2 connection

UL NAS Transport Received:

  Time: 2026-04-17 18:00:01.350

  UE Policy Update Ack: RECEIVED

N1MessageNotify sent to PCF:

  Time: 2026-04-17 18:00:01.400

  Total Latency: ~300ms

  Result: COMPLETED

CM-IDLE场景日志（脱敏）：


# AMF UE Policy Distribution Log (CM-IDLE)

Time: 2026-04-17 18:05:01.100

SUPI: imsi-4608800000XXXXXX

GPSI: 86138000XXXXXX

Received N1N2MessageTransfer from PCF:

  Policy Association ID: pa-4608800000XXXXXX-001

  N1 Message Type: UE Policy Container

UE Connection State Check:

  CM State: CM-IDLE

  N2 Connection: None

  Action: Return 202 Accepted, buffer N1 message, trigger Paging

Response to PCF:

  HTTP Status: 202 Accepted

  Cause: ATTEMPTING_TO_REACH_UE

  N1 Message: BUFFERED

Paging Triggered:

  Time: 2026-04-17 18:05:01.150

  TAI List: [46088-A001, 46088-A002]

  Paging DRX: 32

Waiting for UE response...

UE Service Request Received:

  Time: 2026-04-17 18:05:04.200

  Paging Latency: ~3.05 seconds

  UE State updated: CM-IDLE -> CM-CONNECTED

  New N2 Connection: AMF UE NGAP ID 0x1002

DL NAS Transport Sent (via Initial Context Setup):

  Time: 2026-04-17 18:05:04.350

  Payload Container Type: 5 (UE Policy)

  Via: Initial Context Setup Request

UL NAS Transport Received:

  Time: 2026-04-17 18:05:04.550

  UE Policy Update Ack: RECEIVED

N1MessageNotify sent to PCF:

  Time: 2026-04-17 18:05:04.600

  Total Latency: ~3.5 seconds

  Paging Latency: ~3.05 seconds

  Result: COMPLETED

4.6 两种场景的时序对比图


CM-CONNECTED场景时序：

PCF    AMF    RAN    UE

 |------|------|------|

 |--N1N2Transfer-->|   |   T=0ms

 |<--200 OK-------|   |   T=10ms

 |      |--DL NAS->|   |   T=50ms

 |      |      |-->URSP|   T=60ms

 |      |      |<--Ack-|   T=200ms

 |      |<--UL NAS---|   T=250ms

 |<--N1Notify-----|   |   T=300ms

 总时延: ~300ms

CM-IDLE场景时序：

PCF    AMF    RAN    UE

 |------|------|------|

 |--N1N2Transfer-->|   |   T=0ms

 |<--202 Accepted-|   |   T=10ms

 |      |--Paging-->|   |   T=50ms

 |      |      |-->Page|   T=100ms

 |      |      |      |  (等待DRX周期...)

 |      |      |<--RRC-|   T=3000ms

 |      |<--ServiceReq|   T=3100ms

 |      |--ICSR-->|   |   T=3200ms

 |      |      |-->URSP|   T=3250ms

 |      |      |<--Ack-|   T=3400ms

 |      |<--UL NAS---|   T=3450ms

 |<--N1Notify-----|   |   T=3500ms

 总时延: ~3500ms

5 测试验证与数据解读

5.1 测试预置条件

本场景需要测试CM-IDLE和CM-CONNECTED两种状态：

CM-CONNECTED测试：UE注册后保持数据连接活跃（如持续ping），确保UE处于CM-CONNECTED状态；
CM-IDLE测试：UE注册后停止数据活动，等待足够长时间使UE进入CM-IDLE状态（通常20-30秒无数据活动后UE进入CM-IDLE）。

其余预置条件与第14篇相同。

5.2 验证要点

验证点1：AMF响应码差异

在PCF-AMF接口跟踪中对比两种场景：

CM-CONNECTED场景：AMF返回200 OK；
CM-IDLE场景：AMF返回202 Accepted。

验证点2：时延差异

对比两种场景下PCF发送N1N2MessageTransfer到收到N1MessageNotify的时延：

CM-CONNECTED场景：时延应在数百毫秒内；
CM-IDLE场景：时延应在数秒内（取决于Paging延迟）。

验证点3：额外信令差异

在NGAP消息跟踪中对比：

CM-CONNECTED场景：仅有DL NAS Transport和UL NAS Transport；
CM-IDLE场景：包含Paging、RRC Connection、Service Request、Initial Context Setup。

验证点4：最终结果一致性

确认两种场景下UE最终都成功收到了URSP策略更新，并发送了确认。

5.3 数据解读

通过对比分析测试数据，可以得出以下关键结论：

200 OK vs 202 Accepted是状态指示器：在排障时，AMF的响应码直接告知了UE的连接状态。如果策略推送需要排查，首先检查这个响应码。202 Accepted不意味着失败，而是意味着UE需要被寻呼。
CM-IDLE场景的时延主要来自Paging：从测试数据可以看出，CM-IDLE场景中3.5秒的总时延中，约3秒是Paging等待时间。这个时间取决于UE的DRX周期配置和空口条件。在网络优化中，可以通过调整DRX周期来缩短寻呼延迟。
两种场景的最终结果一致：无论UE处于哪种状态，最终URSP策略都能成功下发给UE。区别仅在于路径和时延。这意味着在大多数情况下，CM状态不会影响策略更新的最终结果，只影响更新速度。
CM-IDLE场景的信令开销更大：Paging + Service Request + Initial Context Setup带来了额外的信令开销。在高频策略更新场景下（如大量用户同时变更套餐），需要评估这种信令开销对网络的影响。

5.4 运维排障指南

问题现象	可能原因	排查步骤
PCF发送策略后长时间无确认	UE处于CM-IDLE且Paging失败	检查AMF是否返回202，检查Paging是否正常发送
AMF返回200但UE未收到策略	N2连接异常或RAN故障	检查N2连接状态，检查RAN日志
AMF返回202且一直未下发	Paging无响应（UE关机或信号差）	检查UE是否在线，检查RAN Paging配置
策略下发成功但UE未应用	UE实现问题或策略格式错误	检查UE日志，验证URSP编码格式
PCF未收到N1MessageNotify	PCF未订阅或订阅过期	检查N1N2MessageSubscribe状态

6 小结与思考

6.1 本篇小结

本篇系统对比了PCF签约信息变更触发切片重选时，CM-IDLE和CM-CONNECTED两种状态下的处理差异。关键要点如下：

响应码差异：CM-CONNECTED返回200 OK，CM-IDLE返回202 Accepted。这是最直接的诊断依据。
信令流程差异：CM-CONNECTED场景直接通过已有N2连接下发，CM-IDLE场景需要先Paging再通过Initial Context Setup下发。
时延差异：CM-CONNECTED场景通常300ms内完成，CM-IDLE场景通常需要2-10秒（取决于Paging延迟）。
结果一致：两种场景最终都能成功完成URSP策略更新，差异仅在于路径和时延。

6.2 延伸思考

思考1：高并发策略更新的影响

当运营商对大量用户同时执行策略变更（如套餐升级活动）时，可能产生大量的N1N2MessageTransfer请求。如果大部分用户处于CM-IDLE状态，AMF需要同时发起大量Paging，可能导致Paging信道拥塞。运营商可以通过分批推送、错峰执行等策略缓解这个问题。

思考2：策略下发失败的重试机制

对于CM-IDLE场景中Paging超时的情况，AMF通常会缓存N1消息等待UE下次主动接入时下发。但如果缓存时间过长（如UE长时间关机），缓存可能被清除。PCF需要具备重试机制，在超时后重新发起策略推送。

思考3：CM-IDLE状态优化的思考

5G系统引入了MICO模式（Mobile Initiated Connection Only），允许UE在CM-IDLE状态下更长时间不被寻呼。但对于需要频繁推送策略更新的场景，MICO模式可能导致策略更新延迟。运营商需要在UE省电和策略及时性之间做出权衡。

6.3 切片篇第11-15篇总结

通过五篇文章，我们完成了5G切片从注册到策略更新的完整实践链路：

篇章	主题	核心内容
第11篇	RAN间直接重定向	AMF不支持的切片通过NSSF查询并直接重定向到目标AMF
第12篇	PDU会话切片选择	UE根据NSSP选择切片，AMF根据S-NSSAI+DNN选择SMF
第13篇	跨AMF移动性注册	UE移动到新区域，New AMF从Old AMF获取上下文，同切片不同NSI
第14篇	URSP策略更新	PCF签约变更，通过N1N2MessageTransfer推送新URSP（CM-IDLE）
第15篇	CM状态对比	CM-IDLE与CM-CONNECTED下策略推送的响应码、时序和信令差异

这五篇文章覆盖了5G切片实践的"进阶场景"，从AMF重选到PDU会话建立，从移动性管理到策略动态更新，帮助读者构建了完整的5G切片运维知识体系。

5GC实践篇之切片篇第15篇：PCF签约信息变更触发切片重选（CM-IDLE与CM-CONNECTED场景对比）

5GC实践篇之切片篇第15篇：PCF签约信息变更触发切片重选（CM-IDLE与CM-CONNECTED场景对比）

1 测试背景与用例简介

1.1 为什么需要对比这两种状态

2 协议规范与关键技术

2.1 相关协议规范

2.2 CM-IDLE与CM-CONNECTED状态模型

2.3 AMF对N1N2MessageTransfer的不同响应

3 消息流程与详细解读

3.1 CM-CONNECTED场景

3.2 CM-IDLE场景

3.3 两种场景的详细对比

3.4 AMF处理N1N2MessageTransfer的决策流程

4 关键信令参数分析

4.1 N1N2MessageTransfer请求（两种场景相同）

4.2 AMF响应对比

4.3 NGAP消息对比

4.4 NAS DL NAS Transport消息（两种场景相同）

4.5 AMF CLI验证数据

4.6 两种场景的时序对比图

5 测试验证与数据解读

5.1 测试预置条件

5.2 验证要点

5.3 数据解读

5.4 运维排障指南

6 小结与思考

6.1 本篇小结

6.2 延伸思考

6.3 切片篇第11-15篇总结

查看完整内容