深度解析 3GPP TS 27.007：10 Commands for packet domain (Part 2 - QoS与TFT：打造智能数据高速公路)

本文技术原理深度参考了3GPP TS 27.007 V19.4.0 (2025-09) Release 19 规范中，关于“10 Commands for packet domain”的核心章节。在Part 1中，我们掌握了“上网三部曲”，成功建立了数据连接。本文为Part 2，我们将进入一个更高级、更精细化的领域：如何为不同的数据业务申请不同的服务质量（QoS），并像智能交通指挥官一样，使用业务流模板（TFT）将数据包精确地引导到各自的专属“快车道”上。

写在前面：小李的烦恼——当“警报”被堵在“常规数据”之后

在Part 1的探索后，工程师小李的“天眼”追踪器原型已经能够稳定地连接到5G云平台。它每隔一小时，就会将自己的GPS位置、电池电量和环境温度打包上报。一切看起来都很完美。

然而，在一次压力测试中，小李发现了一个致命的问题。他模拟了一个紧急情况：设备检测到剧烈碰撞，需要立即上报一条高优先级的“碰撞告警”数据包。不幸的是，这次告警恰好发生在一个例行的、包含大量历史数据的日志文件上传过程中。结果，这条性命攸关的告警信息，被堵在了庞大的日志数据流后面，延迟了整整30秒才被云平台收到。

“这绝对不能接受！”小李心头一紧。对于一个物流追踪器，30秒的延迟可能意味着错过了最佳的货物追回时机；而如果这是一个车载紧急呼叫系统，30秒的延迟更是无法想象的。

他意识到，之前建立的数据连接，就像一条单车道公路。无论上来的是“救护车”（告警数据）还是“集装箱卡车”（日志文件），都只能排队依次通行。他需要的，是一条智能高速公路：有专门的应急车道、快车道和慢车道，并且有一个智能的“交通警察”，能识别不同车辆的类型，并引导它们进入正确的车道。

这个“智能高速公路”的建设方案，就详细规定在第十章的后续部分，其核心技术就是QoS（Quality of Service，服务质量）和TFT（Traffic Flow Template，业务流模板）。本章，我们将和小李一起，学习如何使用+CGEQREQ、+CGDSCONT和+CGTFT等高级AT命令，为“天眼”项目构建一个高效、可靠、差异化服务的数据传输体系。

---

1. QoS进化论：从“尽力而为”到“按需服务”

在AT命令的世界里，QoS的演进深刻地反映了移动通信网络从单纯的“提供连接”到“提供差异化服务”的转变。

1.1 2G/3G (R97/98) QoS：粗放的参数化时代

早期的GPRS网络提供了最基础的QoS概念，通过几个参数来描述数据连接的“好坏”。+CGQREQ (Requested QoS) 和 +CGQMIN (Minimum Acceptable QoS) 就是这个时代的产物。它们定义了：

• Precedence Class: 优先等级

• Delay Class: 延迟等级

• Reliability Class: 可靠性等级

• Peak Throughput Class: 峰值速率

• Mean Throughput Class: 平均速率

这就像是你在寄快递时，只能勾选“普通”、“加急”、“特急”几个粗略的选项。

1.2 UMTS (R99+) QoS：面向业务的分类时代

随着3G的到来，QoS模型变得更加智能。+CGEQREQ (3G Requested QoS) 命令引入了**Traffic Class（业务类型）**这个核心概念。

<Traffic class>: integer type; indicates the type of application for which the UMTS bearer service is optimised (refer 3GPP TS 24.008 clause 10.5.6.5).

0 conversational

1 streaming

2 interactive

3 background

网络不再仅仅看你勾选的“加急”选项，而是会问你：“你寄送的到底是什么东西？”

• Conversational (会话类): 如VoIP。对时延最敏感。

• Streaming (流媒体类): 如视频流。对时延抖动敏感。

• Interactive (交互类): 如网页浏览、信令。要求低误码率、保持时序。

• Background (背景类): 如文件下载、邮件。对时延最不敏感。

这四种分类，让网络可以根据业务的内在属性，来智能地分配和调度资源。

1.3 4G/EPS & 5G/5GS QoS：QCI/5QI的标识符时代

到了4G和5G，QoS模型被进一步抽象和标准化。网络不再直接处理上述一大堆参数，而是使用一个单一的数字标识符——QCI (QoS Class Identifier) in 4G, or 5QI (5G QoS Identifier) in 5G，来代表一整套的QoS特性（优先级、时延预算、误码率等）。

例如，5QI=1可能代表GBR（有保证速率）的会话类语音业务，而5QI=9可能代表Best-Effort的互联网访问。

AT命令的角色： 幸运的是，开发者通常不需要直接操作复杂的QCI/5QI。+CGEQOS/+C5GQOS等AT命令提供了一个抽象层。我们仍然通过设置Traffic class、bitrate等相对简单的参数，然后模组的固件会负责将这些参数映射成底层网络（4G或5G）能够理解的QCI/5QI和相关的QoS参数。

小李的收获： 他明白了，虽然AT命令的“长相”变化不大，但其背后驱动的底层网络QoS机制，已经发生了翻天覆地的变化。他现在要做的，就是学会使用这些AT命令，向模组准确地表达他的业务需求。

---

2. QoS配置实战：为“告警”和“日志”申请不同车道

小李的目标很明确：为“碰撞告警”申请一条低时延、高可靠的交互式（Interactive）快车道；为“常规日志”使用普通的背景类（Background）慢车道。

2.1 +CGEQREQ：提交你的QoS“申请表” (3G Requested QoS)

+CGEQREQ是UMTS时代引入的命令，但由于其定义的参数非常全面，至今仍在4G/5G模组中广泛用于定义QoS profile。

Description

This command allows the TE to specify a UMTS Quality of Service Profile that is used when the MT activates a PDP context.

Table 116: +CGEQREQ parameter command syntax (核心参数简化)

+CGEQREQ=<cid>[,<Traffic class>[,<Maximum bitrate UL>...<Signalling indication>]]

小李的“车道”规划：

他规划了两个PDP Context（或者说，两个未来的承载/QoS流）：

• cid=1: 用于常规业务（日志、心跳），使用默认QoS。

• cid=2: 专门用于紧急告警，需要申请专用的高优先级QoS。

为告警通道（cid=2）配置QoS：

小李需要一个交互式的、保证有64kbps带宽的通道。

1. 发送命令：

   AT+CGEQREQ=2,2,,,,,64,64,,,,,,

2. 解读：

   • 2: 目标是cid=2。

   • 2: Traffic Class设置为2 (Interactive)。

   • 后面的逗号跳过了最大速率等参数，直接设置了<Guaranteed bitrate UL>和<Guaranteed bitrate DL>为64 (kbps)。

为常规通道（cid=1）配置QoS：

对于常规日志，他只需要使用背景类业务，不需要保证速率。

1. 发送命令： AT+CGEQREQ=1,3

2. 解读：

   • 1: 目标是cid=1。

   • 3: Traffic Class设置为3 (Background)。

   • 其他参数省略，使用网络默认值。

+CGEQMIN (Minimum Acceptable QoS): 与+CGEQREQ配对使用，用于告知网络“我最低能接受什么样的QoS”。如果网络连最低要求都无法满足，上下文激活就会失败。

通过这两条命令，小李已经成功地为他的两条“车道”画好了蓝图。但此时，问题来了：当MCU发送一个数据包时，模组怎么知道这个包应该走“告警快车道”还是“日志慢车道”呢？

---

3. 智能交通指挥官：+CGDSCONT 与 +CGTFT

答案就是TFT（Traffic Flow Template）。TFT就像是一组分流规则，它检查每个上行数据包的“五元组”（源/目的IP、源/目的端口、协议号），然后决定这个包应该被映射到哪个承载/QoS流上。

要使用TFT，通常需要先定义一个次要PDP上下文（Secondary PDP Context）。

3.1 +CGDSCONT：申请一条“空车道” (Define Secondary PDP Context)

默认承载（Primary Context）是设备上网的基础。而我们为告警申请的专用QoS通道，就需要通过一个次要PDP上下文来实现，它在4G/5G中就对应着一个专用承载或专用的QoS Flow。

Description

The set command specifies PDP context parameter values for a Secondary PDP context identified by the (local) context identification parameter, .

Table 112: +CGDSCONT parameter command syntax

+CGDSCONT=<cid>,<p_cid>

• <cid>: 要定义的次要上下文的ID。

• <p_cid>: 该次要上下文所关联的主上下文的ID。

小李的实践：

他之前定义的cid=1将作为主上下文。现在，他需要将cid=2定义为一个与cid=1关联的次要上下文。

1. 发送命令： AT+CGDSCONT=2,1

2. 模组响应： OK

3. 解读： 他成功地声明了cid=2是一条特殊的、需要专用QoS的“车道”，并且这条车道是附属于cid=1这条“高速公路”的。

3.2 +CGTFT：制定详细的“交通规则” (Traffic Flow Template)

定义好“空车道”后，就需要+CGTFT这个“交通指挥官”来制定规则了。

Description

This command allows the TE to specify a Packet Filter - PF for a Traffic Flow Template - TFT that is used in the GGSN and in the Packet GW for routing of packets onto different QoS flows towards the TE.

Table 113: +CGTFT parameter command syntax (核心参数简化)

+CGTFT=<cid>[,<packet filter identifier>,<eval-prec>[,<remote addr>[,<protocol>[,<local port>[,<remote port>...]]]]]

关键参数详解：

• <cid>: 要为哪个上下文设置规则。

• <packet filter identifier>: 这条规则的编号。

• <eval-prec>: 评估优先级。数字越小，优先级越高。

• <remote addr>: 目的IP地址/掩码。

• <protocol>: 协议号（如TCP=6, UDP=17）。

• <remote port range>: 目的端口范围。

小李的“智能分流”策略：

他和云端开发同事约定：

• 紧急告警数据，使用UDP协议，发送到服务器114.114.114.114的5001端口。

• 所有其他常规数据，使用TCP协议，发送到服务器的8080端口。

现在，他要为告警通道 cid=2 编写TFT规则：

1. 发送命令：

   AT+CGTFT=2,1,10,"114.114.114.114/255.255.255.255",17,,"5001-5001"

2. 解读：

   • 2: 为cid=2设置规则。

   • 1: 规则编号为1。

   • 10: 优先级为10。

   • "114.114.114.114/255.255.255.255": 精确匹配目的IP。

   • 17: 协议为UDP。

   • ,,: 省略本地端口范围。

   • "5001-5001": 精确匹配目的端口5001。

最终效果：

现在，当小李的MCU：

• 发送告警包（目的IP: 114.114.114.114, 目的端口: 5001），模组的TFT引擎会匹配到这条规则，并将该数据包路由到cid=2所关联的高优先级专用承载上，确保其低时延、高可靠地传输。

• 发送日志包（目的IP: 114.114.114.114, 目的端口: 8080），TFT匹配失败。根据规则，所有不匹配任何TFT的数据包，都会被路由到默认承载（即cid=1）上，以“尽力而为”的方式传输。

小李成功了！他为“天眼”项目构建起了一条真正的“智能数据高速公路”。

---

4. “事后诸葛亮”：读取网络实际分配的QoS

你申请了VIP车道，但最终批下来的是不是VIP？网络有最终决定权。因此，在上下文激活后，读取网络实际协商和分配的QoS参数，是必不可少的验证环节。

• +CGEQNEG (Negotiated QoS): 读取3G QoS协商结果。

• +CGEQOSRDP (EPS QoS Read Dynamic Parameters): 读取4G EPS QoS协商结果。

• +C5GQOSRDP (5GS QoS Read Dynamic Parameters): 读取5G QoS协商结果。

小李的验证：

在AT+CGACT=1,2成功后，他发送AT+C5GQOSRDP=2。模组可能返回+C5GQOSRDP: 2,82,...，其中82是一个代表低时延GBR业务的5QI值。这表明他的QoS申请被网络接受了。如果返回的是一个代表非GBR的5QI（如9），则说明申请被降级了。

---

总结

在本篇文章中，我们和小李一起，从“能上网”迈向了“上好网”的全新境界。我们不仅理解了QoS在移动通信中演进的脉络，更核心的是，我们掌握了利用AT命令实现差异化服务的“组合拳”：

1. 定义服务蓝图 (+CGEQREQ/+CGQREQ)：为不同的业务需求（如告警 vs 日志）定义具有不同QoS特性的“车道”规格。

2. 申请专用通道 (+CGDSCONT)：为主数据公路申请一条空的“专用车道”。

3. 制定交通规则 (+CGTFT)：设置精细的包过滤器，像一个智能交警，将符合特定规则的数据包（如发往特定端口的告警数据）引导到专用车道上。

4. 验证最终结果 (+C...QOSRDP/+CGEQNEG)：检查网络最终批准建设的“车道”规格是否符合预期。

通过这套组合拳，小李的“天眼”追踪器彻底解决了关键数据被拥塞的问题，其可靠性和专业性得到了质的飞跃。然而，第十章的宝藏远未挖尽。在Part 3中，我们将继续探索更多高级主题，如网络发起上下文、APN速率控制、数据开关状态等，让“天眼”的“智慧大脑”变得更加完善。

---

FAQ：快速问答

Q1：是不是所有物联网应用都需要配置TFT和专用承载？

A1：不是。对于大多数对QoS不敏感的应用，如定时上报数据的智能水表、共享单车等，只使用一个默认承载（Primary Context）就足够了，所有数据都以“尽力而为”的方式传输。只有当你的应用中存在多种业务，且其中一种或多种对时延、带宽、可靠性有明确要求时（如紧急告警、远程控制指令、VoIP等），才需要使用TFT和专用承载（Secondary Context）来保证关键业务的服务质量。

Q2：+CGQREQ、+CGEQREQ、+CGEQOS 和 +C5GQOS 之间有什么关系？我该用哪个？

A2：它们都是用于定义QoS的命令，但属于不同时代和制式：

• +CGQREQ: GPRS R97/98的老命令，参数较粗。

• +CGEQREQ: UMTS (3G) R99引入的命令，引入了Traffic Class，参数更全面。

• +CGEQOS: EPS (4G) 的命令，核心参数是QCI。

• +C5GQOS: 5GS (5G) 的命令，核心参数是5QI。

建议： 查阅你所用模组的AT手册。现代模组通常会推荐使用其中一个作为统一的QoS配置入口（通常是+CGEQOS或+C5GQOS），模组固件会负责将其参数映射到当前网络（4G或5G）的底层QoS机制上。

Q3：我能为一个主PDP上下文（Primary PDP Context）设置TFT吗？

A3：不能。TFT的核心作用是“分流”，即将特定的数据流从默认路径（主上下文/默认承载）中分离出来，引导到一个具有特定QoS的专用路径（次要上下文/专用承载）上。主上下文本身就是那个“默认的、无条件”的路径，它不需要、也不应该有TFT。TFT是定义“非默认”路径的规则。

Q4：我成功激活了主上下文（cid=1），但激活次要上下文（cid=2）时失败了，可能是什么原因？

A4：激活次要上下文失败的常见原因有：

1. 网络不支持/不批准QoS：你通过+CGEQREQ申请的QoS参数组合（如特定的GBR速率）超出了网络的能力或签约套餐的限制。

2. APN限制：你所用的APN可能不支持建立多个承载，或者已经达到了该APN允许的最大承载数。

3. 模组能力限制：模组本身支持的并发承载数量有限。

4. TFT配置错误：你为次要上下文配置的TFT规则有语法或逻辑错误，被网络拒绝。

遇到此问题时，应使用AT+CMEE=2查看详细的错误原因码。

Q5：TFT规则中的<eval-prec>（评估优先级）有什么用？

A5：当一个PDP地址关联了多个TFT时（例如，你有多个次要上下文），evaluation precedence决定了检查数据包的顺序。模组会从优先级数值最小的规则开始匹配。一旦一个数据包成功匹配了某条规则，它就会被路由到对应的承载，后续的规则将不再被检查。因此，你应该为更具体、更重要的规则设置更小的优先级数值，将更通用的规则放在后面。这与防火墙规则的匹配逻辑非常相似。