CN101635884B - 短号业务的实现方法、设备及系统 - Google Patents

Abstract

本发明公开了一种短号业务的实现方法，该方法包括：短号业务平台接收对被叫号码的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示端局进行呼叫接续；若否，则直接指示端局进行呼叫接续。本发明同时公开一种短号业务平台、短号业务系统。采用本发明可以简化业务处理流程，降低系统消耗。

Description

短号业务的实现方法、设备及系统

技术领域

本发明涉及通信技术领域，尤其涉及短号业务的实现方法、设备及系统。

背景技术

短号业务依靠短号拨打功能、短号显示功能和集团内通话优惠功能深受集团客户的喜爱。现网运营商都是通过VPMN(Virtual Private Mobile Network，移动虚拟专用网业务)业务架构来实现短号业务。现有VPMN业务实现方案通过将计费处理功能和呼叫控制功能集成在独立的SCP(Service Control Point，业务控制点)平台，来实现用户的短号功能和通话优惠功能。

如图1所示，现有VPMN业务处理流程如下：

步骤101、获得当前呼叫的漫游标志、呼叫类型、呼叫区域。其中，呼叫区域用于指示当前呼叫为市话、省内长途、国内长途、或国际长途；漫游标志用于指示当前呼叫为未漫游、省内漫游、省际漫游、或国际漫游；呼叫类型用于指示当前呼叫为网内、网间、网外号码组、或网外呼叫。

步骤102、判断成员权限是否满足呼叫区域及漫游区域，若超出权限，则执行步骤103，若满足权限，则执行步骤106。

步骤103、进行超出权限的处理，此时有两种处理方式，可以终止呼叫，即执行步骤104，也可以转个人付费，即执行步骤105。

步骤104、终止呼叫。

步骤105、转个人付费，设置个人付费标志，继续步骤106。

步骤106、判断集团权限是否满足呼叫类型及漫游区域，若超出权限，则执行步骤107，若满足权限，则执行步骤110。

步骤107、判断被叫号码是否为短号，若被叫号码为短号，则执行步骤108；若被叫号码为长号，则执行步骤109。

步骤108、终止呼叫。

步骤109、进行普通GSM(Global System for Mobile Communications，全球移动通信系统)呼叫。

步骤110、判断个人付费标志是否已设置，若是，则执行步骤111，若否，则执行步骤114。

步骤111、判断个人付费呼叫是否有优惠，若无优惠，则返回步骤107，若有优惠，则执行步骤112。

步骤112、进行长短号翻译，并接续呼叫。

步骤113、复杂计费矩阵计费。

步骤114、判断成员该呼叫类型是集团付费还是个人付费。

步骤115、进行长短号翻译，确定付费类型，若为个人付费，则执行步骤116，若为集团付费，则执行步骤117。

步骤116、设置个人付费标志，返回步骤111。

步骤117、接续呼叫。

步骤118、复杂计费矩阵计费。

发明人经过分析，发现随着计算机技术的发展和短号业务用户数的激增，VPMN业务技术实现方案存在如下不足，给业务的发展带来障碍：

一、用户计费账户重复存在。在计费部门系统和网络部门系统，用户账号同时存在，并行处理用户计费请求，对于每个用户需双倍业务支撑，业务容量被过度挥霍。且对于边际漫游优惠等业务需求，需计费部门系统、网络部门系统重复处理，业务处理能力被浪费。

二、VPMN业务系统复杂的维护需要。为支持每用户业务处理需求，VPMN系统增加了一系列的业务支撑平台，如SMP(Service Management Point，业务管理点)、话单接口机等等。复杂的系统维护需要，给业务安全运行，带来了不小的难度。且VPMN业务平台多为小型机架构，小型机的使用年限、故障处理、维护保养等方面存在诸多困难。因此，每用户的业务开销相对较高。

三、VPMN业务技术方案流程过于复杂。由于VPMN业务技术方案有多种业务权限控制，流程复杂，市场层面理解难度较大，因此短号业务的推广，实际全部集中在话费优惠功能和短号功能两大功能上。但恰恰是VPMN业务中复杂权限控制功能构成了业务处理的沉重包袱，造成每用户的业务消耗虚高。

四、业务处理能力浪费。网络部门的VPMN业务平台，集合了呼叫控制和计费处理功能。相对于BOSS(Business&Operation Support System，业务支撑系统)强大和成熟的计费处理功能，对每用户的计费处理消耗，VPMN业务平台存在劣势，在增加了负荷的同时，降低了整体的业务处理能力。

五、端局信令支撑能力的严重消耗。为实现计费功能，VPMN业务技术方案的信令流程中增加了许多计费相关信令，使得整个信令流程异常臃肿复杂，VPMN业务的信令负荷也一直居高不下，严重影响了网络的安全运行，降低了业务平台可承载的用户数。

六、僵硬的业务捆绑需求。VPMN业务实现方案中，短号功能与话费优惠进行了一定程度的捆绑，业务推广无法剥离短号功能和话费优惠功能之间的裙带关系，业务发展受到诸多限制。大部分的VPMN业务集团，短号功能的使用范围、使用频次非常有限，许多无需短号功能的集团用户绑定了短号功能，对整个业务系统是一种很大的浪费。

发明内容

本发明实施例提供一种短号业务的实现方法，用以简化业务处理流程，降低系统消耗，该方法包括：

短号业务平台接收对被叫号码的呼叫，判断被叫号码是否为短号，所述短号业务平台属于叠加在核心网之上的独立业务实现平台；

若是，则在对被叫号码进行长短号翻译处理后，指示端局进行呼叫接续；

若否，则直接指示端局进行呼叫接续。

本发明实施例还提供一种短号业务的实现方法，用以简化业务处理流程，降低系统消耗，该方法包括：

短号业务平台接收对被叫号码的呼叫，对主叫长号进行长短号翻译处理，所述短号业务平台属于叠加在核心网之上的独立业务实现平台；

在翻译成功时，按翻译后的短号指示端局进行呼叫接续；

在翻译失败时，直接指示端局进行呼叫接续。

本发明实施例还提供一种短号业务的实现方法，用以简化业务处理流程，降低系统消耗，该方法包括：

短号业务平台接收对主叫端局触发的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；若否，则直接指示主叫端局进行呼叫接续，所述短号业务平台属于叠加在核心网之上的独立业务实现平台；

短号业务平台接收对被叫端局触发的所述呼叫，对主叫长号进行长短号翻译处理；在翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续；由端局产生所述短号业务的话单并传送给业务支撑系统；业务支撑系统按群组中的长短号对应关系，将话单中的短号翻译为对应的长号；按用户群组信息，确定被叫长号与主叫长号是否在同一群组；业务支撑系统按所述确定结果进行批价处理，生成用户账单。

本发明实施例还提供一种短号业务平台，用以简化业务处理流程，降低系统消耗，包括：

接收模块，用于接收对被叫号码的呼叫；

判断模块，用于判断被叫号码是否为短号；

第一处理模块，用于在被叫号码为短号时，在对被叫号码进行长短号翻译处理后，指示端局进行呼叫接续；在被叫号码为长号时，直接指示端局进行呼叫接续。

本发明实施例还提供一种短号业务平台，用以简化业务处理流程，降低系统消耗，包括：

接收模块，用于接收主叫端局触发的呼叫及被叫端局触发的呼叫；

判断模块，用于判断主叫端局触发的呼叫中被叫号码是否为短号；

第一处理模块，用于在被叫号码为短号时，在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；在被叫号码为长号时，直接指示主叫端局进行呼叫接续；

翻译模块，用于对被叫端局触发的呼叫中的主叫长号进行长短号翻译处理；

第二处理模块，用于在对所述主叫长号翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续。

本发明实施例还提供一种短号业务系统，用以简化业务处理流程，降低系统消耗，包括：

短号业务平台，用于：

接收主叫端局触发的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；若否，则直接指示主叫端局进行呼叫接续；

接收被叫端局触发的所述呼叫，对主叫长号进行长短号翻译处理；在翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续；

主叫端局，用于：

将呼叫触发至短号业务平台；按短号业务平台的指示，进行呼叫接续；被叫端局，用于：

将呼叫触发至短号业务平台；按短号业务平台的指示，进行呼叫接续。

本发明实施例中，短号业务平台接收对被叫号码的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示端局进行呼叫接续；若否，则直接指示端局进行呼叫接续，与现有VPMN业务无论被叫号码是否为短号，都要进行长短号翻译处理流程相比，大大缩短了业务处理流程；同时，由于计费功能的剥离，短号业务平台无需再进行计费相关功能的实现，而是交由业务支撑系统进行计费，很大程度上减轻了系统消耗。

本发明实施例中，短号业务平台接收对被叫号码的呼叫，对主叫长号进行长短号翻译处理；在翻译成功时，按翻译后的短号指示端局进行呼叫接续；在翻译失败时，直接指示端局进行呼叫接续，由于计费功能的剥离，在被叫流程只实现在被叫手机上显示主叫短号的功能，也大大降低了系统消耗。

附图说明

图1为背景技术中现有VPMN业务处理流程图；

图2为本发明实施例中INT业务系统的示意图；

图3为本发明实施例中主叫处理流程图；

图4为本发明实施例中被叫处理流程图；

图5为本发明实施例中普通呼叫流程图；

图6为本发明实施例中INT业务网内短号呼叫流程图；

图7为本发明实施例中INT业务网内长号呼叫流程图；

图8为本发明实施例中INT业务话单处理流程图；

图9、图10、图11为本发明实施例中短号业务平台的结构图；

图12为本发明实施例中短号业务系统的结构图。

具体实施方式

本发明实施例中，由短号业务系统(后称INT业务系统)实现同一群组用户之间短号功能和话单优惠功能。其中短号业务平台(后称INT业务平台)集中实现号码翻译功能，用户通话话单由端局统一产生，在BOSS系统实现话费优惠功能，最大限度融合了各自系统的技术优势。

本发明实施例中，短号业务(后称INT业务)用户按群组方式划分，同一群组用户之间相互拨打为网内呼叫，其余呼叫类型都划归为网外呼叫。INT业务用户的网内呼叫享受短号功能和话单优惠功能。

移动用户申请INT业务的流程如下：移动用户从BOSS平台申请INT业务后，营帐系统向INT业务系统传送用户在群组中的长短号对应关系和用户的群组信息(如群组编号、标识等)。INT业务系统将INT业务用户在群组中的长短号对应关系和群组信息存储在INT业务平台中，以便实现用户的长短号翻译功能。实施中，不同群组的INT业务用户的短号可以重复使用。短号的范围可以是61至69开头的6位号码。

本发明实施例中，INT业务的基本功能特征可以如下：

1、INT业务用户可以短号拨打同一群组的INT业务用户。

2、INT业务用户接听同一群组INT业务用户的来电时，手机显示主叫号码对应的群组短号。

3、INT业务用户拨打同一群组用户享受话费优惠。

如图2所示，在INT业务系统中，INT业务平台通过信令转接点(SignalingTransfer Point，STP)和端局相连接，依赖7号信令系统完成呼叫信息的上报和处理。由此可见，INT业务平台属于叠加在核心网之上的独立业务实现平台，依靠独立业务平台实现短号业务，能够增强业务延展性、适应性和可持续发展性。该业务的部署将不再需要核心网设备的改造和支持，业务的扩容和业务的多样性发展也易于实现。

本发明实施例中，INT业务平台实现号码翻译的功能。INT业务平台对拨打短号的网内呼叫主叫流程、网内呼叫被叫流程进行号码翻译，分别实现被叫短号翻译成长号的功能和主叫号码短号显示功能。同时，INT业务平台对网外呼叫和拨打长号的网内呼叫主叫流程直接下发continue消息，指示端局进行呼叫接续。同时，INT业务平台也不再产生用户话单。

主叫处理流程中，短号业务平台接收对被叫号码的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示端局进行呼叫接续；若否，则直接指示端局进行呼叫接续。

如图3所示，一个实施例中，主叫处理流程如下：

步骤301、短号业务平台接收对被叫号码的呼叫，判断被叫号码是否为短号(如6位短号)，若是，则执行步骤302，否则执行步骤305。

步骤302、短号业务平台对被叫号码进行长短号翻译处理。

实施中，可以先根据端局上报的主叫号码，查询主叫号码所属群组的群组号，再根据被叫短号和查询到的主叫号码所属的群组号，在INT业务用户表中查询群组中的长短号对应关系，将被叫短号翻译成对应的长号。长短号翻译成功，则执行步骤303，若翻译失败(未找到被叫短号对应的长号)，则执行步骤304。

步骤303、长短号翻译成功后，短号业务平台按翻译后的长号指示端局进行呼叫接续。INT业务平台向端局下发connect消息，connect消息中的destinationRoutingAddress参数填写为翻译后的用户长号号码，主叫流程处理结束。

步骤304、长短号翻译失败后，短号业务平台直接指示端局进行呼叫接续。INT业务平台向端局下发continue消息，端局接续呼叫，主叫流程处理结束。

步骤305、短号业务平台直接指示端局进行呼叫接续。INT业务平台向端局下发continue消息，让端局进行相应的呼叫接续。主叫流程处理结束。

可以看出，图3所示主叫流程中，若被叫号码是普通用户号码，INT业务平台不做长短号翻译处理。而由于现有VPMN业务逻辑需要实现计费功能，现有VPMN业务无论被叫号码是否为普通用户号码，都要进行号码查询和号码翻译流程。因此，比较而言，INT业务平台大大缩短了业务处理流程。同时，由于计费功能的剥离，INT业务平台不再需要进行计费相关功能的实现，很大程度上减轻了系统消耗。

被叫处理流程中，短号业务平台接收对被叫号码的呼叫，对主叫长号进行长短号翻译处理；在翻译成功时，按翻译后的短号指示端局进行呼叫接续；在翻译失败时，直接指示端局进行呼叫接续。

如图4所示，一个实施例中，被叫处理流程如下：

步骤401、短号业务平台接收对被叫号码的呼叫，对主叫长号进行长短号翻译处理。可以先根据端局上报的被叫号码，查询被叫号码所属群组的群组号，再根据主叫号码和查询得出的群组号，在INT业务用户表中查询群组中的长短号对应关系，将主叫号码翻译为对应的短号。长短号翻译成功，则执行步骤402，若翻译失败(未找到被叫短号对应的长号)，则执行步骤403。

步骤402、长短号翻译成功后，按翻译后的短号指示端局进行呼叫接续。INT业务平台向端局下发connect消息，connect消息中GenericNumber参数填写为翻译后的用户短号码。被叫流程处理结束。

步骤403、长短号翻译失败后，直接指示端局进行呼叫接续。INT业务平台向端局下发continue消息，端局接续呼叫。被叫流程处理结束。

可以看出，由于计费功能的剥离，图4所示INT业务被叫流程只实现被叫手机上显示主叫短号的功能，也大为降低了系统消耗。

通过对比图1、图3、图4可以看到，本发明实施例中INT业务处理流程得到很大简化，系统消耗得到大幅度降低。

对于INT业务用户网内呼叫，本发明实施例可以实现如下功能：

1、主叫流程中，若主叫用户拨打被叫长号，则INT不进行长短号翻译处理，直接下发continue消息接续呼叫。

2、主叫流程中，若主叫用户拨打被叫短号，则INT平台完成被叫短号翻译成对应长号的功能，下发connect消息接续呼叫。

3、被叫流程中，INT平台完成主叫长号翻译成对应短号的功能，下发connect消息接续呼叫。

对于网外呼叫和INT业务用户长号主叫，INT平台进入普通呼叫信令流程，平台不进行长短号翻译处理，直接下发continue消息接续呼叫。

本发明实施例中，向MSC(Mobile-Service Switching Center，移动业务交换中心)/SSP(Service Switching Point，业务交换点)发送的所有continue、connect信令，都是TC-END方式的contiue、connect信令，指示交换机接续呼叫并结束与SCP的对话。

下面将普通呼叫流程、本发明实施例的INT业务网内短号呼叫流程、长号呼叫流程进行对比：

如图5所示，普通呼叫流程如下：

步骤501、根据主叫或被叫签约消息，MSC/VLR(Visited Location Registor，访问位置寄存器)/SSP将呼叫触发至INT业务平台。

步骤502、INT业务平台直接下发continue消息，指示端局接续呼叫。

如图6所示，INT业务网内短号呼叫流程如下：

步骤601、MSCa/VLR/SSP收到呼叫，根据主叫的签约信息O-CSI触发到INT业务平台。

步骤602、INT业务平台将被叫短号翻译成被叫长号，下发connect消息，指示端局接续呼叫。

步骤603、MSCa/VLR/SSP根据INT业务平台返回的被叫真实号码，向HLR发送查询消息。

步骤604、HLR返回被叫号码的签约消息。

步骤605、MSCa/VLR/SSP根据被叫的签约信息T-CSI触发到INT业务平台。

步骤606、INT业务平台将主叫长号翻译成主叫短号，下发connect消息，指示端局接续呼叫，至此，完成了整个INT业务短号功能。

如图7所示，INT业务网内长号呼叫流程如下：

步骤701、MSCa/VLR/SSP收到呼叫，根据主叫的签约信息O-CSI触发到INT业务平台。

步骤702、由于端局上报的被叫号码为长号，INT业务平台直接下发continue消息，指示端局接续呼叫。

步骤703、MSCa/VLR/SSP根据INT业务平台返回的被叫真实号码，向HLR发送查询消息。

步骤704、HLR返回被叫号码的签约消息。

步骤705、MSCa/VLR/SSP根据被叫的签约信息T-CSI触发到INT业务平台。

步骤706、INT业务平台将主叫长号翻译成主叫短号，下发connect消息，指示端局接续呼叫，至此，完成了整个INT业务短号功能。

对比可见，由于计费功能的剥离，INT业务信令流程大为简化，INT业务平台完成号码翻译功能后，不再对呼叫的后续处理进行监控，使信令负荷相对于原有VPMN业务实现方案降低了70％以上，从而极大提高了INT业务平台呼叫负载能力。

本发明实施例中，主被叫在INT业务通话过程中的话单统一由主叫端局、被叫端局产生并传送给业务支撑系统进行批价处理及生成用户账单，INT业务平台不再产生话单。其中，网内呼叫主叫手机话单中被叫号码为用户拨号时的被叫号码，主叫号码为主叫用户真实号码；网内呼叫被叫手机话单中被叫号码为被叫用户真实号码，主叫号码统一为主叫用户短号。

本发明实施例中，BOSS根据INT业务定购关系，产生INT业务用户数据，即BOSS系统产生和存储INT业务用户在群组中的长短号对应关系和用户群组信息。BOSS在接收到端局产生的话单后处理该话单，在查询到主被叫长号在同一群组时，即进行相应的优惠批价。另外，由于短号业务使用的用户数较多，BOSS平台可以通过负荷分担的方式完成INT业务话单的融合处理。

如图8所示，INT业务话单处理流程如下：

步骤801、业务支撑系统接收主叫端局、被叫端局分别为主叫、被叫产生的话单，按群组中的长短号对应关系，将话单中的短号翻译为对应的长号。例如，网内呼叫主叫手机话单中被叫号码为用户拨号时的被叫号码，主叫号码为主叫用户真实号码，若话单中的被叫号码为短号，则在主叫号码所属群组中，将被叫短号翻译为对应的长号。一个实施例中，若翻译成功，则后续可认为主被叫长号在同一群组，若翻译失败，则后续可认为主被叫长号不在同一群组。

步骤802、业务支撑系统按用户群组信息，确定被叫长号与主叫长号是否在同一群组。

步骤803、业务支撑系统按上述确定结果进行批价处理，生成用户账单，若主被叫长号在同一群组，则进行批价优惠、生成用户账单，若主被叫长号不在同一群组，则不优惠。

基于同一发明构思，本发明实施例还提供一种短号业务平台，其结构如图9所示，可以包括：

接收模块901，用于接收对被叫号码的呼叫；

判断模块902，用于判断被叫号码是否为短号；

第一处理模块903，用于在被叫号码为短号时，在对被叫号码进行长短号翻译处理后，指示端局进行呼叫接续；在被叫号码为长号时，直接指示端局进行呼叫接续。

一个实施例中，第一处理模块903包括：

第一查询子模块，用于在被叫号码为短号时，根据端局上报的主叫号码，查询主叫号码所属群组的群组号；

第一翻译子模块，用于根据被叫号码和查询到的主叫号码所属群组的群组号，查询群组中的长短号对应关系，将被叫号码翻译为对应的长号，并将翻译后的被叫长号传送给第一接续子模块；

第一接续子模块，用于基于翻译后的被叫长号指示端局进行呼叫接续处理；以及在被叫号码为长号时，直接指示端局进行呼叫接续。

基于同一发明构思，本发明实施例还提供一种短号业务平台，其结构如图10所示，可以包括：

接收模块1001，用于接收对被叫号码的呼叫；

翻译模块1002，用于对主叫长号进行长短号翻译处理；

第二处理模块1003，用于在翻译成功时，按翻译后的短号指示端局进行呼叫接续；在翻译失败时，直接指示端局进行呼叫接续。

一个实施例中，翻译模块1002包括：

第二查询子模块，用于根据端局上报的被叫号码，查询被叫号码所属群组的群组号；

第二翻译子模块，用于根据主叫号码和查询到的被叫号码所属群组的群组号，查询群组中的长短号对应关系，将主叫号码翻译为对应的短号。

基于同一发明构思，本发明实施例还提供一种短号业务平台，其结构如图11所示，可以包括：

接收模块1101，用于接收主叫端局触发的呼叫及被叫端局触发的呼叫；

判断模块1102，用于判断主叫端局触发的呼叫中被叫号码是否为短号；

第一处理模块1103，用于在被叫号码为短号时，在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；在被叫号码为长号时，直接指示主叫端局进行呼叫接续；其具体结构与上述第一处理模块903基本相同。

翻译模块1104，用于对被叫端局触发的呼叫中的主叫长号进行长短号翻译处理；其具体结构与上述翻译模块1002基本相同。

第二处理模块1105，用于在对主叫长号进行长短号翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续。

基于同一发明构思，本发明实施例还提供一种短号业务系统，其结构如图12所示，可以包括：

短号业务平台1201，用于：

接收主叫端局触发的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；若否，则直接指示主叫端局进行呼叫接续；

接收被叫端局触发的所述呼叫，对主叫长号进行长短号翻译处理；在翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续；

主叫端局1202，用于：

将呼叫触发至短号业务平台；按短号业务平台的指示，进行呼叫接续；

被叫端局1203，用于：

将呼叫触发至短号业务平台；按短号业务平台的指示，进行呼叫接续。

一个实施例中，短号业务平台1201结构与上述图11所述的短号业务平台结构相同，这里再进一步具体说明：

短号业务平台1201包括：

接收模块，用于接收主叫端局触发的呼叫及被叫端局触发的呼叫；

判断模块，用于判断主叫端局触发的呼叫中被叫号码是否为短号；

第一处理模块，用于在判断出所述被叫号码为短号时，根据主叫端局上报的主叫号码，查询主叫号码所属群组的群组号，根据被叫号码和查询到的主叫号码所属群组的群组号，查询群组中的长短号对应关系，将被叫号码翻译为对应的长号，并基于该被叫长号指示端局进行呼叫接续；在被叫号码为长号时，直接指示端局进行呼叫接续；

翻译模块，用于根据被叫端局触发呼叫中的被叫号码，查询被叫号码所属群组的群组号，并根据被叫端局触发呼叫中的主叫号码和查询到的被叫号码所属群组的群组号，查询群组中的长短号对应关系，将主叫号码翻译为对应的短号；

第二处理模块，用于在对所述主叫长号翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续。

一个实施例中，主叫端局1202、被叫端局1203还可以用于产生所述短号业务的话单并传送；该系统还可以包括业务支撑系统1204，用于接收主叫端局、被叫端局传送的话单，按群组中的长短号对应关系，将端局产生的话单中的短号翻译为对应的长号；按用户群组信息，确定被叫长号与主叫长号是否在同一群组；以及，按所述确定结果进行批价处理，生成用户账单。

本发明实施例中，实现呼叫控制和计费处理相分离，对业务功能进行细化、分层处理。短号业务平台只提供号码翻译功能，计费功能交由BOSS处理。从而简化信令流程、优化业务逻辑、增加用户容量、降低用户成本。

对比短号业务的现网实现版本——VPMN业务，可以得知，本发明实施例的有益效果如下：

一、由于业务逻辑被大幅度简化，每用户的系统消耗被大幅度降低，本发明实施例的INT业务实现方案下的用户容量相对于VPMN业务实现方案下的用户容量在同等硬件条件下大致有50％以上增加。

二、由于BOSS系统成熟的计费处理功能拥有巨大的优势，计费功能的迁移使短号业务实现成本大幅度降低，而且增加单个短号业务用户的边际成本也得到大幅降低。

三、INT业务信令负荷大幅度降低。由于计费功能的剥离，原短号业务中RRBE(Request Report BCSM Event)、AC(Apply Charging)、ACR(ApplyCharging Report)等信令已没有存在的价值，信令负荷可以有效降低60％，极大减轻了端局资源消耗。

四、灵活的市场营销手段。呼叫处理与计费功能相分离后，短号业务的发展已无需业务平台的全程参与。对于少部分人使用短号的大INT用户群组，在INT业务平台上只需保留少数频繁使用短号的用户，而整个用户群组的资费优惠在BOSS平台实现，这样，短号功能得到最大化使用、INT平台业务容量得到有效释放、端局智能业务压力减轻、用户资费优惠得到有效实现。

更进一步的，短号功能分离后，也完全可以将短号功能独立发展，或与其他业务品牌进行融合，通过附加功能费的方式更好、更快的收回短号业务的投资成本。

五、计费系统统一化。计费功能的迁移解决了计费系统在短号业务平台和BOSS平台重复投资的问题。而且，计费原则的改动也将无需智能网平台业务升级。由于呼叫控制与计费处理分离，原短号业务中未实现的省际漫游资费优惠、省际边界漫游等问题都能轻松实现，扩展了短号业务业务能力。

六、用户业务感知无影响。原短号业务的用户业务感知集中在短号功能和资费优惠功能两方面。INT业务平台有效承载了上述两大功能。短号业务实现手段的迁移不影响用户的任何业务感知。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

1.一种短号业务的实现方法，其特征在于，该方法包括：

短号业务平台接收对被叫号码的呼叫，对主叫长号进行长短号翻译处理，所述短号业务平台属于叠加在核心网之上的独立业务实现平台；

在翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；

在翻译失败时，直接指示被叫端局进行呼叫接续；

由端局产生所述短号业务的话单并传送给业务支撑系统；

业务支撑系统按群组中的长短号对应关系，将话单中的短号翻译为对应的长号；按用户群组信息，确定被叫长号与主叫长号是否在同一群组；

业务支撑系统按所述确定结果进行批价处理，生成用户账单。

2.如权利要求1所述的方法，其特征在于，所述对主叫长号进行长短号翻译处理包括：

根据被叫端局上报的被叫号码，查询被叫号码所属群组的群组号；

根据主叫号码和查询到的被叫号码所属群组的群组号，查询群组中的长短号对应关系，将主叫号码翻译为对应的短号。

3.一种短号业务的实现方法，其特征在于，该方法包括：

短号业务平台接收主叫端局触发的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；若否，则直接指示主叫端局进行呼叫接续，所述短号业务平台属于叠加在核心网之上的独立业务实现平台；

短号业务平台接收被叫端局触发的所述呼叫，对主叫长号进行长短号翻译处理；在翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续。

4.如权利要求3所述的方法，其特征在于，所述对被叫号码进行长短号翻译处理包括：

根据主叫端局上报的主叫号码，查询主叫号码所属群组的群组号；

根据被叫号码和查询到的主叫号码所属群组的群组号，查询群组中的长短号对应关系，将被叫号码翻译为对应的长号。

5.如权利要求3所述的方法，其特征在于，所述对主叫长号进行长短号翻译处理包括：

根据被叫端局上报的被叫号码，查询被叫号码所属群组的群组号；

根据主叫号码和查询到的被叫号码所属群组的群组号，查询群组中的长短号对应关系，将主叫号码翻译为对应的短号。

6.如权利要求3、4或5所述的方法，其特征在于，该方法进一步包括：

由主叫端局、被叫端局分别为主、被叫产生所述短号业务的话单并传送给业务支撑系统；

业务支撑系统按群组中的长短号对应关系，将话单中的短号翻译为对应的长号；按用户群组信息，确定被叫长号与主叫长号是否在同一群组；

业务支撑系统按所述确定结果进行批价处理，生成用户账单。

7.一种短号业务平台，其特征在于，包括：

接收模块，用于接收主叫端局触发的呼叫及被叫端局触发的呼叫；

判断模块，用于判断主叫端局触发的呼叫中被叫号码是否为短号；

第一处理模块，用于在被叫号码为短号时，在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；在被叫号码为长号时，直接指示主叫端局进行呼叫接续；

翻译模块，用于对被叫端局触发的呼叫中的主叫长号进行长短号翻译处理；

第二处理模块，用于在对所述主叫长号翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续。

8.如权利要求7所述的短号业务平台，其特征在于，所述第一处理模块包括：

第一查询子模块，用于在被叫号码为短号时，根据主叫端局上报的主叫号码，查询主叫号码所属群组的群组号；

第一翻译子模块，用于根据主叫端局上报的被叫号码和查询到的主叫号码所属群组的群组号，查询群组中的长短号对应关系，将被叫号码翻译为对应的长号，并将翻译后的被叫长号传送给第一接续子模块；

第一接续子模块，用于基于翻译后的被叫长号指示主叫端局进行呼叫接续处理；以及在被叫号码为长号时，直接指示主叫端局进行呼叫接续。

9.如权利要求7所述的短号业务平台，其特征在于，所述翻译模块包括：

第二查询子模块，用于根据被叫端局上报的被叫号码，查询被叫号码所属群组的群组号；

第二翻译子模块，用于根据被叫端局上报的主叫号码和查询到的被叫号码所属群组的群组号，查询群组中的长短号对应关系，将主叫号码翻译为对应的短号。

10.一种短号业务系统，其特征在于，包括：

短号业务平台，用于：

接收主叫端局触发的呼叫，判断被叫号码是否为短号；若是，则在对被叫号码进行长短号翻译处理后，指示主叫端局进行呼叫接续；若否，则直接指示主叫端局进行呼叫接续；

接收被叫端局触发的所述呼叫，对主叫长号进行长短号翻译处理；在翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续；

主叫端局，用于：

将呼叫触发至短号业务平台；按短号业务平台的指示，进行呼叫接续；

被叫端局，用于：

将呼叫触发至短号业务平台；按短号业务平台的指示，进行呼叫接续。

11.如权利要求10所述的系统，其特征在于，所述短号业务平台包括：

接收模块，用于接收主叫端局触发的呼叫及被叫端局触发的呼叫；

判断模块，用于判断主叫端局触发的呼叫中被叫号码是否为短号；

第一处理模块，用于在判断出所述被叫号码为短号时，根据主叫端局上报的主叫号码，查询主叫号码所属群组的群组号，根据被叫号码和查询到的主叫号码所属群组的群组号，查询群组中的长短号对应关系，将被叫号码翻译为对应的长号，并基于该被叫长号指示端局进行呼叫接续；在被叫号码为长号时，直接指示端局进行呼叫接续；

翻译模块，用于根据被叫端局触发呼叫中的被叫号码，查询被叫号码所属群组的群组号，并根据被叫端局触发呼叫中的主叫号码和查询到的被叫号码所属群组的群组号，查询群组中的长短号对应关系，将主叫号码翻译为对应的短号；

第二处理模块，用于在对所述主叫长号翻译成功时，按翻译后的短号指示被叫端局进行呼叫接续；在翻译失败时，直接指示被叫端局进行呼叫接续。

12.如权利要求10或11所述的系统，其特征在于，所述主叫端局进一步用于产生所述短号业务的主叫话单并传送；

所述被叫端局进一步用于产生所述短号业务的被叫话单并传送；

所述系统还包括：

业务支撑系统，用于接收主叫端局、被叫端局传送的话单，按群组中的长短号对应关系，将话单中的短号翻译为对应的长号；按用户群组信息，确定被叫长号与主叫长号是否在同一群组；以及，按所述确定结果进行批价处理，生成用户账单。

Images