CN101110991B - Ims中识别滥用紧急承载资源的方法、装置及系统 - Google Patents
Ims中识别滥用紧急承载资源的方法、装置及系统 Download PDFInfo
- Publication number
- CN101110991B CN101110991B CN2007101306546A CN200710130654A CN101110991B CN 101110991 B CN101110991 B CN 101110991B CN 2007101306546 A CN2007101306546 A CN 2007101306546A CN 200710130654 A CN200710130654 A CN 200710130654A CN 101110991 B CN101110991 B CN 101110991B
- Authority
- CN
- China
- Prior art keywords
- message
- bearing
- urgency traffic
- resource
- application
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/436—Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2242/00—Special services or facilities
- H04M2242/04—Special services or facilities for emergency applications
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种IMS中识别滥用紧急承载资源的方法、装置、系统及其应用,其关键是,在呼叫建立过程中,用于传递信息的中间实体判断在同一会话中,来自承载层的消息包含紧急承载指示,而应用层的消息中没有包含紧急业务指示,则判定为滥用紧急承载资源。对于滥用紧急承载资源的呼叫,禁止其建立。应用本发明能够迅速有效地识别出滥用紧急承载资源的呼叫,从而保证了紧急承载资源只能被应用于紧急业务,避免了紧急承载资源被滥用。本发明应用简单、有效。
Description
技术领域
本发明涉及通信技术领域,特别是指一种IP多媒体子系统(IMS,InternetMultiedia Subsystem)中识别滥用紧急承载资源的方法、装置及系统。
背景技术
在紧急的状态下,用户会使用用户设备(UE,User Equipment)呼叫公共安全应答点(PSAP,Public Safety Answering Point)获取帮助,而PSAP也有可能在用户挂机后对用户发起回叫,以便了解更多的信息。本文提到的紧急业务是指用户发起紧急呼叫,还可以包括PSAP回叫用户的情况,当然,也可以不包括PSAP回叫的情况。
图1所示为现有IMS域紧急呼叫的整体流程框架图。图中实线表示UE发起的紧急呼叫,虚线表示PSAP发起的回呼。UE 10发起的紧急呼叫通过GPRS网关支持节点(GGSN,Gateway GPRS Support Node)20、代理呼叫会话控制功能(P-CSCF,Proxy Call Session Control Function)实体40、紧急呼叫会话控制功能(E-CSCF)实体50到达PSAP 80,PSAP 80发起的回呼通过服务呼叫会话控制功能(S-CSCF)实体60、P-CSCF 40、GGSN 20到达UE 10。如果PSAP位于公共交换电话网(PSTN,Public Switched TelephoneNetwor)或电路域(CS,Circuit Switched)网络,则E-CSCF发往PSAP和PSAP发往S-CSCF的信令需要经过媒体网关控制功能(MGCF,MediaGateway Control Function)实体进行转换,如果PSAP在IP域,则不需经过MGCF。图1中策略决定功能(PDF,Policy Decision Function)实体用于承载资源的管理。
由于紧急呼叫是一个本地的服务,所以用户在漫游时,GGSN、PDF、P-CSCF、E-CSCF、MGCF1和PSAP都是漫游地的,但是当PSAP回叫时则会有两种可能,一种是使用漫游地的MGCF1即MGCF70a接入IMS域,一种是通过用户归属域的MGCF2即MGCF70b接入IMS域。
下面结合IMS承载资源的管理流程对现有的紧急呼叫流程进行说明。
图2所示为现有的IMS承载资源的管理流程示意图。
步骤101~102,用户决定发起一个呼叫后,首先通过UE发起一个接入侧的承载资源申请,一般是向GGSN发送一个创建组数据协议(create PDP)请求,如果是为紧急业务申请的资源,则该请求中将携带一个紧急承载指示,如紧急承载标识或者紧急的接入点名称(APN,Access Point Name)等。GGSN和接入网给UE分配承载资源后,GGSN返回一个申请承载资源成功的响应,如create PDP response。
步骤103~104,UE使用申请到的承载资源发送SIP的请求(INVITE)消息,其IP包的目的地址是P-CSCF。该消息通过GGSN进行中转,如果进行的是紧急呼叫,那么该INVITE消息中含有紧急业务指示。
步骤105~106,P-CSCF将该请求转发给其它的设备,如E-CSCF等,进行紧急呼叫的建立,之后,接收INVITE的200消息。
步骤107~108,P-CSCF将INVITE和200中得到的用户连接信息(如IP地址端口等)和服务质量(QoS,Quality of Service)信息(如带宽等)发送给PDF,通常使用的是Diamter协议的AAR(AA-Request)消息,之后,接收来自PDF的响应消息,通常使用的是Diamter的AAA(AA-Answer)消息。如果是本会话的第一个响应消息,那么该消息中必须携带一个Token,该Token标识了该PDF和本次会话。
步骤109~110,P-CSCF将步骤106中收到的200消息通过GGSN前传给UE,如果以前没有携带过Token,那么需要将Token添加到200消息中。
步骤111,UE收到P-CSCF发来的消息后,根据得到的连接信息和QoS信息为媒体信息发起资源申请过程,这是一个创建或更新PDP的过程,UE发送的create PDP消息中携带有Token,如果是紧急承载请求,该消息中将含有某个指示,根据该指示GGSN可以知道这是一个紧急业务的承载请求。上述某个指示可以是与已申请的紧急承载资源的关联关系,也可以是紧急承载标识等。
步骤112,GGSN在收到这个申请消息后,根据其中的Token,向PDF发起承载资源的认证请求,通常是通用开放策略服务协议(COPS,CommonOpen Policy Service Protocol)的REQ消息(COPS REQuest message)。
步骤113,PDF将相关的用户连接信息,QoS信息和其它一些信息发送给GGSN,通常使用COPS的DEC消息(COPS DECision message)。
步骤114,GGSN根据收到的DEC消息核对承载层申请的资源,例如,核对IP地址端口和带宽信息是否符合应用层的要求,如果符合,将在接入网给UE分配承载资源,同时给UE发送承载资源请求的响应消息。
步骤115,如果承载申请成功,UE将发送数据进行通话,该数据的IP包会传送到GGSN,其目的地址是相关的媒体设备。
步骤116,GGSN将数据包转发到IP包的目的地媒体设备,所述媒体设备包括PSAP所控制的媒体设备和MGCF所控制的媒体设备。
在步骤101和步骤111中,表示UE申请的资源为紧急承载的指示为:一个紧急标识字段,或者一个全局专用的紧急APN,或者一个能够关联到已有的紧急承载的索引。
基于上述管理流程,现有紧急业务采用的方法是:首先在GGSN上针对紧急APN配置过滤规则,仅让携带了指定的用于紧急呼叫的P-CSCF的地址的IP包通过GGSN,保证UE发出的IP包只能到达用于紧急呼叫的P-CSCF,同时也只能接收这些地址过来的IP包。如果是为紧急业务申请承载资源,那么在申请时,也就是图2中的步骤101和步骤111将携带紧急承载指示。那么GGSN收到来自或发往这些地址所申请的承载资源时,将会使用过滤规则来过滤所有的IP包,该处理发生在步骤104,步骤110和步骤116。
而紧急承载资源通常享有比普通承载资源更高的优先级和QoS,甚至在普通呼叫因为漫游限制不允许使用承载资源的情况,紧急承载资源也是可以使用的,同时使用紧急承载资源的紧急呼叫还有可能在承载层是免费的。但GGSN的功能只是转发UE发出的IP包,并不解析其应用层内容,上述过滤规则能限制UE发出的IP包只能到达一些特定的用于紧急业务的P-CSCF,但并不限制P-CSCF对接收到的内容解析后是否仍进行紧急业务处理,这样用户就有可能在接入GGSN时申请紧急的承载资源,而在上层应用使用普通的呼叫,这样就可以在接入侧逃避计费及漫游限制等,从而导致滥用紧急承载资源。
发明内容
有鉴于此,本发明提供一种IMS中识别滥用紧急承载资源的方法、装置及系统,以防止紧急承载资源被滥用。
本发明的技术方案包括:
一种IMS中识别滥用紧急承载资源的方法,该方法包括:
在呼叫建立过程中,如果用于传递信息的中间实体检查接收的来自承载层的消息中包含紧急承载指示信息,或接收的应用信令使用了为紧急业务预留的承载层限定的相关资源,则确定承载层使用了紧急承载;则
检查接收的来自应用层的消息或应用信令中是否包含紧急业务指示信息,若未包含则为非紧急业务,则禁止或重定向所述呼叫。
一种IMS中识别滥用紧急承载资源的装置,包括:
消息接收单元,用于接收在呼叫建立过程中出自同一会话的消息或应用信令;
紧急承载识别单元,用于检查如果所述消息中包含紧急承载指示信息,或应用信令使用了为紧急业务预留的承载层限定的相关资源,则确定承载层使用了紧急承载;
紧急业务识别单元,用于检查如果所述消息或应用信令中未包含紧急业务指示信息,则确定应用层为非紧急业务;
判断单元,根据所述紧急承载识别单元和所述紧急业务识别单元的检查结果,在所述结果为承载层使用了紧急承载,但应用层为非紧急业务时,禁止或重定向所述呼叫。
一种IMS中识别滥用紧急承载资源的系统,包括接入侧承载控制IP网关和应用层服务器,
所述接入侧承载控制IP网关包括资源分配装置,用于在呼叫建立过程中,为用户终端分配资源,包括为申请紧急业务承载的用户分配预留的承载层限定的相关资源;
所述应用层服务器包括识别装置,用于检查所述应用层服务器接收的应用信令如果包含了为紧急业务预留的承载层限定的相关资源,则确定承载层使用了紧急承载,检查所述应用信令中是否包含紧急业务指示信息,如果未包含则为非紧急业务,则禁止或重定向所述呼叫。
本发明在呼叫建立过程中,用于传递信息的中间实体判断出在同一服务相关请求中,如果承载层使用的是紧急承载,再判断应用层是否是紧急业务请求,若为非紧急业务请求,则判定该呼叫滥用紧急承载资源。本发明能够迅速有效地识别出滥用紧急承载资源的呼叫,从而保证了紧急承载资源只能被应用于紧急业务,避免了紧急承载资源被滥用。
附图说明
图1是现有的IMS域的紧急呼叫的流程框架图;
图2是现有的MS承载资源的管理流程示意图;
图3是根据本发明第一实施例的承载资源管理流程示意图;
图4是根据本发明第二实施例的承载资源管理流程示意图;
图5是根据本发明第三实施例的承载资源管理流程示意图;
图6是根据本发明第四实施例的承载资源管理流程示意图;
图7是根据本发明第五实施例的承载资源管理流程示意图;
图8是根据本发明实施例中IMS中识别滥用紧急承载资源的装置原理图;
图9是根据本发明实施例中IMS中识别滥用紧急承载资源的系统原理图。
具体实施方式
下面结合附图对本发明优选实施例做进一步的详细说明。
本发明实施例在同一服务相关请求中,用于传递信息的中间实体获知承载层和应用层的紧急属性信息,如果承载层使用的是紧急承载,那么将检查应用层是否是紧急业务,若为非紧急业务,则判定该请求滥用紧急承载资源。所述紧急属性信息包括:承载紧急指示和业务紧急指示。
上述用于传递信息的中间实体可以是接入侧的承载控制IP网关,如GGSN、分组数据服务节点(PDSN)等,还可以是PDF或应用服务器等,当然并不限于此。而且来自应用层的消息中的紧急业务指示可根据会话创建消息中插入的紧急业务指示生成。
图3和图4是基于本发明方法的两个具体实施例。
参见图3,本实施例由UE发起紧急呼叫,且由GGSN判断承载层和应用层的消息中是否都含有紧急指示。
步骤201,UE发起会话INVITE请求,如果是紧急业务,则INVITE请求中将携带紧急业务指示标明该请求为一个紧急业务。紧急业务指示可以是INVITE消息中的某个头域或者是头域中的某个参数,例如:“priority:emergency”。
步骤202~203,P-CSCF收到该请求后,检查消息中是否含有紧急业务指示,如果有,则P-CSCF在本地标记该会话为紧急业务,并将该请求路由到指定的媒体设备例如E-CSCF进行处理,如果没有,则不用标记,P-CSCF按常规消息前传该请求。之后,P-CSCF接收反馈的200响应消息。
步骤204,P-CSCF给PDF发送AAR消息,如果P-CSCF标记过本次会话是一个紧急业务,则AAR消息中将携带紧急业务指示,该指示可以是AAR消息中的一个字段,否则AAR消息中不用携带该紧急业务指示。
步骤205,PDF给P-CSCF回响应消息AAA,如果是本会话的第一个响应消息,那么该消息中必须携带一个Token,该Token标识了该PDF和本次会话。
步骤206,P-CSCF接收到PDF返回的AAA消息后,将200响应前传给UE。
步骤207,UE收到P-CSCF发来的消息后,根据得到的用户连接信息和QoS信息向GGSN发起承载资源申请的消息,这是一个创建或更新PDP的过程,消息中携带有Token,如果是为紧急业务申请承载资源,那么申请消息中需要携带紧急承载指示以表示申请的是紧急的承载资源,该紧急承载指示可以为一个紧急标识字段,一个全局专用的紧急APN,或者一个能够关联到已有的紧急承载的索引。
步骤208,GGSN在收到这个申请消息后,根据Token,将会向PDF发起承载资源的认证请求,通常是COPS的REQ消息。
步骤209,PDF给GGSN发送DEC消息,如果针对本次会话,PDF从P-CSCF收到过来自应用层的紧急业务指示,即接收到的AAR消息中包含了紧急业务指示,那么其发送的DEC消息也携带紧急业务指示,否则,所发送的PDF消息中不添加紧急业务指示。
步骤210,GGSN收到DEC消息后,首先检查用户在资源申请过程中是否携带了紧急承载指示,如果是,则检查收到的DEC消息中是否也含有紧急业务指示,如果DEC消息中没有包含紧急业务指示,则GGSN判定为滥用紧急承载资源,之后,可以进行相关处理,如阻断当前呼叫流程,并进行相应记录等;如果收到的DEC消息中含有紧急业务指示,则继续正常的流程,此时表示该呼叫确实为紧急呼叫流程。
参见图4,本实施例由如PSAP等媒体设备发起对UE的回呼,且由PDF判断承载层和应用层的消息中是否都含有紧急指示,且当前认为PSAP回叫也属于紧急业务。
步骤301,P-CSCF收到了用于呼叫UE的INVITE消息。
步骤302,如果P-CSCF识别出该请求是一个PSAP的回叫,P-CSCF将在发给PDF的AAR消息中携带紧急业务指示。如果不是,则不携带紧急业务指示,具体的识别方法可以通过INVITE中是否包含紧急指示头域,或者根据INVITE中的主叫用户身份等方法进行识别。
步骤303,PDF给P-CSCF回响应消息AAA,如果是本会话的第一个响应消息,那么该消息中必须携带一个Token,该Token标识了该PDF和本次会话。
步骤304,P-CSCF将INVITE请求前传给UE。
步骤305,UE接收到P-CSCF发来的消息后,根据得到的用户连接信息和QoS信息向GGSN发起承载资源申请的消息,这是一个创建或更新PDP的过程,消息中携带有Token,如果是为紧急业务申请承载资源,那么该消息中还需要携带紧急承载指示以表示申请的是紧急承载资源。
步骤306,GGSN在收到这个申请消息后,根据Token,将会向PDF发起承载资源认证的REQ消息。如果申请消息中携带了紧急承载指示,那么REQ消息中也将携带紧急承载指示。
步骤307,PDF收到REQ消息后,检查出该消息中携带了承载层的紧急承载指示,则检查P-CSCF针对本次会话下发的消息中是否携带有应用层的紧急业务指示。如果没有,则PDF判定为滥用紧急承载资源,之后,可以进行相关处理,如阻断当前呼叫流程,并进行相应记录等;如果有,则继续正常的流程,此时表示该呼叫确实为紧急呼叫流程。
上述实施例用于当PSAP发起对UE的回呼时,PDF通过判断承载层和应用层的消息中是否都含有紧急指示,来识别出滥用紧急承载资源的呼叫,从而保证了紧急承载资源只能被应用于紧急业务,避免了紧急承载资源被滥用。
以上仅是两个具体实施例而已,可以理解,在实际应用中,当UE发起紧急呼叫时,也可以由PDF判断承载层和应用层的消息中是否都含有紧急指示;当PSAP发起回呼时,也可以由GGSN判断承载层和应用层的消息中是否都含有紧急指示。
与此同时,本发明实施例还可以在承载层网关上为紧急业务的承载设置过滤规则,保证允许包含了为紧急业务预留的承载层限定的相关资源的数据包通过;对应的,应用层服务器根据承载层控制的协议层的信息判断该消息是否采用的是为紧急业务预留的承载资源,若是,则所述应用层服务器将检查该请求是否为紧急业务,如果不是,将判断该请求是非法请求;否则,将继续后续的流程。其中,判断承载层是否为使用紧急承载可通过初始的消息,例如:注册(register)消息判断,应用层在判断是否为紧急业务时,可通过注册(register)消息判断,还可通过注册(register)消息的响应及后续的invite、message等SIP消息判断。所述承载层控制协议至少包括:IP、传输层协议,比如UDP(User,用户数据包协议Datagram Protocol),TCP(TransmissionControl Protocol,传输控制协议),端口,AH(Authentication Header,认证头协议),ESP(Encapsulating Security Payload,封装安全负载协议),SPI(Security Parameter Index,安全参数索引)等;为紧急业务预留的承载层限定的相关资源至少包括:UE的IP地址、应用服务器的IP地址、应用服务器提供服务的端口、应用服务器提供的传输层协议,应用服务器为UE分配的SPI及其可能组合。
基于上述技术方案,本发明实施例还公开了一种IP多媒体子系统IMS中识别滥用紧急承载资源的方法:在P-CSCF上为紧急业务的消息预留专用服务端口,并判断从该端口相关的应用层消息是否为紧急业务。
如图5所示,其为本发明第三实施例的承载资源管理流程示意图,该方法包括以下步骤:
步骤400~步骤401,在应用服务器如P-CSCF上为紧急业务预留一个紧急承载专用的端口,例如9000;在系统接入侧的承载控制IP网关如GGSN上设置针对所述紧急业务的承载的过滤规则,例如,只允许发往所述P-CSCF的9000端口的使用紧急承载的IP包通过,而发往该P-CSCF的其它端口的使用紧急承载的IP包不允许通过。此外,该过滤规则还可以让紧急业务相关的媒体通行。
步骤402,用户UE向GGSN发送创建组数据协议(create PDP)请求来申请紧急业务的承载资源,所述请求中携带紧急承载指示,如紧急承载标识或者紧急的APN等。
步骤403,GGSN根据所述紧急承载指示,如果识别出该UE申请的是紧急承载,则GGSN为UE分配紧急的承载资源,并向UE返回一个申请承载资源成功的响应,如create PDP response。该响应包括GGSN为UE分配的源IP地址,可能还包括能够访问的远端IP地址及端口,其中,所述远端IP地址为P-CSCF的IP地址,所述目的端口为P-CSCF预置的紧急业务专用端口。
步骤404,UE使用申请到的紧急承载资源发起注册(register)请求消息,该请求消息IP包的源IP地址为GGSN为其分配的所述源IP地址,目的IP地址是P-CSCF的IP地址,端口是9000;其IP包的格式优选为目的IP地址+UDP端口;如果进行的是紧急呼叫,所述消息还包括紧急业务指示,这里所述紧急业务指示可以是用户的注册信息等。
该注册请求消息通过GGSN进行中转,在该过程中,GGSN首先根据预置的过滤规则来检查所述注册请求消息IP包,如果该IP包不是发往P-CSCF的9000端口,那么GGSN将判定该请求为非法请求;否则,执行步骤405。
步骤405,GGSN将所述注册请求消息转发给P-CSCF,P-CSCF通过9000端口接收该消息,此时,P-CSCF认为该消息使用的承载为紧急承载。
步骤406~407,P-CSCF将所注册请求消息发送给其它服务器,其它服务器返回相应的401响应消息。
步骤408~409,P-CSCF为该UE分配下次通信的端口,及ESP协议的SPI,同时标记通过所述下次通信端口收到的请求为使用的是紧急承载的消息。
同时,P-CSCF将401响应消息由GGSN转发给UE,其中,所述401响应消息中还包括P-CSCF新分配的端口号和SPI。
步骤410,UE向GGSN重新发起注册(register)请求消息,此时UE发出的注册请求消息IP包的格式是包含有IP地址+ESP。其中,所述IP地址包括GGSN为该UE分配的源IP地址和P-CSCF的目的IP地址,所述ESP包括P-CSCF为UE分配的SPI。
GGSN在收到该注册请求消息后,检查所述消息中的源IP地址是否为UE在申请紧急承载资源时GGSN分配给该UE的IP地址,如果不是,则GGSN可以判定该请求为非法请求;否则,执行下述步骤。
步骤411~416,GGSN将所述注册请求消息发送给P-CSCF,P-CSCF通过所述新分配的端口收到该UE的注册请求消息后,对该请求的IP包进行ESP解码。
P-CSCF检查所述注册请求消息中是否包含紧急业务指示,若包含,则认为该请求为紧急业务,则P-CSCF根据所述注册请求完成后续的注册流程,并在注册完成后,将200响应消息由GGSN发送至UE;若该请求不包含紧急业务指示,那么P-CSCF认为该请求是非法请求。
此外,如果P-CSCF在此过程中不检查所述注册请求消息是否为紧急业务,那么P-CSCF会在后续当UE发起与该注册相关的如invite、message等SIP请求时,检查该请求是否为紧急业务,若不是,那么P-CSCF将判定该相关请求是非法请求。
需要说明的是,在后续的正常会话过程中,如果需要,P-CSCF还通知GGSN增加新的媒体过滤规则,以确保协商的媒体部分能够通过GGSN。具体的通知新的媒体过滤规则的方法与上述实施例相同,这里不再赘述。
除此之外,上述步骤404中GGSN还可以检查UE使用紧急承载发来的请求消息中的源IP地址是否为该UE在申请紧急承载资源时GGSN分配给该UE的IP地址,若不是,则GGSN判定该请求为非法请求。
上述实施例通过在应用层服务器上为紧急业务分配专用端口,并在承载层网关上针对紧急业务的承载设置过滤规则,允许包含有应用层服务器专用端口的数据包通过;同时,所述应用层服务器如果从分配的专用端口收到数据包,则认为该数据包为采用紧急承载的消息,进而判断从该专用端口获取到的消息是否为紧急业务,从而保证了紧急承载资源只能被应用于紧急业务,避免了紧急承载资源被滥用。
除此之外,本发明实施例并不限于上述的通过设置紧急业务的端口来识别是否采用了紧急承载的消息,例如,所述应用服务器还可以为紧急业务预留一个如SPI等范围,当接收到的消息中有该范围内的SPI时,则判断该消息是否为紧急业务。
如图6所示,其为本发明第四实施例的承载资源管理流程示意图,该方法包括以下步骤:
步骤500~步骤501,在应用服务器如P-CSCF上不仅设置紧急业务专用端口,还为紧急业务预留一个SPI范围,例如20000-30000。同时,在P-CSCF上还设置SPI的分配规则,即P-CSCF如果是从紧急业务专用的端口收到了注册请求消息,那么为该用户UE分配从预留SPI范围中的SPI,例如20006。该过滤规则还可以让紧急业务相关的媒体通行。
在系统接入侧的承载控制IP网关如GGSN上设置针对紧急业务的承载的过滤规则,例如允许用户发往P-CSCF的所述SPI范围内的IP包(如SPI值为20000-30000的IPSEC包)能够通过,而发往该P-CSCF的其它SPI范围的IP包不可以通过,允许用户发往P-CSCF指定端口的IP包通过。
步骤502,UE向GGSN发送一个创建组数据协议(create PDP)请求来申请紧急业务的承载资源,所述请求中携带紧急承载指示,如紧急承载标识或者紧急的APN等。
步骤503,GGSN根据所述紧急承载指示如果识别出该UE申请的是紧急承载,则GGSN为UE分配紧急的承载资源,并向UE返回一个申请承载资源成功的响应,如create PDP response。该响应包括GGSN为UE分配的源IP地址,可能还包括能够访问的远端IP地址及端口,其中,所述端口为P-CSCF预置的紧急业务专用端口。
步骤504,UE使用申请到的紧急承载资源发起注册(register)请求消息,所述请求消息IP包的源IP地址为GGSN为其分配的所述源IP地址,目的IP地址是P-CSCF的IP地址,UDP端口是P-CSCF专用端口;其IP包的格式优选为IP地址+UDP端口;如果进行的是紧急呼叫,所述消息还包括紧急业务指示,这里所述紧急业务指示可以是用户的注册信息等。
该注册请求消息通过GGSN进行中转,在该过程中,GGSN首先根据预置的过滤规则来检查该注册请求消息IP包,如果所述IP包中的目的端口号不是发往P-CSCF的专用端口,那么GGSN将判定该请求为非法请求;否则,执行步骤505。
步骤505,GGSN将所述注册请求消息转发给P-CSCF。
步骤506~507,P-CSCF将所注册请求消息发送给其它服务器,其它服务器返回相应的401响应消息。
步骤508~509,P-CSCF为该UE分配下次通信的端口及ESP协议的SPI。如果是从紧急业务专用端口收到的请求,那么P-CSCF认为该请求使用的是紧急承载资源,此时,所述SPI为从紧急业务预留的SPI范围中选取的。
同时,P-CSCF将401响应消息由GGSN转发给UE,其中,401响应消息中还包括P-CSCF新分配的端口号和SPI。
步骤510,UE向GGSN重新发起注册(register)请求消息,此时UE发出的注册请求消息IP包包含有IP地址+ESP。其中,所述IP地址包括GGSN为UE分配的所述源IP地址和P-CSCF的目的IP地址,所述ESP包括P-CSCF为UE分配的SPI。
GGSN在收到该注册请求消息后,检查该消息中的SPI是否属于为紧急业务预留的范围内的,如果不是,则GGSN可以判定该请求为非法请求;否则,执行下述步骤。
步骤511~515,GGSN将所述注册请求消息发送给P-CSCF,P-CSCF通过所述新分配的端口收到该UE的注册请求消息后,对所述请求的IP包进行ESP解码。
P-CSCF检查解码后的注册请求消息中的SPI是否为紧急业务专用范围内的,若是,则认为该消息为采用的紧急承载资源的消息,则P-CSCF进一步检查该消息是否为紧急业务,如果不是,那么P-CSCF认为该请求是非法请求。否则,P-CSCF根据所述注册请求完成后续的注册流程,并在注册完成后,将200响应消息由GGSN发送至UE。
此外,如果P-CSCF在此过程中不检查所述注册请求消息是否为紧急业务,那么P-CSCF会在后续当UE发起与该注册相关的如invite、message等SIP请求时,检查该请求是否为紧急业务,若不是,则P-CSCF将判定该相关请求是非法请求。
上述实施例通过在承载层网关上设置过滤规则,保证允许包含了使用紧急承载层限定的相关资源信息的数据包通过;同时,应用层服务器在收到用户发出的IP包的消息后,根据该消息中的SPI判断出该消息为包含了使用紧急承载层限定的相关资源信息的消息时,对该消息进行紧急业务检查,进一步判断该消息是否为紧急业务,从而保证了紧急承载资源只能被应用于紧急业务,避免了紧急承载资源被滥用。
与此同时,本发明实施例还公开了一种IMS中识别滥用紧急承载资源的方法:在GGSN上设置允许包含有预置范围内的IP地址的请求通过,其中,所述预置范围内的IP专用于紧急承载资源。P-CSCF当收到该IP地址范围的请求时,检查该请求是否为紧急业务。
如图7所示,其为本发明第五实施例的承载资源管理流程示意图,该方法包括以下步骤:
步骤600,在GGSN上为紧急业务预留一个源IP地址范围,用于为申请紧急业务的承载资源的UE分配。同时,在GGSN上还设置过滤规则,允许包含有所述预留范围内的IP地址的数据包通过,而包含其它源IP地址的IP包不可以通过。该过滤规则还可以让紧急业务相关的媒体通行。
步骤601,在P-CSCF上通过配置或者其它手段获知GGSN上预留的源IP地址范围,以便在P-CSCF收到所述预留IP范围内的请求时,检查该请求是否为紧急业务。
步骤602,UE向GGSN发送一个创建组数据协议(create PDP)请求来申请紧急业务的承载资源,所述请求中携带紧急承载指示,如紧急承载标识或者紧急的APN等。
步骤603,GGSN根据所述紧急承载指示识别出该UE申请的是紧急承载,为该用户分配紧急的承载资源,其中,所述承载资源中的源IP地址为所述紧急业务预留的地址范围中的IP地址。
同时,GGSN向UE返回一个申请承载资源成功的响应,如create PDPresponse。其中所述响应包括GGSN为UE分配的源IP地址。
步骤604,UE使用申请到的紧急承载资源分配发起注册(register)请求消息,由于所述请求消息IP包是使用紧急承载资源发送的,GGSN将检查该消息的源IP地址是否属于预留的范围内的,如果不是,则认为该消息为非法请求;否则,执行下述步骤。
步骤605,GGSN将所述注册请求消息转发给P-CSCF,P-CSCF接收该消息,根据该消息中的IP确定该消息使用的承载为紧急承载。
步骤606~607,P-CSCF将所述注册请求消息发送给其它服务器,其它服务器返回相应的401响应消息。
步骤608~609,P-CSCF为该UE分配下次通信的端口及ESP协议的SPI。
同时,P-CSCF将401响应消息由GGSN转发给UE,其中,所述401响应消息中还包括P-CSCF新分配的端口号和SPI。
步骤610,UE向GGSN重新发起注册(register)请求消息,此时UE发出的所述注册请求消息IP包包含有IP地址+ESP。其中,所述IP地址包括GGSN为UE分配的专用于紧急业务的源IP地址和P-CSCF的目的IP地址,所述ESP包括P-CSCF为UE分配的SPI。
GGSN在收到该注册请求消息后,检查该消息中的源IP地址是否属于为紧急业务预留的IP地址范围,如果不是,则GGSN可以判定该请求为非法请求;否则,执行下述步骤。
步骤611~616,GGSN将所述注册请求消息发送给P-CSCF,P-CSCF通过所述新分配的端口收到该UE的注册请求消息后,对所述请求的IP包进行ESP解码。
P-CSCF根据所述注册请求消息中的源IP地址检查该IP是否属于为紧急业务所预留的源IP地址范围,若是,则P-CSCF认为该消息为采用紧急承载资源的消息,P-CSCF将检查该请求是否是紧急业务,如果请求的不是紧急业务,则P-CSCF认为该请求为非法请求;如果请求的是紧急业务,则P-CSCF根据所述注册请求完成后续的注册流程,并在注册完成后,将200响应消息由GGSN发送至UE。
此外,如果P-CSCF在此过程中不检查所述注册请求消息是否为紧急业务,那么P-CSCF会在后续当UE发起与该注册相关的如invite、message等SIP请求时,检查该请求是否为紧急业务,若不是,则判定所述相关请求是非法请求。
上述实施例承载层网关为申请紧急承载的用户分配针对紧急业务的源IP地址,并保证只允许包含有所述源IP地址的数据包通过;同时,应用层服务器在收到消息后,对包含有所述源IP地址的消息做检查,当认为该消息为使用紧急承载时,再进一步判断该消息是否为紧急业务,从而保证了紧急承载资源只能被应用于紧急业务,避免了紧急承载资源被滥用。
需要说明的是,本发明不仅限于上述几个实施例中的紧急属性信息,即分别只通过源IP地址、应用服务器提供服务的端口、及应用服务器分配的SPI来判断请求消息是否使用了紧急承载,从而进一步判断紧急承载资源是否应用于紧急业务;还可以使用其他承载层控制协议资源或者采取至少一种上述紧急属性信息来判断。
基于上述技术方案,本发明实施例还提供一种IMS中紧急呼叫控制方法,该方法在呼叫建立过程中,传递信息的中间实体接收出自同一会话的消息或应用信令,根据所述消息或信令识别所述呼叫是否滥用紧急承载资源,如果是,则禁止或重定向所述呼叫。根据消息识别所述呼叫是否滥用紧急承载资源的过程与前面实施例中的描述一致,在此不再赘述。
本发明实施例还公开了一种IMS中用于识别滥用紧急承载资源的装置,如图8所示,其为该装置的原理图:
该装置包括:消息接收单元81、紧急承载识别单元82、紧急业务识别单元83、判断单元84。其中,消息接收单元81用于接收在呼叫建立过程中出自同一会话的消息或应用信令;紧急承载识别单元82用于根据消息或应用信令,检查承载层是否使用了紧急承载;紧急业务识别单元83用于根据消息或应用信令检查应用层是否为紧急业务;判断单元84根据紧急承载识别单元82和紧急业务识别单元83的检查结果,在所述结果为承载层使用了紧急承载,但应用层为非紧急业务时,确定所述呼叫滥用紧急承载资源。
可以在紧急承载识别单元82检查到承载层是否使用了紧急承载的情况下,紧急业务识别单元83再对应用层进行检查,由紧急业务识别单元83将最终结果通知判断单元84。当然,也可以由紧急承载识别单元82和紧急业务识别单元83分别对承载层和应用层进行检查,并分别将检查结果通知判断单元84。
紧急承载识别单元82可以通过对消息接收单元81接收的来自承载层的消息中是否包含紧急承载指示信息进行检查,来确定承载层是否使用了紧急承载,如果所述消息中包含紧急承载指示信息,则确定承载层使用了紧急承载。所述紧急承载指示信息可以是:紧急标识字段、或全局专用的紧急接入点名、或能够关联到已有的紧急承载的索引等。同样,紧急业务识别单元83可以通过对消息接收单元81接收的来自应用层的消息中是否包含紧急业务指示信息进行检查,来确定应用层是否为紧急业务,如果所述消息中包含紧急业务指示信息,则确定应用层为紧急业务。所述紧急业务指示信息可以是被叫号码、用户的注册信息等。
可以将该装置集成在接入侧承载控制IP网关比如GGSN、或PDSN上。通过检测用户终端申请资源的消息和PDF返回的资源认证响应消息来实现上述功能;还可以将该装置集成在PDF上,通过检测GGSN发起的资源认证消息和P-CSCF的资源授权消息来实现上述功能。具休实现流程可参照前面对图3和图4中流程的描述。
利用该装置,不仅可以识别用户终端发起的紧急呼叫是否滥用紧急承载资源,还可以识别公共安全应答点对所述紧急呼叫发起的回呼是否滥用紧急承载资源。
另外,紧急承载识别单元82还可以通过对消息接收单元81接收的应用信令是否使用了为紧急业务预留的承载资源进行检查,来确定承载层是否使用了紧急承载,如果使用了为紧急业务预留的承载资源,则确定承载层使用了紧急承载。所述为紧急业务预留的承载资源可以是紧急承载专用的IP地址、端口、SPI等。同样,紧急业务识别单元83可以通过对消息接收单元81接收的应用信令是否包含紧急业务指示信息进行检查,来确定应用层是否为紧急业务,如果所述信令中包含紧急业务指示信息,则确定应用层为紧急业务。所述紧急业务指示信息可以是被叫号码、用户的注册信息等。
可以将该装置集成在应用层服务器比如P-CSCF上。通过检测用户终端的注册请求消息或与注册相关的如invite、message等SIP请求消息,来实现上述功能。具休实现流程可参照前面对图5、图6和图7中流程的描述。
本发明实施例还公开了一种IMS中用于识别滥用紧急承载资源的系统,如图9所示,其为该系统的原理图:
该系统包括:接入侧承载控制IP网关91和应用层服务器92,其中,
接入侧承载控制IP网关91包括资源分配装置911,用于在呼叫建立过程中,为用户终端分配资源,包括为申请紧急业务承载资源的用户分配为紧急业务预留的承载层限定的相关资源;应用层服务器92包括识别装置921,用于根据应用层服务器92接收的应用信令,识别使用所述为紧急业务预留的承载层限定的相关资源的呼叫是否滥用紧急承载资源。识别装置921的结构与图8所示本发明实施例中类似,在此不再赘述。
在IMS中,接入侧承载控制IP网关91可以是GGSN、或PDSN,应用层服务器92可以是P-CSCF。
除此之外,接入侧承载控制IP网关91还可以包括过滤装置912,用于设置针对紧急业务的承载的过滤规则,并根据所述过滤规则检查接入侧承载控制IP网关91接收到的应用信令数据包包含的承载层限定的相关资源信息,如果所述承载层限定的相关资源属于所述为紧急业务预留的承载层限定的相关资源,则允许接入侧承载控制IP网关91转发所述应用信令,否则,禁止接入侧承载控制IP网关91转发所述应用信令。通过过滤装置912,可以保证发出的与紧急业务相关的信息只能到达承载层紧急属性信息描述的实体。
利用该系统,不仅可以识别用户终端发起的紧急呼叫是否滥用紧急承载资源,还可以识别公共安全应答点对所述紧急呼叫发起的回呼是否滥用紧急承载资源。
还可以在该系统中设置控制装置(图中未示),以根据识别装置921的检查结果,控制所述呼叫的建立,如果识别装置921检查结果为所述呼叫滥用紧急承载资源,则禁止或重定向所述呼叫。所述控制装置可以和识别装置921位于不同的功能实体上,也可以位于同一功能实体上。
利用该系统,可以保证紧急承载资源只能被应用于紧急业务,避免了紧急承载资源被滥用。
以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本发明的保护范围内。
Claims (12)
1.一种IP多媒体子系统IMS中识别滥用紧急承载资源的方法,其特征在于,该方法包括:
在呼叫建立过程中,如果用于传递信息的中间实体检查接收的来自承载层的消息中包含紧急承载指示信息,或接收的应用信令使用了为紧急业务预留的承载层限定的相关资源,则确定承载层使用了紧急承载;则
检查接收的来自应用层的消息或应用信令中是否包含紧急业务指示信息,若未包含则为非紧急业务,则禁止或重定向所述呼叫。
2.根据权利要求1所述的方法,其特征在于,所述紧急业务指示信息是根据会话创建消息中的信息生成的。
3.根据权利要求2所述的方法,其特征在于,所述中间实体为接入侧承载控制IP网关;
所述来自承载层的消息为用户终端申请资源的消息,所述来自应用层的消息为策略决定功能实体返回的资源认证响应消息。
4.根据权利要求3所述的方法,其特征在于,所述接入侧承载控制IP网关包括:GPRS网关支持节点GGSN、和/或分组数据服务节点PDSN。
5.根据权利要求2所述的方法,其特征在于,所述中间实体为策略决定功能实体;
所述来自承载层的消息为GPRS网关支持节点GGSN发起的资源认证消息,所述来自应用层的消息为来自代理呼叫会话控制功能实体的资源授权消息。
6.根据权利要求3所述的方法,其特征在于,所述方法还包括:
为紧急业务预留承载层限定的相关资源;
用户设备发送应用信令,应用信令中包含了所述为紧急业务预留的承载层限定的相关资源信息。
7.根据权利要求6所述的方法,其特征在于,所述方法还包括:
接入侧承载控制IP网关根据设置的针对紧急业务承载的过滤规则,检查接收到的所述用户设备所发出的应用信令;
如果所述应用信令包含的承载层限定的相关资源信息属于所述预留的承载层限定的相关资源,则转发所述应用信令;
否则,则判定该应用信令非法。
8.根据权利要求1所述的方法,其特征在于,所述中间实体为应用层服务器;
所述应用信令为SIP消息。
9.根据权利要求1至8任一项所述的方法,其特征在于,所述呼叫为用户终端发起的紧急呼叫,或公共安全应答点对所述紧急呼叫发起的回呼。
10.一种IP多媒体子系统IMS中识别滥用紧急承载资源的装置,其特征在于,包括:
消息接收单元,用于接收在呼叫建立过程中出自同一会话的消息或应用信令;
紧急承载识别单元,用于检查如果所述消息中包含紧急承载指示信息,或应用信令使用了为紧急业务预留的承载层限定的相关资源,则确定承载层使用了紧急承载;
紧急业务识别单元,用于检查如果所述消息或应用信令中未包含紧急业务指示信息,则确定应用层为非紧急业务;
判断单元,根据所述紧急承载识别单元和所述紧急业务识别单元的检查结果,在所述结果为承载层使用了紧急承载,但应用层为非紧急业务时,禁止或重定向所述呼叫。
11.一种IP多媒体子系统IMS中识别滥用紧急承载资源的系统,包括接入侧承载控制IP网关和应用层服务器,其特征在于,
所述接入侧承载控制IP网关包括资源分配装置,用于在呼叫建立过程中,为用户终端分配资源,包括为申请紧急业务承载资源的用户分配预留的承载层限定的相关资源;
所述应用层服务器包括识别装置,用于检查所述应用层服务器接收的应用信令如果包含了为紧急业务预留的承载层限定的相关资源,则确定承载层使用了紧急承载,检查所述应用信令中是否包含紧急业务指示信息,如果未包含则为非紧急业务,则禁止或重定向所述呼叫。
12.根据权利要求11所述的系统,其特征在于,
所述接入侧承载控制IP网关还包括过滤装置,用于设置针对紧急业务的承载的过滤规则,并根据所述过滤规则检查所述接入侧承载控制IP网关接收到的应用信令使用的承载层限定的相关资源,如果应用信令包含的承载层限定的相关资源属于所述为紧急业务预留的承载层限定的相关资源,则允许所述接入侧承载控制IP网关转发所述应用信令,否则,禁止或重定向所述接入侧承载控制IP网关转发所述应用信令。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101306546A CN101110991B (zh) | 2006-07-14 | 2007-07-12 | Ims中识别滥用紧急承载资源的方法、装置及系统 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200610099415 | 2006-07-14 | ||
CN200610099415.4 | 2006-07-14 | ||
CN2007101306546A CN101110991B (zh) | 2006-07-14 | 2007-07-12 | Ims中识别滥用紧急承载资源的方法、装置及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101110991A CN101110991A (zh) | 2008-01-23 |
CN101110991B true CN101110991B (zh) | 2010-06-23 |
Family
ID=39042848
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101306546A Active CN101110991B (zh) | 2006-07-14 | 2007-07-12 | Ims中识别滥用紧急承载资源的方法、装置及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101110991B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9148769B2 (en) | 2008-05-07 | 2015-09-29 | Qualcomm Incorporated | System, apparatus and method to enable mobile stations to identify calls based on predetermined values set in a call header |
CN101730039B (zh) * | 2009-05-07 | 2012-12-19 | 中兴通讯股份有限公司 | 一种ip多媒体子系统业务的建立方法及系统 |
CN101730037A (zh) * | 2009-05-08 | 2010-06-09 | 中兴通讯股份有限公司 | 一种ip多媒体子系统业务的建立方法及系统 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1422507A (zh) * | 2000-04-10 | 2003-06-04 | 诺基亚有限公司 | 移动ip网络中的电话服务 |
CN1505908A (zh) * | 2001-04-27 | 2004-06-16 | ��˹��ŵ�� | 处理网络识别紧急会话的方法和系统 |
-
2007
- 2007-07-12 CN CN2007101306546A patent/CN101110991B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1422507A (zh) * | 2000-04-10 | 2003-06-04 | 诺基亚有限公司 | 移动ip网络中的电话服务 |
CN1505908A (zh) * | 2001-04-27 | 2004-06-16 | ��˹��ŵ�� | 处理网络识别紧急会话的方法和系统 |
Also Published As
Publication number | Publication date |
---|---|
CN101110991A (zh) | 2008-01-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1999910B1 (en) | Quality of service configuration for wireless communication | |
EP1959695B1 (en) | Method and system for establishing or modifying a connection | |
US9386612B2 (en) | Method and system for establishing a connection between network elements | |
US9203504B2 (en) | System and method for enhanced paging and quality of service establishment in mobile satellite systems | |
US20110128955A1 (en) | Emergency services for packet networks | |
US20110182285A1 (en) | Sessions In A Communication System | |
JP2007151187A (ja) | Pdpコンテクストエラー取り扱い方法 | |
EP2127264A1 (en) | Enhanced media control | |
KR100697119B1 (ko) | 무선 통신 네트워크에서 베어러 인가를 위한 방법 및 시스템 | |
EP3182748B1 (en) | Emergency session request handling in a network | |
CN101110991B (zh) | Ims中识别滥用紧急承载资源的方法、装置及系统 | |
CN104468481A (zh) | 一种实现媒体QoS承载资源控制的方法及装置 | |
CN101106813B (zh) | 识别滥用紧急承载资源的方法及接入侧承载控制ip网关 | |
CA2741642C (en) | Method and system for realizing emergency calling service in high rate packet data network | |
KR102003694B1 (ko) | 이동통신시스템에서 세션 설정 방법 및 장치 | |
EP2609727B1 (en) | Method and apparatus for registration of an emergency service in packet data connections | |
KR100462026B1 (ko) | 이동 멀티미디어 서비스를 위한 프록시 서버 장치 및폴리시 제어 방법 | |
El Barachi et al. | Enhancing the QoS and resource management aspects of the 3GPP IMS emergency service architecture | |
WO2008009234A1 (fr) | Procédé d'identification d'utilisation abusive des ressources de supports d'urgence, dispositif et système associés |
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 |