专利名称：传输信息的方法和装置的制作方法
技术领域：
本发明涉及通信领域，并且更具体地，涉及传输信息的方法和装置。
背景技术：
基站接收到地震海嘯报警系统(ETWS,Earthquake and Tsunami Warning System)发送的警报发送请求(Write-Replace Warning Request)消息之后，需要将该消息的内容在空口进行广播。对于地震台风海嘯易发区，可能存在同一时间需要发送多条重复的Write-Replace Warning Request消息的情况,在空口出现拥塞。在现有技术中，当重复的Write-Replace Warning Request到达基站时,基站仅广播一条消息，而将其他消息丢弃，这种处理方式会使地震海嘯的信息报警效果会受到严重 影响。
发明内容
本发明实施例提供一种传输信息的方法和装置，能够根据消息的紧急程度对重复的消息进行广播操作，从而确保地震海嘯的信息报警效果。一方面，提供了一种传输信息的方法，其特征在于，该方法包括第一设备接收警报广播请求消息；如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是该第一设备在接收该警报广播请求消息前接收到的；或者，如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该第一属性指示该警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与该警报广播请求消息重复的消息。另一方面，提供了一种传输信息的方法，其特征在于，该方法包括第一设备接收警报广播请求消息；如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息包括首要通知PN，则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是在该警报广播请求消息前接收到的；或者，如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息不包括PN，则继续或开始广播与该警报广播请求消息重复的消息。再一方面，提供了一种传输信息的装置，其特征在于，该装置包括接收单元，用于接收警报广播请求消息；发送单元，用于广播该接收单元接收的警报广播请求消息；其中，该发送单元具体用于如果在该接收单元接收到该警报广播请求消息后，该发送单元正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是该接收单元在接收该警报广播请求消息前接收到的；或者，如果在该接收单元接收到该警报广播请求消息后，该发送単元正在广播或即将广播与该警报广播请求消息重复的消息，且该第一属性指示该警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与该警报广播请求消息重复的消息。再一方面，提供了一种传输信息的装置，其特征在于，该装置包括接收单元，用于接收警报广播请求消息；发送单元，用于广播该接收単元接收的警报广播请求消息；其中，该发送単元具体用于如果在该接收单元接收到该警报广播请求消息后，该发送単元正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息包括首要通知PN,则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是在该警报广播请求消息前接收到的；或者，具体用于如果在该接收单元接收到该警报广播请求消息后，该发送単元正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息不包括PN，则继续或开始广播与该警报广播请求消息重复的消息。根据本发明实施例的传输信息的方法和装置，通过根据警报消息的紧急程度来广播重复的警报消息，能够避免紧急的警报消息被丢弃，从而能够有效实现报警作用。
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图I是本发明的一个实施例提供的传输信息的方法的示意性流程图。图2是本发明的另ー实施例提供的传输信息的方法的示意性流程图。图3是本发明的一个实施例提供的传输信息的装置的示意性框图。图4是本发明的另ー实施例提供的传输信息的装置的示意性框图。
具体实施例方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。本发明的技术方案，可以应用于各种通信系统，例如全球移动通讯系统(GSM，Global System ofMobile communication),码分多址(CDMA, Code Division MultipleAccess)系统，宽带码分多址(WCDMA, Wideband Code Division Multiple AccessWireless),通用分组无线业务(GPRS, General Packet Radio Service),长期演进(LTE,Long Term Evolution)等。用户端(UE, User Equipment),也可称之为移动终端(Mobile Terminal)、移动用户设备等，可以经无线接入网(例如，RAN, Radio Access Network)与一个或多个核心网进行通信，用户设备可以是移动终端，如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。
基站，可以是GSM 或 CDMA 中的基站(BTS, Base Transceiver Station),也可以是WCDMA中的基站(NodeB),还可以是LTE中的演进型基站(eNB或e-NodeB, evolutional NodeB)，本发明并不限定，但为描述方便，下述实施例以eNB为例进行说明。图I示出了从基站(即第一设备的举例)角度描述的根据本发明一实施例的传输信息的方法100的示意性流程图，如图I所示，该方法100包括S110，第一设备接收警报广播请求消息；S120，如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是该第一设备在接收该警报广播请求消息前接收到的； 如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该第一属性指示该警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与该警报广播请求消息重复的消息。可选地，在本发明实施例中，基站(即第一设备的举例)可以通过SI接ロ接收ETWS发送的警报广播请求消息(以下，记作Write-Replace Warning Request#l)。作为示例而非限定，在本发明实施例中，ETWS可以首先将该Write-Replace Warning Request#l发送给网络侧的警报通知提供方(WNP, warning notification provider),该WNP可以将Write-Replace Warning Request#l 转发给小区广播中心(CBC, cell brocost center),CBC 可以将 Write-Replace Warning Request#l 转发给移动管理实体(MME, MobilityManagement Entity),并由 MME 通过 S I 接ロ将 Write-Replace Warning Request#l 转发给基站。以上，以Write-Replace Warning Request#l为例,对基站接收警报广播请求消息的过程进行了说明，在以下说明中，基站接收警报广播请求消息的过程均可遵从以上过程。根据消息的目的和紧急性，警报广播请求消息可以包括首要通知(PN，Primarynotification)和次要通知(SN, Secondary notification)。首要通知用于快速向用户通告即将发生事件的最为紧急的信息(例如，即将发生的地震或海嘯)，因此时效性较高。次要通知主要用于传送附加信息(例如，发生紧急事件时，应该怎么做或到哪里获得帮助等)。在警报广播请求消息中定义的首要通知，要求在4秒内传送至预计发布警报广播请求消息区域的用户端，并且要求传达少量数据，以便于在网络中快速发送。基站通过系统消息块 10 (SIB10, System Information BlocklO)将该 PN 发送给用户端。在警报广播请求消息中定义的次要通知的长度是9600字节(Byte)，并且，在正常情况下，固网传输时延是毫秒级。存在基站接收到Write-Replace Warning Request#l时，正在或即将发送另一警报广播请求消息(以下，记作Write-Replace Warning Request#2)的情况。其中，“即将发送”指基站需要在第一时段内开始发送，随后对该“第一时间段”进行详细说明。在本发明实施例中，与所述警报广播请求消息重复的消息是所述第一设备在接收所述警报广播请求消息之前接收到的。例如，上述举例中的Write-Replace WarningRequest#2在时间顺序上，先于Write-Replace Warning Request#l到达基站，并且，Write-Replace Warning Request#l 是基站对 Write-Replace Warning Request#2 进行广播前或广播期间到达基站，即两条消息在空ロ出现拥塞。
具体地说,对Write-Replace Warning Request#2进行广播期间是指,基站通过系统消息块11(SIB11, System Information Blockll)将SN发送给用户端,而能够通过SIBll一次发送的消息长度远小于9600Byte，并且，SIBll的使用存在周期性，不能随意的通过一个SIBll连续发送，因此,基站在通过SIBll发送Write-Replace Warning Request消息的SN时,可能会将该SN分片，发送延时也可能比较大,从而,存在基站接收到Write-ReplaceWarning Request#l时，正在发送另一警报广播请求消息(例如，Write-Replace WarningRequest#2)的情况。在本发明实施例中，该即将广播与该警报广播请求消息重复的消息指需要在第一时段内开始广播与该警报广播请求消息重复的消息；其中，该第一时段小于或等于该第一设备的收发转换时延，或者，该第一时段小于或等于该第一设备的消息读取时延。具体地说，对Write-Replace Warning Request#2进行广播前(或者说，即将广播 Write-Replace Warning Request#2)是指，由于在基站对 Write-Replace WarningRequest#2的接收过程和发送(广播)过程之间，存在收发转换时延，因此，存在基站接收到Write-Replace Warning Request#l时，即将(需要在第一时段内)发送另一警报广播请求 消息(例Warning Request#2)的情况。应理解，以上列举了以接收过程和发送过程之间的时延作为第一时段的判定标准的实施例，但本发明并不限定于此，其他能够导致基站对消息发送的延时的情况及该情况下的对应参数均落入本发明的保护范围内，例如，如果基站是从用于存储待发送的消息的消息栈中提取该Write-Replace WarningRequest#2并对其进行广播，则该第一时段还可以是因基站从消息栈中提取消息而产生的时延。以下，省略对相同或相似情况的说明。在本发明实施例中，在两条消息在空口出现拥塞的情况下，基站可以判定Write-Replace Warning Request#l 与 Write-Replace Warning Request#2 是否是重复消息。可选地，在本发明实施例中，作为示例而非限定，基站可以根据Write-R印laceWarning Request 包括的序列号(Serial Number)和信息标识(Message Identifier)这两个信兀进行判定，即，如果 Write-Replace Warning Request#l 的 Serial Number 及Message Identifier 与 Write-Replace Warning Request#2 的 Serial Number 及 MessageIdentifier 全部相同，则可以确定 Write-Replace Warning Request#l 与 Write-ReplaceWarning ReqUeSt#2为重复消息。以下，省略对相同或相似情况的说明。在确定Write-Replace Warning Request#l 与 Write-Replace WarningRequest#2是重复消息后，基站根据Write-Replace Warning Request#l的紧急程度,确定对Write-Replace Warning Request#l 与 Write-Replace Warning Request#2 的处理方式。在本发明实施例中，基站可以根据该Write-Replace Warning Request#l是否需要在用户端自动弹出来确定其紧急程度。可选地，在本发明实施例中，该第一属性为所述警报广播请求消息中的序列号信息的一项内容。例如，基站可以根据Write-Replace Warning Request#l消息包括的SerialNumber中的弹出标识Pop的属性,确定该Write-Replace Warning Request#l是否需要在用户端自动弹出。例如，如果Pop为1，则代表用户端自动弹出该警报消息，如果Pop为0，则代表用户手动打开提示并阅读。因此，当Pop为I时,基站可以确定Write-Replace WarningRequest#!的紧急程度高。应理解，以上列举的Pop的值仅为本发明的一个实施例，本法并不限定于此，其他能够指示用户端的不同处理方法的值均落入本发明的保护范围内，例如，也可以认为如果Pop为O，则代表用户端自动弹出该警报消息，如果Pop为1，则代表用户手动打开提示并阅读。下面，分别对基站在Write-Replace Warning Request#l需要在用户端自动弹出的情况下(即情况I :紧急程度高情况的一例)以及在Write-Replace Warning Request#l不需要在用户端自动弹出的情况下(即情况2 :紧急程度低情况的一例)的处理进行举例说明。情况I如果Write-Replace Warning Request#l需要在用户端自动弹出，则基站可以暂停或不开始对Write-Replace Warning Request#2的广播，并且可以开始广播该Write-Replace Warning Request#l,具体的，可通过SIBlO广播该Write-Replace WarningRequest#l 的 PN,通过 SIB 11 广播该 Write-Replace Warning Request#l 的 SN,应理解，以上列举的广播Write-Replace Warning Request#l的处理仅为示例性说明，本发明并不限定于此。以下省略相同或相似的说明。 可选地，在本发明实施例中，该方法还包括该第一设备在该警报广播请求消息包括警报类型信息和警报安全信息的情况下，确定该警报广播请求消息包括PN。例如，在Write-Replace Warning Request#l中同时存在警报类型信息(Warning Type)和警报安全信息(Warning Security Information)这两个信兀时，基站确定该Write-ReplaceWarning RequestSl包括PN。应理解，以上列举的根据警报类型信息和警报安全信息是否同时存在来确定该警报消息是否包括PN的方法仅为本发明的ー个示例性说明，其他能够用于确定警报消息是否包括PN的方法均落入本发明的包含范围内。以下，省略对相同或相似情况地说明。通常，PN从基站到用户端的传递持续时间为4秒，因此，当Write-ReplaceWarning Request#l 包括 PN 时，基站可以确定 Write-Replace Warning Request#l 的紧急程度高。因此，基站还可以根据警报广播请求消息在用户端是否自动弹出和该警报广播请求消息是否包括PN的情况确定其紧急程度。也即，本发明实施例中，第一设备可以结合警报广播请求消息在用户端是否自动弹出和是否包括PN的情况确定处理方式。以下，省略对相同或相似情况地说明。下面，分别对基站在Write-Replace Warning Request#l需要在用户端自动弹出，且该Write-Replace Warning Request#l包括PN的情况下(即情况A :紧急程度高情况的另一例)以及在Write-Replace Warning Request#l需要在用户端自动弹出，且该Write-Replace Warning Request#l不包括PN的情况下(即情况B :紧急程度高情况的再一例)的处理进行举例说明。情况A可选地，在本发明实施例中，如果该第一属性指示该警报广播请求消息需要在用户端自动弹出，且该警报广播请求消息包括首要通知PN，则该方法还包括丢弃与该警报广播请求消息重复的消息。具体地说，如果Write-Replace Warning Request#l需要在用户端自动弹出，且该 Write-Replace Warning Request#l 包括 PN,则在基站正在对 Write-Replace WarningRequest#2进行广播的情况下，基站可以暂停对Write-Replace Warning Request#2的广播。并且，基站可以开始广播该Write-Replace Warning Request#l0进一步，基站还可以丢弃Write-Replace Warning Request#20例如，正在对Write-Replace Warning Request#2 进行广播的情况下，不再对 Write-Replace WarningRequest#2的未广播内容进行广播，未对Write-Replace Warning Request#2进行广播的情况下，直接删除该Write-Replace Warning Request#2，应理解，以上列举的丢弃Write-Replace Warning Request#2的处理仅为示例性说明，本发明并不限定于此。情况B可选地，在本发明实施例中，如果该第一属性指示该警报广播请求消息需要在用户端自动弹出，且该警报广播请求消息不包括PN，则继续广播或开始广播与该警报广播请求消息重复的消息，并在该广播与该警报广播请求消息重复的消息结束后，开始广播该 警报广播请求消息。可以理解的，该继续广播的情况是针对本发明实施例中“正在发送Write-Replace Warning Request#2”的情况所作的处理，该“开始广播”是针对本发明实施例中“即将发送Write-Replace Warning Request#2”的情况所做的处理，后文不再赘述。具体地说，如果Write-Replace Warning Request#l需要在用户端自动弹出，且该Write-Replace Warning Request#l 不包括 PN，则在基站正在对 Write-Replace WarningRequest#2进行广播的情况下，基站可以继续对Write-Replace Warning Request#2的广播，在基站未对Write-Replace Warning Request#2进行广播的情况下，基站可以开始广播该 Write-Replace Warning Request#2，即，通过 SIBlO 广播该 Write-Replace WarningRequest#2 的 PN，通过 SIBll 广播该 Write-Replace Warning Request#2 的 SN。应理解，以上列举的广播Write-Replace Warning Request#2的处理仅为示例性说明，本发明并不限定于此。以下省略相同或相似的说明。进一步，基站可以在完成对Write-Replace Warning Request#2的广播后，可以开始广播该 Write-Replace Warning Request#l 0根据本发明实施例的传输信息的方法，通过根据两个维度(消息是否在用户端弹出以及是否包括PN)来确定对消息的处理方式，能够进一步确保地震海嘯的信息报警效果，并且，能够缓存某些ETWS消息并在合适的时机(非紧急状态)广播，从而能够有效保障报警效果。情况2如果Write-Replace Warning Request#l不需要在用户端自动弹出，贝U基站可以继续或开始广播 Write-Replace Warning Request#2,即，在基站正在对 Write-ReplaceWarning Request#2进行广播的情况下，基站可以继续对Write-Replace WarningRequest#2的广播，在基站未对Write-Replace Warning Request#2进行广播的情况下，基站可以广播该 Write-Replace Warning Request#20可选地，在本发明实施例中，该方法还包括该第一设备在该警报广播请求消息包括警报类型信息和警报安全信息的情况下，确定该警报广播请求消息包括PN。例如，在 Write-Replace Warning Request#l 中同时存在 Warning Type 和 Warning SecurityInformation 这两个信兀时，基站确定该 Write-Replace Warning Request#l 包括 PN。下面，分别对基站在Write-Replace Warning Request#l不需要在用户端自动弹出，且该Write-Replace Warning Request#l包括PN的情况下(即情况C :紧急程度低情况的另一例)以及在Write-Replace Warning Request#l不需要在用户端自动弹出，且该Write-Replace Warning Request#l不包括PN的情况下(即情况D :紧急程度低情况的再一例)的处理进行举例说明。情况C可选地，在本发明实施例中，如果该第一属性指示该警报广播请求消息不需要在用户端自动弹出，且该警报广播请求消息包括PN，则在该广播与该警报广播请求消息重复的消息结束后，该方法还包括开始广播该警报广播请求消息。具体地说,如果Write-Replace Warning Request#l不需要在用户端自动弹出，且该 Write-Replace Warning Request#l 包括 PN,则在基站正在对 Write-Replace WarningRequest#2进行广播的情况下，基站可以继续对Write-Replace Warning Request#2的广 播；在基站未对Write-Replace Warning Request#2进行广播的情况下,基站可以开始广播该 Write-Replace Warning Request#2。进一步,基站可以在完成对Write-Replace Warning Request#2的广播后，开始广播该 Write-Replace Warning Request#l。情况D
可选地，在本发明实施例中，如果该第一属性指示该警报广播请求消息不需要在用户端自动弹出，且该警报广播请求消息不包括PN，则该方法还包括丢弃该警报广播请求消息。具体地说,如果Write-Replace Warning Request#l不需要在用户端自动弹出，且该Write-Replace Warning Request#l 不包括PN,则在基站正在对Write-Replace WarningRequest#2进行广播的情况下，基站可以继续对Write-Replace Warning Request#2的广播，在基站未对Write-Replace Warning Request#2进行广播的情况下,基站可以开始广播该 Write-Replace Warning Request#2。进一步，基站还可以丢弃Write-Replace Warning Request#l,例如，直接删除该 Write-Replace Warning Request#l,应理解，以上列举的丢弃 Write-Replace WarningRequest#2的处理仅为示例性说明，本发明并不限定于此。根据本发明实施例的传输信息的方法，通过根据两个维度(消息是否在用户端弹出以及是否包括PN)来确定对消息的处理方式，能够进ー步确保地震海嘯的信息报警效果，并且，能够缓存某些ETWS消息并在合适的时机(非紧急状态)广播，从而能够有效保障报警效果。这样，根据本发明实施例的传输信息的方法，通过根据警报消息是否在用户端弹出来确定警报消息的紧急程度，并对重复的警报消息进行广播操作，能够避免紧急的警报消息被丢弃。图2示出了从基站(即第一设备的举例)角度描述的根据本发明一实施例的传输信息的方法200的示意性流程图，如图2所示，该方法200包括S210，第一设备接收警报广播请求消息；S220,如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息包括首要通知PN，则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是在该警报广播请求消息前接收到的；如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息不包括PN，则继续或开始广播与该警报广播请求消息重复的消息。可选地，在本发明实施例中，基站(即第一设备的举例)可以通过SI接口接收ETWS发送的警报广播请求消息(以下，记作Write-Replace Warning Request#l )。作为示例而非限定，在本发明实施例中，ETWS可以首先将该Write-Replace Warning Request#l发送给网络侧的WNP，该WNP可以将Write-R印lace Warning Request#l转发给CBC，CBC可以将Write-Replace Warning Request#l 转发给 MME,并由 MME 通过 SI 接口将 Write-ReplaceWarning Request#l 转发给基站。以上，以 Write-Replace Warning Request#l 为例，对基站接收警报广播请求消息的过程进行了说明，在以下说明中，基站接收警报广播请求消息的过程均可遵从以上过程。 根据消息的目的和紧急性，警报广播请求消息可以包括PN和SN。PN用于快速向用户通告即将发生事件的最为紧急的信息(例如，即将发生的地震或海嘯)，因此时效性较高。SN主要用于传送附加信息(例如，发生紧急事件时，应该怎么做或到哪里获得帮助等)。在警报广播请求消息中定义的PN，要求在4秒内传送至预计发布警报广播请求消息区域的用户端，并且要求传达少量数据，以便于在网络中快速发送。基站通过系统消息块10 (SIB10, System Information BlocklO)将该 PN 发送给用户端。在警报广播请求消息中定义的SN的长度是9600字节(Byte)，并且，在正常情况下，固网传输时延是晕秒级。存在基站接收到Write-Replace Warning Request#l时，正在或即将发送另一警报广播请求消息(以下，记作Write-Replace Warning Request#2)的情况。其中，“即将发送”指基站需要在第一时段内开始发送，随后对该“第一时间段”进行详细说明。在本发明实施例中，与该警报广播请求消息重复的消息是该第一设备在接收该警报广播请求消息之前接收到的。例如，上述举例中的Write-Replace Warning Request#2在时间顺序上，先于 Write-Replace Warning Request#l 到达基站，并且，Write-ReplaceWarning Request#l 是基站对 Write-Replace Warning Request#2 进行广播前或广播期间到达基站，即两条消息在空口出现拥塞。具体地说,对Write-Replace Warning Request#2进行广播期间是指,基站通过系统消息块11(SIB11, System Information Blockll)将SN发送给用户端,而能够通过SIBll一次发送的消息长度远小于9600Byte，并且，SIBll的使用存在周期性，不能随意的通过一个SIBlI连续发送。因此,基站在通过SIB 11发送Write-Replace Warning Request消息的SN时,可能会将该SN分片，发送延时也可能比较大。因此，存在基站接收到Write-ReplaceWarning Request#l时，正在发送另一警报广播请求消息(例如，Write-Replace WarningRequest#2)的情况。在本发明实施例中，该即将广播与该警报广播请求消息重复的消息指需要在第一时段内开始广播与该警报广播请求消息重复的消息；其中，该第一时段小于或等于该第一设备的收发转换时延，或者，该第一时段小于或等于该第一设备的消息读取时延。
具体地说，对Write-Replace Warning Request#2进行广播前(或者说，即将广播 Write-Replace Warning Request#2)是指，由于在基站对 Write-Replace WarningRequest#2的接收过程和发送(广播)过程之间，存在收发转换时延，因此，存在基站接收到Write-Replace Warning Request#l时，即将(需要在第一时段内)发送另一警报广播请求消息(例如，Write-Replace Warning Request#2)的情况。应理解，以上列举了以接收过程和发送过程之间的时延作为第一时段的判定标准的实施例，但本发明并不限定于此，其他能够导致基站对消息发送的延时的情况及该情况下的对应参数均落入本发明的保护范围内，例如，如果基站是从用于存储待发送的消息的消息栈中提取该Write-Replace WarningRequest#2并对其进行广播，则该第一时段还可以是因基站从消息栈中提取消息而产生的时延。以下，省略对相同或相似情况的说明。在本发明实施例中，在两条消息在空ロ出现拥塞的情况下，基站可以判定Write-Replace Warning Request#l 与 Write-Replace Warning Request#2 是否是重复消息。可选地，在本发明实施例中，作为示例而非限定，基站可以根据Write-R印IaceWarning Request 包括的序列号(Serial Number)和信息标识(Message Identifier)这 两个信兀进行判定，即，如果 Write-Replace Warning Request#l 的 Serial Number 及Message Identifier 与 Write-Replace Warning Request#2 的 Serial Number 及 MessageIdentifier 全部相同，则可以确定 Write-Replace Warning Request#I 与 Write-ReplaceWarning Requests为重复消息。以下，省略对相同或相似情况的说明。在确定Write-Replace Warning Request#l 与 Write-Replace WarningRequest#2是重复消息后，基站根据Write-Replace Warning Request#l的紧急程度，确定对Write-Replace Warning Request#l 与Write-Replace Warning Request#2 的处理方式。在本发明实施例中，基站可以根据该Write-Replace Warning Request#l是否包括PN来确定其紧急程度。可选地，在本发明实施例中，该第一设备在该警报广播请求消息包括警报类型信息和警报安全信息的情况下，确定该警报广播请求消息包括PN。具体地说，基站可以在Write-Replace Warning Request#l 中同时存在 WarningType 和 Warning Security Information 这两个信兀的情况下，确定该 Write-ReplaceWarning Request#l包括PN。根据22. 268协议中的規定，PN从基站到用户端的传递持续时间为 4 秒，因此，当 Write-Replace Warning Request#l 包括 PN 时，Write-Replace WarningRequest#l的紧急程度高。下面，分别对基站在Write-Replace Warning Request#l包括PN的情况下(即情况3 :紧急程度高情况的一例)以及在Write-Replace Warning Request#l不包括PN的情况下(即情况4 :紧急程度低情况的一例)的处理进行说明。情况3如果Write-Replace Warning Request#l 包括 PN，则基站可以暂停对Write-Replace Warning Request#2 的广播，并且可以广播该 Write-Replace WarningRequest#l，即，通过 SIB 10 广播该 Write-Replace Warning Request#l 的 PN，通过 SIBll广播该 Write-Replace Warning Request#l 的 SN，应理解，以上列举的广播 Write-ReplaceWarning Request#l的处理仅为示例性说明，本发明并不限定于此。以下省略相同或相似的说明。可选地，在本发明实施例中，该方法还包括根据该警报广播请求消息的第一属性，确定该警报广播请求消息需要在用户端自动弹出，其中，该第一属性为所述警报广播请求消息中的序列号信息的一项内容。例如基站可以根据Wr i te-Rep lace WarningRequest#l消息包括的Serial Number中的弹出标识Pop的属性，确定该Write-ReplaceWarning Request#l是否需要在用户端自动弹出，例如,如果Pop为I,则代表用户端自动弹出该警报消息，如果Pop为0，则代表用户手动打开提示并阅读。因此，当Pop为I时，可以确定Write-Replace Warning Request#l的紧急程度高。应理解，以上列举的Pop的值仅为本发明的一个实施例，本法并不限定于此，其他能够指示用户端的不同处理方法的值均落入本发明的保护范围内，例如，也可以认为如果Pop为0，侧代表用户端自动弹出该警报消息，如果Pop为1，侧代表用户手动打开提示并阅读。以下，省略对相同或相似情况的说明。因此，基站还可以根据警报广播请求消息是否包括PN的情况和该警报广播请求消息在用户端是否自动弹出确定其紧急程度。也即，本发明实施例中，第一设备可以结合警 报广播请求消息是否包括PN的情况和在用户端是否自动弹出确定处理方式。以下，省略对相同或相似情况的说明。下面，分别对基站在Write-Replace Warning Request#l 包括 PN,且该Write-Replace Warning Request#l需要在用户端自动弹出的情况下(即情况E :紧急程度高情况的另一例)以及在 Write-Replace Warning Request#l 包括 PN,且该 Write-ReplaceWarning Request#l不需要在用户端自动弹出的情况下(即情况F :紧急程度高的再一例)的处理进行举例说明。情况E可选地，在本发明实施例中，如果该警报广播请求消息包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则该方法还包括丢弃与该警报广播请求消息重复的消息。具体地说，如果Write-Replace Warning Request#l 包括 PN,且该 Write-ReplaceWarning Request#l需要在用户端自动弹出，则在基站正在对Write-Replace WarningRequest#2进行广播的情况下，基站可以暂停对Write-Replace Warning Request#2的广播。并且，基站可以开始广播该Write-Replace Warning Request#l。进一步，基站还可以丢弃Write-Replace Warning Request#2,例如，正在对Write-Replace Warning Request#2 进行广播的情况下，不再对 Write-Replace WarningRequest#2的未广播内容进行广播，未对Write-Replace Warning Request#2进行广播的情况下，直接删除该Write-Replace Warning Request#2,应理解，以上列举的丢弃Write-Replace Warning Request#2的处理仅为示例性说明，本发明并不限定于此。情况F可选地，在本发明实施例中，如果该警报广播请求消息包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与该警报广播请求消息重复的消息，并在该广播与该警报广播请求消息重复的消息结束后，开始广播该警报广播请求消息。可以理解的，该继续广播的情况是针对本发明实施例中“正在发送Write-Replace Warning Request#2”的情况所作的处理，该“开始广播”是针对本发明实施例中“即将发送Write-Replace Warning Request#2”的情况所做的处理，后文不
再赘述。 具体地说，如果Write-Replace Warning Request#l 包括 PN，且该 Write-ReplaceWarning Request#l不需要在用户端自动弹出，贝U在基站正在对Write-Replace WarningRequest#2进行广播的情况下，基站可以继续对Write-Replace Warning Request#2的广播，在基站未对Write-Replace Warning Request#2进行广播的情况下，基站可以广播该 Write-Replace Warning Request#2, S卩，通过 SIBlO 广播该 Write-Replace WarningRequest#2 的 PN，通过 SIBl I 广播该 Write-Replace Warning Request#2 的 SN。应理解，以上列举的广播Write-Replace Warning Request#2的处理仅为示例性说明，本发明并不限定于此。以下省略相同或相似的说明。进ー步，基站可以在完成对Write-Replace Warning Request#2的广播后，可以广播该 Write-Replace Warning Request#l。根据本发明实施例的传输信息的方法，通过根据两个维度(消息是否在用户端弹出以及是否包括PN)来确定对消息的处理方式，能够进ー步确保地震海嘯的信息报警效果，并且，能够缓存某些ETWS消息并在合适的时机(非紧急状态)广播，从而能够有效保障报警效果。情况4如果Write-Replace Warning Request#l不包括PN，贝U基站可以继续或开始广播 Write-Replace Warning Request#2，即，在基站正在对Write-Replace Warning Request#2进行广播的情况下，基站可以继续对Write-Replace Warning Request#2的广播，在基站未对Write-Replace Warning Request#2进行广播的情况下，基站可以广播该Write-ReplaceWarning Request#2。可选地，在本发明实施例中，该方法还包括根据该警报广播请求消息的第一属性，确定该警报广播请求消息需要在用户端自动弹出，其中，该第一属性为所述警报广播请求消息中的序列号信息的ー项内容。例如，基站可以根据Write-Replace WarningRequest#l消息包括的Serial Number中的弹出标识Pop的属性，确定该Write-ReplaceWarning Request#l是否需要在用户端自动弹出，例如，如果Pop为I，则代表用户端自动弹出该警报消息，如果Pop为0，则代表用户手动打开提示并阅读。下面，分别对基站在Write-Replace Warning Request#l不包括PN，且该Write-Replace Warning Request#l需要在用户端自动弹出的情况下(即情况G :紧急程度低情况的另一例)以及在Write-Replace Warning Request#l不包括PN，且该Write-Replace Warning Request#l不需要在用户端自动弹出的情况下(即情况F :紧急程度低情况的再一例)的处理进行举例说明。情况G可选地，在本发明实施例中，如果该警报广播请求消息不包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则在该广播与该警报广播请求消息重复的消息結束后，该方法还包括开始广播该警报广播请求消息。如果Write-ReplaceWarning Request#l 不包括PN，且该Write-Replace WarningRequest#l需要在用户端自动弹出，则在基站正在对Write-Replace Warning Request#2进行广播的情况下，基站可以继续对Write-Replace Warning Request#2的广播，在基站未对Write-Replace Warning Request#2进行广播的情况下，基站可以开始广播该Write-Replace Warning Request#2。进一步,基站可以在完成对Write-Replace Warning Request#2的广播后，可以开始广播该 Write-Replace Warning Request#l。情况H可选地，在本发明实施例中，如果该警报广播请求消息不包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息不需要在用户端自动弹出，则该方法还包括丢弃该警报广播请求消息。如果Write-ReplaceWarning Request#l 不包括PN,且该Write-R印lace WarningRequest#l不需要在用户端自动弹出，则在基站正在对Write-Replace Warning Request#2 进行广播的情况下，基站可以继续对Write-Replace Warning Request#2的广播，在基站未对Write-Replace Warning Request#2进行广播的情况下，基站可以开始广播该Write-Replace Warning Request#2。进一步，基站还可以丢弃Write-Replace Warning Request#l,例如，直接删除该 Write-Replace Warning Request#l,应理解，以上列举的丢弃 Write-Replace WarningRequest#l的处理仅为示例性说明，本发明并不限定于此。根据本发明实施例的传输信息的方法，通过根据两个维度(消息是否在用户端弹出以及是否包括PN)来确定对消息的处理方式，能够进一步确保地震海嘯的信息报警效果，并且，能够缓存某些ETWS消息并在合适的时机(非紧急状态)广播，从而能够有效保障报警效果。这样，根据本发明实施例的传输信息的方法，通过根据警报消息是否在用户端弹出来确定警报消息的紧急程度，并对重复的警报消息进行广播操作，能够避免紧急的警报消息被丢弃。上文中，结合图I和图2，详细描述了根据本发明实施例的传输信息的方法，下面，将结合图3和图4，详细描述根据本发明实施例的传输信息的装置。图3示出了根据本发明一实施例的建立通信连接的装置200的示意性框图。如图3所示,该装置300包括接收单元310，用于接收警报广播请求消息；发送单元320，用于广播该接收单元310接收的警报广播请求消息；其中，该发送单元320具体用于如果在该接收单元310接收到该警报广播请求消息后，该发送单元320正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是该接收单元在接收该警报广播请求消息前接收到的；或者，如果在该接收单元310接收到该警报广播请求消息后，该发送单元正320在广播或即将广播与该警报广播请求消息重复的消息，且该第一属性指示该警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与该警报广播请求消息重复的消息。可选地，在本发明实施例中，该发送单元320还用于如果该第一属性指示该警报广播请求消息需要在用户端自动弹出，且该警报广播请求消息包括首要通知PN，则丢弃与该警报广播请求消息重复的消息。可选地，在本发明实施例中，该发送単元320还用于如果该第一属性指示该警报广播请求消息需要在用户端自动弹出，且该警报广播请求消息不包括PN，则继续或开始广播与该警报广播请求消息重复的消息，并在该广播与该警报广播请求消息重复的消息结束后，开始广播该警报广播请求消息。可选地，在本发明实施例中，该发送単元320还用于如果该第一属性指示该警报广播请求消息不需要在用户端自动弹出，且该警报广播请求消息包括PN，则在该广播与该警报广播请求消息重复的消息结束后，开始广播该警报广播请求消息。可选地，在本发明实施例中，该发送単元320还用于如果该第一属性指示该警报广播请求消息不需要在用户端自动弹出，且该警报广播请求消息不包括PN，则丢弃该警报广播请求消息。
可选地，在本发明实施例中，该第一属性为该警报广播请求消息中的序列号信息的ー项内容。可选地，在本发明实施例中，该装置还包括确定单元330，用于在该警报广播请求消息包括警报类型信息和警报安全信息的情况下，确定该警报广播请求消息包括PN。可选地，在本发明实施例中，该即将广播与该警报广播请求消息重复的消息指需要在第一时段内开始广播与该警报广播请求消息重复的消息；其中，该第一时段小于或等于该第一设备的收发转换时延，或者，该第一时段小于或等于该第一设备的消息读取时延。根据本发明实施例的传输信息的装置，通过根据两个维度(消息是否在用户端弹出以及是否包括PN)来确定对消息的处理方式，能够进ー步确保地震海嘯的信息报警效果，并且，能够缓存某些ETWS消息并在合适的时机(非紧急状态)广播，从而能够有效保障报警效果。这样，根据本发明实施例的传输信息的装置，通过根据警报消息是否在用户端弹出来确定警报消息的紧急程度，并对重复的警报消息进行广播操作，能够避免紧急的警报消息被丢弃。根据本发明实施例的传输信息的装置300是本发明实施例的方法100中的实施主体，并且，该传输信息的装置300中的各単元及模块和上述其他操作和/或功能分别为了实现图I中的方法100的相应流程，为了简洁，在此不再赘述。图4示出了根据本发明另ー实施例的建立通信连接的装置400的示意性框图。如图4所示,该装置400包括接收单元410，用于接收警报广播请求消息；发送单元420，用于广播该接收単元410接收的警报广播请求消息；其中，该发送単元420具体用于如果在该接收单元410接收到该警报广播请求消息后，该发送単元正420在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息包括首要通知PN，则开始广播该警报广播请求消息，其中，该与该警报广播请求消息重复的消息是在该警报广播请求消息前接收到的；或者，如果在该接收単元410接收到该警报广播请求消息后，该发送単元420正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息不包括PN，则继续或开始广播与该警报广播请求消息重复的消息。
可选地，在本发明实施例中，该发送单元420还用于如果该警报广播请求消息包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则丢弃与该警报广播请求消息重复的消息。可选地，在本发明实施例中，该发送单元420还用于如果该警报广播请求消息包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与该警报广播请求消息重复的消息，并在该广播与该警报广播请求消息重复的消息结束后，开始广播该警报广播请求消息。可选地，在本发明实施例中，该发送单元420还用于如果该警报广播请求消息不包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则在该广播与该警报广播请求消息重复的消息结束后，开始广播该警报广播请求消息。可选地，在本发明实施例中，该发送单元420还用于如果该警报广播请求消息不包括PN，且该警报广播请求消息的第一属性指示该警报广播请求消息不需要在用户端自动弹出，则丢弃该警报广播请求消息。 可选地，在本发明实施例中，该第一属性为该警报广播请求消息中的序列号信息的一项内容。可选地，在本发明实施例中，该装置还包括确定单元430，用于在该警报广播请求消息包括警报类型信息和警报安全信息的情况下，确定该警报广播请求消息包括PN。可选地，在本发明实施例中，该即将广播与该警报广播请求消息重复的消息指需要在第一时段内开始广播与该警报广播请求消息重复的消息；其中，该第一时段小于或等于该第一设备的收发转换时延，或者，该第一时段小于或等于该第一设备的消息读取时延。根据本发明实施例的传输信息的装置，通过根据两个维度(消息是否在用户端弹出以及是否包括PN)来确定对消息的处理方式，能够进一步确保地震海嘯的信息报警效果，并且，能够缓存某些ETWS消息并在合适的时机(非紧急状态)广播，从而能够有效保障报警效果。这样，根据本发明实施例的传输信息的装置，通过根据警报消息是否在用户端弹出来确定警报消息的紧急程度，并对重复的警报消息进行广播操作，能够避免紧急的警报消息被丢弃。根据本发明实施例的传输信息的装置400是本发明实施例的方法200中的实施主体，并且，该传输信息的装置400中的各单元及模块和上述其他操作和/或功能分别为了实现图2中的方法200的相应流程，为了简洁，在此不再赘述。应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和単元的具体工作过程，可以參考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另ー个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过ー些接ロ，装置或単元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的単元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理単元，即可以位于ー个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本发明各个实施例中的各功能単元可以集成在一个处理単元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。 所述功能如果以软件功能単元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在ー个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM, Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本发明的具体实施方式
，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。
权利要求
1.一种传输信息的方法，其特征在于，所述方法包括 第一设备接收警报广播请求消息； 如果所述第一设备在接收到所述警报广播请求消息后，正在广播或即将广播与所述警报广播请求消息重复的消息，且所述警报广播请求消息的第一属性指示所述警报广播请求消息需要在用户端自动弹出，则开始广播所述警报广播请求消息；或者，如果所述第一设备在接收到所述警报广播请求消息后，正在广播或即将广播与所述警报广播请求消息重复的消息，且所述第一属性指示所述警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与所述警报广播请求消息重复的消息； 其中，所述与所述警报广播请求消息重复的消息是所述第一设备在接收所述警报广播请求消息前接收到的。
2.根据权利要求I所述的方法，其特征在于，如果所述第一属性指示所述警报广播请求消息需要在用户端自动弹出，且所述警报广播请求消息包括首要通知PN，则所述方法还包括 丢弃与所述警报广播请求消息重复的消息。
3.根据权利要求I所述的方法，其特征在于，如果所述第一属性指示所述警报广播请求消息需要在用户端自动弹出，且所述警报广播请求消息不包括PN，则继续或开始广播与所述警报广播请求消息重复的消息，并在所述广播与所述警报广播请求消息重复的消息结束后，开始广播所述警报广播请求消息。
4.根据权利要求I所述的方法，其特征在于，如果所述第一属性指示所述警报广播请求消息不需要在用户端自动弹出，且所述警报广播请求消息包括PN，则在所述广播与所述警报广播请求消息重复的消息结束后，所述方法还包括 开始广播所述警报广播请求消息。
5.根据权利要求I所述的方法，其特征在于，如果所述第一属性指示所述警报广播请求消息不需要在用户端自动弹出，且所述警报广播请求消息不包括PN，则所述方法还包括 丢弃所述警报广播请求消息。
6.根据权利要求I至5中任一项所述的方法，其特征在于，所述第一属性为所述警报广播请求消息中的序列号信息的一项内容。
7.根据权利要求I至6中任一项所述的方法，其特征在于，所述即将广播与所述警报广播请求消息重复的消息指需要在第一时段内开始广播与所述警报广播请求消息重复的消息；其中，所述第一时段小于或等于所述第一设备的收发转换时延，或者，所述第一时段小于或等于所述第一设备的消息读取时延。
8.一种传输信息的方法，其特征在于，所述方法包括 第一设备接收警报广播请求消息； 如果所述第一设备在接收到所述警报广播请求消息后，正在广播或即将广播与所述警报广播请求消息重复的消息，且所述警报广播请求消息包括首要通知PN，则开始广播所述警报广播请求消息；或者，如果所述第一设备在接收到所述警报广播请求消息后，正在广播或即将广播与所述警报广播请求消息重复的消息，且所述警报广播请求消息不包括PN，则继续或开始广播与所述警报广播请求消息重复的消息；其中，所述与所述警报广播请求消息重复的消息是在所述警报广播请求消息前接收到的。
9.根据权利要求8所述的方法，其特征在于，如果所述警报广播请求消息包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息需要在用户端自动弹出，则所述方法还包括 丢弃与所述警报广播请求消息重复的消息。
10.根据权利要求8所述的方法，其特征在于，如果所述警报广播请求消息包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与所述警报广播请求消息重复的消息，并在所述广播与所述警报广播请求消息重复的消息结束后，开始广播所述警报广播请求消息。
11.根据权利要求8所述的方法，其特征在于，如果所述警报广播请求消息不包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息需要在用户端自动弹出，则在所述广播与所述警报广播请求消息重复的消息结束后，所述方法还包括 开始广播所述警报广播请求消息。
12.根据权利要求8所述的方法，其特征在于，如果所述警报广播请求消息不包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息不需要在用户端自动弹出，则所述方法还包括 丢弃所述警报广播请求消息。
13.根据权利要求9至12中任一项所述的方法，其特征在于，所述第一属性为所述警报广播请求消息中的序列号信息的一项内容。
14.根据权利要求8至13中任一项所述的方法，其特征在于，所述即将广播与所述警报广播请求消息重复的消息指需要在第一时段内开始广播与所述警报广播请求消息重复的消息；其中，所述第一时段小于或等于所述第一设备的收发转换时延，或者，所述第一时段小于或等于所述第一设备的消息读取时延。
15.一种传输信息的装置，其特征在于，所述装置包括 接收单元，用于接收警报广播请求消息； 发送单元，用于广播所述接收单元接收的警报广播请求消息； 其中，所述发送单元具体用于如果在所述接收单元接收到所述警报广播请求消息后，所述发送单元正在广播或即将广播与所述警报广播请求消息重复的消息，且所述警报广播请求消息的第一属性指示所述警报广播请求消息需要在用户端自动弹出，则开始广播所述警报广播请求消息；或者，如果在所述接收单元接收到所述警报广播请求消息后，所述发送单元正在广播或即将广播与所述警报广播请求消息重复的消息，且所述第一属性指示所述警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与所述警报广播请求消息重复的消息；其中，所述与所述警报广播请求消息重复的消息是所述接收单元在接收所述警报广播请求消息前接收到的。
16.根据权利要求15所述的装置，其特征在于，所述发送单元还用于如果所述第一属性指示所述警报广播请求消息需要在用户端自动弹出，且所述警报广播请求消息包括首要通知PN，则丢弃与所述警报广播请求消息重复的消息。
17.根据权利要求15所述的装置，其特征在于，所述发送单元还用于如果所述第一属性指示所述警报广播请求消息需要在用户端自动弹出，且所述警报广播请求消息不包括PN,则继续或开始广播与所述警报广播请求消息重复的消息，并在所述广播与所述警报广播请求消息重复的消息结束后，开始广播所述警报广播请求消息。
18.根据权利要求15所述的装置，其特征在于，所述发送单元还用于如果所述第一属性指示所述警报广播请求消息不需要在用户端自动弹出，且所述警报广播请求消息包括PN,则在所述广播与所述警报广播请求消息重复的消息结束后，开始广播所述警报广播请求消息。
19.根据权利要求15所述的装置，其特征在于，所述发送单元还用于如果所述第一属性指示所述警报广播请求消息不需要在用户端自动弹出，且所述警报广播请求消息不包括PN,则丢弃所述警报广播请求消息。
20.一种传输信息的装置，其特征在于，所述装置包括 接收单元，用于接收警报广播请求消息； 发送单元，用于广播所述接收单元接收的警报广播请求消息； 其中，所述发送单元具体用于如果在所述接收单元接收到所述警报广播请求消息后，所述发送单元正在广播或即将广播与所述警报广播请求消息重复的消息，且所述警报广播请求消息包括首要通知PN，则开始广播所述警报广播请求消息；或者，具体用于如果在所述接收单元接收到所述警报广播请求消息后，所述发送单元正在广播或即将广播与所述警报广播请求消息重复的消息，且所述警报广播请求消息不包括PN，则继续或开始广播与所述警报广播请求消息重复的消息；其中，所述与所述警报广播请求消息重复的消息是在所述警报广播请求消息前接收到的。
21.根据权利要求20所述的装置，其特征在于，所述发送单元还用于如果所述警报广播请求消息包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息需要在用户端自动弹出，则丢弃与所述警报广播请求消息重复的消息。
22.根据权利要求20所述的装置，其特征在于，所述发送单元还用于如果所述警报广播请求消息包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与所述警报广播请求消息重复的消息，并在所述广播与所述警报广播请求消息重复的消息结束后，开始广播所述警报广播请求消息。
23.根据权利要求20所述的装置，其特征在于，所述发送单元还用于如果所述警报广播请求消息不包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息需要在用户端自动弹出，则在所述广播与所述警报广播请求消息重复的消息结束后，开始广播所述警报广播请求消息。
24.根据权利要求20所述的装置，其特征在于，所述发送单元还用于如果所述警报广播请求消息不包括PN，且所述警报广播请求消息的第一属性指示所述警报广播请求消息不需要在用户端自动弹出，则丢弃所述警报广播请求消息。
全文摘要
本发明实施例提供一种传输信息的方法和装置，能够根据消息的紧急程度进行广播。该方法包括第一设备接收警报广播请求消息；如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该警报广播请求消息的第一属性指示该警报广播请求消息需要在用户端自动弹出，则开始广播该警报广播请求消息；或者，如果该第一设备在接收到该警报广播请求消息后，正在广播或即将广播与该警报广播请求消息重复的消息，且该第一属性指示该警报广播请求消息不需要在用户端自动弹出，则继续或开始广播与该警报广播请求消息重复的消息；其中，该与该警报广播请求消息重复的消息是该第一设备在接收该警报广播请求消息前接收到的。通过根据警报消息的紧急程度来广播重复的警报消息，能够避免紧急的警报消息被丢弃。
文档编号H04H20/59GK102771068SQ201280000620
公开日2012年11月7日 申请日期2012年5月9日 优先权日2012年5月9日
发明者梁冀天, 殷顺尧, 程勇, 龚长松 申请人:华为技术有限公司