重啟恢復時間的調整方法和裝置與流程

2023-05-27 23:50:21

本發明涉及數據網絡通信領域，尤其涉及一種重啟恢復時間的調整方法和裝置。

背景技術：

rsvp-te(resourcereservationprotocol-trafficengineer基於流量工程的資源預留協議)是一種基於mpls多協議標籤交換的流量工程技術。通過信息發布、路徑計算、信令交互、流量轉發四個部件實現業務流量在te隧道中的轉發。

基於rsvp-te的gr(gracefulrestart,優雅重啟)提供了一種業務流量的nsf(non-stopforwarding，不間斷轉發)機制，網絡中設備的控制面發生故障時，可以通過該設備的鄰居設備恢復控制面信息，轉發信息在恢復控制面恢復的階段能夠保持住，以保證流量的轉發。

gr技術需要基於hello檢測，檢測的目的之一就是需要感知鄰居發生了重啟。hello檢測過程中會攜帶restarttime重啟時間和recoverytime恢復時間兩個參數，分別表示重啟後恢復控制通道需要的時間以及控制通道恢復信令與轉發需要的時間。在檢測到鄰居發生了重啟之後，需要為重啟方發送恢復報文，該節點我們稱為輔助方。

restarttime重啟時間，主要是用於輔助方，輔助方需要等待重啟方等待多久，才給重啟方發送恢復報文；recoverytime，主要用於重啟方，需要多久才能完全恢復信令與轉發。在hello的交互中雙方都保存各個鄰居的這兩個參數，一旦鄰居重啟將通過這些重啟前的參數進行恢復。

在實際工程部署優雅重啟的過程中，主流廠商固定配置restarttime和recoverytime。實際上節點te隧道的數量對於恢復時間有直接的影響。節點間可能存在多條lsp隧道，lsp數目隨著時間的變化是動態變化的。經過重啟點的隧道越多，恢復時間就越長。工程部署的時候，往往靜態配置這一恢復時間，隨著開通業務的增加，承載的隧道數目也增多，需要重新配置，給運維也帶來了較多的麻煩。若沒有及時更新配置恢復時間參數，在節點重啟 時，可能由於恢復時間不足，造成te隧道控制平面恢復失敗，導致業務中斷。

技術實現要素：

本發明的主要目的在於提供一種重啟恢復時間的調整方法和裝置，旨在解決網絡設備在優雅重啟時恢復時間不能根據lsp數目動態調整，可能由於恢復時間的不足造成te隧道恢復失敗，從而導致業務中斷的問題。

為實現上述目的，本發明提供一種重啟恢復時間的調整方法，所述重啟恢復時間的調整方法包括步驟：

第一節點獲取與其相鄰的第二節點之間的隧道數目；

所述第一節點根據所述隧道數目確定其重啟恢復時間；

所述第一節點將所述重啟恢復時間發送至第二節點，以供所述第二節點在第一節點重啟時根據所述重啟恢復時間向所述第一節點發送恢復報文。

可選地，所述第一節點根據所述隧道數目確定其重啟恢復時間的步驟之前包括步驟：

所述第一節點判斷所述隧道數目是否發生變化；

在所述隧道數目發生變化時，執行所述第一節點根據所述隧道數目確定其重啟恢復時間的步驟。

可選地，所述第一節點將所述重啟恢復時間發送至第二節點的步驟之前包括步驟：

所述第一節點判斷所述重啟恢復時間是否發生變化；

在所述重啟恢復時間發生變化時，執行所述第一節點將所述重啟恢復時間發送至第二節點的步驟。

可選地，所述重啟恢復時間的調整方法還包括步驟：

所述第一節點接收與其相鄰的所述第二節點發送的重啟恢復時間；

所述第一節點根據所述重啟恢復時間更新存儲在本地的第二節點的重啟恢復時間。

可選地，所述第一節點根據所述重啟恢復時間更新存儲在本地的第二節點的重啟恢復時間的步驟之前還包括步驟：

所述第一節點判斷接收到的所述重啟恢復時間與本地存儲的重啟恢復時間是否一致；

在接收到的所述重啟恢復時間與本地存儲的重啟恢復時間不一致時，執 行所述第一節點根據所述重啟恢復時間更新存儲在本地的第二節點的重啟恢復時間的步驟。

本發明進一步提供一種重啟恢復時間的調整裝置，所述重啟恢復時間調整的裝置包括：

獲取模塊，用於獲取與其所在的節點相鄰的其它節點之間的隧道數目；

確定模塊，用於根據所述隧道數目確定重啟恢復時間；

發送模塊，用於將所述重啟恢復時間發送至所述與其所在的節點相鄰的其它節點，以供所述其它節點在其所在節點重啟時根據所述重啟恢復時間向其所在節點發送恢復報文。

可選地，所述重啟恢復時間的調整裝置還包括：

第一判斷模塊，用於判斷所述隧道數目是否發生變化；

所述確定模塊還用於在所述隧道數目發生變化時，根據所述隧道數目計算確定其重啟恢復時間。

可選地，所述重啟恢復時間的調整裝置還包括：

第二判斷模塊，用於判斷所述重啟恢復時間是否發生變化；

所述發送模塊還用於在所述重啟恢復時間發生變化時，將所述重啟恢復時間發送至與其所在的節點相鄰的其它節點，以供所述其它節點在其所在節點重啟時根據所述重啟恢復時間向其所在節點發送恢復報文。

可選地，所述重啟恢復時間的調整裝置還包括：

接收模塊，用於接收與其所在節點相鄰的所述其它節點發送的重啟恢復回復時間；

存儲模塊，用於根據所述重啟恢復時間更新存儲在本地的所述其它節點的重啟恢復時間。

可選地，所述重啟恢復時間的調整裝置還包括：

第三判斷模塊，用於判斷接收到的所述重啟恢復時間與本地存儲的重啟恢復時間是否一致；

所述存儲模塊還用於在所述接收到的重啟恢復時間與本地存儲的重啟恢復時間不一致時，根據所述重啟恢復時間更新存儲在本地的所述其它節點的重啟恢復時間。

本發明提出的重啟恢復時間的調整方法和裝置，第一節點獲取其與第二節點之間的隧道數目；所述第一節點根據所述隧道數目計算確定其第一恢復時間；所述第一節點更新報文中的所述第一恢復時間並發送至第二節點。在第一節點發生重啟時，第二節點可根據接收到的第一節點發送的報文中的根據二者之間隧道數目動態調整的恢復時間向第一節點發送恢復消息，保證第一節點充足的恢復時間，而不會由於recoverytime恢復時間不足，造成te隧道控制平面恢復失敗，導致業務中斷。

附圖說明

圖1為本發明重啟恢復時間的調整方法第一實施例的流程示意圖；

圖2為本發明基於lsp隧道數目增減rsvphello調整recovery_time交互場景一；

圖3為本發明一實施例判斷隧道數目是否發生變化的流程示意圖；

圖4為本發明基於lsp隧道數目增減rsvphello調整recovery_time交互場景二；

圖5為本發明一判斷恢復時間是否發生變化的流程示意圖；

圖6為本發明重啟恢復時間的調整方法第二實施例的流程示意圖；

圖7為本發明重啟恢復時間的調整裝置第二實施例的中判斷恢復時間是否與本地一致的流程示意圖；

圖8為本發明重啟恢復時間的調整裝置第一實施例的模塊示意圖；

圖9為本發明一實施例包括第一判斷模塊的的模塊示意圖；

圖10為本發明一實施例中包括第二判斷模塊的模塊示意圖；

圖11為本發明重啟恢復時間的調整裝置第二實施例的模塊示意圖；

圖12為本發明重啟恢復時間的調整裝置第二實施例中包括第三判斷模塊的模塊示意圖。

本發明目的的實現、功能特點及優點將結合實施例，參照附圖做進一步說明。

具體實施方式

應當理解，此處所描述的具體實施例僅僅用以解釋本發明，並不用於限定本發明。

本發明提供一種重啟恢復時間的調整方法。

參照圖1，圖1為本發明重啟恢復時間的調整方法第一實施例的流程示意圖。

本實施例提出一種重啟恢復時間的調整方法，所述重啟恢復時間的調整方法包括步驟：

步驟s10，第一節點獲取與其相鄰的第二節點之間的隧道數目；

在本實施例中，各個節點之間按照rsvp-te(resourcereservationprotocol-trafficengineer基於流量工程的資源預留協議)信令交互完成隧道的建立，其中建立隧道的路徑可以是在本地進行的配置，也可以從網絡獲取。建立隧道連接的各個節點之間通過hello報文交互確認鄰居節點的狀態，其中所述hello報文攜帶了restarttime重啟時間和recoverytime恢復時間兩個參數。

在本實施例中，所述recoverytime恢復時間根據建立了鄰居關係的節點間的lsp隧道數目確定。

步驟s20，所述第一節點根據所述隧道數目確定其重啟恢復時間；

在本實施例中，在獲取到建立鄰居關係的節點間的隧道數目後，可根據一個隨所述隧道數目單調的函數計算得到所述恢復時間，例如可根據公式恢復時間t＝(t1+lsp_count*t2)ms計算得到，其中t1是一個基礎時間，t2是lsp數目變化的時間因子，也可以是其他的一個基於lsp數目的單調函數。

如圖2所示，100條lsp從r1經過r2，目的地到r3。這樣r1、r2、r3兩兩之間存在100條lsp，這個時候r1和r2，r2和r3分別建立有hello鄰居關係。

r1和r2、r2和r3兩兩之間分別通告的recovery_time為t1+100*t2ms。保存與各自本地。

當r1和r3之間經過r2再增加一條lsp時，相當於r1和r2，以及r2和r3之間又新增一條lsp。這個時候r1和r2，以及r2和r3之間通告的recovery_time為t1+101*t2，同時也保存於各自本地。

步驟s30，所述第一節點將所述重啟恢復時間發送至第二節點，以供所述第二節點在第一節點重啟時根據所述重啟恢復時間向所述第一節點發送恢復報文。

在本實施例中，所述鄰居節點之間通過hello報文交互，所述hello報文攜帶了restarttime重啟時間和recoverytime恢復時間兩個參數。

進一步地，參照圖3，所述步驟s20之前還包括步驟：

步驟s40，所述第一節點判斷所述隧道數目是否發生變化；

在本實施例中，第一節點與第二節點之間的隧道數目可能隨時間的變化產生變化，所述第一節點定時獲取與所述第二節點之間的隧道數目，並將所述隧道數目保存在本地，在下次獲取兩節點之間的隧道數目後，將獲取到的所述隧道數目與本地保存的隧道數目進行比對，確認兩節點之間的隧道數目是否發生變化。

在所述隧道數目發生變化時，執行所述步驟s20。

在本實施例中，所述第一節點在確認與第二節點之間的隧道數目發生變化時，採用預設的隨隧道數目單調的函數公式計算所述恢復時間並發送到第二節點。

可以理解的是，在檢測到所述第一節點與第二節點之間的隧道數目沒有發生變化時，則可不進行恢復時間的更新操作，只需向第二節點發送原來的恢復時間即可。

如圖4所示，r4-r5-r6，r4-r5-r7分別具有100條lsp，這種情況下r4，r5之間存在200條lsp，r5，r6之間存在100條lsp，r5，r7之間也存在100條lsp。他們兩兩建立hello關係通告的recovery_time分別為：(r4，r5)為t1+200*t2；(r5，r6)為t1+100*t2；(r5，r7)為t1+100*t2。

如果在r5和r7之間增加一條lsp，那麼r5和r7之間hello通告的recovery_time修改為：t1+101*t2。由於其他鄰居間lsp數目沒變，所以維持原來的recovery_time不變。

進一步地，參照圖5，所述步驟s30之前包括步驟：

步驟s50，所述第一節點判斷所述重啟恢復時間是否發生變化；

在本實施例中，所述第一節點還可以在第一節點獲取到與第二節點之間的隧道數目之後進行所述第一節點的重啟恢復時間的計算，根據計算出的所 述第一節點的重啟恢復時間判斷是否發生了變化，根據所述判斷結果確定是否在組建hello交互報文時的，將所述報文中第一節點的重啟恢復時間參數更新。

在所述重啟恢復時間發生變化時，執行所述步驟s30。

本實施例提出的重啟恢復時間的調整方法，第一節點獲取與其相鄰的第二節點之間的隧道數目；所述第一節點根據所述隧道數目確定其重啟恢復時間；所述第一節點將所述重啟恢復時間發送至第二節點，以供所述第二節點在第一節點重啟時根據所述重啟恢復時間向所述第一節點發送恢復報文。在每一次發送hello報文進行交互時，都將獲取到的所述恢復時間更新在報文中，並將所述hello報文發送至鄰居節點。在第一節點發生重啟時，第二節點可根據接收到的第一節點發送的報文中的根據二者之間隧道數目動態調整的重啟恢復時間向第一節點發送恢復消息，保證第一節點充足的恢復時間，而不會由於recoverytime恢復時間不足，造成te隧道控制平面恢復失敗，導致業務中斷。

進一步地，基於本發明第一實施例提出本發明重啟恢復時間的調整方法的第二實施例，參照圖6，所述重啟恢復時間的調整方法還包括步驟：

步驟s60，所述第一節點接收與其相鄰的所述第二節點發送的重啟恢復時間；

在本實施例中，所述第一節點與第二節點之間建立了連接隧道，第一節點與第二節點互為鄰居節點，在第二節點進行優雅重啟時，所述第一節點即為所述第二節點的輔助方，向第二節點發送恢復報文，在進行hello報文交互時，兩節點互相發送並接收所述hello報文，故第一節點也可接收第二節點發送的hello報文。

步驟s70，所述第一節點根據所述重啟恢復時間更新存儲在本地的第二節點的重啟恢復時間。

在本實施例中，所述第一節點接收到第二節點發送的所述報文後，提取所述報文中的重啟恢復時間，並將所述重啟恢復時間保存在本地，在所述第二節點進行重啟時，所述第一節點作為第二節點的輔助方，根據所述重啟恢復時間向所述第二節點發送恢復報文。

在本實施例中，所述第一節點在接收到所述第二節點發送的報文後，提取所述報文中的重啟恢復時間，即所述第二節點進行優雅重啟時的恢復時間，在所述第一節點提取出所述重啟恢復時間後，將所述重啟恢復時間更新保存在本地，作為新的重啟恢復時間，即所述第二節點發生優雅重啟時，向所述第二節點發送恢復報文的時間。

進一步地，參照圖7，所述步驟s70之前還包括步驟：

步驟s80，所述第一節點判斷接收到的所述重啟恢復時間與本地存儲的重啟恢復時間是否一致；

在本實施例中，所述第一節點在提取到所述重啟恢復時間之後，可將所述重啟恢復時間與保存在本地的重啟恢復時間進行對比，根據所述對比結果判斷是否需要對保存在本地的重啟恢復時間，即所述所述第二節點發生優雅重啟時，第一節點向所述第二節點發送恢復報文的時間，進行更新。

在所述報文中的第二恢復時間與本地存儲的第三存儲時間不一致時，執行所述步驟s70。

在本實施例中，在第一節點判斷所述報文中的重啟恢復時間與所述保存在本地的重啟恢復時間不一致時，將所述報文中的所述重啟恢復時間作為新的重啟恢復時間保存在本地，作為所述第二節點發生優雅重啟時，第一節點向所述第二節點發送恢復報文的時間。

本實施例提出的重啟恢復時間的調整方法，在節點接收到鄰居節點發送的報文後，根據從所述報文中提取出的所述恢復時間與本地保存的恢復時間進行對比，確定所述恢復時間是否發生變化，在所述恢復時間發生變化時，將所述變化的恢復時間更新保存在本地作為鄰居節點的優雅重啟恢復時間，在所述恢復時間沒有發生變化時，不更新所述保存在本地的恢復時間，更加節省資源。

本發明進一步提供一種重啟恢復時間的調整裝置。

如圖8所示，圖8為本發明重啟恢復時間的調整裝置第一實施例的功能模塊示意圖。需要強調的是，對本領域的技術人員來說，圖8所示功能模塊圖僅僅是一個較佳實施例的示例圖，本領域的技術人員圍繞圖8所示的重啟恢復時間的調整裝置的功能模塊，可輕易進行新的功能模塊的補充；各功能 模塊的名稱是自定義名稱，僅用於輔助理解該重啟恢復時間的調整裝置的各個程序功能塊，不用於限定本發明的技術方案，本發明技術方案的核心是，各自定義名稱的功能模塊所要達成的功能。

本實施例提出一種重啟恢復時間的調整裝置，所述重啟回復時間的調整裝置包括：

獲取模塊10，用於獲取與其所在的節點相鄰的其它節點之間的隧道數目；

在本實施例中，各個節點之間按照rsvp-te(resourcereservationprotocol-trafficengineer基於流量工程的資源預留協議)信令交互完成隧道的建立，其中建立隧道的路徑可以是在本地進行的配置，也可以從網絡獲取。建立隧道連接的各個節點之間通過hello報文交互確認鄰居節點的狀態，其中所述hello報文攜帶了restarttime重啟時間和recoverytime恢復時間兩個參數。

在本實施例中，所述recoverytime恢復時間根據建立了鄰居關係的節點間的lsp隧道數目確定。

確定模塊20，用於根據所述隧道數目確定重啟恢復時間；

在本實施例中，在獲取到建立鄰居關係的節點間的隧道數目後，可根據一個隨所述隧道數目單調的函數計算得到所述恢復時間，例如可根據公式恢復時間t＝(t1+lsp_count*t2)ms計算得到，其中t1是一個基礎時間，t2是lsp數目變化的時間因子，也可以是其他的一個基於lsp數目的單調函數。

如圖2所示，100條lsp從r1經過r2，目的地到r3。這樣r1、r2、r3兩兩之間存在100條lsp，這個時候r1和r2，r2和r3分別建立有hello鄰居關係。

r1和r2、r2和r3兩兩之間分別通告的recovery_time為t1+100*t2ms。保存與各自本地。

當r1和r3之間經過r2再增加一條lsp時，相當於r1和r2，以及r2和r3之間又新增一條lsp。這個時候r1和r2，以及r2和r3之間通告的recovery_time為t1+101*t2，同時也保存於各自本地。

發送模塊30，用於將所述重啟恢復時間發送至所述與其所在的節點相鄰的其它節點，以供所述其它節點在其所在節點重啟時根據所述重啟恢復時間 向其所在節點發送恢復報文。

在本實施例中，鄰居節點之間通過hello報文交互，所述hello報文攜帶了restarttime重啟時間和recoverytime恢復時間兩個參數。所述其它節點作為輔助方時在主節點重啟時根據所述重啟恢復時間向主節點發送恢復報文。

進一步地，參照圖9，所述rsvp-te優雅重啟的恢復時間調整裝置還包括：

第一判斷模塊40，用於判斷所述隧道數目是否發生變化；

在本實施例中，一節點與其鄰居節點之間的隧道數目可能隨時間的變化產生變化，所述一節點定時獲取與其鄰居二節點之間的隧道數目，並將所述隧道數目保存在本地，在下次獲取兩節點之間的隧道數目後，將獲取到的所述隧道數目與本地保存的隧道數目進行比對，確認兩節點之間的隧道數目是否發生變化。

所述確定模塊20還用於在所述隧道數目發生變化時，根據所述隧道數目計算確定其重啟恢復時間。

可以理解的是，在檢測到所述一節點與其鄰居節點之間的隧道數目沒有發生變化時，則可不進行恢復時間的更新操作，只需向其鄰居節點發送原來的恢復時間即可。

如圖4所示，r4-r5-r6，r4-r5-r7分別具有100條lsp，這種情況下r4，r5之間存在200條lsp，r5，r6之間存在100條lsp，r5，r7之間也存在100條lsp。他們兩兩建立hello關係通告的recovery_time分別為：(r4，r5)為t1+200*t2；(r5，r6)為t1+100*t2；(r5，r7)為t1+100*t2。

如果在r5和r7之間增加一條lsp，那麼r5和r7之間hello通告的recovery_time修改為：t1+101*t2。由於其他鄰居間lsp數目沒變，所以維持原來的recovery_time不變。

進一步地，參照圖10，所述重啟恢復時間的調整裝置還包括：

第二判斷模塊50，用於判斷所述重啟恢復時間是否發生變化；

在本實施例中，所述一節點在確認與其鄰居二節點之間的隧道數目發生變化時，採用預設的隨隧道數目單調的函數公式計算所述恢復時間並發送到其鄰居節點。

在本實施例中，所述一節點還可以在其獲取到與其鄰居節點之間的隧道數目之後進行所述重啟恢復時間的計算，根據計算出的所述重啟恢復時間判斷是否發生了變化，根據所述判斷結果確定是否在組建新報文時，將所述報文中的的所述重啟恢復時間更新。

所述發送模塊30還用於在所述重啟恢復時間發生變化時，將所述重啟恢復時間發送至與其所在的節點相鄰的其它節點，以供所述其它節點在其所在節點重啟時根據所述重啟恢復時間向其所在節點發送恢復報文。

本實施例提出的重啟恢復時間的調整裝置，獲取與其所在的節點相鄰的其它節點之間的隧道數目；根據所述隧道數目確定重啟恢復時間；將所述重啟恢復時間發送至所述與其所在的節點相鄰的其它節點，以供所述其它節點在其所在節點重啟時根據所述重啟恢復時間向其所在節點發送恢復報文。在每一次發送hello報文進行交互時，都將獲取到的所述恢復時間更新在報文中，並將所述hello報文發送至鄰居節點。在一節點發生重啟時，其鄰居節點可根據接收到的報文中的根據二者之間隧道數目動態調整的恢復時間向所述節點發送恢復消息，保證其充足的恢復時間，而不會由於recoverytime恢復時間不足，造成te隧道控制平面恢復失敗，導致業務中斷。

進一步地，基於本發明第一實施例提出本發明重啟恢復時間的調整裝置的第二實施例，參照圖11，所述重啟恢復時間的調整裝置還包括：

接收模塊60，，用於接收與其所在節點相鄰的所述其它節點發送的重啟恢復回復時間；

在本實施例中，所述一節點與其鄰居二節點之間建立了連接隧道，在第二節點進行優雅重啟時，第一節點即為所述第二節點的輔助方，向第二節點發送恢復報文，在進行hello報文交互時，兩節點互相發送並接收所述hello報文，故第一節點也可接收第二節點發送的hello報文。

存儲模塊70，用於根據所述重啟恢復時間更新存儲在本地的所述其它節點的重啟恢復時間。

在本實施例中，第一節點接收到第二節點發送的所述報文後，提取所述報文中的重啟恢復時間，並將所述重啟恢復時間保存在本地，在所述第二節點進行重啟時，所述第一節點作為第二節點的輔助方，根據所述重啟恢復時 間向所述第二節點發送恢復報文。

進一步地，參照圖12，所述所述重啟恢復時間的調整裝置還包括：

第三判斷模塊80，用於判斷接收到的所述重啟恢復時間與本地存儲的重啟恢復時間是否一致；

在本實施例中，第一節點在提取到所述重啟恢復時間之後，可將所述重啟恢復時間與保存在本地的重啟恢復時間進行對比，根據所述對比結果判斷是否需要對保存在本地的重啟恢復時間，即所述所述第二節點發生優雅重啟時，第一節點向所述第二節點發送恢復報文的時間，進行更新。

所述存儲模塊70還用於在所述接收到的重啟恢復時間與本地存儲的重啟恢復時間不一致時，根據所述重啟恢復時間更新存儲在本地的所述其它節點的重啟恢復時間。

在本實施例中，在第一節點判斷所述報文中的重啟恢復時間與所述保存在本地的重啟恢復時間不一致時，將所述報文中的所述重啟恢復時間作為新的重啟恢復時間保存在本地，作為所述第二節點發生優雅重啟時，第一節點向所述第二節點發送恢復報文的時間。

本實施例提出的重啟恢復時間的調整裝置，在節點接收到鄰居節點發送的報文後，根據從所述報文中提取出的所述恢復時間與本地保存的恢復時間進行對比，確定所述恢復時間是否發生變化，在所述恢復時間發生變化時，將所述變化的恢復時間更新保存在本地作為鄰居節點的優雅重啟恢復時間，在所述恢復時間沒有發生變化時，不更新所述保存在本地的恢復時間，更加節省資源。

需要說明的是，在本文中，術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，由語句「包括一個……」限定的要素，並不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到上述 實施例方法可藉助軟體加必需的通用硬體平臺的方式來實現，當然也可以通過硬體，但很多情況下前者是更佳的實施方式。基於這樣的理解，本發明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該計算機軟體產品存儲在一個存儲介質(如rom/ram、磁碟、光碟)中，包括若干指令用以使得一臺終端設備(可以是手機，計算機，伺服器，空調器，或者網絡設備等)執行本發明各個實施例所述的方法。

以上僅為本發明的優選實施例，並非因此限制本發明的專利範圍，凡是利用本發明說明書及附圖內容所作的等效結構或等效流程變換，或直接或間接運用在其他相關的技術領域，均同理包括在本發明的專利保護範圍內。