CN101203052A - 一种防范恶意业务请求的方法和设备 - Google Patents

Abstract

本发明公开了一种防范恶意业务请求的方法，包括如下步骤：网络侧根据用户标识对所收到业务请求所属于的用户进行区分，对于属于相同用户的业务请求的次数进行累计；若累计次数达到预先设置的阈值，则进行保护处理。本发明还公开了用于防范恶意业务请求的网元。本发明方案可以有效减少或弱化恶意业务请求对网络的冲击，增强网络的可靠性。

Description

一种防范恶意业务请求的方法和设备

技术领域

本发明涉及通信技术领域，特别涉及一种防范恶意业务请求的方法和设备。

背景技术

目前出现一些特殊的移动网终端设备，可以在极短的时间内发起大量的业务请求，如呼叫或者发送短消息等。一旦这种情况发生，就会对移动网络中各网元，特别是移动交换中心(MSC)造成比较大的话务冲击，加重核心网的网络负荷，严重时还会造成网络设备瘫痪等事故。

为便于描述，对于这种单用户在短时间内发起多个业务请求，业务请求的数目明显超出正常范围的情况，称为恶意业务请求(Malicious ServiceRequirement，MSR)，如果该MSR为呼叫则还可以称为恶意呼叫(MaliciousCall Attempt，MCA)，如果该MSR为短消息则称为恶意短消息(MaliciousShort Message，MSM)。

目前核心网存在一些流量控制机制，可以在核心网承担的总业务量过大时，采用某种策略对新到达核心网的业务进行部分或者全部限制，以保护核心网设备不过载，提高整个网络的可靠性。

发明人在技术研究中发现，现有技术虽然对于网络总业务量过大时可以提供有效的保护机制，但核心网一般不存在关联判断机制，能够判断出同一个用户在短时间内做了超乎寻常多的业务操作，而对该用户的业务请求进行限制；因此，现有技术存在如下缺陷：对于单个用户短时间内的异常多业务操作无法进行限制，有可能造成网络设备在总容量还允许的情况下，由于恶意业务请求而导致的局部拥塞或者过载。

发明内容

有鉴于此，本发明实施例提出一种防范恶意业务请求的方法，包括如下步骤：

网络侧根据用户标识对所收到业务请求所属于的用户进行区分，对于属于相同用户的业务请求的次数进行累计；

若累计次数达到预先设置的阈值，则进行保护处理。

本发明实施例还提出一种用于防范恶意业务请求的网元，包括：

用户区分单元，用于将具有相同用户标识的业务请求统计为同一个用户的业务请求；

累计模块，用于对用户发起的业务请求次数进行累计；

判断模块，用于判断所述累计模块的累计值是否达到预先设置的阈值，并输出判断结果；

保护处理模块，用于当所述判断模块的判断结果为是，则发送保护处理指示。

从以上技术方案可以看出，对用户单位时间内发起的业务请求次数进行累计，当累积值超过阈值则进行保护处理，可以有效减少或弱化恶意业务请求对网络的冲击，增强网络的可靠性。

附图说明

图1为本发明实施例一的由拜访位置寄存器指示MSC对来自一个移动终端的恶意呼叫请求进行处理的流程图；

图2为本发明实施例二由独立的恶意业务请求控制服务器对来自多个移动终端的恶意呼叫请求进行处理的流程图；

图3为本发明实施例三由HLR作为恶意业务请求控制服务器的处理流程图；

图4为本发明实施例四由SCP作为恶意业务请求控制服务器的处理流程图；

图5为本发明实施例五的恶意业务请求控制服务器的框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细阐述。

由于各种业务流程不尽相同，但针对本发明本身并没有原理上的巨大差异，本发明实施例方案以移动始发呼叫为例进行描述，但本发明技术方案同样适用于其他业务流程，如入局呼叫、汇接呼叫、短消息业务、以及其他各类业务请求等。

本发明所说的一个用户，可以是具有同一个移动用户ISDN号码(MobileSubscriber ISDN Number，MSISDN)、国际移动用户标识(International MobileSubscriber Identity，IMSI)或国际移动设备标识(International MobileEquipment Identity，IMEI)的一个或多个终端。其中，MSISDN与用户账户对应，IMSI与GSM用户标识(GSM Subscriber Identity Module，SIM)卡对应，IMEI与移动终端对应。一般情况下，MISSDN、IMSI和IMEI三者之间是唯一对应的，但在如下情况并不是唯一对应：

a、对于集团用户来说，同一个账户有多个子用户，每个用户各自拥有SIM卡，这些SIM卡放在不同的移动终端中。这样就导致一个MSISDN对应多个IMSI或IMEI。在本发明方案中，该集团用户具有相同的MSISDN，被认为是一个用户。

b、采用一号多卡技术，使得同一个账户用户(同样的MSISDN)可以拥有多个SIM卡。这些卡放在不同的移动终端中，可以在不同地点同时使用。

c、采用SIM克隆技术，使不同终端装载具有相同IMSI的SIM卡，这些终端具有相同的IMSI，在本发明方案中被认为是一个用户。

上面这三种情况的用户都可以认为是具有多个终端的用户。

d、有些移动终端可以装载多于一个的SIM卡，终端可以通过这些SIM卡同时发起业务，该终端虽然具有不同的IMSI，但具有同一个IMEI，因此也被认为是同一个用户。

本发明实施例一：

对于一个用户对应一个移动终端的情况，恶意业务请求的判断和保护控制主要由拜访位置寄存器(VLR)指示MSC完成。具体处理流程如图1所示，包括如下步骤：

步骤101：移动终端向MSC发起业务请求；

步骤102：MSC向VLR获取该移动终端的用户信息；

步骤103：VLR判断是否已启动对应于该用户的单位时长的定时器，如果未启动则启动该定时器；时长可以在VLR设置，用来规定“极短时间”的粒度。

步骤104：VLR对该用户的业务请求次数进行累计。可以分类累计，比如移动始发、短消息始发、业务登记等分别累计，分别累计便于分别进行恶意业务请求的处理，如果是分类累计，则所述单位时长的定时器应对应于具体的分类；也可以不分类累计，将该移动终端的所有业务请求的次数累加在一起。

步骤105：所述单位时间定时器超时，业务请求次数的累计值没有超过阈值，VLR将累计值清零，将单位定时器复位，按照正常的业务流程将用户信息提供给MSC，MSC执行后续操作。

步骤106：在单位定时器时段内的累计值超过预先在VLR设置的阈值，由VLR通知MSC按照预先设定的处理方式进行保护处理。所述阈值可以设置为多级门限，每级门限对应相应的处理方式，超过了哪一级门限则采用与该门限对应的处理方式。

保护的处理方式可以包含但不限于如下一些：

(1)发出告警，指示出用户标识(如用户的MSISDN号码、IMSI等)，由运维人员进行干预，比如MSC提供指定用户闭锁或指定用户在某一时段内闭锁等功能，供运维人员判断后执行；

(2)将相关应对措施事先由运维人员在MSC设置好并自动执行，如指示MSC闭锁所述用户或在一段时间内闭锁该用户。

(3)指示MSC基于该用户进行流量控制，限制用户在规定的单位时间段内的最大业务请求次数。此流控机制可以为只有单一门限，到达门限就立即禁止在单位时间段内该用户的所有后续业务请求，或后续同类的呼叫请求(比如呼叫类，或者短消息)；也可以做成多级门限，每级门限对应特定的百分比，根据该用户的业务请求累积值所达到的门限，采取该门限所对应的百分比限呼，最高门限为100％限呼。

(4对此类呼叫仍然放行，但在该用户的话单中增加恶意呼叫记录，可以由运营商事后对该恶意呼叫收取高额费用。

以上几种措施可以单独或组合使用。

本发明实施例二

对于具有多个移动终端的用户，可能存在多个终端从不同的VLR管辖区域内发起业务请求，这时，由单VLR进行恶意业务请求的判断和控制就不适用了。此时需要在移动网络新增网元或者借助已有的其他网元，比如位置归属寄存器(HLR)或业务控制点(SCP)，来完成恶意业务请求的判断和保护控制。

在本实施例中，恶意业务请求控制服务器(Malicious Service RequirementControlling Database，MSRC-DB)作为一个独立网元存在于核心网络中，用来完成具有多个移动终端的用户在不同VLR管辖区域内发起恶意业务请求时的流量控制。网内多个MSC/VLR可以访问同一个MSRC-DB。

本实施例的处理流程如图2所示，包括如下步骤：

步骤201：移动终端向MSC发起业务请求；

步骤202：MSC向VLR获取该移动终端的用户信息；

步骤203：VLR向MSRC-DB发送恶意呼叫控制请求(MSRC)。

在该步骤中，VLR可以首先根据该移动终端的用户信息判断该用户是否为多终端用户，若是，则向MSRC-DB发送恶意呼叫控制请求；如果该用户不是多终端用户，则按照图1所示流程，由VLR进行恶意呼叫控制。

步骤204：MSRC-DB判断是否已启动对应于该用户的单位时长的定时器，如果未启动则启动该定时器；时长可以在MSRC-DB设置，用来规定“极短时间”的粒度。在单位定时器的时长范围内，MSRC-DB对该用户的业务请求次数进行累计。所述累计包括：将按照不同的业务分别累计和/或各种类型的业务请求一起累计；对该用户的各个终端分别累计和/或对该用户总的业务请求次数进行累计。

步骤205：所述单位时间定时器超时，业务请求次数的累计值没有超过阈值，则认为当前业务请求不是恶意业务请求，MSRC-DB将累计值清零，以及将单位定时器复位，向VLR返回MSRC响应，指示VLR进行正常的业务流程，则VLR将用户信息提供给MSC，MSC执行后续操作。

步骤206：所述单位时间定时器超时前，业务请求次数的累积值超过阈值，则认为当前业务请求是恶意业务请求，MSRC-DB将累计值清零，以及将单位定时器复位，向VLR返回MSRC响应，该响应中包含恶意业务请求标识和相关的处理信息。

VLR向MSC提供用户信息，并将恶意业务请求标识和相关处理信息一同发送给MSC。

则MSC根据处理信息的指示，进行相关的限呼、告警、话统和话单处理等保护处理。

图2中MSRC-DB是跟VLR直接交互，并将相关信息通过VLR传递给MSC。实际上，也可以由VLR指示MSC直接访问MSRC-DB，再由MSC直接跟MSRC-DB交互。

考虑到有可能一个MSRC-DB容量不够支持本网内所有的跨VLR的MSR控制，也可以在网内设置多个MSRC-DB，这些MSRC-DB之间可以进行互查。具体地说，可以将一个MSRC-DB作为主MSRC-DB，其它MSRC-DB作为从MSRC-DB，从MSRC-DB将自身统计的业务请求累计次数与相应的用户信息发送至主MSRC-DB，主MSRC-DB判断是否由来自不同MSRC-DB的业务请求累计次数属于相同的用户，若是，将该用户的业务请求累计次数求总和，根据该总和判断该用户的业务请求是否为恶意业务请求，具体判断方法与前面实施例所述相同，故不再赘述。

在本实施例中，MSRC-DB是作为一个新增网元出现的，本文并未严格限定MSC/VLR跟MSRC-DB之间的查询接口和消息。实施例一也可以被看作实施例二的一个特例：即将MSRC-DB设置在VLR中。

本发明实施例三

在本实施例中，HLR兼做MSRC-DB，完成恶意业务请求控制功能。如图3所示，本实施例的流程和实施例二中基本相同，只是VLR在判断出要向MSRC-DB发送MSRC请求时，可以借用现有的位置更新流程，向HLR发起位置更新请求，其中增加扩展参数表明当前位置更新是为了进行恶意业务请求控制而发起的，由HLR在位置更新响应中给出MSR判断和处理信息。

或者，也可以在VLR和HLR之间扩充新的消息，这个在本发明中不做限制。

本发明实施例四

在本实施例中，SCP兼做MSRC-DB，完成恶意业务请求控制功能。流程如图4所示，包括如下步骤：

步骤401：移动终端向MSC发起业务请求；

步骤402：MSC向VLR获取该移动终端的用户信息；

步骤403：VLR判断当前用户是多终端用户，或者需要对该用户进行恶意呼叫请求的判断，则向MSC返回用户信息，并携带MSRC请求指示。

步骤404：MSC向SCP发送初始检测点(Initial Detect Point，IDP)消息，该消息中携带MSRC请求。

步骤405：SCP中的MSRC-DB功能实体判断是否已启动对应于该用户的单位时长的定时器，如果未启动则启动该定时器；时长可以在MSRC-DB实体设置，用来规定“极短时间”的粒度。在单位定时器的时长范围内，MSRC-DB实体对该用户的业务请求次数进行累计。所述累计包括：将按照不同的业务分别累计和/或各种类型的业务请求一起累计；对该用户的各个终端分别累计和/或对该用户总的业务请求次数进行累计。

步骤406：所述单位时间定时器超时，业务请求次数的累计值没有超过阈值，则认为当前业务请求不是恶意业务请求，MSRC-DB实体将累计值清零，以及将单位定时器复位，SCP向MSC返回事务处理结束(TC-END)以及MSRC响应，指示MSC进行正常的业务流程，MSC执行后续操作。

步骤407：所述单位时间定时器超时前，业务请求次数的累积值超过阈值，则认为当前业务请求是恶意业务请求，MSRC-DB实体将累计值清零，以及将单位定时器复位，SCP向MSC发送提供计费信息(Furnish ChargingInformation，FCI)消息，该消息中携带要求MSC填写到话单中的恶意呼叫请求信息，SCP并向MSC发送释放呼叫(Release Call)的指示。MSC根据指示进行限呼、告警、话统和话单处理的保护操作。

本实施例流程和实施例二中基本相同，只是VLR在判断出要向MSRC-DB发送MSRC请求时，指示MSC向SCP发起MSRC请求。可以借用现有的智能触发流程，向SCP发起智能业务请求其中采用特殊业务键表明当前的智能触发是为了进行恶意业务请求控制而发起的，由SCP在后续响应消息中给出MSR判断和处理信息。或者，也可以在MSC和SCP之间扩充新的消息，这个在本发明中不做限制。

以上所述实施例仅以呼叫业务请求的处理流程为例，对于其它业务请求，涉及的处理网元可能与上述流程不同，但本领域技术人员可以依照上述实施例的精神，由该流程中涉及的网元担当MSRC-DB，或者设置新的网元作为MSRC-DB进行恶意业务请求控制。例如，对于汇接呼叫，交换机可以根据入局的呼叫消息中携带的主叫用户号码来区分用户，进而对用户的业务请求进行统计。

本发明的方案也可以应用于其它类型的网络，例如在IP多媒体子系统(IMS)或者分组交换(PS)域使用此技术，原理和处理流程都基本一致，只是涉及的网元名称不同，故不再一一列举。

本发明实施例五提出一种恶意业务请求控制服务器，如图5所示，包括：

累计模块510，用于对用户在预先设置的单位时间内发起的业务请求次数进行累计。

判断模块520，用于判断所述累计模块510的累计值是否达到预先设置的阈值，并输出判断结果；

保护处理模块530，用于当所述判断模块520的判断结果为是，则发送保护处理指示。

所述累计模块510包括：

用户区分单元511，用于将具有相同MSISDN、IMSI或IMEI的业务请求作为同一个用户的业务请求；

单位时间计时单元512，用于对同一个用户的首个业务请求启动单位时间定时器；

业务请求累计单元513，用于对所述用户区分单元得到的同一个用户的业务请求次数进行累计，当所述单位时间定时器超时，则将累积值输出值所述判断模块520。

该恶意业务请求控制服务器可以位于VLR、HLR、SCP或其它网元中，也可以是单独的网络设备。

本发明方案提供了一种防范恶意业务请求的保护机制，减少或弱化了恶意业务请求对网络的冲击，提供了灵活的应对策略，增强网络的可靠性。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种防范恶意业务请求的方法，其特征在于，包括如下步骤：

网络侧根据用户标识对所收到业务请求所属于的用户进行区分，对于属于相同用户的业务请求的次数进行累计；

若累计次数达到预先设置的阈值，则进行保护处理。

2.根据权利要求1所述的方法，其特征在于，所述根据用户标识对所收到业务请求所属于的用户进行区分包括：将包含相同移动用户ISDN号码MSISDN、国际移动用户标识IMSI或国际移动设备标识IMEI的业务请求统计为同一个用户的业务请求。

3.根据权利要求1所述的方法，其特征在于，所述对于属于相同用户的业务请求的次数进行累计为在单位时间内对于属于相同用户的业务请求的次数进行累计，包括：

网络侧收到用户的业务请求，判断是否启动对应于所述用户的单位时间定时器，若未启动，则启动该单位时间定时器；若已启动，则对所述用户的业务请求次数进行累计；

所述单位时间定时器超时前，业务请求次数的累计值超过预先设置的阈值，则进行保护处理。

4.根据权利要求1所述的方法，其特征在于，所述业务请求包括呼叫请求和/或短消息业务请求。

5.根据权利要求1所述的方法，其特征在于，所述对于属于相同用户的业务请求的次数进行累计包括：对属于相同用户的每个类别的业务请求分别进行累计，或对属于相同用户的所有类别的业务请求进行累计。

6.根据权利要求1所述的方法，其特征在于，所述对于属于相同用户的业务请求的次数进行累计包括：

在多个网元上分别累计用户的业务请求次数；

判断在不同网元上的业务请求次数对应的用户信息是否相同，若是，则对这些业务请求次数求和，作为所述用户信息对应的用户的业务请求次数。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述保护处理包括如下方式的任意组合：

发出告警，并指示所述用户的标识；

闭锁所述用户或在预设的时段内闭锁所述用户；

对所述用户进行流量限制；

在所述用户的话单内增加恶意呼叫记录。

8.根据权利要求7所述的方法，其特征在于，所述阈值为多级门限，每级门限对应相应的保护处理方式；

所述进行保护处理包括：若所述累计次数超过了哪一级门限，则启用所述门限对应的保护处理方式。

9.一种用于防范恶意业务请求的网元，其特征在于，包括：

用户区分单元，用于将具有相同用户标识的业务请求统计为同一个用户的业务请求；

累计模块，用于对用户发起的业务请求次数进行累计；

判断模块，用于判断所述累计模块的累计值是否达到预先设置的阈值，并输出判断结果；

保护处理模块，用于当所述判断模块的判断结果为是，则发送保护处理指示。

10.根据权利要求9所述的网元，其特征在于，所述累计模块包括：

单位时间计时单元，用于对同一个用户的首个业务请求启动单位时间定时器；

业务请求累计单元，用于对所述用户区分单元得到的同一个用户的业务请求次数进行累计，当所述单位时间定时器超时，则将累积值输出值所述判断模块。

11.根据权利要求9或10所述的网元，其特征在于，所述网元设置于拜访位置寄存器或移动交换中心。

12.根据权利要求9或10所述的网元，其特征在于，所述网元设置于归属位置寄存器或业务控制点，所述归属位置寄存器或业务控制点通过扩展接口接收来自移动交换中心/拜访位置寄存器的恶意业务请求控制请求，所述累计模块根据收到的恶意业务请求控制请求对用户发起的业务请求次数进行累计。

Images