51学通信

深度解析 3GPP TS 23.041：9.1节 告警消息的“最后一公里”投递

17分钟阅读

好的，我们继续对TS 23.041的深度拆解。

这是系列文章的第四篇，我们将把显微镜聚焦于规范中技术细节最密集、也是整个CBS/PWS广播流程的“最后一公里”——第九章：协议与协议架构 (Protocols and Protocol Architecture)。本篇将首先解读9.1节，详细剖析告警消息是如何在不同代际的核心网与无线接入网之间进行传递的。

深度解析 3GPP TS 23.041：9.1节 告警消息的“最后一公里”投递

本文技术原理深度参考了3GPP TS 23.041 V18.6.0 (2024-09) Release 18规范中，关于“9.1 Requirements on Core Network and Radio Access Network”的核心章节。本文旨在为读者详细拆解一条PWS（公共预警系统）告警消息，是如何穿越从CBC/CBCF到RAN（无线接入网）的层层协议栈，最终在基站侧被调度、并通过空口广播出去的。我们将以4G E-UTRAN的流程为核心，兼顾2G/3G/5G的演进，来揭示这场“生命信息投递”的技术细节。

引言：从“总调度”到“广播员”的指令下达

在上一篇中，我们了解了CBS/PWS“接力赛”中各个“选手”的职责。我们知道，“总调度”CBC/CBCF负责制定广播计划，“领队”MME/AMF负责承上启下，而最终的“广播员”eNB/gNB负责在空口将消息“喊”出去。

现在，我们要解决的是一个具体的技术问题：这条从CBE（信息源）发出的台风预警，在CBCF那里被打包成一个标准的WRITE-REPLACE-WARNING-REQUEST消息之后，它是如何穿过MME/AMF，最终到达成千上万个基站，并被准确无误地广播出去的？这个过程，就是告警消息投递的“最后一公里”。

第九章，正是这份“最后一公里”投递方案的详细施工图。它定义了所需的协议栈、信令流程、以及手机在收到告警后的具体行为。今天，我们将化身为“网络协议分析师”，以4G LTE网络中的PWS告警流程为范本，深入探索这条“生命线”的每一个技术环节。

1. 跨代际的投递流程概览 (9.1.1, 9.1.2, 9.1.3.4, 9.1.3.5)

9.1节首先按照网络代际，分别描述了告警消息的投递流程。虽然细节各异，但其核心思想——“CBC/CBCF → 控制节点 → 基站”——是一致的。

  • GSM (2G) (9.1.1): CBC通过SMS BROADCAST命令将88字节的CBS页面分块（4x22字节）或整体发送给BSC，BSC再调度给BTS在CBCH信道上广播。
  • UMTS (3G) (9.1.2): CBC通过SMS BROADCAST COMMAND将完整的CBS消息发送给RNC，RNC负责在CTCH逻辑信道上进行广播。NodeB在此过程中是透明的。
  • E-UTRAN (4G LTE) (9.1.3.4): 这是现代PWS系统的基础，我们将重点解析。
  • NG-RAN (5G NR) (9.1.3.5): 流程与4G高度相似，但承载于5G的全新接口和协议之上。

2. 4G E-UTRAN告警投递流程精解 (9.1.3.4.2)

这是PWS系统在当前存量网络中应用最广泛的流程。规范中的“Figure 9.1.3.4.2-1: Warning message delivery procedure in E-UTRAN”是理解这一流程的“圣经”。让我们跟随这张图，一步步追踪台风预警的旅程。

2.1 步骤0 & 1：信息源与鉴权

  1. Network registration and security … procedures are performed.
  2. CBE … sends emergency information … to the CBC. The CBC shall authenticate this request.
  • 流程解读:
    • 步骤0 (UE注册): 用户的手机（UE）正常注册在网络中。
    • 步骤1 (CBE→CBC): 应急管理部门（CBE），通过一个（3GPP未标准化的）接口，向运营商的**CBC（小区广播中心）**发送了Emergency Broadcast Request（紧急广播请求）。这个请求中包含了告警的核心要素：
      • "warning type": 告警类型，如“台风”。
      • "warning message": 告警内容文本。
      • "impacted area": 受影响的地理区域。
      • "time period": 广播的持续时间。
    • CBC的职责: CBC的第一项工作，是鉴权。它必须确认这个请求来自一个合法的、已授权的CBE，以防止任何人都能随意发布国家级警报。

2.2 步骤2 & 3 & 4：从CBC到MME的指令下达与确认

  1. …the CBC identifies which MMEs need to be contacted and determines the information to be place into the Warning Area List… The CBC sends a Write-Replace Warning Request message … to MMEs.
  2. The MME sends a Write-Replace Warning Confirm message that indicates to the CBC that the MME has started to distribute the warning message to eNodeBs.
  3. …the CBC may confirm to the CBE that it has started to distribute the warning message.
  • 流程解读:
    • 步骤2 (CBC→MME):
      • 目标MME选择: CBC根据CBE请求的“受影响区域”，查询自己的网络拓扑数据库，找出覆盖该区域的所有MME（移动性管理实体）。
      • 构造广播指令: CBC构造一条核心信令——Write-Replace Warning Request。这条信令通过标准的SBc接口发送给目标MME。其中包含了：
        • Message Identifier, Serial Number: 告警的“身份证”。
        • List of TAIs: 跟踪区ID列表。这是CBC告诉MME“请将此告警发往这些TA下的所有基站”的关键指令。
        • Warning Area List: 更精细的区域定义，可以是一个小区ID列表或紧急区域ID。这个列表是给基站看的。
        • Warning Message Content: 告警内容本身。
    • 步骤3 (MME→CBC): MME收到指令后，不会等基站广播完成再回复。它会立即回复一个Write-Replace Warning Confirm消息给CBC，表示：“老板，指令收到，我马上开始往下派发！”这种异步确认机制，保证了系统的高效性。
    • 步骤4 (CBC→CBE): CBC在收到了来自所有相关MME的确认后，可以向CBE回复一个最终的确认，表示“全网已开始投递”。

2.3 步骤5 & 6 & 7：从MME到UE的“最后一公里”

  1. The MME forwards Write-Replace Warning Message Request to eNodeBs.
  2. The eNodeB shall broadcast the warning message…
  3. If the UE has been configured to receive warning messages…, then the UE proceeds as follows…

这是告警消息从控制核心到用户手机的最终旅程。

  • 流程解读:
    • 步骤5 (MME→eNB): MME根据CBC给出的List of TAIs，将Write-Replace Warning Request消息封装在S1AP协议的WRITE-REPLACE WARNING REQUEST消息中，通过S1接口，下发给该TA下的所有eNB（基站）。
    • 步骤6 (eNB广播): eNB收到指令后，开始执行广播任务。
      • 区域判断: eNB会检查指令中的Warning Area List。如果列表为空，则在自己管辖的所有小区进行广播。如果列表非空，则只在列表指定的小区进行广播。
      • 无线调度: eNB负责在无线广播信道上，按照CBC指定的重复周期，频繁地调度和广播这条告警消息。
      • 寻呼（Paging）: 对于最高优先级的告警（如ETWS），eNB还会在寻呼信道上，周期性地发送一个特殊的“ETWS指示”。这个指示，就像是在全城拉响了“防空警报”，它的作用是唤醒那些处于DRX（非连续接收）深度睡眠状态的手机，告诉它们：“有紧急情况，快醒来接收广播！”
    • 步骤7 (UE接收与告警):
      • 空闲态UE: 处于空闲态的小雅的手机，在监听寻呼信道时，检测到了“ETWS指示”。
      • 立即告警: The UE can use "warning type" values, 'earthquake', 'tsunami' ... immediately to alert the user. 手机解析出告警类型后，无需等待接收完整的告警文本，就会立即触发最高优先级的用户告警（特殊的铃声和振动）。
      • 接收详细信息: 与此同时，手机会立即开始读取广播信道，接收完整的warning message内容，并将其显示在屏幕上。
    • 步骤7 (User Alerting): 这是用户最终的感知——手机发出刺耳的警报声，屏幕上弹出“超强台风预警，请立即撤离！”的弹窗。

2.4 步骤8 & 9：广播完成的上报与追溯

  1. If the Send Warning-Message-Indication parameter was present in the Write-Replace Warning Request …, the MME shall forward the Broadcast Scheduled Area Lists in a Write-Replace Warning Indication(s) to the CBC.
  2. From the Write-Replace Warning Response messages returned by eNodeB’s the MME determines the success or failure of the delivery and creates a trace record.
  • 流程解读: 这两个步骤是可选的，用于实现广播状态的闭环监控和追溯。
    • eNB→MME: eNB在完成一次或多次广播后，可以向MME上报WRITE-REPLACE WARNING RESPONSE，其中包含一个Broadcast Completed Area List，告知MME“我在这些小区成功广播了”。
    • MME→CBC (步骤8): 如果CBC在最初的请求中要求了上报（通过Send Write-Replace-Warning-Indication参数），MME会将从各个eNB收集到的“成功列表”，汇总后通过WRITE-REPLACE WARNING INDICATION消息上报给CBC。
    • MME记录 (步骤9): MME会根据eNB的响应，记录下本次广播的“轨迹（trace record）”，包括成功/失败的小区、广播次数等，以供后续的运维和审计。

3. 5G NG-RAN的演进 (9.1.3.5)

5G时代的PWS流程与4G高度相似，但承载于全新的服务化架构和接口之上。

  • CBCF → AMF: 使用**服务化接口（Namf_Communication_NonUeN2MessageTransfer）**来传递Write-Replace Warning Request NG-RAN消息。
  • AMF → NG-RAN (gNB/ng-eNB): 使用**N2接口（NGAP协议）**来传递WARNING REQUEST消息。
  • NG-RAN → UE: 通过5G的广播信道进行广播，同样支持通过寻呼信道发送紧急指示。

核心逻辑不变，但接口的现代化和标准化，使得5G PWS系统更加灵活、开放，并能够与网络切片、私网等5G新特性进行更好的结合。

FAQ环节

Q1：为什么CBC不直接把广播指令发给基站，而要经过MME/AMF这一层？ A1：MME/AMF在PWS流程中扮演了**“路由器”和“聚合/解聚合点”**的关键角色。

  • 解耦: CBC是核心网的集中节点，它不应该也无法直接管理成千上万个基站。MME/AMF作为无线接入的“锚点”，天然地知道自己管辖着哪些基站，以及这些基站属于哪个TAI。
  • 效率: CBC只需要向少数几个MME/AMF下发指令，并附上一个TAI列表。MME/AMF负责将这个“宏观指令”解聚合，并“分发”给TAI内的所有相关基站。这种两级分发架构，极大地降低了CBC的管理复杂度和信令负载。

Q2：eNB/gNB在收到广播请求后，是立即广播吗？ A2：不一定。eNB/gNB是广播任务的最终调度者。它会根据CBC下发的参数（如重复周期）和当前的无线信道状况，来调度广播消息的发送时机。对于高优先级的PWS告警，eNB会以尽可能高的优先级，在专用的广播信道上进行调度。它需要平衡告警的及时性与对其他正常通信业务的影响。

Q3：什么是ETWS的“主通知（Primary Notification）”和“次通知（Secondary Notification）”？ A3：这是ETWS系统为了追求极致的速度而设计的两级通知机制。

  • 主通知 (Primary Notification): 是一个非常短小（仅几十字节）、信息极其精炼的告警。它通常只包含最核心的告警类型（如“地震”）和受影响的大致区域。它的内容会被直接承载在寻呼（Paging）消息中，通过寻呼信道这个“VIP通道”以极高的频率广播出去。其目标是在地震波到达前的几秒钟内，就唤醒手机并触发初步警报。
  • 次通知 (Secondary Notification): 是一个完整的、包含详细文本信息的CBS消息。它通过常规的广播信道（CBCH/CTCH）发送。手机在被主通知唤醒后，会立即去读取这个信道，获取详细的灾害信息（如震级、震中、应对措施等）。 这种“寻呼唤醒+广播详情”的两步法，是ETWS实现秒级告警的关键。

Q4：如果一个区域被多个MME/AMF共同服务（MME/AMF Pool），CBC会怎么做？ A4：CBC会将同一个告警请求，发送给Pool内的所有MME/AMF。这意味着，一个基站（eNB/gNB）可能会从多个MME/AMF那里，收到内容完全相同的广播请求。规范对此有明确要求：

When S1-flex is used the eNodeB may receive same message from multiple MMEs. The eNodeB detects duplicate messages by checking the message identifier and serial number…

  • 基站必须具备重复消息检测能力。它会检查收到的告警的“身份证”（Message ID + Serial Number），如果发现是重复的，它只会执行第一个到达的请求，并对后续的重复请求，同样回复成功的响应（但不再重复广播），以保证信令流程的闭环。

Q5：手机是如何知道要去监听哪个广播信道的？ A5：这是通过系统消息（System Information Block, SIB）来告知的。基站会在一个更高层的广播信道（BCCH）上，周期性地广播系统信息。其中，特定类型的SIB（如SIB12 in E-UTRAN）会包含PWS相关的配置信息，它会告诉手机：“本小区支持PWS，相关的告警将在某某信道上广播，请在需要时去监听”。手机在空闲时，会先读取这些SIB，从而了解到PWS的“频道表”。

关系图谱