專利名稱：一種跟蹤泄漏資源的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種跟蹤泄漏資源的方法。
背景技術(shù)：
第三代移動通訊技術(shù)(3G技術(shù))相對于第二代移動通訊技術(shù)(2G技術(shù))有了很大的改進(jìn)，增加了更多的業(yè)務(wù)，提高了無線環(huán)境下通話的質(zhì)量，為用戶提供了更加豐富的個人通訊服務(wù)。而正因為如此，3G技術(shù)相比2G技術(shù)，呼叫的信令流程更為復(fù)雜，消息交互更多，資源管理也更為復(fù)雜，發(fā)生資源吊死的可能性也更大。
為此，需要提供一種方法可以有效的回收吊死的資源，同時針對吊死的資源具有跟蹤定位功能。目前的WCDMA(Wideband Code Division MultipleAccess，寬帶碼分多址接入)系統(tǒng)，涉及各種各樣資源的管理，對于泄漏的垃圾資源的回收一般采用的就是定時核查的方式。
所述的定時核查的方法如圖1所示，資源管理模塊A用于管理各個資源使用模塊使用的資源。對于需要進(jìn)行資源核查的情況，資源管理模塊A將定時向各個資源使用模塊B發(fā)送核查消息，以核查資源使用情況；所述的核查消息中承載著資源使用模塊B的資源使用情況，資源使用模塊B根據(jù)資源管理模塊A下發(fā)的資源使用情況，調(diào)整不一致的資源使用情況。
通過上述定時核查方式雖然可以發(fā)現(xiàn)資源吊死，并釋放資源，但是對于資源吊死無法提供一種有效的追蹤定位的功能。簡而言之，資源核查可以回收沒有釋放的資源，但是不能查出是誰沒有釋放資源。即無法定位資源吊死的位置，不便于消除或降低相應(yīng)位置上的資源泄漏的可能性。
總之，對于資源管理，一般來說定時核查方式可以達(dá)到回收垃圾資源的目的，可以基本回避資源吊死的情況。但是一旦系統(tǒng)遇到大話務(wù)量沖擊，定時核查來不及啟動，泄漏的垃圾資源就會迅速積累，還是會導(dǎo)致最終新建的呼叫申請不到資源而失敗的情況。因此，定時核查只是一個治標(biāo)不治本的方法。一旦發(fā)生資源吊死，最希望獲得的信息就是“到底是誰沒有釋放資源”。這就使得如何跟蹤資源泄漏的情況成為一個需要解決的問題。

發(fā)明內(nèi)容
鑒于上述現(xiàn)有技術(shù)所存在的問題，本發(fā)明的目的在于提供一種跟蹤泄漏資源的方法，通過把呼叫流程的ID與資源管理模塊的ID相結(jié)合作為資源使用模塊的ID，增強(qiáng)了資源管理模塊跟蹤泄漏資源的功能。
本發(fā)明的目的是通過以下技術(shù)方案實現(xiàn)的本發(fā)明提供了一種跟蹤泄漏資源的方法，包括資源申請模塊提供唯一的標(biāo)識ID向資源管理模塊申請資源，資源管理模塊在分配資源的同時記錄下該ID，在核查釋放資源時，根據(jù)該ID定位資源泄漏的資源使用者信息。
所述ID包括呼叫流程ID及該資源申請模塊的ID。
所述的資源申請模塊申請資源過程包括A、無線鏈路RL建立過程。
所述步驟A具體包括A1、用戶設(shè)備UE端發(fā)出呼叫，向無線網(wǎng)絡(luò)控制器RNC發(fā)出無線資源控制RRC連接請求；A2、RNC接收到上述請求后向一基站NODEB發(fā)出RL建立請求；A3、NODEB提供一唯一的ID給RNC，為該請求申請資源，該ID包括RRC呼叫流程ID及該NODEB的ID；A4、RNC的資源管理模塊記錄下此ID，并為上述RRC呼叫流程分配資源。
所述步驟A還包括A5、RNC為RRC指配完資源后把資源分配給UE使用，向UE端發(fā)送應(yīng)答，建立RRC連接；A6、UE端完成RRC連接后，以向RNC端發(fā)出RRC連接完成方式確認(rèn)完成。
所述的資源申請模塊申請資源過程包括B、RL重配置過程。
所述步驟B具體包括B1、核心網(wǎng)CN端向RNC發(fā)出無線接入承載RAB分配請求；B2、RNC接收上述請求后向NODEB發(fā)出RL重配置請求；B3、NODEB接收上述請求后，向RNC提供一唯一的ID用以申請資源，該ID包括RAB呼叫流程ID與NODEB的ID；B4、RNC的資源管理模塊記錄下此ID，RAB分配資源，在RNC處理完該過程后提交該RL重配置結(jié)果給NODEB。
所述步驟B還包括B5、RNC端指配完資源后，把資源分配給UE使用，通過發(fā)送無線承載RB建立方式通知給UE端；B6、UE端收到消息以后開始傳輸信道，邏輯信道，物理信道的配置過程，UE端完成配置后，向RNC端以發(fā)出RB建立完成方式確認(rèn)完成。
所述步驟B還包括B7、上述資源指配完成后，向CN端發(fā)出應(yīng)答，回應(yīng)RAB分配請求。
所述無線信令的傳輸過程是直傳過程。
由上述本發(fā)明提供的技術(shù)方案可以看出，本發(fā)明通過把呼叫流程的ID與資源管理模塊的ID相結(jié)合作為資源使用模塊的ID，無論哪類資源泄漏，資源管理模塊都可以區(qū)分出來，增強(qiáng)了資源管理模塊跟蹤泄漏資源的功能。


圖1為背景技術(shù)采用的資源管理方式示意圖。
圖2為本發(fā)明跟蹤泄漏資源方法示意圖。
圖3為本發(fā)明跟蹤泄漏資源方法操作流程圖。
具體實施例方式
本發(fā)明提供一種跟蹤泄漏資源的方法，采用資源申請模塊在資源申請的時候，向資源管理模塊提供唯一的標(biāo)識。資源管理模塊在分配資源的同時記錄下資源使用者的ID，這樣，一旦發(fā)生資源吊死，資源管理模塊在核查釋放資源的同時，就可以查出資源的使用者。如圖2所示，每一資源使用模塊具有唯一的ID，資源管理模塊在核查釋放資源時可根據(jù)資源使用模塊的ID查出導(dǎo)致資源泄漏的模塊。
下面參照圖3對本發(fā)明具體實施方式
予以說明本發(fā)明僅就傳輸層實例資源的申請過程予以說明，各種實例資源的管理方法參照該實施方式，其中傳輸層實例資源是一種AAL(ATM適配層)實例資源。
一種RL(無線鏈路)建立過程申請傳輸層實例資源過程包括如下步驟步驟33UE(用戶設(shè)備)端發(fā)出呼叫，向RNC(無線網(wǎng)絡(luò)控制器)發(fā)出RRC(無線資源控制)連接請求；步驟34RNC接收到上述請求后向NODEB(一基站)發(fā)出RL建立請求；步驟35NODEB接收到上述RL建立請求后，為該請求申請信令的傳輸層實例資源，即向RNC發(fā)出應(yīng)答，提供一唯一的ID給RNC，該ID包括RRC呼叫流程ID及該NODEB的ID，兩者結(jié)合在一起構(gòu)成唯一的確定該RRC流程資源使用的標(biāo)志，此申請信令的傳輸層實例資源過程即圖中申請傳輸層實例資源過程I；步驟36RNC的資源管理模塊(圖中未示出)記錄下此ID，并在為上述RRC呼叫流程申請到傳輸層實例資源后，把資源分配給UE使用，向UE端發(fā)送應(yīng)答，建立RRC連接；步驟37UE端完成RRC連接后，以向RNC端發(fā)出RRC連接完成方式確認(rèn)完成，該呼叫流程RL建立過程的申請傳輸層實例資源過程完成。
一種RL重配置過程申請傳輸層實例資源過程包括如下步驟步驟38CN(核心網(wǎng))端向RNC發(fā)出RAB(無線接入承載)指配請求；步驟39RNC接收上述請求后向NODEB發(fā)出RL重配置請求；步驟40NODEB接收上述請求后，為RL重配置做準(zhǔn)備，主要是向RNC提供一唯一的ID用以申請信令的傳輸層實例資源，即圖中申請傳輸層實例資源過程II，該唯一的ID包括RAB呼叫流程ID與NODEB的ID；步驟41RNC的資源管理模塊記錄下此ID，在RNC處理完該過程后提交該RL重配置結(jié)果給NODEB；步驟42RNC端申請完傳輸層實例資源后，把資源分配給UE使用，通過發(fā)送RB(無線承載)建立方式通知給UE端；步驟43UE端收到消息以后開始傳輸信道，邏輯信道，物理信道的配置過程，UE端完成配置后，向RNC端以發(fā)出RB建立完成方式確認(rèn)完成。
步驟44上述資源指配完成后，向CN端發(fā)出應(yīng)答，回應(yīng)RAB分配請求。
在圖3中整個RL建立過程及RL重配置過程中傳輸層實例資源的申請都是由NODEB申請的，由于兩者所處流程不同，即流程的ID不同，因此，兩個傳輸層實例資源申請過程雖然由同一模塊發(fā)出，但二者的ID不同，因此，無論哪類資源泄漏了，都可以區(qū)分出來。UE與CN的無線呼叫信令的交互，對于接入網(wǎng)RNC和NODEB來說是透明的，RNC和NODEB不需要知道該無線呼叫信令過程，在RNC只是直接透傳，所以無線呼叫信令過程是一個直傳過程。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)該以權(quán)利要求的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1.一種跟蹤泄漏資源的方法，其特征在于，包括資源申請模塊申請資源時向資源管理模塊提供唯一的標(biāo)識ID，資源管理模塊在分配資源的同時記錄下該ID，在核查釋放資源時，根據(jù)該ID定位資源泄漏的資源使用者信息。
2.如權(quán)利要求1所述的一種跟蹤泄漏資源的方法，其特征在于，所述ID包括呼叫流程ID及該資源申請模塊的ID。
3.如權(quán)利要求2所述的一種跟蹤泄漏資源的方法，其特征在于，該資源申請模塊申請資源過程包括A、無線鏈路RL建立過程。
4.如權(quán)利要求3所述的一種跟蹤泄漏資源的方法，其特征在于，所述步驟A具體包括A1、用戶設(shè)備UE端發(fā)出呼叫，向無線網(wǎng)絡(luò)控制器RNC發(fā)出無線資源控制RRC連接請求；A2、RNC接收到上述請求后向基站NODEB發(fā)出RL建立請求；A3、NODEB提供一唯一的ID給RNC，為該請求申請資源，該ID包括RRC呼叫流程ID及該NODEB的ID；A4、RNC的資源管理模塊記錄下此ID，并為上述RRC呼叫流程分配資源。
5.如權(quán)利要求4所述的一種跟蹤泄漏資源的方法，其特征在于，所述步驟A還包括A5、RNC為RRC指配完資源后把資源分配給UE使用，向UE端發(fā)送應(yīng)答，建立RRC連接；A6、UE端完成RRC連接后，以向RNC端發(fā)出RRC連接完成方式確認(rèn)完成。
6.如權(quán)利要求2所述的一種跟蹤泄漏資源的方法，其特征在于，該資源申請模塊申請資源過程包括B、RL重配置過程。
7.如權(quán)利要求6所述的一種跟蹤泄漏資源的方法，其特征在于，所述步驟B具體包括B1、核心網(wǎng)CN端向RNC發(fā)出無線接入承載RAB分配請求；B2、RNC接收上述請求后向NODEB發(fā)出RL重配置請求；B3、NODEB接收上述請求后，向RNC提供一唯一的ID用以申請資源，該ID包括RAB呼叫流程ID與NODEB的ID；B4、RNC的資源管理模塊記錄下此ID，RAB分配資源，在RNC處理完該過程后提交該RL重配置結(jié)果給NODEB。
8.如權(quán)利要求7所述的一種跟蹤泄漏資源的方法，其特征在于，所述步驟B還包括B5、RNC端指配完資源后，把資源分配給UE使用，通過發(fā)送無線承載RB建立方式通知給UE端；B6、UE端收到消息以后開始傳輸信道，邏輯信道，物理信道的配置過程，UE端完成配置后，向RNC端以發(fā)出RB建立完成方式確認(rèn)完成。
9.如權(quán)利要求8所述的一種跟蹤泄漏資源的方法，其特征在于，所述步驟B還包括B7、上述資源指配完成后，向CN端發(fā)出應(yīng)答，回應(yīng)RAB分配請求。
10.如權(quán)利要求3或6所述的一種跟蹤泄漏資源的方法，其特征在于，所述無線信令的傳輸過程是直傳過程。
全文摘要
本發(fā)明涉及通信技術(shù)領(lǐng)域中一種跟蹤泄漏資源的方法。資源申請模塊提供一ID向資源管理模塊申請資源，該ID包括呼叫流程的ID及資源管理模塊的ID，資源管理模塊在分配資源的同時記錄下該ID，在核查釋放資源時，根據(jù)該ID定位資源泄漏的資源使用者信息，該跟蹤泄漏資源的方法，無論哪類資源泄漏，資源管理模塊都可以區(qū)分出來，增強(qiáng)了資源管理模塊跟蹤泄漏資源的功能。
文檔編號H04W72/04GK1889740SQ200510080080
公開日2007年1月3日 申請日期2005年6月29日 優(yōu)先權(quán)日2005年6月29日
發(fā)明者金穎 申請人:華為技術(shù)有限公司