51学通信

深度解析 3GPP TS 38.413：9.2.8 Warning Message Transmission Messages (预警消息传输消息)

15分钟阅读

本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“9.2.8 Warning Message Transmission Messages”的核心章节，旨在为读者提供一份关于5G网络公共预警系统（PWS）信令“指令书”的详细解码指南，揭示网络是如何通过具体的信令消息结构来发布、更新和撤销紧急告警的。

深度解析 3GPP TS 38.413：9.2.8 Warning Message Transmission Messages (预警消息传输消息)

大家好，欢迎回到3GPP规范的深度解析之旅。在之前的文章中，我们已经对NGAP协议中的PDU会话管理、UE上下文管理以及移动性管理等核心消息进行了详细的剖析。今天，我们将聚焦于一组特殊但至关重要的消息——预警消息传输消息（Warning Message Transmission Messages）。

这些消息是5G网络承载**公共预警系统（Public Warning System, PWS）**功能的信令基础。当自然灾害、恐怖袭击或任何重大公共安全事件发生时，政府授权的机构可以通过PWS，利用移动通信网络，向特定区域内的所有手机大规模、高优先级地推送告警信息。我们手机上收到的地震预警、台风警报，背后正是这套机制在运作。

Warning Message Transmission Messages定义了核心网的AMF与接入网的gNB之间，为了广播这些“生命攸关”的信息而进行的信令交互。它们构成了PWS任务从下达到执行、再到撤销的完整闭环。

为了生动地理解这份“紧急动员令”的每一个细节，我们将引入一位身处应急指挥中心的主角——总指挥官Alex。一场突如其来的强烈地震袭击了城市，Alex需要立即通过5G网络，向震区及周边居民发布紧急避险通知。

  • 事件: 城市发生强烈地震，需要立即发布预警。
  • 网络节点: 应急指挥中心的AMF-Emergency，以及覆盖震区的gNB-ZoneA。

我们将跟随Alex的指挥，剖析本章定义的五种核心消息，看看这份“动员令”是如何被下达、确认、取消和管理的：

  • WRITE-REPLACE WARNING REQUEST: Alex如何下达“一级警报”的广播指令。
  • WRITE-REPLACE WARNING RESPONSE: gNB-ZoneA如何回复“指令收到，已开始广播”。
  • PWS CANCEL REQUEST: 在余震风险解除后，如何下达“解除警报”的指令。
  • PWS CANCEL RESPONSE: gNB-ZoneA如何确认警报已停止。
  • PWS RESTART INDICATION / PWS FAILURE INDICATION: 基站在故障后如何与指挥中心恢复同步，或上报广播能力故障。

1. 紧急动员令：WRITE-REPLACE WARNING REQUEST (写入-替换预警请求)

这是PWS流程的核心发起消息，由AMF向gNB下达“开始广播”或“更新广播内容”的指令。

9.2.8.1 WRITE-REPLACE WARNING REQUEST This message is sent by the AMF to request the start or overwrite of the broadcast of a warning message.

场景引入： 地震发生后，应急指挥中心（通过CBC - Cell Broadcast Centre）立即生成了预警信息，并将其发送给AMF-Emergency。AMF需要立即命令震区内的gNB-ZoneA开始广播。

AMF-Emergency向gNB-ZoneA发送WRITE-REPLACE WARNING REQUEST消息。

表格 9.2.8.1-1: WRITE-REPLACE WARNING REQUEST 消息内容

IE/Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned Criticality
Message TypeM9.3.1.1YESreject
Message IdentifierM9.3.1.35YESreject
Serial NumberM9.3.1.36YESreject
Warning Area ListO9.3.1.37YESignore
Repetition PeriodM9.3.1.49YESreject
Number of Broadcasts RequestedM9.3.1.38YESreject
Warning TypeO9.3.1.39YESignore
Warning Message ContentsO9.3.1.42YESignore
Concurrent Warning Message IndicatorO9.3.1.46YESreject
Warning Area CoordinatesO9.3.1.112YESignore

核心IE深度解码：

  • Message Identifier: 消息标识符。它唯一地标识了预警的类型和来源。例如，它可以指明这是来自国家地震局的最高级别警报。
  • Serial Number: 序列号。它与Message Identifier一起，构成了某条预警消息在某一时刻的唯一版本号。当预警内容需要更新时（例如，发布余震预警），Message Identifier保持不变，而Serial Number会递增。gNB通过对比这两个ID，就能知道是启动新广播还是替换旧广播。
  • Warning Area List: 预警区域列表。AMF通过这个IE精确定义了广播的地理范围。可以是小区列表（Cell ID List）、跟踪区列表（TAI List）或紧急区域ID列表（Emergency Area ID List）。
  • Repetition Period 和 Number of Broadcasts Requested: 重复周期和请求广播次数。这两个参数共同决定了预警的广播策略。例如，Repetition Period=2秒，Number of Broadcasts=30，意味着gNB会在接下来的一分钟内，每2秒重复广播一次这条紧急消息，确保区域内尽可能多的设备能收到。
  • Warning Message Contents: 预警消息内容。这就是用户最终在手机屏幕上看到的文本信息，例如：“地震预警：XX地区发生强震，请立即就近避险！”
  • Concurrent Warning Message Indicator: 并发预警指示。如果存在，表示gNB可以同时广播多条不同的预警消息。如果不存在，当gNB收到一条新的预警请求时，它必须停止正在广播的旧预警，转而广播新预警。

2. 执行回执：WRITE-REPLACE WARNING RESPONSE (写入-替换预警响应)

gNB在收到并成功处理了REQUEST消息后，需要向AMF回复一个“执行回执”。

9.2.8.2 WRITE-REPLACE WARNING RESPONSE This message is sent by the NG-RAN node to acknowledge the AMF on the start or overwrite request of a warning message.

场景演绎： gNB-ZoneA收到了Alex下达的地震预警广播请求。它立即将该任务置于最高优先级，分配了小区广播信道（Cell Broadcast Channel）资源，并开始按照请求的重复策略进行广播。

完成任务调度后，gNB-ZoneA向AMF-Emergency回复WRITE-REPLACE WARNING RESPONSE消息。

表格 9.2.8.2-1: WRITE-REPLACE WARNING RESPONSE 消息内容

IE/Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned Criticality
Message TypeM9.3.1.1YESreject
Message IdentifierM9.3.1.35YESreject
Serial NumberM9.3.1.36YESreject
Broadcast Completed Area ListO9.3.1.43YESignore
Criticality DiagnosticsO9.3.1.3YESignore

核心IE深度解码：

  • Message Identifier / Serial Number: gNB会原封不动地将请求中的这两个ID返回，以便AMF将响应与之前的请求对应起来。
  • Broadcast Completed Area List: 这是响应中最关键的信息。gNB会在这里列出成功启动了预警广播的区域。如果AMF请求在10个小区广播，而gNB只成功地在其中的8个小区启动了广播（另外2个可能因故障或资源问题失败），那么这个列表就只会包含这8个小区。AMF收到后，就知道预警在哪些区域已经生效，在哪些区域失败，从而可以做出后续决策（如记录告警、尝试在其他gNB上广播等）。

3. 解除警报：PWS CANCEL REQUEST / RESPONSE (PWS取消请求/响应)

当紧急情况解除，需要停止广播时，AMF会发起PWS CANCEL流程。

9.2.8.3 PWS CANCEL REQUEST This message is forwarded by the AMF to the NG-RAN node to cancel an already ongoing broadcast of a warning message.

场景演绎： 余震风险已过，Alex需要解除地震预警。AMF向gNB-ZoneA发送PWS CANCEL REQUEST。

REQUEST消息的核心IE：

  • Message Identifier / Serial Number: 再次使用这两个ID来精确指定要取消的是哪一条预警。
  • Warning Area List: 指定在哪些区域取消广播。
  • Cancel-All Warning Messages Indicator: 这是一个“王炸”选项。如果这个IE存在，gNB会忽略其他ID，立即停止并删除所有正在广播的预警消息。

gNB-ZoneA收到后，立即停止广播，并回复PWS CANCEL RESPONSE，在Broadcast Cancelled Area List中报告成功取消广播的区域。

4. 故障与恢复：PWS RESTART / FAILURE INDICATION (PWS重启/故障指示)

这两个流程由gNB发起，用于向AMF报告其PWS功能的状态。

  • PWS RESTART INDICATION (9.2.8.5):

    • 目的: gNB在重启后，其内存中正在进行的PWS任务会丢失。它通过此消息告知AMF：“我刚刚重启了，请把需要我广播的预警任务再发我一遍。”
    • 场景: gNB-ZoneA因故重启。上线后，它向AMF发送PWS RESTART INDICATION。AMF检查后发现地震预警仍在有效期，于是重新向gNB-ZoneA发送WRITE-REPLACE WARNING REQUEST，使其恢复广播。

  • PWS FAILURE INDICATION (9.2.8.6):

    • 目的: 当gNB的某些小区因为硬件故障等原因，持续无法进行PWS广播时，通过此消息向AMF报告。
    • 场景: gNB-ZoneA的某个小区的广播信道模块损坏。它向AMF发送PWS FAILURE INDICATION，并在PWS Failed Cell List中指明故障的小区。AMF收到后，会记录告警并通知网管系统，告知应急指挥中心的Alex，预警系统出现了覆盖盲区。

FAQ

Q1: 为什么WRITE-REPLACE WARNING REQUEST消息中的Message Identifier和Serial Number都是强制的（Mandatory）？

A1: 这两个IE共同构成了预警消息的唯一版本标识，是整个PWS流程能够正确运行的基础，因此必须存在。

  • Message Identifier 区分了不同的预警“事件”。例如，地震预警和台风预警会有不同的Message Identifier。
  • Serial Number 区分了同一事件的不同版本。这使得“替换”（Overwrite）功能成为可能。如果没有序列号，当gNB收到一个Message Identifier相同的请求时，它无法判断这究竟是一次重复的指令，还是一个包含了更新信息的指令。有了序列号，gNB只需比较新消息的序列号是否大于当前正在广播的消息的序列号，就能做出正确的替换决策。

Q2: 如果AMF请求在一个包含100个小区的TA中广播预警，但其中一个小区广播失败了，gNB会在WRITE-REPLACE WARNING RESPONSE中如何报告？

A2: gNB会在Broadcast Completed Area List IE中，明确地列出那99个成功启动了广播的小区。AMF通过对比请求的区域列表和响应的成功列表，就能知道哪个小区失败了。这种精细化的反馈机制，使得核心网能够准确掌握预警的实际覆盖情况。AMF可能会将这个失败信息上报给网管，或者，如果可能的话，尝试通过另一个相邻的gNB来覆盖这个“盲区”。

Q3: PWS CANCEL REQUEST和WRITE-REPLACE WARNING REQUEST都可以停止一个旧的广播，它们有什么区别？

A3: 它们的目的和效果完全不同。

  • PWS CANCEL REQUEST的目的是终止一个预警广播。执行后，该预警将不再被广播。
  • WRITE-REPLACE WARNING REQUEST（当用于替换时）的目的是更新一个预警广播。执行后，旧的广播会停止，但一个新的、内容更新的广播会立即开始。它是一个“先停后启”的原子操作，确保了预警信息的连续性。

Q4: gNB在收到WRITE-REPLACE WARNING REQUEST后，是立即开始广播吗？

A4: 不完全是。gNB收到请求后，会立即开始调度广播。实际的第一次广播时间，取决于小区广播的调度周期（由SIB（System Information Block）定义）。gNB会将预警消息安排在下一个可用的广播时机进行发送。Repetition Period参数定义的是后续重复广播的间隔。所以，从AMF下发指令到用户手机上第一次出现预警，会有一个短暂的调度延迟。

Q5: 为什么PWS相关的流程都是非UE关联的（non-UE associated）？

A5: 因为PWS的本质是广播，它的目标是特定地理区域内的所有设备，而不是某一个特定的UE。如果采用UE关联的信令，网络就需要为区域内的成千上万个UE逐一建立连接、下发消息，这在紧急情况下会立即导致信令风暴和网络瘫痪。非UE关联的流程，意味着AMF与gNB之间的信令交互是“对小区/区域”的指令，gNB再通过公共的广播信道将信息传递给所有UE，这是实现大规模、高效率信息分发的唯一可行方式。

关系图谱