本發(fā)明涉及通信技術領域,尤其涉及一種容災倒回的方法及系統(tǒng)。
背景技術:
IMS(Internet Protocol Multimedia Subsystem,IP多媒體子系統(tǒng))是一種全新的多媒體業(yè)務形式,是3GPP(3rd Generation Partnership Project,第三代合作伙伴組織)定義的下一代網絡的標準,它采用SIP(Session Initiation Protocol,會話初始協(xié)議)體系,能夠滿足現在的終端客戶更新穎、更多樣化的多媒體業(yè)務的需求。
目前,在基于IMS系統(tǒng)的語音業(yè)務VoLTE中可以應用容災倒回技術,即IMS系統(tǒng)中的多個S-CSCF(Serving call session control Function,服務呼叫會話控制功能實體)設備之間互相容災備份,當其中一臺設備故障后,可以由非故障設備接管故障設備的業(yè)務,接管故障設備的業(yè)務的非故障設備稱為容災設備,假設S-CSCF1為故障設備,當S-CSCF1故障恢復后,容災設備應將部分業(yè)務倒回至S-CSCF1上,以減輕容災設備的壓力。具體的實現方法為:當故障設備恢復之后,I-CSCF(Interrogating call session control Function,查詢呼叫會話控制功能實體)根據用戶輸入的指令開啟倒回開關,當I-CSCF接收到VoLTE SBC(Session Border Control,會話邊界控制器)轉發(fā)的終端的重注冊請求消息時,根據終端的重注冊請求消息,I-CSCF向HSS(Home subscriber Server,歸屬用戶服務器)發(fā)送UAR(User Authorization Request,用戶鑒權請求)消息,使終端用戶按照初始注冊重新選擇一次S-CSCF,HSS接收到該UAR消息之后,確定具有當前終端所需能力的S-CSCF,將其中每個S-CSCF具有的能力以及優(yōu)先級反饋給I-CSCF,I-CSCF將HSS返回的每個S-CSCF具有的能力分別與本地配置的相應的S-CSCF的能力進行比較,從中選取與本地配置的S-CSCF的能力一致的S-CSCF,然后從選取出的S-CSCF中選取一個優(yōu)先級最高的S-CSCF作為終端歸屬的S-CSCF,并將重注冊請求消息轉發(fā)到終端歸屬的S-CSCF,如果S-CSCF的優(yōu)先級一樣,則I-CSCF按照負荷分擔算法選擇S-CSCF,并將重注冊請求消息轉發(fā)到該S-CSCF,之后,終端歸屬的S-CSCF對終端進行鑒權,鑒權成功后,終端歸屬的S-CSCF向HSS發(fā)送配置請求消息,HSS根據配置請求信息向S-CSCF返回相關用戶數據,例如簽約數據等,以完成終端的重注冊。
可見,由于I-CSCF在處理重注冊請求消息的過程中,需要為接入IMS系統(tǒng)中的所有終端都重新選擇S-CSCF,但是重新選擇的S-CSCF中沒有終端的相關用戶數據,所以每個S-CSCF都需要向HSS請求其所服務的終端的相關用戶數據,造成HSS壓力過大。
技術實現要素:
本發(fā)明的實施例提供一種容災倒回的的方法及裝置,可以解決在基于IMS系統(tǒng)的容災倒回中,每個用戶注冊時,S-CSCF都需要向HSS請求其所服務的UE(User Equipment,用戶設備)的相關用戶數據,造成HSS壓力過大的問題。
為達到上述目的,本發(fā)明的實施例采用如下技術方案:
第一方面,本發(fā)明實施例提供一種容災倒回的方法,包括:
當容災設備接收到連接于所述容災設備的前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量,所述容災設備為接管故障設備的業(yè)務的非故障設備,所述已倒回數量為所述容災設備已倒回給所述故障設備的UE的數量;
當所述已倒回數量滿足預設倒回目標時,所述容災設備繼續(xù)處理所述重注冊請求消息;
當所述已倒回數量未滿足預設倒回目標時,所述容災設備向所述前一網元發(fā)送地址重定向指示,所述地址重定向指示中包含故障恢復設備的地址,所述故障恢復設備為已恢復的故障設備;
所述前一網元根據所述地址重定向指示向所述故障恢復設備轉發(fā)所述重注冊請求消息,以使得所述故障恢復設備繼續(xù)處理所述重注冊請求消息。
第二方面,本發(fā)明實施例提供一種容災倒回的系統(tǒng),包括:
容災設備,用于當接收到連接于所述容災設備的前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量,所述容災設備為接管故障設備的業(yè)務的非故障設備,所述已倒回數量為所述容災設備已倒回給故障恢復設備的UE的數量,所述故障恢復設備為已恢復的故障設備;當所述已倒回數量滿足預設倒回目標時,繼續(xù)處理所述重注冊請求消息;當所述已倒回數量未滿足預設倒回目標時,向所述前一網元發(fā)送地址重定向指示,所述地址重定向指示中包含故障恢復設備的地址;
所述待處理UE,用于向所述前一網元發(fā)送所述重注冊請求消息;
所述前一網元,用于向所述容災設備轉發(fā)所述重注冊請求消息;接收所述地址重定向指示;根據所述地址重定向指示向所述故障恢復設備轉發(fā)所述重注冊請求消息;
所述故障恢復設備,用于接收所述前一網元轉發(fā)的重注冊請求消息;繼續(xù)處理所述重注冊請求消息。
本發(fā)明實施例提供的容災倒回的方法及系統(tǒng),當容災設備接收到連接于容災設備的前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量,容災設備為接管故障設備的業(yè)務的非故障設備,已倒回數量為容災設備已倒回給故障設備的UE的數量;當已倒回數量滿足預設倒回目標時,容災設備繼續(xù)處理重注冊請求消息;當已倒回數量未滿足預設倒回目標時,容災設備向前一網元發(fā)送地址重定向指示,地址重定向指示中包含故障恢復設備的地址,故障恢復設備為已恢復的故障設備;然后,前一網元根據地址重定向指示向故障恢復設備轉發(fā)重注冊請求消息,以使得故障恢復設備繼續(xù)處理重注冊請求消息。與現有技術中每個用戶注冊時,S-CSCF都需要向HSS請求當前其所服務的UE的相關用戶數據,造成HSS壓力過大相比,本發(fā)明實施例中,容災設備只需將自身負責的一部分UE倒回至故障恢復設備,剩余的UE的重注冊請求消息仍然由容災設備自己處理,由于容災設備中之前已經存儲了自己所負責的UE的相關用戶數據,所以容災設備在處理這些UE的重注冊請求消息的過程中,不需要重新向HSS請求UE的相關用戶數據,相應地,HSS也不需要在本地查找并向容災設備返回UE的相關用戶數據,減少了容災設備和HSS的能耗,并且降低了占用的接口帶寬,進而減輕了HSS的壓力。
附圖說明
為了更清楚地說明本發(fā)明實施例或現有技術中的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施例,對于本領域普通技術人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據這些附圖獲得其他的附圖。
圖1為本發(fā)明實施例提供的IMS系統(tǒng)的邏輯結構示意圖;
圖2為本發(fā)明實施例提供的一種容災倒回的方法的流程圖;
圖3為本發(fā)明實施例提供的另一種容災倒回的方法的流程圖;
圖4為本發(fā)明實施例提供的另一種容災倒回的方法的流程圖;
圖5為本發(fā)明實施例提供的另一種容災倒回的方法的流程圖;
圖6為本發(fā)明實施例提供的另一種容災倒回的方法的流程圖;
圖7為本發(fā)明實施例提供的一種容災倒回的系統(tǒng)的邏輯結構示意圖。
具體實施方式
下面將結合本發(fā)明實施例中的附圖,對本發(fā)明實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅僅是本發(fā)明一部分實施例,而不是全部的實施例。基于本發(fā)明中的實施例,本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。
為了避免現有的基于IMS系統(tǒng)的容災倒回技術中,每個用戶注冊時,I-CSCF都需要向HSS請求當前其所服務的UE的相關用戶數據所造成HSS壓力過大的問題,本發(fā)明實施例提供了一種容災倒回的處理方法,該方法應用于IMS系統(tǒng),如圖1所示,IMS系統(tǒng)中包括:P-CSCF(Proxy call session control Function,代理呼叫會話控制功能實體)、I-CSCF(Interrogating call session control Function,查詢呼叫會話控制功能實體)、S-CSCF(Serving call session control Function,服務呼叫會話控制功能實體)、HSS(Home subscriber Server,歸屬用戶服務器)以及AS(Application Server,應用服務器),其中,P-CSCF、I-CSCF、S-CSCF以及AS依次連接,此外,I-CSCF、S-CSCF以及AS均連接于HSS,圖1中的連接關系不限制于有線連接。
結合圖1所示的IMS系統(tǒng),本發(fā)明實施例提供了一種容災倒回的方法,如圖2所示,該方法包括:
201、當容災設備接收到連接于容災設備的前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量。
其中,容災設備為接管故障設備的業(yè)務的非故障設備,已倒回數量為容災設備已倒回給故障設備的UE的數量。
需要說明的是,結合圖1所示的IMS系統(tǒng),當故障設備為S-CSCF時,容災設備也為S-CSCF,此時容災設備的前一網元為直接與該容災設備相連的I-CSCF,當故障設備為AS時,容災設備也為AS,此時容災設備的前一網元為直接與該容災設備相連的S-CSCF。
若容災設備為S-CSCF,則VoLTE SBC將接收到的UE的重注冊請求消息轉發(fā)至I-CSCF,I-CSCF向HSS發(fā)送UAR消息,以獲取上一次重注冊流程中,處理該UE的重注冊請求消息的S-CSCF的域名,該S-CSCF的域名儲存在HSS中,I-CSCF根據得到的S-CSCF的域名,將UE的重注冊請求消息分別發(fā)送給上一次重注冊流程中,處理該UE的重注冊請求消息的S-CSCF。
需要說明的是,由S-CSCF處理重注冊請求消息的流程為基本注冊流程,由AS處理重注冊請求消息的流程為第三方注冊流程,第三方注冊流程在基本流程結束之后。
需要說明的是,在基于IMS的語音業(yè)務VoLTE的系統(tǒng)中,P-CSCF網元的功能可集成于SBC網元中,VoLTE SBC既可以代表SBC網元也可以代表P-CSCF網元。
若容災設備為AS,則S-CSCF向HSS發(fā)送UAR消息,以獲取上一次第三方注冊流程中,處理該UE的重注冊請求消息的AS的域名,該AS的域名儲存在HSS中,S-CSCF根據得到的AS的域名,將UE的重注冊請求消息分別發(fā)送給上一次第三方注冊流程中,處理該UE的重注冊請求消息的AS。
202、當已倒回數量滿足預設倒回目標時,容災設備繼續(xù)處理重注冊請求消息。
其中,預設倒回目標為需倒回UE的數量,或者為需保留UE的數量,或者為需倒回UE的數量占容災設備所負責的所有UE的數量的比例。若預設倒回目標為20萬,也就是說需倒回至已恢復的故障設備的UE的數量為20萬,則當已倒回至已恢復的故障設備的UE的數量達到20萬時,容災設備就可以確定已倒回數量滿足預設倒回目標,此時,由容災設備繼續(xù)處理重注冊請求消息,以容災設備為S-CSCF2為例,容災設備繼續(xù)處理重注冊請求消息的方法為:S-CSCF2向HSS發(fā)送MAR(Multimedia Authorization Request,多媒體鑒權請求)消息,HSS根據該MAR消息返回MAA(Multimedia Authorization Response,多媒體鑒權響應)消息,該MAA消息中攜帶有UE的鑒權數據,S-CSCF2根據返回的MAA消息中攜帶的UE的鑒權數據,構造401消息并向UE發(fā)送401消息,要求終端進行鑒權,若鑒權成功,則UE在S-CSCF2上成功注冊,且因為在上一次處理重注冊請求消息的流程之后,S-CSCF2本地已經存儲了從HSS獲取的UE的相關用戶數據,S-CSCF2不需要向HSS發(fā)送SAR(Server Assignment Request,用戶配置請求)消息以獲取UE的相關用戶數據,減輕了UE的壓力。
需要說明的是,預設倒回目標可以根據容災設備的業(yè)務承載能力或運營商的實際需要進行設置。
203、當已倒回數量未滿足預設倒回目標時,容災設備向前一網元發(fā)送地址重定向指示,地址重定向指示中包含故障恢復設備的地址。
其中,地址重定向指示具體可以為305user proxy響應,故障恢復設備為已恢復的故障設備,地址重定向指示中包含故障恢復設備的地址。
204、前一網元根據地址重定向指示向故障恢復設備轉發(fā)重注冊請求消息,以使得故障恢復設備繼續(xù)處理重注冊請求消息。
需要說明的是,由于故障恢復設備本地并未保存UE的相關用戶數據,所以,故障恢復設備需要向HSS發(fā)送SAR消息,HSS向故障恢復設備返回SAA(Server Assignment Answer,用戶配置響應)消息,該SAA消息中攜帶UE的相關用戶數據,例如,簽約數據等。
本發(fā)明實施例提供的容災倒回的方法,當容災設備接收到連接于容災設備的前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量,容災設備為接管故障設備的業(yè)務的非故障設備,已倒回數量為容災設備已倒回給故障設備的UE的數量;當已倒回數量滿足預設倒回目標時,容災設備繼續(xù)處理重注冊請求消息;當已倒回數量未滿足預設倒回目標時,容災設備向前一網元發(fā)送地址重定向指示,地址重定向指示中包含故障恢復設備的地址,故障恢復設備為已恢復的故障設備;然后,前一網元根據地址重定向指示向故障恢復設備轉發(fā)重注冊請求消息,以使得故障恢復設備繼續(xù)處理重注冊請求消息。與現有技術中每個用戶注冊時,S-CSCF都需要向HSS請求當前其所服務的UE的相關用戶數據,造成HSS壓力過大相比,本發(fā)明實施例中,容災設備只需將自身負責的一部分UE倒回至故障恢復設備,剩余的UE的重注冊請求消息仍然由容災設備自己處理,由于容災設備中之前已經存儲了自己所負責的UE的用戶配置數據,所以容災設備在處理這些UE的重注冊請求消息的過程中,不需要重新向HSS請求UE的相關用戶數據,相應地,HSS也不需要在本地查找并向容災設備返回UE的相關用戶數據,減少了容災設備和HSS的能耗,并且降低了占用的接口帶寬,進而減輕了HSS的壓力。
結合圖2所示的方法流程,為了防止容災倒回過程中,對UE的正常通話造成影響,還需在重注冊請求消息中添加UE的呼叫信息,基于此,在本發(fā)明實施例提供的另一種實現方式中,如圖3所示,上述步驟201,容災設備確定已倒回數量之后,當已倒回數量未滿足預設倒回目標時,該方法具體可以實現為步驟205至步驟207。
205、當已倒回數量未滿足預設倒回目標時,容災設備根據呼叫信息確定待處理UE的通話狀態(tài)。
需要說明的是,VoLTE SBC在接收到待處理UE的重注冊請求消息時,向重注冊請求消息中插入該待處理UE的呼叫信息,并將插入呼叫信息的重注冊請求消息轉發(fā)至I-CSCF,再由I-CSCF將每個待處理UE的重注冊請求消息分別發(fā)送給上一次重注冊流程中處理該待處理UE的重注冊請求消息的S-CSCF。
根據上述流程可知,容災設備仍然可以接收到在上一次重注冊請求消息的處理流程中其所服務的UE發(fā)送的新的重注冊請求消息,容災設備可以根據重注冊請求消息中的呼叫信息確定當前待處理UE的通話狀態(tài)為通話中還是為未通話。
206、當待處理UE的通話狀態(tài)為通話中時,容災設備繼續(xù)處理重注冊請求消息。
可以理解的是,當待處理UE的通話狀態(tài)為通話中時,說明容災設備正在為該UE提供通話服務,為了保證UE的通話不受影響,容災設備應繼續(xù)處理該UE的重注冊請求消息,并繼續(xù)為該UE提供通話服務。通過這種處理方式,可以避免因倒回而中斷呼叫業(yè)務的進行,影響用戶的體驗。
容災設備繼續(xù)處理重注冊請求消息的方法已在圖2所示的實施例中進行了描述,此處不再贅述。
207、當待處理UE的通話狀態(tài)為未通話時,容災設備向前一網元發(fā)送地址重定向指示。
可以理解的是,當待處理UE的通話狀態(tài)為未通話時,說明容災設備當前并沒有為UE提供通話服務,則容災設備向前一網元發(fā)送地址重定向指示,從而將該UE倒回至故障恢復設備。
需要說明的是,當已倒回數量滿足預設目標時,則不再執(zhí)行上述步驟205至207,則是直接由容災設備繼續(xù)處理重注冊請求消息。
可以理解的是,預設目標可根據容災設備的業(yè)務承載能力或運營商的實際需要設定,當已倒回數量滿足預設目標時,容災設備上需要處理的業(yè)務量已在其業(yè)務承載能力之內,所以不需要繼續(xù)執(zhí)行倒回流程。
還需說明的是,現有技術中,在I-CSCF中設置倒回開關,由I-CSCF統(tǒng)一處理UE的重注冊請求消息,導致HSS的壓力較大,而本申請將倒回開關設置在容災設備中,由容災設備處理自身負責的UE的重注冊請求消息,由于容災設備已經存儲了這些UE的相關用戶數據,且并非所有UE都需要倒回,所以容災設備無需重新向HSS請求未倒回的UE的相關用戶數據,所以將倒回開關設置在容災設備中可以減輕HSS的壓力,為了控制容災設備中的倒回開關,在上述步驟201,當容災設備接收到前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量之前,如圖4所示,還需要執(zhí)行步驟401至402。
401、容災設備接收用戶輸入的倒回指令,倒回指令中包括故障恢復設備的地址。
當容災設備接收到用戶輸入的倒回指令時,說明故障設備此時已經恢復,可以將部分UE倒回至故障恢復設備,所以可以繼續(xù)執(zhí)行步驟402。
402、容災設備根據倒回指令開啟倒回開關。
可以理解的是,在上述實施例所描述的容災倒回的流程中,當已倒回數量滿足預設倒回目標時,容災設備關閉倒回開關,停止倒回的流程,后續(xù)接收到的UE的重注冊請求消息直接由容災設備進行處理。
需要說明的是,容災設備上含有計數設備,計數設備可以統(tǒng)計已倒回至故障恢復設備的UE的數量,當計數設備統(tǒng)計的已倒回至故障恢復設備的UE的數量滿足預設倒回目標時,關閉倒回開關。
本發(fā)明實施例提供的容災倒回的方法,在已倒回至故障恢復設備的UE的數量未滿足預設倒回目標,且容災設備判斷當前待處理的UE的通話狀態(tài)為通話中時,容災設備繼續(xù)處理重注冊請求消息,當待處理UE的通話狀態(tài)為未通話時,容災設備向連接于容災設備的前一網元發(fā)送地址重定向指示,由此,可以區(qū)分正在通話的UE,并且不倒回正在通話的UE,可以保證UE的通話不受影響;且當存在需要倒回的UE時,容災設備可以直接將倒回指令中攜帶的故障恢復設備的地址提供給故障恢復設備的前一網元,以使得該前一網元根據故障恢復設備的地址將需要倒回的UE的重注冊請求消息發(fā)送至故障恢復設備,而無需由該前一網元再與HSS進行數據交互而重新確定需倒回的UE所屬的故障恢復設備,從而簡化了容災倒回的流程,且由于減少了用戶注冊過程中,相關網元與HSS之間的數據交互,所以減輕了HSS的壓力,且減少了倒回時間。
本發(fā)明實施例中的容災設備可以為S-CSCF,也可以為AS,以下將分別對容災設備為S-CSCF時容災倒回的方法和容災設備為AS時容災倒回的方法進行說明。
當容災設備為S-CSCF時,本發(fā)明實施例提供的容災倒回的方法如圖5所示,在該實施例中,以S-CSCF2為容災設備,S-CSCF1為故障恢復設備為例進行說明。
501、S-CSCF2根據用戶輸入的倒回指令開啟倒回開關。
502、VoLTE SBC接收UE發(fā)送的重注冊請求消息。
需要說明的是,接入IMS系統(tǒng)的UE都會周期性的向VoLTE SBC發(fā)送重注冊請求消息,VoLTE SBC會分別對每個UE的重注冊消息進行處理。
503、VoLTE SBC在重注冊請求消息中插入UE的呼叫信息。
其中,呼叫信息用于指示終端是否處于通話中。
504、VoLTE SBC將重注冊請求消息轉發(fā)至I-CSCF。
505、I-CSCF向HSS發(fā)送UAR消息。
其中,I-CSCF向HSS發(fā)送UAR消息用于請求獲取上一次重注冊流程中,處理該UE的重注冊請求消息的S-CSCF的域名。
506、HSS向I-CSCF返回UAA消息。
對應的,HSS返回的UAA消息中攜帶上一次重注冊流程中處理該UE的重注冊請求消息的S-CSCF的域名。
507、I-CSCF根據UAA消息,將UE的重注冊請求消息轉發(fā)至S-CSCF2。
其中,S-CSCF2為上一次重注冊流程中處理該UE的重注冊請求消息的S-CSCF。
508、S-CSCF2判斷當前已倒回數量是否滿足預設倒回目標,當當前已倒回數量不滿足預設倒回目標時,S-CSCF2根據接收到的待處理UE的重注冊消息,判斷該待處理UE是否正在通話。
具體地,如果當前已倒回數量滿足預設倒回目標,或者當前已倒回數量未滿足預設倒回目標,且UE正在通話時,S-CSCF2繼續(xù)完成對該待處理UE的注冊。
509、如果該待處理UE沒有處于通話中時,S-CSCF2向I-CSCF返回305Use Proxy響應。
其中,305Use Proxy響應中攜帶故障恢復設備的地址。
510、I-CSCF接收到305Use Proxy響應后,根據305Use Proxy響應中的S-CSCF1的地址,向S-CSCF1轉發(fā)重注冊請求消息。
其中,S-CSCF1為故障恢復設備。
511、S-CSCF1接收待處理UE的重注冊請求消息,向HSS發(fā)送MAR(Multimedia Authorization Request,多媒體鑒權請求)消息。
512、HSS返回MAA(Multimedia Authorization Response,多媒體鑒權響應)消息,該MAA消息中攜帶有UE的鑒權數據。
513、S-CSCF1根據MAA中的UE的鑒權數據,通過I-CSCF和Volte SBC向UE發(fā)送401消息,要求終端進行鑒權。
514、S-CSCF1向HSS發(fā)送SAR消息,以獲取對應UE的相關用戶數據。
515、HSS返回MAA消息。
其中,MAA消息中攜帶UE的相關用戶數據。
516、S-CSCF1通過I-CSCF和Volte SBC向UE發(fā)送200OK消息,提示UE基本注冊成功。
當容災設備為AS時,本發(fā)明實施例提供的容災倒回的方法如圖6所示,在該實施例中,以AS2為容災設備,AS1為故障恢復設備為例進行說明,需要說明的是,由AS處理重注冊請求消息的流程為第三方注冊流程,在基本注冊流程結束之后根據用戶的實際需要確定是否進行第三方注冊流程。
601、AS2根據用戶輸入的倒回指令開啟倒回開關。
602、S-CSCF將重注冊請求消息轉發(fā)至AS2。
需要說明的是,重注冊請求消息指AS2在上一次第三方注冊流程中所服務的UE發(fā)送的消息,在VoLTE SBC轉發(fā)重注冊請求消息之前,還需在重注冊請求消息中插入UE的呼叫信息(圖6中未示出)。
其中,在基于IMS的語音業(yè)務VoLTE的系統(tǒng)中,P-CSCF網元的功能可集成于SBC網元中,用VoLTE SBC代表SBC網元和P-CSCF網元的統(tǒng)一。
603、AS2判斷當前已倒回數量是否滿足預設倒回目標,當當前已倒回數量不滿足預設倒回目標時,AS2根據接收到的待處理UE的重注冊請求消息,判斷該待處理UE是否正在通話。
具體地,如果當前已倒回數量滿足預設倒回目標,或者當前已倒回數量未滿足預設倒回目標,且UE正在通話時,AS2繼續(xù)完成對該待處理UE的注冊。
604、如果該待處理UE沒有處于通話中,AS2向S-CSCF返回305Use Proxy響應。
其中,305Use Proxy響應中攜帶故障恢復設備的地址。
605、S-CSCF接收到305Use Proxy響應后,根據305Use Proxy響應中的AS1的地址,向AS1轉發(fā)重注冊請求消息。
其中,AS1為故障恢復設備。
606、AS1接收待處理UE的重注冊請求消息,向HSS發(fā)送UDR(User Date Request,用戶數據請求)消息,以獲取該待處理UE的相關用戶數據。
607、HSS返回UDA(User Date Answer,用戶數據響應)消息。
其中,該UDA消息中攜帶UE的相關用戶數據。
608、AS1通過S-CSCF、I-CSCF和Volte SBC向UE發(fā)送200OK消息,提示UE第三方注冊成功。
本發(fā)明實施例提供的容災倒回的方法,當容災設備接收到連接于容災設備的前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量,容災設備為接管故障設備的業(yè)務的非故障設備,已倒回數量為容災設備已倒回給故障設備的UE的數量;當已倒回UE的數量滿足預設倒回目標時,容災設備繼續(xù)處理重注冊請求消息;當已倒回UE的數量未滿足預設倒回目標時,容災設備向前一網元發(fā)送地址重定向指示,地址重定向指示中包含故障恢復設備的地址,故障恢復設備為已恢復的故障設備;然后,前一網元根據地址重定向指示向故障恢復設備轉發(fā)重注冊請求消息,以使得故障恢復設備繼續(xù)處理重注冊請求消息。與現有技術中每個用戶注冊時,S-CSCF都需要向HSS請求當前其所服務的UE的相關用戶數據,造成HSS壓力過大相比,本發(fā)明實施例中,容災設備只需將自身負責的一部分UE倒回至故障恢復設備,剩余的UE的重注冊請求消息仍然由容災設備自己處理,由于容災設備中之前已經存儲了自己所負責的UE的相關用戶數據,所以容災設備在處理這些UE的重注冊請求消息的過程中,不需要重新向HSS請求UE的相關用戶數據,相應地,HSS也不需要在本地查找并向容災設備返回UE的相關用戶數據,減少了容災設備和HSS的能耗,并且降低了占用的接口帶寬,進而減輕了HSS的壓力。
對應于圖1所示的方法流程,為了解決在基于IMS系統(tǒng)的容災倒回中,每個用戶注冊時,S-CSCF都需要向HSS請求其所服務的UE的相關用戶數據,造成HSS壓力過大的問題,本發(fā)明實施例提供了一種容災倒回的系統(tǒng),如圖7所示,該系統(tǒng)包括:容災設備701、待處理UE702、前一網元703以及故障恢復設備704。
容災設備701,用于當接收到連接于容災設備701的前一網元703轉發(fā)的待處理用戶設備UE702的重注冊請求消息時,確定已倒回數量,容災設備701為接管故障設備的業(yè)務的非故障設備,已倒回數量為容災設備701已倒回給故障恢復設備704的UE的數量,故障恢復設備704為已恢復的故障設備;當已倒回數量滿足預設倒回目標時,繼續(xù)處理重注冊請求消息;當已倒回數量未滿足預設倒回目標時,向前一網元703發(fā)送地址重定向指示,地址重定向指示中包含故障恢復設備704的地址,預設倒回目標為需倒回UE的數量,或者為需保留UE的數量,或者為需倒回UE的數量占容災設備701所負責的所有UE的數量的比例。
待處理UE702,用于向前一網元703發(fā)送重注冊請求消息。
前一網元703,用于向容災設備701轉發(fā)重注冊請求消息;接收地址重定向指示;根據地址重定向指示向故障恢復設備704轉發(fā)重注冊請求消息。
故障恢復設備704,用于接收前一網元703轉發(fā)的重注冊請求消息;繼續(xù)處理重注冊請求消息。
在本發(fā)明另一實施例中,重注冊消息中攜帶待處理UE的呼叫信息,呼叫信息用于表示待處理UE的通話狀態(tài);容災設備701,還用于當已倒回數量未滿足預設倒回目標時,根據呼叫信息確定待處理UE702的通話狀態(tài);當待處理UE702的通話狀態(tài)為通話中時,繼續(xù)處理重注冊請求消息;當待處理UE702的通話狀態(tài)為未通話時,向前一網元703發(fā)送地址重定向指示。
在本發(fā)明另一實施例中,容災設備701,還用于接收用戶輸入的倒回指令,倒回指令中包括故障恢復設備704的地址;根據倒回指令開啟倒回開關。
在本發(fā)明另一實施例中,容災設備701,還用于當已倒回數量滿足預設倒回目標時,關閉倒回開關。
本發(fā)明實施例提供的容災倒回的系統(tǒng),當容災設備接收到連接于容災設備的前一網元轉發(fā)的待處理用戶設備UE的重注冊請求消息時,確定已倒回數量,容災設備為接管故障設備的業(yè)務的非故障設備,已倒回數量為容災設備已倒回給故障設備的UE的數量;當已倒回數量滿足預設倒回目標時,容災設備繼續(xù)處理重注冊請求消息;當已倒回數量未滿足預設倒回目標時,容災設備向前一網元發(fā)送地址重定向指示,地址重定向指示中包含故障恢復設備的地址,故障恢復設備為已恢復的故障設備;然后,前一網元根據地址重定向指示向故障恢復設備轉發(fā)重注冊請求消息,以使得故障恢復設備繼續(xù)處理重注冊請求消息。與現有技術中每個用戶注冊時,S-CSCF都需要向HSS請求當前其所服務的UE的相關用戶數據,造成HSS壓力過大相比,本發(fā)明實施例中,容災設備只需將自身負責的一部分UE倒回至故障恢復設備,剩余的UE的重注冊請求消息仍然由容災設備自己處理,由于容災設備中之前已經存儲了自己所負責的UE的相關用戶數據,所以容災設備在處理這些UE的重注冊請求消息的過程中,不需要重新向HSS請求UE的相關用戶數據,相應地,HSS也不需要在本地查找并向容災設備返回UE的相關用戶數據,減少了容災設備和HSS的能耗,并且降低了占用的接口帶寬,進而減輕了HSS的壓力。
通過以上的實施方式的描述,所屬領域的技術人員可以清楚地了解到本發(fā)明可借助軟件加必需的通用硬件的方式來實現,當然也可以通過硬件,但很多情況下前者是更佳的實施方式?;谶@樣的理解,本發(fā)明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來,該計算機軟件產品存儲在可讀取的存儲介質中,如計算機的軟盤,硬盤或光盤等,包括若干指令用以使得一臺計算機設備(可以是個人計算機,服務器,或者網絡設備等)執(zhí)行本發(fā)明各個實施例所述的方法。
以上所述,僅為本發(fā)明的具體實施方式,但本發(fā)明的保護范圍并不局限于此,任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內,可輕易想到變化或替換,都應涵蓋在本發(fā)明的保護范圍之內。因此,本發(fā)明的保護范圍應以所述權利要求的保護范圍為準。