專利名稱：一種分布式管理的無線網(wǎng)絡子系統(tǒng)中的呼叫處理方法
技術領域：
本發(fā)明涉及寬帶碼分多址(WCDMA)移動通信技術的呼叫處理方法，特別涉及到一種分布式管理的無線網(wǎng)絡子系統(tǒng)(RNS)中的呼叫處理方法。
背景技術：
WCDMA系統(tǒng)是由核心網(wǎng)(CN)，全球移動通信系統(tǒng)的陸地無線接入網(wǎng)絡(UTRAN)和用戶設備(UE)組成的，圖1顯示了WCDMA系統(tǒng)的網(wǎng)絡結構。其中，UTRAN的主要功能是實現(xiàn)系統(tǒng)的接入控制，移動性管理以及無線資源的管理和控制等功能。如圖1所示，UTRAN包括一個或者多個通過Iu接口連接到CN的RNS，一個RNS可以包括一個無線網(wǎng)絡控制器(RNC)以及一個或者多個基站Node B。
在RNS的設計中，可以應用分布式管理的方法，即在一個RNS中可以應用多個分布式信令處理子系統(tǒng)來管理并實現(xiàn)RNC的基本功能，其中每個分布式信令處理子系統(tǒng)負責RNS中一部分小區(qū)用戶的接入控制、移動性管理以及無線資源的管理和控制等等。每個分布式信令處理子系統(tǒng)管理的小區(qū)可以由用戶根據(jù)實際情況進行配置，但是從系統(tǒng)負荷分擔和處理能力等方面考慮，每個分布式信令處理子系統(tǒng)管理的小區(qū)數(shù)目和容量都會有一定的限制。如圖1所示，RNC A和RNC B分別有兩個分布式信令處理子系統(tǒng)1和2，分別負責管理該RNS中一部分的小區(qū)。
需要說明的是，UTRAN可以包含一個或者多個RNS，一個RNC中可以包含一個或者多個分布式信令處理子系統(tǒng)，一個分布式信令處理子系統(tǒng)可以管理一個或者多個Node B，而不限于圖1所示的數(shù)量關系。
在WCDMA系統(tǒng)中，為了對用戶設備(UE)的狀態(tài)和資源消耗進行方便的管理，RNC會為每個新的接入呼叫分配一個用戶實例，該用戶實例負責管理該呼叫的所有信令交互、資源分配等操作。并且用戶實例只有在UE與RNC之間的連接被釋放的時候才被釋放。需要說明的是，UE總是通過其所在的小區(qū)接入到UTRAN的，且RNC所管理的每一個小區(qū)都對應RNC中的一個分布式信令處理子系統(tǒng)，而每個分布式信令處理子系統(tǒng)可以管理一個或者多個小區(qū)。如圖1所示，如果UE從分布式信令處理子系統(tǒng)1管理的小區(qū)接入UTRAN，則分布式信令處理子系統(tǒng)1需要為UE的呼叫分配一個用戶實例。出于系統(tǒng)容量上的考慮，每個分布式信令處理子系統(tǒng)可以分配的用戶實例的數(shù)目是有一定限制的。
目前，WCDMA系統(tǒng)中新的接入呼叫主要可以由以下幾個方面啟動UE發(fā)起無線資源控制連接(RRC)建立請求；硬切換伴隨遷移，作為目標RNC接收到遷移請求消息；UE發(fā)生2G到3G切換，切換進入UTRAN系統(tǒng)；跨RNC軟切換過程中，作為目標的RNC接收到無線鏈路建立的請求消息；小區(qū)更新伴隨遷移時，作為目標的RNC接收到小區(qū)更新消息。
上文所述的用戶實例是在UE第一次接入系統(tǒng)的時候，由UE所在小區(qū)對應的分布式信令處理子系統(tǒng)分配的。用戶實例的分配步驟如下a.當UE選擇從如圖1所示的小區(qū)A(CELL A)接入UTRAN系統(tǒng)時，UE的第一條接入呼叫請求信令就會到達管理該小區(qū)的分布式信令處理子系統(tǒng)1；b.分布式信令處理子系統(tǒng)1檢查它是否有可用的用戶實例，如果有，就為該呼叫分配一個新的用戶實例以及呼叫資源；如果沒有，則進行異常處理，拒絕該呼叫。
然而，現(xiàn)有的用戶實例分配策略在實際的應用中是有一定的局限性的，即用戶實例并不隨著UE的切換而遷移。結合圖1舉例說明，當該UE從圖1所示的分布式信令處理子系統(tǒng)1管理的CELL A切換到位于相同RNS的分布式信令處理子系統(tǒng)2管理的小區(qū)CELL B上時，該呼叫的用戶實例并不會從分布式信令處理子系統(tǒng)1遷移到分布式信令處理子系統(tǒng)2上。也就是說，此時UE雖然處在分布式信令處理子系統(tǒng)2所管理的小區(qū)CELL B內(nèi)，但是該UE的呼叫仍然占用分布式信令處理子系統(tǒng)1的用戶實例資源。
由此可以看出，由于每個分布式信令處理子系統(tǒng)可以分配的用戶實例數(shù)目是有限的，所以應用這種用戶實例的分配策略就有可能會出現(xiàn)如下問題雖然某些分布式信令處理子系統(tǒng)所管理的小區(qū)的無線鏈路資源還有空閑，但其用戶實例卻已經(jīng)被消耗完了。在這種情況下，如果有處于該分布式信令處理子系統(tǒng)所管理的小區(qū)的UE需要接入新的呼叫，就會因為該分布式信令處理子系統(tǒng)已經(jīng)沒有可用的用戶實例而導致呼損。

發(fā)明內(nèi)容
有鑒與此，本發(fā)明的目的就是提供一種分布式管理的RNS中進行呼叫處理的方法，以此來解決在分布式管理的RNS中可能出現(xiàn)的雖然某個分布式信令處理子系統(tǒng)的小區(qū)無線鏈路資源很空閑，但是由于該分布式信令處理子系統(tǒng)已無可用的用戶實例而造成呼損的問題。
為了達到上述目的，本發(fā)明公開了一種分布式管理的RNS中的呼叫處理方法，該方法主要包含以下步驟a.UE發(fā)起接入呼叫請求；b.管理UE所在小區(qū)的分布式信令處理子系統(tǒng)判斷是否可以處理該呼叫，如果可以，則直接處理該呼叫，然后結束本流程；否則，選擇可以處理該呼叫的分布式信令處理子系統(tǒng)；c.由所選擇的分布式信令處理子系統(tǒng)處理該呼叫。
其中，步驟b所述的判斷是否可以處理該呼叫的方法為判斷該分布式信令處理子系統(tǒng)是否有可用的用戶實例，如果有，則可以處理該呼叫；否則，不能處理該呼叫。
在UTRAN系統(tǒng)配置時，RNC為每個分布式信令處理子系統(tǒng)綁定一個備選子系統(tǒng)，步驟b所述的選擇可以處理該呼叫的分布式信令處理子系統(tǒng)為選擇該分布式信令處理子系統(tǒng)的備選子系統(tǒng)。
另外，步驟b所述的選擇分布式信令處理子系統(tǒng)的方法還可以為RNC根據(jù)其RNS中各個分布式信令處理子系統(tǒng)的用戶實例占用情況，為該呼叫選擇最空閑的分布式信令處理子系統(tǒng)。
上述的選擇分布式信令處理子系統(tǒng)的方法包括以下步驟RNC檢測所有分布式信令處理子系統(tǒng)的用戶實例占用情況，如果有一個或者多個分布式信令處理子系統(tǒng)具有可用的用戶實例，則選擇當前最空閑的分布式信令處理子系統(tǒng)；如果所有的分布式信令處理子系統(tǒng)都無可用的用戶實例，則進行異常處理，拒絕該呼叫。
此外，步驟b所述的選擇分布式信令處理子系統(tǒng)的方法又可以為RNC隨機逐一檢測RNS中所有的分布式信令處理子系統(tǒng)，選擇檢測到的第一個具有可用的用戶實例的分布式信令處理子系統(tǒng)。
上述的選擇分布式信令處理子系統(tǒng)的方法包括以下步驟RNC逐一檢測RNS中所有的分布式信令處理子系統(tǒng)的用戶實例占用情況，如果有可用的用戶實例，則選擇該分布式信令處理子系統(tǒng)；如果無用戶實例可用，則繼續(xù)檢測下一個分布式信令處理子系統(tǒng)；如果檢測完畢所有的分布式信令處理子系統(tǒng)，都沒有可用的用戶實例，則進行異常處理，拒絕該呼叫。
步驟c在所述的處理該呼叫之前，進一步包括將該呼叫轉(zhuǎn)移到所選擇的分布式信令處理子系統(tǒng)上。
由此可見，當UE進行呼叫接入請求時，應用本發(fā)明所述的方法可以在管理UE所在小區(qū)的分布式信令處理子系統(tǒng)已無用戶實例可用的情況下，選擇其他的分布式信令處理子系統(tǒng)處理該呼叫，以解決由于管理UE接入的小區(qū)的分布式信令處理子系統(tǒng)由于無用戶實例可用而造成的呼損，降低了分布式管理的RNS的呼損率，提高了系統(tǒng)資源的利用率。


圖1顯示了UTRAN的網(wǎng)絡結構；圖2顯示了本發(fā)明所述的在分布式管理的RNS中進行呼叫處理的具體流程；圖3顯示了本發(fā)明所述的一個優(yōu)選實施例的呼叫處理流程；圖4顯示了本發(fā)明所述的另一個優(yōu)選實施例的呼叫處理流程；圖5顯示了本發(fā)明所述的又一個優(yōu)選實施例的呼叫處理流程。
具體實施例方式
下面就結合附圖和具體的實施例對本發(fā)明進行進一步的詳細說明。
本發(fā)明公開了一種在分布式管理的無線網(wǎng)絡子系統(tǒng)中的呼叫處理方法，該方法主要包含以下步驟a.UE發(fā)起接入呼叫請求；b.管理UE所在小區(qū)的分布式信令處理子系統(tǒng)判斷是否可以處理該呼叫，如果可以，則直接處理該呼叫，然后結束本流程；否則，選擇可以處理該呼叫的分布式信令處理子系統(tǒng)；c.由所選擇的分布式信令處理子系統(tǒng)處理該呼叫。
上述方法的具體步驟如圖2所示，圖2為本發(fā)明所述的分布式管理的RNS中進行呼叫處理的具體流程，包括以下步驟步驟201UE在某個分布式信令處理子系統(tǒng)所管理的小區(qū)接入UTRAN；步驟202該分布式信令處理子系統(tǒng)判決是否可以處理該呼叫如果可以，則執(zhí)行步驟203；否則，執(zhí)行步驟204；其中，上述分布式信令處理子系統(tǒng)判決是否可以處理該呼叫的步驟又稱為話務分擔判決；步驟203該分布式信令處理子系統(tǒng)直接處理該呼叫，即為該呼叫分配用戶實例、呼叫資源等，然后結束本流程；
步驟204選擇可以處理該呼叫的分布式信令處理子系統(tǒng)，然后執(zhí)行步驟205；步驟205將該呼叫轉(zhuǎn)移到所選擇的分布式信令處理子系統(tǒng)，并由所選擇的分布式信令處理子系統(tǒng)處理該呼叫，即為該呼叫分配用戶實例、呼叫資源等，然后結束本流程。
其中，步驟205又稱為話務分擔。
圖3所示的為本發(fā)明的一個優(yōu)選的實施例，在該實施例中，上述步驟204所述的選擇可以處理該呼叫的分布式信令處理子系統(tǒng)是通過為每個分布式信令處理子系統(tǒng)綁定一個備選子系統(tǒng)的方法來實現(xiàn)的。
在這一實施例中，在對UTRAN系統(tǒng)進行配置的時候就為其所有的分布式信令處理子系統(tǒng)確定兩兩互為備選子系統(tǒng)的關系，并在每個分布式信令處理子系統(tǒng)中記錄其備選子系統(tǒng)的標識。一旦需要進行話務分擔，則直接將呼叫轉(zhuǎn)移到相對應的備選分布式信令處理子系統(tǒng)上，其具體步驟如下步驟301UTRAN系統(tǒng)配置所有的分布式信令處理子系統(tǒng)為兩兩互為備選子系統(tǒng)的關系；步驟302UE在其中一個分布式信令處理子系統(tǒng)所管理的小區(qū)接入UTRAN；步驟303該分布式信令處理子系統(tǒng)進行話務分擔的判決如果有可用的用戶實例，則執(zhí)行步驟304；否則，執(zhí)行步驟305；步驟304由該分布式信令處理子系統(tǒng)處理該呼叫，為該呼叫分配用戶實例、分配呼叫資源等；步驟305將呼叫處理轉(zhuǎn)移到其備選分布式信令處理子系統(tǒng)，下面執(zhí)行步驟306；步驟306該備選子系統(tǒng)判斷是否可以處理該呼叫，如果該備選分布式信令處理子系統(tǒng)有可用的用戶實例，則執(zhí)行步驟307；否則，執(zhí)行步驟308；步驟307由該備選信令處理子系統(tǒng)處理該呼叫，為呼叫分配用戶實例，分配呼叫資源；步驟308進行異常處理，拒絕該呼叫。
下面舉例對這一實施例進行詳細說明假設UTRAN系統(tǒng)設置了6個分布式信令處理子系統(tǒng)1、2、3、4、5和6，則在UTRAN進行系統(tǒng)配置的時候就可以將分布式信令處理子系統(tǒng)1和2，3和4，5和6兩兩分別確定為互為備選的分布式信令處理子系統(tǒng)。如圖1所示，RNC可以將分布式信令處理子系統(tǒng)1和2設置為互為備選子系統(tǒng)。其中，各個分布式信令處理子系統(tǒng)都負責其管理的小區(qū)上報的信令的轉(zhuǎn)發(fā)以及其負責用戶的信令交互。此時，UE由分布式信令處理子系統(tǒng)1管理的小區(qū)接入UTRAN，如果分布式信令處理子系統(tǒng)1發(fā)現(xiàn)已無可用的用戶實例滿足新的呼叫，就直接將該呼叫轉(zhuǎn)移給其備選分布式信令處理子系統(tǒng)2，如果此時分布式信令處理子系統(tǒng)2也無可用的用戶實例，則拒絕該呼叫接入。同樣，如果分布式信令處理子系統(tǒng)2需要話務分擔，也將直接將呼叫處理轉(zhuǎn)移給其備選分布式信令處理子系統(tǒng)1來實現(xiàn)。以上所述的方法同樣適用于分布式信令處理子系統(tǒng)3和4以及5和6之間的話務分擔。需要說明的是，互為備選的分布式信令處理子系統(tǒng)的選擇可以是分布式信令處理子系統(tǒng)1～6之間的任意組合，而不超出本發(fā)明的精神和范圍。
應用該方法的優(yōu)點就是簡單、易行，其不足之處就是如果UTRAN系統(tǒng)所配置的互為備選的兩個分布式信令處理子系統(tǒng)的負荷都很重，也很難避免由于沒有可用的用戶實例而造成呼損的問題。
圖4顯示了本發(fā)明的另一個優(yōu)選的實施例，在該實施例中，上述步驟204所述的選擇可以處理該呼叫的分布式信令處理子系統(tǒng)是通過RNC為呼叫選擇最空閑的分布式信令處理子系統(tǒng)進行處理的方法來實現(xiàn)的。
其中，所述最空閑的分布式信令處理子系統(tǒng)是指具有最多可用用戶實例的分布式信令處理子系統(tǒng)。
在該實施例中，UTRAN系統(tǒng)并不為每個分布式信令處理子系統(tǒng)確定固定的備選關系，而是根據(jù)當前各個分布式信令處理子系統(tǒng)的用戶實例占用情況，動態(tài)的選擇最為空閑的分布式信令處理子系統(tǒng)。如果經(jīng)過選擇，所有的分布式信令處理子系統(tǒng)都無可用的用戶實例，則拒絕該呼叫，導致呼損，如圖4所示，具體包含以下步驟步驟401UE在一個分布式信令處理子系統(tǒng)所管理的小區(qū)接入UTRAN；步驟402該分布式信令處理子系統(tǒng)進行話務分擔的判決，如果有可用的用戶實例，則執(zhí)行步驟403；否則，執(zhí)行步驟404；步驟403由該信令處理子系統(tǒng)處理該呼叫，為該呼叫分配用戶實例、分配呼叫資源等；步驟404RNC檢測所有分布式信令處理子系統(tǒng)的用戶實例占用情況，如果有分布式信令處理子系統(tǒng)有可用的用戶實例，則執(zhí)行步驟405；否則，執(zhí)行步驟406；步驟405RNC選出當前最空閑的分布式信令處理子系統(tǒng)，將該呼叫處理轉(zhuǎn)移到最空閑分布式信令處理子系統(tǒng)進行處理，最空閑的分布式信令處理子系統(tǒng)為該呼叫分配用戶實例，分配呼叫資源。
步驟406進行異常處理，拒絕該呼叫。
下面舉例對這一實施例進行詳細說明例如，假設UTRAN系統(tǒng)設置了6個分布式信令處理子系統(tǒng)1、2、3、4、5和6，各個分布式信令處理子系統(tǒng)都負責其管理的小區(qū)上報的信令的轉(zhuǎn)發(fā)以及其負責用戶的信令交互。此時，如果分布式信令處理子系統(tǒng)1發(fā)現(xiàn)其已無可用的用戶實例，RNC則通過動態(tài)選擇機制找到此時具有最多可用用戶實例的分布式信令處理子系統(tǒng)，比如分布式信令處理子系統(tǒng)4，并將該呼叫轉(zhuǎn)移給分布式信令處理子系統(tǒng)4來處理。如果6個分布式信令處理子系統(tǒng)都無可用的用戶實例，則將導致呼損。
應用這種方法的優(yōu)點就是最大程度的利用了RNS中所有分布式信令處理子系統(tǒng)的用戶實例。但是其不足之處就是，RNC需要維護一套動態(tài)選擇最為空閑的分布式信令處理子系統(tǒng)的選擇機制，因而增加了額外的系統(tǒng)開銷。
圖5顯示了本發(fā)明所述的又一個優(yōu)選的實施例，在這一實施例中，上述步驟204所述的選擇可以處理該呼叫的分布式信令子處理系統(tǒng)的方法為RNC隨機搜索系統(tǒng)所有的分布式信令處理子系統(tǒng)，直到找到一個可以處理該呼叫的分布式信令處理子系統(tǒng)。
在該實施例中，UTRAN系統(tǒng)是根據(jù)當前各個分布式信令處理子系統(tǒng)的用戶實例占用情況，動態(tài)隨機的選擇空閑的分布式信令處理子系統(tǒng)。如果搜索了所有的分布式信令處理子系統(tǒng)都沒有可用的用戶實例，則拒絕該呼叫，而導致呼損，如圖5所示，其具體步驟如下步驟501UE在一個分布式信令處理子系統(tǒng)所管理的小區(qū)接入UTRAN；步驟502該分布式信令處理子系統(tǒng)進行話務分擔的判決如果有可用的用戶實例，則執(zhí)行步驟503；否則，執(zhí)行步驟504；步驟503由該分布式信令處理子系統(tǒng)處理該呼叫，為該呼叫分配用戶實例、分配呼叫資源等；步驟504RNC隨機搜索另一個分布式信令處理子系統(tǒng)的用戶實例占用情況如果有可用的用戶實例，則執(zhí)行步驟505；如果無用戶實例可用，則循環(huán)該步驟；如果搜索完畢所有的分布式信令處理子系統(tǒng)，都沒有可用的用戶實例，則執(zhí)行步驟506；步驟505將該呼叫處理轉(zhuǎn)移到搜索到的有空閑用戶實例的分布式信令處理子系統(tǒng)進行處理，即為該呼叫分配用戶實例，分配呼叫資源；步驟506進行異常處理，拒絕該呼叫。
下面舉例對本實施例進一步詳細說明，例如，假設UTRAN系統(tǒng)設置了6個分布式信令處理子系統(tǒng)1、2、3、4、5和6，各個分布式信令處理子系統(tǒng)都負責其管理的小區(qū)上報的信令的轉(zhuǎn)發(fā)以及其負責用戶的信令交互。此時，如果分布式信令處理子系統(tǒng)1沒有可用的用戶實例，則進行話務分擔，將呼叫處理轉(zhuǎn)移給分布式信令處理子系統(tǒng)2，如果恰好分布式信令處理子系統(tǒng)2也無可用的用戶實例，則將呼叫處理再一次轉(zhuǎn)移給分布式信令處理子系統(tǒng)3，以此類推......。直到搜索到可用的用戶實例為止。如果所有的分布式信令處理子系統(tǒng)都沒有可用的用戶實例則拒絕該呼叫。需要說明的是，分布式信令處理子系統(tǒng)在進行話務分擔的時候搜索具有空閑用戶實例的分布式信令處理子系統(tǒng)的順序并不限于如上所述的順序，還可以是任意其它系統(tǒng)設定的搜索順序，而不會超出本發(fā)明的精神和范圍。
應用這種方法的優(yōu)點也是最大限度的利用了所有分布式信令處理子系統(tǒng)的用戶實例。其不足之處就是，這種方法可能需要在不同的分布式信令處理子系統(tǒng)上將該呼叫處理進行多次轉(zhuǎn)移才能得到處理，造成系統(tǒng)對呼叫的處理時延較大。
由此可見，應用本發(fā)明所述的方法，可以在很大程度上解決在分布式管理的RNS中可能出現(xiàn)的雖然某個分布式信令處理子系統(tǒng)的小區(qū)無線鏈路資源很空閑，但是由于該分布式信令處理子系統(tǒng)已無可用的用戶實例而造成的呼損的問題。因此，應用本方法可以降低系統(tǒng)的呼損率，提高系統(tǒng)資源的利用率。
以上所述僅為本發(fā)明的較佳實施例而已，并非用來限定本發(fā)明的保護范圍。
權利要求
1.一種分布式管理的無線網(wǎng)絡子系統(tǒng)中的呼叫處理方法，其特征在于，該方法主要包含以下步驟a.UE發(fā)起接入呼叫請求；b.管理UE所在小區(qū)的分布式信令處理子系統(tǒng)判斷是否可以處理該呼叫，如果可以，則直接處理該呼叫，然后結束本流程；否則，選擇可以處理該呼叫的分布式信令處理子系統(tǒng)；c.由所選擇的分布式信令處理子系統(tǒng)處理該呼叫。
2.如權利要求1所述的方法，其特征在于，步驟b所述的判斷是否可以處理該呼叫的方法為判斷該分布式信令處理子系統(tǒng)是否有可用的用戶實例，如果有，則可以處理該呼叫；否則，不能處理該呼叫。
3.如權利要求1所述的方法，其特征在于，在UTRAN系統(tǒng)配置時，RNC為每個分布式信令處理子系統(tǒng)綁定一個備選子系統(tǒng)，步驟b所述的選擇可以處理該呼叫的分布式信令處理子系統(tǒng)為選擇該分布式信令處理子系統(tǒng)的備選子系統(tǒng)。
4.如權利要求1所述的方法，其特征在于，步驟b所述的選擇分布式信令處理子系統(tǒng)的方法為RNC根據(jù)其RNS中各個分布式信令處理子系統(tǒng)的用戶實例占用情況，為該呼叫選擇最空閑的分布式信令處理子系統(tǒng)。
5.如權利要求4所述的方法，其特征在于，所述的選擇分布式信令處理子系統(tǒng)的方法包括以下步驟RNC檢測所有分布式信令處理子系統(tǒng)的用戶實例占用情況，如果有一個或者多個分布式信令處理子系統(tǒng)具有可用的用戶實例，則選擇當前最空閑的分布式信令處理子系統(tǒng)；如果所有的分布式信令處理子系統(tǒng)都無可用的用戶實例，則進行異常處理，拒絕該呼叫。
6.如權利要求1所述的方法，其特征在于，步驟b所述的選擇分布式信令處理子系統(tǒng)的方法為RNC隨機逐一檢測RNS中所有的分布式信令處理子系統(tǒng)，選擇檢測到的第一個具有可用的用戶實例的分布式信令處理子系統(tǒng)。
7.如權利要求6所述的方法，其特征在于，所述的選擇分布式信令處理子系統(tǒng)的方法包括以下步驟RNC逐一檢測RNS中所有的分布式信令處理子系統(tǒng)的用戶實例占用情況，如果有可用的用戶實例，則選擇該分布式信令處理子系統(tǒng)；如果無用戶實例可用，則繼續(xù)檢測下一個分布式信令處理子系統(tǒng)；如果檢測完畢所有的分布式信令處理子系統(tǒng)，都沒有可用的用戶實例，則進行異常處理，拒絕該呼叫。
8.如權利要求1所述的方法，其特征在于，步驟c在所述的處理該呼叫之前，進一步包括將該呼叫轉(zhuǎn)移到所選擇的分布式信令處理子系統(tǒng)上。
全文摘要
本發(fā)明公開了一種分布式管理的無線網(wǎng)絡子系統(tǒng)中的呼叫處理方法，該方法的主要步驟為在UE發(fā)起接入呼叫時，管理UE所在小區(qū)的分布式信令處理子系統(tǒng)首先判斷是否可以處理該呼叫，如果該子系統(tǒng)有可用的用戶實例，則直接處理該呼叫；否則，選擇可以處理該呼叫的分布式信令處理子系統(tǒng)處理該呼叫。應用該方法可以在很大程度上解決在分布式管理的RNC系統(tǒng)中可能出現(xiàn)的某個分布式信令處理子系統(tǒng)的小區(qū)無線鏈路資源很空閑，但是由于該分布式信令處理子系統(tǒng)已無可用的用戶實例而造成的呼損的問題，可以降低系統(tǒng)的呼損率，提高系統(tǒng)資源的利用率。
文檔編號H04W28/16GK1713769SQ20041004823
公開日2005年12月28日 申請日期2004年6月14日 優(yōu)先權日2004年6月14日
發(fā)明者劉霞玲, 張蕾, 徐曉琳, 王強, 秦圣奕, 雍文遠 申請人:華為技術有限公司