一种业务恢复方法、相关装置以及系统的制作方法

专利名称：一种业务恢复方法、相关装置以及系统的制作方法
技术领域：
本发明涉及通信领域，尤其涉及一种业务恢复方法、相关装置以及系统。
背景技术：
随着无线网络不断升级，提供丰富的数据业务成为可能，电信运营商只提供话音的实时话务控制，不能满足客户对享受丰富多种媒体业务的需求。实现多种业务融合的实时计费，比传统话音计费相比更复杂。传统网络中的计费功能往往基于话音、数据、多媒体 内容等不同类型的业务体系纵向并行发展而来，造成业务间计费的孤立，在线计费和离线计费采用完全不同的机制分别处理，造成客户细分营销策略不得不受到预付费和后付费的天然阻隔。随着新型业务的不断涌现，用于满足完备的计费需求的计费系统，必然存在重复投资建设，不但成本高、效率低下，而且各系统的计费能力各异，相互之间难以做到信息共享和业务捆绑营销，无法满足未来的杀手级应用环境的要求。在引入在线计费系统后，很多因素会导致与客户端的通信发生故障，甚至导致客户端直接宕机，使得在线计费系统的功能无法快速恢复，影响用户的体验。如何更好的支持在线用户在异常条件下快速恢复系统的能力，提升体验，并减少运营商的损失，是技术人员亟待解决的问题。在现有技术中，对于大规模的在线计费系统(OCS, Online Charging System),—般需要部署多个计费节点才能满足多种业务实时计费的功能。在多个计费节点的前端，需要设置有一个直径信用控制代理节点(DCC Proxy, Diameter Credit Control Proxy),该DCC Proxy负责将客户端的计费请求分发给各个计费节点。如果客户端出现异常情况，例如供电中断或宕机造成客户端重启，则客户端之前的业务会话信息会全部丢失，而DCC Proxy以及计费节点却还保存着之前的业务会话信息，无法重新继续进行业务处理。根据现有的规范，若遇到上述的情况，客户端会通过交互消息将原始状态标识发送给DCC Proxy,当DCCProxy获取客户端发生重启后，等待该客户端之前的会话信息超时，然后按照业务超时进行处理。在业务超时这段时间内，由于DCC Proxy依然保存着客户端之前的业务会话信息，导致DCC Proxy以及计费节点的会话资源被大量的占用，同时，在计费节点中被该业务会话信息占用的业务余额也无法释放，导致其它业务无法使用上述业务余额，严重的影响到了其它业务的使用。

发明内容
本发明实施例提供了一种业务恢复方法、相关装置以及系统，用于解决客户端由于重启而导致业务无法快速恢复的问题。本发明提供的业务恢复方法，包括获取客户端提供的第一原始状态标识；接收客户端发送的计费请求；比较所述第一原始状态标识与本地存储的第二原始状态标识，若不相同，则根据所述计费请求查找相应的计费节点；向所述计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复。可选的,所述根据计费请求查找相应的计费节点，包括对所述计费请求进行解析，解析出所述计费请求对应的业务关联标识以及业务标识；根据所述业务关联标识以及业务标识识别出承载业务的业务类型；查找所述业务类型对应的计费节点。可选的,所述根据计费请求查找相应的计费节点,还包括提取所述计费请求中的入网标识；根据所述入网标识解析出所述计费请求对应的业务编号；根据所述业务编号在本地的路由数据库中查找对应的计费节点。可选的，所述获取客户端提供的第一原始状态标识包括接收客户端发送的能力交互请求，并向所述客户端发送能力交互响应；获取所述能力交互请求中携带的第一原始状态标识。可选的，所述根据计费请求查找相应的计费节点之后，包括查找业务恢复策略；所述向计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务 进行恢复，包括若业务恢复策略查找成功，则根据所述业务恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述业务恢复策略对所述计费节点上对应的承载业务进行恢复；若业务恢复策略查找失败，则根据系统级恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述系统级恢复策略对所述计费节点上对应的承载业务进行恢复。可选的，所述若业务恢复策略查找失败之后，还包括提取所述计费请求中的入网标识，根据所述入网标识解析出所述计费请求对应的业务编号，根据所述业务编号在本地的路由数据库中查找对应的计费节点，查找节点恢复策略；所述向计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复，还包括若节点恢复策略查找成功，则根据所述节点恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述节点恢复策略对所述计费节点上对应的承载业务进行恢复；若节点恢复策略查找失败，则根据系统级恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述系统级恢复策略对所述计费节点上对应的承载业务进行恢复。可选的,所述根据计费请求查找相应的计费节点之后,包括查找节点恢复策略；所述向计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复，还包括若节点恢复策略查找成功，则根据所述节点恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述节点恢复策略对所述计费节点上对应的承载业务进行恢复；若节点恢复策略查找失败，则根据系统级恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述系统级恢复策略对所述计费节点上对应的承载业务进行恢复。本发明提供的直径信用控制代理节点，包括获取单元，用于获取客户端提供的第一原始状态标识；接收单元，用于接收客户端发送的计费请求；比较单元，用于比较所述第一原始状态标识与本地存储的第二原始状态标识，若不相同，则触发查找单元；查找单元，用于根据所述计费请求查找相应的计费节点；恢复请求发送单元，用于向所述计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复。可选的，所述查找单元包括第一解析模块，用于对所述计费请求进行解析，解析出所述计费请求对应的业务关联标识以及业务标识；识别模块，用于根据所述业务关联标识以及业务标识识别出相应的业务类型；第一查找模块，用于查找所述业务类型对应的计费节点。可选的，所述查找单元还包括提取模块，用于提取所述计费请求中的入网标识；第二解析模块，用于根据所述入网标识解析出所述计费请求对应的业务编号；第二查找模块，用于根据所述业务编号在本地的路由数据库中查找对应的计费节点。可选的，所述直径信用控制代理节点还包括能力协商单元，用于接收客户端发送的能力交互请求，并向所述客户端发送能力交互响应；所述获取单元还用于获取所述能力交互请求中携带的第一原始状态标识；策略查找单元，用于查找用户自定义的恢复策略，所述用户自定义的恢复策略包括业务恢复策略和节点恢复策略。本发明提供的业务恢复系统，包括直径信用控制代理节点和计费节点；所述直径信用控制代理节点，用于获取客户端提供的第一原始状态标识；接收客户端发送的计费请求；比较所述第一原始状态标识与本地存储的第二原始状态标识，若不相同，则根据所述
计费请求查找相应的计费节点；向所述计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复；所述计费节点，用于接收所述直径信用控制代理节点发送的业务恢复请求,并根据所述业务恢复请求对本地对应的承载业务进行恢复。从以上技术方案可以看出，本发明实施例具有以下优点本发明在获知客户端提供的原始状态标识发生变化以后，直接查找计费请求相应的计费节点，并向该计费节点发送业务恢复请求，使得所述计费节点对对应的承载业务进行恢复，使得客户端重启前的业务所占用的业务余额能够及时的释放，其它的业务可以顺利的进行。


图I为本发明业务恢复方法一流程示意图；图2为本发明业务恢复方法的另一流程示意图；图3为本发明业务恢复方法的另一流程示意图；图4为本发明业务恢复方法的另一流程示意图；图5为本发明业务恢复系统的一信令流程图；图6为本发明DCC Proxy的一结构示意图；图7为本发明业务恢复系统的一结构示意图。
具体实施例方式本发明实施例提供了一种业务恢复方法、相关装置以及系统，用于解决客户端由于重启而导致业务无法快速恢复的问题。请参阅图1，本发明实施例中业务恢复方法的一个实施例包括101、DCC Proxy获取客户端提供的第一原始状态标识；在客户端发生异常情况进行重启之后，客户端若要和DCC Proxy重新进行通信，则在通信前需要与DCC Proxy进行能力协商，具体可以为DCC Proxy接收客户端发送的能力交互请求，在确认该能力交互请求中的客户端信息后，向该客户端发送能力交互响应，在客户端接收到该能力交互响应之后，客户端与DCC Proxy的能力协商结束。该客户端可以包括业务控制点(SCP, Service Control Point)和网关通用无线业务支持点(GGSN, Gateway GPRS Support Node)。
在客户端向DCC Proxy发送能力交互请求的同时,可以在该能力交互请求上携带第一原始状态标识，使得DCC Proxy接收客户端发送的能力交互请求时，同时也可以获取到客户端提供的第一原始状态标识。此外，客户端在与DCC Proxy完成能力协商之后，也可以通过一条单独的消息向DCC Proxy发送第一原始状态标识,而DCC Proxy直接从该单独携带第一原始状态标识的消息中获取第一原始状态标识；可以理解的是，在实际应用中，DCC Proxy获取第一原始状态标识还可以有其他的方式，此处具体不作限定。原始状态标识(Origin-State-Id)是一个单调递增的值，每当客户端发生重启时，该原始状态标识的值就会发生变化(增大)。本发明实施例中的第一原始状态标识表示原始状态标识在客户端重启发生变化后的值。在客户端发生重启时，将第一原始状态标识通过客户端与DCC Proxy之间的交互消息发送给DCC Proxy,使得DCC Proxy可以获知客户端发生重启。
102、DCC Proxy接收客户端发送的计费请求；DCC Proxy接收客户端发送的计费请求,该计费请求用于指示DCC Proxy对该计费请求中指定的承载业务进行计费。客户端出现异常情况之后进行重启，由于重启导致客户端之前的业务会话信息会全部丢失，故在DCC Proxy与客户端完成能力协商之后,客户端与DCC Proxy进行通信,重新向DCC Proxy发送各个承载业务的计费请求,使得DCC Proxy继续对指定的承载业务进行计费操作。103、DCC Proxy根据计费请求查找相应的计费节点；DCC Proxy在获取到客户端提供的第一原始状态标识之后，DCC Proxy对比第一原始状态标识与本地存储的第二原始状态标识，若第一原始状态标识等于第二原始状态标识，则说明客户端没有发生重启，DCC Proxy可以正常的根据上述计费请求执行计费操作；若第一原始状态标识不等于第二原始状态标识，则说明客户端发生了重启，DCC Proxy则根据该计费请求查找相应的计费节点。具体DCC Proxy查找计费节点的方法可以是根据该计费请求对应的承载业务进行查找的方法，也可以是根据该计费请求对应的业务编号进行查找的方法，详细的过程在本发明的后续实施例中再进行描述。104> DCC Proxy向计费节点发送业务恢复请求。DCC Proxy向上述查找到的计费节点发送业务恢复请求,使得该计费节点对该计费节点上自身所承载的相关业务进行恢复。由于客户端发生了重启，丢失了之前的所有业务信息，故客户端需要重新发起了业务请求，并且要求DCC Proxy对重新发起的业务请求进行计费；但是，在客户端之前所进行的业务未发生超时的这段时间内，DCC Proxy依然保存在之前的业务信息，这些业务信息不止无法被更新，且占用着客户端的业务余额，影响了其它业务的开展；因此，当DCC Proxy从新的计费请求中识别出需要执行的承载业务后，查找到这些承载业务对应的计费节点，向这些计费节点发送释放这些业务的请求，使得计费节点根据客户的需求处理之前的业务数据，并释放相应的业务余额。具体的客户需求可以在用户自定义的恢复策略中体现。该业务恢复请求中携带有第一原始状态标识，在计费节点收到该业务恢复请求之后，提取其中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据；由于在计费节点中保存着客户端的承载业务重启前以及重启后的业务数据，而客户端发生重启之后会重新对该承载业务进行处理，故需要计费节点删除重启前的业务数据，以解放占用的内存，同时又需要保存重启后的业务数据，而通过第一原始状态标识则可以区分具体哪些数据是重启前的业务数据，哪些是重启后的业务数据；具体的由于原始状态标识是一个单调递增的值，业务数据中对应的原始状态标识凡小于该第一原始状态标识的，则认为该业务数据为重启前的业务数据，需要进程删除，而反之，原始状态标识凡不小于该第一原始状态标识的业务数据则需要保存。此外,DCC Proxy还可以使用一些具有针对性的恢复策略对承载业务进行恢复，具体的恢复策略可以包括业务恢复策略、节点恢复策略以及系统级恢复策略。业务恢复策略主要是优先考虑业务类型进行恢复的用户自定义的策略，节点恢复策略主要是优先针对某些节点进行恢复的用户自定义的策略，而系统级恢复策略则是普遍使用的DCC Proxy默认的恢复策略。具体的，则恢复策略的实现上，DCC Proxy可以直接在上述业务恢复请求上承载指 定的恢复策略，通过业务恢复请求将指定的恢复策略发送给计费节点，使得计费节点根据该指定的恢复策略进行业务恢复；也可以预先在计费节点中设置好各种恢复策略，而DCCProxy则直接在该业务恢复请求上承载指定的恢复策略对应的标识，具体现实的形式可以根据实际情况而定，此处不作限定。下面以业务恢复策略为例，对上述业务恢复方法的实施例进行具体的描述，请参阅图2，本发明实施例中业务恢复方法的另一个实施例包括201、DCC Proxy获取能力交互请求中的第一原始状态标识；在客户端与DCC Proxy进行通信之前,客户端与DCC Proxy进行能力协商。具体的，DCC Proxy接收客户端发送的能力交互请求,在确认该能力交互请求中的客户端信息后，向该客户端发送能力交互响应，在客户端接收到该能力交互响应之后，客户端与DCCProxy的能力协商结束。在接收到上述能力交互请求的同时，DCC Proxy从该能力交互请求中获取第一原始状态标识。此外，客户端在与DCC Proxy完成能力协商之后，也可以通过一条单独的消息向DCC Proxy发送第一原始状态标识,而DCC Proxy直接从该单独携带第一原始状态标识的消息中获取第一原始状态标识；可以理解的是，在实际应用中，DCC Proxy获取第一原始状态标识还可以有其他的方式，此处具体不作限定。在DCC Proxy获取到上述第一原始状态标识之后，DCC Proxy对比第一原始状态标识与本地存储的第二原始状态标识，若第一原始状态标识等于第二原始状态标识，则说明客户端没有发生重启，当DCC Proxy收到该客户端发送的计费请求时，可以正常的根据上述计费请求执行计费操作；若第一原始状态标识不等于第二原始状态标识，则说明客户端发生了重启，当DCCProxy收到该客户端发送的计费请求之后，则执行步骤203。202、DCC Proxy接收客户端发送的计费请求；DCC Proxy接收客户端发送的计费请求,该计费请求用于指示DCC Proxy对该计费请求中指定的承载业务进行计费。客户端出现异常情况之后进行重启，由于重启导致客户端之前的业务会话信息会全部丢失，故在DCC Proxy与客户端完成能力协商之后,客户端与DCC Proxy进行通信,重新向DCC Proxy发送各个承载业务的计费请求,使得DCC Proxy继续对指定的承载业务进行计费操作。203、DCC Proxy对计费请求进行解析；DCC Proxy对上述计费请求进行解析,解析出该计费请求对应的业务关联标识(Service-Context-ID)以及业务标识(Service_Identifier)。业务关联标识和业务标识分别标记了承载业务的服务地址和承载业务的标识，由于业务关联标识标记的是承载业务的服务地址，而该服务地址上可以包含有多种的业务应用，因此，还需要通过业务标识来确认具体是哪一种业务类型，所以通过这两个参数就可以唯一的确定具体承载业务的业务类型。204、DCC Proxy根据业务关联标识和业务标识识别承载业务的业务类型； DCC Proxy根据上述解析得到的业务关联标识和业务标识识别承载业务的业务类型，具体的可以参考下表
业务关联标识业务标识业务类型
voice@huawei. com 0语音
message@huawei. com 0SMS
GPRS@huawei. com0GPRSDCC Proxy使用业务关联标识和业务标识的不同组合，映射到相应的业务类型，则DCC Proxy可以获知具体应该对哪些承载业务进行恢复。205、DCC Proxy查找业务类型对应的计费节点；DCC Proxy查找上述识别到的业务类型在哪个计费节点上进行计费，以该计费节点作为发送业务恢复请求的计费节点。206、DCC Proxy查找业务恢复策略；DCC Proxy在本地的规则库查找业务恢复策略，若查找成功(即本地存有业务恢复策略)，则执行步骤207 ;若查找失败(即本地没有存有业务恢复策略)，则执行步骤208 ；业务恢复策略为优先考虑业务类型进行恢复的用户自定义的恢复策略。207、DCC Proxy根据业务恢复策略向计费节点发送业务恢复请求；DCC Proxy若查找成功的查找到业务恢复策略，则根据上述查找到的业务恢复策略向计费节点发送业务恢复请求。该业务恢复请求中携带有第一原始状态标识以及上述识别到的业务类型，在计费节点收到该业务恢复请求之后，判断该业务恢复请求中携带的业务类型是否与计费节点本地所处理的业务类型一致，若一致，则提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该业务恢复请求中还携带有上述业务恢复策略或上述业务恢复策略所对应的标识，计费节点可以根据该业务恢复策略进行业务恢复的操作，具体可以包括取消该业务类型对应的承载业务所占用的业务余额，记录该承载业务之前的会话信息以及预留相关信息到文件内，删除处理后的相关会话信息等。208、DCC Proxy根据系统级恢复策略向计费节点发送业务恢复请求。DCC Proxy若没有查找到业务恢复策略，则系统级的恢复策略向计费节点发送业务恢复请求。该业务恢复请求中携带有第一原始状态标识以及上述识别到的业务类型，在计费节点收到该业务恢复请求之后，判断该业务恢复请求中携带的业务类型是否与计费节点本地所处理的业务类型一致，若一致，则提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该业务恢复请求中还携带有上述系统级恢复策略或上述系统级恢复策略所对应的标识，计费节点可以根据该系统级恢复策略进行业务恢复的操作。 下面以节点恢复策略为例，对上述业务恢复方法的实施例进行具体的描述，请参阅图3，本发明实施例中业务恢复方法的另一个实施例包括301、DCC Proxy获取能力交互请求中的第一原始状态标识；在客户端与DCC Proxy进行通信之前,客户端与DCC Proxy进行能力协商。具体的，DCC Proxy接收客户端发送的能力交互请求,在确认该能力交互请求中的客户端信息后，向该客户端发送能力交互响应，在客户端接收到该能力交互响应之后，客户端与DCCProxy的能力协商结束。在接收到上述能力交互请求的同时，DCC Proxy从该能力交互请求中获取第一原始状态标识。此外，客户端在与DCC Proxy完成能力协商之后，也可以通过一条单独的消息向DCC Proxy发送第一原始状态标识,而DCC Proxy直接从该单独携带第一原始状态标识的消息中获取第一原始状态标识；可以理解的是，在实际应用中，DCC Proxy获取第一原始状态标识还可以有其他的方式，此处具体不作限定。在DCC Proxy获取到上述第一原始状态标识之后，DCC Proxy对比第一原始状态标识与本地存储的第二原始状态标识，若第一原始状态标识等于第二原始状态标识，则说明客户端没有发生重启，当DCC Proxy收到该客户端发送的计费请求时，可以正常的根据上述计费请求执行计费操作；若第一原始状态标识不等于第二原始状态标识，则说明客户端发生了重启，当DCCProxy收到该客户端发送的计费请求之后，则执行步骤303。302、DCC Proxy接收客户端发送的计费请求；本实施例中的步骤302的内容与前述图2所示的实施例中步骤202的内容相同，此处不再赘述。303、DCC Proxy获取计费请求对应的业务编号；在获取到客户端发送的计费请求之后，DCC Proxy提取该计费请求中的入网标识(Subscription-Id),并根据提取到的入网标识解析出该计费请求对应的业务编号(service number)。304、DCC Proxy根据业务编号查找计费节点的路由地址；DCC Proxy根据上述解析到的业务编号在本地路由数据库里查找对应的计费节点的路由地址。在实际应用中，客户端在请求对某个承载业务进行计费同时，也会指定该承载业务具体在哪个计费节点上进行计费，DCC Proxy可以通过对计费请求中的入网标识进行解析，得到该计费请求中对应的业务编码，而该业务编码则在DCC Proxy中对应着相应计费节点的路由地址；本发明实施例是优先对计费请求所指向的计费节点进行恢复，直接恢复该计费节点上的所有承载业务，不对承载业务进行区别。305、DCC Proxy查找节点恢复策略；DCC Proxy在本地的规则库查找节点恢复策略，若查找成功(即本地存有节点恢复策略)，则执行步骤306 ;若查找失败(即本地没有存有节点恢复策略)，则执行步骤307 ；节点恢复策略主要是优先针对某些节点进行恢复的用户自定义的恢复策略。306、DCC Proxy根据节点恢复策略向计费节点发送业务恢复请求；DCC Proxy若查找成功的查找到节点恢复策略，则根据上述查找到的节点恢复策略向计费节点发送业务恢复请求。 该节点恢复请求中携带有第一原始状态标识,在计费节点收到该业务恢复请求之后，DCC Proxy提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。由于在计费节点中保存着客户端的承载业务重启前以及重启后的业务数据，而客户端发生重启之后会重新对该承载业务进行处理，故需要计费节点删除重启前的业务数据，以解放占用的内存，同时又需要保存重启后的业务数据，而通过第一原始状态标识则可以区分具体哪些数据是重启前的业务数据，哪些是重启后的业务数据；具体的由于原始状态标识是一个单调递增的值，业务数据中对应的原始状态标识凡小于该第一原始状态标识的，则认为该业务数据为重启前的业务数据，需要进程删除，而反之，原始状态标识凡不小于该第一原始状态标识的业务数据则需要保存。并且，该节点恢复请求中还携带有上述节点恢复策略或上述节点恢复策略所对应的标识，计费节点可以根据该节点恢复策略进行业务恢复的操作，具体可以包括1、取消该承载业务所占用的业务余额；2、将该承载业务之前的会话信息以及预留信息记录到备档文件内；3、删除处理后的相关会话信息；4、判断是否还有未处理的业务数据，若有，则继续执行步骤I至3。307、DCC Proxy根据系统级恢复策略向计费节点发送业务恢复请求。DCC Proxy若没有查找到节点恢复策略，则系统级的恢复策略向计费节点发送业务恢复请求。该业务恢复请求中携带有第一原始状态标识，在计费节点收到该业务恢复请求之后，提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该业务恢复请求中还携带有上述系统级恢复策略或上述系统级恢复策略所对应的标识，计费节点可以根据该系统级恢复策略进行业务恢复的操作。在本实施例中，上述步骤303 304可以发生在DCC Proxy接受客户端发送的计费请求(即步骤302)之后，查找节点恢复策略(步骤305)之前，上述次序仅供参考，步骤303 304具体的执行顺序可以根据实际情况而定，此处不作限定。本发明恢复策略的方案还可以结合业务恢复策略以及节点恢复策略一同进行操作，请参阅图4，本发明实施例中业务恢复方法的另一个实施例包括401、DCC Proxy获取能力交互请求中的第一原始状态标识；
在客户端与DCC Proxy进行通信之前,客户端与DCC Proxy进行能力协商。具体的，DCC Proxy接收客户端发送的能力交互请求,在确认该能力交互请求中的客户端信息后，向该客户端发送能力交互响应，在客户端接收到该能力交互响应之后，客户端与DCCProxy的能力协商结束。在接收到上述能力交互请求的同时，DCC Proxy从该能力交互请求中获取第一原始状态标识。此外，客户端在与DCC Proxy完成能力协商之后，也可以通过一条单独的消息向DCC Proxy发送第一原始状态标识,而DCC Proxy直接从该单独携带第一原始状态标识的消息中获取第一原始状态标识；可以理解的是，在实际应用中，DCC Proxy获取第一原始状态标识还可以有其他的方式，此处具体不作限定。
在DCC Proxy获取到上述第一原始状态标识之后，DCC Proxy对比第一原始状态标识与本地存储的第二原始状态标识，若第一原始状态标识等于第二原始状态标识，则说明客户端没有发生重启，当DCC Proxy收到该客户端发送的计费请求时，可以正常的根据上述计费请求执行计费操作；若第一原始状态标识不等于第二原始状态标识，则说明客户端发生了重启，当DCCProxy收到该客户端发送的计费请求之后，则执行步骤403。402、DCC Proxy接收客户端发送的计费请求；本实施例中的步骤402的内容与前述图2所示的实施例中步骤402的内容相同，此处不再赘述。403、DCC Proxy对计费请求进行解析；DCC Proxy对上述计费请求进行解析,解析出该计费请求对应的业务关联标识(Service-Context-ID)以及业务标识(Serv ice_I dent ifier)。业务关联标识和业务标识分别标记了承载业务的服务地址和承载业务的标识，由于业务关联标识标记的是承载业务的服务地址，而该服务地址上可以包含有多种的业务应用，因此，还需要通过业务标识来确认具体是哪一种业务类型，所以通过这两个参数就可以唯一的确定具体承载业务的业务类型。404、DCC Proxy根据业务关联标识和业务标识识别承载业务的业务类型；DCC Proxy根据上述解析得到的业务关联标识和业务标识识别承载业务的业务类型，则DCC Proxy可以获知具体应该对哪些承载业务进行恢复。405、DCC Proxy查找业务类型对应的计费节点；DCC Proxy查找上述识别到的业务类型在哪个计费节点上进行计费，以该计费节点作为发送业务恢复请求的计费节点。406、DCC Proxy查找业务恢复策略；DCC Proxy在本地的规则库查找业务恢复策略，若查找成功(即本地存有业务恢复策略)，则执行步骤407 ;若查找失败(即本地没有存有业务恢复策略)，则执行步骤408。407、DCC Proxy根据业务恢复策略向计费节点发送业务恢复请求；DCC Proxy若查找成功的查找到业务恢复策略，则根据上述查找到的业务恢复策略向计费节点发送业务恢复请求。该业务恢复请求中携带有第一原始状态标识以及上述识别到的业务类型，在计费节点收到该业务恢复请求之后，判断该业务恢复请求中携带的业务类型是否与计费节点本地所处理的业务类型一致，若一致，则提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该业务恢复请求中还携带有上述业务恢复策略或上述业务恢复策略所对应的标识，计费节点可以根据该业务恢复策略进行业务恢复的操作，具体可以包括取消该业务类型对应的承载业务所占用的业务余额，记录该承载业务之前的会话信息以及预留相关信息到文件内，删除处理后的相关会话信息等。408、DCC Proxy获取计费请求对应的业务编号；在获取到客户端发送的计费请求之后，DCC Proxy提取该计费请求中的入网标识(Subscription-Id),并根据提取到的入网标识解析出该计费请求对应的业务编号(service number)。409、DCC Proxy根据业务编号查找到计费节点的路由地址；
DCC Proxy根据上述解析到的业务编号在本地路由数据库里查找对应的计费节点的路由地址。410、DCC Proxy查找节点恢复策略；DCC Proxy在本地的规则库查找节点恢复策略，若查找成功(即本地存有节点恢复策略)，则执行步骤411 ;若查找失败(即本地没有存有节点恢复策略)，则执行步骤412。41UDCC Proxy根据节点恢复策略向计费节点发送业务恢复请求；DCC Proxy若查找成功的查找到节点恢复策略，则根据上述查找到的节点恢复策略向计费节点发送业务恢复请求。该节点恢复请求中携带有第一原始状态标识，在计费节点收到该业务恢复请求之后，DCC Proxy提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该节点恢复请求中还携带有上述节点恢复策略或上述节点恢复策略所对应的标识，计费节点可以根据该节点恢复策略进行业务恢复的操作，具体可以包括1、取消该承载业务所占用的业务余额；2、将该承载业务之前的会话信息以及预留信息记录到备档文件内；3、删除处理后的相关会话信息；4、判断是否还有未处理的业务数据，若有，则继续执行步骤I至3。412, DCC Proxy根据系统级恢复策略向计费节点发送业务恢复请求。DCC Proxy若没有查找到节点恢复策略，则根据系统级的恢复策略向计费节点发送业务恢复请求。该业务恢复请求中携带有第一原始状态标识，在计费节点收到该业务恢复请求之后，提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该业务恢复请求中还携带有上述系统级恢复策略或上述系统级恢复策略所对应的标识，计费节点可以根据该系统级恢复策略进行业务恢复的操作。在本发明实施例中，优先执行业务恢复策略，当查询不到业务恢复策略时，可以再查询节点恢复策略，如此，则可以兼顾两种恢复策略的方案，最大可能的满足运营商的需求，灵活的配置各种策略，提升了用户的体验。为了便于理解，下面以一具体应用场景对上述的实施例中描述的业务恢复系统进行描述，请参阅图5，具体为501、客户端发送能力交互请求；
在客户端发生异常情况进行重启之后，客户端发送能力交互请求(CER，Capabilities Exchange Request)与DCC Proxy进行能力协商,该能力交互请求中携带有原始状态标识。502、代理节点返回能力交互响应；
DCC Proxy接收客户端发送的能力交互请求,在确认该能力交互请求中的客户端信息后，存储该能力交互请求，并向客户端发送能力交互响应(CEA, CapabilitiesExchange Answer)。503、客户端发送计费请求；客户端在接受到DCC Proxy返回的能力交互响应之后,确认可以与DCCProxy进行通信，则向DCC Proxy发送各个承载业务的计费请求,请求DCCProxy继续进行承载业务的计费操作。504、代理节点判断是否需要进行业务恢复；DCC Proxy接收客户端发送的计费请求，判断该计费请求是否可以进行，是否需要进行业务恢复。具体为DCC Proxy获取该能力交互请求中携带的第一原始状态标识，对比该第一原始状态标识与本地存储的第二原始状态标识，若两个原始状态标识相等，则根据上述计费请求触发计费节点进行正常的计费流程；若不相等，则触发步骤505。505、代理节点识别客户端的承载业务；在确认需要进行业务恢复之后，DCC Proxy对该计费请求进行解析，并解析出业务关联标识和业务标识等参数；然后，DCC Proxy使用上述业务关联标识和业务标识的不同组合，映射到相应的业务类型。此外，DCC Proxy还可以通过对计费请求中的入网标识进行解析，得到该计费请求中对应的业务编码，根据该业务编码查询到相应计费节点的路由地址。在识别出上述计费请求中承载业务的业务类型以及得到计费节点的路由地址之后，DCC Proxy在本地的规则库中查找用户自定义的恢复策略(包括业务恢复策略和节点恢复策略)，若本地没有用户自定义的恢复策略，则使用系统级的恢复策略进行业务恢复。506、代理节点发送业务恢复请求；在确定具体使用哪一个恢复策略进行业务恢复后，DCC Proxy向计费节点发送业务恢复请求。其中，上述业务恢复请求中携带有第一原始状态标识、上述识别到的业务类型以及相应恢复策略(或恢复策略的标识)。507、计费节点执行业务恢复。计费节点在接收到DCC Proxy发送的业务恢复请求后,若该业务恢复请求中携带的是业务恢复策略，则判断该业务恢复请求中携带的业务类型是否与计费节点本地所处理的业务类型一致，若一致，则提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。若该业务恢复请求中携带的不是业务恢复策略，则直接提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。具体判别删除哪些承载业务数据的方法业务数据中对应的原始状态标识凡小于该第一原始状态标识的，则认为该业务数据为重启前的业务数据，需要进程删除，而反之，原始状态标识凡不小于该第一原始状态标识的业务数据则需要保存。上面仅以一些例子对本发明实施例中的应用场景进行了说明，可以理解的是，在实际应用中，还可以有更多的应用场景，具体此处不作限定。下面对用于执行上述业务恢复方法的本发明DCC Proxy的实施例进行说明，其逻辑结构请参考图6，本发明实施例中DCC Proxy的一个实施例包括获取单元601，用于获取客户端提供的第一原始状态标识；接收单元602，用于接收客户端发送的计费请求；比较单元603，用于比较上述第一原始状态标识与本地存储的第二原始状态标识， 若不相同，则触发查找单元604 ；查找单元604，用于根据上述计费请求查找相应的计费节点；恢复请求发送单元605，用于向上述计费节点发送业务恢复请求，使得该计费节点对该计费节点上对应的承载业务进行恢复。此外，本发明实施例中的查找单元604可以包括第一解析模块6041，用于对上述计费请求进行解析，解析出该计费请求对应的业务关联标识以及业务标识；识别模块6042，用于根据上述业务关联标识以及业务标识识别出相应的业务类型；第一查找模块6043，用于查找上述业务类型对应的计费节点。提取模块6044，用于提取上述计费请求中的入网标识；第二解析模块6045，用于根据上述入网标识解析出该计费请求对应的业务编号；第二查找模块6046，用于根据上述业务编号在本地的路由数据库中查找对应的计费节点。此外,本发明实施例中的DCC Proxy还可以进一步包括能力协商单元606,用于接收客户端发送的能力交互请求,并向该客户端发送能力交互响应；策略查找单元607，用于查找用户自定义的恢复策略，所述用户自定义的恢复策略包括业务恢复策略和节点恢复策略。本发明实施例DCC Proxy分配装置中各个单元具体的交互过程如下在客户端发生异常情况进行重启之后，客户端若要和DCC Proxy重新进行通信，则在通信前需要与DCC Proxy进行能力协商 DCC Proxy的能力协商单元606接收客户端发送的能力交互请求，在确认该能力交互请求中的客户端信息后，向该客户端发送能力交互响应，在客户端接收到该能力交互响应之后，客户端与DCC Proxy的能力协商结束。在客户端向DCC Proxy发送能力交互请求的同时,可以在该能力交互请求上携带第一原始状态标识，则DCC Proxy接收客户端发送的能力交互请求时,DCC Proxy的获取单元601可以从该能力交互请求中获取第一原始状态标识。此外，在客户端在与DCC Proxy完成能力协商之后，也可以通过一条单独的消息向DCC Proxy发送第一原始状态标识,则DCCProxy的获取单元601可以直接从该单独携带第一原始状态标识的消息中获取第一原始状态标识；可以理解的是，在实际应用中，DCC Proxy获取第一原始状态标识还可以有其他的方式，此处具体不作限定。原始状态标识(Origin-State-Id)是一个单调递增的值，每当客户端发生重启时，该原始状态标识的值就会发生变化(增大)。本发明实施例中的第一原始状态标识表示原始状态标识在客户端重启发生变化后的值。在客户端发生重启时，将第一原始状态标识通过客户端与DCC Proxy之间的交互消息发送给DCC Proxy,使得DCC Proxy可以获知客户端发生重启。在获取到上述第一原始状态标识之后，DCC Proxy的比较单元603对比第一原始状态标识与本地存储的第二原始状态标识，若第一原始状态标识等于第二原始状态标识，则说明客户端没有发生重启，当接收单元602收到该客户端发送的计费请求时，可以正常的根据上述计费请求执行计费操作；若第一原始状态标识不等于第二原始状态标识，则说明客户端发生了重启，当接收单元602收到该客户端发送的计费请求之后，则执行查找单元 604。接收单元602接收客户端发送的计费请求,该计费请求用于指示DCCProxy对该计费请求中指定的承载业务进行计费。客户端出现异常情况之后进行重启，由于重启导致客 户端之前的业务会话信息会全部丢失，故在DCCProxy与客户端完成能力协商之后,客户端与DCC Proxy进行通信,重新向DCC Proxy发送各个承载业务的计费请求,使得DCC Proxy继续对指定的承载业务进行计费操作。查找单元604根据该计费请求查找相应的计费节点。具体的，可以有两种查找方法I、首先，查找单元604的第一解析模块6041对上述计费请求进行解析，解析出该计费请求对应的业务关联标识以及业务标识；业务关联标识和业务标识分别标记了承载业务的服务地址和承载业务的标识，由于业务关联标识标记的是承载业务的服务地址，而该服务地址上可以包含有多种的业务应用，因此，还需要通过业务标识来确认具体是哪一种业务类型，所以通过这两个参数就可以唯一的确定具体承载业务的业务类型；然后，识别模块6042根据上述解析得到的业务关联标识和业务标识识别承载业务的业务类型；最后，第一查找模块6043查找上述识别到的业务类型在哪个计费节点上进行计费，以该计费节点作为发送业务恢复请求的计费节点。2、首先，提取模块6044提取该计费请求中的入网标识；然后第二解析模块6045根据提取到的入网标识解析出该计费请求对应的业务编号；最后，第二查找模块6046，根据上述解析到的业务编号在本地路由数据库里查找对应的计费节点的路由地址。在实际应用中，客户端在请求对某个承载业务进行计费同时，也会指定该承载业务具体在哪个计费节点上进行计费，DCCProxy可以通过对计费请求中的入网标识进行解析，得到该计费请求中对应的业务编码，而该业务编码则在DCC Proxy中对应着相应计费节点的路由地址。在查找到计费单元之后，策略查找单元607查找用户自定义的恢复策略，该用户自定义的恢复策略包括业务恢复策略和节点恢复策略。策略查找单元607可以设置优先查找业务恢复策略，在业务恢复策略查找失败后在查找节点恢复策略。具体的，策略查找单元607在本地的规则库查找业务恢复策略，若查找成功，则触发恢复请求发送单元605根据上述查找到的业务恢复策略向计费节点发送业务恢复请求。该业务恢复请求中携带有第一原始状态标识以及上述识别到的业务类型，在计费节点收到该业务恢复请求之后，判断该业务恢复请求中携带的业务类型是否与计费节点本地所处理的业务类型一致，若一致，则提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该业务恢复请求中还携带有上述业务恢复策略或上述业务恢复策略所对应的标识，计费节点可以根据该业务恢复策略进行业务恢复的操作，具体可以包括取消该业务类型对应的承载业务所占用的业务余额，记录该承载业务之前的会话信息以及预留相关信息到文件内，删除处理后的相关会话信息等。若业务恢复策略查找失败，则继续查找节点恢复策略，若节点恢复策略查找成功，则触发恢复请求发送单元605根据上述查找到的节点恢复策略向计费节点发送业务恢复请求。该节点恢复请求中携带有第一原始状态标识，在计费节点收到该业务恢复请求之后，DCC Proxy提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该节点恢复请求中还携带有上述节点恢复策略或上述节点恢复策略所对应的标识，计费节点可以根据该节点恢复策略进行业务恢复的操作。若节点恢复策略仍查找失败，则恢复请求发送单元605根据系统级的恢复策略向 计费节点发送业务恢复请求。该业务恢复请求中携带有第一原始状态标识，在计费节点收到该业务恢复请求之后，提取该业务恢复请求中的第一原始状态标识，通过该第一原始状态标识判断具体应该删除哪些承载业务的数据。并且，该业务恢复请求中还携带有上述系统级恢复策略或上述系统级恢复策略所对应的标识，计费节点可以根据该系统级恢复策略进行业务恢复的操作。下面对执行本发明业务恢复方法的业务恢复系统进行描述，其逻辑结构请参阅图7，本发明实施例中业务恢复系统的一个实施例包括直径信用控制代理节点701和计费节点702 ；直径信用控制代理节点701，用于获取客户端提供的第一原始状态标识；接收客户端发送的计费请求；比较该第一原始状态标识与本地存储的第二原始状态标识，若不相同，则根据该计费请求查找相应的计费节点；向该计费节点702发送业务恢复请求，使得该计费节点702对相应的承载业务进行恢复；计费节点702，用于接收该直径信用控制代理节点701发送的业务恢复请求，并根据该业务恢复请求对本地对应的承载业务进行恢复。上述业务恢复系统的应用场景可以参考图5实施例中的具体内容，此处不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的装置、方法和系统，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM, Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本发明的具体实施方式
，但本发明的保护范围并不局限于此，任何 熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。
权利要求
1.一种业务恢复方法，其特征在于，包括 获取客户端提供的第一原始状态标识； 接收客户端发送的计费请求； 比较所述第一原始状态标识与本地存储的第二原始状态标识，若不相同，则根据所述计费请求查找相应的计费节点； 向所述计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复。
2.根据权利要求I所述的方法，其特征在于，所述根据计费请求查找相应的计费节点，包括 对所述计费请求进行解析，解析出所述计费请求对应的业务关联标识以及业务标识； 根据所述业务关联标识以及业务标识识别出承载业务的业务类型； 查找所述业务类型对应的计费节点。
3.根据权利要求I所述的方法，其特征在于，所述根据计费请求查找相应的计费节点，还包括 提取所述计费请求中的入网标识； 根据所述入网标识解析出所述计费请求对应的业务编号； 根据所述业务编号在本地的路由数据库中查找对应的计费节点。
4.根据权利要求I所述的方法，其特征在于，所述获取客户端提供的第一原始状态标识包括 接收客户端发送的能力交互请求，并向所述客户端发送能力交互响应； 获取所述能力交互请求中携带的第一原始状态标识。
5.根据权利要求2所述的方法，其特征在于， 所述根据计费请求查找相应的计费节点之后，包括 查找业务恢复策略； 所述向计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复，包括 若业务恢复策略查找成功，则根据所述业务恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述业务恢复策略对所述计费节点上对应的承载业务进行恢复；若业务恢复策略查找失败，则根据系统级恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述系统级恢复策略对所述计费节点上对应的承载业务进行恢复。
6.根据权利要求5所述的方法，其特征在于，所述若业务恢复策略查找失败之后，还包括 提取所述计费请求中的入网标识，根据所述入网标识解析出所述计费请求对应的业务编号，根据所述业务编号在本地的路由数据库中查找对应的计费节点，查找节点恢复策略； 所述向计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复，还包括 若节点恢复策略查找成功，则根据所述节点恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述节点恢复策略对所述计费节点上对应的承载业务进行恢复；若节点恢复策略查找失败，则根据系统级恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述系统级恢复策略对所述计费节点上对应的承载业务进行恢复。
7.根据权利要求3所述的方法，其特征在于， 所述根据计费请求查找相应的计费节点之后，包括 查找节点恢复策略； 所述向计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复，还包括 若节点恢复策略查找成功，则根据所述节点恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述节点恢复策略对所述计费节点上对应的承载业务进行恢复；若节点恢复策略查找失败，则根据系统级恢复策略向计费节点发送业务恢复请求，使得所述计费节点根据所述系统级恢复策略对所述计费节点上对应的承载业务进行恢复。
8.一种直径信用控制代理节点，其特征在于，包括 获取单元，用于获取客户端提供的第一原始状态标识； 接收单元，用于接收客户端发送的计费请求； 比较单元，用于比较所述第一原始状态标识与本地存储的第二原始状态标识，若不相同，则触发查找单元； 查找单元，用于根据所述计费请求查找相应的计费节点； 恢复请求发送单元，用于向所述计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复。
9.根据权利要求8所述的节点，其特征在于，所述查找单元包括 第一解析模块，用于对所述计费请求进行解析，解析出所述计费请求对应的业务关联标识以及业务标识； 识别模块，用于根据所述业务关联标识以及业务标识识别出相应的业务类型； 第一查找模块，用于查找所述业务类型对应的计费节点。
10.根据权利要求8所述的节点，其特征在于，所述查找单元还包括 提取模块，用于提取所述计费请求中的入网标识； 第二解析模块，用于根据所述入网标识解析出所述计费请求对应的业务编号； 第二查找模块，用于根据所述业务编号在本地的路由数据库中查找对应的计费节点。
11.根据权利要求8所述的节点,其特征在于,所述节点还包括 能力协商单元，用于接收客户端发送的能力交互请求，并向所述客户端发送能力交互响应； 所述获取单元还用于获取所述能力交互请求中携带的第一原始状态标识。
12.根据权利要求8至11任意一项所述的节点，其特征在于，所述节点还包括 策略查找单元，用于查找用户自定义的恢复策略，所述用户自定义的恢复策略包括业务恢复策略和节点恢复策略。
13.—种业务恢复系统，其特征在于，包括直径信用控制代理节点和计费节点； 所述直径信用控制代理节点，用于获取客户端提供的第一原始状态标识；接收客户端发送的计费请求；比较所述第一原始状态标识与本地存储的第二原始状态标识，若不相同，则根据所述计费请求查找相应的计费节点；向所述计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复； 所述计费节点，用于接收所述直径信用控制代理节点发送的业务恢复请求，并根据所述业务恢复请求对本地对应的承载业务进行恢复。
全文摘要
本发明实施例公开了一种业务恢复方法、相关装置以及系统，用于解决客户端由于重启而导致业务无法快速恢复的问题。本发明实施例方法包括获取客户端提供的第一原始状态标识；接收客户端发送的计费请求；比较所述第一原始状态标识与本地存储的第二原始状态标识，若不相同，则根据所述计费请求查找相应的计费节点；向所述计费节点发送业务恢复请求，使得所述计费节点对所述计费节点上对应的承载业务进行恢复。此外，本发明还提供了实现该方法的相应装置以及系统。
文档编号H04W4/24GK102802143SQ20111013854
公开日2012年11月28日 申请日期2011年5月26日 优先权日2011年5月26日
发明者荣传湘 申请人:华为软件技术有限公司