一种分布式管理的无线网络子系统中的呼叫处理方法

文档序号:7593163阅读:176来源:国知局
专利名称:一种分布式管理的无线网络子系统中的呼叫处理方法
技术领域
本发明涉及宽带码分多址(WCDMA)移动通信技术的呼叫处理方法,特别涉及到一种分布式管理的无线网络子系统(RNS)中的呼叫处理方法。
背景技术
WCDMA系统是由核心网(CN),全球移动通信系统的陆地无线接入网络(UTRAN)和用户设备(UE)组成的,图1显示了WCDMA系统的网络结构。其中,UTRAN的主要功能是实现系统的接入控制,移动性管理以及无线资源的管理和控制等功能。如图1所示,UTRAN包括一个或者多个通过Iu接口连接到CN的RNS,一个RNS可以包括一个无线网络控制器(RNC)以及一个或者多个基站Node B。
在RNS的设计中,可以应用分布式管理的方法,即在一个RNS中可以应用多个分布式信令处理子系统来管理并实现RNC的基本功能,其中每个分布式信令处理子系统负责RNS中一部分小区用户的接入控制、移动性管理以及无线资源的管理和控制等等。每个分布式信令处理子系统管理的小区可以由用户根据实际情况进行配置,但是从系统负荷分担和处理能力等方面考虑,每个分布式信令处理子系统管理的小区数目和容量都会有一定的限制。如图1所示,RNC A和RNC B分别有两个分布式信令处理子系统1和2,分别负责管理该RNS中一部分的小区。
需要说明的是,UTRAN可以包含一个或者多个RNS,一个RNC中可以包含一个或者多个分布式信令处理子系统,一个分布式信令处理子系统可以管理一个或者多个Node B,而不限于图1所示的数量关系。
在WCDMA系统中,为了对用户设备(UE)的状态和资源消耗进行方便的管理,RNC会为每个新的接入呼叫分配一个用户实例,该用户实例负责管理该呼叫的所有信令交互、资源分配等操作。并且用户实例只有在UE与RNC之间的连接被释放的时候才被释放。需要说明的是,UE总是通过其所在的小区接入到UTRAN的,且RNC所管理的每一个小区都对应RNC中的一个分布式信令处理子系统,而每个分布式信令处理子系统可以管理一个或者多个小区。如图1所示,如果UE从分布式信令处理子系统1管理的小区接入UTRAN,则分布式信令处理子系统1需要为UE的呼叫分配一个用户实例。出于系统容量上的考虑,每个分布式信令处理子系统可以分配的用户实例的数目是有一定限制的。
目前,WCDMA系统中新的接入呼叫主要可以由以下几个方面启动UE发起无线资源控制连接(RRC)建立请求;硬切换伴随迁移,作为目标RNC接收到迁移请求消息;UE发生2G到3G切换,切换进入UTRAN系统;跨RNC软切换过程中,作为目标的RNC接收到无线链路建立的请求消息;小区更新伴随迁移时,作为目标的RNC接收到小区更新消息。
上文所述的用户实例是在UE第一次接入系统的时候,由UE所在小区对应的分布式信令处理子系统分配的。用户实例的分配步骤如下a.当UE选择从如图1所示的小区A(CELL A)接入UTRAN系统时,UE的第一条接入呼叫请求信令就会到达管理该小区的分布式信令处理子系统1;b.分布式信令处理子系统1检查它是否有可用的用户实例,如果有,就为该呼叫分配一个新的用户实例以及呼叫资源;如果没有,则进行异常处理,拒绝该呼叫。
然而,现有的用户实例分配策略在实际的应用中是有一定的局限性的,即用户实例并不随着UE的切换而迁移。结合图1举例说明,当该UE从图1所示的分布式信令处理子系统1管理的CELL A切换到位于相同RNS的分布式信令处理子系统2管理的小区CELL B上时,该呼叫的用户实例并不会从分布式信令处理子系统1迁移到分布式信令处理子系统2上。也就是说,此时UE虽然处在分布式信令处理子系统2所管理的小区CELL B内,但是该UE的呼叫仍然占用分布式信令处理子系统1的用户实例资源。
由此可以看出,由于每个分布式信令处理子系统可以分配的用户实例数目是有限的,所以应用这种用户实例的分配策略就有可能会出现如下问题虽然某些分布式信令处理子系统所管理的小区的无线链路资源还有空闲,但其用户实例却已经被消耗完了。在这种情况下,如果有处于该分布式信令处理子系统所管理的小区的UE需要接入新的呼叫,就会因为该分布式信令处理子系统已经没有可用的用户实例而导致呼损。

发明内容
有鉴与此,本发明的目的就是提供一种分布式管理的RNS中进行呼叫处理的方法,以此来解决在分布式管理的RNS中可能出现的虽然某个分布式信令处理子系统的小区无线链路资源很空闲,但是由于该分布式信令处理子系统已无可用的用户实例而造成呼损的问题。
为了达到上述目的,本发明公开了一种分布式管理的RNS中的呼叫处理方法,该方法主要包含以下步骤a.UE发起接入呼叫请求;b.管理UE所在小区的分布式信令处理子系统判断是否可以处理该呼叫,如果可以,则直接处理该呼叫,然后结束本流程;否则,选择可以处理该呼叫的分布式信令处理子系统;c.由所选择的分布式信令处理子系统处理该呼叫。
其中,步骤b所述的判断是否可以处理该呼叫的方法为判断该分布式信令处理子系统是否有可用的用户实例,如果有,则可以处理该呼叫;否则,不能处理该呼叫。
在UTRAN系统配置时,RNC为每个分布式信令处理子系统绑定一个备选子系统,步骤b所述的选择可以处理该呼叫的分布式信令处理子系统为选择该分布式信令处理子系统的备选子系统。
另外,步骤b所述的选择分布式信令处理子系统的方法还可以为RNC根据其RNS中各个分布式信令处理子系统的用户实例占用情况,为该呼叫选择最空闲的分布式信令处理子系统。
上述的选择分布式信令处理子系统的方法包括以下步骤RNC检测所有分布式信令处理子系统的用户实例占用情况,如果有一个或者多个分布式信令处理子系统具有可用的用户实例,则选择当前最空闲的分布式信令处理子系统;如果所有的分布式信令处理子系统都无可用的用户实例,则进行异常处理,拒绝该呼叫。
此外,步骤b所述的选择分布式信令处理子系统的方法又可以为RNC随机逐一检测RNS中所有的分布式信令处理子系统,选择检测到的第一个具有可用的用户实例的分布式信令处理子系统。
上述的选择分布式信令处理子系统的方法包括以下步骤RNC逐一检测RNS中所有的分布式信令处理子系统的用户实例占用情况,如果有可用的用户实例,则选择该分布式信令处理子系统;如果无用户实例可用,则继续检测下一个分布式信令处理子系统;如果检测完毕所有的分布式信令处理子系统,都没有可用的用户实例,则进行异常处理,拒绝该呼叫。
步骤c在所述的处理该呼叫之前,进一步包括将该呼叫转移到所选择的分布式信令处理子系统上。
由此可见,当UE进行呼叫接入请求时,应用本发明所述的方法可以在管理UE所在小区的分布式信令处理子系统已无用户实例可用的情况下,选择其他的分布式信令处理子系统处理该呼叫,以解决由于管理UE接入的小区的分布式信令处理子系统由于无用户实例可用而造成的呼损,降低了分布式管理的RNS的呼损率,提高了系统资源的利用率。


图1显示了UTRAN的网络结构;图2显示了本发明所述的在分布式管理的RNS中进行呼叫处理的具体流程;图3显示了本发明所述的一个优选实施例的呼叫处理流程;图4显示了本发明所述的另一个优选实施例的呼叫处理流程;图5显示了本发明所述的又一个优选实施例的呼叫处理流程。
具体实施例方式
下面就结合附图和具体的实施例对本发明进行进一步的详细说明。
本发明公开了一种在分布式管理的无线网络子系统中的呼叫处理方法,该方法主要包含以下步骤a.UE发起接入呼叫请求;b.管理UE所在小区的分布式信令处理子系统判断是否可以处理该呼叫,如果可以,则直接处理该呼叫,然后结束本流程;否则,选择可以处理该呼叫的分布式信令处理子系统;c.由所选择的分布式信令处理子系统处理该呼叫。
上述方法的具体步骤如图2所示,图2为本发明所述的分布式管理的RNS中进行呼叫处理的具体流程,包括以下步骤步骤201UE在某个分布式信令处理子系统所管理的小区接入UTRAN;步骤202该分布式信令处理子系统判决是否可以处理该呼叫如果可以,则执行步骤203;否则,执行步骤204;其中,上述分布式信令处理子系统判决是否可以处理该呼叫的步骤又称为话务分担判决;步骤203该分布式信令处理子系统直接处理该呼叫,即为该呼叫分配用户实例、呼叫资源等,然后结束本流程;
步骤204选择可以处理该呼叫的分布式信令处理子系统,然后执行步骤205;步骤205将该呼叫转移到所选择的分布式信令处理子系统,并由所选择的分布式信令处理子系统处理该呼叫,即为该呼叫分配用户实例、呼叫资源等,然后结束本流程。
其中,步骤205又称为话务分担。
图3所示的为本发明的一个优选的实施例,在该实施例中,上述步骤204所述的选择可以处理该呼叫的分布式信令处理子系统是通过为每个分布式信令处理子系统绑定一个备选子系统的方法来实现的。
在这一实施例中,在对UTRAN系统进行配置的时候就为其所有的分布式信令处理子系统确定两两互为备选子系统的关系,并在每个分布式信令处理子系统中记录其备选子系统的标识。一旦需要进行话务分担,则直接将呼叫转移到相对应的备选分布式信令处理子系统上,其具体步骤如下步骤301UTRAN系统配置所有的分布式信令处理子系统为两两互为备选子系统的关系;步骤302UE在其中一个分布式信令处理子系统所管理的小区接入UTRAN;步骤303该分布式信令处理子系统进行话务分担的判决如果有可用的用户实例,则执行步骤304;否则,执行步骤305;步骤304由该分布式信令处理子系统处理该呼叫,为该呼叫分配用户实例、分配呼叫资源等;步骤305将呼叫处理转移到其备选分布式信令处理子系统,下面执行步骤306;步骤306该备选子系统判断是否可以处理该呼叫,如果该备选分布式信令处理子系统有可用的用户实例,则执行步骤307;否则,执行步骤308;步骤307由该备选信令处理子系统处理该呼叫,为呼叫分配用户实例,分配呼叫资源;步骤308进行异常处理,拒绝该呼叫。
下面举例对这一实施例进行详细说明假设UTRAN系统设置了6个分布式信令处理子系统1、2、3、4、5和6,则在UTRAN进行系统配置的时候就可以将分布式信令处理子系统1和2,3和4,5和6两两分别确定为互为备选的分布式信令处理子系统。如图1所示,RNC可以将分布式信令处理子系统1和2设置为互为备选子系统。其中,各个分布式信令处理子系统都负责其管理的小区上报的信令的转发以及其负责用户的信令交互。此时,UE由分布式信令处理子系统1管理的小区接入UTRAN,如果分布式信令处理子系统1发现已无可用的用户实例满足新的呼叫,就直接将该呼叫转移给其备选分布式信令处理子系统2,如果此时分布式信令处理子系统2也无可用的用户实例,则拒绝该呼叫接入。同样,如果分布式信令处理子系统2需要话务分担,也将直接将呼叫处理转移给其备选分布式信令处理子系统1来实现。以上所述的方法同样适用于分布式信令处理子系统3和4以及5和6之间的话务分担。需要说明的是,互为备选的分布式信令处理子系统的选择可以是分布式信令处理子系统1~6之间的任意组合,而不超出本发明的精神和范围。
应用该方法的优点就是简单、易行,其不足之处就是如果UTRAN系统所配置的互为备选的两个分布式信令处理子系统的负荷都很重,也很难避免由于没有可用的用户实例而造成呼损的问题。
图4显示了本发明的另一个优选的实施例,在该实施例中,上述步骤204所述的选择可以处理该呼叫的分布式信令处理子系统是通过RNC为呼叫选择最空闲的分布式信令处理子系统进行处理的方法来实现的。
其中,所述最空闲的分布式信令处理子系统是指具有最多可用用户实例的分布式信令处理子系统。
在该实施例中,UTRAN系统并不为每个分布式信令处理子系统确定固定的备选关系,而是根据当前各个分布式信令处理子系统的用户实例占用情况,动态的选择最为空闲的分布式信令处理子系统。如果经过选择,所有的分布式信令处理子系统都无可用的用户实例,则拒绝该呼叫,导致呼损,如图4所示,具体包含以下步骤步骤401UE在一个分布式信令处理子系统所管理的小区接入UTRAN;步骤402该分布式信令处理子系统进行话务分担的判决,如果有可用的用户实例,则执行步骤403;否则,执行步骤404;步骤403由该信令处理子系统处理该呼叫,为该呼叫分配用户实例、分配呼叫资源等;步骤404RNC检测所有分布式信令处理子系统的用户实例占用情况,如果有分布式信令处理子系统有可用的用户实例,则执行步骤405;否则,执行步骤406;步骤405RNC选出当前最空闲的分布式信令处理子系统,将该呼叫处理转移到最空闲分布式信令处理子系统进行处理,最空闲的分布式信令处理子系统为该呼叫分配用户实例,分配呼叫资源。
步骤406进行异常处理,拒绝该呼叫。
下面举例对这一实施例进行详细说明例如,假设UTRAN系统设置了6个分布式信令处理子系统1、2、3、4、5和6,各个分布式信令处理子系统都负责其管理的小区上报的信令的转发以及其负责用户的信令交互。此时,如果分布式信令处理子系统1发现其已无可用的用户实例,RNC则通过动态选择机制找到此时具有最多可用用户实例的分布式信令处理子系统,比如分布式信令处理子系统4,并将该呼叫转移给分布式信令处理子系统4来处理。如果6个分布式信令处理子系统都无可用的用户实例,则将导致呼损。
应用这种方法的优点就是最大程度的利用了RNS中所有分布式信令处理子系统的用户实例。但是其不足之处就是,RNC需要维护一套动态选择最为空闲的分布式信令处理子系统的选择机制,因而增加了额外的系统开销。
图5显示了本发明所述的又一个优选的实施例,在这一实施例中,上述步骤204所述的选择可以处理该呼叫的分布式信令子处理系统的方法为RNC随机搜索系统所有的分布式信令处理子系统,直到找到一个可以处理该呼叫的分布式信令处理子系统。
在该实施例中,UTRAN系统是根据当前各个分布式信令处理子系统的用户实例占用情况,动态随机的选择空闲的分布式信令处理子系统。如果搜索了所有的分布式信令处理子系统都没有可用的用户实例,则拒绝该呼叫,而导致呼损,如图5所示,其具体步骤如下步骤501UE在一个分布式信令处理子系统所管理的小区接入UTRAN;步骤502该分布式信令处理子系统进行话务分担的判决如果有可用的用户实例,则执行步骤503;否则,执行步骤504;步骤503由该分布式信令处理子系统处理该呼叫,为该呼叫分配用户实例、分配呼叫资源等;步骤504RNC随机搜索另一个分布式信令处理子系统的用户实例占用情况如果有可用的用户实例,则执行步骤505;如果无用户实例可用,则循环该步骤;如果搜索完毕所有的分布式信令处理子系统,都没有可用的用户实例,则执行步骤506;步骤505将该呼叫处理转移到搜索到的有空闲用户实例的分布式信令处理子系统进行处理,即为该呼叫分配用户实例,分配呼叫资源;步骤506进行异常处理,拒绝该呼叫。
下面举例对本实施例进一步详细说明,例如,假设UTRAN系统设置了6个分布式信令处理子系统1、2、3、4、5和6,各个分布式信令处理子系统都负责其管理的小区上报的信令的转发以及其负责用户的信令交互。此时,如果分布式信令处理子系统1没有可用的用户实例,则进行话务分担,将呼叫处理转移给分布式信令处理子系统2,如果恰好分布式信令处理子系统2也无可用的用户实例,则将呼叫处理再一次转移给分布式信令处理子系统3,以此类推......。直到搜索到可用的用户实例为止。如果所有的分布式信令处理子系统都没有可用的用户实例则拒绝该呼叫。需要说明的是,分布式信令处理子系统在进行话务分担的时候搜索具有空闲用户实例的分布式信令处理子系统的顺序并不限于如上所述的顺序,还可以是任意其它系统设定的搜索顺序,而不会超出本发明的精神和范围。
应用这种方法的优点也是最大限度的利用了所有分布式信令处理子系统的用户实例。其不足之处就是,这种方法可能需要在不同的分布式信令处理子系统上将该呼叫处理进行多次转移才能得到处理,造成系统对呼叫的处理时延较大。
由此可见,应用本发明所述的方法,可以在很大程度上解决在分布式管理的RNS中可能出现的虽然某个分布式信令处理子系统的小区无线链路资源很空闲,但是由于该分布式信令处理子系统已无可用的用户实例而造成的呼损的问题。因此,应用本方法可以降低系统的呼损率,提高系统资源的利用率。
以上所述仅为本发明的较佳实施例而已,并非用来限定本发明的保护范围。
权利要求
1.一种分布式管理的无线网络子系统中的呼叫处理方法,其特征在于,该方法主要包含以下步骤a.UE发起接入呼叫请求;b.管理UE所在小区的分布式信令处理子系统判断是否可以处理该呼叫,如果可以,则直接处理该呼叫,然后结束本流程;否则,选择可以处理该呼叫的分布式信令处理子系统;c.由所选择的分布式信令处理子系统处理该呼叫。
2.如权利要求1所述的方法,其特征在于,步骤b所述的判断是否可以处理该呼叫的方法为判断该分布式信令处理子系统是否有可用的用户实例,如果有,则可以处理该呼叫;否则,不能处理该呼叫。
3.如权利要求1所述的方法,其特征在于,在UTRAN系统配置时,RNC为每个分布式信令处理子系统绑定一个备选子系统,步骤b所述的选择可以处理该呼叫的分布式信令处理子系统为选择该分布式信令处理子系统的备选子系统。
4.如权利要求1所述的方法,其特征在于,步骤b所述的选择分布式信令处理子系统的方法为RNC根据其RNS中各个分布式信令处理子系统的用户实例占用情况,为该呼叫选择最空闲的分布式信令处理子系统。
5.如权利要求4所述的方法,其特征在于,所述的选择分布式信令处理子系统的方法包括以下步骤RNC检测所有分布式信令处理子系统的用户实例占用情况,如果有一个或者多个分布式信令处理子系统具有可用的用户实例,则选择当前最空闲的分布式信令处理子系统;如果所有的分布式信令处理子系统都无可用的用户实例,则进行异常处理,拒绝该呼叫。
6.如权利要求1所述的方法,其特征在于,步骤b所述的选择分布式信令处理子系统的方法为RNC随机逐一检测RNS中所有的分布式信令处理子系统,选择检测到的第一个具有可用的用户实例的分布式信令处理子系统。
7.如权利要求6所述的方法,其特征在于,所述的选择分布式信令处理子系统的方法包括以下步骤RNC逐一检测RNS中所有的分布式信令处理子系统的用户实例占用情况,如果有可用的用户实例,则选择该分布式信令处理子系统;如果无用户实例可用,则继续检测下一个分布式信令处理子系统;如果检测完毕所有的分布式信令处理子系统,都没有可用的用户实例,则进行异常处理,拒绝该呼叫。
8.如权利要求1所述的方法,其特征在于,步骤c在所述的处理该呼叫之前,进一步包括将该呼叫转移到所选择的分布式信令处理子系统上。
全文摘要
本发明公开了一种分布式管理的无线网络子系统中的呼叫处理方法,该方法的主要步骤为在UE发起接入呼叫时,管理UE所在小区的分布式信令处理子系统首先判断是否可以处理该呼叫,如果该子系统有可用的用户实例,则直接处理该呼叫;否则,选择可以处理该呼叫的分布式信令处理子系统处理该呼叫。应用该方法可以在很大程度上解决在分布式管理的RNC系统中可能出现的某个分布式信令处理子系统的小区无线链路资源很空闲,但是由于该分布式信令处理子系统已无可用的用户实例而造成的呼损的问题,可以降低系统的呼损率,提高系统资源的利用率。
文档编号H04W28/16GK1713769SQ20041004823
公开日2005年12月28日 申请日期2004年6月14日 优先权日2004年6月14日
发明者刘霞玲, 张蕾, 徐晓琳, 王强, 秦圣奕, 雍文远 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1