專利名稱：Ims中識別濫用緊急承載資源的方法、裝置及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及通信技術領域，特別是指一種IP多媒體子系統(tǒng)(IMS， Internet Multiedia Subsystem)中識別濫用緊急承載資源的方法、裝置及系統(tǒng)。
背景纟支術
在緊急的狀態(tài)下，用戶會使用用戶設備(UE, User Equipment)呼叫公 共安全應答點(PSAP, Public Safety Answering Point)獲取幫助，而PSAP 也有可能在用戶掛機后對用戶發(fā)起回叫，以便了解更多的信息。本文提到的 緊急業(yè)務是指用戶發(fā)起緊急呼叫，還可以包括PSAP回叫用戶的情況，當然， 也可以不包括PSAP回叫的情況。
圖1所示為現(xiàn)有IMS域緊急呼叫的整體流程框架圖。圖中實線表示UE 發(fā)起的緊急呼叫，虛線表示PSAP發(fā)起的回呼。UE IO發(fā)起的緊急呼叫通過 GPRS網關支持節(jié)點(GGSN， Gateway GPRS Support Node) 20、代理呼叫 會話控制功能(P-CSCF, Proxy Call Session Control Function)實體40、緊急 呼叫會話控制功能(E-CSCF)實體50到達PSAP 80, PSAP 80發(fā)起的回呼 通過服務呼叫會話控制功能(S-CSCF)實體60、 P-CSCF 40、 GGSN20到達 UE 10。如果PSAP位于公共交換電話網(PSTN, Public Switched Telephone Networ)或電路域(CS， Circuit Switched)網絡，則E-CSCF發(fā)往PSAP和 PSAP發(fā)往S-CSCF的信令需要經過々某體網關控制功能(MGCF, Media Gateway Control Function)實體進行轉換，如果PSAP在IP域，則不需經過 MGCF。圖1中策略決定功能(PDF， Policy Decision Function)實體用于承載資 源的管理。
由于緊急呼叫是一個本地的服務，所以用戶在漫游時，GGSN、 PDF、 P-CSCF、 E-CSCF、 MGCF 1和PSAP都是漫游地的，但是當PSAP回叫時則 會有兩種可能， 一種是使用漫游地的MGCF1即MGCF70a接入IMS域，一 種是通過用戶歸屬域的MGCF2即MGCF70b接入IMS域。
下面結合IMS承載資源的管理流程對現(xiàn)有的緊急呼叫流程進行說明。
圖2所示為現(xiàn)有的IMS承載資源的管理流程示意圖。
步驟101-102,用戶決定發(fā)起一個呼叫后，首先通過UE發(fā)起一個接入 側的承載資源申請， 一般是向GGSN發(fā)送一個創(chuàng)建組數(shù)據(jù)協(xié)議(create PDP ) 請求，如果是為緊急業(yè)務申請的資源，則該請求中將攜帶一個緊急承載指示， 如緊急承載標識或者緊急的接入點名稱(APN, Access Point Name)等。GGSN 和接入網給UE分配承載資源后，GGSN返回 一個申請承載資源成功的響應， 如create PDP response 。
步驟103- 104, UE使用申請到的承載資源發(fā)送SIP的請求(INVITE ) 消息，其IP包的目的地址是P-CSCF。該消息通過GGSN進行中轉，如果進 行的是緊急呼叫，那么該INVITE消息中含有緊急業(yè)務指示。
步驟105- 106， P-CSCF將該請求轉發(fā)給其它的設備，如E-CSCF等， 進行緊急呼叫的建立，之后，接收INVITE的200消息。
步驟107- 108， P-CSCF將INVITE和200中得到的用戶連接信息(如 IP地址端口等)和服務質量(QoS, Quality of Service )信息(如帶寬等)發(fā) 送給PDF,通常使用的是Diamter協(xié)議的AAR (AA-Request)消息，之后， 接收來自PDF的響應消息，通常使用的是Diamter的AAA ( AA-Answer)消 息。如果是本會話的第一個響應消息，那么該消息中必須攜帶一個Token, 該Token標識了該PDF和本次會話。
步驟109-110, P-CSCF將步驟106中收到的200消息通過GGSN前傳 給UE,如果以前沒有攜帶過Token,那么需要將Token添加到200消息中。
步驟lll, l正收到P-CSCF發(fā)來的消息后，根據(jù)得到的連接信息和QoS 信息為媒體信息發(fā)起資源申請過程，這是一個創(chuàng)建或更新PDP的過程，UE 發(fā)送的create PDP消息中攜帶有Token,如果是緊急承載請求，該消息中將 含有某個指示，根據(jù)該指示GGSN可以知道這是一個緊急業(yè)務的承載請求。 上述某個指示可以是與已申請的緊急承載資源的關聯(lián)關系，也可以是緊急承 載標識等。
步驟112， GGSN在收到這個申請消息后，根據(jù)其中的Token,向PDF 發(fā)起承載資源的認證請求，通常是通用開放策略服務協(xié)議(COPS, Common Open Policy Service Protocol)的REQ消息(COPS REQuest message )。
步驟113, PDF將相關的用戶連接信息，QoS信息和其它一些信息發(fā)送 給GGSN,通常使用COPS的DEC消息(COPS DECision message )。
步驟114， GGSN根據(jù)收到的DEC消息核對承載層申請的資源，例如， 核對IP地址端口和帶寬信息是否符合應用層的要求，如果符合，將在接入網 給UE分配承載資源，同時給UE發(fā)送承栽資源請求的響應消息。
步驟115,如果承載申請成功，UE將發(fā)送數(shù)據(jù)進行通話，該數(shù)據(jù)的IP 包會傳送到GGSN，其目的地址是相關的媒體設備。
步驟116, GGSN將數(shù)據(jù)包轉發(fā)到IP包的目的地媒體設備，所述媒體設 備包括PSAP所控制的媒體設備和MGCF所控制的媒體設備。
在步驟101和步驟111中，表示UE申請的資源為緊急承載的指示為 一個緊急標識字段，或者一個全局專用的緊急APN,或者一個能夠關聯(lián)到已 有的緊急承載的索引。
基于上述管理流程，現(xiàn)有緊急業(yè)務采用的方法是首先在GGSN上針對 緊急APN配置過濾規(guī)則，僅讓攜帶了指定的用于緊急呼叫的P-CSCF的地址 的IP包通過GGSN，保證UE發(fā)出的IP包只能到達用于緊急呼叫的P-CSCF, 同時也只能接收這些地址過來的IP包。如果是為緊急業(yè)務申請承載資源，那 么在申請時，也就是圖2中的步驟101和步驟111將攜帶緊急承載指示。那 么GGSN收到來自或發(fā)往這些地址所申請的承載資源時，將會使用過濾規(guī)則 來過濾所有的IP包，該處理發(fā)生在步驟104,步驟110和步驟116。
而緊急承載資源通常享有比普通承載資源更高的優(yōu)先級和QoS,甚至在 普通呼叫因為漫游限制不允許使用承載資源的情況，緊急承載資源也是可以 使用的，同時使用緊急承載資源的緊急呼叫還有可能在承載層是免費的。但 GGSN的功能只是轉發(fā)UE發(fā)出的IP包，并不解析其應用層內容，上述過濾 規(guī)則能限制UE發(fā)出的IP包只能到達一些特定的用于緊急業(yè)務的P-CSCF， 但并不限制P-CSCF對接收到的內容解析后是否仍進行緊急業(yè)務處理，這樣
用戶就有可能在接入GGSN時申請緊急的承載資源，而在上層應用使用普通 的呼叫，這樣就可以在接入側逃避計費及漫游限制等，從而導致濫用緊急承 載資源。

發(fā)明內容
有鑒于此，本發(fā)明提供一種IMS中識別濫用緊急承載資源的方法、裝置 及系統(tǒng)，以防止緊急承載資源被濫用。
本發(fā)明的技術方案包括
一種IMS中識別濫用緊急承載資源的方法，該方法包括
在呼叫建立過程中，如果用于傳遞信息的中間實體確定承載層使用了緊 急承載，則檢查應用層是否為緊急業(yè)務；
若為非緊急業(yè)務，則確定該呼叫濫用緊急承載資源。
一種IMS中識別濫用緊急承載資源的裝置，包括
消息接收單元，用于接收在呼叫建立過程中出自同一會話的消息或應用 信令；
緊急承載識別單元，用于根據(jù)所述消息或應用信令，檢查承載層是否使 用了緊急岸義載；
緊急業(yè)務識別單元，用于根據(jù)所述消息或應用信令^r查應用層是否為緊 急業(yè)務；
判斷單元，根據(jù)所述緊急承載識別單元和所述緊急業(yè)務識別單元的檢查 結果，在所述結果為承載層使用了緊急承載，但應用層為非緊急業(yè)務時，確 定所述呼叫濫用緊急承載資源。
一種IMS中識別濫用緊急承載資源的系統(tǒng)，包括接入側承載控制IP網 關和應用層服務器，
所述接入側承載控制IP網關包括資源分配裝置，用于在呼叫建立過程 中，為用戶終端分配資源，包括為申請緊急業(yè)務承載的用戶分配預留的承載
層限定的相關資源；
所述應用層服務器包括識別裝置，用于根據(jù)所述應用層服務器接收的應 用信令，識別使用所述承載層限定的相關資源的應用是否濫用緊急承載資源。
本發(fā)明在呼叫建立過程中，用于傳遞信息的中間實體判斷出在同一服務 相關請求中，如果承載層使用的是緊急承載，再判斷應用層是否是緊急業(yè)務 請求，若為非緊急業(yè)務請求，則判定該呼叫濫用緊急承載資源。本發(fā)明能夠 迅速有效地識別出濫用緊急承載資源的呼叫，從而保證了緊急承載資源只能 被應用于緊急業(yè)務，避免了緊急承載資源被濫用。


圖1是現(xiàn)有的IMS域的緊急呼叫的流程框架圖2是現(xiàn)有的MS承載資源的管理流程示意圖3是根據(jù)本發(fā)明第一實施例的承載資源管理流程示意圖；■
圖4是根據(jù)本發(fā)明第二實施例的承載資源管理流程示意圖5是根據(jù)本發(fā)明第三實施例的承載資源管理流程示意圖6是根據(jù)本發(fā)明第四實施例的承載資源管理流程示意圖7是根據(jù)本發(fā)明第五實施例的承載資源管理流程示意圖8是根據(jù)本發(fā)明實施例中IMS中識別濫用緊急承載資源的裝置原理
圖9是根據(jù)本發(fā)明實施例中IMS中識別濫用緊急承載資源的系統(tǒng)原理圖。
具體實施例方式
下面結合附圖對本發(fā)明優(yōu)選實施例做進一步的詳細說明。
本發(fā)明實施例在同一服務相關請求中，用于傳遞信息的中間實體獲知承 載層和應用層的緊急屬性信息，如果承載層使用的是緊急承載，那么將檢查 應用層是否是緊急業(yè)務，若為非緊急業(yè)務，則判定該請求濫用緊急承載資源。 所述緊急屬性信息包括承載緊急指示和業(yè)務緊急指示。
上述用于傳遞信息的中間實體可以是接入側的承載控制IP網關，如 GGSN、分組數(shù)據(jù)服務節(jié)點(PDSN)等，還可以是PDF或應用服務器等，
當然并不限于此。而且來自應用層的消息中的緊急業(yè)務指示可根據(jù)會話創(chuàng)建 消息中插入的緊急業(yè)務指示生成。
圖3和圖4是基于本發(fā)明方法的兩個具體實施例。
參見圖3,本實施例由UE發(fā)起緊急呼叫，且由GGSN判斷承載層和應 用層的消息中是否都含有緊急指示。
步驟201, UE發(fā)起會話INVITE請求，如果是緊急業(yè)務，則INVITE請 求中將攜帶緊急業(yè)務指示標明該請求為一個緊急業(yè)務。緊急業(yè)務指示可以是 INVITE消息中的某個頭域或者是頭域中的某個參數(shù)，例如 "priority: emergency"。
步驟202-203, P-CSCF收到該請求后，檢查消息中是否含有緊急業(yè)務 指示，如果有，則P-CSCF在本地標記該會話為緊急業(yè)務，并將該請求i 各由 到指定的媒體設備例如E-CSCF進行處理，如果沒有，則不用標記，P-CSCF 按常規(guī)消息前傳該請求。之后，P-CSCF接收反饋的200響應消息。
步驟204, P-CSCF給PDF發(fā)送AAR消息，如果P-CSCF標記過本次會 話是一個緊急業(yè)務，則AAR消息中將攜帶緊急業(yè)務指示，該指示可以是AAR 消息中的一個字段，否則AAR消息中不用攜帶該緊急業(yè)務指示。
步驟205， PDF給P-CSCF回響應消息AAA,如果是本會話的第一個響 應消息，那么該消息中必須攜帶一個Token,該Token標識了該PDF和本次 會話。
步驟206, P-CSCF接收到PDF返回的AAA消息后，將200響應前傳給UE。
步驟207, UE收到P-CSCF發(fā)來的消息后，根據(jù)得到的用戶連接信息和 QoS信息向GGSN發(fā)起承載資源申請的消息，這是一個創(chuàng)建或更新PDP的 過程，消息中攜帶有Token,如果是為緊急業(yè)務申請承載資源，那么申請消 息中需要攜帶緊急承載指示以表示申請的是緊急的承載資源，該緊急承載指 示可以為一個緊急標識字段， 一個全局專用的緊急APN，或者一個能夠關聯(lián) 到已有的緊急承載的索引。
步驟208， GGSN在收到這個申請消息后，根據(jù)Token,將會向PDF發(fā) 起承載資源的認證請求，通常是COPS的REQ消息。
步驟209, PDF給GGSN發(fā)送DEC消息，如果針對本次會話，PDF從 P-CSCF收到過來自應用層的緊急業(yè)務指示，即接收到的AAR消息中包含了 緊急業(yè)務指示，那么其發(fā)送的DEC消息也攜帶緊急業(yè)務指示，否則，所發(fā)送 的PDF消息中不添加緊急業(yè)務指示。
步驟210， GGSN收到DEC消息后，首先4企查用戶在資源申請過程中是 否攜帶了緊急承載指示，如果是，則檢查收到的DEC消息中是否也含有緊急 業(yè)務指示，如果DEC消息中沒有包含緊急業(yè)務指示，則GGSN判定為濫用 緊急承載資源，之后，可以進行相關處理，如阻斷當前呼叫流程，并進行相 應記錄等；如果收到的DEC消息中含有緊急業(yè)務指示，則繼續(xù)正常的流程， 此時表示該呼叫確實為緊急呼叫流程。
參見圖4,本實施例由如PSAP等媒體設備發(fā)起對UE的回呼，且由PDF 判斷承載層和應用層的消息中是否都含有緊急指示，且當前認為PSAP回叫
也屬于緊急業(yè)務。
步驟301, P-CSCF收到了用于呼叫UE的INVITE消息。
步驟302,如果P-CSCF識別出該請求是一個PSAP的回叫，P-CSCF將 在發(fā)給PDF的AAR消息中攜帶緊急業(yè)務指示。如果不是，則不攜帶緊急業(yè) 務指示，具體的識別方法可以通過INVITE中是否包含緊急指示頭域，或者 根據(jù)INVITE中的主叫用戶身份等方法進行識別。
步驟303, PDF給P-CSCF回響應消息AAA,如果是本會活的第一個響 應消息，那么該消息中必須攜帶一個Token,該Token標識了該PDF和本次會話。
步驟304, P-CSCF將INVITE請求前傳給UE。
步驟305, UE接收到P-CSCF發(fā)來的消息后，根據(jù)得到的用戶連接信息 和QoS信息向GGSN發(fā)起承載資源申請的消息，這是一個創(chuàng)建或更新PDP 的過程，消息中攜帶有Token,如果是為緊急業(yè)務申請承載資源，那么該消
息中還需要攜帶緊急承載指示以表示申請的是緊急承載資源。
步驟306, GGSN在收到這個申請消息后，根據(jù)Token,將會向PDF發(fā) 起承載資源認證的REQ消息。如果申請消息中攜帶了緊急承載指示，那么 REQ消息中也將攜帶緊急承載指示。
步驟307， PDF收到REQ消息后，檢查出該消息中攜帶了承載層的緊急 承載指示，則檢查P-CSCF針對本次會話下發(fā)的消息中是否攜帶有應用層的 緊急業(yè)務指示。如果沒有，則PDF判定為濫用緊急承載資源，之后，可以進 行相關處理，如阻斷當前呼叫流程，并進行相應記錄等；如果有，則繼續(xù)正 常的流程，此時表示該呼叫確實為緊急呼叫流程。
上述實施例用于當PSAP發(fā)起對UE的回呼時，PDF通過判斷承載層和 應用層的消息中是否都含有緊急指示，來識別出濫用緊急承載資源的呼叫， 從而保證了緊急承載資源只能被應用于緊急業(yè)務，避免了緊急承載資源被濫 用。
以上僅是兩個具體實施例而已，可以理解，在實際應用中，當UE發(fā)起 緊急呼叫時，也可以由PDF判斷承載層和應用層的消息中是否都含有緊急指 示；當PSAP發(fā)起回呼時，也可以由GGSN判斷承載層和應用層的消息中是 否都含有緊急指示。
與此同時，本發(fā)明實施例還可以在承載層網關上為緊急業(yè)務的承載設置 過濾規(guī)則，保證允許包含了為緊急業(yè)務預留的承載層限定的相關資源的數(shù)據(jù) 包通過；對應的，應用層服務器根據(jù)承載層控制的協(xié)議層的信息判斷該消息 是否采用的是為緊急業(yè)務預留的承載資源，若是，則所述應用層服務器將檢 查該請求是否為緊急業(yè)務，如果不是，將判斷該請求是非法請求；否則，將 繼續(xù)后續(xù)的流程。其中，判斷承載層是否為^f吏用緊急承載可通過初始的消息， 例如注冊(register)消息判斷，應用層在判斷是否為緊急業(yè)務時，可通過 注冊(register)消息判斷，還可通過注冊(register)消息的響應及后續(xù)的invite、 message等SIP消息判斷。所述承載層控制協(xié)議至少包括IP、傳輸層協(xié)議， 比如UDP ( User,用戶數(shù)據(jù)包協(xié)i義 Datagram Protocol )， TCP ( Transmission Control Protocol,傳輸控制十辦i義)，端口， AH (Authentication Header, i人i正頭協(xié)議)，ESP (Encapsulating Security Payload，封裝安全負載協(xié)議)，SPI (Security Parameter Index,安全參數(shù)索引)等；為緊急業(yè)務預留的承載層限 定的相關資源至少包括UE的IP地址、應用服務器的IP地址、應用服務器 提供服務的端口、應用服務器提供的傳輸層協(xié)議，應用服務器為UE分配的 SPI及其可能組合。
基于上述技術方案，本發(fā)明實施例還公開了一種IP多媒體子系統(tǒng)IMS 中識別濫用緊急承載資源的方法在P-CSCF上為緊急業(yè)務的消息預留專用 服務端口 ，并判斷從該端口相關的應用層消息是否為緊急業(yè)務。
如圖5所示，其為本發(fā)明第三實施例的承載資源管理流程示意圖，該方 法包括以下步驟
步驟400 ~步驟401,在應用服務器如P-CSCF上為緊急業(yè)務預留一個緊 急承載專用的端口，例如9000;在系統(tǒng)接入側的承載控制IP網關如'GGSN 上設置針對所述緊急業(yè)務的承載的過濾規(guī)則，例如，只允許發(fā)往所述P-CSCF 的9000端口的使用緊急承載的IP包通過，而發(fā)往該P-CSCF的其它端口的 使用緊急承載的IP包不允許通過。此外，該過濾規(guī)則還可以讓緊急業(yè)務相關 的媒體通行。
步驟402,用戶UE向GGSN發(fā)送創(chuàng)建組數(shù)據(jù)協(xié)議(create PDP )請求來 申請緊急業(yè)務的承載資源，所述請求中攜帶緊急承載指示，如緊急承載標識 或者緊急的APN等。
步驟403， GGSN根據(jù)所述緊急承載指示，如果識別出該UE申請的是 緊急承載，則GGSN為UE分配緊急的承載資源，并向UE返回一個申請承 載資源成功的響應，如create PDP response。該響應包括GGSN為UE分配的 源IP地址，可能還包括能夠訪問的遠端IP地址及端口，其中，所述遠端IP 地址為P-CSCF的IP地址，所述目的端口為P-CSCF預置的緊急業(yè)務專用端 n 。
步驟404， UE使用申請到的緊急承載資源發(fā)起注冊(register)請求消 息，該請求消息IP包的源IP地址為GGSN為其分配的所述源IP地址，目的 IP地址是P-CSCF的IP地址，端口是9000;其IP包的格式優(yōu)選為目的IP地
址+UDP端口；如果進行的是緊急呼叫，所述消息還包括緊急業(yè)務指示，這
里所述緊急業(yè)務指示可以是用戶的注冊信息等。
該注冊請求消息通過GGSN進行中轉，在該過程中，GGSN首先根據(jù)預 置的過濾規(guī)則來檢查所述注冊請求消息IP包，如果該IP包不是發(fā)往P-CSCF 的9000端口，那么GGSN將判定該請求為非法請求；否則，執(zhí)行步驟405。
步驟405, GGSN將所述注冊請求消息轉發(fā)給P-CSCF， P-CSCF通過9000 端口接收該消息，此時，P-CSCF認為該消息使用的承載為緊急承載。
步驟406~407, P-CSCF將所注冊請求消息發(fā)送給其它服務器，其它服務 器返回相應的401響應消息。
步驟408 ~ 409, P-CSCF為該UE分配下次通信的端口 ，及ESP協(xié)議的
SPI,同時標記通過所述下次通信端口收到的請求為使用的是緊急承載的消 臺
同時，P-CSCF將401響應消息由GGSN轉發(fā)給UE,其中，所述401 響應消息中還包括P-CSCF新分配的端口號和SPI。
步驟410, UE向GGSN重新發(fā)起注冊(register)請求消息，此時UE發(fā) 出的注冊請求消息IP包的格式是包含有IP地址+ESP。其中，所述IP地址包 括GGSN為該UE分配的源IP地址和P-CSCF的目的IP地址，所述ESP包 括P-CSCF為UE分配的SPI。
GGSN在收到該注冊請求消息后，檢查所述消息中的源IP地址是否為 UE在申請緊急承載資源時GGSN分配給該UE的IP地址，如果不是，則GGSN 可以判定該請求為非法請求；否則，執(zhí)行下述步驟。
步驟411-416, GGSN將所述注冊請求消息發(fā)送給P-CSCF, P-CSCF通 過所述新分配的端口收到該UE的注冊請求消息后，對該請求的IP包進行 ESP解碼。
P-CSCF檢查所述注冊請求消息中是否包含緊急業(yè)務指示，若包含，則 認為該請求為緊急業(yè)務，則P-CSCF才艮據(jù)所述注冊請求完成后續(xù)的注冊流程， 并在注冊完成后，將200響應消息由GGSN發(fā)送至UE;若該請求不包含緊 急業(yè)務指示，那么P-CSCF認為該請求是非法請求。
此外，如果P-CSCF在此過程中不檢查所述注冊請求消息是否為緊急業(yè) 務，那么P-CSCF會在后續(xù)當UE發(fā)起與該注冊相關的如invite、 message等 SIP請求時，檢查該請求是否為緊急業(yè)務，若不是，那么P-CSCF將判定該 相關請求是非法請求。
需要說明的是，在后續(xù)的正常會話過程中，如果需要，P-CSCF還通知 GGSN增加新的媒體過濾規(guī)則，以確保協(xié)商的媒體部分能夠通過GGSN。具 體的通知新的媒體過濾規(guī)則的方法與上述實施例相同，這里不再贅述。
除此之外，上述步驟404中GGSN還可以檢查UE使用緊急承載發(fā)來的 請求消息中的源IP地址是否為該UE在申請緊急承載資源時GGSN分配給該 UE的IP地址，若不是，則GGSN判定該請求為非法請求。
上述實施例通過在應用層服務器上為緊急業(yè)務分配專用端口 ，并在承載 層網關上針對緊急業(yè)務的承載設置過濾規(guī)則，允許包含有應用層服務器專用 端口的數(shù)據(jù)包通過；同時，所述應用層服務器如果從分配的專用端口收到數(shù)
據(jù)包，則認為該數(shù)據(jù)包為采用緊急承載的消息，進而判斷從該專用端口獲取 到的消息是否為緊急業(yè)務,從而保證了緊急承載資源只能被應用于緊急業(yè)務， 避免了緊急承載資源被濫用。
除此之外，本發(fā)明實施例并不限于上述的通過設置緊急業(yè)務的端口來識 別是否采用了緊急承載的消息，例如，所述應用服務器還可以為緊急業(yè)務預 留一個如SPI等范圍，當接收到的消息中有該范圍內的SPI時，則判斷該消 息是否為緊急業(yè)務。
如圖6所示，其為本發(fā)明第四實施例的承載資源管理流程示意圖，該方 法包括以下步驟
步驟500 ~步驟501,在應用服務器如P-CSCF上不僅設置緊急業(yè)務專用 端口 ，還為緊急業(yè)務預留一個SPI范圍，例如20000 - 30000。同時，在P-CSCF 上還設置SPI的分配A見則，即P-CSCF如果是AV緊急業(yè)務專用的端口收到了 注冊請求消息，那么為該用戶UE分配從預留SPI范圍中的SPI,例如20006。
該過濾規(guī)則還可以讓緊急業(yè)務相關的媒體通行。
在系統(tǒng)接入側的承載控制IP網關如GGSN上設置針對緊急業(yè)務的承載 的過濾規(guī)則，例如允許用戶發(fā)往P-CSCF的所述SPI范圍內的IP包(如SPI 值為20000-30000的IPSEC包)能夠通過，而發(fā)往該P-CSCF的其它SPI 范圍的IP包不可以通過，允許用戶發(fā)往P-CSCF指定端口的IP包通過。
步驟502， l正向GGSN發(fā)送一個創(chuàng)建組數(shù)據(jù)協(xié)議(create PDP )請求來 申請緊急業(yè)務的承載資源，所述請求中攜帶緊急承載指示，如緊急承載標識 或者緊急的APN等。
步驟503， GGSN根據(jù)所述緊急承載指示如果識別出該l正申請的是緊 急承載，則GGSN為UE分配緊急的承載資源，并向UE返回一個申請承載 資源成功的響應，如create PDP response。該響應包括GGSN為UE分配的源 IP地址，可能還包括能夠訪問的遠端IP地址及端口，其中，所述端口為 P-CSCF預置的緊急業(yè)務專用端口 。
步驟504， UE使用申請到的緊急承載資源發(fā)起注冊(register)請求消息， 所述請求消息IP包的源IP地址為GGSN為其分配的所述源IP地址，目的IP 地址是P-CSCF的IP地址，UDP端口是P-CSCF專用端口；其IP包的格式 優(yōu)選為IP地址+UDP端口；如果進行的是緊急呼叫，所述消息還包括緊急業(yè) 務指示，這里所述緊急業(yè)務指示可以是用戶的注冊信息等。
該注冊請求消息通過GGSN進行中轉，在該過程中，GGSN首先根據(jù)預 置的過濾規(guī)則來檢查該注冊請求消息IP包，如果所述IP包中的目的端口號 不是發(fā)往P-CSCF的專用端口，那么GGSN將判定該請求為非法請求；否則， 執(zhí)行步驟505。
步驟505, GGSN將所述注冊請求消息轉發(fā)給P-CSCF。
步驟506~507， P-CSCF將所注冊請求消息發(fā)送給其它服務器，其它服務 器返回相應的401響應消息。
步驟508 ~ 509， P-CSCF為該UE分配下次通信的端口及ESP協(xié)議的SPI。 如果是從緊急業(yè)務專用端口收到的請求，那么P-CSCF認為該請求使用的是
緊急承載資源，此時，所述SPI為從緊急業(yè)務預留的SPI范圍中選取的。
同時，P-CSCF將401響應消息由GGSN轉發(fā)給UE,其中，401響應消 息中還包括P-CSCF新分配的端口號和SPI。
步驟510， UE向GGSN重新發(fā)起注冊(register)請求消息，此時UE發(fā) 出的注冊請求消息IP包包含有IP地址+ESP。其中，所述IP地址包括GGSN 為UE分配的所述源IP地址和P-CSCF的目的IP地址，所述ESP包括P-CSCF 為UE分配的SPI。
GGSN在收到該注冊請求消息后，檢查該消息中的SPI是否屬于為緊急 業(yè)務預留的范圍內的，如果不是，則GGSN可以判定該請求為非法請求；否 則，執(zhí)行下述步驟。
步驟511-515， GGSN將所述注冊請求消息發(fā)送給P-CSCF, P-CSCF通 過所述新分配的端口收到該UE的注冊請求消息后，對所述請求的IP包進行 ESP解碼。
P-CSCF檢查解碼后的注冊請求消息中的SPI是否為緊急業(yè)務專用范圍 內的，若是，則認為該消息為采用的緊急承載資源的消息，則P-CSCF進一 步檢查該消息是否為緊急業(yè)務，如果不是，那么P-CSCF認為該請求是非法 請求。否則，P-CSCF #4居所述注冊請求完成后續(xù)的注冊流程，并在注冊完 成后，將200響應消息由GGSN發(fā)送至UE。
此外，如果P-CSCF在此過程中不檢查所述注冊請求消息是否為緊急業(yè) 務，那么P-CSCF會在后續(xù)當UE發(fā)起與該注冊相關的如invite、 message等 SIP請求時，檢查該請求是否為緊急業(yè)務，若不是，則P-CSCF將判定該相 關請求是非法請求。
上述實施例通過在承載層網關上設置過濾規(guī)則，保證允許包含了使用緊 急承載層限定的相關資源信息的數(shù)據(jù)包通過；同時，應用層服務器在收到用 戶發(fā)出的IP包的消息后，根據(jù)該消息中的SPI判斷出該消息為包含了使用緊 急承載層限定的相關資源信息的消息時，對該消息進行緊急業(yè)務檢查，進一 步判斷該消息是否為緊急業(yè)務，從而保證了緊急承載資源只能被應用于緊急
業(yè)務，避免了緊急承載資源被濫用。
與此同時，本發(fā)明實施例還公開了一種IMS中識別濫用緊急承載資源的
方法在GGSN上設置允許包含有預置范圍內的IP地址的請求通過，其中， 所述預置范圍內的IP專用于緊急承載資源。P-CSCF當收到該IP地址范圍的 請求時，檢查該請求是否為緊急業(yè)務。
如圖7所示，其為本發(fā)明第五實施例的承載資源管理流程示意圖，該方 法包括以下步驟
步驟600，在GGSN上為緊急業(yè)務預留一個源IP地址范圍，用于為申請 緊急業(yè)務的承載資源的UE分配。同時，在GGSN上還設置過濾規(guī)則，允許 包含有所述預留范圍內的IP地址的數(shù)據(jù)包通過，而包含其它源IP地址的IP 包不可以通過。該過濾MJ'j還可以讓緊急業(yè)務相關的^某體通行。
步驟601，在P-CSCF上通過配置或者其它手段獲知GGSN上預留的源 IP地址范圍，以便在P-CSCF收到所述預留IP范圍內的請求時，檢查該請求 是否為緊急業(yè)務。
步驟602, UE向GGSN發(fā)送一個創(chuàng)建組數(shù)據(jù)協(xié)議(create PDP )請求來 申請緊急業(yè)務的承載資源，所述請求中攜帶緊急承載指示，如緊急承載標識 或者緊急的APN等。
步驟603， GGSN根據(jù)所述緊急承載指示識別出該UE申請的是緊急承 載，為該用戶分配緊急的承載資源，其中，所述承載資源中的源IP地址為所 述緊急業(yè)務預留的地址范圍中的IP地址。
同時，GGSN向UE返回一個申請承載資源成功的響應，如create PDP response。其中所述響應包括GGSN為UE分配的源IP地址。
步驟604， UE使用申請到的緊急承載資源分配發(fā)起注冊(register)請求 消息，由于所述請求消息IP包是使用緊急承載資源發(fā)送的，GGSN將檢查該 消息的源IP地址是否屬于預留的范圍內的，如果不是，則認為該消息為非法 請求；否則，執(zhí)行下述步驟。
步驟605, GGSN將所述注冊請求消息轉發(fā)給P-CSCF, P-CSCF接收該
消息，根據(jù)該消息中的IP確定該消息使用的承載為緊急承載。
步驟606-607， P-CSCF將所述注冊請求消息發(fā)送給其它服務器，其它服 務器返回相應的401響應消息。
步驟608 ~ 609， P-CSCF為該UE分配下次通信的端口及ESP協(xié)議的SPI。
同時，P-CSCF將401響應消息由GGSN轉發(fā)給UE,其中，所述401 響應消息中還包4舌P-CSCF新分配的端口號和SPI。
步驟610, UE向GGSN重新發(fā)起注冊(register)請求消息，此時UE發(fā) 出的所述注冊請求消息IP包包含有IP地址+ESP。其中，所述IP地址包括 GGSN為UE分配的專用于緊急業(yè)務的源IP地址和P-CSCF的目的IP地址， 所述ESP包括P-CSCF為UE分配的SPI。
GGSN在收到該注冊請求消息后，檢查該消息中的源IP地址是否屬于為 緊急業(yè)務預留的IP地址范圍，如果不是，則GGSN可以判定該請求為非法 請求；否則，執(zhí)行下述步驟。
步驟611-616, GGSN將所述注冊請求消息發(fā)送給P-CSCF， P-CSCF通 過所述新分配的端口收到該UE的注冊請求消息后，對所述請求的IP包進行 ESP解碼。
P-CSCF根據(jù)所述注冊請求消息中的源IP地址檢查該IP是否屬于為緊急 業(yè)務所預留的源IP地址范圍，若是，則P-CSCF認為該消息為采用緊急承載 資源的消息，P-CSCF將檢查該請求是否是緊急業(yè)務，如果請求的不是緊急 業(yè)務，則P-CSCF認為該請求為非法請求；如果請求的是緊急業(yè)務，則P-CSCF 根據(jù)所述注冊請求完成后續(xù)的注冊流程，并在注冊完成后，將200響應消息 由GGSN發(fā)送至UE。
此外，如果P-CSCF在此過程中不檢查所述注冊請求消息是否為緊急業(yè) 務，那么P-CSCF會在后續(xù)當UE發(fā)起與該注冊相關的如invite、 message等 SIP請求時，檢查該請求是否為緊急業(yè)務，若不是，則判定所述相關請求是 非法請求。
上述實施例承載層網關為申請緊急承載的用戶分配針對緊急業(yè)務的源
IP地址，并保證只允許包含有所述源IP地址的數(shù)據(jù)包通過；同時，應用層 服務器在收到消息后，對包含有所述源IP地址的消息做檢查，當認為該消息 為使用緊急承載時，再進一步判斷該消息是否為緊急業(yè)務，從而保證了緊急 承載資源只能被應用于緊急業(yè)務，避免了緊急承載資源被濫用。
需要說明的是，本發(fā)明不僅限于上述幾個實施例中的緊急屬性信息，即 分別只通過源IP地址、應用服務器提供服務的端口、及應用服務器分配的 SPI來判斷請求消息是否使用了緊急承載，從而進一步判斷緊急承載資源是
否應用于緊急業(yè)務；還可以使用其他承載層控制協(xié)議資源或者采取至少一種 上述緊急屬性信息來判斷。
基于上述技術方案，本發(fā)明實施例還提供一種IMS中緊急呼叫控制方 法，該方法在呼叫建立過程中，傳遞信息的中間實體接收出自同一會話的消 息或應用信令，根據(jù)所述消息或信令識別所述呼叫是否濫用緊急承載資源， 如果是，則禁止或重定向所述呼叫。根據(jù)消息識別所述呼叫是否濫用緊急承 載資源的過程與前面實施例中的描述一致，在此不再贅述。
本發(fā)明實施例還公開了 一種IMS中用于識別濫用緊急承載資源的裝置， 如圖8所示，其為該裝置的原理圖
該裝置包括消息接收單元81、緊急承載識別單元82、緊急業(yè)務識別單 元83、判斷單元84。其中，消息接收單元81用于接收在呼叫建立過程中出 自同一會話的消息或應用信令；緊急承載識別單元82用于根據(jù)消息或應用信 令，檢查承載層是否使用了緊急承載；緊急業(yè)務識別單元83用于根據(jù)消息或 應用信令檢查應用層是否為緊急業(yè)務；判斷單元84根據(jù)緊急承載識別單元 82和緊急業(yè)務識別單元83的檢查結果，在所述結果為承載層使用了緊急承 載，但應用層為非緊急業(yè)務時，確定所述呼叫濫用緊急承載資源。
可以在緊急承載識別單元82檢查到承載層是否使用了緊急承載的情況 下，緊急業(yè)務識別單元83再對應用層進行;險查，由緊急業(yè)務識別單元83將 最終結果通知判斷單元84。當然，也可以由緊急承載識別單元82和緊急業(yè) 務識別單元83分別對承載層和應用層進行^r查，并分別將^r查結果通知判斷 單元84。
緊急承載識別單元82可以通過對消息接收單元81接收的來自承載層的 消息中是否包含緊急承載指示信息進行檢查，來確定承載層是否使用了緊急 承載，如果所述消息中包含緊急承載指示信息，則確定承載層使用了緊急承 載。所述緊急承載指示信息可以是緊急標識字段、或全局專用的緊急接入 點名、或能夠關聯(lián)到已有的緊急承載的索引等。同樣，緊急業(yè)務識別單元83 可以通過對消息接收單元81接收的來自應用層的消息中是否包含緊急業(yè)務 指示信息進行檢查，來確定應用層是否為緊急業(yè)務，如果所述消息中包含緊 急業(yè)務指示信息，則確定應用層為緊急業(yè)務。所述緊急業(yè)務指示信息可以是 被叫號碼、用戶的注冊信息等。
可以將該裝置集成在接入側承載控制IP網關比如GGSN、或PDSN上。 通過檢測用戶終端申請資源的消息和PDF返回的資源認證響應消息來實現(xiàn) 上述功能；還可以將該裝置集成在PDF上，通過檢測GGSN發(fā)起的資源認 證消息和P-CSCF的資源授權消息來實現(xiàn)上述功能。具休實現(xiàn)流程可參照前 面對圖3和圖4中流程的描述。
利用該裝置，不僅可以識別用戶終端發(fā)起的緊急呼叫是否濫用緊急承載 資源，還可以識別公共安全應答點對所述緊急呼叫發(fā)起的回呼是否濫用緊急 承載資源。
另外，緊急承載識別單元82還可以通過對消息接收單元81接收的應用 信令是否使用了為緊急業(yè)務預留的承載資源進行檢查，來確定承載層是否使 用了緊急承載，如果使用了為緊急業(yè)務預留的承載資源，則確定承載層使用 了緊急承載。所述為緊急業(yè)務預留的承載資源可以是緊急承載專用的IP地 址、端口、 SPI等。同樣，緊急業(yè)務識別單元83可以通過對消息接收單元81 接收的應用信令是否包含緊急業(yè)務指示信息進行;險查，來確定應用層是否為 緊急業(yè)務，如果所述信令中包含緊急業(yè)務指示信息，則確定應用層為緊急業(yè) 務。所述緊急業(yè)務指示信息可以是被叫號碼、用戶的注冊信息等。
可以將該裝置集成在應用層服務器比如P-CSCF上。通過檢測用戶終端 的注冊請求消息或與注冊相關的如invite、 message等SIP請求消息，來實現(xiàn) 上述功能。具休實現(xiàn)流程可參照前面對圖5、圖6和圖7中流程的描述。
本發(fā)明實施例還公開了 一種IMS中用于識別濫用緊急承載資源的系統(tǒng)，
如圖9所示，其為該系統(tǒng)的原理圖
該系統(tǒng)包括接入側承載控制IP網關91和應用層服務器92,其中，
接入側承載控制IP網關91包括資源分配裝置911,用于在呼叫建立過 程中，為用戶終端分配資源，包括為申請緊急業(yè)務承載資源的用戶分配為緊 急業(yè)務預留的承載層限定的相關資源；應用層服務器92包括識別裝置921, 用于根據(jù)應用層服務器92接收的應用信令,識別使用所述為緊急業(yè)務預留的 承載層限定的相關資源的呼叫是否濫用緊急承載資源。識別裝置921的結構 與圖8所示本發(fā)明實施例中類似，在此不再贅述。
在IMS中，接入側承載控制IP網關91可以是GGSN、或PDSN,應用 層服務器92可以是P-CSCF。
除此之外，接入側承載控制IP網關91還可以包括過濾裝置912,用于 設置針對緊急業(yè)務的承載的過濾規(guī)則，并根據(jù)所述過濾規(guī)則檢查接入側承載 控制IP網關91接收到的應用信令數(shù)據(jù)包包含的承載層限定的相關資源信息， 如果所述承載層限定的相關資源屬于所述為緊急業(yè)務預留的承載層限定的相 關資源，則允許接入側承載控制IP網關91轉發(fā)所述應用信令，否則，禁止 接入側承載控制IP網關91轉發(fā)所述應用信令。通過過濾裝置912,可以保 證發(fā)出的與緊急業(yè)務相關的信息只能到達承載層緊急屬性信息描述的實體。
利用該系統(tǒng)，不僅可以識別用戶終端發(fā)起的緊急呼叫是否濫用緊急承載 資源，還可以識別公共安全應答點對所述緊急呼叫發(fā)起的回呼是否濫用緊急 承載資源。
還可以在該系統(tǒng)中設置控制裝置(圖中未示)，以根據(jù)識別裝置921的檢 查結果，控制所述呼叫的建立，如果識別裝置921檢查結果為所述呼叫濫用 緊急承載資源，則禁止或重定向所述呼叫。所述控制裝置可以和識別裝置921 位于不同的功能實體上，也可以位于同一功能實體上。
利用該系統(tǒng)，可以保證緊急承載資源只能被應用于緊急業(yè)務，避免了緊 急承載資源被濫用。
以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范 圍。凡在本發(fā)明的精神和原則之內所作的任何修改、等同替換、改進等，均 包含在本發(fā)明的保護范圍內。
權利要求
1、一種IMS中識別濫用緊急承載資源的方法，其特征在于，該方法包括在呼叫建立過程中，如果用于傳遞信息的中間實體確定承載層使用了緊急承載，則檢查應用層是否為緊急業(yè)務；若為非緊急業(yè)務，則確定該呼叫濫用緊急承載資源。
2、 根據(jù)權利要求1所述的方法，其特征在于，所述中間實體確定承載層 使用了緊急承載的過程包括所述中間實體檢查接收的來自承載層的消息中是否包含緊急承載指示信自 如果包含，則確定承載層使用了緊急承載。
3、 根據(jù)權利要求2所述的方法，其特征在于，所述中間實體檢查應用層 是否為緊急業(yè)務的過程包括所述中間實體檢查接收的來自應用層的消息中是否包含緊急業(yè)務指示信息；如果包含，則確定應用層為緊急業(yè)務。
4、 根據(jù)權利要求3所述的方法，其特征在于，所述緊急業(yè)務指示信息是 根據(jù)會話創(chuàng)建消息中的信息生成的。
5、 根據(jù)權利要求4所述的方法，其特征在于，所述中間實體為接入側承 載控制IP網關；所述來自承載層的消息為用戶終端申請資源的消息，所述來自應用層的 消息為策略決定功能實體返回的資源認證響應消息。
6、 根據(jù)權利要求5所述的方法，其特征在于，所述接入側承載控制IP 網關包括GPRS網關支持節(jié)點GGSN、和/或分組數(shù)據(jù)服務節(jié)點PDSN。
7、 根據(jù)權利要求4所述的方法，其特征在于，所述中間實體為策略決定 功能實體； 所述來自承載層的消息為GPRS網關支持節(jié)點GGSN發(fā)起的資源認證消息，所述來自應用層的消息為來自代理呼叫會話控制功能實體的資源授權消 自
8、 根據(jù)權利要求1所述的方法，其特征在于，所述中間實體確定承載層 使用了緊急承載的過程包括所述中間實體檢查接收到的應用信令是否包含了為緊急業(yè)務預留的承載 層限定的相關資源；如果使用了為緊急業(yè)務預留的資源，則確定承載層使用了緊急承載。
9、 根據(jù)權利要求8所述的方法，其特征在于，所述方法還包括 為緊急業(yè)務預留承載層限定的相關資源；所述用戶設備發(fā)送應用信令，所述應用信令數(shù)據(jù)包中包含了所述為緊急 業(yè)務預留的承載層限定的相關資源信息。
10、 根據(jù)權利要求9所述的方法，其特征在于，所述方法還包括所述接入側承載控制IP網關根據(jù)設置的針對緊急業(yè)務承載的過濾規(guī)則， 檢查接收到的所述用戶設備所發(fā)出的應用信令數(shù)據(jù)包；如果所述應用信令數(shù)據(jù)包包含的承載層限定的相關資源信息屬于所述預 留的承載層限定的相關資源，則轉發(fā)所述應用信令；否則，則判定該應用信令數(shù)據(jù)包非法。
11、 根據(jù)權利要求8所述的方法，其特征在于，所述中間實體檢查應用 層是否為緊急業(yè)務的過程包括所述中間實體檢查收到的應用信令中是否包含緊急業(yè)務指示信息；如果包含，則確定應用層為緊急業(yè)務。
12、 根據(jù)權利要求11所述的方法，其特征在于，所述中間實體為應用層 服務器；所述應用信令為SIP消息。
13、 根據(jù)權利要求1至12任一項所述的方法，其特征在于，所述呼叫為 用戶終端發(fā)起的緊急呼叫，或公共安全應答點對所述緊急呼叫發(fā)起的回呼。
14、 根據(jù)權利要求1至12任一項所述的方法，其特征在于，，其特征在 于，所述方法還包括確定所述呼叫濫用緊急承載資源時，禁止或重定向所述呼叫。
15、 一種IMS中識別濫用緊急承栽資源的裝置，其特征在于，包括消息接收單元，用于接收在呼叫建立過程中出自同一會話的消息或應用 信令；緊急承載識別單元，用于根據(jù)所迷消息或應用信令，檢查承載層是否使 用了緊急岸、載；緊急業(yè)務識別單元，用于根據(jù)所述消息或應用信令檢查應用層是否為緊急業(yè)務；判斷單元，根據(jù)所述緊急承栽識別單元和所述緊急業(yè)務識別單元的才企查 結果，在所述結果為承載層使用了緊急承載，但應用層為非緊急業(yè)務時，確 定所述呼叫濫用緊急承載資源。
16、 根據(jù)權利要求15所述的裝置，其特征在于，所述緊急承載識別單元通過檢查所述消息接收單元接收的來自承載層的 消息中包含緊急承載指示信息，確定承載層使用了緊急承載；所述緊急業(yè)務識別單元通過檢查所述消息接收單元接收的來自應用層的 消息中未包含緊急承栽指示信息，確定應用層為非緊急業(yè)務。
17、 根據(jù)權利要求15所述的裝置，其特征在于，所述緊急承載識別單元通過4全查所述消息接收單元接收到的應用信令使 用了為緊急業(yè)務預留的承載資源，確定承載層使用了緊急承載；所述緊急業(yè)務識別單元通過檢查所述消息接收單元接收的應用信令中未 包含緊急業(yè)務指示信息，確定應用層為非緊急業(yè)務。
18、 根據(jù)權利要求15至17任一項所述的裝置，其特征在于，還包括 控制單元，用于根據(jù)所述判斷單元的確定結果，控制所述呼叫的建立， 如果所述判斷單元的確定結果為所述呼叫濫用緊急承載資源，則禁止或重定 向所述呼叫。
19、 一種IMS中識別濫用緊急承載資源的系統(tǒng)，包括接入側承載控制IP 網關和應用層服務器，其特征在于，所述接入側承載控制IP網關包括資源分配裝置，用于在呼叫建立過程 中，為用戶終端分配資源，包括為申請緊急業(yè)務承載資源的用戶分配預留的 承載層限定的相關資源；所述應用層服務器包括識別裝置，用于根據(jù)所述應用層服務器接收的應 用信令,識別使用所述承載層限定的相關資源的應用是否濫用緊急承載資源。
20、 根據(jù)權利要求19所述的系統(tǒng)，其特征在于，所述接入側承栽控制IP網關還包括過濾裝置，用于設置針對緊急業(yè)務的 承載的過濾規(guī)則，并根據(jù)所述過濾規(guī)則檢查所述接入側承載控制IP網關接收 到的應用信令使用的承載層限定的相關資源，如果所述應用信令數(shù)據(jù)包包含 的承載層限定的相關資源屬于所述為緊急業(yè)務預留的承載層限定的相關資 源，則允許所述接入側承載控制IP網關轉發(fā)所述應用信令，否則，禁止或重 定向所述接入側承載控制IP網關轉發(fā)所述應用信令。
21、 根據(jù)權利要求19或20所述的系統(tǒng)，其特征在于，所述應用層服務 器還包括控制裝置，用于才艮據(jù)所述識別裝置的^r查結果，控制所述呼叫的建立， 如果所述識別裝置;f全查結果為所述呼叫濫用緊急^^載資源，則禁止或重定向 所述呼叫。
全文摘要
本發(fā)明公開了一種IMS中識別濫用緊急承載資源的方法、裝置、系統(tǒng)及其應用，其關鍵是，在呼叫建立過程中，用于傳遞信息的中間實體判斷在同一會話中，來自承載層的消息包含緊急承載指示，而應用層的消息中沒有包含緊急業(yè)務指示，則判定為濫用緊急承載資源。對于濫用緊急承載資源的呼叫，禁止其建立。應用本發(fā)明能夠迅速有效地識別出濫用緊急承載資源的呼叫，從而保證了緊急承載資源只能被應用于緊急業(yè)務，避免了緊急承載資源被濫用。本發(fā)明應用簡單、有效。
文檔編號H04W4/22GK101110991SQ20071013065
公開日2008年1月23日 申請日期2007年7月12日 優(yōu)先權日2006年7月14日
發(fā)明者朱奮勤, 鵬 趙 申請人:華為技術有限公司