MICO(Mobile Initiated Connection Only,仅移动发起连接)模式是3GPP Rel-15引入的5G核心网级别省电机制,专为mMTC/IoT场景设计。其核心思想极其简单:当UE处于CM-IDLE状态且激活了MICO模式时,网络(AMF)完全不对该UE进行寻呼,UE不需要监听寻呼信道,从而实现极致省电。
这一定位与传统4G EPS中的PSM(Power Saving Mode)看似相似,但MICO模式在5G架构中有独立的规范定义和信令交互机制,且与5G网络切片、LADN等特性深度耦合。
MICO模式涉及的核心规范体系:
| 规范编号 | 关键章节 | 内容定位 |
|---|---|---|
| TS 23.501 | §5.4.1.3 | MICO模式架构原理、注册区域策略、AMF决策条件 |
| TS 23.501 | §5.31.7 | 省电机制框架,MICO与PSM/eDRX的关系 |
| TS 23.502 | §4.2.2.2 | Registration过程中MICO协商的具体信令流 |
| TS 23.502 | §4.2.3.2 | Service Request与MICO模式的交互 |
| TS 24.501 | §9.11.3.31 | NAS层MICO Indication IE的编码格式 |
| TS 24.501 | §8.2.6 | Registration Request消息中MICO IE的位置 |
| TS 24.501 | §8.2.7 | Registration Accept消息中MICO IE的位置 |
| TS 29.518 | §6 | AMF SBI接口中MICO相关参数的传递 |
| TS 29.503 | §6 | UDM中MICO相关订阅数据的存储 |
MICO模式的激活完全发生在Registration过程中,是UE和AMF之间的一次协商而非单向指示。下图展示完整的MICO协商信令流:
sequenceDiagram
participant UE
participant RAN as gNB/NG-RAN
participant AMF
participant UDM
participant PCF
participant SMF
Note over UE: UE触发Registration<br/>(初始注册/移动性更新/周期性注册)
UE->>RAN: RRC Setup Complete<br/>(携带NAS: Registration Request)
Note right of UE: NAS IE: MICO Indication<br/>(Requested = true)<br/>5GS Registration Type<br/>Mobile Identity (SUCI/5G-GUTI)<br/>5GMM Capability<br/>Requested NSSAI
RAN->>AMF: NGAP: Initial UE Message<br/>(转发NAS Registration Request)
Note right of RAN: NGAP IE:<br/>UserLocationInformation<br/>RAN UE NGAP ID<br/>Selected PLMN ID
AMF->>AMF: 内部决策:是否允许MICO?
Note right of AMF: 决策依据:<br/>1. UE订阅数据中的MICO策略<br/>2. 本地运营商策略<br/>3. 当前网络负载<br/>4. UE类型(IoT/非IoT)<br/>5. 紧急注册不适用MICO
AMF->>UDM: Nudm_SDM_Get<br/>(获取订阅数据)
UDM-->>AMF: Nudm_SDM_Get Response<br/>(含MICO Subscription Info)
AMF->>PCF: Npcf_AMPolicy_Get<br/>(获取AM策略)
PCF-->>AMF: Npcf_AMPolicy_Get Response<br/>(含MICO相关策略规则)
AMF->>AMF: 最终MICO决策:<br/>Grant 或 Reject
alt MICO被授权(Granted)
AMF-->>RAN: NGAP: Initial Context Setup Request<br/>(携带NAS: Registration Accept)
Note right of AMF: NAS IE包含:<br/>✅ MICO Indication(granted)<br/>✅ T3512 Periodic Registration Timer<br/>✅ Registration Area(可能=整个PLMN)<br/>✅ Allowed NSSAI
RAN-->>UE: RRC Reconfiguration<br/>(携带NAS: Registration Accept)
Note left of UE: UE进入MICO模式:<br/>CM-IDLE + MICO active<br/>停止监听寻呼信道
else MICO被拒绝(Rejected)
AMF-->>RAN: NGAP: Initial Context Setup Request<br/>(携带NAS: Registration Accept)
Note right of AMF: NAS IE中:<br/>❌ 不包含MICO Indication<br/>✅ T3512(常规值)<br/>✅ TAI List(正常注册区域)
RAN-->>UE: RRC Reconfiguration<br/>(携带NAS: Registration Accept)
Note left of UE: UE不进入MICO模式<br/>正常监听寻呼
end
关键信令消息IE解析——Registration Request中的MICO Indication:
根据TS 24.501 §9.11.3.31,MICO Indication IE是一个极简的NAS信息元素,仅占3个字节:
| 字段 | 八位组 | 比特位 | 含义 |
|---|---|---|---|
| IEI(信息元素标识) | Octet 1 | 全部 | 值为0xB-(具体值依TS 24.501 Table 9.11.3.31.1) |
| Length of MICO indication | Octet 2 | 全部 | 固定为1(1字节内容) |
| Spare | Octet 3 | Bit 8-2 | 备用,全0 |
| A/T(MICO indication) | Octet 3 | Bit 1 | 0 = 不请求MICO 1 = 请求MICO模式 |
设计意图:MICO Indication只用1个bit表达请求/不请求,这种极简设计体现了3GPP对IoT设备的考量——减少NAS消息大小,降低空口传输开销。在Registration Accept中,AMF使用完全相同的IE格式来指示是否授权MICO。如果Registration Accept中不携带MICO Indication IE,则等同于拒绝MICO请求。
AMF在收到UE的MICO请求后,并非无条件授权。根据TS 23.501 §5.4.1.3,AMF需要综合考量以下五个维度:
flowchart TD
A[UE发送Registration Request<br/>携带MICO Indication] --> B{1.紧急注册?}
B -->|是| Z[拒绝MICO<br/>紧急注册不允许MICO]
B -->|否| C{2.UDM订阅数据<br/>是否允许MICO?}
C -->|不允许| Z
C -->|允许/未定义| D{3.本地运营商策略<br/>是否允许MICO?}
D -->|不允许| Z
D -->|允许| E{4.当前网络负载<br/>是否可支持?}
E -->|过载状态| F[可能拒绝MICO<br/>需要UE可寻呼以进行拥塞控制]
E -->|正常| G{5.UE类型判断}
G -->|IoT/mMTC设备| H[✅ 授权MICO模式]
G -->|普通智能手机| I[大概率拒绝MICO<br/>需保持下行可达性]
F --> J{是否有替代方案?}
J -->|建议eDRX| K[拒绝MICO<br/>建议UE使用eDRX]
J -->|可接受MICO| H
各判定标准的详细解析:
标准1:紧急注册排除(TS 23.501 §5.4.1.3) 紧急注册(Emergency Registration)的UE不允许进入MICO模式。这是因为在紧急情况下,网络必须能够寻呼UE(例如IMS紧急呼叫回拨、紧急通知下行推送等)。如果Registration Request中5GS Registration Type设置为"emergency registration",AMF必须忽略MICO Indication。
标准2:UDM订阅数据(TS 29.503 §6) AMF通过Nudm_SDM_Get服务从UDM获取UE的订阅数据。订阅数据中可以包含MICO相关的策略信息: - MICO Allowed:明确标记该UE是否被允许使用MICO模式 - Subscribed Periodic Registration Timer:建议的周期性注册定时器值 - MICO Preference:运营商为该UE预设的MICO偏好
标准3:本地运营商策略(TS 23.501 §5.4.1.3) AMF的本地配置可以覆盖或补充UDM中的策略。例如: - 某些运营商可能全局禁止MICO模式(为了保持对所有UE的可达性) - 某些运营商可能仅在特定时间段允许MICO(如夜间低负载时段) - AMF可以根据当前跟踪区域(TA)的负载情况动态调整MICO策略
标准4:网络负载状态 当AMF检测到网络拥塞或需要向大量UE推送信息(如ETWS/CMAS紧急警报)时,可能临时拒绝MICO请求。这是为了确保在紧急情况下网络能够寻呼所有UE。
标准5:UE类型判断 虽然3GPP规范没有强制要求AMF根据UE类型做决策,但实际运营商部署中,AMF通常结合以下信息判断: - UE的5GMM Capability中是否指示了MICO能力 - UE的Subscription中的Service Type(如是否为IoT专用套餐) - RFSP(RF Spatial Preference)索引是否指向IoT专用频段
当UE处于MICO模式+CM-IDLE状态时,如果有下行数据到达(例如应用服务器尝试向IoT传感器发送控制命令),整个处理链路如下:
sequenceDiagram
participant AF as Application Server
participant UPF
participant SMF
participant AMF
participant UDM
AF->>UPF: 下行数据包<br/>(目的地址=UE IP)
UPF->>SMF: N4 Session Report<br/>(Data Notification)<br/>告知有下行数据待发送
SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N2 SM Information + N1 SM Container)
Note right of SMF: SMF尝试通过AMF<br/>向UE发送下行信令
AMF->>AMF: 检查UE状态:<br/>CM-IDLE + MICO Mode = Active
alt 策略1:直接拒绝
AMF-->>SMF: HTTP 503 Service Unavailable<br/>Cause: "UE not reachable due to MICO"
SMF-->>UPF: N4 Session Modification<br/>(指示丢弃下行数据)
Note right of AMF: 最简单粗暴的策略<br/>直接告知SMF UE不可达
else 策略2:缓冲等待UE唤醒
AMF-->>SMF: HTTP 503 + 缓冲指示
SMF->>SMF: 启动缓冲定时器<br/>(等待UE发起Service Request)
Note right of SMF: 数据被暂存于UPF<br/>直到UE下次唤醒
else 策略3:触发UE可达性通知
AMF->>SMF: Nsmf_EventExposure_Notify<br/>(UE Reachability = unreachable)
SMF->>AF: 通知应用服务器<br/>UE当前不可达
Note right of AMF: 让应用层决定<br/>是否重试或延迟发送
end
三种策略的运营商成本博弈分析:
| 策略 | 优点 | 缺点 | 适用场景 | 运营商成本 |
|---|---|---|---|---|
| 直接拒绝+丢弃 | 实现简单,无存储开销 | 数据丢失,应用层需重传 | 对丢包容忍的场景(如遥测下行确认) | 最低 |
| 缓冲等待唤醒 | 数据不丢失 | SMF/UPF需要缓冲资源,延迟不确定(可能数小时) | 控制指令不可丢失的场景(如固件升级触发) | 中等(需要缓冲资源) |
| 可达性通知 | 应用层可智能调度 | 需要NEF/AF支持事件订阅 | 高价值IoT应用(如车联网远程控制) | 较高(需要事件订阅架构) |
根据TS 23.501 §5.4.1.3的明确规定:AMF shall reject any request for downlink data delivery for UE in MICO mode and whose UE CM state in AMF is CM-IDLE。也就是说,规范层面的默认行为是直接拒绝,缓冲和通知是运营商可选的增值策略。
MICO模式中一个极具设计智慧的机制是注册区域分配策略。根据TS 23.501 §5.4.1.3:
"A UE in CM-IDLE in MICO mode can be provided with a registration area that is the entire PLMN if the AMF serves the entire PLMN."
这意味着,当AMF服务整个PLMN时,可以给MICO模式的UE分配一个等于整个PLMN的注册区域。这个设计的深层意图是多维度的:
1. 消除移动性触发的注册更新 如果注册区域=整个PLMN,那么UE无论怎么移动(小区重选),都不会触发"Mobility Registration Update"。这极大减少了MICO模式UE的空口信令。
2. 与MICO的语义一致性 MICO模式的UE本就不被寻呼,那么AMF不需要知道UE的精确位置。分配整个PLMN作为注册区域,与"不需要寻呼"的语义完全一致——既然不寻呼,何必追踪位置?
3. 减少AMF负载 大量IoT设备的移动性注册更新会给AMF带来巨大负载。全PLMN注册区域策略可以从源头上消除这类信令。
4. 潜在风险 全PLMN注册区域也有代价:当UE移动到另一个AMF的服务区域时,可能需要AMF重分配(AMF Reallocation),这在TS 23.502 §4.2.2.2.3中有详细描述。
flowchart LR
subgraph 正常模式UE
A1[TAI List = TA1, TA2, TA3] --> B1[离开TAI List]
B1 --> C1[触发Mobility Registration Update]
C1 --> D1[信令开销大<br/>位置精确度高]
end
subgraph MICO模式UE
A2[Registration Area = 整个PLMN] --> B2[任意移动]
B2 --> C2[不触发位置更新]
C2 --> D2[信令开销极低<br/>但位置不可知]
end
subgraph MICO模式UE-小区域
A3[Registration Area = TA1, TA2] --> B3[有MO数据待发送时检查]
B3 --> C3[离开区域则附带注册更新]
C3 --> D3[折中方案:<br/>在MO数据发送时顺便更新]
end
第三种情况的精妙之处:当MICO UE被分配较小的注册区域时,UE不是在离开区域时立即发起注册更新,而是在有上行数据/信令待发送时,在发送的Registration Request中附带位置更新。这种"捎带"(piggyback)机制是MICO模式的另一个省电设计。
MICO模式下,UE与网络之间唯一的"心跳"机制是周期性注册定时器T3512。这个定时器的值决定了UE多久必须主动联系一次网络。
T3512编码格式(TS 24.501 §9.11.2.5,GPRS Timer 3格式):
| 八位组 | 比特位 | 含义 |
|---|---|---|
| IEI | Octet 1 | 定时器标识 |
| Length | Octet 2 | 固定为1 |
| Unit | Octet 3 Bit 7-6 | 00=2秒, 01=分钟, 10=6分钟, 11=小时 |
| Timer Value | Octet 3 Bit 5-0 | 0-63 × 单位 |
T3512典型配置场景:
| UE类型 | T3512建议值 | 对应的二进制编码 | UE唤醒频率 |
|---|---|---|---|
| 智能水表 | 24小时 | Unit=11(小时), Value=24(0x18) → 0xD8 | 每天1次 |
| 环境传感器 | 72小时 | Unit=11(小时), Value=72(0x48) → 0xE8 | 每3天1次 |
| 智能停车传感器 | 6小时 | Unit=10(6分钟), Value=60(0x3C) → 0xBC | 每6小时1次 |
| 资产追踪器 | 1小时 | Unit=01(分钟), Value=60(0x3C) → 0x7C | 每小时1次 |
T3512博弈分析:
stateDiagram-v2
[*] --> RM_Deregistered: UE开机
RM_Deregistered --> RM_Registered: Registration成功
RM_Registered --> RM_Deregistered: Deregistration
state RM_Registered {
[*] --> CM_IDLE_MICO_Yes: MICO Granted
[*] --> CM_IDLE_Normal: MICO Rejected
CM_IDLE_MICO_Yes --> CM_CONNECTED: UE发起MO数据/信令
CM_IDLE_Normal --> CM_CONNECTED: UE发起MO数据<br/>或被寻呼(MT)
CM_CONNECTED --> CM_IDLE_MICO_Yes: NAS连接释放<br/>且MICO仍然active
CM_CONNECTED --> CM_IDLE_Normal: NAS连接释放<br/>MICO被AMF撤销
note right of CM_IDLE_MICO_Yes
MICO Active状态:
- 不监听寻呼
- 不触发移动性注册更新
- 仅T3512到期或MO数据时唤醒
end note
note right of CM_IDLE_Normal
正常CM-IDLE:
- 正常监听寻呼
- 离开TAI List触发注册更新
- 可被网络寻呼
end note
}
状态转换中的MICO关键规则(TS 23.501 §5.4.1.3):
MICO仅在CM-IDLE时生效:即使UE被授权了MICO模式,在CM-CONNECTED状态下UE仍然可以接收下行数据。MICO的寻呼豁免仅在CM-IDLE状态下有效。
CM-CONNECTED不改变MICO授权:UE进入CM-CONNECTED状态(如发起Service Request)后,MICO授权不会自动取消。当UE回到CM-IDLE时,MICO模式继续有效。
AMF可动态撤销MICO:通过UE Configuration Update(TS 24.501 §5.4.4)或下一次Registration Accept中不携带MICO Indication,AMF可以撤销UE的MICO模式。
每次注册都重新协商:MICO模式不是永久的。每次Registration(包括周期性注册更新),UE和AMF都重新协商MICO。这意味着AMF可以基于当前网络状态动态调整MICO策略。
LADN(Local Area Data Network,本地数据网络)是5G另一个与MICO紧密相关的特性。根据TS 23.501 §5.6.6,LADN仅在特定地理区域内可用。MICO模式UE与LADN的交互存在一个有趣的设计矛盾:
矛盾点:MICO UE不监听寻呼、不更新位置,那么AMF如何知道MICO UE是否仍在LADN服务区域内?
3GPP的解决方案(TS 23.501 §5.4.1.3 + §5.6.6):
| 场景 | MICO UE行为 | AMF行为 |
|---|---|---|
| UE在LADN区域内唤醒 | 可正常建立LADN PDU Session | 提供LADN可用性信息 |
| UE离开LADN区域后唤醒 | 应避免请求LADN PDU Session | 不提供LADN信息或指示不可用 |
| UE在LADN区域内但MICO IDLE | 不会被网络通知LADN变化 | 无法通知UE(因不寻呼) |
| UE有激活的LADN PDU Session | 走正常PDU Session释放流程 | SMF检测UE不在LADN区域后释放会话 |
| 维度 | MICO模式 | PSM(Power Saving Mode) | eDRX(Extended DRX) |
|---|---|---|---|
| 规范定义 | TS 23.501 §5.4.1.3 | TS 23.501 §5.31.7 | TS 23.501 §5.31.3-6 |
| 核心机制 | 网络不寻呼UE | UE进入深睡眠(不监听任何信道) | UE延长DRX周期,周期性监听寻呼 |
| 下行可达性 | 完全不可达 | 仅Active Time期间可达 | PTW窗口内可达 |
| 省电程度 | ★★★★★(极致) | ★★★★★(极致) | ★★★☆☆(中等) |
| 最大睡眠时间 | 等于T3512(可配置数天) | 等于T3412-ext(最长约413天) | 等于eDRX周期(最长约2.9小时) |
| 适用网络 | 仅5GS | 4G EPS + 5GS | 4G EPS + 5GS |
| 协商位置 | Registration Request/Accept | Attach Request/Accept 或 TAU Request/Accept | Attach Request/Accept 或 TAU Request/Accept |
| 与5G切片的耦合 | 紧密(通过Allowed NSSAI) | 无直接耦合 | 无直接耦合 |
| 典型设备 | 智能水表、垃圾桶传感器 | 环境传感器、智能仪表 | 可穿戴设备、资产追踪器 |
| 能否与eDRX共存 | 规范未明确禁止,但实际意义不大 | 可以与eDRX组合使用 | 可以与PSM组合使用 |
关键差异解读: - MICO是5G独有的核心网级别省电机制,PSM和eDRX是从4G继承的 - MICO的省电原理是"网络不寻呼",PSM是"UE主动深睡",eDRX是"UE延长监听周期" - MICO与5G切片(S-NSSAI)紧密耦合,AMF可能为MICO UE分配特殊的Allowed NSSAI - 在实践中,MICO通常独立使用,而PSM+eDRX经常组合使用
Wireshark过滤规则:
# 过滤Registration Request中的MICO Indication
nas-5gs.reg_type == 1 && nas-5gs.mico_indication == 1
# 过滤Registration Accept中的MICO授权
nas-5gs.msg_type == 0x42 && nas-5gs.mico_indication == 1
# 过滤T3512定时器值
nas-5gs.t3512_value
# NGAP层面识别MICO UE的Initial Context Setup
ngap.procedureCode == 14
关键识别点:
| 故障现象 | 可能原因 | 排错思路 |
|---|---|---|
| IoT设备MICO请求被拒绝 | UDM订阅数据中MICO未授权 | 检查Nudm_SDM_Get响应中的MICO相关字段 |
| MICO UE周期性注册失败 | T3512过长导致UE超时或网络侧删除了UE上下文 | 检查AMF的隐式去注册定时器(Implicit Deregistration Timer)是否小于T3512 |
| 下行数据丢失 | AMF在MICO模式下直接拒绝下行数据通知 | 检查SMF是否配置了数据缓冲策略 |
| MICO UE无法建立PDU Session | MICO UE的Allowed NSSAI限制了可用切片 | 检查Registration Accept中的Allowed NSSAI |
| MICO UE位置不可追踪 | 全PLMN注册区域导致AMF无法确定UE位置 | 正常现象——MICO设计即如此。需要时通过UE可达性通知机制解决 |
| ## 十一、运营商部署MICO的实际考量 |
MICO模式对运营商的核心价值在于减少寻呼负载。一个拥有100万IoT设备的网络,如果这些设备不使用MICO,每秒钟可能需要发送数千次寻呼消息。MICO模式将这些寻呼开销降为零。
但MICO也有隐性成本: - SMF/UPF缓冲资源:下行数据需要临时存储 - 可达性管理复杂度:AF/NEF需要订阅UE可达性事件 - AMF MICO策略管理:需要为不同IoT业务配置差异化MICO策略
Q1: MICO模式和PSM能否同时激活? A: 根据TS 23.501 §5.4.1.3和§5.31.7,MICO和PSM在机制上有重叠但并非互斥。规范允许MICO模式的UE同时协商PSM参数。但在实际部署中,MICO已经提供了极致省电(完全不监听寻呼),叠加PSM的意义有限。大多数厂商选择只启用其中一种。PSM的优势在于可以定义Active Time(T3324),让UE在进入深睡前有一段时间保持可达,这是MICO不提供的。
Q2: MICO模式下紧急呼叫如何处理? A: 紧急呼叫是UE发起的(Mobile Originated),MICO模式仅限制网络发起的寻呼,不限制UE发起的通信。因此MICO UE始终可以发起紧急呼叫。但紧急注册时MICO不被授权,所以UE在紧急注册后不会被置于MICO模式。
Q3: AMF如何动态撤销已授权的MICO模式? A: 有三种机制:(1)通过UE Configuration Update Command(TS 24.501 §5.4.4)在不带MICO Indication的情况下更新UE配置;(2)在下一次周期性注册更新中,Registration Accept不携带MICO Indication;(3)通过Nudm_SDM_Notification从UDM推送更新的订阅策略,AMF据此在下次交互时改变MICO授权。
Q4: MICO UE的PDU Session在CM-IDLE时如何处理? A: 根据TS 23.501 §5.4.1.3,MICO UE在CM-IDLE状态下,其PDU Session仍然维持在SMF/UPF中(除非因不活动超时被释放)。当UE通过MO Service Request回到CM-CONNECTED时,可以恢复PDU Session的数据传输。这与正常UE的行为一致,区别在于MICO UE不会被网络通过寻呼唤醒以接收下行数据。
Q5: Rel-18/19对MICO有哪些增强? A: Rel-18引入了对卫星接入场景下MICO的增强(TS 23.501 §5.4.13),允许在间歇性卫星覆盖中使用MICO模式优化省电。Rel-19引入了LP-WUS(Low Power Wake Up Signal)与MICO的交互(TS 23.501 §5.4.12a),为MICO UE提供了一种在保持极致省电的同时偶尔接收关键下行通知的机制。
本文由「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 等场景全覆盖。
