CN101640573B - 接收紧急事件通知的方法、装置和系统 - Google Patents
接收紧急事件通知的方法、装置和系统 Download PDFInfo
- Publication number
- CN101640573B CN101640573B CN2008101345704A CN200810134570A CN101640573B CN 101640573 B CN101640573 B CN 101640573B CN 2008101345704 A CN2008101345704 A CN 2008101345704A CN 200810134570 A CN200810134570 A CN 200810134570A CN 101640573 B CN101640573 B CN 101640573B
- Authority
- CN
- China
- Prior art keywords
- emergency notification
- message
- request
- emergency
- receiving element
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
- G08B27/005—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations with transmission via computer network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
- H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency
Abstract
本发明的实施例公开了一种接收紧急事件通知的方法、装置和系统，涉及通信应用领域，只要用户终端与承载网络通信正常，无论是否在收看直播电视节目都可以及时接收到紧急事件通知。所述方法包括：接收单元发现紧急事件通知业务；接收单元附着到紧急事件通知业务；接收单元接收分发单元发送的紧急事件通知消息。所述紧急事件通知接收单元装置，包括：发现处理模块、附着处理模块和消息接收处理模块。本发明的实施例通过附着到紧急事件通知业务，使得用户终端可以及时接收到紧急事件通知。
Description
技术领域
本发明涉及通信应用领域，具体而言是涉及一种接收紧急事件通知的方法、装置和系统。
背景技术
IP多媒体子系统(IMS，IP Multimedia Subsystem)是3GPP(3rd GenerationPartnership Project，第三代移动通信标准化伙伴项目)标准定义的一种全新的多媒体业务形式，它能够满足现在的终端客户更新颖、更多样化多媒体业务的需求，是3G(3rd Generation)移动网实现分组语音和分组数据，提供统一的多媒体业务和应用的目标网络。
IMS采用IP分组域作为其控制信令和媒体传输的承载通道，采用SIP(Session Initiation Protocol，会话初始协议)协议作为呼叫控制信令，实现了业务管理、会话控制及承载接入的三者分离。
IPTV(Internet Protocol Television，因特网协议电视)业务是一种利用宽带IP网络，集互联网、多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。用户在家中可以使用PC或者网络机顶盒+普通电视机方式享受IPTV业务，也可以通过移动终端享受IPTV业务。IPTV使用TCP/IP作为承载协议进行单播、广播或组播视频业务，有效地将电视网、电话网和互联网三个领域结合在一起，是三网融合最具代表性的业务，正受到业界越来越多的关注。
IMS based IPTV(以IMS为基础的IPTV)就是在IMS的整体架构下提供IPTV业务，以充分利用IMS网络中已有的注册、认证、路由、会话控制与建立、业务触发、计费、端到端QoS(Quality of Service，服务质量)保证等机制来为用户提供流媒体业务，以及融合流媒体和实时会话业务的多媒体业务。
EAS(Emergency Alert System，紧急通知系统)，就是要实现及时准确地向公众发布紧急事件通知消息，例如气象灾害、地质灾害、毒气泄露、海啸预警、地震预警、动乱、战争等威胁生命及财产安全的紧急消息。对于IMS网络 及IMS based IPTV系统来说，需要有适当的机制向终端用户及时发布紧急事件通知，紧急事件通知消息的形式包括文本、音频、视频等。
传统电视的EAS业务，是通过改变内容源的方式来传递紧急事件通知消息，即采用网络侧切换内容源的方式来传递紧急事件通知消息，例如本地电视台暂停当前节目内容的播放，改为插播紧急事件通知消息，收看该频道的用户即可收看到该紧急事件通知消息。但是，如果用户正在收看的频道没有播放该紧急事件通知消息，则该用户不能及时得到紧急事件通知。例如，一用户正在收看外地的电视频道甚至外国的电视频道节目，此时，本地政府部门通过本地电视频道发布的紧急事件通知消息，则该用户就不能及时得到。而且，即使是在本地电视转播站将向本地用户传输的所有频道的内容源都切换成紧急事件通知消息，仍然只能是正在收看直播电视节目的用户才能接收到紧急事件通知消息。在交互式IPTV中，用户终端不仅可以收看直播电视节目，还可以点播(Video onDemand，VOD)节目，或操作电子节目菜单(Electronic Program Guide，EPG菜单)，玩游戏等，甚至可以是完全本地的操作，例如播放本地存储的节目，或进行视频通话等。这样，这些当时未收看直播电视节目、正在进行其它各种操作的用户也就不能收看到紧急事件通知消息。
在实现本发明过程中，发明人发现现有技术中至少存在这样的问题：未收看直播电视节目的用户终端不能及时接收到紧急事件通知。
发明内容
本发明实施例提供了一种接收紧急事件通知的方法、装置和系统，只要用户终端与承载网络通信正常，无论是否在收看直播电视节目都可以及时接收到紧急事件通知。
为实现上述目的，本发明实施例是通过如下技术方案实现的：
一种接收紧急事件通知的方法，包括以下步骤：
接收单元发现紧急事件通知业务；
接收单元附着到紧急事件通知业务；
接收单元接收分发单元发送的紧急事件通知消息。
一种紧急事件通知接收单元装置，包括：
发现处理模块，用于紧急事件通知业务的发现；
附着处理模块，用于紧急事件通知业务发现完成后，进行紧急事件通知业务的附着；
消息接收处理模块，用于接收紧急事件通知消息，并从紧急事件通知消息中获取紧急事件通知指示。
一种接收紧急事件通知的系统，包括：
分发单元，用于向接收单元发送紧急事件通知消息；
接收单元，用于发现紧急事件通知业务，并附着到紧急事件通知业务，接收分发单元发送的紧急事件通知消息。
上述接收紧急事件通知的方法、装置和系统中，如果接收单元获取的是分发单元用于发送紧急事件通知的多播地址信息，则接收单元向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着；或者如果接收单元获取的是分发单元间接的数据库服务器地址信息，则接收单元首先向该服务器发送查询消息，获取分发单元用于发送紧急事件通知消息的多播地址，再向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着。
本发明实施例还提供了一种发现紧急事件通知业务的方法，能够通过第三方注册的方式发现紧急事件通知业务。本发明实施例是通过如下技术方案实现的：
接收单元向呼叫会话控制功能CSCF发送IMS注册请求；
CSCF处理所述IMS注册请求后，向紧急通知系统应用服务器EAS AS发送第三方IMS注册请求；
EAS AS处理所述第三方IMS注册请求后，向接收单元发送紧急事件通知业务发现消息。
本发明实施例还提供了一种接收紧急事件通知媒体流的方法，能够保证传送媒体流需要的网络带宽资源。本发明实施例可以通过如下技术方案实现：
从紧急事件通知消息中获取紧急事件通知媒体流的网络参数，所述网络参 数包括多播地址信息，该多播地址信息为专用的特定的多播地址，或者为普通的多播地址；
发送加入所述多播地址信息对应多播组的请求消息，所述请求消息携带所述多播地址信息，或同时携带紧急指示；
多播复制控制点及复制点ECF/EFF处理所述多播组加入请求消息，向资源和准入控制子系统RACS请求预留承载资源，并根据识别出的所述多播地址或紧急指示，携带预留承载资源的优先级；
加入所述多播组接收紧急事件通知媒体流并播放输出。
本发明实施例还提供了一种加入紧急事件通知IPTV频道的方法，能够实现紧急事件通知频道的强行切换。本发明实施例是通过如下技术方案实现的：
从紧急事件通知消息中获取紧急事件通知的IPTV频道标识，所述IPTV频道标识为专用于紧急事件通知媒体流发送的特定的频道标识，或者为普通的频道标识；
发起紧急事件通知会话的建立请求，所述建立请求中携带所述IPTV频道标识，或同时携带紧急指示；
紧急呼叫会话控制功能E-CSCF处理所述紧急事件通知会话的建立请求，向资源和准入控制子系统RACS请求预留承载资源，并根据识别出的所述IPTV频道标识或紧急指示，携带预留承载资源的优先级；
紧急事件通知会话建立后，加入所述紧急事件通知的IPTV频道。
由以上技术方案可知，在接收单元发现紧急事件通知业务后，通过加入对应多播组完成紧急事件通知业务的附着，然后接收分发单元发送的紧急事件通知消息，使得用户终端无论是否在收看直播电视节目，只要用户终端与承载网络通信正常，都可以及时接收到紧急事件通知。
而且，通过提供紧急事件通知业务的带宽策略，使得IMS网络的终端无论在享受什么节目，例如观看IPTV节目或玩游戏，或观看终端本地保存的节目，或正在进行菜单操作，也不管在进行什么通信，例如进行视频通话，都可以及时接收到紧急事件通知。并且，可以在各种业务异常的情况下提供紧急事件通知业务，只要用户成功注册IMS网络，都可以接收到紧急事件通知业务；甚至 也能够做到在用户终端未成功注册IMS网络，或IMS网络注册失败、漫游限制等情况下，只要终端与承载网络的通信正常，都可以接收到紧急事件通知业务。
图1为本发明实施例适用的网络逻辑架构图；
图2为本发明实施例提供的接收紧急事件通知的方法的流程图；
图3为本发明实施例一提供的接收紧急事件通知的方法的流程图；
图4为本发明实施例二提供的接收紧急事件通知的方法的流程图；
图5为本发明实施例三提供的接收紧急事件通知的方法的流程图；
图6为本发明实施例四提供的接收紧急事件通知的方法的流程图；
图7为本发明实施例五提供的接收紧急事件通知的方法的流程图；
附图说明
图8为本发明实施例六提供的接收紧急事件通知的方法的流程图；
图9为本发明实施例提供的接收紧急事件通知媒体流的方法的流程图；
图10为本发明实施例提供的加入紧急事件通知IPTV频道的方法的流程图；
图11为本发明实施例提供的发现紧急事件通知业务的方法的流程图；
图12为本发明实施例提供的紧急事件通知接收单元装置的功能模块图；
图13为本发明实施例提供的紧急事件通知业务服务器装置的功能模块图；
图14为本发明实施例提供的紧急呼叫会话控制功能装置的功能模块图。
参见图1，为本发明实施例适用的网络逻辑架构图。如图1所示，其中：
具体实施方式
1)发布单元101用于发布紧急事件通知，为紧急事件通知的源头，向分发单元102发布紧急事件通知。
发布单元101通常位于各级政府部门的应急处理中心，在IMS网络中，发布单元101往往是IMS网络之外的设备，与IMS网络之间存在接口，接口协议通常由政府主管部门规定。
发布单元101与分发单元102之间的E4接口为信令接口，用于紧急事件通知发布的信令交互和控制，以及紧急事件通知消息的发送。例如，通过E4接口，发布单元101向分发单元102请求发布紧急事件通知，分发单元102对发布单元101进行认证。通过E4接口发送的紧急事件通知消息，携带紧急事件通知指示(包括紧急事件通知媒体流的地址)，指示消息的接收方如何获取紧急事件通知的媒体内容；通过E4接口也可传送文本方式的紧急事件通知内容等。E4接口协议由政府部门规定，可以是专用的协议，可以采用SIP、HTTP协议，其它标准协议或私有协议。
发布单元101与分发单元102之间的M2接口为媒体流接口，用于传送音视频方式的紧急事件通知，例如音视频媒体流，或音视频文件等，接口协议包括但不限于：RTP/RTCP协议，FTP协议，HTTP协议，其它标准协议或私有协议。
2)分发单元102用于向接收单元103分发紧急事件通知，在接收到发布单元101的紧急事件通知后，向接收单元103分发紧急事件通知。
分发单元102不仅进行信令层面的紧急事件通知消息的分发，还可完成媒体层面的紧急事件通知的下发，即音视频媒体流方式的紧急事件通知内容的分发。
在IMS网络中，分发单元102可以位于应用服务器AS，或媒体服务器MF，或多播业务中的多播复制的基本控制点及复制点ECF/EFF(Elementary ControlFunction/Elementary Forwarding Function)单个实体中；分发单元102还可以位于上述的AS和ECF/EFF，或AS和MF和ECF/EFF等多个实体中。
分发单元102也可以不是某一个或几个实体，而是一个网络，即有一个紧 急事件通知分发网络，该网络中，有部分实体与发布单元101有直接接口，另有部分实体与接收单元103有直接接口，还有部分实体与发布单元101或接收单元103没有直接接口，在网络中完成业务分发的作用。例如，在IMS网络中，包括P-CSCF、S-CSCF、I-CSCF在内的IMS Core，可以作为紧急事件通知分发网络，将紧急事件通知消息进行路由分发，最后分发到作为紧急事件通知接收单元103的用户终端设备UE。IMS Core完成信令层面的紧急事件通知分发，IMS控制的媒体网络完成媒体层面的紧急事件通知分发。
3)接收单元103用于附着到分发单元102上接收分发单元102分发的紧急事件通知，并进行紧急事件通知的处理及呈现。
在IMS网络中，接收单元103可以位于用户设备UE中。
接收单元103与分发单元102之间的E2接口为信令接口，用于紧急事件通知的信令交互和控制，以及紧急事件通知消息的发送，例如传送紧急事件通知指示，传送文本方式的紧急事件通知等。接口协议包括但不限于：承载于IP的专用协议、SIP协议，其它标准协议或私有协议。
接收单元103与分发单元102之间的M1接口为媒体流接口，用于音视频方式的紧急事件通知的传送，例如音视频媒体流，或音视频文件等，接口协议包括但不限于：RTP/RTCP协议，FTP协议，HTTP协议，其它标准协议或私有协议。
在具体的紧急事件通知发送过程中，M1接口可能不需要，例如，当紧急事件通知消息内容为文本方式时，文本方式的内容可以直接在E2接口上传送。
M1接口的使用，往往是根据E2接口上传送的的紧急事件通知指示，指示接收单元103从M1接口获取音视频方式的紧急事件通知，并在紧急事件通知指示中携带M1接口的相关参数，例如地址信息、媒体格式信息，或发送紧急事件通知的IPTV频道标识等。接收单元103根据该指示从M1接口接收音视频方式的紧急事件通知内容，并播放输出。
4)业务发现单元104用于紧急事件通知业务的发现，即用于获取分发单元102的相关信息，使得接收单元103能够附着到分发单元102接收紧急事件通知。
在IMS网络中，业务发现单元104可以位于网络附着子系统NASS、网关GPRS支持节点GGSN、呼叫会话控制功能CSCF、或应用服务器AS、或动态主机配置协议DHCP服务器、也可位于用户终端设备UE中等。
业务发现单元104与接收单元103之间的E1接口为直接接口或间接接口，用于传送紧急事件通知业务发现信息，例如向接收单元103传送分发单元102的地址信息等，接口协议包括但不限于：DHCP协议、Diameter协议，SIP协议，其它标准协议或私有协议。
业务发现单元104与接收单元103可以位于同一个物理实体中，例如都位于用户终端设备UE中，这种情况下，业务发现单元104与接收单元103之间的E1接口为内部接口。
由上所述，一个完整的紧急事件通知可能有两种情况。
A、紧急事件通知仅包含E2接口上传送的紧急事件通知消息，该紧急事件通知消息中可以携带便于在消息体中携带的字节数较少的紧急事件通知消息内容，例如文本方式的紧急事件通知消息内容。这种情况下，M1接口没有使用到。
B、紧急事件通知分为两部分，一部分是E2接口上传送的紧急事件通知消息，并在该通知消息中携带紧急事件通知指示；另一部分是M1接口上传送的紧急事件通知媒体流。这种情况下，E2接口上传送的紧急事件通知消息中携带紧急事件通知指示，该紧急事件通知指示中携带M1接口的相关参数，用于指示接收单元103从M1接口获取音视频方式的紧急事件通知。
参见图2，图2为本发明实施例提供的接收紧急事件通知的方法的流程图，包括：
步骤201，接收单元发现紧急事件通知业务。
所述接收单元发现紧急事件通知业务，就是指接收单元发现分发单元，即接收单元获取紧急事件通知分发单元的相关信息，包括分发单元的相关地址信息，也可以包括一些参数信息。本发明实施例中，紧急事件通知消息采用多播方式发送，要获取的分发单元的相关信息包括分发单元用于发送紧急事件通知的多播地址信息，或者分发单元间接的数据库服务器地址信息。接收单元使用 该分发单元的相关信息接收紧急事件通知消息。
如果接收单元获取的分发单元的相关信息是间接的信息，例如一个数据库服务器的地址，则接收单元先获取该间接的信息，进一步再获取分发单元的直接信息，例如先获取数据库服务器地址的信息，再向该数据库服务器获取分发单元的多播地址信息。
接收单元发现分发单元的方式包括：在接收单元物理实体上预置分发单元相关信息；或者接收单元与业务发现单元进行消息交互，获取分发单元的相关信息。前者是静态的发现过程，即在接收单元物理实体上静态的数据配置获取过程，后者是动态的发现过程，例如在网络附着过程中或网络附着完成后，或IMS注册过程中或IMS注册完成后动态发现分发单元。
静态的发现过程，就是在接收单元物理实体上预先静态设置分发单元的相关信息，例如设置分发单元用于发送紧急事件通知的多播地址信息，或间接的数据库服务器地址信息等。这种设置可以是用户自行设置，或终端设备交付用户使用前预置的。例如，如果传送紧急事件通知消息的多播地址为一个业界标准规定的知名多播地址，则可在终端设备中预置。这种静态的业务发现过程，发现单元与接收单元位于同一个物理实体内，业务发现单元提供用户输入界面或其他输入接口接收分发单元信息的设置。接收单元与业务发现单元之间的E1接口为一个物理实体内的内部接口，例如数据查询接口，接收单元使用该内部接口获取分发单元的信息，完成紧急事件通知业务发现。
动态的发现过程，就是在接收单元启动过程中，通过E1接口与业务发现单元进行消息交互，获取分发单元的相关信息。这里的消息交互包括PULL方式和PUSH方式，PULL方式就是接收单元通过E1接口向业务发现单元发送紧急事件通知业务发现请求消息，业务发现单元通过E1接口向接收单元发送紧急事件通知业务发现响应消息，消息中携带分发单元的相关信息，例如用于发送紧急事件通知消息的多播地址。PUSH方式就是业务发现单元通过E1接口向接收单元发送紧急事件通知业务发现指示消息，消息中携带分发单元的相关信息。
在IMS网络中，业务发现单元所处的位置有两种情况，一种情况是处于承载层，为承载网络中的一个实体或多个实体，另一种情况是处于业务层，为IMS 网络会话层或应用层的一个实体或多个实体，其中也可能包括承载层的实体。
对应地，在PULL方式的业务发现过程中，接收单元发送紧急事件通知业务发现请求消息有两种情况，一种情况是在承载网络中发送该请求，例如可以在网络附着过程中或网络附着完成后发送该请求，另一种情况是在业务层中发送该请求，例如可以在IMS注册过程中或IMS注册完成后发送该请求。即分别为承载网络层面的PULL方式业务发现过程(进一步又分为网络附着过程中的PULL方式业务发现过程和网络附着完成后的PULL方式业务发现过程)，和IMS层面的PULL方式业务发现过程(进一步又分为IMS注册过程中的PULL方式业务发现过程和IMS注册完成后的PULL方式业务发现过程)。
网络附着过程中的PULL方式业务发现过程，是指接收单元在网络附着过程中发送紧急事件通知业务发现请求，获取分发单元信息，完成网络附着过程的同时也完成了业务发现的过程。一般的网络附着过程为，接收单元向网络发送网络附着请求，例如动态主机配置协议(DHCP，Dynamic Host ConfigureProtocol)请求，该请求可以是广播方式发送，网络中处理网络附着请求的实体，例如DHCP服务器，接收到该网络附着请求，除了正常处理网络附着请求外，还获取分发单元的相关信息，例如用于发送紧急事件通知消息的多播地址信息，在向接收单元发送网络附着响应的消息中携带分发单元信息，这样，接收单元在完成网络附着的同时就完成了紧急事件通知业务发现。这个过程中，业务发现单元就位于网络中处理网络附着请求的实体中，例如DHCP服务器中。紧急事件通知业务发现请求就位于网络附着请求消息中，这个紧急事件通知业务发现请求可以是隐式的请求，也就是接收单元发送的网络附着请求中并不明确携带紧急事件通知业务发现请求，在处理网络附着请求的实体中额外增加了紧急事件通知业务发现的处理，并在网络附着响应消息中携带紧急事件通知业务发现信息。这个紧急事件通知业务发现请求，也可以是显式的请求，即在网络附着请求消息中明确携带了紧急事件通知业务发现请求指示。
因此，网络附着过程中的PULL方式紧急事件通知业务发现，紧急事件通知业务发现请求位于网络附着请求消息中，紧急事件通知业务发现响应位于网络附着响应消息中。
网络附着完成后的PULL方式业务发现过程，是指接收单元在网络附着完成后发送紧急事件通知业务发现请求，获取紧急事件通知业务发现信息，紧急事件通知业务发现过程在网络附着过程之后完成。例如，接收单元在网络附着完成后，向网络发送紧急事件通知业务发现请求，该请求可采用广播方式发送，网络中处理紧急事件通知业务发现的实体(即业务发现单元)处理该业务发现请求，回复紧急事件通知业务发现响应消息，消息中携带紧急事件通知业务发现信息。这个过程中，业务发现单元可以位于与处理网络附着的实体不同的独立实体中。
IMS注册过程中的PULL方式业务发现过程，是指接收单元在进行IMS注册过程中发送紧急事件通知业务发现请求，获取分发单元的相关信息，完成IMS注册的同时也就完成了业务发现的过程。一般的IMS注册过程为，接收单元获取P-CSCF地址后，向P-CSCF发送IMS注册请求消息(SIP Register消息)，IMS注册请求被路由到一个分配的S-CSCF后执行IMS注册，S-CSCF向接收单元回复IMS注册响应消息(SIP响应码消息)。处理IMS注册的实体，例如S-CSCF，接收到该IMS注册请求，除了正常处理IMS注册请求外，还获取分发单元的相关信息，例如用于发送紧急事件通知消息的多播地址信息，在向接收单元发送IMS注册响应的消息中携带紧急事件通知业务发现信息，这样，接收单元在完成IMS注册的同时就获取了紧急事件通知业务发现信息。这个过程中，业务发现单元就位于IMS网络中处理IMS注册请求的实体中，例如S-CSCF中。紧急事件通知业务发现请求就位于IMS注册请求消息中，这个紧急事件通知业务发现请求可以是隐式的请求，也就是接收单元发送的IMS注册请求中并不明确携带紧急事件通知业务发现请求，在处理IMS注册请求的实体中额外增加了紧急事件通知业务发现的处理，并在IMS注册响应消息中携带紧急事件通知业务发现信息。这个紧急事件通知业务发现请求，也可以是显式的请求，即在IMS注册请求消息中明确携带紧急事件通知业务发现请求指示。
因此，IMS注册过程中的PULL方式紧急事件通知业务发现，紧急事件通知业务发现请求位于IMS注册请求消息中，紧急事件通知业务发现响应位于IMS注册响应消息中。
IMS注册完成后的PULL方式业务发现过程，是指接收单元在IMS注册完成后发送紧急事件通知业务发现请求，获取紧急事件通知业务发现信息，紧急事件通知业务发现过程在IMS注册过程之后完成。例如，接收单元在IMS注册完成后，向网络发送紧急事件通知业务发现请求，该请求可发送给S-CSCF，S-CSCF根据一定的策略，例如初始过滤规则iFC，将该请求触发到处理紧急事件通知业务发现的实体(即业务发现单元)，例如AS，处理该业务发现请求，AS回复紧急事件通知业务发现响应消息，消息中携带紧急事件通知业务发现信息，该紧急事件通知业务发现响应消息经S-CSCF发送到接收单元。
PUSH方式的紧急事件通知业务发现，是在业务发现单元感知到接收单元后，向接收单元发送紧急事件通知业务发现指示消息。如前所述，IMS网络中，业务发现单元可以位于承载网络层，也可位于业务层。
在承载网络层，业务发现单元感知接收单元的方式包括，网络附着设备在成功处理接收单元的网络附着请求后，向业务发现单元发送接收单元的网络附着信息；或业务发现单元主动向网络附着设备查询完成网络附着的接收单元的信息；或业务发现单元就位于网络附着设备，通过实体内部接口获取接收单元的信息。
在业务层，业务发现单元感知接收单元的方式包括，处理IMS注册的实体在成功处理接收单元的IMS注册请求后，向业务发现单元发送接收单元的IMS注册信息；或业务发现单元主动向IMS注册实体订阅或查询完成IMS注册的接收单元信息；或业务发现单元就位于IMS注册实体，通过实体内部接口获取接收单元的IMS注册信息。
上述这些过程中，业务发现单元也需要获取紧急事件通知业务发现信息，这可以是在业务发现单元上预先配置的，也可以是业务发现处理过程中业务发现单元向外部数据库查询获取的。
紧急事件通知业务发现请求消息可以是DHCP请求消息，SIP Register消息，Diameter消息，RADIUS消息，其它专有消息等。
紧急事件通知业务发现指示消息可以是Diameter消息，SIP Message消息，RADIUS消息等。
接收单元获取到分发单元的相关信息后，可在随后进行紧急事件通知业务附着。
步骤202，接收单元附着到紧急事件通知业务。
接收单元附着到紧急事件通知业务，指的是做好接收单元能够接收紧急事件通知的准备，即业务附着后接收单元可以接收到分发单元发送的紧急事件通知消息。
具体是，接收单元通过步骤201获取紧急事件通知业务发现信息后，通过E2接口向分发单元发送紧急事件通知业务附着请求，附着到紧急事件通知业务。
本发明实施例中，紧急事件通知消息采用多播方式发送，接收单元附着到紧急事件通知业务的方式包括：
如果接收单元获取的是分发单元用于发送紧急事件通知的多播地址信息，则接收单元向分发单元发送加入对应多播组的请求消息，例如Internet组管理协议(IGMP，Internet Group Management Protocol)加入消息(即IGMP Join消息)，以准备接收使用该多播地址发送的紧急事件通知消息。并且，为了能随时接收到紧急事件通知消息，紧急事件通知接收单元加入该多播组后，不再退出该多播组。在接收单元重新启动或网络通信中断恢复后，接收单元需要重新加入该多播组，或在需要重新进行网络附着或IMS注册时，接收单元需要重新进行业务发现，重新进行业务附着，即重新加入到该多播组。或者，
如果接收单元获取的是分发单元间接的分发单元信息，例如一个数据库服务器的地址信息，则接收单元先获取该间接的信息，进一步再获取分发单元的直接信息，例如先获取数据库服务器地址的信息，再向该数据库服务器获取紧急事件通知分发单元的地址信息，在获取分发单元用于发送紧急事件通知消息的多播地址后，再向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着。
步骤203，接收单元接收分发单元发送的紧急事件通知消息。
在接收单元接收分发单元发送的紧急事件通知消息的步骤之前，所述方法还包括：分发单元接收发布单元发送的发布紧急事件通知的请求消息；根据所 述请求消息分发单元向接收单元分发紧急事件通知消息。即：
分发单元通过E4接口接收到发布单元发送的紧急事件通知发送请求后，通过E2接口向接收单元分发紧急事件通知消息。
在该步骤中，分发单元可以在发布单元通过E4接口发送的紧急事件通知消息的指示下，通过M2接口接收音视频方式的紧急事件通知，并在通过E2接口发送的紧急事件通知消息中携带紧急事件通知指示，指示接收单元通过M1接口接收音视频方式的紧急事件通知。
如果接收单元接收分发单元发送的紧急事件通知消息中携带紧急事件通知指示，则步骤203还包括：根据紧急事件通知消息中的紧急事件通知指示接收单元进行紧急事件通知的处理及呈现。即，
接收单元在接收到通过E2接口发送的紧急事件通知消息后，如果所述紧急事件通知消息中携带紧急事件通知指示，则接收单元通过M1接口接收音视频方式的紧急事件通知并进行呈现。
上述E4接口上传送的紧急事件通知消息和E2接口上传送的紧急事件通知消息可以不一致，M2接口上传送的音视频与M1接口上传送的音视频也可以不一致。E4接口和M2接口为IMS系统对外的接口，可能为政府部门规定的应急处理中心的统一接口，该统一接口可能可以连接除IMS网络之外的其他多种通信网络。E2接口和M1接口为IMS网络内的接口，在IMS网络内定义。分发单元可以在E4接口与E2接口之间，M2接口与M1接口之间进行格式转换，例如，M2接口上音视频编码为某一个格式，M1接口上传送的音视频编码可能转换为另一种格式；除此之外，分发单元还可以在传送方式上进行修改。例如，E4接口和M2接口是单播发送的，在E4接口上可以进行单播的媒体流协商，以建立M2媒体通道；E2接口和M1接口使用多播发送，在E2接口上则指示接收单元多播媒体流的地址，接收单元通过加入该多播组进行多播媒体流的接收。但是，E4接口与E2接口之间，以及M2接口与M1接口之间传送的业务层内容则需要保持一致，即紧急事件通知的内容本身不能改变。
分发单元通过E4接口接收到发布单元发送的紧急事件通知发布请求消息后，需要对发布单元进行认证。该认证可以是使用预置的策略和数据，对发布 单元的身份的合法性进行认证，以及对发布单元发布的紧急事件通知消息合法性进行认证。认证通过后，启动紧急事件通知的分发。
在本发明实施例中，E2接口采用多播方式发送紧急事件通知消息。这样，接收单元通过紧急事件通知业务发现获取了分发单元用于发送紧急事件通知消息的多播地址，并在紧急事件通知业务附着时已经加入了对应的多播组，则当分发单元使用该多播地址发送紧急事件通知消息时，接收单元就可以接收到紧急事件通知消息。
多播方式的紧急事件通知消息的发送，与单播方式相比，大大降低了对分发单元的处理性能的要求，也大大降低了对传送网络的带宽要求，采用多播方式也避免了单播方式需要在瞬间发送大量消息的情况。这样，就可以有效地避免分发单元处理能力过载，或传送网络拥塞的情况。
这里，接收单元在紧急事件通知业务附着时加入的多播组的多播地址(也就是紧急事件通知业务发现时获取的多播地址)，与分发单元发送紧急事件通知消息使用的多播地址必须一致。分发单元获取该多播地址可以有两种方式，一种是在分发单元上预先配置的，另一种方式是分发单元向外部数据库查询获取的。前一种方式，该预置的数据必须与业务发现单元上预置的数据保持一致，或与业务发现单元使用的外部数据库中的数据保持一致。后一种方式，分发单元使用的外部数据库上的数据必须与业务发现单元上预置的数据一致，或者与业务发现单元使用的外部数据库上的数据保持一致，或使用同一个外部数据库。
分发单元在进行紧急事件通知消息分发的过程中可以进行一定的过滤，例如根据地理位置进行过滤，过滤方法可以为：在发布单元发送的紧急事件通知消息中携带该紧急事件通知适用的地理区域编码列表，分发单元是由多个物理实体组成的网络，不同的物理实体可能位于不同的地理区域，则紧急事件通知消息分发到与上述地理区域编码列表相符合的地理区域的物理实体，再由这些物理实体发送到其所负责的与上述地理区域编码列表相符合的接收单元。
E2接口上传送的紧急事件通知消息中携带紧急事件通知指示，包括紧急事件通知的类型，例如有3种类型的紧急事件通知，分别是文本方式、文本+音频方式、音视频方式，紧急指示，以及如果需要使用M1接口传送音视频方式紧急 事件通知媒体流，还包括用于传送紧急事件通知媒体流的M1接口参数和音视频编解码方式等信息。
本发明实施例中M1接口可采用多播方式，这种情况下M1接口参数可以直接为用于发送音视频媒体流的多播地址信息。接收单元按照紧急事件通知指示加入对应的多播组，接收多播音视频媒体流，并播放输出。这个多播地址可以是专用的特定的多播地址，或普通的多播地址。
M1接口参数也可以是一个广播地址，这种情况下，接收单元按照紧急事件通知指示，从该广播地址接收音视频媒体流(例如调谐到对应的频率)，并播放输出。
M1接口参数也可以是其他的应用层地址，例如FTP地址或HTTP地址，这种情况下，接收单元需要按照紧急事件通知指示获取该地址指示的内容，例如使用FTP或HTTP获取音视频内容，并播放输出。
M1接口参数还可以是一个IPTV频道标识，接收单元按照紧急事件通知指示切换到该频道，接收并播放该频道的音视频媒体内容。这个IPTV频道标识可以是特定的频道标识，专门用于紧急事件通知媒体流的发送，或普通的频道标识。
如果M1接口参数是一个IPTV频道标识，则接收单元切换到该指示频道有如下的几种情况：
1)若接收单元正在播放所述IPTV频道标识所指示的频道的直播内容(不是时移内容)，则接收单元继续该频道的播放；
2)若接收单元正在播放所述IPTV频道标识所指示的频道的时移内容，则接收单元结束时移状态，切换到直播状态；
3)若接收单元正在播放与所述IPTV频道标识所指示的频道不同的另外一个频道的内容，且这两个频道属于同一个域，例如同属于一个拜访域或归属域，则接收单元进行频道切换，切换到所述IPTV频道标识所指示的频道；
4)接收单元正在播放与所述IPTV频道标识所指示的频道不同的另外一个频道的内容，且这两个频道属于不同的域，例如用户终端漫游到一个拜访域，但正在播放归属域某频道的内容，紧急事件通知指示信息中的频道标识为拜访域的频道标识，则接收单元停止所述另外一个频道的内容播放(可以是释放当 前业务，或暂停当前媒体流，或仅仅是不呈现该媒体流等)，向所述IPTV频道标识所在域发起所述IPTV频道标识所指示频道的播放请求；
5)接收单元正在播放VOD节目或本地节目，或者正在进行本地菜单操作，则接收单元停止或暂停当前节目或操作，发起直播节目业务请求，所述请求携带所述IPTV频道标识；
6)接收单元处于空闲状态，未播放任何直播频道节目，也未播放其他类型的节目，则接收单元发起直播节目业务请求，所述请求携带所述IPTV频道标识。
接收单元在处理紧急事件通知的呈现过程中，需要按照紧急事件通知消息中携带的紧急事件通知指示的要求进行配合处理，例如停止或暂停当前播放的节目，强行切换到M1接口上接收到的紧急事件通知音视频媒体流的播放，该强行切换操作不管当前用户是在播放IPTV节目，在进行视频通话，还是在玩游戏，在播放本地保存的节目，或在进行菜单操作等，目的是使用户及时获取紧急事件通知。这样的配合处理，可以是政府主管部门强制规定的，例如，IMS网络中，用户设备UE必须满足强制的紧急事件通知业务的相关标准，才能入网使用。
M1接口上传送音视频媒体流需要的网络带宽资源，应该得到保证，特别是M1接口参数直接为多播地址，接收单元直接加入到对应多播组的情况。并且，由于紧急事件通知业务的特殊性，需要能够逾越其他业务占用的带宽。如果用户正在使用占用带宽比较多的业务，没有剩余带宽或剩余带宽不足时，仍需要保证紧急事件通知业务的带宽，此时需要逾越正在使用的业务所占用的带宽，即需要进行动态的带宽调整，降低甚至剥夺其他业务使用的带宽，将这些带宽提供给紧急事件通知业务使用。
本发明实施例提供的紧急事件通知业务的带宽策略，有如下的几种实现方式：
1)紧急事件通知业务的带宽策略，可以是事先预置的，即预先设置到承载层的策略执行实体或策略决策实体，这种预先设置需要预先获取紧急事件通知业务媒体流的相关参数。例如，如果紧急事件通知采用多播方式发送，需要预先获取多播地址，在承载层的策略执行实体或策略决策实体上预先设置该多播地址的媒体流的带宽要求及优先级。
当该带宽策略预置到策略执行实体时，策略执行实体根据这些参数检测到紧急事件通知媒体流后，自动执行预先设置的策略，分配相应的带宽，并根据需要逾越其他业务的带宽。策略执行实体根据这些参数检测到紧急事件通知结束后(例如使用流量检测的方式)，自动释放分配的带宽，恢复被逾越的其他业务的带宽。
或者，当该带宽策略预置到承载层的策略决策实体时，策略决策实体可通过PUSH方式或PULL方式控制策略执行实体执行该带宽策略。例如，带宽策略设置到承载层的策略决策实体后，策略决策实体PUSH到其负责的所有策略执行实体，或策略执行实体向策略决策实体请求某业务的带宽策略时，策略决策实体在响应消息中同时携带紧急事件通知的带宽策略。
紧急事件通知业务的带宽策略，可以是分发单元感知到接收单元完成网络附着，或在处理接收单元的紧急事件通知业务附着过程中，下发到承载层的策略执行实体或策略决策实体的。例如，紧急通知系统应用服务器EAS AS感知到接收单元完成了网络附着，向承载层下发承载策略。
2)紧急事件通知业务的带宽策略，可以是在分发单元进行紧急事件通知分发过程中下发到承载层，即分发单元需要发送紧急事件通知媒体流时，向承载层下发承载策略，请求预留相应的带宽，并指示优先级，以根据需要逾越其他业务的带宽。分发单元在紧急事件通知结束时，向承载层下发承载策略，请求释放分配的相应的带宽，并恢复被逾越的其他业务的带宽。例如，EAS AS在处理紧急事件通知业务分发过程中向资源和准入控制子系统(RACS，Resource andAdmission Control Sub-sys-tem)请求预留带宽资源并指示资源的优先级，或ECF/EFF接收到紧急事件通知消息或接收到紧急事件通知视频媒体流后向RACS请求预留带宽资源并指示资源的优先级。
3)紧急事件通知业务的带宽策略，可以是分发单元接收到接收单元请求紧急事件通知媒体内容后，下发到承载层。例如，ECF/EFF接收到接收单元发送的加入多播组(用来发送紧急事件通知音视频媒体流的多播组)的IGMP Join消息后，向RACS请求预留带宽资源并指示资源的优先级。这里，ECF/EFF要能够识别该多播地址为紧急事件通知的多播地址，这可以是在IGMP Join消息中携 带紧急指示，或该多播地址为预置的特定的多播地址，或ECF/EFF接收到紧急事件通知消息后获取该多播地址为紧急事件通知媒体流的多播地址。
4)紧急事件通知业务的带宽策略，也可以是接收单元接收到紧急事件通知消息后，向承载层的策略执行实体，请求分配相应的带宽，并根据需要逾越其他业务的带宽。接收单元在紧急事件通知结束时，向承载层的策略执行实体，请求释放分配的相应的带宽，并恢复其他业务的带宽。例如，UE接收到紧急事件通知消息，消息中的紧急事件通知指示携带紧急指示和用于传送音视频媒体流的多播地址，UE向RACS请求预留带宽资源并指示资源的优先级。
5)紧急事件通知业务的带宽策略，还可以是接收单元接收到紧急事件通知接收消息后，发起紧急事件通知会话的建立，通过会话的建立进行带宽资源的预留，即在会话建立过程中通过CSCF与RACS的交互进行资源预留。这种情况下，紧急事件通知消息中携带的M1接口参数往往为一个IPTV频道标识，这个频道标识有两种情况，一种是该频道标识为特殊的频道标识，专门用来发送紧急事件通知媒体流，另一种情况是该频道标识为普通的频道标识，平时提供IPTV节目，在需要时用来发送紧急事件通知媒体流。接收单元发起建立的紧急事件通知会话为紧急会话，可以在会话建立请求消息中携带紧急指示，或网络侧呼叫会话控制功能(CSCF，Call Session Control Function)根据请求的频道标识识别为紧急会话建立请求，在向RACS请求预留带宽资源时可指示业务的优先级，以在需要时能够逾越其他业务占用的带宽，保证紧急事件通知媒体流的带宽。
本发明实施例给出了一种接收紧急事件通知的方法，在接收单元发现紧急事件通知业务后，通过附着到紧急事件通知业务，接收分发单元发送的紧急事件通知消息，而且在紧急事件通知消息中携带紧急事件通知指示时，根据紧急事件通知指示接收单元进行相应的紧急事件通知的处理及呈现。本发明实施例提供的方法，分发单元使用多播方式进行紧急事件通知消息的分发，可以有效避免紧急事件通知业务发送时可能出现的消息风暴导致的承载网络拥塞及消息发送单元处理能力过载等问题，通过接收单元附着到分发单元的多播地址接收紧急事件通知消息，使得用户终端无论是否在收看直播电视节目，只要用户终 端与承载网络通信正常，都可以及时接收到紧急事件通知。。
在本发明实施例提供的方法中，通过提供的紧急事件通知业务的带宽策略，使得IMS网络的终端无论在享受什么节目，例如观看IPTV节目或玩游戏，或观看终端本地保存的节目，或正在进行菜单操作，也不管在进行什么通信，例如进行视频通话，都可以及时接收到紧急事件通知。并且，可以在各种业务异常的情况下提供紧急事件通知业务，例如在用户欠费或停机，未使用IPTV业务状态、漫游状态等各种状态下，只要用户成功注册IMS网络，都可以接收到紧急事件通知业务；甚至也能够做到在用户终端未成功注册IMS网络，或IMS网络注册失败、漫游限制等情况下，只要终端与承载网络的通信正常，都可以接收到紧急事件通知业务。
下面以具体的实施例对本发明实施例提供的接收紧急事件通知的方法作进一步的说明。
实施例一：
参见图3，图3为本发明实施例一提供的接收紧急事件通知的方法的流程图，本发明实施例一中，政府部门应急处理中心设备EAS Center是紧急事件通知的发布单元，IMS网络中EAS应用服务器EAS AS和EAS媒体服务器EAS MF及多播复制控制点及复制点ECF/EFF为紧急事件通知的分发单元，DHCP服务器(DHCPServer)为紧急事件通知的业务发现单元，用户设备UE是紧急事件通知的接收单元。
步骤301，UE向DHCP Server发送网络附着请求(DHCP Request)。
步骤302，DHCP Server向UE返回网络附着响应消息(DHCP Response)，所述响应消息中携带紧急事件通知业务发现信息。
在实施例一中，UE是在网络附着过程中完成紧急事件通知业务的发现。
这里，紧急事件通知消息采用多播方式传送，紧急事件通知业务发现信息为用于发送紧急事件通知消息的多播地址。
步骤303，UE向ECF/EFF发送IGMP Join消息。
UE获取该多播地址后，加入对应多播组，完成紧急事件通知业务附着，准备接收紧急事件通知消息。
步骤304，EAS Center向EAS AS发送发布紧急事件通知的请求消息(EASRequest)。
本发明实施例中，紧急事件通知包括音视频媒体流，EAS Center发送的发布紧急事件通知的请求消息中携带紧急事件通知指示，指示需要接收音视频媒体流。
步骤305，EAS AS向EAS MF发送接收和分发紧急事件通知媒体流的请求消息(EAS Request)。
步骤306，EAS AS向EAS Center发送发布紧急事件通知请求的响应消息(EASResponse)。
这里，EAS AS可以对EAS Center进行认证，所述认证包括对EAS Center的身份合法性进行认证，以及对EAS Center发布的紧急事件通知消息合法性进行认证。
步骤307，EAS AS接收EAS Center发布的紧急事件通知消息(EAS Message)。
步骤308，EAS AS将该紧急事件通知消息(EAS Message)分发到ECF/EFF。
步骤309，UE从ECF/EFF中接收到该紧急事件通知消息(EAS Message)。
步骤310，UE向ECF/EFF发送IGMP Join消息。
UE按照紧急事件通知消息中的紧急事件通知指示，获取用于发送紧急事件通知媒体流的多播地址，加入到该紧急事件通知媒体流对应的多播组，以接收音视频方式的紧急事件通知。
步骤311，ECF/EFF与RACS交互进行资源预留。
具体步骤为：ECF/EFF处理所述多播组加入请求消息，向资源和准入控制子系统RACS请求预留承载资源，并根据识别出的多播地址或紧急指示，携带预留承载资源的优先级。
这里，音视频媒体流的多播地址可以是特定的多播地址，ECF/EFF识别该特定的多播地址后，与RACS交互进行资源预留时，携带申请的资源的优先级，指示在带宽不足时逾越其他业务占用的带宽。该多播地址也可以是普通的多播地址，UE发送的IGMP Join消息中携带紧急指示，ECF/EFF根据该紧急指示，确定申请的资源的优先级。
步骤312，EAS MF从EAS Center接收发布的紧急事件通知媒体流(EASMedia)。
步骤313，EAS MF将该紧急事件通知媒体流(EAS Media)分发到ECF/EFF。
步骤314，UE从ECF/EFF中接收到该紧急事件通知媒体流(EAS Media)，并播放输出。
实施例二：
参见图4，图4为本发明实施例二提供的接收紧急事件通知的方法的流程图，本发明实施例二中，政府部门应急处理中心设备EAS Center是紧急事件通知的发布单元，IMS网络中EAS应用服务器EAS AS和EAS媒体服务器EAS MF及多播复制控制点及复制点ECF/EFF为紧急事件通知的分发单元，EAS Finder为紧急事件通知的业务发现单元，用户设备UE是紧急事件通知的接收单元。
步骤401，UE向EAS Finder发送紧急事件通知业务发现请求消息(EAS FindRequest)。
步骤402，EAS Finder向UE回复紧急事件通知业务发现响应消息(EAS FindResponse)，消息中携带紧急事件通知业务发现信息。
本发明实施例二中，用户设备UE在完成网络附着后进行紧急事件通知业务的发现，可以采用发送广播方式的紧急事件通知业务发现请求消息，处理紧急事件通知业务发现的实体EAS Finder处理该广播消息。
这里，紧急事件通知消息采用多播方式传送，紧急事件通知业务发现信息为用于发送紧急事件通知消息的多播地址。
步骤403，UE向ECF/EFF发送IGMP Join消息。
UE从接收到的紧急事件通知业务发现信息中，获取该多播地址后，加入对应多播组，完成紧急事件通知业务附着，准备接收紧急事件通知消息。
步骤404，EAS Center向EAS AS发送发布紧急事件通知的请求消息(EASRequest)。
本发明实施例中，紧急事件通知包括音视频媒体流，EAS Center发送的发布紧急事件通知的请求消息中携带紧急事件通知指示，指示需要接收音视频媒体流。
步骤405，EAS AS向EAS MF发送接收和分发紧急事件通知媒体流的请求(MFRequest)。
步骤406，EAS AS向EAS Center返回发布紧急事件通知请求的响应消息(EASResponse)。
这里，EAS AS可以对EAS Center进行认证，所述认证包括对EAS Center的身份合法性进行认证，以及对EAS Center发布的紧急事件通知消息合法性进行认证。
步骤407，EAS AS接收EAS Center发布的紧急事件通知消息(EAS Message)。
步骤408，EAS AS将该紧急事件通知消息(EAS Message)分发到ECF/EFF。
步骤409，ECF/EFF与RACS交互进行资源预留。
该步骤具体为：ECF/EFF接收到紧急事件通知消息(EAS Message)后，根据紧急事件通知指示中携带的音视频媒体流的参数与RACS交互预留承载资源。这里，ECF/EFF是通过识别出紧急事件通知消息，在与RACS交互进行资源预留时，携带申请的资源的优先级，指示在带宽不足时逾越其他业务占用的带宽。
步骤410，UE从ECF/EFF中接收到该紧急事件通知消息(EAS Message)。
步骤411，EAS MF从EAS Center接收发布的紧急事件通知媒体流(EASMedia)。
步骤412，EAS MF将接收到的紧急事件通知媒体流(EAS Media)分发到ECF/EFF。
步骤413，UE向ECF/EFF发送IGMP Join消息。
UE按照紧急事件通知消息中的紧急事件通知指示，获取用于发送紧急事件通知媒体流的多播地址，加入该紧急事件通知媒体流对应的多播组，接收音视频方式的紧急事件通知。
步骤414，UE从ECF/EFF中接收到该紧急事件通知媒体流(EAS Media)，并播放输出。
实施例三：
参见图5，图5为本发明实施例三提供的接收紧急事件通知的方法的流程图，本发明实施例三中，政府部门应急处理中心设备EAS Center是紧急事件通知的 发布单元，IMS网络中EAS应用服务器EAS AS和EAS媒体服务器EAS MF及多播复制控制点及复制点ECF/EFF为紧急事件通知的分发单元，EAS Finder和DHCPServer为紧急事件通知的业务发现单元，用户设备UE是紧急事件通知的接收单元。
步骤501，DHCP Server处理完UE的网络附着后主动向EAS Finder上报UE的网络附着完成的状态信息(Network Attachment Announce)。
本发明实施例三中，用户设备UE与DHCP Server完成网络附着后进行紧急事件通知业务的发现，这里是PUSH方式的紧急事件通知业务发现，用于紧急事件通知业务发现的实体EAS Finder感知到UE完成网络附着后(这里具体是DHCPServer处理完用户的网络附着后主动上报给EAS Finder)，主动向UE发送紧急事件通知业务发现指示信息。
步骤502，EAS Finder主动向UE发送紧急事件通知业务发现指示信息(EASService Announce)。
这里，紧急事件通知消息采用多播方式传送，紧急事件通知业务发现信息为用于发送紧急事件通知消息的多播地址。
步骤503，UE向EAS Finder返回紧急事件通知业务发现指示的响应信息(EASService Response)。
步骤504，UE向ECF/EFF发送IGMP Join消息。
UE从接收到的紧急事件通知业务发现信息中，获取该多播地址后，请求加入对应多播组，完成紧急事件通知业务附着，准备接收紧急事件通知消息。
步骤505，EAS Center向EAS AS发送发布紧急事件通知的请求消息(EASRequest)。
本发明实施例中，紧急事件通知包括音视频媒体流，EAS Center发送的发布紧急事件通知的请求消息中携带紧急事件通知指示，指示需要接收音视频媒体流。
步骤506，EAS AS向EAS MF发送接收和分发紧急事件通知媒体流的请求(MFRequest)。
步骤507，EAS AS向EAS Center返回发布紧急事件通知请求的响应消息(EAS Response)。
步骤508，EAS AS接收EAS Center发布的紧急事件通知消息(EAS Message)。
步骤509，EAS AS将该紧急事件通知消息(EAS Message)分发到ECF/EFF。
步骤510，UE从ECF/EFF中接收到该紧急事件通知消息(EAS Message)。
步骤511，EAS MF从EAS Center接收发布的紧急事件通知媒体流(EASMedia)。
步骤512，EAS MF将接收到的紧急事件通知媒体流(EAS Media)分发到ECF/EFF。
步骤513，ECF/EFF与RACS交互进行资源预留。
该步骤具体为：ECF/EFF接收到紧急事件通知媒体流后，与RACS交互预留承载资源。这里，ECF/EFF是在接收到紧急事件通知消息后，从紧急事件通知指示中获取了发送紧急事件通知媒体流的多播地址，当该多播地址的媒体流到来时，与RACS交互进行资源预留，并携带申请的资源的优先级，指示在带宽不足时逾越其他业务占用的带宽。
步骤514，UE向ECF/EFF发送IGMP Join消息。
UE按照紧急事件通知消息中的紧急事件通知指示，获取用于发送紧急事件通知媒体流的多播地址，加入该紧急事件通知媒体流对应的多播组，以接收音视频方式的紧急事件通知。
步骤515，UE从ECF/EFF中接收到该紧急事件通知媒体流(EAS Media)，并播放输出。
实施例四：
参见图6，图6为本发明实施例四提供的接收紧急事件通知的方法的流程图，本发明实施例四中，政府部门应急处理中心设备EAS Center是紧急事件通知的发布单元，IMS网络中EAS应用服务器EAS AS和EAS媒体服务器EAS MF及多播复制控制点及复制点ECF/EFF为紧急事件通知的分发单元，呼叫会话控制功能CSCF和EAS AS为紧急事件通知的业务发现单元，用户设备UE是紧急事件通知的接收单元。
步骤601，UE向CSCF发送IMS注册请求消息(Register)。
步骤602，CSCF向UE返回200OK消息，完成UE的IMS注册。
步骤603，CSCF向EAS AS发送第3方IMS注册请求消息(Register)。
步骤604，EAS AS向CSCF返回200OK消息，完成第3方的IMS注册。
步骤605，EAS AS主动向UE发送紧急事件通知业务发现指示消息(Message)。
本发明实施例四中，用户设备UE在IMS注册过程中，通过第3方注册进行紧急事件通知业务的发现，这里业务发现为PUSH方式业务发现。CSCF处理UE的IMS注册请求后，向EAS AS发送第3方注册请求，EAS AS处理第3方注册后，主动向UE发送紧急事件通知业务发现指示消息。
这里，紧急事件通知消息采用多播方式传送，紧急事件通知业务发现信息为用于发送紧急事件通知消息的多播地址。
步骤606，UE向ECF/EFF发送IGMP Join消息。
UE从接收到的紧急事件通知业务发现信息中，获取该多播地址后，加入对应多播组，完成紧急事件通知业务附着，准备接收紧急事件通知消息。
步骤607，EAS Center向EAS AS发送发布紧急事件通知的请求消息(EASRequest)。
本发明实施例中，紧急事件通知包括音视频媒体流，EAS Center发送的发布紧急事件通知的请求消息中携带紧急事件通知指示，指示需要接收音视频媒体流。
步骤608，EAS AS向EAS MF发送接收和分发紧急事件通知媒体流的请求(MFRequest)。
步骤609，EAS AS向EAS Center返回发布紧急事件通知请求的响应消息(EASResponse)。
步骤610，EAS AS接收EAS Center发布的紧急事件通知消息(EAS Message)。
步骤611，EAS AS向承载层下发带宽策略。
该步骤具体为：EAS AS接收到紧急事件通知消息后，根据紧急事件通知指示中携带的音视频媒体流的参数向承载层下发带宽策略，指示紧急事件通知音视频媒体流的带宽要求及优先级，这里，带宽策略可以下发到RACS，由RACS完成承载资源预留，并在带宽不足时逾越其他业务占用的带宽。
步骤612，EAS AS将该紧急事件通知消息(EAS Message)分发到ECF/EFF。
步骤613，UE从ECF/EFF中接收到该紧急事件通知消息(EAS Message)。
步骤614，EAS MF从EAS Center接收发布的紧急事件通知媒体流(EASMedia)。
步骤615，EAS MF将接收到的紧急事件通知媒体流(EAS Media)分发到ECF/EFF。
步骤616，UE向ECF/EFF发送IGMP Join消息。
UE按照紧急事件通知消息中的紧急事件通知指示，获取用于发送紧急事件通知媒体流的多播地址，加入到该紧急事件通知媒体流对应的多播组，以接收音视频方式的紧急事件通知。
步骤617，UE从ECF/EFF中接收到该紧急事件通知媒体流(EAS Media)，并播放输出。
实施例五：
参见图7，图7为本发明实施例五提供的接收紧急事件通知的方法的流程图，本发明实施例五中，政府部门应急处理中心设备EAS Center是紧急事件通知的发布单元，IMS网络中EAS应用服务器EAS AS和EAS媒体服务器EAS MF及多播复制控制点及复制点ECF/EFF及紧急呼叫会话控制功能E-CSCF为紧急事件通知的分发单元，DHCP Server为紧急事件通知的业务发现单元，用户设备UE是紧急事件通知的接收单元。
步骤701，UE向DHCP Server发送网络附着请求消息(DHCP Request)。
步骤702，DHCP Server向UE返回网络附着请求响应消息(DHCP Response)，所述响应消息中携带紧急事件通知业务发现信息。
本发明实施例五中，用户设备UE是在网络附着过程中完成紧急事件通知业务的发现。
这里，紧急事件通知消息采用多播方式传送，紧急事件通知业务发现信息为用于发送紧急事件通知消息的多播地址。
步骤703，UE向ECF/EFF发送IGMP Join消息。
UE从接收到的紧急事件通知业务发现信息中，获取该多播地址后，加入对 应多播组，完成紧急事件通知业务附着，准备接收紧急事件通知消息。
步骤704，EAS Center向EAS AS发送发布紧急事件通知的请求消息(EASRequest)。
本发明实施例中，紧急事件通知包括音视频媒体流，EAS Center发送的发布紧急事件通知的请求消息中携带紧急事件通知指示，指示需要接收音视频媒体流。
步骤705，EAS AS向EAS MF发送接收和分发紧急事件通知媒体流的请求(MFRequest)。
步骤706，EAS AS向EAS Center返回发布紧急事件通知请求的响应消息(EASResponse)。
步骤707，EAS AS接收EAS Center发布的紧急事件通知消息(EAS Message)。
步骤708，EAS AS将该紧急事件通知消息(EAS Message)分发到ECF/EFF。
步骤709，UE从ECF/EFF中接收到该紧急事件通知消息(EAS Message)。
本发明实施例中，紧急事件通知包括音视频媒体流，紧急事件通知消息中携带紧急事件通知指示，这里紧急事件通知指示中的M1接口参数为紧急事件通知频道标识，指示UE切换到指示的频道接收音视频媒体流。
步骤710，EAS MF从EAS Center接收发布的紧急事件通知媒体流(EASMedia)。
步骤711，EAS MF将接收到的紧急事件通知媒体流(EAS Media)分发到ECF/EFF。
步骤712，UE发起紧急事件通知会话的建立请求消息(Invite)，请求消息中携带紧急事件通知频道标识，并可携带紧急指示。
步骤713，E-CSCF与RACS交互进行资源预留。
该步骤具体为：E-CSCF处理所述紧急事件通知会话的建立请求，向RACS请求预留承载资源，并根据识别出的所述IPTV频道标识或紧急指示，携带预留承载资源的优先级。这里，发送紧急事件通知媒体流的频道标识可以为特定的频道标识，E-CSCF识别该特定的频道标识，与RACS交互进行资源预留过程中，携带申请的资源的优先级，指示在带宽不足时逾越其他业务占用的带宽。或该频 道标识为普通频道标识，UE发送的会话建立请求消息中携带紧急指示，E-CSCF根据该紧急指示，确定申请的资源的优先级。
步骤714，E-CSCF向EAS AS转发紧急事件通知会话的建立请求消息(Invite)。
步骤715，EAS AS向E-CSCF返回200OK响应消息，所述响应消息中携带所述紧急事件通知IPTV频道的多播地址。
步骤716，E-CSCF将所述200OK响应消息发送至UE，完成紧急事件通知会话的建立。
步骤717，UE向ECF/EFF发送IGMP Join消息。
UE接收到紧急会话响应消息，建立紧急会话，从响应消息中获取紧急事件通知IPTV频道的多播地址，加入该多播地址对应的多播组，以接收音视频媒体流。
步骤718，UE从ECF/EFF中接收该IPTV频道发送的紧急事件通知媒体流并播放输出。
注意，在本发明实施例五中，UE尚未进行IMS注册，或IMS注册失败都可以接收紧急事件通知，这是通过紧急会话实现的。具体是通过紧急事件通知频道标识信息或会话中的紧急会话标识，网络侧对该会话作紧急的特殊处理，允许未注册用户发起紧急会话，并经过E-CSCF、EAS AS的处理，完成紧急会话的建立。
实施例六：
参见图8，图8为本发明实施例六提供的接收紧急事件通知的方法的流程图，本发明实施例六中，政府部门应急处理中心设备EAS Center是紧急事件通知的发布单元，IMS网络中EAS应用服务器EAS AS和EAS媒体服务器EAS MF及多播复制控制点及复制点ECF/EFF为紧急事件通知的分发单元，呼叫会话控制功能CSCF为紧急事件通知的业务发现单元，用户设备UE是紧急事件通知的接收单元。
步骤801，UE向CSCF发送IMS注册请求消息(Register)。
步骤802，CSCF向UE返回IMS注册响应消息(200OK)，消息中携带紧急事件通知业务发现信息。
本发明实施例六中，用户设备UE是在IMS注册过程中完成紧急事件通知业务的发现。
这里，紧急事件通知消息采用多播方式传送，紧急事件通知业务发现信息为用于发送紧急事件通知消息的多播地址。
步骤803，UE向ECF/EFF发送IGMP Join消息。
UE从接收到的紧急事件通知业务发现信息中，获取该多播地址后，加入对应多播组，完成紧急事件通知业务附着，准备接收紧急事件通知消息。
步骤804，EAS Center向EAS AS发送发布紧急事件通知的请求消息(EASRequest)。
本发明实施例中，紧急事件通知包括音视频媒体流，EAS Center发送的发布紧急事件通知的请求消息中携带紧急事件通知指示，指示需要接收音视频媒体流。
步骤805，EAS AS向EAS MF发送接收和分发紧急事件通知媒体流的请求(MFRequest)。
步骤806，EAS AS向EAS Center返回发布紧急事件通知请求的响应消息(EASResponse)。
步骤807，EAS AS接收EAS Center发布的紧急事件通知消息(EAS Message)。
步骤808，EAS AS将该紧急事件通知消息(EAS Message)分发到ECF/EFF。
步骤809，UE从ECF/EFF中接收到该紧急事件通知消息(EAS Message)。
步骤810，EAS MF从EAS Center接收发布的紧急事件通知媒体流(EASMedia)。
步骤811，EAS MF将接收到的紧急事件通知媒体流(EAS Media)分发到ECF/EFF。
步骤812，UE与RACS交互进行资源预留。
该步骤具体为：UE接收到紧急事件通知消息后，根据紧急事件通知指示获取需要接收音视频方式的紧急事件通知媒体流，向RACS请求预留承载资源，并携带申请的资源的优先级，指示在带宽不足时逾越其他业务占用的带宽。
步骤813，UE向ECF/EFF发送IGMP Join消息。
UE按照紧急事件通知消息中的紧急事件通知指示，获取用于发送紧急事件通知媒体流的多播地址，加入该紧急事件通知媒体流对应的多播组，以接收音视频方式的紧急事件通知。
步骤814，UE从ECF/EFF中接收到该紧急事件通知媒体流(EAS Media)，并播放输出。
为此，在以上本发明实施例提供的接收紧急事件通知的方法及具体实施例的基础上，本发明实施例还提供了一种接收紧急事件通知媒体流的方法，参见图9，图9为本发明实施例提供的接收紧急事件通知媒体流的方法的流程图，包括：
步骤901，接收单元从紧急事件通知消息中获取紧急事件通知媒体流的网络参数，所述网络参数包括多播地址信息，该多播地址信息可以为专用的特定的多播地址，或者为普通的多播地址。
步骤902，接收单元发送加入所述多播地址信息对应多播组的请求消息，所述请求消息携带所述多播地址信息，或同时携带紧急指示。
步骤903，多播复制控制点及复制点ECF/EFF处理所述多播组加入请求消息，向资源和准入控制子系统RACS请求预留承载资源，并根据识别出的所述多播地址或紧急指示，携带预留承载资源的优先级。
步骤904，接收单元加入所述多播组接收紧急事件通知媒体流并播放输出。
其中，所述ECF/EFF向RACS请求预留承载资源的步骤可以在：
ECF/EFF处理所述多播组加入请求消息时向RACS请求预留承载资源；或者，
ECF/EFF接收到所述紧急事件通知消息时向RACS请求预留承载资源；或者，
ECF/EFF接收到所述紧急事件通知媒体流时向RACS请求预留承载资源。
带宽策略的步骤903还可以为：
紧急通知系统应用服务器EAS AS在接收到紧急事件通知消息后，根据所述紧急事件通知媒体流的网络参数，向承载层请求预留承载资源，所述请求中携带预留承载资源的优先级。或者，
接收单元根据所述获取的紧急事件通知媒体流的网络参数，向资源和准入控制子系统RACS请求预留承载资源，所述请求中携带预留承载资源的优先级。
本发明实施例还提供了一种加入紧急事件通知IPTV频道的方法，参见图10，图10为本发明实施例提供的加入紧急事件通知IPTV频道的方法的流程图，包括：
步骤1010，接收单元从紧急事件通知消息中获取紧急事件通知的IPTV频道标识，所述IPTV频道标识可以为专用于紧急事件通知媒体流发送的特定的频道标识，或者为普通的频道标识。
步骤1020，接收单元发起紧急事件通知会话的建立请求，所述建立请求中携带所述IPTV频道标识，或同时携带紧急指示。
步骤1030，紧急呼叫会话控制功能E-CSCF处理所述紧急事件通知会话的建立请求，向资源和准入控制子系统RACS请求预留承载资源，并根据识别出的所述IPTV频道标识或紧急指示，携带预留承载资源的优先级。
步骤1040，紧急呼叫会话控制功能E-CSCF向紧急通知系统应用服务器EASAS转发紧急事件通知会话的建立请求。
步骤1050，紧急呼叫会话控制功能E-CSCF接收并转发紧急通知系统应用服务器EAS AS返回的响应消息，所述响应消息中携带所述紧急事件通知IPTV频道的多播地址。
步骤1060，接收单元接收所述紧急事件通知会话建立请求的响应消息，加入所述响应消息中携带的多播地址对应的多播组，接收该IPTV频道发送的紧急事件通知媒体流并播放输出。
本发明实施例还提供了一种发现紧急事件通知业务的方法，参见图11，图11为本发明实施例提供的发现紧急事件通知业务的方法的流程图，包括：
步骤1110，接收单元向呼叫会话控制功能CSCF发送IMS注册请求。
步骤1120，呼叫会话控制功能CSCF处理所述IMS注册请求后，向紧急通知系统应用服务器EAS AS发送第三方IMS注册请求。
步骤1130，EAS AS处理所述第三方IMS注册请求后，向接收单元发送紧急事件通知业务发现消息。
所述的发现消息包括发送紧急事件通知消息的多播地址信息，或者发送紧急事件通知消息的间接的数据库服务器地址信息，用于指示消息的接收方如何 附着到紧急事件通知业务。
本发明实施例还提供了一种接收紧急事件通知的系统，参见图1，包括：
分发单元102，用于向接收单元103发送紧急事件通知消息；
接收单元103，用于发现紧急事件通知业务，并附着到紧急事件通知业务，接收分发单元102发送的紧急事件通知消息。
所述分发单元102可为一个实体，或者为几个实体，或者为一个分发网络。
例如，分发单元102可以为如下之一及其组合：
应用服务器AS，用于接收紧急事件通知消息，并从紧急事件通知消息中获取紧急事件通知指示；分发紧急事件通知消息；并根据紧急事件通知指示控制媒体服务器MF接收和分发紧急事件通知媒体流；
媒体服务器MF，用于接收和分发紧急事件通知媒体流；
基本控制功能及复制功能ECF/EFF，用于多播业务中的多播复制和控制。
所述分发单元102还可以包括：
紧急呼叫会话控制功能E-CSCF，用于通过识别会话建立请求中携带的频道标识为紧急频道标识，或者通过识别会话建立请求中携带的紧急指示，识别会话建立请求为紧急频道加入请求消息；并在识别出紧急频道加入请求消息后，向承载层的策略执行实体请求预留承载资源，所述请求中携带预留承载资源的优先级。
所述接收单元103，还用于从紧急事件通知消息中获取紧急事件通知指示，并根据所述获取的紧急事件通知指示，切换到紧急事件通知媒体流的呈现，接收紧急事件通知媒体流。
所述系统还包括：
业务发现单元104，用于获取分发单元102的相关信息，并提供给接收单元103。
所述业务发现单元104可以位于与所述接收单元同一个物理实体中，或者可以位于网络附着子系统NASS、网关GPRS支持节点GGSN、呼叫会话控制功能CSCF、应用服务器AS、或处理网络附着请求的实体中。
本发明实施例还提供了一种紧急事件通知接收单元装置，参见图12，图12 为本发明实施例提供的紧急事件通知接收单元装置的功能模块图，包括：
发现处理模块1210，用于紧急事件通知业务的发现。
所述发现包括网络附着过程中或网络附着完成后PULL方式的业务发现、IMS注册过程中或IMS注册完成后PULL方式的业务发现，以及网络附着完成后或IMS注册完成后PUSH方式的业务发现。
附着处理模块1220，用于紧急事件通知业务发现完成后，进行紧急事件通知业务的附着。
消息接收处理模块1230，用于接收紧急事件通知消息，并从紧急事件通知消息中获取紧急事件通知指示。
媒体流接收处理模块1240，用于接收紧急事件通知媒体流，以及根据所述获取的紧急事件通知指示，切换到紧急事件通知媒体流的呈现。
进一步的，所述紧急事件通知接收单元装置还包括如下之一及其组合：
预留承载资源请求模块1250，用于根据紧急事件通知指示，向承载层请求预留承载资源，所述请求中携带预留承载资源的优先级；
紧急会话建立请求模块1260，用于发起紧急事件通知会话的建立请求，所述建立请求中携带紧急事件通知指示的IPTV频道标识，或同时携带紧急指示。
本发明实施例还提供了一种紧急事件通知业务服务器装置，参见图13，图13为本发明实施例提供的紧急事件通知业务服务器装置的功能模块图，包括：
发布接口模块1310，用于接收紧急事件通知消息，并从紧急事件通知消息中获取紧急事件通知指示；
消息分发模块1320，用于分发紧急事件通知消息；
媒体流控制模块1330，用于根据紧急事件通知指示控制媒体服务器MF接收和分发紧急事件通知媒体流。
进一步的，所述紧急事件通知业务服务器装置还包括如下之一及其组合：
预留承载资源请求模块1340，用于根据紧急事件通知指示，向承载层请求预留承载资源，所述请求中携带预留承载资源的优先级；
紧急会话建立处理模块1350，用于发送紧急事件通知会话的建立请求的响应消息，所述响应消息中携带所述紧急事件通知指示的IPTV频道的多播地址。
本发明实施例还提供了一种紧急呼叫会话控制功能装置，参见图14，图14为本发明实施例提供的紧急呼叫会话控制功能装置的功能模块图，包括：
紧急频道加入识别模块1410，用于通过识别紧急事件通知会话建立请求中携带的IPTV频道标识为紧急频道标识，或者通过识别会话建立请求中携带的紧急指示，识别紧急事件通知会话建立请求为紧急频道加入请求消息。
紧急频道加入处理模块1420，用于在识别出紧急频道加入请求消息后，向承载层的策略执行实体请求预留承载资源，并根据识别出的所述IPTV频道标识或紧急指示，携带预留承载资源的优先级。
进一步的，所述紧急频道加入处理模块1420，还用于在识别出紧急频道加入请求消息后向紧急通知系统应用服务器EAS AS转发紧急事件通知会话的建立请求；接收并转发紧急通知系统应用服务器EAS AS返回的响应消息，所述响应消息中携带所述紧急频道加入的多播地址。
通过以上实施例的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得终端设备(可以是IPTV电视、手机，个人计算机，媒体播放器等)执行本发明各个实施例所述的方法。这里所称的存储介质，如：ROM/RAM、磁盘、光盘等。
以上对本发明实施例所提供的接收紧急事件通知的方法、装置和系统进行了详细介绍，实施例的说明只是用于帮助理解本发明的方法及其思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
Claims (23)
1.一种接收紧急事件通知的方法，其特征在于，包括以下步骤：
接收单元发现紧急事件通知业务；
接收单元附着到紧急事件通知业务，其中如果接收单元获取的是分发单元用于发送紧急事件通知的多播地址信息，则接收单元向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着；或者如果接收单元获取的是分发单元间接的数据库服务器地址信息，则接收单元首先向该服务器发送查询消息，获取分发单元用于发送紧急事件通知消息的多播地址，再向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着；
接收单元接收分发单元发送的紧急事件通知消息。
2.根据权利要求1所述的方法，其特征在于，所述接收单元发现紧急事件通知业务的方式包括：
在接收单元上预置分发单元的相关信息；或者
接收单元与业务发现单元进行消息交互，获取分发单元的相关信息；
其中，所述相关信息包括分发单元用于发送紧急事件通知的多播地址信息，或者分发单元间接的数据库服务器地址信息。
3.根据权利要求2所述的方法，其特征在于，所述接收单元与业务发现单元进行消息交互，获取分发单元的相关信息的方式，包括：
接收单元以广播方式向网络发送网络附着请求；网络中处理网络附着请求的实体接收到该网络附着请求，在向接收单元发送网络附着响应消息中携带分发单元的相关信息；其中，业务发现单元位于所述网络中处理网络附着请求的实体中；或者，
接收单元在完成网络附着后以广播方式向网络发送紧急事件通知业务发现请求；业务发现单元接收该业务发现请求，在向接收单元发送紧急事件通知业务发现响应消息中携带分发单元的相关信息；或者，
业务发现单元在感知到接收单元完成网络附着后，主动向接收单元发送分发单元的相关信息；或者，
接收单元向呼叫会话控制功能CSCF发送IMS注册请求；IMS网络中处理IMS注册请求的实体接收到该IMS注册请求，在向接收单元发送IMS注册响应消息中携带分发单元的相关信息；其中，业务发现单元位于所述呼叫会话控制功能CSCF中；或者，
接收单元在完成IMS注册后向呼叫会话控制功能CSCF发送紧急事件通知业务发现请求；呼叫会话控制功能CSCF将该请求触发到业务发现单元，由业务发现单元处理该业务发现请求，业务发现单元在向CSCF发送紧急事件通知业务发现响应消息中携带分发单元的相关信息；所述紧急事件通知业务发现响应消息经CSCF发送到接收单元；或者，
接收单元向呼叫会话控制功能CSCF发送IMS注册请求；CSCF处理所述IMS注册请求后，向紧急通知系统应用服务器EAS AS发送第三方IMS注册请求；EASAS处理所述第三方IMS注册请求后，主动向接收单元发送分发单元的相关信息；其中，CSCF和EAS AS为业务发现单元。
4.根据权利要求1所述的方法，其特征在于，所述接收单元接收分发单元发送的紧急事件通知消息中携带紧急事件通知指示，所述方法还包括：
根据紧急事件通知消息中的紧急事件通知指示接收单元进行紧急事件通知的处理及呈现。
5.根据权利要求4所述的方法，其特征在于，所述紧急事件通知指示包括紧急事件通知的类型、紧急指示，以及用于传送紧急事件通知媒体流的接口参数；所述用于传送紧急事件通知媒体流的接口参数可以为多播地址信息、广播地址信息、FTP/HTTP应用层地址信息，或IPTV频道标识信息中的任一项。
6.根据权利要求4所述的方法，其特征在于，所述根据紧急事件通知消息中的紧急事件通知指示接收单元进行紧急事件通知的处理及呈现的步骤之前，所述方法还包括下述任一个步骤：
分发单元根据紧急事件通知指示，在进行紧急事件通知分发过程中向承载层请求预留承载资源并指示资源的优先级；或者，
分发单元在接收到接收单元请求紧急事件通知媒体流内容时，通过识别所述请求为紧急事件通知指示，向承载层请求预留承载资源并指示资源的优先级；或者，
接收单元在接收到紧急事件通知消息后，根据紧急事件通知指示向承载层的策略执行实体请求预留承载资源并指示资源的优先级；或者，
接收单元在接收到紧急事件通知消息后，根据紧急事件通知指示发起紧急事件通知会话的建立请求，通过紧急事件通知会话的建立分发单元向承载层的策略执行实体请求预留承载资源并指示资源的优先级；或者，
在承载层的策略执行实体或策略决策实体中预置紧急事件通知媒体流的带宽要求及优先级，并指示承载层检测到紧急事件通知媒体流后，自动执行预先设置的带宽策略。
7.根据权利要求5所述的方法，其特征在于，若所述用于传送紧急事件通知媒体流的接口参数为多播地址信息，则所述根据紧急事件通知消息中的紧急事件通知指示接收单元进行紧急事件通知的处理及呈现的步骤包括：
接收单元获取所述多播地址信息；
接收单元发送加入所述多播地址信息对应多播组的请求消息，所述请求消息携带所述多播地址信息，或同时携带紧急指示；
接收单元加入所述多播组，接收紧急事件通知媒体流并播放输出。
8.一种发现紧急事件通知业务的方法，其特征在于，包括如下步骤：
接收单元向呼叫会话控制功能CSCF发送IMS注册请求；
CSCF处理所述IMS注册请求后，向紧急通知系统应用服务器EAS AS发送第三方IMS注册请求；
EAS AS处理所述第三方IMS注册请求后，向接收单元发送紧急事件通知业务发现消息。
9.一种接收紧急事件通知媒体流的方法，其特征在于，包括如下步骤：
从紧急事件通知消息中获取紧急事件通知媒体流的网络参数，所述网络参数包括多播地址信息，该多播地址信息为专用的特定的多播地址，或者为普通的多播地址；
发送加入所述多播地址信息对应多播组的请求消息，所述请求消息携带所述多播地址信息，或同时携带紧急指示；
多播复制控制点及复制点ECF/EFF处理所述多播组加入请求消息，向资源和准入控制子系统RACS请求预留承载资源，并根据识别出的所述多播地址或紧急指示，携带预留承载资源的优先级；
加入所述多播组接收紧急事件通知媒体流并播放输出。
10.一种加入紧急事件通知IPTV频道的方法，其特征在于，包括如下步骤：
从紧急事件通知消息中获取紧急事件通知的IPTV频道标识，所述IPTV频道标识为专用于紧急事件通知媒体流发送的特定的频道标识，或者为普通的频道标识；
发起紧急事件通知会话的建立请求，所述建立请求中携带所述IPTV频道标识，或同时携带紧急指示；
紧急呼叫会话控制功能E-CSCF处理所述紧急事件通知会话的建立请求，向资源和准入控制子系统RACS请求预留承载资源，并根据识别出的所述IPTV频道标识或紧急指示，携带预留承载资源的优先级；
紧急事件通知会话建立后，加入所述紧急事件通知的IPTV频道。
11.根据权利要求10所述的方法，其特征在于，所述方法还包括：
紧急呼叫会话控制功能E-CSCF向紧急通知系统应用服务器EAS AS转发紧急事件通知会话的建立请求；
紧急呼叫会话控制功能E-CSCF接收并转发紧急通知系统应用服务器EAS AS返回的响应消息，所述响应消息中携带所述紧急事件通知IPTV频道的多播地址；
接收所述紧急事件通知会话建立请求的响应消息，加入所述响应消息中携带的多播地址对应的多播组，接收该IPTV频道发送的紧急事件通知媒体流并播放输出。
12.一种接收紧急事件通知的系统，其特征在于，包括：
分发单元，用于向接收单元发送紧急事件通知消息；接收单元，用于发现紧急事件通知业务，并附着到紧急事件通知业务，接收分发单元发送的紧急事件通知消息；
其中，如果接收单元获取的是分发单元用于发送紧急事件通知的多播地址信息，则接收单元向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着；或者如果接收单元获取的是分发单元间接的数据库服务器地址信息，则接收单元首先向该服务器发送查询消息，获取分发单元用于发送紧急事件通知消息的多播地址，再向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着。
13.根据权利要求12所述的系统，其特征在于，所述分发单元为如下之一及其组合：
应用服务器AS，用于接收紧急事件通知消息，并从紧急事件通知消息中获取紧急事件通知指示；分发紧急事件通知消息；并根据紧急事件通知指示控制媒体服务器MF接收和分发紧急事件通知媒体流；
媒体服务器MF，用于接收和分发紧急事件通知媒体流；
基本控制功能及复制功能ECF/EFF，用于多播业务中的多播复制和控制。
14.根据权利要求13所述的系统，其特征在于，所述分发单元还可以包括：
紧急呼叫会话控制功能E-CSCF，用于通过识别会话建立请求中携带的频道标识为紧急频道标识，或者通过识别会话建立请求中携带的紧急指示，识别会话建立请求为紧急频道加入请求消息；并在识别出紧急频道加入请求消息后，向承载层的策略执行实体请求预留承载资源，所述请求中携带预留承载资源的优先级。
15.根据权利要求14所述的系统，其特征在于，
所述接收单元，还用于从紧急事件通知消息中获取紧急事件通知指示，并根据所述获取的紧急事件通知指示，切换到紧急事件通知媒体流的呈现，接收紧急事件通知媒体流。
16.根据权利要求12所述的系统，其特征在于，所述系统还包括：
业务发现单元，用于获取所述分发单元的相关信息，并提供给所述接收单元。
17.一种紧急事件通知接收单元装置，其特征在于，包括：
发现处理模块，用于紧急事件通知业务的发现；
附着处理模块，用于紧急事件通知业务发现完成后，进行紧急事件通知业务的附着，其中如果发现处理模块获取的是分发单元用于发送紧急事件通知的多播地址信息，则附着处理模块向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着；或者如果发现处理模块获取的是分发单元间接的数据库服务器地址信息，则附着处理模块首先向该服务器发送查询消息，获取分发单元用于发送紧急事件通知消息的多播地址，再向分发单元发送加入对应多播组的请求消息，加入对应多播组完成紧急事件通知业务的附着；
消息接收处理模块，用于接收紧急事件通知消息，并从紧急事件通知消息中获取紧急事件通知指示。
18.根据权利要求17所述的紧急事件通知接收单元装置，其特征在于，所述装置还包括：
媒体流接收处理模块，用于接收紧急事件通知媒体流，以及根据所述获取的紧急事件通知指示，切换到紧急事件通知媒体流的呈现。
19.根据权利要求18所述的紧急事件通知接收单元装置，其特征在于，所述装置还包括如下之一及其组合：
预留承载资源请求模块，用于根据紧急事件通知指示，向承载层请求预留承载资源，所述请求中携带预留承载资源的优先级；
紧急会话建立请求模块，用于发起紧急事件通知会话的建立请求，所述建立请求中携带所述紧急事件通知指示的IPTV频道标识，或同时携带紧急指示。
20.一种紧急事件通知业务服务器装置，其特征在于，包括：
发布接口模块，用于接收紧急事件通知消息，并从紧急事件通知消息中获取紧急事件通知指示；
消息分发模块，用于分发紧急事件通知消息；
媒体流控制模块，用于根据紧急事件通知指示控制媒体服务器MF接收和分发紧急事件通知媒体流。
21.根据权利要求20所述的紧急事件通知业务服务器装置，其特征在于，所述装置还包括如下之一及其组合：
预留承载资源请求模块，用于根据紧急事件通知指示，向承载层请求预留承载资源，所述请求中携带预留承载资源的优先级；
紧急会话建立处理模块，用于发送紧急事件通知会话的建立请求的响应消息，所述响应消息中携带所述紧急事件通知指示的IPTV频道的多播地址。
22.一种紧急呼叫会话控制功能装置，其特征在于，包括：
紧急频道加入识别模块，用于通过识别紧急事件通知会话建立请求中携带的IPTV频道标识为紧急频道标识，或者通过识别会话建立请求中携带的紧急指示，识别紧急事件通知会话建立请求为紧急频道加入请求消息；
紧急频道加入处理模块，用于在识别出紧急频道加入请求消息后，向承载层的策略执行实体请求预留承载资源，并根据识别出的所述IPTV频道标识或紧急指示，携带预留承载资源的优先级。
23.根据权利要求22所述的紧急呼叫会话控制功能装置，其特征在于，
所述紧急频道加入处理模块，还用于在识别出紧急频道加入请求消息后向紧急通知系统应用服务器EAS AS转发紧急事件通知会话的建立请求；接收并转发紧急通知系统应用服务器EAS AS返回的响应消息，所述响应消息中携带所述紧急频道加入的多播地址。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101345704A CN101640573B (zh) | 2008-07-28 | 2008-07-28 | 接收紧急事件通知的方法、装置和系统 |
| PCT/CN2009/071245 WO2010012165A1 (zh) | 2008-07-28 | 2009-04-13 | 接收紧急事件通知的方法、装置和系统 |
| US12/502,320 US8184002B2 (en) | 2008-07-28 | 2009-07-14 | Method and device for receiving emergency event alert |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101345704A CN101640573B (zh) | 2008-07-28 | 2008-07-28 | 接收紧急事件通知的方法、装置和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101640573A CN101640573A (zh) | 2010-02-03 |
| CN101640573B true CN101640573B (zh) | 2011-09-14 |
Family
ID=41609933
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2008101345704A Expired - Fee Related CN101640573B (zh) | 2008-07-28 | 2008-07-28 | 接收紧急事件通知的方法、装置和系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101640573B (zh) |
| WO (1) | WO2010012165A1 (zh) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8184002B2 (en) | 2008-07-28 | 2012-05-22 | Huawei Technologies Co., Ltd. | Method and device for receiving emergency event alert |
| CN102984550B (zh) * | 2011-09-07 | 2018-01-09 | 中兴通讯股份有限公司 | 一种基于iptv的紧急通知发布的方法和系统 |
| CN102610070B (zh) * | 2012-03-27 | 2014-05-28 | 中华电信股份有限公司 | 一种利用低频无线时频传播系统的紧急告警系统及方法 |
| CN105263063A (zh) * | 2015-10-14 | 2016-01-20 | 天脉聚源(北京)传媒科技有限公司 | 一种播放控制方法及装置 |
| CN108418819B (zh) * | 2018-02-27 | 2023-02-03 | 湖南农业大学 | 一种农村应急广播流媒体直播方法与应用 |
| CN110661668B (zh) * | 2019-09-29 | 2023-05-16 | 深圳前海微众银行股份有限公司 | 一种消息发送管理方法及装置 |
| CN114979006B (zh) * | 2021-10-14 | 2023-09-05 | 中移互联网有限公司 | 一种会话初始协议sip消息处理方法及其消息处理系统 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6882709B1 (en) * | 1999-04-14 | 2005-04-19 | General Instrument Corporation | Enhanced broadband telephony services |
| US20050183120A1 (en) * | 2004-01-13 | 2005-08-18 | Saurabh Jain | Multi-user personalized digital multimedia distribution methods and systems |
| WO2007101473A1 (en) * | 2006-03-07 | 2007-09-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Time-shifting and chase-play for an iptv system |
| CN101175198A (zh) * | 2006-11-02 | 2008-05-07 | 华为技术有限公司 | 网络电视的业务控制方法及系统、终端和应用处理模块 |
| CN101222283A (zh) * | 2007-11-29 | 2008-07-16 | 北京航空航天大学 | 基于用户位置实时播报交通信息的网络电台系统 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7592912B2 (en) * | 2005-12-09 | 2009-09-22 | Time Warner Cable Inc. | Emergency alert data delivery apparatus and methods |
| US7515036B2 (en) * | 2006-08-25 | 2009-04-07 | At&T Intellectual Property I, L.P. | System and method of communicating emergency alerts |
| US20080120639A1 (en) * | 2006-11-21 | 2008-05-22 | Sbc Knowledge Ventures, Lp | System and method of providing emergency information |
-
2008
- 2008-07-28 CN CN2008101345704A patent/CN101640573B/zh not_active Expired - Fee Related
-
2009
- 2009-04-13 WO PCT/CN2009/071245 patent/WO2010012165A1/zh active Application Filing
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6882709B1 (en) * | 1999-04-14 | 2005-04-19 | General Instrument Corporation | Enhanced broadband telephony services |
| US20050183120A1 (en) * | 2004-01-13 | 2005-08-18 | Saurabh Jain | Multi-user personalized digital multimedia distribution methods and systems |
| WO2007101473A1 (en) * | 2006-03-07 | 2007-09-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Time-shifting and chase-play for an iptv system |
| CN101175198A (zh) * | 2006-11-02 | 2008-05-07 | 华为技术有限公司 | 网络电视的业务控制方法及系统、终端和应用处理模块 |
| CN101222283A (zh) * | 2007-11-29 | 2008-07-16 | 北京航空航天大学 | 基于用户位置实时播报交通信息的网络电台系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010012165A1 (zh) | 2010-02-04 |
| CN101640573A (zh) | 2010-02-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8184002B2 (en) | Method and device for receiving emergency event alert | |
| CN101640573B (zh) | 接收紧急事件通知的方法、装置和系统 | |
| US10397644B2 (en) | Switching between delivery methods in an IPTV communication network | |
| CN101155293B (zh) | 一种进行网络直播电视业务频道授权的方法、系统及装置 | |
| US9609542B2 (en) | Service specific subscriber priority | |
| KR101433225B1 (ko) | Ｉｍｓ 아키텍쳐 네트워크에서 ｉｐ 텔레비젼 서비스에 액세스하기 위한 시스템 | |
| CN100571278C (zh) | 在iptv业务中应用终端能力信息的方法、系统及装置 | |
| WO2010028589A1 (zh) | 业务推送协商方法及装置、推送业务系统 | |
| US10455294B2 (en) | Video distribution method and device | |
| CN101420432A (zh) | 一种ims监听的实现方法、系统及装置 | |
| CN101605142A (zh) | 会话管理的实现方法、装置、系统及终端 | |
| CN101547402A (zh) | 一种建立iptv多播业务的方法及设备 | |
| CN101388784A (zh) | 一种处理组播业务信息的方法、装置及系统 | |
| US20080098091A1 (en) | System and method for providing personalized multimedia broadcasting over a mobile telecommunications radio area network | |
| WO2008089702A1 (fr) | Système et procédé de mise en oeuvre de service multimédia en flux, et entité de fonction de commande de ce service | |
| CN101155110B (zh) | 一种实现业务集成的方法及系统 | |
| CN101883333B (zh) | 获取指定用户实时媒体播放信息的方法、系统和装置 | |
| EP2590378B1 (en) | Method and system for audio broadcast in video surveillance | |
| WO2009129728A1 (zh) | 广播/组播方法、设备和系统 | |
| Riede et al. | Quadruple play-session management enabler for multimedia streaming | |
| CN102281517A (zh) | 非语音紧急呼叫的控制方法、ip多媒体子系统及p-cscf | |
| CN101848200A (zh) | 一种插入媒体内容的方法、装置、应用层实体及系统 | |
| KR20140050515A (ko) | 멀티캐스트 및 유니캐스트 혼용 기반의 주문형 비디오 서비스 제공 장치 및 그 방법 | |
| KR101874019B1 (ko) | Ims 망을 이용하여 반이중 통화, 전이중 통화, 컨퍼런스 및 문자 서비스 기능을 제공하는 ptt 시스템 | |
| CN101340362B (zh) | 一种频道切换结果的上报方法、系统及实体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C41 | Transfer of patent application or patent right or utility model | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20160606 Address after: New Hampshire Patentee after: Flash point technology Address before: 518129 headquarters building of Bantian HUAWEI base, Longgang District, Guangdong, Shenzhen Patentee before: Huawei Technologies Co., Ltd. |
|
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110914 Termination date: 20170728 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |