51学通信

深度解析 3GPP TS 27.007：10 Commands for packet domain (Part 5 - 资源管理与功耗优化)

23分钟阅读

深度解析 3GPP TS 27.007：10 Commands for packet domain (Part 5 - 资源管理与功耗优化)

本文技术原理深度参考了3GPP TS 27.007 V19.4.0 (2025-09) Release 19 规范中，关于“10 Commands for packet domain”的核心章节。在前四部分中，我们已掌握了数据连接的建立、QoS保障、动态管理及行为模式定义。本文为Part 5，我们将聚焦于连接建立之后的“精打细算”：如何进行资源清理、如何与网络协同进行信令与功耗优化、如何应对网络拥塞时的“退避”策略，以及如何实现蜂窝与Wi-Fi的智能切换。

写在前面：小李的“精细化运营”挑战

工程师小李的“天眼”追踪器项目已经进入了小规模部署和压力测试阶段。设备能够稳定地在全球各地接入网络，并根据业务优先级智能地调度数据，这让他倍感自豪。然而，随着设备数量的增加和运行时间的延长，一些更深层次、更“精细化”的问题开始暴露出来，运维团队向小李提出了新的挑战：

  1. “内存泄漏”疑云：运维人员发现，经过长时间运行和多次网络切换后，一些设备的内存占用有微小的、持续的增长，他们怀疑是模组内部定义了过多的、不再使用的“连接配置档案”导致的。

  2. “电量焦虑”：在一次关键的续航测试中，设备的数据发送间隔被设置为很短。测试人员发现，即使在数据发送的间隙，设备的功耗也迟迟降不下来，远高于预期。他们需要一种方式，能主动告诉网络“我已经没事了，请让我尽快休息”。

  3. “连接风暴”：在一个大型仓库中，由于一次短暂的局部网络中断，上百台“天眼”设备在网络恢复的瞬间同时发起重连请求，导致了信令拥塞，结果大部分设备都因网络拒绝而重连失败，并陷入了“重试-失败-再重试”的恶性循环。

  4. “降本增效”：客户的一个大型物流中心覆盖了高质量的企业级Wi-Fi。他们希望部署在该中心的“天眼”设备，能够优先使用免费的Wi-Fi来传输数据，仅在Wi-Fi信号弱或不可用时，才切换到蜂窝网络，以节省大量的流量费用。

这些问题，不再是“能不能用”的问题，而是“用得好不好、用得省不省、用得稳不稳”的精细化运营问题。小李明白，他必须让“天眼”学会自我清理、主动节能、遵守秩序、择路而行。

他再次深入第十章，这次他的目标是那些用于资源管理、功耗优化和高级连接策略的AT命令。+CGDEL、+CNMPSD、+CABTSR、+CWLANOLAD……这些命令将赋予“天眼”真正的运营智慧。

1. 资源的“断舍离”：用 +CGDEL 清理无用上下文

首先，小李要解决运维团队提出的“内存泄漏”疑云。虽然这不一定是真正的内存泄漏，但管理不再使用的PDP/PDU会话定义，确实是保持设备长期稳定运行的好习惯。+CGDEL (Delete non-active PDP contexts) 命令就是为此设计的清理工具。

Description

The execution command +CGDEL= removes the indicated PDP context and removes all associated data related to the indicated PDP contexts that are not activated. The AT command will not delete or remove information for activated PDP contexts.

这段描述的核心是：+CGDEL只能删除未激活 (not activated) 的上下文。这是一种安全机制，防止开发者误删正在使用的数据连接。

Table 10.1.29-1: +CGDEL action command syntax

| Command | Possible Response(s) |

| :--- | :--- |

|+CGDEL[=<cid>]| [+CGDEL: <cid>[,<cid>[,...]]]
+CME ERROR: <err> |

|+CGDEL=?| |

+CGDEL提供了两种清理模式：

  • 精确删除 +CGDEL=<cid>:

    删除一个指定的、未激活的上下文。如果该上下文是主上下文（Primary），并且关联了其他未激活的次要上下文（Secondary），那么这些次要上下文也会被一并删除。

  • 批量删除 +CGDEL (不带参数):

    A special form of the command can be given as +CGDEL (with the = omitted). In this form, all primary PDP contexts that are not activated or have any activated secondary PDP contexts will be removed and all secondary PDP contexts that are not activated will be removed.

    这是一个强大的“一键清理”功能。它会删除所有完全空闲的上下文。

小李的“垃圾回收”机制：

为了解决资源占用的问题，小李在他的固件中设计了一个简单的“垃圾回收”函数：

  1. 定期巡检： MCU每隔24小时，或者在每次长途运输任务结束后，执行一次清理。

  2. 查询所有上下文状态： 发送AT+CGACT?，获取所有已定义的<cid>及其激活状态。

  3. 识别无用上下文： 遍历+CGACT?的返回结果，找出所有<state>为0（deactivated）的<cid>。

  4. 执行精确删除： 针对每一个识别出的无用<cid>，发送AT+CGDEL=<cid>。

  5. 或者，执行批量删除： 如果业务逻辑允许，更简单粗暴的方式是直接发送AT+CGDEL，模组会自动完成所有未激活上下文的清理工作。

通过引入+CGDEL，小李确保了“天眼”设备在长期运行后，其内部配置依然保持干净、高效，从根源上杜绝了因配置冗余导致的潜在问题。

2. 主动节能：用 +CNMPSD 和 +CEPPI 优化信令

解决了资源清理，小李转向了更棘手的功耗问题。他发现，即使数据发送完毕，模组依然在RRC Connected状态下“空转”一段时间，等待网络侧的RRC Inactivity Timer超时，这期间的功耗远高于Idle状态。他需要一种方法，能主动告诉网络：“我的话说完了，可以挂电话了。”

2.1 +CNMPSD：向网络发出“休眠”信号 (No More PS Data)

+CNMPSD就是这样一个“礼貌的告别”信号。

Description

This command indicates that no application is expected to exchange data.

When in E-UTRAN…, this can cause transmission of a UEAssistanceInformation message with powerPrefIndication set to “lowPowerConsumption” to the network.

Table 10.1.33-1: +CNMPSD action command syntax

| Command | Possible Response(s) |

| :--- | :--- |

| +CNMPSD | |

| +CNMPSD=? | |

这个命令非常简单，没有参数。当TE执行它时，模组会向网络发送一个**“UE Assistance Information”**信令，其中携带了一个“低功耗偏好”的指示。

工作流程与效果：

  1. TE发送数据： MCU通过数据通道发送完最后一包数据。

  2. TE发送+CNMPSD： MCU立即通过AT命令通道发送AT+CNMPSD。

  3. 模组通知网络： 模组将这个“请求”封装成底层信令发送给基站。

  4. 网络（基站）决策： 基站收到这个“暗示”后，可以（但非必须） 不再等待RRC Inactivity Timer走完，而是立即释放该UE的RRC连接，使其快速进入低功耗的RRC Idle状态。

小李的节能代码优化：

他修改了数据上报函数：

 
// 伪代码
 
function send_data(packet) {
 
  // ... socket send logic ...
 
  socket_send(packet);
 
  // 新增逻辑：发送完最后一包后，立刻通知网络
 
  if (is_last_packet_of_burst()) {
 
    at_command_send("AT+CNMPSD");
 
  }
 
}

这个小小的改动，使得每次数据传输后，设备都能更快地进入节能状态，积少成多，极大地延长了整体续航。

2.2 +CEPPI：更明确的功耗“偏好” (Power Preference Indication)

+CEPPI提供了另一种，或者说更明确的方式来向网络表达功耗偏好。

Description

This command indicates whether the MT prefers a configuration primarily optimised for power saving or not.

Table 10.1.38-1: +CEPPI action command syntax

| Command | Possible Response(s) |

| :--- | :--- |

| +CEPPI=<power preference> | |

| +CEPPI=? | +CEPPI: (list of supported ...) |

  • <power preference>=0: Normal（正常模式）。

  • <power preference>=1: Low power consumption（低功耗偏好）。

+CEPPI和+CNMPSD的作用类似，都是通过UEAssistanceInformation信令向网络传递信息。它们的细微区别在于：

  • +CNMPSD更像一个一次性事件：“我这次数据发完了”。

  • +CEPPI更像一个状态设定：“我现在进入了偏好节能的模式”。

在实际应用中，两者可以结合使用，或者根据模组厂商的推荐来选择。

3. 应对拥塞：“退避”的智慧 (+CABTSR & +CGAPNRC)

解决了功耗，小李直面那个导致“连接风暴”的棘手问题——网络拥塞。他需要让“天眼”学会在被网络“拒绝服务”后，能“知趣”地等待，而不是疯狂重试。APN Back-off机制就是网络的这种“熔断”保护。

3.1 +CABTSR：监听网络的“禁令” (APN Back-off Timer Status Reporting)

当网络因为拥塞或其他原因，暂时不想接受某个APN的连接请求时，它会在拒绝消息中携带一个“Back-off Timer”（退避定时器）。+CABTSR命令就是用来监控这个定时器状态的。

Description

Set command controls the presentation of unsolicited result code +CABTSRI: ,<event_type>[,<residual_backoff_time>…] reporting the APN back-off timer parameter values from MT to TE…

Table 10.1.41-1: +CABTSR parameter command syntax

+CABTSR=[<n>]

  • <n>=1: 开启Back-off事件的主动上报。

小李的“智能重试”逻辑：

  1. 开启监听： MCU在初始化时发送AT+CABTSR=1。

  2. 连接失败： MCU尝试AT+CGACT=1,1，但失败了，并且模组收到了网络下发的Back-off定时器。

  3. URC响起： 模组立即向MCU上报URC：

    +CABTSRI: "cmiot",0,3600

  4. MCU解读与决策：

    • "cmiot": 表明这个“禁令”是针对cmiot这个APN的。

    • 0 (<event_type>): 表示Back-off定时器已启动。

    • 3600: <residual_backoff_time>，表示剩余的禁止时间为3600秒（1小时）。

  5. “冷静”等待： MCU收到这个URC后，立即停止对cid=1的重试。它会在本地启动一个1小时的定时器。在这1小时内，任何尝试激活cid=1的操作都将被程序自身阻止。1小时后，才进行下一次重试。

通过+CABTSR，小李的设备从一个只会“鲁莽”重试的“愣头青”，变成了一个懂得遵守网络秩序、避免加剧拥塞的“好公民”。

3.2 +CGAPNRC：更精细的“限流” (APN Rate Control)

除了Back-off这种“一刀切”的禁止，网络还可能对APN进行更精细的“速率控制”。+CGAPNRC用于读取网络下发的这些控制参数。

This execution command returns the APN rate control parameters (see 3GPP TS 24.008) associated to the provided context identifier .

+CGAPNRC的响应中，会包含<Maximum_uplink_rate>和<Uplink_time_unit>等参数，它们共同定义了“在多长时间内，最多允许发送多少条上行信令消息”。这通常由网络侧配置，TE主要是读取和遵守。

4. 蜂窝与Wi-Fi的“华尔兹”：+CWLANOLAD 智能切换

最后，小李要为D客户实现Wi-Fi与蜂窝的智能切换功能。这正是3GPP定义的**WLAN Offloading（WLAN分流）**技术。

Description

Set command enables or disables the WLAN offload assistance data reporting. If reporting is enabled by =1, the MT returns the following unsolicited result code from MT to TE whenever the WLAN offload assistance data changes at the MT.

+CWLANOLAD (WLAN Offload Assistance Data) 命令允许TE向模组配置一系列复杂的切换判决门限。

Table 10.1.39-1: +CWLANOLAD parameter command syntax (极其复杂，此处仅展示核心思想)

+CWLANOLAD=[<n>[,<threshRSCPLow>...<WLANIdentifierListLength>...]]

工作原理——基于门限的智能推荐：

这个命令的核心思想不是由模组来“决定”切换，而是由模组根据TE设定的规则，在合适的时机向TE发出“建议切换”的通知。

小李的切换策略配置：

他希望：

  • 当蜂窝信号（如RSRP）低于某个值（如-110dBm），并且 周边Wi-Fi信号（如RSSI）高于某个值（如-65dBm）时，从蜂窝切换到Wi-Fi。

  • 反之，当Wi-Fi信号低于-80dBm，并且 蜂窝信号高于-100dBm时，从Wi-Fi切回蜂窝。

他通过AT+CWLANOLAD将这些门限值（threshRSRPLow, threshBeaconRSSIHigh等）配置给模组。

智能切换的完整流程：

  1. 配置门限： MCU发送AT+CWLANOLAD=1,...配置好各种信号门限，并开启上报。

  2. 模组持续监控： 模组在后台同时测量蜂窝和Wi-Fi的信号质量。

  3. 触发切换推荐（URC）： 当测量值穿越了小李设定的门限（例如，蜂窝信号变差，同时Wi-Fi信号变好），模组会向MCU上报一个URC，如 +CWLANOLADI: ...，其中包含了触发规则的测量值。

  4. TE（MCU）执行切换： MCU的URC处理程序收到这个“切换建议”后，由MCU自己来执行真正的切换动作：

    • 断开蜂窝数据连接（AT+CGACT=0,1）。

    • 启动Wi-Fi模块，连接到指定的SSID，获取IP地址。

    • 将上层应用的Socket重新绑定到Wi-Fi网络接口上，恢复与云平台的通信。

  5. 切回流程类似：当Wi-Fi信号变差，蜂窝信号变好，模组会上报另一个URC，MCU再执行切回蜂窝的逻辑。

关键点： +CWLANOLAD体系中，模组是“决策辅助系统”，TE才是“总指挥官”。模组提供精准的判决依据，而最终的切换执行权，掌握在应用开发者手中。

总结

在第十章的Part 5中，我们聚焦于数据连接建立后的高级管理与优化，这对于将一个物联网产品从“可用”提升到“优异”至关重要。

  • 通过**+CGDEL**，我们学会了对无用资源进行“断舍离”，保证了设备长期运行的整洁性。

  • 通过**+CNMPSD和+CEPPI**，我们掌握了与网络协同，主动进入低功耗状态的信令优化技巧。

  • 通过**+CABTSR和+CGAPNRC**，我们让设备学会了遵守网络秩序，在拥塞时智能“退避”，大大增强了在大规模部署场景下的稳定性。

  • 通过**+CWLANOLAD**，我们构建了蜂窝与Wi-Fi之间智能切换的桥梁，实现了成本与连接性的最佳平衡。

至此，小李的“天眼”追踪器已经具备了高度的智能和环境适应能力。它不再是一个简单的通信管道，而是一个懂得自我管理、懂得与网络和谐共处的智能终端。第十章的探索即将进入尾声，在最后的部分，我们将对本章进行全面的总结，并展望AT命令在5G演进中的未来。

FAQ：快速问答

Q1：AT+CGDEL和AT+CGACT=0都可以让一个上下文变为“非激活”，它们有什么区别？

A1：这是一个非常重要的区别：

  • AT+CGACT=0,<cid> (Deactivate): 只是“去激活”一个上下文，即断开数据连接，释放IP地址。但这个上下文的定义（+CGDCONT配置的信息）依然存在于模组中。你可以随时再次使用AT+CGACT=1,<cid>来重新激活它。

  • AT+CGDEL=<cid> (Delete): 是“删除”这个上下文。它不仅会断开连接（如果已激活，虽然规范说不能删除已激活的，但行为上会先使其非激活），更重要的是，它会彻底清除这个<cid>对应的所有配置信息（APN, PDP Type, QoS, TFT等）。删除后，你必须重新使用+CGDCONT等命令来定义它，才能再次使用。

Q2：我发送了AT+CNMPSD，但用功耗仪看，模组并没有立即进入Idle模式，为什么？

A2：+CNMPSD发送的“低功耗偏好”信令，对于网络（基站）来说，是一个**“建议”而非“命令”**。基站是否立即释放RRC连接，取决于它自身的资源调度算法、当前小区的负载情况以及运营商的策略配置。在网络繁忙时，基站可能会忽略这个建议。但总的来说，发送+CNMPSD会显著增加设备提前进入Idle模式的概率，是一种非常有效的功耗优化手段。

Q3：当收到APN Back-off定时器（+CABTSRI）后，我的设备真的就不能再尝试连接了吗？

A3：是的，你的应用程序必须遵守这个定时器。Back-off是网络的一种自我保护机制。如果你忽略定时器，继续疯狂重试，不仅会加剧网络拥塞，还可能被网络识别为“异常设备”，并可能受到更严厉的惩罚（如更长时间的禁止接入）。一个设计良好的物联网终端，必须包含处理Back-off逻辑的“退避与重试”模块。

Q4：在WLAN Offloading中，模组可以同时连接蜂窝和Wi-Fi吗？

A4：这取决于模组的硬件和软件能力。+CWLANOLAD本身定义的，是基于3GPP接入网发现和选择功能（ANDSF）的切换辅助机制。在大多数简单的物联网模组中，执行的是“断一连一”的切换（Break-before-make）。但更高级的设备和网络技术（如ATSSS - Access Traffic Steering, Switching and Splitting in 5G）则支持真正的多路并发传输，即同时使用蜂窝和Wi-Fi链路来传输数据。+CWLANOLAD是实现这些高级功能的基础。

Q5：+CEUS（UE’s Usage Setting）和+CEPPI（Power Preference Indication）有什么关联？

A5：它们都与功耗优化相关，但层面不同。

  • +CEUS: 设置UE的“使用场景”，0为”voice centric”，1为”data centric”。这个设置会影响UE在附着时向网络上报的一些能力和偏好，例如，“data centric”的UE可能会向网络表示它支持PSM，并倾向于使用数据优化相关的配置。它是一个宏观的、长期的行为设定。

  • +CEPPI: 是一个实时的、战术性的功耗偏好指示。它告诉网络“我现在希望进入省电模式”。

可以这样理解：+CEUS="data centric" 像是在你的个人档案里写上“我是一个注重节能的人”；而+CEPPI=1则是在你完成一天的工作后，对办公室的智能系统说：“我要下班了，请关灯关空调。”

关系图谱