CN101110878B - 一种预付费业务实现方法及预付费业务网元和网络 - Google Patents

Abstract

本发明公开了一种预付费业务实现方法及预付费业务网元和网络。包括：预付费业务网元根据用户发起呼叫请求为所述用户建立业务连接；预付费业务网元与计费平台进行所述用户的费用预扣；根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。本发明提出一种可以避免延长业务连接建立时延的预付费实现方法。这种预付费方法应用于各种预付费业务，由于用户的费用预扣与建立业务连接并行处理，使得用户业务建立的时延大为减小，可以忽略预付费流程对业务建立的影响，提高用户满意度。

Description

一种预付费业务实现方法及预付费业务网元和网络

技术领域

本发明涉及通信领域，尤其涉及一种预付费业务实现方法及预付费业务网元和网络。 

背景技术

随着通信技术的发展，传统的通信方式和业务得到了长足的发展，预付费业务成为较为常见的一种通信业务。如图1所示，在现有的预付费方案中，当App Server(应用服务器)收到通话/业务请求发起时，先从计费平台预扣费用，如果成功，App Server继续后续的业务逻辑，并进行业务费用监控；当前一次预扣的费用用完，就向计费平台确认扣费，同时再预扣一定费用；当计费平台上预付费帐号上费用用完，则导致预扣失败，此时App Server会切断业务。现有技术中，App Server可以是传统的智能网业务系统，典型业务有中国移动的神州行业务，中国联通的如意通业务，固网中的201等卡号业务。上述方案中的App Server也可以是软交换中心，负责呼叫业务的逻辑。 

下面以PoC(PTT over cellular，在蜂窝系统上实现的PTT)业务为例进行说明。 

PoC业务的概念来自于对讲机，其用户体验使用方式和对讲机类似——简单、快捷，半双工通话。用户通过预先设定通话群组，通话时无需拨号，按住特定的按键，就可以同时将话音传送给群组中其他所有的成员，按键即讲，呼叫和通话连接过程在瞬间完成。而接收方无需任何响应就能接听，通话过程采用半双工的方式，一方在说话时，其他成员只能接听不能说话。 

制定PoC标准规范的组织是OMA(Open Mobile Alliance，开放移动联盟)，该规范中定义的PoC网络示意如图2所示，是基于IMS(IP Multimedia System； IP多媒体子系统)的PoC网络(图中的“SIP/IP core”)结构，主要实体简介如下： 

PoC Server(PoC服务器)：是业务的主要呼叫控制设备，是IMS网络的一种Application Server(应用服务器)； 

PoC XDMS：存储PoC业务需要的群组信息等数据的服务器。 

PoC Client(PoC客户端)，用户使用该客户端和PoC Server发起、接收PoC呼叫、申请发言权、发言等。 

建立PoC Group Talk(群组呼叫)后，用户可以通过TBCP(Talk Burst ControlProtocol，发言控制协议)向PoC Server申请Floor(发言权)，只有获得发言权，用户才被准许说话，其说话产生的Talk Burst(媒体流)才能被PoC Server转发到群组的其他成员。 

作为一种电信业务，PoC也要求实现预付费和后付费等多种灵活的计费方式。 

图3描述了基于IMS的PoC网络架构。其中PoC服务器(PoC Server)是PoC业务的主要处理单元，功能包括：PoC会话处理功能、媒体分发功能、谈话权控制处理功能、用户平面的适配功能、不同编码协议的转换功能等。 

终端侧主要的部分是PoC Client，用来执行PoC的呼叫处理、媒体处理等。 

呈现服务器(Presence Server)的功能是接收并存储UE公布的呈现信息，并分发到PoC客户端。常见的呈现信息有“是否在线”、“免打扰”等。 

XML文件管理服务器(XDMS)用于管理PoC业务所需的群组和列表。提供PoC组信息的增加、修改、删除以及组的授权和控制等功能。在IMS网络架构中，Ut接口提供XDMS和UE之间的通信功能。 

由此可见，在实现预付费业务的时候，现有技术一般在业务服务器收到呼叫发起请求的时候，暂时挂起呼叫处理流程，先通过计费协议向计费平台进行费用预扣。以确保用户的账户余额能支付后续的业务使用，只有当计费平台返回响应的时候才继续呼叫流程的处理，因此会增加呼叫建立的时延。 

这种预付费流程能确保精确计费，保护运营商的利益，但是也存在一个明显的缺点，即会延长呼叫的建立时延，只有在计费平台返回响应的时候，呼叫流程继续处理。虽然该缺点对某些时延要求不高的电信业务而言影响可以忽略，但是对于像PoC这样对建立时延极其苛刻的业务，是不可接受的，会影响用户的感受。 

发明内容

本发明提供一种预付费业务的实现方法和预付费业务网元及网络，用以解决现有技术中存在的预付费方案带来时延过大的问题。 

本发明方法包括： 

一种预付费业务实现方法，包括： 

预付费业务网元根据用户发起呼叫请求为所述用户建立业务连接； 

所述预付费业务网元与计费平台进行所述用户的费用预扣； 

根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。 

所述预付费业务网元为所述用户建立业务连接的步骤与预付费业务网元与计费平台进行所述用户的费用预扣的步骤同时进行。 

所述的方法，如果所述用户费用预扣成功，则保持所述业务连接。 

所述的方法，如果所述用户费用预扣成功，保持所述业务连接后，还包括后续再次进行用户费用预扣的步骤。 

所述的方法，如果所述用户费用预扣成功，保持所述业务连接后，还包括预付费业务网元监视所述用户通话状态的步骤。 

所述的方法，如果所述用户费用预扣失败，则终止所述业务连接。 

所述预付费业务网元终止所述业务连接后，向所述用户返回终止业务连接原因。 

所述预付费业务网元终止所述业务连接后，向所述计费平台上报所述用户的欠费信息。 

所述的方法，当所述用户进行费用预存时，所述计费平台在所预存费用中，扣除所述欠费。 

所述预付费业务网元为应用服务器，或POC服务器，或呼叫处理单元，或交换中心，或智能网业务交换点。 

所述计费平台为智能网业务控制点。 

所述预付费业务网元与计费平台之间，所使用计费协议，为智能网计费协议信令或Radius/Diameter计费协议信令。 

本发明预付费业务网元包括： 

一种预付费业务网元，包括： 

业务连接建立单元，根据用户发起呼叫请求为所述用户建立业务连接； 

费用预扣单元，用于与所述计费平台进行所述用户的费用预扣； 

连接状态控制单元，根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。 

所述的预付费业务网元，还包括： 

连接控制单元，用于控制业务连接建立单元为所述用户建立业务连接和费用预扣单元与计费平台进行所述用户的费用预扣操作同时进行。 

所述的预付费业务网元，还包括： 

监视单元，用于监视所述用户通话状态。 

所述的预付费业务网元，还包括： 

终止业务连接原因发送单元，用于在用户费用预扣失败，终止所述业务连接时，向所述用户返回终止业务连接原因。 

所述的预付费业务网元，还包括： 

用户欠费信息上报单元，用于在终止所述业务连接后，向所述计费平台上报所述用户的欠费信息。 

本发明一种预付费业务网络包括： 

一种预付费业务网络，包括预付费业务网元和与其相连的计费系统，所述 预付费业务网元包括： 

业务连接建立单元，根据用户发起呼叫请求为所述用户建立业务连接； 

费用预扣单元，用于与所述计费平台进行所述用户的费用预扣； 

连接状态控制单元，根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。 

所述预付费业务网元还包括： 

连接控制单元，用于控制业务连接建立单元为所述用户建立业务连接和费用预扣单元与计费平台进行所述用户的费用预扣操作同时进行。 

所述预付费业务网元还包括： 

监视单元，用于监视所述用户通话状态。 

所述预付费业务网元还包括： 

终止业务连接原因发送单元，用于在用户费用预扣失败，终止所述业务连接时，向所述用户返回终止业务连接原因。 

所述预付费业务网元还包括： 

用户欠费信息上报单元，用于在终止所述业务连接后，向所述计费平台上报所述用户的欠费信息。 

本发明提出一种可以避免延长业务连接建立时延的预付费实现方法及预付费业务网元和预付费业务网络。这种预付费方案应用于各种预付费业务，由于用户的费用预扣与建立业务连接并行处理，使得用户业务建立的时延大为减小，可以忽略预付费流程对业务建立的影响，提高用户满意度。 

本发明提供的预付费方法也可以应用在其他的预付费解决方案中。例如原来的智能网预付费解决方案中，或者3G/NGN网络中软交换，IMS子系统的业务系统中。 

附图说明

图1为现有技术中预付费业务流程示意图； 

图2为现有技术中OMA PoC规范的网络结构示意图； 

图3为现有技术中PoC系统的网络结构示意图； 

图4为本发明方案预付费业务网络结构示意图； 

图5为本发明预付费业务网元结构示意图； 

图6为本发明预付费业务的流程示意图； 

图7为本发明方案预付费业务费用预扣成功的流程示意图； 

图8为本发明方案预付费业务费用预扣失败的流程示意图； 

图9为本发明方案预付费业务在PoC系统中应用，费用预扣成功的流程示意图； 

图10是本发明例3中解决用户恶意试呼的方案流程图； 

图11为本发明方案预付费业务在智能网中应用，费用预扣成功的流程示意图； 

图12为本发明方案预付费业务在智能网中应用，费用预扣失败的流程示意图。 

具体实施方式

下面结合说明书附图来说明本发明的具体实施方式。 

本发明提出一种可以避免延长业务连接建立时延的预付费实现方法，使业务连接的建立过程和费用预扣过程并发进行，即服务器在收到业务连接请求的时候，正常进行业务连接处理，建立业务连接；同时向计费平台进行费用预扣过程，如果计费平台返回用户帐户费用不足，则立即拆除业务连接，否则业务正常进行。这种方法在遇到用户余额不足的时候，可能会导致计费有少数损失，不过计费平台可以把不足的费用作为欠费记录下来，等用户账户充值后再扣除。这种预付费方法的应用，可以大大减小预付费过程对呼叫建立的影响，达到最佳效果。 

下面以呼叫业务连接建立过程为例进行说明，其他业务的方案与此类似处 理即可。 

如图4所示，是本发明预付费业务实现方法的网络结构示意图，从图中可见，主要包括： 

负责预付费业务用户呼叫处理的预付费业务网元100，负责处理呼叫业务逻辑，同时作为计费发起方根据其业务逻辑向计费平台发起扣费/预留等预付费请求。 

该预付费业务网元可以为各种应用服务器，典型的例如PoC服务器，传统的智能电信业务服务器，呼叫处理单元，交换中心，或智能网业务交换点等。 

负责对用户预付费进行管理的计费平台200，存放用户账户余额信息，并响应应用服务器进行预扣/预留等请求进行预扣/预留服务。用户可以通过一定的途径对其账户进行充值。该计费平台可以包含OCS(Online Charging System，在线计费系统)和/或CDF(Charging Data Function，计费话单功能实体)。OCS和CDF可以存在于PoC服务器或IMS系统的其他实体，例如S-CSCF或者P-CSCF中。 

上述预付费业务网元和计费平台之间为通过计费协议交互。计费协议可以是传统的智能网信令，也可以是Radius/Diameter等其他的计费协议信令。 

此外，上述预付费业务网元和计费平台之间可以是一种可信的关系，例如部署在运营商的同一个域内部，也可以通过一定的认证鉴权过程进行相互认证，此处不再赘述。 

如图5所示，是该预付费业务网络中，预付费业务网元100的结构示意图，从图中可见，其主要包括如下结构： 

业务连接建立单元101，根据用户发起呼叫请求为所述用户建立业务连接； 

费用预扣单元102，用于与所述计费平台进行所述用户的费用预扣； 

连接状态控制单元103，根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。 

进一步，该预付费业务网元100还包括： 

连接控制单元104，用于控制业务连接建立单元为所述用户建立业务连接和费用预扣单元与计费平台进行所述用户的费用预扣操作同时进行。 

监视单元105，用于监视所述用户通话状态。 

终止业务连接原因发送单元106，用于在用户费用预扣失败，终止所述业务连接时，向所述用户返回终止业务连接原因。 

用户欠费信息上报单元107，用于在终止所述业务连接后，向所述计费平台上报所述用户的欠费信息。 

如图6所示，是本发明方案的主流程图，从图中可见，主要包括以下步骤： 

S601、预付费业务网元根据用户发起呼叫请求为所述用户建立通话连接。 

当用户需要使用预付费业务时，其向负责付费业务用户呼叫处理的预付费业务网元发起呼叫请求，预付费业务网元根据所述呼叫请求，在第一时间内为所述用户建立通话连接，这样预付费用户就不必等待预付费业务网元与计费系统之间进行费用预扣等操作，直接由预付费业务网元建立起该用户的通话连接，使用户感受不到计费处理产生的时延。 

S602、预付费业务网元与计费平台进行所述用户的费用预扣。 

在预付费业务网元为所述用户建立通话连接的同时，预付费业务网元与计费平台进行所述用户的本次业务的费用预扣，预付费业务网元与计费平台的费用预扣过程以及采用的方案，可以参照现有技术的相关内容确定，在此不再赘述。 

S603、根据所述用户费用预扣结果，保持所述通话连接或者终止所述通话连接。 

根据S602的费用预扣结果，预付费业务网元决定是否保持对所述用户已经建立的通话连接。 

如果所述用户费用预扣成功，则保持所述通话连接。 

如果所述用户费用预扣失败，则终止所述通话连接，所述预付费业务网元终止所述通话连接后，向所述用户返回终止通话原因，并由预付费业务网元向 所述计费平台上报所述用户的欠费信息。 

上述方案中，如果所述用户费用预扣成功，保持所述通话连接后，还包括后续再次进行用户费用预扣的步骤。 

在用户费用预扣成功，保持所述通话连接后，预付费业务网元还要监视所述用户通话状态，如果用户通话状态发生了变化，预付费业务网元要依据所述的状态变化与计费平台及时确认所述用户的预付费使用情况，比如当用户结束本次预付费业务时，预付费业务网元要及时向计费平台发送费用确认，确认用户使用费用。 

上述方案中，由于预付费业务网元在接收到用户呼叫请求后，立即为所述用户建立通话连接，然后才与计费平台之间协商所述用户的费用预扣，这样如果费用预扣操作失败，则预付费业务网元已经为所述用户提供了一段时间的预付费业务，而这一段时间的预付费业务并没有被付费，针对该种情况，在用户费用预扣失败，预付费业务网元终止所述通话连接后，由预付费业务网元向所述用户返回终止通话原因，并由预付费业务网元向所述计费平台上报所述用户的欠费信息。当所述用户进行费用预存时，所述计费平台在所预存费用中，优先扣除所述欠费。 

下面结合具体的实例，来说明本发明的实现方式。 

例1、预付费业务网元为应用服务器，呼叫建立后费用成功预扣流程： 

如图7是呼叫建立的时候，用户余额充足，可以满足呼叫费用情况下的预付费流程，包括如下步骤： 

S701、用户向应用服务器发起一个呼叫请求。 

S702、应用服务器立即处理用户的呼叫请求，按照正常的后付费业务流程处理。同时启动另外一个并行任务，进行费用预扣的操作。 

S703、应用服务器根据业务的特点向计费平台发送费用预扣请求，比如“5分钟PoC业务费用”或者“0.8元”等。 

S704、计费平台进行费用预扣后，向应用服务器返回费用预扣成功的结果。 

S705、收到费用预扣成功的消息后，应用服务器不打断当前用户的正常业务，当前用户继续进行呼叫。 

S706、计费平台通过启动定时期等手段监视所述用户的业务使用量。 

S707、当一个计费周期结束，前一次预扣费用用完时，应用服务器向计费平台发送“上次费用确认和下次预扣请求”。 

S708、计费平台返回“费用确认和预扣”的成功应答。 

S709、计费平台监视到用户本次呼叫结束。 

S710、应用服务器向计费平台发送“上次费用确认(部分)”，通知计费平台最后的扣费周期中实际使用的费用。 

S711、计费平台返回“费用确认”的成功应答。 

S712、应用服务器根据计费情况生成CDR(Call Detail Record，详细呼叫记录)。 

S713、计费平台根据扣费情况生成CDR。 

上述流程中S706～S708步骤会根据呼叫时间长度不同重复多次。 

上述过程中，与一般预付费业务实现流程最大的区别在于，步骤S702中的呼叫处理正常进行，同时启动一个并行的预扣任务。即S703、S704两步与S702/S705两步是并行的，可以没有先后关系。S704与S706才存在顺序关系；这里呼叫处理和费用预扣是并行处理，不必等计费平台返回费用预扣结果；而在一般的预付费过程中呼叫处理和费用预扣是串行处理的，只有等到计费平台返回费用预扣结果的时候，才能根据费用预扣结果进行呼叫处理。 

例2、呼叫建立时预扣失败的处理流程： 

如图8是预付费业务网元为应用服务器，呼叫建立时首次费用预扣失败的预付费流程，从图中可见，包括以下步骤： 

S801、用户向应用服务器发起一个呼叫请求。 

S802、应用服务器立即处理用户的呼叫请求，按照正常的后付费业务流程处理，同时启动另外一个并行任务，进行费用预扣的操作。 

S803、应用服务器根据业务的特点向计费平台发送费用预扣请求，比如“5分钟PoC业务费用”或者“0.8元”等。 

S804、计费平台进行费用预扣，本实例中费用预扣失败，向应用服务器返回费用预扣失败的结果。此处的费用预扣失败原因很多，典型的是，用户余额不足，用户欠费，用户账户冻结等。 

S805、收到费用预扣失败的消息后，应用服务器中断当前用户的正常业务，向用户返回呼叫结束原因。 

S806、应用服务器向计费平台上报欠费信息，例如“1分钟PoC使用费用”，或者“0.18元”等。 

S807、计费平台保存该用户欠费信息后向应用服务器返回确认响应。 

S808、应用服务器根据计费情况生成CDR。 

S809、计费平台根据扣费情况生成CDR。 

在实例2的流程中，在应用服务器收到费用预扣失败的信息时，就启动呼叫结束流程。此处把费用预扣失败作为一个呼叫结束的触发原因，对原有的业务流程影响比较小。 

此外，费用预扣失败也可以发生在中间计费环节，处理过程与首次费用预扣失败基本相同。 

本发明方案还可以在多个网络环境下应用。 

例3、预付费在PoC业务中的应用流程： 

如图9所示，是本发明方案在PoC业务中的应用，实例3是预扣费用成功的流程，包括如下步骤： 

S901、用户向PoC务器发起一个呼叫请求。 

S902、PoC服务器立即处理用户的呼叫请求，按照正常的后付费业务流程 处理。同时启动另外一个并行任务，进行费用预留操作。 

S903、PoC服务器根据业务的特点向计费平台发送费用预扣请求。 

S904、计费平台进行费用预扣后，向PoC服务器返回费用预扣成功的结果。 

S905、收到费用预扣成功的消息后，PoC服务器不打断当前用户的正常业务，当前用户继续进行呼叫。 

S906、计费平台通过启动定时期等手段监视所述用户的业务使用量。 

S907、当一个计费周期结束，前一次预扣费用用完时，PoC服务器向计费平台发送“上次费用确认和下次预扣请求”。 

S908、计费平台返回费用预扣成功应答。 

S909、计费平台监视到用户本次呼叫结束。 

S910、PoC服务器向计费平台发送“上次费用确认(部分)”，通知计费平台最后的扣费周期中实际使用的费用。 

S911、计费平台返回“费用确认”的成功应答。 

S912、PoC服务器根据计费情况生成CDR。 

S913、计费平台根据扣费情况生成CDR。 

上述方案中，当用户余额不足的时候，由于PoC业务的特殊性，极端情况下有可能存在用户恶意多次试呼的情况，解决该问题可以采用如下方法。 

当UE向IMS注册的时候，SCFCF会从HSS得到该用户的余额信息。在该用户对应的iFC中设置如下的业务过滤规则：如果用户余额小于预定的门限值(该门限值可以由运营商设置)，则不允许其使用PoC业务，不发起后续的SCFCF-PoC AS之间的第三方注册过程。如图10所示，是该方案的流程示意图，从图中可见，包括以下步骤： 

S1001、SCSCF接收用户发起的注册请求。 

S1002、SCSCF向HSS查询用户信息和Ifc信息。 

S1003、根据查询结果判断用户余额是否满足PoC业务设定的门限值？如果是进入步骤S1004，否则进入S1005。 

S1004、允许用户使用该PoC业务，向PoC服务器发起第三方注册。 

S1005、不允许用户使用该PoC业务，不向PoC服务器发起第三方注册。 

例4、预付费在传统智能网中的应用流程，余额预扣成功： 

在智能网中，主要包括如下网元： 

SSP：业务交换点，完成基本的交换功能，完成SCP的指示/请求，向SCP上报必要的信息。当收到预付费的呼叫请求的时候，会向SCP发送预付费的呼叫请求，然后等待SCP的进一步指令：如呼叫继续进行，或者呼叫终止等。 

SCP：业务控制点，解释执行智能业务——按照各种业务逻辑指挥相关的SSP完成各种操作。扣费和检查余额等操作都是由SCP进行的。 

如图11所示，在智能网中该预付费业务实现方法包括如下步骤： 

S1101、用户发起预付费呼叫。 

S1102、智能网SSP向SCP发送预付费呼叫请求。 

S1103、智能网SCP立即指示SSP呼叫继续进行。 

S1104、智能网SCP进行费用预扣，该用户的余额充足，费用预扣成功。 

S1105、智能网SCP指示SSP呼叫继续进行。 

S1106、智能网SSP继续进行所述用户的本次业务呼叫。 

S1107、智能网SCP监视所述用户费用，所述用户费用用完。 

S1108、智能网SCP向SSP指示呼叫结束。 

S1109、智能网SSP根据计费情况生成CDR。 

S1110、智能网SCP根据扣费情况生成CDR。 

例5、预付费在传统智能网中的应用流程，余额不足： 

如图12所示，是预付费业务在智能网中应用，预扣费用失败的流程示意图，从图中可见，包括以下步骤： 

S1201、用户发起预付费呼叫。 

S1202、智能网SSP向SCP发送预付费呼叫请求。 

S1203、智能网SCP立即指示SSP呼叫继续进行。 

S1204、智能网SCP进行费用预扣，该用户的余额不足，费用预扣失败。 

S1205、智能网SCP指示SSP呼叫终止进行。 

S1206、智能网SSP终止进行所述用户的本次业务呼叫。 

S1207、智能网SSP根据计费情况生成CDR。 

S1208、智能网SCP根据扣费情况生成CDR。 

根据上述流程，可以看出呼叫业务处理流程与预付费处理流程之间的影响关系，两个业务处理流程之间的影响，呼叫业务处理流程和预付费处理流程是两个同步的过程，通过特定的事件进行有限的交互： 

1、呼叫业务处理流程收到新呼叫请求时，通知预付费流程进行费用预扣。 

2、呼叫业务处理流程通过监视业务使用，当业务正常结束或者计费周期结束时，通知预付费流程再次进行费用预扣过程。 

3、当预付费流程发现扣费失败时候，通知呼叫业务处理流程结束会话。 

在上述方案中，如果预付费用户费用预扣失败，则在欠费用户充值后，上一次业务欠费进行补偿： 

在“呼叫建立时预扣失败的处理流程”中提到，用户余额不足等原因会造成预扣失败，但此时用户已经使用了一段时间的业务，应用服务器最后会根据用户使用的情况向计费平台上报欠费的具体信息。在计费平台收到欠费信息的时候，可以先用用户的账户余额抵扣部分欠费额，如果不足以抵扣，记录抵扣后的欠费额，当用户下次充值的时候，首先用充值额抵扣剩余的欠费额，参见如下的处理过程： 

本发明提出一种可以避免延长呼叫建立时延的预付费实现方法。这种预付费方法应用于各种预付费业务，可以忽略预付费流程对呼叫建立的影响，提高用户满意度。 

本发明提供的预付费方法也可以应用在其他的预付费解决方案中。例如原 来的智能网预付费解决方案中，或者3G/NGN网络中软交换，IMS子系统的业务系统中。 

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

Claims (22)

1.一种预付费业务实现方法，包括：

预付费业务网元根据用户发起呼叫请求为所述用户建立业务连接；

所述预付费业务网元与计费平台进行所述用户的费用预扣；

根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。

2.如权利要求1所述的方法，其特征在于，所述预付费业务网元为所述用户建立业务连接的步骤与预付费业务网元与计费平台进行所述用户的费用预扣的步骤同时进行。

3.如权利要求1所述的方法，其特征在于，如果所述用户费用预扣成功，则保持所述业务连接。

4.如权利要求3所述的方法，其特征在于，如果所述用户费用预扣成功，保持所述业务连接后，还包括后续再次进行用户费用预扣的步骤。

5.如权利要求3所述的方法，其特征在于，如果所述用户费用预扣成功，保持所述业务连接后，还包括预付费业务网元监视所述用户通话状态的步骤。

6.如权利要求1所述的方法，其特征在于，如果所述用户费用预扣失败，则终止所述业务连接。

7.如权利要求6所述的方法，其特征在于，所述预付费业务网元终止所述业务连接后，向所述用户返回终止业务连接原因。

8.如权利要求6所述的方法，其特征在于，所述预付费业务网元终止所述业务连接后，向所述计费平台上报所述用户的欠费信息。

9.如权利要求8所述的方法，其特征在于，当所述用户进行费用预存时，所述计费平台在所预存费用中，扣除所述欠费。

10.如权利要求1所述的方法，其特征在于，所述预付费业务网元为应用服务器，或POC服务器，或呼叫处理单元，或交换中心，或智能网业务交换点。

11.如权利要求1所述的方法，其特征在于，所述计费平台为智能网业务控制点。

12.如权利要求1所述的方法，其特征在于，所述预付费业务网元与计费平台之间，所使用计费协议，为智能网计费协议信令或Radius/Diameter计费协议信令。

13.一种预付费业务网元，其特征在于，包括：

业务连接建立单元，根据用户发起呼叫请求为所述用户建立业务连接；

费用预扣单元，用于与所述计费平台进行所述用户的费用预扣；

连接状态控制单元，根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。

14.如权利要求13所述的预付费业务网元，其特征在于，还包括：

连接控制单元，用于控制业务连接建立单元为所述用户建立业务连接和费用预扣单元与计费平台进行所述用户的费用预扣操作同时进行。

15.如权利要求13所述的预付费业务网元，其特征在于，还包括：

监视单元，用于监视所述用户通话状态。

16.如权利要求13所述的预付费业务网元，其特征在于，还包括：

终止业务连接原因发送单元，用于在用户费用预扣失败，终止所述业务连接时，向所述用户返回终止业务连接原因。

17.如权利要求16所述的预付费业务网元，其特征在于，还包括：

用户欠费信息上报单元，用于在终止所述业务连接后，向所述计费平台上报所述用户的欠费信息。

18.一种预付费业务网络，包括预付费业务网元和与其相连的计费系统，其特征在于，所述预付费业务网元包括：

业务连接建立单元，根据用户发起呼叫请求为所述用户建立业务连接；

费用预扣单元，用于与所述计费平台进行所述用户的费用预扣；

连接状态控制单元，根据所述用户费用预扣结果，保持所述业务连接或者终止所述业务连接。 

19.如权利要求18所述的预付费业务网络，其特征在于，所述预付费业务网元还包括：

连接控制单元，用于控制业务连接建立单元为所述用户建立业务连接和费用预扣单元与计费平台进行所述用户的费用预扣操作同时进行。

20.如权利要求18所述的预付费业务网络，其特征在于，所述预付费业务网元还包括：

监视单元，用于监视所述用户通话状态。

21.如权利要求18所述的预付费业务网络，其特征在于，所述预付费业务网元还包括：

终止业务连接原因发送单元，用于在用户费用预扣失败，终止所述业务连接时，向所述用户返回终止业务连接原因。

22.如权利要求18所述的预付费业务网络，其特征在于，所述预付费业务网元还包括：

用户欠费信息上报单元，用于在终止所述业务连接后，向所述计费平台上报所述用户的欠费信息。 

Images