本發(fā)明涉及通信系統(tǒng)內(nèi)的容災(zāi)領(lǐng)域，尤其涉及一種容災(zāi)方法、裝置及通信系統(tǒng)。

背景技術(shù)：

為了保證通信系統(tǒng)不能因為單個設(shè)備故障導(dǎo)致系統(tǒng)癱瘓，現(xiàn)有技術(shù)提供了容災(zāi)機(jī)制，為通信設(shè)備配置容災(zāi)設(shè)備，當(dāng)該通信設(shè)備故障時，其執(zhí)行的業(yè)務(wù)轉(zhuǎn)交給對應(yīng)的容災(zāi)設(shè)備執(zhí)行，以此來維持通信系統(tǒng)的正常運行。

現(xiàn)有的容災(zāi)方法為：源設(shè)備或者中轉(zhuǎn)設(shè)備直接將通信請求(認(rèn)證業(yè)務(wù)等)發(fā)送至目標(biāo)設(shè)備，目標(biāo)設(shè)備若因為設(shè)備故障導(dǎo)致不可用時，目標(biāo)設(shè)置通知源設(shè)備將這些通信請求轉(zhuǎn)發(fā)至目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行處理。這種方法因為需要先將通信請求發(fā)送給目標(biāo)設(shè)備，過程較慢，效率低。

因此，如何提供一種現(xiàn)有容災(zāi)效率低的容災(zāi)方法，是本領(lǐng)域技術(shù)人員亟待解決的技術(shù)問題。

技術(shù)實現(xiàn)要素：

本發(fā)明提供了一種容災(zāi)方法、裝置及通信系統(tǒng)，以解決現(xiàn)有容災(zāi)效率低的問題。

本發(fā)明提供了一種容災(zāi)方法，其包括：在接收到源設(shè)備的通信請求后，確定通信請求的目標(biāo)設(shè)備；判斷目標(biāo)設(shè)備的工作狀態(tài)是否可用，若不可用，則通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信。

進(jìn)一步的，判斷目標(biāo)設(shè)備的工作狀態(tài)是否可用包括：判斷其與目標(biāo)設(shè)備之間是否存在可用鏈路，若否，則工作狀態(tài)為不可用。

進(jìn)一步的，還包括：若否，則發(fā)動單次建鏈，當(dāng)單次建鏈?zhǔn)〈螖?shù)大于預(yù)設(shè)值時，工作狀態(tài)為不可用。

進(jìn)一步的，通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信包括：查找目標(biāo)設(shè)備的容災(zāi)設(shè)備，將容災(zāi)設(shè)備的標(biāo)識發(fā)送至源設(shè)備。

進(jìn)一步的，通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信包括：通知源設(shè)備目標(biāo)設(shè)備不可用，通知源設(shè)備查找目標(biāo)設(shè)備的容災(zāi)設(shè)備。

本發(fā)明提供了一種容災(zāi)裝置，其包括：確定模塊，用于在接收到源設(shè)備的通信請求后，確定通信請求的目標(biāo)設(shè)備；處理模塊，用于判斷目標(biāo)設(shè)備的工作狀態(tài)是否可用，若不可用，則通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信。

進(jìn)一步的，處理模塊用于判斷其與目標(biāo)設(shè)備之間是否存在可用鏈路，若否，則工作狀態(tài)為不可用。

進(jìn)一步的，處理模塊還用于若否，則發(fā)動單次建鏈，當(dāng)單次建鏈?zhǔn)〈螖?shù)大于預(yù)設(shè)值時，工作狀態(tài)為不可用。

進(jìn)一步的，處理模塊用于查找目標(biāo)設(shè)備的容災(zāi)設(shè)備，將容災(zāi)設(shè)備的標(biāo)識發(fā)送至源設(shè)備。

進(jìn)一步的，處理模塊用于通知源設(shè)備目標(biāo)設(shè)備不可用，通知源設(shè)備查找目標(biāo)設(shè)備的容災(zāi)設(shè)備。

本發(fā)明也提供了一種通信系統(tǒng)，其包括本發(fā)明提供的容災(zāi)裝置。

本發(fā)明的有益效果：

本發(fā)明提供了一種新的容災(zāi)方法，在發(fā)送通信請求到目標(biāo)設(shè)備之前，先判斷目標(biāo)設(shè)備的工作狀態(tài)，若目標(biāo)設(shè)備不可用，則直接通知源設(shè)備將通信請求發(fā)送給容災(zāi)設(shè)備，而不必發(fā)送給目標(biāo)設(shè)備，減少了通信流程，提供了容災(zāi)效率，解決了現(xiàn)有容災(zāi)效率低的問題。

附圖說明

圖1為本發(fā)明第一實施例提供的容災(zāi)裝置的結(jié)構(gòu)示意圖；

圖2為本發(fā)明第二實施例提供的容災(zāi)方法的流程圖；

圖3為本發(fā)明第三實施例提供的容災(zāi)方法的流程圖。

具體實施方式

現(xiàn)通過具體實施方式結(jié)合附圖的方式對本發(fā)明做出進(jìn)一步的詮釋說明。

第一實施例：

圖1為本發(fā)明第一實施例提供的容災(zāi)裝置的結(jié)構(gòu)示意圖，由圖1可知，在本實施例中，本發(fā)明提供的容災(zāi)裝置1包括：

確定模塊11，用于在接收到源設(shè)備的通信請求后，確定通信請求的目標(biāo)設(shè)備；

處理模塊12，用于判斷目標(biāo)設(shè)備的工作狀態(tài)是否可用，若不可用，則通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信，若可用則轉(zhuǎn)發(fā)通信請求至目標(biāo)設(shè)備。

在一些實施例中，上述實施例中的處理模塊12用于判斷其與目標(biāo)設(shè)備之間是否存在可用鏈路，若否，則工作狀態(tài)為不可用。

在一些實施例中，上述實施例中的處理模塊12還用于若否，則發(fā)動單次建鏈，當(dāng)單次建鏈?zhǔn)〈螖?shù)大于預(yù)設(shè)值時，工作狀態(tài)為不可用。

在一些實施例中，上述實施例中的處理模塊12用于查找目標(biāo)設(shè)備的容災(zāi)設(shè)備，將容災(zāi)設(shè)備的標(biāo)識發(fā)送至源設(shè)備。

在一些實施例中，上述實施例中的處理模塊12用于通知源設(shè)備目標(biāo)設(shè)備不可用，通知源設(shè)備查找目標(biāo)設(shè)備的容災(zāi)設(shè)備。

對應(yīng)的，本發(fā)明也提供了一種通信系統(tǒng)，其包括本發(fā)明提供的容災(zāi)裝置1。

第二實施例：

圖2為本發(fā)明第二實施例提供的容災(zāi)方法的流程圖，由圖2可知，在本實施例中，本發(fā)明提供的容災(zāi)方法包括以下步驟：

S201：在接收到源設(shè)備的通信請求后，確定通信請求的目標(biāo)設(shè)備；

S202：判斷目標(biāo)設(shè)備的工作狀態(tài)是否可用，若不可用，則通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信。

在一些實施例中，上述實施例中的判斷目標(biāo)設(shè)備的工作狀態(tài)是否可用包括：判斷其與目標(biāo)設(shè)備之間是否存在可用鏈路，若否，則工作狀態(tài)為不可用。

在一些實施例中，上述實施例還包括：若否，則發(fā)動單次建鏈，當(dāng)單次建鏈?zhǔn)〈螖?shù)大于預(yù)設(shè)值時，工作狀態(tài)為不可用。

在一些實施例中，上述實施例中的通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信包括：查找目標(biāo)設(shè)備的容災(zāi)設(shè)備，將容災(zāi)設(shè)備的標(biāo)識發(fā)送至源設(shè)備。

在一些實施例中，上述實施例中的通知源設(shè)備與目標(biāo)設(shè)備的容災(zāi)設(shè)備進(jìn)行通信包括：通知源設(shè)備目標(biāo)設(shè)備不可用，通知源設(shè)備查找目標(biāo)設(shè)備的容災(zāi)設(shè)備。

現(xiàn)結(jié)合具體應(yīng)用場景對本發(fā)明做進(jìn)一步的詮釋說明。

第三實施例：

本實施例以GBA通信系統(tǒng)為例對本發(fā)明進(jìn)行詮釋說明，GAA(Generic Authentication Architecture)是一種通用的鑒權(quán)機(jī)制，GAA有兩種類型的認(rèn)證機(jī)制，一個基于通訊實體間的共享密鑰，稱為GBA(Generic Bootstrapping Architecture)；另一種是基于(公共、私有)鑰匙對稱數(shù)字證書，稱為SSC(Support for Subscriber Certificates),GBA采用共享密鑰機(jī)制,方便UE和網(wǎng)絡(luò)部署,得到廣泛應(yīng)用。在GBA架構(gòu)中，引入了兩個邏輯網(wǎng)元，BSF和AP，BSF(Bootstrapping Server Function)作為引導(dǎo)服務(wù)功能，可以從HSS獲得GBA的用戶安全設(shè)置和AKA認(rèn)證向量；AP(Authentication Proxy)作為認(rèn)證代理功能，代替AS完成對UE的認(rèn)證，然后通過AP和AS之間的接口轉(zhuǎn)發(fā)UE請求到AS。目前在標(biāo)準(zhǔn)中針對BSF和AP的沒有容災(zāi)描述，傳統(tǒng)容災(zāi)的方案是在上一跳網(wǎng)元中設(shè)置下一跳對應(yīng)容災(zāi)的網(wǎng)元，本方案直接采用終端和BSF生產(chǎn)的B-TID中BSF主機(jī)名實現(xiàn)容災(zāi)，簡單，易實施。

結(jié)合本實施例的運用場景，本專利的核心思想就是利用BSF在引導(dǎo)時候生產(chǎn)的B-TID中BSF域名或者主機(jī)名,AP在向該BSF發(fā)送BIR之前，首先判斷該BSF的狀態(tài)，當(dāng)該BSF主機(jī)的狀態(tài)不可用的時候，返回重新引導(dǎo)指示消息，要求終端重新引導(dǎo)，在終端重新引導(dǎo)的時候選擇了容災(zāi)的BSF，由容災(zāi)BSF提供引導(dǎo)功能。

圖3為本發(fā)明第三實施例提供的容災(zāi)方法的流程圖，由圖3可知，在本實施例中，本發(fā)明提供的容災(zāi)方法包括以下步驟：

S301：用戶終端UE與BSF完成引導(dǎo)。

本步驟為UE通過BSF引導(dǎo)流程，BSF生成B-TID并發(fā)送給UE流程。具體的，本步驟包括：

UE向BSF發(fā)送GET請求消息，參數(shù)攜帶IMPI；

BSF收到請求消息后，對于初始引導(dǎo)流程，BSF通過Zh接口向HSS發(fā)送認(rèn)證請求消息，請求消息中攜帶IMPI信息；

HSS返回認(rèn)證響應(yīng)消息，響應(yīng)消息中攜帶認(rèn)證向量；

BSF構(gòu)造401認(rèn)證響應(yīng)消息，并發(fā)送給UE；

UE構(gòu)造請求消息并發(fā)送給BSF，請求消息中包括鑒權(quán)的response值；

BSF收到UE發(fā)送的請求后，并引導(dǎo)成功后，BSF構(gòu)造200OK成功響應(yīng)消息，響應(yīng)消息中攜帶B-TID等信息，并發(fā)送給UE，B-TID的生成規(guī)則為：base64encode(RAND)@BSF_servers_domain_name。

S302：中轉(zhuǎn)設(shè)備AP檢測BSF主機(jī)的工作狀態(tài)。

本步驟包括以下步驟：

AP根據(jù)配置的檢測定時器間隔設(shè)置檢測定時器；

檢測定時器時間到了后，AP判斷到目的BSF主機(jī)是否存在可用鏈路，如果不存在鏈路，則檢測進(jìn)程發(fā)起單次建鏈；

AP判斷本次定時器檢測主機(jī)狀態(tài)為正常，則將該主機(jī)檢測成功次數(shù)加1，如果成功次數(shù)大于等于可用檢測次數(shù)，則設(shè)置目前主機(jī)狀可用；

AP判斷本次定時器檢測主機(jī)狀態(tài)為故障，則將該主機(jī)檢測不可用次數(shù)加1，如果失敗次數(shù)大于等于故障檢測次數(shù)，則設(shè)置目前主機(jī)狀不可用。

S303：AP接收到發(fā)送給BSF通信請求，判斷目標(biāo)設(shè)備的工作狀態(tài)不可用， 通知終端重新引導(dǎo)。

AP在接收到終端發(fā)起的鑒權(quán)請求(通信請求的一種具體應(yīng)用)后，終端在HTTP消息中攜帶了B-TID，AP在發(fā)送BIR請求到BSF之前，根據(jù)BSF主機(jī)的不同狀態(tài)做不同的處理。本步驟以BSF主機(jī)的工作狀態(tài)不可用為例進(jìn)行說明，若主機(jī)狀態(tài)可用，后續(xù)流程與步驟S305相同。

具體的，本步驟包括以下步驟：

終端發(fā)送HTTP GET消息到AP協(xié)商GBA鑒權(quán)方式；

AP回復(fù)401，指示UE進(jìn)行GBA鑒權(quán)；

終端攜帶B-TID向AP發(fā)起GBA鑒權(quán)請求；

AP解析B-TID，提取出BSF主機(jī)名，判斷BSF主機(jī)的狀態(tài)為不可用，AP向終端返回重新引導(dǎo)指示。AP可以采用三種方案給終端返回重新引導(dǎo)指示：AP向終端返回401消息其中stale＝false或者不攜帶stale＝false，要求終端進(jìn)行重新引導(dǎo)；AP向終端返回401消息，在401消息中擴(kuò)展參數(shù)，在擴(kuò)展參數(shù)中攜帶bsf2的IP地址或者主機(jī)名或者域名，要求終端向bsf2進(jìn)行重新引導(dǎo)；AP向終端返回3XX消息，在3XX消息中攜帶bsf2的IP地址或者主機(jī)名或者域名,終端接收到該3XX消息后，重新向bsf2引導(dǎo)。

S304：終端向容災(zāi)設(shè)備進(jìn)行重新引導(dǎo)。

終端在接收到重新引導(dǎo)消息后，根據(jù)自身配置或者BSF主機(jī)名/域名到DNS查詢，獲得BSF2(容災(zāi)設(shè)備)的IP地址，而后終端按照步驟S301的內(nèi)容向BSF2發(fā)起引導(dǎo)，引導(dǎo)成功后，BSF2返回B-TID為base64encode(RAND)@BSF2給終端。

S305：AP接收到發(fā)送給BSF2通信請求，判斷容災(zāi)設(shè)備的工作狀態(tài)可用，執(zhí) 行后續(xù)鑒權(quán)流程。

終端發(fā)送攜帶BSF2的B-TID base64encode(RAND)@BSF2 HTTP消息到AP，AP判斷BSF2狀態(tài)可用。AP發(fā)送BIR消息到HSS，查詢鑒權(quán)數(shù)據(jù)。BSF2通過BIA消息返回鑒權(quán)數(shù)據(jù)。AP在鑒權(quán)通過后，將HTTP消息轉(zhuǎn)發(fā)給相應(yīng)的AS。

本實施例結(jié)合具體運用場景，提供了一種AP和BSF之間實現(xiàn)容災(zāi)的一種方法，包括主機(jī)檢測，容災(zāi)處理。在AP通過Zn接口發(fā)送BIR消息前，判斷BSF主機(jī)狀態(tài)，當(dāng)對應(yīng)的BSF宕機(jī)或者網(wǎng)絡(luò)中斷，AP返回重新引導(dǎo)指示消息，要求終端進(jìn)行重新引導(dǎo)，終端將鑒權(quán)引導(dǎo)消息發(fā)送到容災(zāi)BSF，保證鑒權(quán)業(yè)務(wù)可以正常的進(jìn)行下去。

綜上可知，通過本發(fā)明的實施，至少存在以下有益效果：

在發(fā)送通信請求到目標(biāo)設(shè)備之前，先判斷目標(biāo)設(shè)備的工作狀態(tài)，若目標(biāo)設(shè)備不可用，則直接通知源設(shè)備將通信請求發(fā)送給容災(zāi)設(shè)備，而不必發(fā)送給目標(biāo)設(shè)備，減少了通信流程，提供了容災(zāi)效率，解決了現(xiàn)有容災(zāi)效率低的問題。

以上僅是本發(fā)明的具體實施方式而已，并非對本發(fā)明做任何形式上的限制，凡是依據(jù)本發(fā)明的技術(shù)實質(zhì)對以上實施方式所做的任意簡單修改、等同變化、結(jié)合或修飾，均仍屬于本發(fā)明技術(shù)方案的保護(hù)范圍。