具体实施方式
为使本发明的目的、技术方案和优点更加清楚,以下结合附图及具体实施例,对本发明作进一步地详细说明。
根据本发明的实施例,提供了一种提高业务呼通率的实现方法。
图3是根据本发明实施例的提高业务呼通率的实现方法的流程图,如图3所示,该方法包括:
步骤302,RNC向UE发送无线承载(RB)建立消息;
步骤304,RNC判断其是否在第一预设时间内未接收到来自UE的无线承载响应消息,若是,则RNC触发UE上报小区更新消息;
步骤306,RNC接收到来自UE的小区更新消息,并根据小区更新消息所携带的信息和/或接收到小区更新消息的时间判断用户设备的配置状态;
步骤308,RNC根据UE的配置状态进行呼叫重建处理。
在步骤304中,RNC触发UE上报小区更新消息包括但不限于以下两种方式:RL去激活方式以及RL删除方式。RL去激活方式是指RNC向UE所属的NodeB(基站)发送RL去激活消息,使得无线链路停止下行发射,导致UE下行失步,UE在无线链路失败上报条件满足后,发送无线链路失败原因的小区更新消息给RNC,从而RNC进行无线链路重建过程。RL删除方式是指RNC向UE所属的NodeB发送RL删除消息,同样也是为了让UE下行失步,上报无线链路失败原因的小区更新消息给RNC,从而进行无线链路重建过程。比较这两种方式,在RL去激活方式下,上行链路仍然保持,RL删除方式比较彻底,但这两种方式的目的都是为了让UE上报小区更新消息进行无线链路的重建。RNC发送RL去激活消息或RL删除消息后,需要设置定时器T2(第二预设时间)等待UE上报小区更新消息,设置该定时器时长请参考T313和N313的取值。如果在该定时器超时前未收到UE上报的小区更新消息,则认为是异常情况,不在本发明的讨论范围内。若该异常情况发生,则RNC直接给CN返回业务指派失败。在本发明具体实施例中仅考虑RNC在T2超时前收到小区更新消息的情况。
在具体实施时,采用RL去激活方式和采用RL删除方式触发呼叫重建是有区别的。在RL去激活方式下,呼叫重建过程是先删除链路,再建立新链路;在RL删除方式下,呼叫重建过程只有新建链路过程。
步骤304中,RNC在第一预设时间内未接收到来自用户设备的无线承载响应消息的原因,根据空口失败的时间点划分为:(1)空口消息(无线承载建立消息)下发失败;(2)空口消息处理过程中失败;(3)返回空口响应消息失败三种情况,这些场景能涵盖所有空口质量导致的空口失败。区分场景是为了使RNC准确判断UE的状态,并和UE保持配置的同步。
下面具体说明区分上述三种情形的方法。
首先,可以从RNC等待空口响应定时器是否超时加以区分。一般情况下,RNC设置定时器,即在第一预设时间内等待空口响应消息,如果在第一预设时间内接收到空口响应消息,则杀定时器,否则定时器超时,RNC认为空口异常不再等待空口消息。
需要说明,第一预设时间(定时器T1)的设定需要考虑空口响应需要的时间以及IU口定时器时间。在保证空口配置时间满足的情况下,可以适当缩短RNC等待空口响应时间。第二预设时间(定时器T2)的设定,可依据无线链路失败满足的标准来确定。
具体来说,首先,第一预设时间不能设置过短,致使UE侧还没重配完成,网络侧提前超时,所以网络侧的空口定时器时长通常大于空口响应需要的时间TUE。具体地,设置第一预设时间需要综合考虑消息长度、空口传输、UE处理等因素。因此T1>TUE。
其次,根据本发明实施例,在业务建立过程中插入呼叫重建,所以在设置第一预设时间时还需要考虑呼叫重建所需要的时间,避免IU口(RNC与CN之间的接口)定时器T(即从RNC接收到来自CN的业务指派请求到向CN返回业务建立完成的时间)提前超时,否则会出现即使呼叫重建成功,但IU口超时的情况,仍然达不到挽回呼叫的目的。呼叫重建的时间包括UE检测到无线链路失败的时长T2(即第二预设时间)和呼叫重建流程所需的时长。因此T1<T-T2。
根据无线链路失败上报准则,UE侧检测到无线链路失败的时间(即第二预设时间)可以通过T313和N313计算得到,即检测到无线链路失败的时间T2(第二预设时间)=T313+N313*10ms+160ms+Toff,其中N313是物理层连续失步的次数,T313是N313次连续失步后启动的无线链路失败上报定时器,Toff为系统偏移量,160ms是同步检测的固定延迟。
另外,定时器T1的时长不应当大于新配置生效后,在新配置上检测到无线链路失败的时长,即T1<TUE+T2。
所以在T1定时器未超时的情况下,如果RNC接收到RL失败原因的小区更新,则认为UE没有切换到新配置(即第二配置状态),因为切换到新配置的时长和新配置上检测到无线链路失败的时长之和大于RNC等待空口响应的时长T1。如果在T1超时前RNC接收到RL失败原因的小区更新,则认为UE仍处于旧配置(即第一配置状态)。
RNC在等待空口响应定时器T1超时后,可以根据RNC发送RB建立消息后,RNC的RLC层是否接收到对端的ACK来处理:如果接收到,则认为UE接收到RB建立消息;否则,没有收到存在两种情况:(1)UE没有收到RB建立消息;(2)UE收到RB建立消息并返回ACK,但RNC没有收到ACK。
值得注意的是,对于R6及以上版本,在CELL UPDATE(小区更新)消息中包含有Reconfiguration Status Indicator信元,其表征UE收到RB建立/RB重配/RB释放等消息,正处于重配流程中,或已返回RB响应消息,正在等待该消息的RLC ACK。如果UE发送的CELL UPDATE中没有携带Reconfiguration Status Indicator信元,则认为UE没有收到RB建立消息。
因此,根据本发明实施例的区分上述三种情形的方式包括:如果在小区更新消息中没有携带Reconfiguration Status Indicator信元,无论是超时前还是超时后收到的小区更新消息,都可以认为UE没有收到RB建立消息,仍处于第一配置状态(即旧配置);如果在定时器T1(即第一预设时间)超时后收到的小区更新消息中携带了此信元,可以认为UE返回了RB响应消息,已经切换到第二配置状态(即新配置);如果在空口定时器(即第一预设时间)超时前收到的小区更新消息中携带了此信元,则认为UE正处于重配流程中,仍处于旧配置。
在判断出UE已经切换到新配置的情况下,RNC也需要切换到新配置上,因为UE在返回成功的RB建立响应消息时,新配置已经在UE侧生效,所以此时RNC按收到空口响应进行处理,并在新配置上进行呼叫重建;又因为RNC没有正确收到空口RB建立完成消息,所以无法获取响应消息中的加密信息,而UE因为没有收到对端RLC层的ACK(Acknowledgement,确认帧),也不会生效加密信息,所以网络侧和UE侧的加密信息不会因为空口响应消息的丢失而产生不一致。
根据上述的空口失败的三种情形,RNC分别进行如下处理:
(1)在UE没有收到RNC的RB建立消息的情况下,UE仍处于旧配置上,RNC在旧配置上进行呼叫重建,呼叫重建成功后再重建业务RB。
(2)在UE收到RB建立消息并返回成功响应,但RNC没有收到该响应消息的情况下,RNC在新配置上通过插入呼叫重建流程挽回呼叫。
(3)在UE收到RB建立消息,但重配过程中检测到无线链路失败或RLC不恢复的情况下,UE会停止重配流程,保持旧配置,并上报原因为无线链路失败的小区更新消息,此时,RNC在旧配置上进行呼叫重建,呼叫重建成功后再重建业务RB。
下面结合图4至图10详细描述本发明实施例。
图4是业务建立过程中RNC等空口RB建立响应超时,去激活RL后(仅包含SRNC RL),接收到UE小区更新消息的流程示意图。如图4所示,该流程具体包括:
步骤401:RNC接收到CN下发的业务指派消息;
步骤402:RNC向NodeB发送无线链路重配请求消息;
步骤403:RNC接收到NodeB返回的无线链路重配响应消息;
步骤404:RNC向UE发送无线承载建立消息;
步骤405:RNC设置空口定时器T1(第一预设时间);
步骤406:RNC判断T1定时器超时,即在T1过程中没有接收到来自UE的响应消息;
步骤407:RNC向NodeB发送无线链路去激活命令消息,去激活UE所属的无线链路;
步骤408:RNC设置定时器T2(第二预设时间),等待UE的小区更新消息;
步骤409:RNC在定时器T2超时前接收到来自UE的小区更新消息,该小区更新消息中携带有UE当前的重配状态指示;
步骤410:RNC向NodeB发送无线链路删除请求消息;
步骤411:RNC接收到NodeB返回的无线链路删除响应消息;
步骤412:RNC向NodeB发送无线链路建立请求消息;
步骤413:RNC接收到NodeB返回的无线链路建立响应消息;
步骤414:RNC向UE发送小区更新确认消息;
步骤415:RNC接收到UE返回的重配完成消息;
步骤416:RNC向CN发送业务指派响应消息。
图5是业务建立过程中RNC等空口RB建立响应超时,去激活RL后(包含DRNC RL),接收到UE小区更新消息的流程示意图。图5在图4所示的基础上,增加了无线链路去激活消息的跨IUR口(logical interface betweentwo RNCs,服务RNC(SRNC)和漂移RNC(DRNC)之间的接口)处理,当UE的激活集包含DRNC无线链路时,需要通过IUR口传递无线链路去激活消息到DRNC。如图5所示,该流程具体包括:
步骤501:SRNC接收到CN下发的业务指派消息;
步骤502:SRNC向NodeB发送无线链路重配请求消息;
步骤503:SRNC向DRNC发送无线链路重配请求消息;
步骤504:DRNC向NodeB(DRNC)发送无线链路重配请求消息;
步骤505:SRNC接收到NodeB返回的无线链路重配响应消息;
步骤506:DRNC接收到NodeB(DRNC)返回的无线链路重配响应消息;
步骤507:SRNC接收到DRNC返回的无线链路重配响应消息;
步骤508:SRNC向UE发送无线承载建立消息;
步骤509:SRNC设置空口定时器T1(第一预设时间);
步骤510:SRNC判断T1定时器超时,即在T1过程中没有接收到来自UE的响应消息;
步骤511:SRNC向NodeB发送无线链路去激活命令消息,去激活UE所属的无线链路;
步骤512:SRNC向DRNC发送无线链路去激活命令消息;
步骤513:DRNC向NodeB(DRNC)发送无线链路去激活命令消息;
步骤514:SRNC设置定时器T2(第二预设时间),等待UE的小区更新消息;
步骤515:SRNC在定时器T2超时前接收到来自UE的小区更新消息,该小区更新消息中携带有UE当前的重配状态指示;
步骤516:SRNC向NodeB发送无线链路删除请求消息;
步骤517:SRNC向DRNC发送无线链路删除请求消息;
步骤518:DRNC向NodeB(DRNC)发送无线链路删除请求消息;
步骤519:SRNC向NodeB发送无线链路建立请求消息;
步骤520:SRNC接收到NodeB返回的无线链路建立响应消息;
步骤521:SRNC向UE发送小区更新确认消息;
步骤522:SRNC接收到UE返回的重配完成消息;
步骤523:SRNC向CN发送业务指派响应消息。
图6是业务建立过程中RNC等空口RB建立响应超时,删除RL后(仅包含SRNC RL),接收到UE小区更新消息的流程示意图。如图6所示,该流程具体包括:
步骤601:RNC接收到CN下发的业务指派消息;
步骤602:RNC向NodeB发送无线链路重配消息;
步骤603:RNC接收到NodeB返回的无线链路重配响应消息;
步骤604:RNC向UE发送无线承载建立消息;
步骤605:RNC设置等待空口定时器T1;
步骤606:RNC判断T1定时器超时,即在T1过程中没有收到UE的响应消息;
步骤607:RNC向NodeB发送无线链路删除请求消息;
步骤608:RNC接收到NodeB返回的无线链路删除响应消息;
步骤609:RNC设置定时器T2,等待UE的小区更新消息;
步骤610:RNC在定时器T2超时前接收到UE的小区更新消息;
步骤611:RNC向NodeB发送无线链路建立请求消息;
步骤612:RNC接收到NodeB返回的无线链路建立响应消息;
步骤613:RNC向UE发送小区更新确认消息;
步骤614:RNC接收到UE返回的重配完成消息;
步骤615:RNC向CN发送业务指派响应消息。
图7是业务建立过程中RNC等空口RB建立响应超时,删除RL后(包含DRNC RL),等到UE小区更新的流程示意图。图7与图6类似,差别在于在T1超时后,需增加DRNC无线链路的删除,SRNC通过IUR口将无线链路删除传递到DRNC。如图7所示,该流程具体包括:
步骤701:SRNC接收到CN下发的业务指派消息;
步骤702:SRNC向NodeB发送无线链路重配请求消息;
步骤703:SRNC向DRNC发送无线链路重配请求消息;
步骤704:DRNC向NodeB(DRNC)发送无线链路重配请求消息;
步骤705:SRNC接收到NodeB返回的无线链路重配响应消息;
步骤706:DRNC接收到NodeB(DRNC)返回的无线链路重配响应消息;
步骤707:SRNC接收到DRNC返回的无线链路重配响应消息;
步骤708:SRNC向UE发送无线承载建立消息;
步骤709:SRNC设置空口定时器T1(第一预设时间);
步骤710:SRNC判断T1定时器超时,即在T1过程中没有接收到来自UE的响应消息;
步骤711:SRNC向NodeB发送无线链路删除请求消息;
步骤712:SRNC向DRNC发送无线链路删除请求消息;
步骤713:DRNC向NodeB(DRNC)发送无线链路删除请求消息;
步骤714:SRNC设置定时器T2(第二预设时间),等待UE的小区更新消息;
步骤715:SRNC在定时器T2超时前接收到来自UE的小区更新消息,该小区更新消息中携带有UE当前的重配状态指示;
步骤716:SRNC向NodeB发送无线链路建立请求消息;
步骤717:SRNC接收到NodeB返回的无线链路建立响应消息;
步骤718:SRNC向UE发送小区更新确认消息;
步骤719:SRNC接收到UE返回的重配完成消息;
步骤720:SRNC向CN发送业务指派响应消息。
图8是业务建立过程中,UE没有接收到RB建立消息,RNC去激活无线链路触发呼叫重建的流程示意图。如图8所示,该流程具体包括:
步骤801:RNC接收到CN下发的业务指派消息;
步骤802:RNC向NodeB发送无线链路重配请求消息;
步骤803:RNC接收到NodeB返回的无线链路重配响应消息;
步骤804:RNC向UE发送无线承载建立消息,无线承载建立消息用虚线表示该消息没有发送到UE;
步骤805:RNC设置等待空口定时器T1;
步骤806:RNC判断T1定时器超时,即在T1过程中没有收到UE的响应消息;
步骤807:RNC向NodeB发送无线链路去激活命令消息,去激活UE所属的无线链路;
步骤808:RNC设置定时器T2,等待UE的小区更新消息;
步骤809:RNC在定时器T2超时前接收到UE上报的小区更新消息,该消息中没有携带重配指示信元,表示UE没有进行重配处理;
步骤810:RNC向NodeB发送无线链路删除请求消息;
步骤811:RNC接收到NodeB返回的无线链路删除响应消息;
步骤812:RNC向NodeB发送无线链路建立请求消息;
步骤813:RNC接收到NodeB返回的无线链路建立响应消息;
步骤814:RNC向UE发送小区更新确认消息;
步骤815:RNC接收到UE返回的重配完成消息;
步骤816:在呼叫重建完成后,RNC向UE发送无线承载建立消息;
步骤817:RNC接收到UE返回的RB建立响应消息;
步骤818:RNC向CN发送业务指派响应消息。
图9是业务建立过程中,UE没有收到RB建立消息,RNC删除无线链路触发呼叫重建的流程示意图。图9和图8类似,在删除无线链路触发呼叫重建后,发送RB建立消息给UE进行业务无线承载的建立。如图9所示,该流程具体包括:
步骤901:RNC接收到CN下发的业务指派消息;
步骤902:RNC向NodeB发送无线链路重配消息;
步骤903:RNC接收到NodeB返回的无线链路重配响应消息;
步骤904:RNC向UE发送无线承载建立消息,无线承载建立消息用虚线表示该消息没有发送到UE;
步骤905:RNC设置等待空口定时器T1;
步骤906:RNC判断T1定时器超时,即在T1过程中没有收到UE的响应消息;
步骤907:RNC向NodeB发送无线链路删除请求消息;
步骤908:RNC接收到NodeB返回的无线链路删除响应消息;
步骤909:RNC设置定时器T2,等待UE的小区更新消息;
步骤910:RNC在定时器T2超时前接收到UE上报的小区更新消息,该消息中没有携带重配指示信元,表示UE没有进行重配处理;
步骤911:RNC向NodeB发送无线链路建立请求消息;
步骤912:RNC接收到NodeB返回的无线链路建立响应消息;
步骤913:RNC向UE发送小区更新确认消息;
步骤914:RNC接收到UE返回的重配完成消息;
步骤915:在呼叫重建完成后,RNC向UE发送无线承载建立消息;
步骤916:RNC接收到UE返回的RB建立响应消息;
步骤917:RNC向CN发送业务指派响应消息。
图10是业务建立过程中,RNC在空口响应超时前收到小区更新的流程示意图,具体包括:
步骤1001:RNC接收到CN下发的业务指派消息;
步骤1002:RNC向NodeB发送无线链路重配消息;
步骤1003:RNC接收到NodeB返回的无线链路重配响应消息;
步骤1004:RNC向UE发送无线承载建立消息;
步骤1005:RNC设置等待空口定时器T1;
步骤1006:在T1定时器未超时前,RNC收到UE的小区更新;
步骤1007:RNC杀定时器T1;
步骤1008:RNC向NodeB发送无线链路删除请求消息;
步骤1009:RNC接收到NodeB返回的无线链路删除响应消息;
步骤1010:RNC向NodeB发送无线链路建立请求消息;
步骤1011:RNC接收到NodeB返回的无线链路建立响应消息;
步骤1012:RNC向UE发送小区更新确认消息;
步骤1013:RNC接收到UE返回的重配完成消息;
步骤1014:呼叫重建完成后,RNC向UE发送RB建立消息,进行业务无线承载的建立;
步骤1015:RNC接收到UE返回的RB建立响应消息;
步骤1016:RNC向CN发送业务指派响应消息。
在上述的流程图中,图4、5、6、7示出RNC等空口响应超时的具体实施例。图4、5采用的是无线链路去激活方式触发呼叫重建,图6、7采用无线链路删除方式触发呼叫重建,图4、6是仅包括S侧链路的处理,图5、7是包括D侧链路的处理示意图。图8、9示出UE没有收到RB建立消息的具体实施例,图8采用无线链路去激活方式触发呼叫重建,图9采用无线链路删除方式触发呼叫重建。图10示出了RNC在空口响应超时前收到小区更新的具体实施例。
装置实施例
根据本发明的实施例,还提供了一种无线网络控制器。
图11是根据本发明的实施例的无线网络控制器的框图,如图11所示,该无线网络控制器包括:
发送模块10,用于向用户设备发送无线承载建立消息;第一判断模块20,用于判断是否在第一预设时间内未接收到来自用户设备的无线承载响应消息;触发模块30,用于在判断模块的判断结果为是的情况下,触发用户设备上报小区更新消息;接收模块40,用于接收来自用户设备的小区更新消息;第二判断模块50,用于根据小区更新消息所携带的信息和/或接收到小区更新消息的时间判断用户设备的配置状态;重建处理模块60,用于根据第二判断模块判断的用户设备的配置状态进行呼叫重建处理。
其中,触发模块通过向用户设备所属的基站发送无线链路去激活消息或无线链路删除消息,触发用户设备上报小区更新消息。
其中第二判断模块进一步包括:第一判断子模块,用于小区更新消息中未携带用户设备的重配信息,则判断用户设备为第一配置状态;第二判断子模块,用于在第一预设时间内接收到小区更新消息、且小区更新消息中携带有用户设备的重配信息,则判断用户设备为第一配置状态;第三判断子模块,用于超过第一预设时间接收到小区更新消息、且小区更新消息中携带有用户设备的重配信息,则判断用户设备为第二配置状态。
在具体实施中,根据本发明实施例的无线网络控制器的工作流程可以参考图2至图10,此处不赘述。
综上所示,根据本发明上述技术方案,可以有效地挽回因空口失败导致的掉话,提高了网络呼通率。
以上所述仅为本发明的实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的权利要求范围之内。