3GPP规范中should、shall、can、may的使用场景与区别？

Question

在3GPP规范文档中，"shall"、"should"、"can"和"may"是常用模态动词，用于表达不同的强制性级别与建议程度。实际应用中，开发者和技术人员常对其具体含义和使用场景存在混淆。 例如： - **“Shall”** 表示**强制性要求**，必须实现，否则可能影响协议一致性； - **“Should”** 表示**推荐行为**，强烈建议遵循，但非强制； - **“Can”** 表示**能力或可能性**，描述系统具备的某项功能； - **“May”** 则表示**可选行为**，允许根据情况决定是否执行。 理解这些词汇的准确语义，对于正确解读3GPP规范、确保协议一致性与互操作性至关重要。在开发5G NR、IMS或LTE相关系统时，如何依据这些关键词做出合规设计，是工程师面临的重要技术问题。

Answer 1

3GPP规范中“shall”、“should”、“can”与“may”的语义解析与应用实践

在3GPP标准文档中，模态动词的使用具有严格的语义定义，直接影响协议实现的一致性与互操作性。开发者和技术人员若对其理解不清，可能导致实现偏差，影响系统兼容性。

1. 模态动词的基本语义区分

• Shall：强制性要求，必须实现。用于描述不可更改的技术约束。
• Should：推荐行为，强烈建议遵循，但不强制。通常用于优化或增强功能。
• Can：表示能力或可能性，说明某项功能存在或可行。
• May：可选行为，允许根据具体情况决定是否执行。

关键词	语义	是否强制	典型应用场景
Shall	必须执行	是	协议一致性、关键流程
Should	建议执行	否	性能优化、推荐配置
Can	具备能力	否	功能支持声明
May	可选行为	否	灵活实现选项

2. 在5G NR/IMS/LTE系统设计中的实际应用

以下是一些典型场景中这些词汇的应用方式：

// 示例：5G NR RRC连接建立过程
if (ueSupportsFeatureX) {
    // Feature X can be used if supported
    enableFeatureX();
}

// Handover decision should consider signal quality
if (signalQuality > threshold) {
    triggerHandover();
}

// UE shall respond to paging message within T3413 timer
startPagingResponseTimer(T3413);

3. 工程实践中常见问题与分析流程

1. 开发人员误将“should”当作非必要项忽略，导致性能下降；
2. 错误地将“can”理解为“shall”，造成不必要的资源消耗；
3. 忽视“may”条件下的分支逻辑，引发兼容性问题。

graph TD A[读取3GPP规范] --> B{识别模态动词} B --> C[Shall: 强制实现] B --> D[Should: 推荐实现] B --> E[Can: 表示能力] B --> F[May: 可选实现] C --> G[确保协议一致性] D --> H[提升系统性能] E --> I[声明功能支持] F --> J[处理多厂商兼容]