專利名稱：一種實現(xiàn)緊急呼叫的方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及IP 多媒體子系統(tǒng)(IMS，IP Multimedia Core Network Subsystem)域 緊急呼叫技術，尤指一種當采用用戶面定位服務(SUPL)技術時，用戶終端(UE)接入到系統(tǒng) 長期演進(SAE)網(wǎng)絡下實現(xiàn)緊急呼叫的方法及系統(tǒng)。
背景技術：
IMS是新一代通信網(wǎng)絡的核心，IMS采用會話發(fā)起協(xié)議(SIP，SessionInitiation Protocol)體系，SIP規(guī)定通信與接入無關，并具備多種媒體業(yè)務控制功能與承載能力分離 能力、呼叫與會話分離能力、應用與服務分離能力、業(yè)務與網(wǎng)絡分離能力、以及移動網(wǎng)與英 特網(wǎng)業(yè)務融合能力等特點。由于IMS和接入無關的特點，IMS下的緊急業(yè)務(EMC，Emergency Call)可以建 設在通用無線分組業(yè)務(GPRS，General Packet Radio Service)網(wǎng)絡，或者系統(tǒng)長期演進 (SAE, System Architecture Evolution)網(wǎng)絡上，提供統(tǒng)一的緊急呼叫控制。為了實現(xiàn)IMS下的緊急業(yè)務，定位服務是必不可少的業(yè)務，比如需要根據(jù)UE的位 置將緊急呼叫路由到合適的警局，警局出于安全、救援的目的，需要知道UE當前的位置信 肩、^^ ο圖1為現(xiàn)有UE通過接入SAE網(wǎng)絡執(zhí)行緊急業(yè)務的網(wǎng)絡架構的示意圖，如圖1所 示，主要包括SAE網(wǎng)絡部分、策略計費控制(PCC，Policy ChargingControl)部分、位置定 位服務部分以及IMS緊急業(yè)務部分。其中，位置定位服務部分包括控制面定位服務(LCS， Location Service)和用戶面定位服務(SUPL, Security User Plane Location)兩種定位 服務方式。其中，SAE網(wǎng)絡部分，用于提供底層的承載管理和移動性管理。SAE網(wǎng)絡部分的網(wǎng) 元包括增強的無線基站(eNodeB)、移動性管理實體(MME，MobiIityManagement Entity)以 及SAE網(wǎng)關(SAE GW)。eNodeB是下一代的無線接入網(wǎng)的主要空口資源的控制設備，可以提 供更高的上下行速率，更低的傳輸延遲和更加可靠的無線傳輸。MME負責管理和存儲用戶 設備(UE，User Equipment)的上下文，比如UE/用戶標識、移動性管理狀態(tài)、用戶安全參數(shù) 等，為用戶分配臨時標識，當UE駐扎在該跟蹤區(qū)域或者該網(wǎng)絡時，負責對該用戶進行鑒權 等。SAE GW為用戶面功能實體，可以分為服務網(wǎng)關(S-GW，Serving Gff)和分組數(shù)據(jù)網(wǎng)絡網(wǎng) 關(PDN GW，也稱為P-GW)兩種GW。S-GW是SAE系統(tǒng)與傳統(tǒng)第三代合作伙伴計劃(3GPP，The 3rd Generation Partnership Project)系統(tǒng)間的移動錨點，以及與演進的通用陸地無線 接入網(wǎng)(E-UTRAN，EvolvedUniversal Terrestrial Radio Access Network)之間的移動錨 點。P-GW是SAE與分組數(shù)據(jù)網(wǎng)絡(PDN，Packet Data Network)的邊界網(wǎng)關，負責PDN的接 入、在SAE與PDN間轉(zhuǎn)發(fā)數(shù)據(jù)等功能。PCC部分，用于在底層承載層和上層業(yè)務層建立有效的策略、計費控制。PCC部分 的網(wǎng)元包括策略和計費規(guī)則功能(PCRF，Policy and Charging RulesFunction)和策略和 計費執(zhí)行功能(PCEF, Policy and Charging EnforcementFunction)。PCRF 是 PCC 部分的重要功能實體，用于控制策略和計費規(guī)則的獲取、裝配和下發(fā)等。PCEF是具體的策略和計費 的執(zhí)行點，通常位于GW功能中。在SAE網(wǎng)絡中，PCEF功能位于PDN Gff中。位置定位服務部分包括控制面LCS和SUPL兩部分?？刂泼鍸CS部分的網(wǎng)元包括 增強的服務移動定位中心(E-SMLC，Enhanced SMLC)和網(wǎng)關移動定位中心(GMLC，Gateway Mobile Location Center)，其中，E-SMLC負責接收UE的測量報告、向UE下發(fā)定位參數(shù)、計 算UE的物理位置等；GMLC負責向業(yè)務層提供位置信息、從承載層獲取UE的位置信息。SUPL 部分的核心網(wǎng)元為用戶面定位平臺(SLP，SUPL Location Platform)。另外，具有SUPL能 力的UE被稱為SET (SUPL Enabled Terminal)，也就是集成有定位模塊(如A-GPS)的UE。IMS緊急業(yè)務部分，用于控制和處理緊急呼叫的會話。IMS緊急呼叫部分包括歸屬 用戶服務器(HSS，Home Subscriber Server)、緊急呼叫會話控制功能(E-CSCF，Emergency Call Session Control Function)、位置請求功能(LRF, Location Require Function)禾口 公共安全接入點(PSAP，Public Safety AccessPoint)。HSS位于歸屬網(wǎng)，用于管理用戶的 簽約數(shù)據(jù)。E-CSCF位于拜訪網(wǎng)，是控制緊急會話過程的核心網(wǎng)元。PSAP實際上就是警局。 LRF是一個邏輯功能實體，為E-CSCF、PSAP等提供UE的位置信息，LRF可以獨立部署，也可 能包含在其它位置服務器中，比如集成在GMLC、SLP等中。目前，在現(xiàn)有緊急呼叫的研究中，要求UE即使是在被限制服務的情況下，也應該 能夠發(fā)起緊急呼叫。UE被限制服務的情況有如下幾種1、UE具有有效的普遍集成電路卡片(UICC，Universal Integrated CircuitCard)，是一個合法的IMS用戶，在HSS中具備合法的用戶身份，但是存在一定的服 務限制，比如在漫游地被限制服務、當前欠費不允許發(fā)起正常呼叫、在特定的小區(qū)或者路 由區(qū)(Track Area)內(nèi)被限制服務等。2,UE具備有效的UICC卡，但是該卡上所記錄的IMSI在HSS中是無效的。比如該 UICC卡上所記錄的IMSI，由于長期不使用已被HSS注銷。3、UE不具備有效的UICC卡，當然也不存在IMSI。當UE處于上述被限制服務的情況時，在緊急呼叫中，稱為受限制模式。對于受 限制模式下的UE，該UE發(fā)起的正常網(wǎng)絡附著、或業(yè)務建立請求，將會被網(wǎng)絡所拒絕。而緊 急呼叫應該能保證受限制模式的UE也能夠得到緊急呼叫的支持。因此，3GPP在研究的分 組演進系統(tǒng)(EPS，Evolved Packet System)網(wǎng)絡對緊急呼叫的支持中，針對受限制模式 的UE進行了一系列的技術改進，一個典型的改進就是促使受限制模式的UE通過緊急附著 (Emergency Attach)附著到EPS網(wǎng)絡，并建立專門用于緊急呼叫的緊急承載(Emergency Bearer)。對于一個受限制模式下的UE，發(fā)起緊急呼叫需要執(zhí)行如下主要步驟首先，建立緊急承載。大致包括UE發(fā)起緊急附著，即UE在發(fā)起普通附著時，攜帶 緊急標識，以告知承載網(wǎng)絡當前附著是為了撥打緊急電話等緊急業(yè)務。承載網(wǎng)絡接收到來 自UE的緊急附著請求，通過緊急APN(E-APN，Emergency APN)建立專門用于緊急呼叫的缺 省承載，該缺省承載主要用于信令控制。然后，進行緊急呼叫。大致包括UE發(fā)起緊急呼叫，即通過在一個正常的INVITE 中攜帶緊急標識，表明當前呼叫請求是一個緊急呼叫。UE在被叫號碼中填寫緊急號碼，如 果UE在拜訪地，則該緊急號碼是拜訪地的緊急號碼；緊急呼叫被路由到E-CSCF，E-CSCF通
5過LRF查詢PSAP的地址。LRF通過查詢UE的位置信息來決定為UE服務的PSAP。E-CSCF 在獲得PSAP的地址后，將呼叫路由給PSAP，從而建立起緊急呼叫。其中，LRF通過查詢位置 服務器來獲得UE的位置，并根據(jù)UE的位置信息來決定將呼叫路由到合適的PSAP。另一方 面，LRF可以接受PSAP在緊急呼叫中對UE的位置查詢請求，并從位置服務器獲得UE的位
直fe息。圖2為現(xiàn)有技術中采用SUPL技術，SLP查詢UE位置信息的流程圖，如圖2所示， 包括如下步驟步驟200 :SLP接收到位置請求后，向短信中心(或WAP網(wǎng)關)發(fā)送SUPL定位初始 化(SUPL INIT)消息。在該SUPL INIT消息中，攜帶有SUPL會話標識(ID)、SLP支持的定 位方式、SLP的運行模式等信息。步驟201 短信中心(或WAP網(wǎng)關)將SUPL INIT包裝成短消息(或WAP消息)。步驟202 短信中心(或WAP網(wǎng)關)將包裝后的SUPL INIT消息發(fā)送給帶有SUPL 定位能力的UE (SET)。步驟203 =SET接收到包裝后的SUPL INIT消息后，主動向網(wǎng)絡發(fā)起用于定位的用 戶面承載建立的過程?？蛇x地，在SET和SLP之間進一步建立IPSec安全鏈接隧道。步驟204 =SET向SLP發(fā)送SUPL定位初始化響應(SUPL POS INIT)消息。在該SUPL POS INIT消息中，攜帶有SUPL會話ID、SET的SUPL能力等。步驟205 在SET與SLP之間交互后續(xù)的定位消息。步驟206 =SLP向SET發(fā)送SUPL定位結(jié)束(SUPL END)消息，完成對SET的定位。圖2所示的流程中，如果SET接入到GERAN/UTRAN網(wǎng)絡，則SLP可以通過短信網(wǎng)關 或WAP網(wǎng)關向SET發(fā)送消息，在消息中包裝SUPL INIT消息，以觸發(fā)UE自行建立定位用的承 載。根據(jù)圖2所示的流程，在SET接入到SAE下，所建立的定位用承載是非緊急的。此外， 在SLP發(fā)起的定位流程中，如果SET通過IP網(wǎng)絡接入的情況下(如SET通過Wifi接入)， 且SLP和SET之間存在Lup接口，則SLP可以通過Lup 口直接向SET發(fā)送SUPL INIT消息， 以觸發(fā)定位過程的建立。前面提到，控制面LCS和SUPL是當前兩個主流的位置定位技術，其中，LCS技術， 其定位信息、位置信息均承載在控制信道中；SUPL技術，其基本出發(fā)點是在UE和SLP之間 建立一個用戶面隧道，定位消息、位置信息均承載在該用戶面隧道上。由于SUPL定位技術 不依賴于具體的接入和承載網(wǎng)絡，已經(jīng)獲得了廣泛的應用。SUPL技術只需要在SLP和UE之 間建立用于定位的用戶面隧道(即用戶面承載)，因此，SUPL技術可以靈活地部署在多種網(wǎng) 絡中，如GERAN、UTRAN、E-UTRAN等，因此現(xiàn)在已經(jīng)獲得了廣泛的應用。如果一個SAE網(wǎng)絡部署的位置服務采用的是SUPL技術，則UE接入到該SAE網(wǎng)絡 發(fā)起緊急呼叫時，用于定位的承載創(chuàng)建過程存在的問題是，定位承載在某些情況下根本就 不能創(chuàng)建。因為，現(xiàn)有SUPL技術下，用于定位的承載是由UE創(chuàng)建的，SLP通過短信中心或 WAP網(wǎng)關通知UE創(chuàng)建定位用承載。但是，在受限制模式下，短信、WAP消息由于服務限制是 不能發(fā)送給UE的，因此，當SAE網(wǎng)絡部署的位置服務采用的是SUPL技術時，受限制模式下 的UE接入到該SAE網(wǎng)絡是不能實現(xiàn)緊急呼叫的。即使是UE在非受限制模式(正常模式)下，采用SUPL技術來服務于緊急呼叫也 可能會出現(xiàn)如下問題即使UE能夠創(chuàng)建定位用的承載，但是，該承載沒有被標識為緊急的(即服務質(zhì)量、優(yōu)先級等沒有被標記為緊急的)，這樣，如果UE從非受限區(qū)域移動到受限制 區(qū)域，所有的非緊急承載將被釋放，也就是說，此時服務于緊急呼叫的定位承載(非緊急承 載)也將被認為是非緊急承載而被釋放。由此可見，當SAE網(wǎng)絡部署的位置服務采用的是 SUPL技術時，已發(fā)起緊急呼叫的UE,如果從非受限區(qū)域移動到受限制區(qū)域，是無法保證緊 急呼叫下所需要的位置服務的連續(xù)性的，從而導致緊急呼叫切換的失敗。
發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種實現(xiàn)緊急呼叫的方法，當采用SUPL技 術，UE接入到SAE網(wǎng)絡時，能夠?qū)崿F(xiàn)緊急呼叫，而且保證其連續(xù)性。本發(fā)明的另一目的在于提供一種實現(xiàn)緊急呼叫的系統(tǒng)，當采用SUPL技術，UE接入 到SAE網(wǎng)絡時，能夠?qū)崿F(xiàn)緊急呼叫，而且保證其連續(xù)性。為達到上述目的，本發(fā)明的技術方案是這樣實現(xiàn)的一種實現(xiàn)緊急呼叫的方法，該方法包括用戶面定位平臺SLP接收到與緊急呼叫相關的位置查詢，通知用戶設備UE進行用 戶面定位初始化；UE發(fā)起緊急定位承載的建立，并通過建立起的緊急定位承載服務后續(xù)緊急呼叫。所述SLP接收到與緊急呼叫相關的位置查詢，通知用戶設備UE進行用戶面定位初 始化具體包括所述SLP判斷所接收的位置查詢請求中是否攜帶有緊急標識，如果攜帶有，所述 SLP向UE發(fā)送用戶面定位初始化消息，并在該消息中攜帶緊急標識。該方法之前還包括預先設置用于處理緊急呼叫處理的實體；所述SLP接收到與緊急呼叫相關的位置查詢，通知用戶設備UE進行用戶面定位初 始化具體包括所述SLP接收到位置查詢請求，判斷發(fā)起所述位置查詢請求的實體是否為 用于處理緊急呼叫處理的實體，如果是，所述SLP向UE發(fā)送用戶面定位初始化消息，并在該 消息中攜帶緊急標識。所述SLP通過短信網(wǎng)關或WAP網(wǎng)關將所述用戶面定位初始化消息SUPLINIT發(fā)送 給UE。所述用戶面定位初始化消息經(jīng)短信中心或WAP網(wǎng)關包裝成短消息或WAP消息后， 發(fā)送給所述UE。所述用戶面定位初始化消息包含在下行數(shù)據(jù)中。所述UE被通知進行用戶面定位初始化之后，發(fā)起承載建立過程，建立服務于緊急 呼叫的緊急定位承載的建立之前，該方法還包括所述UE判斷所述用戶面定位初始化消息中是否攜帶有緊急標識，如果攜帶有，則 所述UE主動發(fā)起服務于緊急呼叫的緊急定位承載的建立；或者，所述UE確定自身是否是執(zhí)行的緊急附著，如果是，則所述UE主動發(fā)起緊急 定位承載的建立；或者，所述UE判斷出所述用戶面定位初始化消息中未攜帶緊急標識，但所述UE確 定自身是執(zhí)行的緊急附著，則所述UE主動發(fā)起緊急定位承載的建立。所述UE通過指定所述緊急定位承載的服務質(zhì)量等級或其它信息，來表明所述承載是服務于緊急定位的，并向移動性管理實體MME發(fā)起緊急定位承載的建立過程。一種實現(xiàn)緊急呼叫的系統(tǒng)，至少包括用戶設備UE和用戶面定位平臺SLP，其中，SLP，用于在接收到與緊急呼叫相關的位置查詢，通知UE進行用戶面定位初始化；UE，用于發(fā)起緊急定位承載的建立，并通過建立起的緊急定位承載服務后續(xù)緊急 呼叫。所述SLP還用于，判斷發(fā)起所接收的位置查詢請求中是否攜帶有緊急標識，如果攜帶有，所述SLP 向UE發(fā)送用戶面定位初始化消息，并在該消息中攜帶緊急標識。所述SLP還用于，查詢發(fā)起所述位置查詢請求的實體是否為預設的用于處理緊急呼叫處理的實體， 如果是，所述SLP向UE發(fā)送用戶面定位初始化消息，并在該消息中攜帶緊急標識。還包括短信網(wǎng)關或WAP網(wǎng)關；所述SLP通過短信網(wǎng)關或WAP網(wǎng)關將所述用戶面定位初始化消息發(fā)送給UE。還包括PDN GW網(wǎng)關；所述SLP通過PDN Gff向UE發(fā)送下行數(shù)據(jù)，在下行數(shù)據(jù)中包含發(fā)送給UE的所述用 戶面定位初始化消息。所述UE還用于，判斷所述用戶面定位初始化消息中是否攜帶有緊急標識，如果攜帶有，則所述UE 主動發(fā)起服務于緊急呼叫的緊急定位承載的建立。所述UE還用于，確定自身是否是執(zhí)行的緊急附著，如果是，則所述UE主動發(fā)起服務于緊急呼叫的 緊急定位承載的建立。從上述本發(fā)明提供的技術方案可以看出，對于一個SAE網(wǎng)絡部署的位置服務采用 的是SUPL技術，在UE接入到該SAE網(wǎng)絡發(fā)起緊急呼叫時，由于表明了位置查詢是用于緊急 呼叫的，UE在接收到進行用戶面初始化的通知，確定定位承載是服務于緊急呼叫的，從而發(fā) 起緊急定位承載的建立。這樣，實現(xiàn)了受限制模式下的UE接入到SAE網(wǎng)絡的緊急呼叫。而 且，由于該定位承載是專門服務于緊急呼叫的，因此，在已發(fā)起緊急呼叫的UE從非受限區(qū) 域移動到受限制區(qū)域時，該緊急定位承載不會被釋放，保證了緊急呼叫的連續(xù)性。
圖1為現(xiàn)有UE通過接入SAE網(wǎng)絡執(zhí)行緊急業(yè)務的網(wǎng)絡架構的示意圖；圖2為現(xiàn)有技術中采用SUPL技術，SLP查詢UE位置信息的流程圖；圖3為本發(fā)明實現(xiàn)緊急呼叫的方法的流程圖；圖4為本發(fā)明實現(xiàn)緊急呼叫的第一實施例的流程圖；圖5為本發(fā)明實現(xiàn)緊急呼叫的第二實施例的流程圖。
具體實施例方式圖3為本發(fā)明實現(xiàn)緊急呼叫的方法的流程圖，如圖3所示，包括步驟300 =SLP接收到與緊急呼叫相關的位置查詢，通知UE進行用戶面定位初始化。本步驟中，SLP識別接收到的是與緊急呼叫相關的位置查詢，可以采用兩種方式來 實現(xiàn)一種是，在SLP接收到的位置查詢請求中攜帶有緊急標識；另一種是，SLP預先設置或 存儲用于處理緊急呼叫處理的實體的地址，而與緊急呼叫相關的位置查詢來自于用于處理 緊急呼叫處理的實體如指定的LRF。步驟301 =UE發(fā)起緊急承載的建立，要求建立服務于緊急呼叫的緊急定位承載的 建立，并通過建立起的緊急定位承載服務后續(xù)緊急呼叫。本步驟中，當UE接收到用戶面定位初始化的消息時，如果用戶面定位初始化消息 中攜帶有緊急標識，則UE主動發(fā)起服務于緊急呼叫的緊急定位承載的建立；如果用戶面定 位初始化消息中未攜帶緊急標識，則UE進一步確定自身是否是緊急附著狀態(tài)，如果是，UE 主動發(fā)起服務于緊急呼叫的緊急定位承載的建立。如果用戶面定位初始化消息中未攜帶緊急標識，而且UE判定自身不是緊急附著 狀態(tài)，則按照現(xiàn)有流程執(zhí)行即可。從本發(fā)明方法可見，如果一個SAE網(wǎng)絡部署的位置服務采用的是SUPL技術，在UE 接入到該SAE網(wǎng)絡發(fā)起緊急呼叫時，由于表明了位置查詢是用于緊急呼叫的，UE在接收到 用戶面定位初始化的消息時，確定定位承載是服務于緊急呼叫的，從而發(fā)起緊急定位承載 的建立。這樣，實現(xiàn)了受限制模式下的UE接入到SAE網(wǎng)絡的緊急呼叫。而且，由于該定位 承載是專門服務于緊急呼叫的，因此，在已發(fā)起緊急呼叫的UE從非受限區(qū)域移動到受限制 區(qū)域時，該緊急定位承載不會被釋放，保證了緊急呼叫的連續(xù)性。下面結(jié)合實施例，對本發(fā)明方法進行詳細描述。圖4為本發(fā)明實現(xiàn)緊急呼叫的第一實施例的流程圖，第一實施例中，假設拜訪網(wǎng) 部署了 SUPL功能，SLP通過在下行數(shù)據(jù)中攜帶緊急標識來通知UE發(fā)起緊急定位承載的建 立。如圖4所示，包括步驟400 =UE發(fā)起一個緊急呼叫，該緊急呼叫被路由到E-CSCF。步驟401 =E-CSCF向LRF發(fā)起位置查詢請求，并要求LRF根據(jù)位置信息分配合適的 PSAP0步驟402 =LRF向SLP發(fā)送位置查詢請求。由于該位置查詢請求服務于緊急呼叫， 本實施例中，假設LRF在位置查詢請求中攜帶緊急標識，以明確告知SLP，當前的位置查詢 請求是一個用于緊急呼叫的位置查詢請求。步驟403 =SLP收到LRF發(fā)送的位置查詢請求，根據(jù)位置查詢請求中攜帶的緊急標 識，獲知該位置查詢請求是服務于緊急呼叫的。需要說明的是，如果步驟402中，LRF向SLP發(fā)送位置查詢請求中未攜帶緊急標識， SLP可以根據(jù)預先設置的用于處理緊急呼叫處理的實體(如對應這些實體的地址)，查詢該 LRF是否為用于處理緊急呼叫處理的實體(如果在預先設置的地址中能找到該LRF的地址， 則認為該LRF為用于處理緊急呼叫處理的實體)，從而獲知該位置查詢請求是否是服務于 緊急呼叫的。步驟404 :SLP向P-GW發(fā)送下行數(shù)據(jù)，在該下行數(shù)據(jù)中包含SUPL INIT消息，并且， 本實施例中，在該SUPL INIT消息中還攜帶有緊急標識。步驟405 =P-Gff接收到來自SLP的下行數(shù)據(jù)后，如果UE處于空閑(IDLE)態(tài)，則首
9先將該UE激活，然后接收到的下行數(shù)據(jù)轉(zhuǎn)發(fā)給UE。步驟406 =UE接收到下行數(shù)據(jù)后，從其中的SUPL INIT消息中獲得緊急標識后，主 動發(fā)起緊急定位承載的建立過程。UE向MME發(fā)起緊急承載的建立過程，并通過指定該緊急承載的服務質(zhì)量等級 (QCI)、或其它信息，來表明該緊急承載是服務于緊急定位的。需要說明的是，在步驟404中，UE可以僅判斷自身是否是緊急附著狀態(tài)，從而主動 發(fā)起緊急定位承載的建立過程；或者，UE可以先檢測在SUPL INIT消息中未攜帶緊急標識 (即在SLP下發(fā)的下行數(shù)據(jù)中不包含緊急標識)后判斷自身是緊急附著狀態(tài)，從而，UE同樣 主動發(fā)起緊急定位承載的建立過程。步驟407 在UE建立好緊急定位承載后，向SLP回復SUP POS INIT消息。步驟408 步驟410 之后，SLP向UE發(fā)起后續(xù)定位請求，并從UE處獲得具體的位 置信息。當SLP獲得了 UE的位置信息后，SLP向LRF發(fā)送位置查詢響應，以告知UE的位置信 息。LRF獲得UE的位置信息后，根據(jù)UE的位置信息決定合適的PSAP地址，返回給E-CSCF， E-CSCF執(zhí)行后續(xù)緊急呼叫流程。本步驟的具體實現(xiàn)與現(xiàn)有技術完全一致，這里不再贅述。圖4所示的第一實施例，可以應用于有PCC、無PCC服務于緊急呼叫的場合，并且 SLP和P-GW之間可以部署Lup接口或者增強的Lup接口。如果SLP和P-GW之間部署Lup 接口，則SLP可以通過Lup接口發(fā)送下行數(shù)據(jù)給UE。如果SLP和P-GW之間沒有部署Lup接 口或者增強的Lup接口，則SLP可以通過標準IP通道向UE發(fā)送下行數(shù)據(jù)，由于P-GW負責 處理UE的上下行數(shù)據(jù)，P-GW通過現(xiàn)有機制將下行數(shù)據(jù)發(fā)送給UE。UE根據(jù)在下行數(shù)據(jù)中所 包含的SUPL INIT消息或者UE是緊急附著的，發(fā)起緊急定位承載的建立過程。圖5為本發(fā)明實現(xiàn)緊急呼叫的第二實施例的流程圖，第二實施例中，假設拜訪網(wǎng) 部署了 SUPL功能，SLP通過在下行數(shù)據(jù)中攜帶緊急標識來通知UE發(fā)起緊急定位承載的建 立。如圖5所示，包括步驟500 =UE發(fā)起一個緊急呼叫，該緊急呼叫被路由到E-CSCF。步驟501 =E-CSCF向LRF發(fā)起位置查詢請求，并要求LRF根據(jù)位置信息分配合適的 PSAP0步驟502 =LRF向SLP發(fā)送位置查詢請求。由于該位置查詢請求服務于緊急呼叫， 本實施例中，假設LRF在位置查詢請求中攜帶緊急標識，以明確告知SLP，當前的位置查詢 請求是一個用于緊急呼叫的位置查詢請求。步驟503 =SLP收到LRF發(fā)送的位置查詢請求，根據(jù)位置查詢請求中攜帶的緊急標 識，獲知該位置查詢請求是服務于緊急呼叫的。需要說明的是，如果步驟502中，LRF向SLP發(fā)送位置查詢請求中未攜帶緊急標識， SLP可以根據(jù)預先設置的用于處理緊急呼叫處理的實體(如對應這些實體的地址)，查詢該 LRF是否為用于處理緊急呼叫處理的實體(如果在預先設置的地址中能找到該LRF的地址， 則認為該LRF為用于處理緊急呼叫處理的實體)，從而獲知該位置查詢請求是否是服務于 緊急呼叫的。步驟504 :SLP接收到位置查詢請求后，向短信中心(或WAP網(wǎng)關)發(fā)送SUPL INIT 消息。本實施例中，在該SUPL INIT消息中還攜帶有緊急標識。步驟505 步驟506 短信中心(或WAP網(wǎng)關)將該SUPL INIT消息包裝成短消息(或WAP消息)，并發(fā)送給帶有SUPL定位能力的UE。步驟507 =UE接收到包裝后的SUPL INIT消息后，從其中的SUPL INIT消息中獲 得緊急標識后，主動發(fā)起緊急定位承載的建立過程。進一步地，UE和SLP之間還可以建立 IPSec安全鏈接隧道。UE向MME發(fā)起緊急承載的建立過程，并通過指定該緊急承載的QCI、或其它信息， 來表明該緊急承載是服務于緊急定位的。需要說明的是，在步驟507中，UE可以僅判斷自身是否是緊急附著狀態(tài)，從而主動 發(fā)起緊急定位承載的建立過程；或者，UE可以先檢測在SUPL INIT消息中未攜帶緊急標識 (即在SLP下發(fā)的下行數(shù)據(jù)中不包含緊急標識)后判斷自身是緊急附著狀態(tài)，從而，UE同樣 主動發(fā)起緊急定位承載的建立過程。步驟508 在UE建立好緊急定位承載后，向SLP回復SUP POS INIT消息。步驟509 步驟511 之后，SLP向UE發(fā)起后續(xù)定位請求，并從UE處獲得具體的位 置信息。當SLP獲得了 UE的位置信息后，SLP向LRF發(fā)送位置查詢響應，以告知UE的位置信 息。LRF獲得UE的位置信息后，根據(jù)UE的位置信息決定合適的PSAP地址，返回給E-CSCF， E-CSCF執(zhí)行后續(xù)緊急呼叫流程。本步驟的具體實現(xiàn)與現(xiàn)有技術完全一致，這里不再贅述。圖5所示的第二實施例，典型應用于網(wǎng)絡中存在短信網(wǎng)關、WAP網(wǎng)關可以服務于緊 急呼叫的場景。由于短信服務、WAP短消息服務的特性，該方法不能應用于UE無卡、UE無有 效IMSI的緊急呼叫。對于UE存在有效IMSI，但是IMSI被限制的場景，如果拜訪地運營商 允許為這種狀態(tài)下的UE開放短信服務、WAP短消息服務，則該方法可以應用。在該場景下， SLP通過短信網(wǎng)關、WAP網(wǎng)關將SUPL INIT消息發(fā)送給UE，促使UE根據(jù)SUPL INIT消息創(chuàng) 建用于定位的緊急承載。以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍，凡在 本發(fā)明的精神和原則之內(nèi)所作的任何修改、等同替換和改進等，均應包含在本發(fā)明的保護 范圍之內(nèi)。
權利要求
一種實現(xiàn)緊急呼叫的方法，其特征在于，該方法包括用戶面定位平臺SLP接收到與緊急呼叫相關的位置查詢，通知用戶設備UE進行用戶面定位初始化；UE發(fā)起緊急定位承載的建立，并通過建立起的緊急定位承載服務后續(xù)緊急呼叫。
2.根據(jù)權利要求1所述的方法，其特征在于，所述SLP接收到與緊急呼叫相關的位置查 詢，通知用戶設備UE進行用戶面定位初始化具體包括所述SLP判斷所接收的位置查詢請求中是否攜帶有緊急標識，如果攜帶有，所述SLP向 UE發(fā)送用戶面定位初始化消息，并在該消息中攜帶緊急標識。
3.根據(jù)權利要求1所述的方法，其特征在于，該方法之前還包括預先設置用于處理緊 急呼叫處理的實體；所述SLP接收到與緊急呼叫相關的位置查詢，通知用戶設備UE進行用戶面定位初始化 具體包括所述SLP接收到位置查詢請求，判斷發(fā)起所述位置查詢請求的實體是否為用于 處理緊急呼叫處理的實體，如果是，所述SLP向UE發(fā)送用戶面定位初始化消息，并在該消息 中攜帶緊急標識。
4.根據(jù)權利要求2或3所述的方法，其特征在于，所述SLP通過短信網(wǎng)關或WAP網(wǎng)關將 所述用戶面定位初始化消息SUPL INIT發(fā)送給UE。
5.根據(jù)權利要求4所述的方法，其特征在于，所述用戶面定位初始化消息經(jīng)短信中心 或WAP網(wǎng)關包裝成短消息或WAP消息后，發(fā)送給所述UE。
6.根據(jù)權利要求2或3所述的方法，其特征在于，所述用戶面定位初始化消息包含在下 行數(shù)據(jù)中。
7.根據(jù)權利要求2或3所述的方法，其特征在于，所述UE被通知進行用戶面定位初始 化之后，發(fā)起承載建立過程，建立服務于緊急呼叫的緊急定位承載的建立之前，該方法還包 括所述UE判斷所述用戶面定位初始化消息中是否攜帶有緊急標識，如果攜帶有，則所述 UE主動發(fā)起服務于緊急呼叫的緊急定位承載的建立；或者，所述UE確定自身是否是執(zhí)行的緊急附著，如果是，則所述UE主動發(fā)起緊急定位 承載的建立；或者，所述UE判斷出所述用戶面定位初始化消息中未攜帶緊急標識，但所述UE確定自 身是執(zhí)行的緊急附著，則所述UE主動發(fā)起緊急定位承載的建立。
8.根據(jù)權利要求7所述的方法，其特征在于，所述UE通過指定所述緊急定位承載的 服務質(zhì)量等級或其它信息，來表明所述承載是服務于緊急定位的，并向移動性管理實體MME 發(fā)起緊急定位承載的建立過程。
9.一種實現(xiàn)緊急呼叫的系統(tǒng)，其特征在于，至少包括用戶設備UE和用戶面定位平臺 SLP，其中，SLP，用于在接收到與緊急呼叫相關的位置查詢，通知UE進行用戶面定位初始化；UE，用于發(fā)起緊急定位承載的建立，并通過建立起的緊急定位承載服務后續(xù)緊急呼叫。
10.根據(jù)權利要求9所述的系統(tǒng)，其特征在于，所述SLP還用于，判斷發(fā)起所接收的位置查詢請求中是否攜帶有緊急標識，如果攜帶有，所述SLP向UE 發(fā)送用戶面定位初始化消息，并在該消息中攜帶緊急標識。
11.根據(jù)權利要求9所述的系統(tǒng)，其特征在于，所述SLP還用于，查詢發(fā)起所述位置查詢請求的實體是否為預設的用于處理緊急呼叫處理的實體，如果 是，所述SLP向UE發(fā)送用戶面定位初始化消息，并在該消息中攜帶緊急標識。
12.根據(jù)權利要求10或11所述的系統(tǒng)，其特征在于，還包括短信網(wǎng)關或WAP網(wǎng)關； 所述SLP通過短信網(wǎng)關或WAP網(wǎng)關將所述用戶面定位初始化消息發(fā)送給UE。
13.根據(jù)權利要求10或11所述的系統(tǒng)，其特征在于，還包括PDNGff網(wǎng)關；所述SLP通過PDN Gff向UE發(fā)送下行數(shù)據(jù)，在下行數(shù)據(jù)中包含發(fā)送給UE的所述用戶面 定位初始化消息。
14.根據(jù)權利要求10或11所述的系統(tǒng)，其特征在于，所述UE還用于，判斷所述用戶面定位初始化消息中是否攜帶有緊急標識，如果攜帶有，則所述UE主動 發(fā)起服務于緊急呼叫的緊急定位承載的建立。
15.根據(jù)權利要求13所述的系統(tǒng)，其特征在于，所述UE還用于，確定自身是否是執(zhí)行的緊急附著，如果是，則所述UE主動發(fā)起服務于緊急呼叫的緊急 定位承載的建立。
全文摘要
本發(fā)明提供了一種實現(xiàn)緊急呼叫的方法及系統(tǒng)，對于一個SAE網(wǎng)絡部署的位置服務采用的是SUPL技術，在UE接入到該SAE網(wǎng)絡發(fā)起緊急呼叫時，由于表明了位置查詢是用于緊急呼叫的，UE在接收到進行用戶面初始化的通知，確定定位承載是服務于緊急呼叫的，從而發(fā)起緊急定位承載的建立。這樣，實現(xiàn)了受限制模式下的UE接入到SAE網(wǎng)絡的緊急呼叫。而且，由于該定位承載是專門服務于緊急呼叫的，因此，在已發(fā)起緊急呼叫的UE從非受限區(qū)域移動到受限制區(qū)域時，該緊急定位承載不會被釋放，保證了緊急呼叫的連續(xù)性。
文檔編號H04W4/22GK101938727SQ20091008861
公開日2011年1月5日 申請日期2009年6月30日 優(yōu)先權日2009年6月30日
發(fā)明者朱春暉, 李志軍, 謝寶國 申請人:中興通訊股份有限公司