深度解析 3GPP TS 27.007：9 Mobile termination errors (移动终端错误)

本文技术原理深度参考了3GPP TS 27.007 V19.4.0 (2025-09) Release 19 规范中，关于“9 Mobile termination errors”的核心章节。本章是每一位通信应用开发者的“调试圣经”，它定义了如何从模组获取精确的错误信息，并解读这些信息背后的深层含义。掌握本章，意味着你将拥有洞察通信故障的“火眼金睛”。

写在前面：当“天眼”遭遇“滑铁卢”

在上一章的探索中，我们的主角——物联网工程师小李，已经成功地掌握了如何控制模组的核心状态和进行人机交互。他的“天眼”追踪器原型，不仅能连上5G网络，还能通过小屏幕显示自身状态，响应按键操作。一切似乎都进展顺利。

然而，当他将原型机带到公司地下一层的停车场进行实地测试时，问题出现了。设备开机后，屏幕上只是孤零零地显示着“网络连接中…”，几分钟过去了，毫无动静。小李连接上调试串口，他之前编写的程序日志只是机械地重复着“激活数据连接…失败…重试…”。

他尝试手动发送AT+CGACT=1,1，模组冷冷地返回了一行ERROR。

ERROR！这个词对于开发者来说，是世界上最无助的词语之一。它只告诉你“错了”，却丝毫不提及“错在哪”和“为什么错”。是因为信号不好？SIM卡欠费？APN配错了？还是网络侧出了问题？面对这个“黑盒”，小李束手无策。

这时，他想起了规范中专门用来处理这种情况的一章——第九章，“Mobile termination errors”。这一章，正是为了打破ERROR的魔咒，将模组从一个不可揣测的“黑盒”，变成一个能够清晰自我诊断的“水晶盒”。

本章内容将是小李，以及所有通信开发者，从“能用”走向“可靠”的关键一步。让我们跟随小李，学习如何开启模组的“话痨”模式，并听懂它所诉说的每一个“苦衷”。

---

1. 打破沉默的魔咒：AT+CMEE 命令详解

面对令人沮丧的ERROR，小李首先要做的，就是让模组“开口说话”，告诉他更详细的错误信息。AT+CMEE (Report Mobile Termination Error) 命令正是完成这一任务的“总开关”。

Description

Set command disables or enables the use of final result code +CME ERROR: as an indication of an error relating to the functionality of the MT. When enabled, MT related errors cause +CME ERROR: final result code instead of the regular ERROR final result code.

这段描述直击要害：+CMEE命令的作用，就是用更详细的+CME ERROR: <err>来替代笼统的ERROR。它就像是应用的“调试模式开关”。

Table 110: +CMEE parameter command syntax

| Command | Possible response(s) |

| :--- | :--- |

| +CMEE=[<n>] | |

| +CMEE? | +CMEE: <n> |

| +CMEE=? | +CMEE: (list of supported <n>s) |

参数<n>有三个关键的取值：

• 0 (disable): 关闭详细错误报告。模组只返回ERROR。（默认值）

• 1 (enable and use numeric values): 开启详细错误报告，并使用数字格式的错误码。

• 2 (enable and use verbose values): 开启详细错误报告，并使用文本格式（可读字符串）的错误描述。

小李的顿悟与实践：

他立刻明白了问题所在。他回到停车场，在发送AT+CGACT=1,1之前，先发送了一条命令：

AT+CMEE=2

模组返回OK。然后，他再次尝试激活数据连接：

AT+CGACT=1,1

这一次，模组的响应不再是那个冰冷的ERROR，而是：

+CME ERROR: no network service

“没有网络服务！” 答案瞬间揭晓。地下停车场信号覆盖太差，导致模组根本无法注册到网络上，自然也就无法激活数据连接。问题定位！

开发策略的转变：

小李立刻在他的MCU固件初始化代码的最前端，加入了AT+CMEE=2这条指令。他决定：

• 开发和调试阶段： 始终使用+CMEE=2（文本模式），错误信息直观，便于快速定位问题。

• 量产和日志记录阶段： 可能会切换到AT+CMEE=1（数字模式）。数字错误码更紧凑，便于MCU解析和存储在有限的日志空间中，然后由云平台根据错误码表进行翻译和分析。

+CMEE命令是AT命令调试的第一道大门，也是最重要的一道。永远不要在没有开启+CMEE的情况下进行开发和调试！

---

2. “错误代码速查表”：深入解读 +CME ERROR 的世界 (9.2)

开启了+CMEE之后，小李就拥有了一本详尽的“错误代码速查表”。规范的9.2节，用巨大的篇幅，列举了从0到几百个错误代码的含义。这些代码不是杂乱无章的，而是经过精心分类，反映了错误发生的不同阶段和层面。小李决定将它们分门别类进行学习。

2.1 通用错误 (General errors, 0-100)：日常开发的基础障碍

这部分错误码覆盖了最常见的、与设备自身状态或简单交互相关的失败。

9.2.1 General errors

Numeric Text

0 phone failure

…

3 operation not allowed

…

10 SIM not inserted

11 SIM PIN required

12 SIM PUK required

13 SIM failure

…

16 incorrect password

…

30 no network service

小李为这些高频错误构建了具体的故障场景：

• 场景一：SIM卡问题

  • 现象： AT+CPIN? 返回 +CME ERROR: 10 (SIM not inserted)。

  • 诊断： 物理问题。SIM卡没插好，卡座坏了，或者SIM卡触点脏了。

  • 现象： AT+CPIN="1234" 返回 +CME ERROR: 16 (incorrect password)。

  • 诊断： PIN码错误。连续三次错误后，将返回+CME ERROR: 12 (SIM PUK required)。

  • 现象： AT+CIMI 返回 +CME ERROR: 13 (SIM failure)。

  • 诊断： SIM卡可能已损坏，或者与模组不兼容。

• 场景二：操作权限问题

  • 现象： 尝试修改一个只读参数，如AT+CGSN="new_imei"。

  • 诊断： 返回 +CME ERROR: 3 (operation not allowed) 或 +CME ERROR: 4 (operation not supported)。这告诉小李，他的操作逻辑本身是错误的。

• 场景三：网络环境问题

  • 现象： 在地下室发送AT+COPS?。

  • 诊断： 返回 +CME ERROR: 30 (no network service)。简单直接，问题出在环境，而不是设备或SIM卡。

2.2 网络附着失败 (Attach Errors, 9.2.2.1)：“被拒之门外”

这是物联网设备最核心的故障之一。设备已经开机，SIM卡也正常，但就是无法注册到网络上。这类错误码直接反映了网络侧（核心网）拒绝UE接入的原因，其定义与NAS信令（TS 24.501等）中的拒绝原因值高度相关。

9.2.2.1.3 Errors for 5GS

Numeric Text

103 Illegal UE

…

111 PLMN not allowed

113 Roaming not allowed in this tracking area

172 Semantically incorrect message

小李正在测试一张新的物联网卡，但AT+CGATT=1总是失败，并返回了+CME ERROR: 111。

• 查询速查表： 111 对应 PLMN not allowed。

• 深入分析： 这意味着网络明确拒绝了该IMSI的接入请求。小李立刻联想到几种可能：

  1. 这张SIM卡还没有在运营商的系统中激活。

  2. 这张卡是归属于A运营商的，但当前环境中只有B运营商的信号，而A、B之间没有签署漫游协议。

  3. SIM卡的订阅信息中，限制了它只能在特定的区域（如某省）使用，而设备当前不在该区域内。

• 解决方案： 小李联系了SIM卡供应商，确认是卡片尚未激活。问题解决。

其他常见的附着错误还包括：

• 103 (Illegal UE): 设备的IMEI被运营商加入了黑名单（例如，该设备是失窃设备或未经认证的设备）。

• 113 (Roaming not allowed in this tracking area): SIM卡本身支持漫游，但在当前所在的这个特定跟踪区（TA）内，漫游是不被允许的。这通常是运营商之间的精细化策略。

2.3 数据激活失败 (Context Activation Errors, 9.2.2.2)： “能打电话，不能上网”

这是另一种常见且令人困惑的故障。设备已经成功附着到网络（+C5GREG: 1或5），但执行AT+CGACT=1,1时却失败了。这说明设备与网络的信令连接是正常的，但数据通道的建立请求被拒绝了。

9.2.2.2.3 Errors for 5GS

Numeric Text

126 Insufficient resources

127 Missing or unknown DNN

129 User authentication or authorization failed

130 Request rejected, unspecified

小李的“天眼”设备在办公室测试一切正常，但到了客户现场，却出现了+CME ERROR: 127。

• 查询速查表： 127 对应 Missing or unknown DNN（在4G及以前，是Missing or unknown APN）。

• 深入分析： DNN/APN是数据网络的入口。这个错误说明，设备请求连接的"cmiot"这个APN，在当前所在的网络（可能是漫游网络）中，是不被识别或不支持的。

• 解决方案： 小李联系客户，确认他们的现场网络环境需要使用另一个专网APN "customer.net"。他在程序中修改了AT+CGDCONT的APN参数，问题解决。

其他常见的数据激活错误：

• 126 (Insufficient resources): 网络侧资源不足，无法为你的设备分配数据通道资源（如IP地址、承载资源）。这通常是暂时性的网络拥塞。

• 129 (User authentication or authorization failed): 某些专网APN需要用户名和密码认证（通过AT+CGAUTH设置）。这个错误说明认证信息错误或缺失。

• 178 (Maximum number of PDU sessions reached): 尝试激活的数据连接数，超过了设备或网络支持的上限。

通过对这些错误码的分类学习，小李建立了一套清晰的故障诊断流程：先查通用错误（硬件/SIM）→ 再查附着错误（网络准入）→ 最后查激活错误（数据业务权限）。

---

3. “未卜先知”：用 +CNEC 捕获网络底层错误

+CMEE是在命令执行失败后提供详细信息，而+CNEC (Report Network Error Codes) 则更进一步，它允许TE主动接收来自网络底层的错误报告，即便这些错误还没有导致某条AT命令失败。

Description

The command activates or deactivates unsolicited reporting of error codes sent by the network. When activated, based on the setting of , the ME will report CS mobility management, GPRS mobility management… related error codes sent by the network.

Table 9.1B-1: +CNEC parameter command syntax

| Command | Possible response(s) |

| :--- | :--- |

| +CNEC=[<n>] | |

| +CNEC? | +CNEC: <n> |

| +CNEC=? | +CNEC: (list of supported <n>s) |

参数<n>是一个位图（bitmap），允许开发者订阅不同协议层面的错误信息：

• 1 (bit 0): CS 移动性管理 (MM) 错误

• 2 (bit 1): GPRS 移动性管理 (GMM) 错误

• 4 (bit 2): GPRS 会话管理 (GSM) 错误

• 8 (bit 3): EPS 移动性管理 (EMM) 错误

• 16 (bit 4): EPS 会话管理 (ESM) 错误

• 32 (bit 5): 5GS 移动性管理 (5GMM) 错误

• 64 (bit 6): 5GS 会话管理 (5GSM) 错误

小李的高级诊断策略：

为了进行深入的现场测试，他决定捕获所有类型的网络错误。

1. 发送命令： AT+CNEC=127 (1+2+4+8+16+32+64)

2. 模组响应： OK

现在，模组变成了一个网络信令的“侦听器”。

• 场景： 设备正在一个信号边缘区域移动。网络尝试将它从一个小区切换到另一个，但切换失败，网络向UE发送了一条带有特定原因值的拒绝消息。这个过程非常快，可能还不足以导致上层应用感知到“掉线”。

• URC上报： 开启了+CNEC的模组，会立即捕获到这个底层的拒绝消息，并上报一个URC，例如：

  +CNEC_EMM: 19

• 分析： 19在EPS EMM中可能代表“ESM failure”。这给了小李一个宝贵的线索：网络切换过程中，会话管理层面出现了问题。这比事后发现数据不通再去排查，要提前了关键的一步。

+CNEC是高级调试和网络质量监控的利器，它让开发者能够洞察到冰山之下的信令风暴。

---

总结

第九章“移动终端错误”，是连接理论与残酷现实的桥梁。它不教我们如何成功，而是教我们如何优雅、高效地处理失败。通过本章的学习，小李的技能树得到了巨大的提升：

• 他学会了使用 AT+CMEE 这个最强大的调试工具，让模组从“沉默的黑盒”变成了“健谈的伙伴”。

• 他掌握了三大类核心错误码的诊断逻辑，能够快速区分硬件、SIM卡、网络准入和业务配置等不同层面的问题。

• 他了解了如何利用 +CNEC 这种主动错误上报机制，去捕获那些转瞬即逝的底层网络异常，为产品的稳定性优化提供了前所未有的深度视角。

现在，小李的“天眼”追踪器不仅能工作，更重要的是，当它不能工作时，它能清晰地告诉小李“为什么”。这正是区分一个业余原型和一个专业产品的关键所在。具备了强大的故障诊断能力，小李对“天眼”项目的最终成功充满了信心。

---

FAQ：快速问答

Q1：在我的最终量产产品中，AT+CMEE应该设置为1（数字）还是2（文本）？

A1：这取决于您的产品策略。

• 设置为2（文本）的优点：现场技术支持或高级用户通过调试接口可以直接读懂错误，方便快速排查。缺点：错误信息字符串较长，占用更多的日志存储空间和传输带宽。

• 设置为1（数字）的优点：错误码紧凑，节省日志空间和上报流量。缺点：不直观，需要后台系统配合错误码表进行翻译。

推荐做法：对于大多数资源受限的物联网设备，量产版本推荐使用AT+CMEE=1，并通过日志系统将错误码上传到云端进行统一分析和展示。

Q2：模组返回了+CME ERROR: 50 (Incorrect parameters)，但我检查了我的AT命令语法，完全符合规范，这是为什么？

A2：Incorrect parameters除了字面上的语法错误，还可能意味着“参数的组合不合逻辑”或“在当前状态下参数值无效”。例如：

1. 参数逻辑冲突： 比如在一个设置时间的命令中，你设置的“结束时间”早于“开始时间”。

2. 状态与参数不匹配： 比如AT+CHLD=2（在两路通话间切换）命令，你必须在有一个激活通话和一个保持通话的状态下才能使用。如果你只有一个通话，执行此命令就可能返回参数错误。

因此，遇到此错误时，不仅要检查语法，还要检查命令执行的上下文（Context）和前提条件。

Q3：我的设备在国外漫游时，频繁出现+CME ERROR: 113 (Roaming not allowed in this location area)，这是什么意思？

A3：这个错误比+CME ERROR: 111 (PLMN not allowed) 更具体。它说明你的SIM卡套餐是支持国际漫游的，但在设备当前所在的这个特定区域（由Location Area Code或Tracking Area Code标识），运营商之间的漫游协议可能存在限制，或者你的套餐不包含在该区域的漫游服务内。这通常是运营商精细化策略导致，需要联系SIM卡提供商，确认你的漫游套餐覆盖范围是否包含该特定区域。

Q4：为什么规范要区分移动性管理（MM/GMM/EMM/5GMM）和会话管理（GSM/ESM/5GSM）的错误？

A4：这是因为它们对应了UE在网络中的两种核心状态机：

• 移动性管理（MM）：负责UE的“在网”状态，处理的是注册、去附着、位置更新等流程。它的核心任务是让网络知道“我是谁”以及“我在哪”。MM失败，意味着设备彻底掉线。

• 会话管理（SM）：负责UE的“数据通道”状态，处理的是PDP/PDU会话的建立、修改、删除等流程。它的核心任务是为应用层提供数据传输的“管道”。SM失败，通常意味着“能打电话不能上网”。

通过+CNEC将这两类错误分开上报，可以让开发者精确地知道是设备的“身份/位置”出了问题，还是“数据管道”出了问题。

Q5：+CME ERROR列表如此庞大，我需要全部记住吗？

A5：完全不需要。作为开发者，你应该重点掌握最常见的20-30个错误码，特别是通用错误、附着错误和数据激活错误中的高频错误。对于其他不常见的错误，你只需要知道去哪里查找（你的模组AT手册或TS 27.007规范本身），并在你的代码中做好通用的错误处理逻辑，能够记录和上报任何未知的错误码即可。关键是建立起分类诊断的思维模式，而不是死记硬背。