公共预警技术——PWS

       随着突发公共事件对人类和社会的影响越来越大以及信息技术的进步，各国政府对突发时间的应急处理由传统的事后响应逐渐向事前预防的方向发展，以便在灾害发生前，提前做好准备，尽可能减少灾害所带来的财产和生命损失。

       近年来公共预警技术越来越受到研究机构、标准化组织和各国政府的重视，3GPP已经就公共预警系统(Public Warning System,PWS)开展研究，分析灾害发生时对公共预警有哪些需求，并就地震和海啸预警系统(Earthquake and Tsunami Warning System,ETWS)开展研究，另外美国也在研究商用手机预警系统(Commercial Mobile Alert System,CMAS),亚太电信标准化计划正在开展早期预警与减灾无线电通信系统(Radio communication Systems for Early Warning and Disaster Relief Operations)的研究，这些都表明公共预警技术已成为应急通信领域新的技术趋势，这些事前的监测和预警手段的使用，从时间维度上为现有应急通信事后处理提供很好的辅助和补充，标志着科能融合应急通信步入一个新的时代。

       公共预警是通过网络(如公众移动通信网)向处于危险区域的公众提供安全可靠、灵活可信的告警通知，通过建立公共预警系统，提供公共预警业务。

       典型的公共预警系统有日本主导研究的地震和海啸预警系统及美国主导研究的商用手机预警系统。

       3GPP作为成功推出全球移动通信标准的标准化组织，近年来开始对如何利用公众移动通信网提供公共预警业务开展系统研究，并从公众用户和业务提供者的角度，对公共预警系统提出了需求，包括公共预警业务的基本需求、终端需求以及安全、漫游、管制等相关需求，为公共预警系统的开发、部署提供基础和依据。

1.PWS基本需求

       当灾难（如地震、海啸、飓风和火灾等）发生时，PWS应能及时、准确地向公众颁布告警通知，公众用户收到告警通知后，可以釆取恰当的措施保护家庭和自己免受严重伤害，避免生命和财产损失。PWS需要提供一种向公众颁布告警通知的机制，提高告警通知的可靠性、安全性。

       公共预警涉及告警通知提供者、网络运营商和终端用户3个角色。告警通知提供者通常为如政府机构或公共服务组织，是告警通知的合法提供者。网络运营商是公众移动通信网的运营者，接收来自告警通知提供者的告警信息，并向终端用户广播告警通知。终端用户即是接收告警信息的公众用户。

       PWS应能向公众用户广播告警通知，并满足如下需求：

       1）PWS应能在不需用户确认的情况下同时向多用户广播告警通知。

       2）PWS必须按照管制要求中规定的语言广播告警通知。

       3）按照管制要求，PWS依照先接收先广播的原则处理告警通知。

       4）用户接收和呈现PWS发送的告警通知时，不需事先主动与PWS建立语音或数据会话。

       5）告警通知应只在紧急情况时（如生命或财产处在危险时刻等）广播，告警通知也可用于运营商网络的商业服务。

       对PWS向公众用户广播的告警通知的内容，有如下需求：

       1）PWS不应修改或转译告警通知提供者广播的告警通知内容。

       2）告警通知内容可能包括事件描述、影响区域、建议采取的措施、到期时间（包含时区）、告警通知发送机构5个要素，并能根据管制要求在告警通知中增加其他要素。

       3）当网络流量已经急剧增加时（如用户呼叫匪警/火警），告警通知中携带的URL或电话号码可能加重无线网络的拥塞。因此，告警通知不宜携带任何直接增加网络流量负荷的信息（如URL或电话号码）。

       对于告警通知的范围，PWS应能基于告警通知提供者提供的地理信息，应尽可能根据网络区域覆盖的配置情况（如小区、NodeB.RNC分布等）进一步确定告警通知广播的区域。另外，系统应可以激活或取消告警通知的发送。

2.PWS终端需求

       对于PWS终端，有如下基本需求：

       1）PWS终端应尽可能不需用户进行任何操作即可接收并显示告警通知。

       2）PWS终端处于空闲状态时，可接收告警通知。

       3）PWS终端应按照告警通知提供者提供的语言显示告警通知，终端不要求有语言翻译的功能。

       4）PWS终端应具有允许用户配置与告警通知相关的功能，至少支持调整告警提示音的音量O

       5）PWS终端应具备只用于告警通知的特定告警提示（如音频告警信号和振动）的功能，该提示区别于其他告警提示；当终端收到告警通知时，用户操作界面应有停止特定音频和振动告警提示的功能。

       6）用户可通过手动操作（如通过按键）终端，停止当前持续的告警提示，但是仍可接收后续告警通知的告警提示，持续告警提示的频率和持续时间因终端类型而异。

       7）PWS终端应根据特有参数判定某告警通知是否为重复告警通知，从而自动拒绝接收重复的告警通知。

       8）PWS终端应不具有转发、回复、复制粘贴告警通知的功能。

       9）PWS终端应具有存储、查阅告警通知的功能。

在满足上述基本需求的基础上，终端还可以满足以下需求：

       1）根据监管要求和运营商的策略，终端可具备接收非告警通知的能力。

       2）终端的电池寿命不应受PWS影响。

       3）PWS的终端应默认设置为接收所有告警通知。

       4）受监管要求和运营商策略限制，终端应尽可能具备禁用部分或所有告警通知的功能。用户应能通过终端用户界面选择启用/禁用选项，启用、禁用接收部分或所有告警通知。

3.PWS其他需求

        PWS漫游需求：如果PWS用户在归属网络激活了告警通知业务，当用户漫游到拜访地且拜访网络支持PWS时，用户应尽可能收到拜访网络的告警通知；若PWS终端不满足拜访网络的PWS业务要求，终端可能无法接受拜访网络的告警通知。

       PWS管制需求：PWS应符合地区性的管制需求。因此，对于不同网络、或同一个网络的不同地区提供PWS业务都有不同的需求。

       PWS安全需求：根据管制政策需要，PWS应只广播授权告警通知提供者发送的告警通知；应保护告警通知的完整性；应能屏蔽错误或虚假的告警通知。

       以上介绍了公共预警的需求，下面以地震和海啸预警系统、手机预警系统为例，说明具体的公共预警实现机制和方案。

       地震和海啸预警系统（ETWS）是为应对地震和海啸这样的自然灾害而设计的一种公共预警系统。地震和海啸传播速度快、持续时间短，需快速准确地发送告警通知给受灾用户，帮助用户采取恰当的应急措施逃避危险。同时，告警通知内容应易于不同用户（如不同语言的用户）理解。目前，许多国家迫切需要地震和海啸预警系统减轻灾难带给人类社会的损失。

1.ETWS需求

       ETWS的实现示意如图5-92所示。

       如图5-92所示，告警通知提供者通过网络（如PLMN）同时向在受灾区域且具有接受告警通知能力的手机用户广播关于地震和海啸的告警通知，以便用户逃离危险。

根据紧急程度，告警通知分为如下两类：

图5-92    ETWS实现示意图

     （1）主要告警通知（Primary Notification）：ETWS在最短的时间内（秒级）为用户提供最紧急事件的通知，如地震即将发生。

     （2）次要告警通知（Secondary Notification）：ETWS向用户发送政府颁布的非紧急补充信息，如应急措施、避难所地图、食物分发日程表等。

      对上述告警通知的广播传送时间有如下需求：

      1）对网络运营商，发送告警通知的持续时间是从收到告警通知开始到告警通知成功发送给用户之间的时间。

       2）即使在话务量拥塞的情况下，主要告警通知应在4s内发送给通知区域的用户。

       3）即使在话务量拥塞的情况下，次要告警通知也能传送给通知区域的用户。.

       对于告警通知的内容，要求主要告警通知和次要告警通知都应至少通知地震和海啸两种紧急事件，并向终端标识告警提示的优选方式，如是否在终端界面上显示文本信息、是否响铃或是否振动；应区别于测试、训练或其他通知；应以合适的类型和长度发送，如考虑到ETWS的传送能力，应将告警内容限制在一定长度内；主要告警通知应以尽可能少的字节在网络上传送，以实现快速传递;次要告警通知能发送大量数据，如传送文本、音频、救助指南、避难所地图、食物分发日程表等内容。

        告警通知的发送有一定的优先级要求，主要告警通知应优先于次要告警通知，网络应根据告警通知优先级顺序排列通知，以免主要告警通知和次要告警通知同时存在于网络中。

       用户收到告警通知时，终端应以只直观的方式（如图标或图片）提示地震和海啸即将发生；告警通知提供者采用地区较通用语言、易理解的方式发送告警通知。

2.ETWS架构和消息流程

       针对上述ETWS需求，公众移动通信网络（如GSM、UMTS、LTE等）有如下5种不同的解决方案，即方案1：带有IMSI并基于CBS的解决方案；方案2：E-MBMS；方案3：MBMS；方案4：通过GERAN接入的并基于增强型CBS的解决方案；方案5：通过Paging消息，并基于增强型CBS的解决方案。

       每个方案关注的侧重点不同，如方案1只关注告警通知的广播速度，而方案5着重考虑了安全和覆盖全球的范围。

      分析以上5种方案，主要分为基于小区广播系统（CBS）和基于多媒体广播/组播业务（MBMS）架构的两种方案。

     （1）基于CBS的ETWS

       方案1、方案4和方案5是基于CBS的ETWS实现方案，适用于GERAN、UTRAN、E-UTRAN3种无线接入方式，如图5-93所示。

图5-93   基于CBS的ETWS架构图

 

如图5-93所示：

       1）小区广播中心（CBC）可通过UTRAN（UMTS网络的无线接入网）、E-UTRAN（LTE网络的无线接入网）、GERAN（GSM无线接入网）向UE发送告警通知。

       2）当UE收到CBC发送包括Paging-ETWS-Indicator字段的消息时，终端即启动接收告警通知的功能。

       3）可在一定区域内向所有接收者发送大量不需确认的告警消息。

       4）告警通知发送给告警信息提供者和网络运营商相互协定的覆盖区域，可能包括一个小区、多个小区或整个移动网络。

       5）告警消息可来自许多小区广播实体（CellBroadcastEntities,CBE）,如提供信息源的PSAP0

       6）BSC/RNC应只连接一个CBC,BSC/RNC应支持如下功能，见表5-9。

BSC	RNC
翻译CBC发送的消息
存储CBS消息
路由CBS消息给相应BTSs	路由CBS消息
	向终端发送包含Paging-ETWS-Indicator和紧急指示的消 息给，指示告警

       基于小区广播系统的ETWS流程如图5-94所示。

       1）通过设备管理界面将终端配置成根据Paging-ETWS-Indicator字段接受ETWS告警通知。终端和网络进行双向认证鉴权，并与ETWS时钟进行同步。 

图5-94  基于小区广播系统的ETWS流程

       2）CBC接受并验证CBE发送的告警通知，包括告警类型（见表5-10）、告警消息、告警区域（标识连接的RNC）、告警时长。

表5-10   告警类型值

       3）RNC收到CBC发送的Write-Replace消息，包括紧急指示（区别普通小区广播消息）、服务区域ID列表（标识广播的小区）、告警类型、告警消息（包括数字签名、时间戳）等。

       4）RNC通过“服务区域ID列表”和lub接口向NodeB发送消息（包含紧急指示）。

       5）根据CBE要求和告警时长，RNC/NodeB可重复不断的广播告警通知。

       6）终端收到带有Paging-ETWS-Indicator字段和告警类型值的消息时，即接收并显示告警通知。

       7）RNC给CBC发送响应消息Report-Successo

       8）CBC给CBE发送确认消息ACK。

（2）基于E-MBMS的ETWS

      方案2和方案3是基于MBMS的ETWS实现方案，本节以基于E-MBMS为例说明ETWS 的系统架构，该架构只适用于E-UTRAN无线接入方式，如图5-95所示。

图5-95   基于E-MBMS的ETWS架构图

       在图5-95中，内容提供方可通过MBMS系统向UE发送告警通知；MBMS1接收和处理来自eBM-SC的MBMS承载业务会话控制信令（如会话开始、停止）以及用户面功能模块所提供的必要信息（如用于MBMS数据传输的IP组播地址），并通过M3接口与接入网进行信令交互；MBMS2为E-UTRAN（eNodeB）分配IP组播地址，通过SGmb和Sm接口转发eBM-SC与MBMS1之间的交互信令，通过SGi-mb接口接收来自eBM-SC的MBMS业务数据，并通过Ml接口将业务数据下发到接入网侧；eBM-SC除具有提供用户业务功能外，还可针对业务特性和用户数量，通过SGi接口选择合理的承载方式（MBMS承载或单播承载），UE可使用单播承载方式向eBM-SC发起注册/注销，可通过单播承载方式为特定用户提供高级别的MBMS业务。

       根据发送主要告警通知和次要告警通知方式的不同，基于E-MBMS的ETWS消息流程有两种实现方式，如图5-96和图5-97所示。方式1以MBMS数据的方式发送主要告警通知/次要告警通知，方式2在会话开始请求消息中发送主要告警通知，并以MBMS数据方式发送次要告警通知。相对而言，方式2能够更及时地向用户发送主要告警通知。

图5-96  基于E-MBMS的ETWS消息流程图（方式1） 

       1) eBM-SC给MBMS2发送会话开始请求消息，并提供会话属性(包括QoS、MBMS业务区域、会话标识符和会话持续时间等)。

       2) MBMS2给eBM-SC发送会话开始响应消息，并包含eBM-SC发送给MBMS2的MBMS数据。

       3) MBMS2存储会话属性，并为此次会话分配IP组播地址；同时，发送会话开始请求消息(会话属性、IP组播地址)给MBMS1。

       4) MBMS1存储会话属性，并发送响应消息给MBMS2。

       5) MBMS1发送会话开始请求消息给E-UTRAN。

       6) E-UTRAN给MBMS1发送响应消息，确认收到会话开始请求消息。

       7) E-UTRAN(eNodeB)向IP多播地址发送IP组播加入消息。

       8) 根据MBMS数据传送参数，E-UTRAN建立RAN无线资源。

       9) eBM-SC以MBMS数据方式向MBMS2发送ETWS主要告警通知/次要告警通知。

      10) MBMS2可增加同步信息，并使用IP组播方式向所有已加入的E-UTRAN(eNodeB)发送主要告警通知/次要告警通知。

图9-97  基于E-MBMS的ETWS消息流程图（方式2） 

       图5-97所示的方式2与图5-96所示的方式1有如下区别：

       1) 会话开始请求消息(消息1)、消息3)和消息5))中增加了ETWS主要告警通知指示语。

       2) 建立RAN资源(消息8))时，E-UTRAN(eNodeB)向UE只发送主要告警通知。

       3) eBM-SC向E-UTRAN(eNodeB)(消息9)和消息10)只发送ETWS次要告警通知。

       3GPPETMS相关规范见表5-11。

       美国FCC根据国会2006年9月通过的《紧急警报和应急反应网法》(Warning Alert and Response Network Act,WARN)的要求开始建设商用手机预警系统(CMAS)。该法案在2006年10月13日签署成为法律，是一部旨在改进国家紧急情况警报体系的联邦法令。

Rel. 8	3GPP规范	内 容	状态
Stage 1	TS 22. 168	主要研究ETWS的需求，包括3GPP研究范围的界定、 对预警信息传递的需求、对传递时长的需求、对分布颗 粒度的需求、对预警信息成分和大小的需求、优先级的 需求、对终端的需求、安全需求、计费需求、漫游需求等	SA1负责，已完成
Stage 2	TS 23. 041	介绍基于GSM和UMTS网络架构的小区广播短消息 业务(CBS)的技术实现,包括网络架构、功能实体(包括 CBE、CBC、BSC/RNC、BTS、UE/MS 等)、协议参数、消息 格式、流程等，并包含针对ETWS的增强功能	CT1负责，已完成
	TR 23. 828	该技术报告列举了 3GPP网络(如GSM、UMTS、LTE) 针对ETWS需求的5种候选解决方案，主要是无线接入侧(如 GERAN、UTRAN、E-UTRAN 等)方案	SA2负责，已完成
Stage 3	TS 25.419	UTRAN lu-BC接口 ：服务区域广播协议(SABP)增加 Paging-ETWS-Indicator 扩展字段支持 ETWS	正在进行

       2007年至2008年期间，FCC的相关标准组织(包括ATIS、TIA等)针对CMAS做了大量的工作，讨论通过了CMAS的网络架构、技术需求、操作过程等。根据WARN的不同要求，2008年FCC颁布了如下3个报告，指导并推进CMAS的建设：

       1) FCC08-99:FCC First Report and Order In the Matter of The CMAS,针对WARN的602(a),包括CMAS的需求、架构、协议等。

       2) FCC08-164:FCC Second Report and Order and Further Notice of Proposed RulemakingIn the Matter of The CMAS,针对WARN的602(c)和602(f),包括CMAS的补充传送系统(如电视台、广播台等)要求、运营商的测试要求(如每月接口测试等)。

       3)FCC08-184:FCC Third Report and Order and Further Notice of Proposed Rulemaking In the Matter of The CMAS,针对WARN的602(b),包括告运营商参与CMAS程序、用户接受告警能力、运营商运维CMAS成本、CMAS部署进度等相关规定。

       美国ATIS联合TIA颁布了Joint ATIS/TIA CMAS Mobile Device Behavior Specification,主要内容内容包括“C”接口、CMAS的具体需求、CMAS终端功能等。

       ATIS的无线技术系统委员会(Wireless Technologies and Systems Committee,WTSC)制定了基于GSM/UMTS小区广播服务的CMAS标准，主要规范E接口；而TIA即将颁布的TIA.1149标准是基于CDMA系统的CMAS,主要对CDMA2000空中接口进行扩展以支持CMAS。

1.CMAS需求

       CMAS系统实现示意图如图5-98所示。

       如图5-98所示，美国联邦应急事务管理总署(FederalEmergencyManagementAgency,FE-MA)接受和汇集联邦机构、本地或州应急中心(EmergencyOperationsCenter,EOC)等发送的预警信息，并通过安全接口向运营商发送，运营商收到预警信息后向各自的用户发送。

       CMAS是FCC拟部署的全国灾害短信预警系统，在全国范围内建立一个手机短信发送预警体系。一旦发生自然灾害或紧急事件，灾后电视、广播信号和电力等中断，该预警系统能够以短信(将来会有音频、视频等)的方式及时向有手机和其他移动设备的用户发送预警信息，并能在第一时间向公众通报事件情况，以便人员疏导和组织救灾。

       美国各大移动通信运营商可自愿加入该预警系统，向用户发送告警通知。如果用户的手机支持CMAS,并与运营商签署手机漫游协议，不论用户身处何地都可通过CMAS收到预警信息。 

图5-98   CMAS系统实现示意图

商用手机预警系统有如下需求：

       1）美国移动运营商可通过CMAS向各自用户发送以下3类公共预警信息：

       ①美国总统启用CMAS发送的消息：危及美国公众安全和健康的重大事故信息，如恐怖主义袭击等。

       ②灾难预警信息：告知市民有可能会发生影响他们生活或危及生命的事件，如地震、龙卷风等在内的重大自然灾害信息。

       ③儿童绑架事件预警信息：儿童教育和“安贝尔预警系统”（AmberAlert,由美国政府设立、专门用于协助寻访失踪和被绑架儿童的预警网络）信息。

       2) CMAS用户可通过终端界面拒绝接收灾难和儿童绑架预警信息，而任何开通小区广播服务的CMAS终端都必须无条件接收并呈现总统启用CMAS发送的信息。

       3) 提供特定的声音、振动或视频告警提示，确保用户可以听到或看到告警提示。

       4) 紧急告警不能中断正在进行的呼叫。

       5) 可发送包含90个英文字符的消息（基于GSM的7bit编码）。

2.CMAS架构

       基于GSM/UMTS小区广播功能架构，并结合图5-98所示的实现示意，CMAS架构有图5-99基于GSM的CMAS架构和图5-100基于UMTS的CMAS架构。

3.CMAS现状

       目前，FCC已选定预警通知发送的技术标准，并帮助运营商部署相应的网络，确保发送预警通知的网络通畅。CMAS只支持英文告警，并正在商定是否也可以提供其他语言告警。

       FCC同时也要求电视台作为CMAS的附属告警通知分发系统。在商务部18个月的资助下，所有电视台必须为数字电视传送器配备相应的装置与技术，进而可接收来自FEMA的CMAS告警通知，并传送给已加入CMAS的运营商。表5-12为CMAS自2006年10月以来的发展时间表。 

图5-99   基于GSM的CMAS架构

图5-100    基于UMTS的CMAS架构

表5-12CMAS时间表

        ETWS和CMAS是PWS的两种系统，存在共同点和不同点，详见表5-13。

表5-13ETWS和CMAS对比

 

子系统名称	ETWS	CMAS
关系	都属于PWS
简介	通过网络向用户广播地震和海啸的告警通知	美国全国性基于手机短信的预警体系（类 似小区广播功能）
主导国家	日本	美国
告警通知	只发送地震、海啸告警通知	发送自然灾害（地震、海啸等）、社会灾害（如恐怖主义、寻找儿童等）的预警信息
方案	5种候选方案，基于CBS和MBMS两类	基于GSM/UMTS网络的CRS架构
现状	日本全国范围内已经运行了 EEW系统	预计2010年前可付诸实施
需求 参考规范	TS 22. 168 和 TS 22. 268	FCC 08-99、TS 22. 268 和 Joint AT1S/TIA CMAS Mobile Device Behavior Specification