[發明專利]一種無線網絡控制器與B節點的通信上下文防吊死方法

有效

• 申請號: 200710003068.5
• 申請日: 2007-01-31
• 公開（公告）號: CN101237361A
• 公開（公告）日: 2008-08-06
• 發明（設計）人: 李志海
• 申請（專利權）人: 中興通訊股份有限公司
• 主分類號: H04L12/28
• 分類號: H04L12/28;H04L12/24;H04L12/26;H04Q7/36;H04Q7/30;H04Q7/38
• 代理公司: 北京安信方達知識產權代理有限公司
• 代理人: 龍洪;霍育棟

技術領域

本發明涉及第三代移動通信系統的無線接入網技術，尤其涉及到第三代移動通信無線網絡控制器(RNC)與B節點(Node?B)之間資源一致性檢查的方法。

背景技術

第三代移動通信系統的無線接入網部分為了管理方便，在RNC(無線網絡控制器)為一個通話用戶分配一個RNC通信上下文，在Node?B(B節點)為一個通話用戶分配一個Node?B通信上下文，分別用于管理該通話用戶在RNC、Node?B的無線資源。

一旦通話中止，RNC通信上下文、Node?B通信上下文都需要同步刪除，也就是說RNC通信上下文、Node?B通信上下文需要同時創建、同時刪除，兩者之間的一致性顯得非常重要。

一旦RNC通信上下文刪除，RNC會向Node?B發送復位請求(ResetRequest)或者無線鏈路刪除請求(Radio?Link?Deletion?Request)，同步刪除對應的Node?B通信上下文。同理，Node?B通信上下文提前刪除后，也會向RNC發送復位請求，同步刪除對應的RNC通信上下文。

如果在上述同步刪除過程中，刪除消息發送異常導致目標方無法正確接收，或者接收方處理未能成功刪除掉指定的通信上下文，都會導致Node?B通信上下文與RNC通信上下文不一致，此時，即為通信上下文吊死。無論對于Node?B還是RNC，過多通信上下文吊死都將導致可用無線資源減少。

出現通信上下文吊死以后，最常見的處理方法是將有通信上下文吊死的一方(可以是RNC，也可以是NodeB)進行復位操作，待復位一方重啟成功后，主動向另一方發起復位請求(Reset?Request)，重新達到兩邊通信上下文資源一致。但是，這種處理方法不僅會造成現有通話掉話，而且在啟動過程中，新用戶無法接入。

發明內容

本發明所要解決的技術問題在于，提供一種無線網絡控制器與B節點的通信上下文防吊死的方法，實現兩者的通信上下文及時同步一致，解決RNC、Node?B的通信上下文不一致導致的吊死問題。

本發明提供一種無線網絡控制器與B節點的通信上下文防吊死的方法，包括如下步驟：

(1)在所述無線網絡控制器與B節點之間的Iub口新增通信上下文檢測請求與通信上下文檢測響應信令；

(2)所述無線網絡控制器和B節點分別建立通信上下文后，B節點通信上下文向RNC周期性發送通信上下文檢測請求，所述RNC通信上下文給B節點周期性回應通信上下文檢測響應，進行通信上下文的周期性檢測；

(3)所述B節點通信上下文和/或所述RNC通信上下文根據各自通信上下文的周期性檢測結果，判定自身通信上下文已吊死時，刪除該通信上下文及其使用的資源。

進一步地，步驟(1)中：

所述通信上下文檢測請求是Iub口的B節點應用部分NBAP信令，由B節點發往所述無線網絡控制器，其中攜帶B節點通信上下文標識及保存的無線網絡控制器通信上下文標識；

所述通信上下文檢測響應是Iub口的B節點應用部分NBAP信令，由所述無線網絡控制器發往B節點，其中攜帶無線網絡控制器通信上下文標識及B節點通信上下文標識。

進一步地，步驟(2)進一步可分為：

(2-1)所述無線網絡控制器創建一個無線網絡控制器通信上下文，該無線網絡控制器通信上下文接收B節點發來的無線鏈路建立響應后，啟動一個等待定時器T1；

(2-2)B節點收到無線鏈路建立請求后，創建一個B節點通信上下文，該B節點通信上下文向無線網絡控制器回應無線鏈路建立響應后，啟動周期發送定時器T2；

(2-3)收到周期發送定時器T2超時消息后，B節點通信上下文向無線網絡控制器發送通信上下文檢測請求，并啟動一個等待定時器T3；

(2-4)無線網絡控制器收到通信上下文檢測請求后，判斷該請求消息中的內容在無線網絡控制器都存在，則由請求消息包含的無線網絡控制器通信上下文向B節點回應通信上下文檢測響應，并刪除等待定時器T1，重新啟動等待定時器T1；

(2-5)所述B節點通信上下文收到通信上下文檢測響應后，刪除等待定時器T3，重新啟動周期發送定時器T2。

進一步地，步驟(2-2)進一步包括啟動一個初始化為0的超時計數器，記錄步驟(2-3)的等待定時器T3的超時次數，每超時一次該超時計數器的計數值加1。

進一步地，步驟(2-2)進一步包括確定一個最大允許發送失敗次數。

進一步地，步驟(3)進一步可分為：