一种异常情况下的寻呼控制方法及装置制造方法
【专利摘要】本发明公开了一种异常情况下的寻呼控制方法及装置，用于解决MME发送大量寻呼消息造成负荷过重而引发设备故障，以及不区分UE等级导致对优先级高的UE无法优先处理的问题，该方法为：在设定的检测周期内，每次对UE发送寻呼消息之前，获取在检测周期内累计的寻呼消息条数，并判断寻呼消息条数是否大于第一设定阈值；在判定寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息，否则，在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息；在判定寻呼消息条数小于或等于第一设定阈值时，发送寻呼消息。采用上述方法，可以有效对寻呼过程进行控制。
【专利说明】一种异常情况下的寻呼控制方法及装置
【技术领域】
[0001]本发明涉及通信领域，尤其涉及一种异常情况下的寻呼控制方法及装置。
【背景技术】
[0002]UE注册到LTE网络中，当没有业务发生时，一般会处于空闲(ECM-1DLE)状态，该状态是用于指示UE和移动管理实体(Mobile Management Entity,MME)之间的信令连接释放，即SI链路释放。参阅图1所示的网络侧发起的寻呼过程，具体包括步骤I至步骤6b，其中，当网络侧有下行数据或者有下行信令时(即步骤I和步骤2)，需要对处于ECM-1DLE态的UE发起寻呼(即步骤3和步骤4)，UE收到MME对其的寻呼消息后，发起服务请求过程(即步骤5)来恢复SI链路连接，在恢复SI链路连接后，下行数据或者下行信令才会下发到终端。
[0003]根据3GPP协议，以下几种情况MME都需要对UE进行寻呼:
[0004]参阅图2所示的专用承载激活过程，具体包括步骤I至步骤12，3GPP协议记载:服务网关发送给MME创建承载请求，若UE处于ECM-1DLE态，从步骤3处，MME将会触发网络触发服务请求。(The Serving Gff sends the Create Bearer Request message to theMME.1f the UE is in ECM-1DLE state the MME will trigger the Network TriggeredService Request from step3.)
[0005]参阅图3所示的MME发起的去附着过程，具体包括步骤I至步骤14，以及参阅图4所示的HSS发起的去附着过程，具体包括步骤Ia至步骤10a，3GPP协议记载:若UE处于ECM-1DLE态，MME会寻呼UEJIf the UE is in ECM-1DLE state the MME pages the UE.)
[0006]参阅图5所示的UE在激活状态下的F1DN GW发起的承载去激活过程,具体包括步骤I至步骤11，3GPP协议记载:MME通过发送给UE去附着请求消息，隐式地将UE去附着。若UE 处于 ECM-1DLE 态,MME 会寻呼 UE。(the MME explicitly detaches the UE by sendinga Detach Request message to the UE.1f the UE is in ECM-1DLE state the MME pagesthe UE.)
[0007]在某些突发或者异常的情况下，如分组数据网(Packet Data Network, PDN)向大量UE发送业务推送消息或者分组数据网网关(PDN Gateway, PGW)因为故障而需要释放掉所有的用户等等异常情况。在上述异常情况下，若大量的UE处于ECM-1DLE态，根据3GPP协议，MME需要对所有UE发起寻呼，MME瞬间会有大量的寻呼消息下发，大量的寻呼消息可能会造成MME的负荷饱和从而引发MME设备故障(如宕机)，严重时会造成整个网络的瘫痪。并且寻呼消息的下发并不区分UE等级，导致对于优先级高的UE无法保证可以优先处理。
【发明内容】
[0008]本发明实施例提供一种异常情况下的寻呼控制方法及装置，用以解决现有技术中存在的异常情况下，MME对UE发起寻呼，瞬间产生大量寻呼消息下发至UE时，造成MME负荷过重，从而引发设备故障的问题，以及在MME的负荷加重时，对寻呼消息的下发并不区分UE等级，导致对优先级高的UE无法优先处理的问题。[0009]本发明实施例提供一种异常情况下的寻呼控制方法及装置。
[0010]第一方面，一种异常情况下的寻呼控制方法，该方法包括:
[0011]在设定的检测周期内，每次对UE发送寻呼消息之前，获取在检测周期内累计的寻呼消息条数，并判断寻呼消息条数是否大于第一设定阈值；
[0012]在判定寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息，否则，在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息；
[0013]在判定寻呼消息条数小于或等于第一设定阈值时，发送寻呼消息。
[0014]结合第一方面，在第一种可能的实现方式中，获取在当前检测周期内累计的寻呼消息条数之后，在判断寻呼消息条数是否大于第一设定阈值之前，进一步包括:
[0015]判定寻呼消息条数小于当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
[0016]结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，进一步包括:
[0017]在判定寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0018]通过这种可能的实现方式，在寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，不再发送待发送的寻呼消息，可以使得MME设备不至于达到负荷最大的状态而导致设备瘫痪。
[0019]结合第一方面，在第三种可能的实现方式中，在判定寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，进一步包括:
[0020]判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。
[0021]通过这种可能的实现方式，处于空闲态的用户在多种情况下会发生寻呼过程，对于创建承载过程以及发送下行数据时触发而发送的寻呼消息过程，用户感知明显，因此，需要优先处理。
[0022]结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，进一步包括:
[0023]判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息。
[0024]结合第一方面或第一方面的上述任意一种可能的实现方式，在第五种可能的实现方式中，在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，进一步包括:
[0025]在确定寻呼消息的寻呼类型不为指定寻呼类型时，丢弃寻呼消息，丢弃的寻呼消息不进行累计。
[0026]通过这种可能的实现方式，通过指定寻呼类型，排除MME给全网发送寻呼消息对应的寻呼类型，以减少MME发送寻呼消息的条数。
[0027]结合第一方面或第一方面的第一至第四种中任意一种实现方式，在第六种可能的实现方式中，在确定寻呼消息的寻呼类型为指定寻呼类型之后，在发送寻呼消息之前，进一步包括:
[0028]判断寻呼消息不为重发寻呼消息时，初步确定能够发送寻呼消息。
[0029]结合第一方面的第六种可能的实现方式，在第七种可能的实现方式中，进一步包括:
[0030]确定寻呼消息为重发寻呼消息时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0031]通过这种可能的实现方式，可以尽可能的少发寻呼消息，有效的对寻呼消息进行控制，不对重发的寻呼消息，再次重复发送。
[0032]第二方面，一种异常情况下的寻呼控制装置，该装置包括:
[0033]第一处理单元，用于在设定的检测周期内，每次对UE发送寻呼消息之前，获取在检测周期内累计的寻呼消息条数，并判断寻呼消息条数是否大于第一设定阈值；
[0034]第二处理单元，用于在判定寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息，否则，在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息；
[0035]第三处理单元，用于在判定寻呼消息条数小于或等于第一设定阈值时，发送寻呼消息。
[0036]结合第二方面，在第一种可能的实现方式中，第一处理单元，还用于:
[0037]在获取在当前检测周期内累计的寻呼消息条数之后，在判断寻呼消息条数是否大于第一设定阈值之前，判定寻呼消息条数小于当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
[0038]结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，第一处理单元，还用于:
[0039]在判定寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0040]通过这种可能的实现方式，在寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，不再发送待发送的寻呼消息，可以使得MME设备不至于达到负荷最大的状态而导致设备瘫痪。
[0041]结合第二方面，在第三种可能的实现方式中，第二处理单元，还用于:
[0042]在判定寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。
[0043]通过这种可能的实现方式，处于空闲态的用户在多种情况下会发生寻呼过程，对于创建承载过程以及发送下行数据时触发而发送的寻呼消息过程，用户感知明显，因此，需要优先处理。
[0044]结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，第二处理单元，还用于:
[0045]判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息。[0046]结合第二方面或第二方面的上述任意一种可能的实现方式，在第五种可能的实现方式中，第二处理单元，还用于:
[0047]在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，在确定寻呼消息的寻呼类型不为指定寻呼类型时，丢弃寻呼消息，丢弃的寻呼消息不进行累计。
[0048]通过这种可能的实现方式，通过指定寻呼类型，排除MME给全网发送寻呼消息对应的寻呼类型，以减少MME发送寻呼消息的条数。
[0049]结合第二方面或第二方面的第一至第四种中任意一种实现方式，在第六种可能的实现方式中，第二处理单元，还用于:
[0050]在确定寻呼消息的寻呼类型为指定寻呼类型之后，在发送寻呼消息之前，判断寻呼消息不为重发寻呼消息时，初步确定能够发送寻呼消息。
[0051]结合第二方面的第六种可能的实现方式，在第七种可能的实现方式中，第二处理单元，还用于:
[0052]确定寻呼消息为重发寻呼消息时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0053]通过这种可能的实现方式，可以尽可能的少发寻呼消息，有效的对寻呼消息进行控制，不对重发的寻呼消息，再次重复发送。
[0054]第三方面，一种异常情况下的寻呼控制装置，该装置包括:
[0055]处理器，用于在设定的检测周期内，每次对UE发送寻呼消息之前，获取在检测周期内累计的寻呼消息条数，并判断寻呼消息条数是否大于第一设定阈值；在判定寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息，否则，在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息；或者，在判定寻呼消息条数小于或等于第一设定阈值时，发送寻呼消息。
[0056]结合第三方面，在第一种可能的实现方式中，处理器，还用于:
[0057]在获取在当前检测周期内累计的寻呼消息条数之后，在判断寻呼消息条数是否大于第一设定阈值之前，判定寻呼消息条数小于当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
[0058]结合第三方面的第一种可能的实现方式，在第二种可能的实现方式中，处理器，还用于:
[0059]在判定寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0060]通过这种可能的实现方式，在寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，不再发送待发送的寻呼消息，可以使得MME设备不至于达到负荷最大的状态而导致设备瘫痪。
[0061]结合第三方面，在第三种可能的实现方式中，处理器，还用于:
[0062]在判定寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。[0063]通过这种可能的实现方式，处于空闲态的用户在多种情况下会发生寻呼过程，对于创建承载过程以及发送下行数据时触发而发送的寻呼消息过程，用户感知明显，因此，需要优先处理。
[0064]结合第三方面的第三种可能的实现方式，在第四种可能的实现方式中，处理器，还用于:
[0065]判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息。
[0066]结合第三方面或第三方面的上述任意一种可能的实现方式，在第五种可能的实现方式中，处理器，还用于:
[0067]在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，在确定寻呼消息的寻呼类型不为指定寻呼类型时，丢弃寻呼消息，丢弃的寻呼消息不进行累计。
[0068]通过这种可能的实现方式，通过指定寻呼类型，排除MME给全网发送寻呼消息对应的寻呼类型，以减少MME发送寻呼消息的条数。
[0069]结合第三方面或第三方面的第一至第四种中任意一种实现方式，在第六种可能的实现方式中，处理器，还用于:
[0070]在确定寻呼消息的寻呼类型为指定寻呼类型之后，在发送寻呼消息之前，判断寻呼消息不为重发寻呼消息时，初步确定能够发送寻呼消息。
[0071]结合第三方面的第六种可能的实现方式，在第七种可能的实现方式中，处理器，还用于:
[0072]确定寻呼消息为重发寻呼消息时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0073]通过这种可能的实现方式，可以尽可能的少发寻呼消息，有效的对寻呼消息进行控制，不对重发的寻呼消息，再次重复发送。
【专利附图】
【附图说明】
[0074]图1为现有技术中网络侧发起的寻呼协议图；
[0075]图2为现有技术中专用承载激活过程协议图；
[0076]图3为现有技术中MME发起的去附着过程协议图；
[0077]图4为现有技术中HSS发起的去附着过程协议图；
[0078]图5为现有技术中UE在激活状态下的TON Gff发起的承载去激活过程协议图；
[0079]图6为本发明实施例中异常情况下的寻呼控制流程图；
[0080]图7为本发明实施例中异常情况下的寻呼控制详细流程图；
[0081]图8为本发明实施例中异常情况下的寻呼控制装置图；
[0082]图9为本发明实施例中异常情况下的用于寻呼控制的处理器结构图。
【具体实施方式】
[0083]为了解决现有技术中存在的异常情况下，MME对UE发起寻呼，瞬间产生大量寻呼消息下发至UE时，造成MME负荷过重，从而引发设备故障的问题，以及在MME的负荷加重时，对寻呼消息的下发并不区分UE等级，导致对优先级高的UE无法优先处理的问题，本发明实施例提供一种异常情况下的寻呼控制方法及装置。
[0084]下面结合附图，用具体实施例对本发明提供的方法及装置和相应系统进行详细描述。
[0085]参阅图6所示，本发明实施例提供的异常情况下的寻呼控制方法，具体为根据当前寻呼的寻呼类型以及当前待发送的寻呼消息所针对的UE的优先级进行寻呼控制，处于ECM-1DLE态的用户，在多种情况下会发生寻呼过程，比如承载建立、承载删除或有下行链路数据时。对于承载删除过程，用户感知并不明显，但是对于承载建立或有下行链路数据时，用户感知明显，对于承载建立过程以及有下行链路数据发送时，本发明实施里的寻呼控制方法可以在寻呼消息条数达到一定程度时，保证优先级高的用户优先建立承载，对于非承载建立或有下行链路数据发送时，如承载删除等过程引起的寻呼，则根据寻呼类型进行寻呼控制，具体流程如下:
[0086]步骤600:在设定的检测周期内，MME每次对UE发送寻呼消息之前，获取在检测周期内累计的寻呼消息条数，并判断寻呼消息条数是否大于第一设定阈值，若是，则执行步骤610 ;否则，执行步骤620。
[0087]具体的，在MME获取在当前检测周期内累计的寻呼消息条数之后，在判断寻呼消息条数是否大于第一设定阈值之前，判定寻呼消息条数小于当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。在判定寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0088]上述流程具体为:获取在检测周期内累计的寻呼消息条数可以通过在MME设备设置循环定时器以及寻呼条数计数器，循环定时器可配置检测周期，在每个周期的开始时刻对寻呼条数计数器进行初始化，即寻呼条数计数器清零的操作。在获取当前检测周期内累计的寻呼条数之后，判断寻呼消息条数是否大于或等于当前周期内能够发送的最大寻呼条数，若是，则丢弃当前寻呼的寻呼消息；否则，执行步骤610，判断寻呼消息条数是否大于第一设定阈值以及判断后的后续操作。上述最大寻呼条数以及第一设定阈值可以通过操作维护中心(Operation and Maintenance Centre, OMC)配置，第一设定阈值的设置是根据MME发送的寻呼消息条数在一个检测周期内达到一定数值时，需要开始对后续寻呼进行寻呼控制。
[0089]步骤610 =MME判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则执行步骤620 ;否则，执行步骤630。
[0090]步骤620 =MME发送寻呼消息。
[0091]步骤630:MME在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息。
[0092]具体的，在判定寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作(即步骤610)。判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息。
[0093]上述流程具体为:MME在判定寻呼消息条数大于第一设定阈值后，判断当前寻呼是否由创建承载过程触发或者由发送下行数据触发，若是，则执行判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值；否则，执行判断当前待发送的寻呼消息的寻呼类型是否为指定寻呼类型。
[0094]其中,UE的优先级主要通过业务质量(Quality of Service, QoS)参数中的分配和保留优先级(Allocation Retention Priority,ARP)中包含的优先级别(Priority-Level)来指示的，优先级别(Priority-Level)的取值范围为I至15,取值为I用于指示最高优先级，取值为15用于指示最低优先级。本发明实施例中的，所谓的优先级达到第二设定阈值即判断当前待发送的寻呼消息所针对的UE默认承载的ARP中指示的优先级别(Priority-Level)的取值是否小于某个设定值,若小于某个设定值时,则当前待发送的寻呼消息所针对的UE的优先级高于设定的优先级，例如，第二阈值设定为5，则优先级别(Priority-Level)的取值为I至5时，即为优先级达到第二阈值。
[0095]MME判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息；否则，在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消
肩、O
[0096]在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，进一步确定寻呼消息的寻呼类型不为指定寻呼类型时，丢弃寻呼消息，丢弃的寻呼消息不进行累计。
[0097]在确定寻呼消息的寻呼类型为指定寻呼类型之后，在发送寻呼消息之前，进一步判断寻呼消息不为重发寻呼消息时，初步确定能够发送寻呼消息。若确定寻呼消息为重发寻呼消息时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0098]上述流程具体为:MME判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息，否则，执行判断寻呼消息的寻呼类型是否为指定寻呼类型，若确定寻呼消息的寻呼类型为指定寻呼类型，则进一步判断寻呼消息是否为重发寻呼消息，若是，则丢弃寻呼消息，否则，发送寻呼消息。若确定寻呼消息的寻呼类型部位指定寻呼类型，则直接丢弃该寻呼消息。
[0099]其中，上述指定寻呼类型通常指定为全球唯一(用户)临时标识(GloballyUnique Temporary Identity, GUTI)寻呼，GUTI 为 MME 为 UE 分配的临时标识，GUTI 寻呼这种类型的寻呼为小范围的寻呼，若确定寻呼类型不为GUTI寻呼为国际移动用户标识(International Mobile Subscriber Identity, IMSI)寻呼时，则丢弃寻呼消息。
[0100]步骤640:MME在判定寻呼消息条数小于或等于第一设定阈值时，发送寻呼消息。
[0101]在判定寻呼消息条数小于或等于第一设定阈值时，MME设备在当前检测周期内发送的寻呼消息条数在可处理的寻呼条数范围内，因此直接发送寻呼消息。
[0102]参阅图7所示，通过举例详细对上述寻呼控制的流程进行说明。
[0103]步骤7000 =MME启动循环定时器和寻呼消息条数计数器，在循环定时器完成一个检测周期的计时后，初始化寻呼条数计数器，并且直接执行步骤7020。
[0104]步骤7010:寻呼消息条数加1，寻呼消息条数加I后，执行步骤7020。
[0105]可以通过循环定时器配置检测周期，本举例中将检测周期设为一秒钟，则循环定时器和寻呼消息条数计数器用来检测每秒钟MME发送的寻呼消息条数，寻呼消息条数的累计规则为只累计成功发送的寻呼消息条数，对丢弃的寻呼消息不进行累计。检测周期可以通过OMC配置。[0106]步骤7020:MME有寻呼消息待发送。
[0107]步骤7030:MME判断寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数；若是，则执行步骤7040 ;否则，执行步骤7050。
[0108]其中最大寻呼条数可以通过OMC配置，本举例中，假设最大寻呼条数为5000条。则在每秒钟内寻呼消息条数累计至5000条之后发送的寻呼消息进行丢弃处理，不再发送。若每秒钟内寻呼消息条数没有达到5000条时，继续执行后续操作。
[0109]步骤7040 =MME丢弃上述寻呼消息，丢弃寻呼消息后，返回步骤7020。
[0110]步骤7050:MME判断寻呼消息条数是否大于第一设定阈值；若是，则执行步骤7060 ;否则，执行步骤7070。
[0111]该第一设定阈值可以通过OMC配置，可以配置为最大寻呼条数的一定百分比，例如，每秒钟发送的寻呼消息条数在达到最大寻呼条数的百分之八十(即每秒发送4000条)开始对寻呼过程进行控制，则本举例中的第一设定阈值为4000条，则当前一秒内，若发送的寻呼消息条数超过4000时，开始对寻呼过程进行控制，即执行后续判断操作，若发送的寻呼消息条数未超过4000，则直接发送上述寻呼消息。
[0112]步骤7060:MME判断当前寻呼是否由创建承载过程触发或者由发送下行数据触发；若是，则执行步骤7080 ;否则，执行步骤7100。
[0113]步骤7070:MME发送当前待发送寻呼消息，发送寻呼消息后，返回步骤7010。
[0114]步骤7080 =MME判断当前待发送的寻呼消息所针对的UE默认承载的ARP中的优先级是否小于设定值；若是，则执行步骤7090 ;否则执行步骤7100。
[0115]UE默认承载的ARP中的优先级别的取值范围为I到15，其中，取值I用于指示最高优先级，取值15用于指示最低优先级，例如，将设定值设置为5，则在判定当前待发送的寻呼消息所针对的UE默认承载的ARP中的优先级别的取值为1-4时，执行步骤7090 ;若在判定当前待发送的寻呼消息所针对的UE默认承载的ARP中的优先级别的取值为5-15时，则执行步骤7100。
[0116]步骤7090:MME发送上述寻呼消息，发送寻呼消息后，返回步骤7010。
[0117]步骤7100:MME判断寻呼消息的寻呼类型是否为GUTI寻呼；若是，则执行步骤7110 ;否则，执行步骤7120。
[0118]步骤7110 =MME判断寻呼消息是否为重发寻呼消息；若是，则执行步骤7130 ;否则执行步骤7140。
[0119]步骤7120:若为MSI寻呼，则MME丢弃上述寻呼消息，丢弃寻呼消息后，返回步骤7020。
[0120]步骤7130 =MME丢弃上述寻呼消息，丢弃寻呼消息后，返回步骤7020。
[0121]步骤7140:MME发送上述寻呼消息，发送寻呼消息后，返回步骤7010。
[0122]基于同一发明构思，根据本发明上述实施例提供的异常情况下的寻呼控制方法，相应地，本发明另一实施例还提供了一种异常情况下的寻呼控制装置，该装置的结构示意图如图8所示，具体包括:第一处理单元800、第二处理单元810以及第三处理单元820:
[0123]第一处理单元800，用于在设定的检测周期内，每次对UE发送寻呼消息之前，获取在检测周期内累计的寻呼消息条数，并判断寻呼消息条数是否大于第一设定阈值；
[0124]第二处理单元810，用于在判定寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息，否则，在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息；
[0125]第三处理单元820，用于在判定寻呼消息条数小于或等于第一设定阈值时，发送寻呼消息。
[0126]第一处理单元800，还用于:
[0127]在获取在当前检测周期内累计的寻呼消息条数之后，在判断寻呼消息条数是否大于第一设定阈值之前，判定寻呼消息条数小于当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
[0128]第一处理单元800，还用于:
[0129]在判定寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0130]第二处理单元810，还用于:
[0131]在判定寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。
[0132]第二处理单元810，还用于:
[0133]判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息。
[0134]第二处理单元810，还用于:
[0135]在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，在确定寻呼消息的寻呼类型不为指定寻呼类型时，丢弃寻呼消息，丢弃的寻呼消息不进行累计。
[0136]第二处理单元810，还用于:
[0137]在确定寻呼消息的寻呼类型为指定寻呼类型之后，在发送寻呼消息之前，判断寻呼消息不为重发寻呼消息时，初步确定能够发送寻呼消息。
[0138]第二处理单元810，还用于:
[0139]确定寻呼消息为重发寻呼消息时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0140]基于同一发明构思，根据本发明上述实施例提供的异常情况下的寻呼控制方法，相应地，本发明另一实施例还提供了一种异常情况下的寻呼控制实体装置，该装置的结构示意图如图9所示,具体包括:处理器900:
[0141]处理器900，用于在设定的检测周期内，每次对UE发送寻呼消息之前，获取在检测周期内累计的寻呼消息条数，并判断寻呼消息条数是否大于第一设定阈值；在判定寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送寻呼消息，否则，在确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息；或者，在判定寻呼消息条数小于或等于第一设定阈值时，发送寻呼消息。
[0142]处理器900,还用于:
[0143]在获取在当前检测周期内累计的寻呼消息条数之后，在判断寻呼消息条数是否大于第一设定阈值之前，判定寻呼消息条数小于当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
[0144]处理器900，还用于:
[0145]在判定寻呼消息条数大于或等于当前检测周期内能够发送的最大寻呼条数时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0146]处理器900,还用于:
[0147]在判定寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。
[0148]处理器900,还用于:
[0149]判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定寻呼消息的寻呼类型为指定寻呼类型时，再发送寻呼消息。
[0150]处理器900，还用于:
[0151]在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，在确定寻呼消息的寻呼类型不为指定寻呼类型时，丢弃寻呼消息，丢弃的寻呼消息不进行累计。
[0152]处理器900，还用于:
[0153]在确定寻呼消息的寻呼类型为指定寻呼类型之后，在发送寻呼消息之前，判断寻呼消息不为重发寻呼消息时，初步确定能够发送寻呼消息。
[0154]处理器900，还用于:
[0155]确定寻呼消息为重发寻呼消息时，丢弃寻呼消息，其中，丢弃的寻呼消息不进行累计。
[0156]综上所述，本发明实施例提供的方案在大量UE处于ECM-1DLE态时，MME对UE发起寻呼，瞬间产生大量寻呼消息下发至UE时，根据UE优先级以及当前寻呼的寻呼类型对寻呼过程进行控制，不会造成MME负荷过重，避免了设备故障的问题，以及在MME的负荷加重时，对寻呼消息的下发并区分UE等级，可以在上述异常情况下优先处理优先级高的UE的请求。
[0157]显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
【权利要求】
1.一种异常情况下的寻呼控制方法，其特征在于，该方法包括: 在设定的检测周期内，每次对UE发送寻呼消息之前，获取在所述检测周期内累计的寻呼消息条数，并判断所述寻呼消息条数是否大于第一设定阈值； 在判定所述寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送所述寻呼消息，否则，在确定所述寻呼消息的寻呼类型为指定寻呼类型时，再发送所述寻呼消息； 在判定所述寻呼消息条数小于或等于第一设定阈值时，发送所述寻呼消息。
2.如权利要求1所述的方法，其特征在于，获取在当前检测周期内累计的寻呼消息条数之后，在判断所述寻呼消息条数是否大于第一设定阈值之前，进一步包括: 判定所述寻呼消息条数小于所述当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
3.如权利要求2所述的方法，其特征在于，进一步包括: 在判定所述寻呼消息条数大于或等于所述当前检测周期内能够发送的最大寻呼条数时，丢弃所述寻呼消息，其中，丢弃的寻呼消息不进行累计。
4.如权利要求1所述的方法，其特征在于，在判定所述寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，进一步包括: 判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。
5.如权利要求4所述的方法，其特征在于，进一步包括: 判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定所述寻呼消息的寻呼类型为指定寻呼类型时，再发送所述寻呼消息。
6.如权利要求1一 5任一项所述的方法，其特征在于，在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，进一步包括: 在确定所述寻呼消息的寻呼类型不为指定寻呼类型时，丢弃所述寻呼消息，丢弃的寻呼消息不进行累计。
7.如权利要求1一 5任一项所述的方法，其特征在于，在确定所述寻呼消息的寻呼类型为指定寻呼类型之后，在发送所述寻呼消息之前，进一步包括: 判断所述寻呼消息不为重发寻呼消息时，初步确定能够发送所述寻呼消息。
8.如权利要求7所述的方法，其特征在于，进一步包括: 确定所述寻呼消息为重发寻呼消息时，丢弃所述寻呼消息，其中，丢弃的寻呼消息不进行累计。
9.一种异常情况下的寻呼控制装置，其特征在于，该装置包括: 第一处理单元，用于在设定的检测周期内，每次对UE发送寻呼消息之前，获取在所述检测周期内累计的寻呼消息条数，并判断所述寻呼消息条数是否大于第一设定阈值； 第二处理单元，用于在判定所述寻呼消息条数大于第一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送所述寻呼消息，否则，在确定所述寻呼消息的寻呼类型为指定寻呼类型时，再发送所述寻呼消息； 第三处理单元，用于在判定所述寻呼消息条数小于或等于第一设定阈值时，发送所述寻呼消息。
10.如权利要求9所述的装置，其特征在于，所述第一处理单元，还用于: 在获取在当前检测周期内累计的寻呼消息条数之后，在判断所述寻呼消息条数是否大于第一设定阈值之前，判定所述寻呼消息条数小于所述当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
11.如权利要求10所述的装置，其特征在于，所述第一处理单元，还用于: 在判定所述寻呼消息条数大于或等于所述当前检测周期内能够发送的最大寻呼条数时，丢弃所述寻呼消息，其中，丢弃的寻呼消息不进行累计。
12.如权利要求9所述的装置，其特征在于，所述第二处理单元，还用于: 在判定所述寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。
13.如权利要求12所述的装置，其特征在于，所述第二处理单元，还用于: 判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定所述寻呼消息的寻呼类型为指定寻呼类型时，再发送所述寻呼消息。
14.如权利要求9一 13任一项所述的装置，其特征在于，所述第二处理单元，还用于: 在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，在确定所述寻呼消息的寻呼类型不为指定寻呼类型时，丢弃所述寻呼消息，丢弃的寻呼消息不进行累计。
15.如权利要求9一 13任一项所述的装置，其特征在于，所述第二处理单元，还用于: 在确定所述寻呼消息的寻呼类型为指定寻呼类型之后，在发送所述寻呼消息之前，判断所述寻呼消息不为重发寻呼消息时，初步确定能够发送所述寻呼消息。
16.如权利要求15所述的装置，其特征在于，所述第二处理单元，还用于: 确定所述寻呼消息为重发寻呼消息时，丢弃所述寻呼消息，其中，丢弃的寻呼消息不进行累计。
17.一种异常情况下的寻呼控制装置，其特征在于，该装置包括: 处理器，用于在设定的检测周期内，每次对UE发送寻呼消息之前，获取在所述检测周期内累计的寻呼消息条数，并判断所述寻呼消息条数是否大于第一设定阈值；在判定所述寻呼消息条数大于第 一设定阈值时，进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值，若是，则发送所述寻呼消息，否则，在确定所述寻呼消息的寻呼类型为指定寻呼类型时，再发送所述寻呼消息；或者，在判定所述寻呼消息条数小于或等于第一设定阈值时，发送所述寻呼消息。
18.如权利要求17所述的装置，其特征在于，所述处理器，还用于: 在获取在当前检测周期内累计的寻呼消息条数之后，在判断所述寻呼消息条数是否大于第一设定阈值之前，判定所述寻呼消息条数小于所述当前检测周期内能够发送的最大寻呼条数时，确定执行后续判断操作。
19.如权利要求18所述的装置，其特征在于，所述处理器，还用于: 在判定所述寻呼消息条数大于或等于所述当前检测周期内能够发送的最大寻呼条数时，丢弃所述寻呼消息，其中，丢弃的寻呼消息不进行累计。
20.如权利要求17所述的装置，其特征在于，所述处理器，还用于: 在判定所述寻呼消息条数大于第一设定阈值后，在进一步判断当前待发送的寻呼消息所针对的UE的优先级是否达到第二设定阈值之前，判定当前寻呼由创建承载过程触发或者由发送下行数据触发时，确定执行后续判断操作。
21.如权利要求20所述的装置，其特征在于，所述处理器，还用于: 判定当前寻呼不是由创建承载过程触发或者由发送下行数据触发时，在进一步确定所述寻呼消息的寻呼类型为指定寻呼类型时，再发送所述寻呼消息。
22.如权利要求17- 21任一项所述的装置，其特征在于，所述处理器，还用于: 在确定当前待发送的寻呼消息所针对的UE的优先级未达到第二设定阈值之后，在确定所述寻呼消息的寻呼类型不为指定寻呼类型时，丢弃所述寻呼消息，丢弃的寻呼消息不进行累计。
23.如权利要求17- 21任一项所述的装置，其特征在于，所述处理器，还用于: 在确定所述寻呼消息的寻呼类型为指定寻呼类型之后，在发送所述寻呼消息之前，判断所述寻呼消息不为重发寻呼消息时，初步确定能够发送所述寻呼消息。
24.如权利要求23所述的装置，其特征在于，所述处理器，还用于: 确定所述寻呼消息为重发寻呼消息时，丢弃所述寻呼消息，其中，丢弃的寻呼消息不进行累计。
【文档编号】H04W68/02GK103648165SQ201310747088
【公开日】2014年3月19日 申请日期:2013年12月30日 优先权日:2013年12月30日
【发明者】苏丽芳, 习建德 申请人:大唐移动通信设备有限公司