一种计费方法及设备与流程

本申请涉及通信领域，尤其涉及一种计费方法及装置。
背景技术：
：目前在线计费的基本机制是：计费触发功能(chargingtriggerfunction，ctf)向在线计费系统(onlinechargingsystem，ocs)申请预留某一费率组(ratinggroup)的配额，ocs授予配额，ctf执行配额管理、配额使用及计费信息采集，并在监测到计费上报条件(触发条件)满足时，向计费系统上报所采集的计费信息。在4g网络中，位于网关的策略和计费执行功能(policyandchargingenforcementfunction，pcef)为ctf，pcef会根据策略和计费规则功能(policyandchargingrulesfunction，pcrf)下发的计费策略确定计费模式(在线计费或离线计费)、统计方法(流量或时长等)、费率组(ratinggroup，本申请称之为chargingkey)、上报粒度等。其中，计费粒度包括：service_identifier_level或rating_group_level，如果计费粒度为rating_group_level，则pcef必须为每个费率组上报计费信息，如果计费粒度为service_identifier_level，则pcef必须为每个费率组和业务标识上报计费信息。随着数据流量的剧增，对移动网络提出了新的挑战。为了应对此挑战，演进出了控制面和用户面分离的移动数据网架构。在此架构下，控制面只做控制，可以集中部署；数据流在用户面通过，分布式部署。用户可以就近接入用户面，减少数据在网络中的传输距离，减小网络时延，提高网络效率。目前，4g网络下已经扩展了控制面和用户面分离的网络架构，可以一定程度上实现对于控制面和用户面分离的网络架构下计费。如图1所示，servinggateway-c、pdngateway-c、tdf-c属于控制面，servinggateway-u、pdngateway-u、tdf-u属于用户面。一般来说，控制面是计费触发点，完成计费触发功能，用户面是计费采集点，完成计费采集功能，在此架构下，控制面的数量和用户面在运行态的数量是1比1的关系。然而，随着移动流量剧增、接入设备量剧增、业务对带宽时延等的增强需求，逐渐演变出了面向未来业务需求的较为复杂的网络架构，例如随着用户的移动、用户面负荷的压力、用户业务的特殊需求，使得用户所接入的用户面可能会出现较为频繁的切换，或者，一个用户同时会有多个用户面，用户的业务数据流在不同用户面之间迁移，目前的计费机制无法在这样的场景下实现准确的计费处理。技术实现要素：本申请的实施例提供一种计费方法，主要解决在网络控制和数据流转发分离架构中，一个pdusession的用户面发生切换时，或者一个pdusession存在多个用户面时，用户的业务数据流在用户面之间迁移的计费处理。第一方面，提供一种计费方法，该方法包括：控制面功能实体cp确定用户设备ue在第一数据会话上传输的数据流需要迁移到第二数据会话上，所述第一数据会话是ue和第一用户面功能实体up间的数据会话，所述第二数据会话是所述ue和第二up间的数据会话，所述第一up和第二up为所述cp对应的up，所述第一数据会话和第二数据会话对应同一个pdusession；所述cp获取第一up统计的所述数据流迁移前的计费信息；所述cp确定需要向第二up下发的所述数据流迁移后使用的配额，并下发给第二up。基于该方案，cp获取数据流迁移前up上的计费信息，并进一步确定迁移后需要给目标up下发的配额并下发，实现用户的业务数据流在用户面之间迁移的计费处理的连续性。可选的，所述cp通过与计费系统之间的第一计费会话对所述第一up上的所述数据流计费，所述cp确定所述数据流从第一up迁移到第二up后，所述第一up上无使用所述数据流对应的chargingkey的其他数据流；所述cp为第二up上所述数据流使用所述第一计费会话进行计费，基于该方案，可以不改变切换后的计费会话。可选的，所述cp获取第一up统计的所述数据流迁移前的计费信息，确定需要向第二up下发的配额并下发给第二up，包括：所述cp接收第一up上报的所述数据流迁移前的计费信息，向计费系统上报所述计费信息，并为第二up申请用于所述数据流的配额；所述cp接收所述计费系统下发的所述配额；所述cp根据所述计费系统下发的配额，生成向第二up下发的配额，基于该方案，计费系统感知到迁移的发生，可以对up的切换计费进行更加准确的配额控制。可选的，所述cp获取第一up的计费信息，确定需要向所述第二up下发的配额，包括：所述cp根据获取的第一up统计的所述数据流迁移前的计费信息，确定剩余的可用配额，并根据所述剩余的可用配额生成向第二up下发的配额。基于该方案，计费系统不需要感知到up的切换，或者数据流的迁移，可以减轻计费系统的负担。可选的，所述方法还包括：所述cp缓存第一up上报的所述数据流迁移前的计费信息；所述cp接收第二up上报的所述数据流迁移后的计费信息；所述cp合并所述第二up上报的计费信息和所缓存的第一up上报的计费信息，将合并后的计费信息上报给计费系统。可选的，所述方法还包括：所述cp将第一up上报的所述数据流迁移前的计费信息发送给第二up，使得第二up基于所述第一up上报的所述数据流迁移前的计费信息，继续统计所述数据流迁移后的计费信息；所述cp接收第二up在满足上报条件时上报的所述数据流迁移前和迁移后的计费信息，并上报给计费系统。可选的，所述cp根据所述计费系统下发的指示，确定所述pdusession上的数据流从第一up迁移到第二up后，向计费系统上报所述数据流迁移前的计费信息。基于该方案，计费系统可以设置数据流切换相关的计费上报指示下发给cp，增强计费的灵活性。可选的，所述cp获取第一up统计的所述数据流迁移前的计费信息，包括：所述cp接收第一数据会话中断触发第一up上报的计费信息。可选的，所述cp获取第一up统计的所述数据流迁移前的计费信息，包括：所述cp检测到第二up上报的所述数据流对应的数据流开始事件后，获取第一up上统计的所述数据流迁移前的计费信息。可选的，所述方法进一步包括：所述cp通过与计费系统之间的第一计费会话对所述第一up上的所述数据流计费，所述cp确定所述数据流从第一up迁移到第二up后，所述第一up上存在使用所述数据流对应的chargingkey的其他数据流；所述cp为第二up上所述数据流使用所述第一计费会话；所述cp同时从所述第一up和第二up上获取所述数据流的计费信息。这里的“其他”是指相对于迁移过去的数据流，没有迁移过去的，叫做“其他”数据流，它们都是cp建立的pdusession上的数据流。基于该方案，可以实现sscmode3下的数据流准确计费，确保跨ck的数据流不因为up的切换而被忽略。可选的，所述cp进一步确定需要向第一up下发的配额，所述方法包括：所述cp将计费系统为所述chargingkey下发的配额分割成多个子配额并分别下发给所述第一up和第二up。可选的，所述方法进一步包括：所述cp在任一个up上所述配额用完并上报所述配额对应的计费信息后，获取其他up上统计的所述配额对应的计费信息；所述cp合并所述配额对应的计费信息，并上报给计费系统。可选的，所述方法进一步包括：所述cp在任一个up上所述配额用完并上报所述配额对应的计费信息后，获取其他up上统计的所述配额对应的计费信息；所述cp缓存所有up上报的所述配额对应的计费信息，确定所述配额的剩余可用量，重新分配所述配额的剩余可用量，并向第一up和第二up下发所述重新分配的配额；所述cp在所述配额用完或者所述配额的剩余可用量满足上报阈值时，合并所述缓存的所述配额对应的计费信息，并向计费系统上报所述合并的计费信息。可选的，所述方法进一步包括，所述cp通过与计费系统之间的第一计费会话对所述第一up上的所述数据流计费；所述cp确定所述数据流从第一up迁移到第二up后，所述第一up上存在使用所述数据流对应的chargingkey的其他数据流；所述cp为第二up上传输所述数据流的第二数据会话使用第二计费会话，通过第二计费会话向计费系统申请配额，并将申请的配额下发给第二up；所述第二计费会话是所述cp与计费系统为所述第二up上的第二数据会话建立的计费会话。基于该方案，通过新建一个专门为目标up计费的计费会话，来实现高效准确的计费，降低cp在配额处理上的负担。第二方面，提供一种计费方法，所述方法包括：控制面功能实体cp从第一用户面功能实体up和第二up上获取所述cp对应的一个pdusession上的数据流的计费信息，所述第一up和第二up为所述cp对应的up；所述cp将计费系统下发的配额分割成多个子配额，并分别下发给所述第一up和第二up。基于该方案，cp可同时对其对应的两个up上产生的数据流进行计费。可选的，所述第一up和第二up上存在使用相同chargingkey的数据流；所述cp同时从所述第一up和第二up上获取所述数据流的计费信息；对于diameter协议接口的情形，所述cp通过与计费系统间的一个计费会话对第一up和第二up进行计费。可选的，所述cp将计费系统下发的配额分割成多个子配额并下发给up，包括：所述cp将计费系统为所述chargingkey下发的配额分割成多个子配额并分别下发给所述第一up和第二up。可选的，所述方法进一步包括：所述cp在任一个up上所述配额用完并上报所述配额对应的计费信息后，获取其他up上统计的所述配额对应的计费信息；所述cp合并所述配额对应的计费信息，并上报给计费系统。可选的，所述方法进一步包括：所述cp在任一个up上所述配额用完并上报所述配额对应的计费信息后，获取其他up上统计的所述配额对应的计费信息；所述cp缓存所有up上报的所述配额对应的计费信息，确定所述配额的剩余可用量，重新分配所述配额的剩余可用量，并向第一up和第二up下发所述重新分配的配额；所述cp在所述配额用完或者所述配额的剩余可用量满足上报阈值时，合并所述缓存的所述配额对应的计费信息，并向计费系统上报所述合并的计费信息。第三方面，提供一种计费方法，包括以下步骤：在线计费系统ocs向控制面功能实体cp下发指示信息，所述指示信息用于指示cp在所述cp对应的用户面功能实体up从第一up切换为第二up后，向所述ocs上报所述第一up切换前的计费信息；所述ocs接收所述cp上报的所述第一up统计的切换前的计费信息。可选的，所述指示信息随所述ocs下发给所述cp的配额一起下发。可选的，所述ocs接收所述cp上报的计费信息后，向所述cp下发给第二up，或同时给第一up和第二up的配额。第四方面，提供一种计费设备，包括判断模块，获取模块和处理模块：所述判断模块，用于确定用户设备ue在第一数据会话上传输的数据流需要迁移到第二数据会话上，所述第一数据会话是ue和第一用户面功能实体up间的数据会话；所述第二数据会话是所述ue和第二up间的数据会话，所述第一up和第二up是所述计费设备对应的up，所述第一数据会话和第二数据会话对应同一个pdusession；所述获取模块，用于获取第一up统计的所述数据流迁移前的计费信息；所述处理模块，用于确定需要向第二up下发的所述数据流迁移后使用的配额，并下发给第二up。可选的，还包括所述会话模块，用于与计费系统建立第一计费会话，并通过所述第一计费会话对所述第一up上的所述数据流计费，所述判断模块还用于确定所述数据流从第一up迁移到第二up后，所述第一up上无使用所述数据流对应的chargingkey的其他数据流，所述会话模块进一步用于为第二up上所述数据流使用所述第一计费会话进行计费。可选的，所述获取模块用于接收第一up上报的所述数据流迁移前的计费信息，并通过所述会话模块向计费系统上报所述计费信息，为第二up申请用于所述数据流的配额；所述会话模块用于接收所述计费系统下发的所述配额；所述处理模块根据所述计费系统下发的配额，生成向第二up下发的配额。可选的，所述处理模块用于根据获取的第一up统计的所述数据流迁移前的计费信息，确定剩余的可用配额，并根据所述剩余的可用配额生成向第二up下发的配额。可选的，所述获取模块用于接收第一数据会话中断触发第一up上报的计费信息。可选的，所述获取模块用于获取第二up上报的所述数据流对应的数据流开始事件后，第一up上统计的所述数据流迁移前的计费信息。可选的，还包括会话模块，用于与计费系统建立第一计费会话，并通过所述第一计费会话对所述第一up上的所述数据流计费，所述判断模块用于确定所述数据流从第一up迁移到第二up后，所述第一up上存在使用所述数据流对应的chargingkey的其他数据流；所述获取模块进一步用于同时从所述第一up和第二up上获取所述数据流的计费信息。可选的，还包括会话模块，用于与计费系统建立第一计费会话，并通过所述第一计费会话对所述第一up上的所述数据流计费，所述判断模块进一步用于确定所述数据流从第一up迁移到第二up后，所述第一up上存在使用所述数据流对应的chargingkey的其他数据流；所述会话模块进一步用于为第二up上传输所述数据流的第二数据会话建立和计费系统的第二计费会话，通过第二计费会话向计费系统申请配额，所述处理模块进一步用于并将申请的配额下发给第二up。第五方面，提供一种计费系统，包括下发模块和接收模块，所述下发模块，用于向控制面功能实体cp下发指示信息，所述指示信息用于指示cp在所述cp对应的用户面功能实体up从第一up切换为第二up后，向所述ocs上报所述第一up切换前的计费信息；所述接收模块，用于接收所述cp上报的所述第一up统计的切换前的计费信息。第六方面，提供一种计算设备，实现中可以是cp，对应5g中的smf功能实体，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当该计算设备运行时，该处理器执行该存储器存储的该计算机执行指令，以使该计算设备执行如上述第一方面或者第二方面中任一所述的计费方法。第七方面，提供一种计算设备，实现中可以是ocs功能实体，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当该计算设备运行时，该处理器执行该存储器存储的该计算机执行指令，以使该计算设备执行如上述第三方面中任一所述的计费方法。第八方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面，第二方面或者第三方面中任意一项的计费方法。第九方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述第一方面，第二方面或者第三方面任意一项的计费方法。其中，第二方面至第九方面中任一种设计方式所带来的技术效果可参见第一方面中或者实施例中不同设计方式所带来的技术效果描述，此处不再赘述。第十方面，提供一种网络系统，包括如上述任一方面所述的计费设备和如上述任一方面所述的计费系统。本申请的上述方面或其他方面在以下实施例的描述中会更加简明易懂。本发明实施例的方案，实现了在较为复杂的控制面和用户面分离场景下，例如，一个pdusession的用户面发生切换时，或者一个pdusession存在多个用户面时，用户的业务数据流在用户面之间迁移情况下的计费，使得计费可以支撑业务端到端的更低时延、且提高了网络的效率的优化部署，实现优化部署下数据业务的精准计费，提高网络效率和用户体验。附图说明图1是现有技术中控制面和用户面分离的网络架构的示意图；图2是依据本申请一实施例的网络架构的示意图；图3是依据本申请一实施例的计算机设备300的硬件结构示意图；图4是依据本申请一实施例的计费方法400的示范性流程图；图5是依据本申请一实施例的计费方法500的示范性流程图；图6是依据本申请一实施例的计费方法600的示范性流程图；图7是依据本申请一实施例的计费方法700的示范性流程图；图8是依据本申请一实施例的计费方法800的示范性流程图；图9是依据本申请一实施例的计费方法900的示范性流程图；图10是依据本申请一实施例的计费方法1000的示范性流程图；图11是依据本申请一实施例的计费方法1100的示范性流程图；图12是依据本申请一实施例计费设备1200的一种可能的结构示意图；图13是依据本申请一实施例计费系统1300的一种可能的结构示意图。具体实施方式本申请实施例涉及的网元名称本身不对设备构成限定。具体来说，会话管理功能这个名字本身对设备不构成限定，实际中，可以为其他名字，比如：up(userplane)用户面功能这个名字本身对设备不构成限定，实际中，可以为其他名字，比如：用户面功能实体(userplanefunctionentity)。在线计费系统这个名字本身对设备不构成限定，实际中，可以为其他名字，比如：计费系统，或其他名字。在此进行统一说明，以下不再赘述。本申请实施例方案以5g网络为例，但使用范围不限5g网络，部分4g，或者4g到5g网络的过渡网络也可能使用，也可以应用到未来的可能的其他通信或者计费系统中，只要存在同一个pdusession(或者类似的数据连接)的用户面发生切换，或者一个pdusession存在多个用户面时，用户的业务数据流在用户面之间迁移的场景，相应的计费方法都可以采用本发明相关实施例的方案。图2是依据本申请一实施例的网络架构的示意图。其中，smf为会话管理功能(sessionmanagementfunction)，pcf为策略控制功能(policycontrolfunction)，upf为用户面功能(userplanefunction)，ocs为在线计费系统(onlinechargingsystem)，ue为用户设备(userequipment)。smf与pcf之间通过n7接口通信，smf与upf之间通过n4接口通信，不同upf之间通过n9接口通信。smf的功能包括协议数据单元(protocoldataunit，pdu)会话(session)的管理，如建立、修改和释放；ue的互联网协议(internetprotocol，ip)地址分配；upf选择；upf路由策略配置；获取pcf的控制策略，并执行该控制策略的控制面部分；确定在ip类型下，pdusession的业务及会话连续性(serviceandsessioncontinuity，ssc)模式(称为sscmode)，具体的，pdu会话有三种ssc模式mode，分别为：ssc模式1、ssc模式2以及ssc模式3；sscmode1：在该模式下，终端建立pdu会话之后，无论终端移动到任何区域或者任何接入技术下，该pdu会话的upf网元均作为锚点，为该终端服务，即该pdu会话不会由于终端的移动发生任何形式的中断。sscmode2：在该模式下，终端建立pdu会话之后，当终端移动，如果终端离开了upf网元的服务区域，或者因为upf网元故障，负载过大等原因，网络可以为终端的该pdu会话重选upf网元，并使终端建立重选upf网元后的pdu会话，用户的业务会从原upf迁移到新的upf。在这种模式下，upf网元可以认为是有特定服务区域的，当终端在该服务区域移动时，该upf网元为终端服务，而如果终端离开了这个服务区域，则网络侧可以确定该upf网元则不能为终端服务，原通过该upf网元建立的pdu会话将会发生中断，同时和新的upf建立pdu会话。sscmode3:在该模式下，终端建立pdu会话之后，upf网元的服务区域也是有范围的，当终端离开了upf网元的服务区域后，网络为终端选择新的upf网元为该终端服务，终端通过该新的upf网元与原dn网元建立pdu会话，但是与上述ssc模式2不同的是，终端通过旧的upf网元建立的pdu会话可以暂时不释放连接，而是在新的pdu会话建立完成后再释放。upf的功能包括完成与外部数据网交互的锚点功能(具有锚点功能的upf称为upf锚点)；数据包路由和转发；数据包检测，并执行pcf激活的控制策略的用户面部分。pcf的功能包括生成并下发策略，或者激活smf上静态配置的策略，通过策略控制upf上路由的业务数据流的qos、门控、计费等。smf可以根据pcf下发的策略确定是否和ocs建立在线计费会话，以及确定业务数据流对应的chargingkey。ocs的功能包括根据smf的请求进行配额授予，并根据smf上报的配额使用信息进行余额扣减或返还。ue是具有用户永久身份(subscriberpermanentidentity，supi)或者国际移动用户识别码(internationalmobilesubscriberidentificationnumber，imsi)的设备，可以为具有sim/esim的手机、平板、电脑、iot设备、或者其他可以连接5g网络或者其他网络的设备。本申请中配额申请、分配、计费信息上报接口可以是diameter协议接口或者服务化接口，服务化接口如restful等，服务化接口的方式下，cp和计费系统间不建立计费会话，而是直接通过服务化消息进行交互，服务化消息(如：restful)是无状态的消息。本申请主要以diameter协议进行示例说明，但本申请并不限定消息格式，也可以使用restfulapi等其他格式。本申请中涉及的一些概念，进一步说明如下：控制面：执行pdusession管理、ip地址分配、用户面选择等功能，本申请称之为cp或者cp功能实体，在5g核心网中对应smf；用户面：执行数据包路由和转发、数据包检测等，本申请称之为up或者up功能实体，在5g核心网中对应upf。pdusession：(类似4g、4g/5g过渡网络的ip-cansession，后续描述中，一律用pdusession来表示相关或者类似概念)，pdusession是建立在ue和提供pdu连接业务的数据网络(datanetwork，dn)之间的，而连接dn的是upf，因此也可以说pdusession是建立在ue和upf之间的。pdusession的建立由smf控制，因此ue会向smf发送pdusession建立请求，smf来选择与ue建立连接的upf。一个pdusession可以存在/对应多个upf实体。cp、ocs和up可以通过计算机设备的形式实现。图3是依据本申请一实施例的计算机设备300的硬件结构示意图。如图3所示，计算机设备300包括处理器302、存储器304、通信接口306和总线308。其中，处理器302、存储器304和通信接口306通过总线308实现彼此之间的通信连接。处理器302可以采用通用的中央处理器(centralprocessingunit，cpu)，微处理器，应用专用集成电路(applicationspecificintegratedcircuit，asic)，或者一个或多个集成电路，用于执行相关程序，以实现本申请实施例所提供的技术方案。存储器304可以是只读存储器(readonlymemory，rom)，静态存储设备，动态存储设备或者随机存取存储器(randomaccessmemory，ram)。存储器304可以存储操作系统3041和其他应用程序3042。在通过软件或者固件来实现本申请实施例提供的技术方案时，用于实现本申请实施例提供的技术方案的程序代码保存在存储器304中，并由处理器302来执行。通信接口306使用例如但不限于收发器一类的收发装置，来实现与其他设备或通信网络之间的通信。总线308可包括一通路，在各个部件(例如处理器302、存储器304、通信接口306)之间传送信息。当计算机设备300是cp时，处理器302执行存储器304中保存的用于实现本申请实施例提供的技术方案的程序代码，以实现图4至图11实施例所示的方法。当计算机设备300是ocs/ofcs时，处理器302执行存储器304中保存的用于实现本申请实施例提供的技术方案的程序代码，以实现图4至图10实施例所示的方法。本申请实施例，可以实现在一个pdusession的用户面发生切换时，或者一个pdusession存在多个用户面时，用户的业务数据流在用户面之间迁移情况下，对数据业务的精准计费，提高网络效率和用户体验。图4是依据本申请一实施例的计费方法400的示范性流程图。计费方法400可以由图2所示的smf(cp)、ocs、或upf(up)来执行。s401，控制面功能实体cp确定ue在第一数据会话上传输的数据流需要迁移到第二数据会话上，所述第一数据会话是cp建立的ue和第一up(up1)间的数据会话；所述第二数据会话是所述ue和第二up(up2)间的数据会话，所述第一up和第二up为该cp对应的up，所述第一数据会话和第二数据会话对应同一个pdusession；所述cp通过与计费系统之间的第一计费会话对所述第一up上的所述数据流计费；ue和数据网络之间的数据流传输是通过建立的pdusession来实现的，pdusession是建立在ue和提供pdu连接业务的数据网络(datanetwork，dn)之间的。pdusession的建立由控制面功能实体cp，如smf控制，因此ue会向cp发送pdusession建立请求，cp来选择与ue建立连接的up。由于存在一个pdusession的用户面发生切换，或者一个pdusession存在多个用户面时，用户的业务数据流在用户面之间迁移情况，将ue和用户面的pdusession迁移到不同的用户面上，或者同时建立到两个或以上用户面上，但是在迁移过程中，两个或者多个up是对应同一个cp，pdusession是不变的。这里所说的“不变”，或者说“同一个”pdusession，指的是该pdusession在up的变化过程中，控制面基本不变，具体为sessionid，ue的ip地址和接入点(dnn)不变。s402，cp获取第一up统计的所述数据流迁移前的计费信息；由于涉及到用户面的切换，业务数据流迁移到第二up,计费采集点也会产生变化，这种变化包括但不限于：计费采集点从第一up迁移到第二up，迁移后第二up作为唯一的计费采集点；或者迁移后第一up和第二up同时作为计费采集点。cp获取迁移完成之前(包括迁移过程中)第一up上的计费信息，如果ue和第一up的数据连接在迁移完成后依然存在的话，cp还可以继续获取第一up的计费信息，用于迁移期间或者迁移后的配额管理，保证计费过程的连续性和准确性；计费信息的具体的获取方式，可以是第一up主动上报，也可以是cp向第一up发送获取请求来获取；触发方式也可以有多种实现，例如迁移的发生(决策迁移或实际发生迁移，如第一up会话释放)会触发第一up主动上报；也可以是cp检测到第二up开始传输业务数据流后，向第一up请求上报等；具体可以通过在cp或者up上配置相关触发条件(trigger)实现。s403，cp确定需要向第二up下发的所述数据流迁移后使用的配额并下发给第二up。对于在线计费的情况，cp需要确定给第二up下发的配额，以保证在第二up上产生的流量可以被统计和计费；具体的，根据ocs对迁移是否感知，cp可以自主确定向第二up下发的配额(ocs不感知up迁移)或者向ocs申请新配额(ocs感知到up迁移，因为迁移，导致需要进行配额的重新下发)。根据本申请实施例提供的技术方案，cp决策要进行up迁移后，会获取迁移前up的计费信息，并进一步确定迁移后需要给目标up下发的配额并下发，从而实现一个控制面对应多个用户面的cu分离场景下，用户面迁移时的计费，保证了计费的连续性和准确性。下面结合更多的具体实现，说明承载数据流的up发生变化情况下的计费处理过程。本发明实施例中，数据流为某一pdusession的数据流，迁移过程中，pdusession不变，第一up(up1)是迁移前up，第二up(up2)是迁移后up。承载数据流的up发生变化包括如下情况之一：情况a:cp先拆除与ue与up1的连接,再建立ue和up2的连接，即：一个pdusession同时只对应一个up。sscmode2的情形属于情况a；情况b:cp建立ue和up2的连接,但并未拆除和up1的连接，即：一个pdusession同时会对应有多个up。cp可以是等业务数据流全部迁移到up2上后再拆除和up1的连接(pdusession的所有数据流全部迁移)，或者不拆除up2的连接，而是用up2的连接承载部分业务流量(pdusession的数据流部分迁移)。sscmode3的情形属于情况b；上述a,b两种情况下，cp都作为ctf和计费系统进行交互，为pdusession建立计费会话，up向cp上报采集到的计费信息。针对情况a，cp先中断ue与up1的pdusession，然后建立ue与up2的pdusession，此时数据流的up发生了变化,下面根据ocs是否感知到数据流在up间迁移，详细描述情况a下的计费处理方法：a1、ocs感知数据流在up间迁移的计费处理方法，参考附图5：步骤501：cp确定要改变数据流的up，cp将首先中断ue与up1的pdusession，并建立ue与up2的pdusession；(执行计费信息采集的up发生变化)步骤502：cp发起中断up1上的pdusession，并接收up1上报的计费信息，具体的，cp发起释放up1的pdusession，并建立up2的pdusession。up1上的pdusession释放流程触发up1向cp上报计费信息；up1的上报信息中包括上报原因(即：触发上报的触发条件)，这里的上报原因为pdusessionrelease。上报信息格式示例：配额对应id上报原因(reportingtrigger)计费信息(measurementinformation)步骤503：cp根据up1上报的计费信息，生成向ocs上报的计费信息，并向ocs上报，上报原因指明为up变化，同时申请第二up上该数据流使用的新配额；上报信息中携带up1信息(如ip地址)。上报格式示例：diameter格式如果是restful格式，则消息示例如下；步骤504：ocs向cp下发授予的用于第二up上该数据流的新配额；步骤505：cp根据该新配额，生成向up2下发的信息，该信息携带新配额对应信息，并向up2下发该生成的信息，以使得up2为后续的数据流使用该新配额。cp在up2上建立该pdusession时或者在up2上完成该pdusession建立且数据流传输之前，向up2下发根据ocs授予的新配额生成的信息。下发信息包括数据流检测规则和新配额对应的门限信息，并且携带了二者的关联信息。本发明实施例的方案，实现了网络控制和数据流转发分离架构中，一个pdusession的用户面发生切换时的计费处理，在ue和up1的pdusession释放后，触发up1向cp上报计费信息，cp进一步向ocs上报up1的计费信息，上报原因指明为up变化，并申请新配额给up2，实现了ocs可感知数据流在up间的迁移计费处理。由于ocs感知到数据流在up面的迁移，可以使得ocs对不同up上的业务数据流使用执行不同的费率以支持更为灵活和合理的计费，并且也降低了cp参与配额管理的负担。a2：ocs不感知数据流在up间迁移的计费处理方法，参考附图6，具体步骤说明如下：步骤601：cp确定要改变数据流的up(执行计费信息采集的up发生变化)，cp将首先中断ue与up1的pdusession，并建立ue与up2的pdusession；步骤602：cp发起中断up1上的pdusession，并接收up1上报的计费信息；具体的，cp发起释放up1的pdusession，并建立up2的pdusession。可以是up1上的pdusession释放流程触发up1向cp上报计费信息。up1的上报信息中包括上报原因(即：触发上报的条件)，这里的上报原因为pdusessionrelease。步骤603：cp根据up1上报的该数据流的计费信息，确定剩余可用配额，并根据该剩余可用配额生成向up2下发的信息，该信息携带该剩余可用配额对应信息。cp根据up1上报的计费信息确定剩余可用配额的方法为如下之一：如果cp向up1下发该配额时，缓存了配额信息，则up1可以只上报配额的使用信息，cp根据所缓存的配额信息减去up1上报的配额的使用信息，即为剩余可用配额；上报信息格式示例：配额对应id上报原因(reportingtrigger)计费信息：{usageinformation}如果cp向up1下发该配额时，未缓存配额信息，则up1同时上报配额的使用信息和剩余配额值，cp把接收到的up1上报的剩余配额值作为剩余可用配额。上报信息格式示例：配额对应id上报原因(reportingtrigger)计费信息：{usageinformation，remainderquota}cp在得到剩余可用配额后，进一步，还判断是否满足向ocs上报的条件，该判断是基于ocs所下发的触发条件来判断，比如：剩余配额刚好低于ocs所规定的门限，则满足向ocs上报的条件。如果满足则基于up1的上报生成向ocs上报的信息，正常向ocs上报并申请新配额，上报的原因指明所满足的触发条件。若未满足向ocs上报的条件，则根据该剩余可用配额生成向up2下发的信息，该信息携带该剩余可用配额对应信息。步骤604：cp向up2下发携带所述剩余可用配额的信息，以使得up2为后续的数据流使用该剩余可用配额；cp在up2上建立该pdusession时或者在up2上完成该pdusession建立且数据流传输之前，向up2下发根据剩余可用配额生成的信息。cp对up1所上报的计费信息进行如下任一方法处理：a.cp缓存up1上报的使用信息；b.cp将up1上报的信息也同时下发给up2，up2在此基础上继续统计。步骤605：cp接收up2在上报条件满足时上报的使用信息，并根据up1和up2上报的使用信息生成向ocs上报的信息，并向ocs上报。具体的，若cp缓存up1上报的计费信息，则cp将up2上报的使用信息和所缓存的up1上报的使用信息进行合并，生成向ocs上报的计费信息，并向ocs上报；若之前cp将up1上报的信息也同时下发给了up2，则up2基于up1的使用信息继续累积，并合并上报，cp根据up2上报的计费信息生成向ocs上报的计费信息，并向ocs上报。本发明实施例的方案，实现了网络控制和数据流转发分离架构中，一个pdusession的用户面发生切换时的计费处理，在ue和up1的pdusession释放后，触发up1向cp上报计费信息，cp根据up1上报的计费信息，自主处理数据流迁移后剩余配额的使用，ocs对于up的迁移不感知，在ocs无需基于up执行计费处理时，减少了向ocs上报的信令数量，降低了ocs的负担。a3、cp可以根据ocs指示，确定使用上述a1或者a2实施例中的相关计费方法，具体的，ocs据自身决策或者运营商配置，可以单独或者在向cp下发配额时，随配额一起下发指示up变化的触发条件(trigger)。该触发条件用于指示cp，在使用该配额的up发生变化时，向ocs发起重授权。具体步骤说明如下：步骤1：cp确定要改变数据流的up(执行计费的up发生变化)，cp将首先中断ue与up1的pdusession，并建立ue与up2的pdusession；步骤2：cp发起中断up1上的pdusession，并接收up1上报的计费信息；up1上的pdusession释放流程触发up1向cp上报计费信息。up1的上报信息中包括上报原因(即：触发上报的条件)，这里的上报原因为pdusessionrelease；步骤3：若ocs为该配额下发了指示up变化的触发条件，则up1的上报使得该触发条件满足，cp执行a1的步骤503～505；若ocs没有为该配额下发指示up变化的触发条件，cp执行a2的步骤603～605。通过ocs在向cp下发配额时，根据自身决策或者运营商配置，随配额一起下发指示up变化的触发条件，可以增强计费的灵活性，提升ocs的自主权，进而在需要对不同up上的业务数据流使用执行不同的费率以支持更为灵活和合理的计费时，指示cp上报数据流在up间的迁移，在ocs无需基于up执行计费处理时，cp不上报数据流在up间的迁移，以减少信令。下面描述情况b,即cp建立ue与up2的pdusession，但并未拆除和up1的连接，即：一个pdusession同时会对应有多个up，此时数据流的up发生了变化，分两种情况进行处理：b1：在建立ue到up2的pdusession后，若up1上的业务数据流是以chargingkey(ck)为粒度迁移到up2的，包括：up1上的数据流全部迁移到up2，如表1示例；表1以及包括：up1上部分chargingkey(如ck2)对应的数据流迁移到up2，如表2示例；表2cp可以在迁移时或者迁移后判断一个chargingkey的数据流是否跨up，也可以下发路由表的时候就已经考虑了是否跨up的情况，即可以在生成路由策略时通过路由表控制，具体方法可以是：cp根据其为up1及up2生成的路由表，以及pcf下发的chargingkey对应的流模板，判断一个chargingkey所对应的流模板所覆盖的内容，是否被分割到up1和up2的路由表，进而确定一个chargingkey下的数据流是否跨up。本实施例中，cp判断业务数据流是以ck为粒度跨up的情况下，计费的具体方法如下：b11、ocs感知数据流在up间迁移的计费处理方法，参考附图7，步骤701：cp确定要改变数据流的up(执行计费的up发生变化)；步骤702：cp发起建立up2上的pdusession；步骤703：up2上的pdusession建立成功后，smf通知ue,ue发起将发送的上行数据流到up2的pdusession上，up2在接收到上行流时，触发startofsdf(业务数据流开始)事件，并将该事件上报给cp；步骤704：cp在接收到up2上报的startofsdf事件后，向up1发送请求上报计费信息的消息，并接收up1上报的计费信息；up1的上报信息中包括上报原因(即：触发上报的条件)，这里的上报原因为pdusessionrelease。上报信息格式示例：配额对应id上报原因(reportingtrigger)计费信息(measurementinformation)步骤705：cp根据up1上报的计费信息，生成向ocs上报的计费信息，并向ocs上报，上报原因指明为up变化，同时申请新配额；上报信息中携带up1信息(如ip地址)。上报格式示例：步骤706：ocs向cp下发新配额；步骤707：cp根据该新配额，生成向up2下发的信息，该信息携带新配额对应信息，并向up2下发该生成的信息，以使得up2为后续的数据流使用该新配额；后续cp收到up1的terminationofsdf事件后，触发释放ue和up1之间的pdusession。b12、ocs不感知数据流在up间迁移的计费处理方法，如附图8所示，具体步骤描述如下：步骤801：cp确定要改变数据流的up(执行计费收集的up发生变化)；步骤802：cp发起建立up2上的pdusession；具体的，cp发起up2的pdusession建立流程。步骤803：up2上的pdusession建立成功后，ue将发送的上行数据流迁移到up2的pdusession上，up2在接收到上行流时，触发startofsdf事件，并将该事件上报给cp；步骤804：cp在接收到up2上报的startofsdf事件后，向up1发送请求上报计费信息的消息，并接收up1上报的计费信息；up1的上报信息中包括上报原因(即：触发上报的条件)，这里的上报原因为pdusessionrelease。步骤805：cp根据up1上报的该数据流的计费信息确定剩余可用配额，并根据该剩余可用配额生成向up2下发的信息，该信息携带该剩余可用配额对应信息；cp根据up1上报的计费信息确定剩余配额的方法为如下之一：a.如果cp向up1下发该配额时，缓存了配额信息，则up1只上报配额的使用信息，cp根据所缓存的配额信息减去up1上报的配额的使用信息，即为剩余可用配额；上报信息格式示例：配额对应id上报原因(reportingtrigger)计费信息：{usageinformation}b.如果cp向up1下发该配额时，未缓存配额信息，则up1同时上报配额的使用信息和剩余配额值，cp把接收到的up1上报的剩余配额值作为剩余可用配额。cp在得到剩余可用配额后，进一步，还判断是否满足向ocs上报的条件，该判断是基于ocs所下发的触发条件来判断，比如：剩余配额刚好低于ocs所规定的门限，则满足向ocs上报的条件。如果满足则基于up1的上报生成向ocs上报的信息，正常向ocs上报并申请新配额，上报的原因指明所满足的触发条件。若未满足向ocs上报的条件，则根据该剩余可用配额生成向up2下发的信息，该信息携带该剩余可用配额对应信息。步骤806：cp向up2下发该生成的信息，该信息携带所述剩余可用配额，以使得up2为后续的数据流使用该剩余可用配额；cp对up1所上报的计费信息进行如下任一方法处理：–cp缓存up1上报的使用信息；–cp将up1上报的信息也同时下发给up2，up2在此基础上继续统计。步骤807：cp接收up2在上报条件满足时上报的使用信息，并根据up1和up2上报的使用信息生成向ocs上报的信息，并向ocs上报。具体的，若cp缓存up1上报的计费信息，则cp将up2上报的使用信息和所缓存的up1上报的使用信息进行合并，生成向ocs上报的计费信息，并向ocs上报。若之前cp将up1上报的信息也同时下发给了up2，则up2基于up1的使用信息继续累积，并合并上报，cp根据up2上报的计费信息生成向ocs上报的计费信息，并向ocs上报。本发明b11，b12实施例的方案，cp以up2上报的startofsdf事件作为up2的pdusession建立成功并开始数据传输的标志，并以此触发向up1发送请求上报计费信息的消息，实现了一个pdusession同时对应有多个up，并且同一个chargingkey的数据流不跨up的情形下计费，b11和b12的方案进一步区分了ocs是否感知迁移的处理方式，使得计费的处理更加灵活。b13、cp根据ocs指示，确定使用上述b11或b12的方法ocs在向cp下发配额时，根据自身决策，可以随配额一起下发指示up变化的触发条件，或者不下发该触发条件。该触发条件用以指示cp，在使用该配额的up发生变化时，向ocs发起重授权，具体步骤如下：步骤1：cp确定要改变数据流的up(执行计费的up发生变化)；步骤2：cp发起建立up2上的pdusession步骤3：ue将发送的上行数据流迁移到up2的pdusession上，up2在接收到ue的上行流时，触发startofsdf事件，并将该事件上报给cp；步骤4：cp在接收到up2上报的startofsdf事件后，向up1发送请求上报计费信息的消息，并接收up1上报的计费信息；up1的上报信息中包括上报原因(即：触发上报的条件)，这里的上报原因为pdusessionrelease。步骤5：若ocs为该配额下发了指示up变化的触发条件，则up1的上报使得该触发条件满足，则cp执行b11的步骤705～707；若ocs没有为该配额下发指示up变化的触发条件，则cp执行b12的步骤805～807。本发明b13实施例的方案，通过ocs在向cp下发配额时，根据自身决策或者运营商配置，随配额一起下发指示up变化的触发条件，可以增强计费的灵活性，提升ocs的自主权，进而在需要对不同up上的业务数据流使用执行不同的费率以支持更为灵活和合理的计费时，指示cp上报数据流在up间的迁移，在ocs无需基于up执行计费处理时，cp不上报数据流在up间的迁移，以减少信令。b2：在建立up2的pdusession后，若up1上的业务数据流是部分迁移到up2，且一个chargingkey对应的业务数据流会跨up，即：在一段时间内(一般是up2发送startofsdf事件后,到up1发送terminationofsdf事件之前)，up1和up2上会同时有同一chargingkey的业务数据流)，如下表3示意：表3cp可以在迁移后判断一个chargingkey的数据流是否跨up，也可以在生成路由策略时通过路由表控制，具体方法可以是：cp根据其为up1及up2生成的路由表，以及pcf下发的chargingkey对应的流模板，判断一个chargingkey所对应的流模板所覆盖的内容，是否被分割到up1和up2的路由表，进而确定一个chargingkey下的数据流是否跨up，上述表3的例子中，ck1对应的sf1数据流跨越了up。计费方面的具体处理方法如下：b21、cp进行配额的管理，包括对配额的使用和上报进行控制；对于服务化协议接口的方式(如restful)，cp和ocs可以直接通过服务化消息进行交互；对于diameter协议的接口，一个pdusession使用一个计费会话，即不因为数据流的迁移而增加新的计费会话，参考附图9，需要说明的是，下述步骤中，不涉及cp和ocs交互的部分，同样适用于服务化协议接口的方式。具体步骤说明如下：步骤901：cp确定采集计费信息的up；由于数据流迁移时up1和up2上同时存在有同一chargingkey的业务数据流，cp需要确定采集计费信息的up，具体的，cp根据pcf发送并激活的policy确定采集计费信息的up。这里up1和up2即cp确定的计费采集点。cp确定采集计费信息的up的时机，和cp确定ck数据流跨up的时机，并没有严格的时序关系。步骤902：cp处理ocs授予的配额；这里ocs授予的配额包括ocs新授予的配额(cp按照chargingkey向ocs申请配额)，或者cp获取的up1上的未使用的可用配额。由于多up是逻辑独立的，所以cp必须为每个up单独控制配额，包括：配额的下发、使用信息的上报。由于pcf下发的面向不同up的policy使用相同的chargingkey，而ocs是按照chargingkey分配配额，所以cp接收到的ocs分配的配额可能是跨up配额。为了防止ocs分配的配额跨up，或者跨up后还能正常的使用，具体方法如下：步骤9021.cp不管chargingkey是否跨up，均向ocs申请该chargingkey的配额；步骤9022.cp接收到ocs分配的配额后，在生成向up下发的规则时，判断该配额是否是多个up共享，具体的，cp可以根据该配额对应的chargingkey对应的数据流是否分布在不同的up来确定，若该chargingkey对应的数据流分布在多个up上，则意味着该配额多个up共享；步骤9023.cp若检测到一个配额跨up，则将该配额分割成小配额，为每个up均分割一个小配额，然后使用小配额生成向up下发的规则下发给up执行。cp记录这些分割后的小配额及与up的对应关系。步骤9024.cp接收任一up(如up1)在配额用完时或者上报条件满足时上报的计费数据，cp根据所保存的小配额与up的对应关系，向其他up发送请求上报该配额的使用信息，等收到所有up返回该配额的使用信息后，cp可以进行如下处理：cp将所有up上报的该配额的使用信息合并在一个消息中，向ocs上报。其中，该消息中的每个up的使用信息作为独立的容器，对于up1上报的信息对应的容器，包括所满足的trigger和对应的up标识，对于其他up上报的信息对应的容器，包括信息指明该上报是因为其他上报导致的，具体的，可以在容器中携带relatedtrigger，或者reportingreason的值指明是连带上报，同时携带对应的up标识；上报格式示例：或者，合并所有up上报的使用信息，并使用一个容器上报合并的使用信息。如果存在tariff-time-change，则合并时将每个up的上报信息中的tariff-time-change之前的部分合并，之后的部分合并。上报消息中还可以携带上报原因，该原因为：某一up导致的上报。消息示例：cp缓存各up上报的使用信息(该信息将在下次向ocs上报时一起上报给ocs)，将未使用的剩余可用配额汇总，再重新分割成小配额(每个up分配一个小配额)并下发给up继续使用。上述a)和b)可以选择一个实现；或者，上述a)和b)可以同时实现。如果是同时实现，则cp需要增加一步判断：若满足向ocs上报的条件(上报条件可以是ocs下发的重授权触发条件，或者配额的使用限制条件，如配额过期等)，则执行a)，否则执行b)。本发明b21实施例的方案，通过cp控制配额在多个up上的使用，协调了多up间配额共享使用，同时屏蔽了配额使用的复杂性对ocs的影响，从而提高了ocs的效率。b22、对于cp和计费系统之间采用diameter协议交互的情况，cp为up2建立一个新的在线计费会话；参考附图10，步骤1001：cp确定采集计费信息的up如果有多个up时，cp需要确定采集计费信息的up，具体的，cp接收pcf激活的policy，根据该policy确定采集计费信息的up，这里up1和up2都是计费信息采集点。步骤1002：cp确定会存在该pdusession的一个chargingkey对应的业务数据流会跨up，则为新建立的需要执行在线计费统计的up向ocs发起建立新的up2专有在线计费会话。附图仅为实例，需要说明的是cp确定采集计费信息的up的时机和cp确定ck数据流跨up的时机，并没有严格的时序关系。具体的，cp判断当前的sscmode，如果是sscmode3，推定为可能存在某个chargingkey对应的业务数据流会跨up，则为up2发起建立新的计费会话；或者，如果是sscmode3，且根据分配的路由信息，会出现某特定chargingkey对应的业务数据流会跨up1和up2，则为up2发起建立新的计费会话。若cp为pdusession增加一个bp或ulcl，则在确定需要执行在线计费统计的up后，同样执行上述判断，若会出现某特定chargingkey对应的业务数据流会跨up1和up2，则为up2或要执行在线计费功能的bp或ulcl发起建立新的计费会话。cp保存up和该计费会话的对应关系。此时，cp在新的计费会话中，为up2单独申请配额、管理配额使用、上报配额使用信息。步骤b1003：cp确定up1上pdusession拆除时或者up1上无数据流时，向ocs发起拆除up1对应的计费会话。拆除会话时或之前，向ocs上报up1上收集的配额使用信息。进一步的，若cp删除某一个up上的pdusession，则步骤如附图11所示，如下：步骤1101：cp确定删除up1上的pdusession；步骤1102：cp向up1下发信息，删除pdusession；步骤1103：cp接收up1上报的计费信息；步骤1104：cp根据所保存的up1和其对应计费会话的对应关系，向ocs发起该计费会话的结束请求，同时携带up1上报的使用信息；其他的up的在线计费会话不受up1上pdusession结束的影响，也不受up1对应在线计费会话结束的影响。本发明b22实施例的方案，通过cp分别为每个up建立独立的计费会话，降低了cp和ocs的实现复杂度，cp无需协调一个配额在多个up间的使用。方案c:本发明实施例还提供了一种计费方法，该方法从静态的角度描述了cp同时与其对应的两个up以及计费系统交互，完成计费信息的收集和上报，以及配额申请和下发的过程。所述方法包括：控制面功能实体cp从第一用户面功能实体up和第二up上获取所述cp对应的一个pdusession上的数据流的计费信息，所述第一up和第二up为所述cp对应的up；所述cp将计费系统下发的配额分割成多个子配额，并分别下发给所述第一up和第二up。一般来说，所述第一up和第二up上存在使用相同chargingkey的数据流；所述cp同时从所述第一up和第二up上获取所述数据流的计费信息；对于diameter协议接口的情形，所述cp通过与计费系统间的一个计费会话对第一up和第二up进行计费。所述cp将计费系统下发的配额分割成多个子配额并下发给up，包括：所述cp将计费系统为所述chargingkey下发的配额分割成多个子配额并分别下发给所述第一up和第二up。所述方法进一步包括：所述cp在任一个up上所述配额用完并上报所述配额对应的计费信息后，获取其他up上统计的所述配额对应的计费信息；所述cp合并所述配额对应的计费信息，并上报给计费系统。所述方法进一步包括：所述cp在任一个up上所述配额用完并上报所述配额对应的计费信息后，获取其他up上统计的所述配额对应的计费信息；所述cp缓存所有up上报的所述配额对应的计费信息，确定所述配额的剩余可用量，重新分配所述配额的剩余可用量，并向第一up和第二up下发所述重新分配的配额；所述cp在所述配额用完或者所述配额的剩余可用量满足上报阈值时，合并所述缓存的所述配额对应的计费信息，并向计费系统上报所述合并的计费信息。需要说明的是，前述实施例a,b所涉及的各步骤的相关内容，特别是实施例b21的情形，根据其相关性可以援引到方案c中，在此不再赘述,基于该实施例描述的技术方案，cp可同时对其对应的两个up上产生的数据流进行计费。计费系统包括在线计费系统ocs和离线计费系统ofcs。其中离线计费仅仅涉及计费信息采集和上报(包括上报触发条件)，而在线计费除了和离线计费类似的计费信息采集和上报外，还包括配额授予、配额使用管理(包括配额使用条件监控)、动态trigger(ocs激活的触发条件)、配额使用信息上报。本申请中如果没有特殊说明，计费上报适用于在线计费中的上报和离线计费中的上报，而计费配额申请、配额使用管理、动态trigger仅仅适用于在线计费。离线的计费有几种方法，包括ctf实时上报计费信息、ctf生成cdr后上报cdr、ctf直接生成cdr文件后上报cdr文件。在这几种方式下计费信息的采集粒度、用于触发实时上报或写cdr的触发条件等都是相同的，所以本申请实施例中仅以ctf实时上报计费信息为例进行说明。对于前述实施例中，情况a的情形，即cp先拆除与ue与up1的连接,再建立ue和up2的连接，离线计费方法简要描述如下，相关的细节可以类似参考前述实施例，在此不再赘述：步骤1：cp确定要改变数据流的up(执行计费的up发生变化)，cp将首先中断ue与up1的pdusession，同时建立ue与up2的pdusession；步骤2：cp发起中断up1上的pdusession，并接收up1上报的计费信息；up1上的pdusession释放流程触发up1向cp上报计费信息。up1的上报信息中包括上报原因(即：触发上报的条件)，这里的上报原因为pdusessionrelease。步骤3(计费系统感知up切换)：cp向cdf/cgf/bs上报计费信息，上报原因“up切换”；步骤3’(计费系统不感知up切换)：cp缓存up1的使用信息，并等待up2上报使用信息，在收到up2的使用信息后，cp将up2上报的使用信息和所缓存的up1上报的使用信息进行合并，将合并后的信息向cdf/cgf/bs上报。对于情况b:cp建立ue和up2的连接,但并未拆除和up1的连接；离线计费的方法简要描述如下：步骤1：cp确定要改变数据流的up(执行计费的up发生变化)，cp将首先建立ue与up2的pdusession，在数据流切换到up2后，中断ue与up1的pdusession；步骤2：cp发起建立up2上的pdusession；步骤3：ue将发送的上行数据流切换到up2的pdusession上，up2在接收到上行流时，触发startofsdf事件，并将该事件上报给cp；步骤4：cp在接收到up2上报的startofsdf事件后，向up1发送请求上报计费信息的消息，并接收up1上报的计费信息；up1的上报信息中包括上报原因(即：触发上报的条件)，这里的上报原因为pdusessionrelease。步骤5(计费系统感知up切换)：cp向cdf/cgf/bs上报计费信息，上报原因“up切换”；步骤5’(计费系统不感知up切换)：cp缓存up1的使用信息，并等待up2上报使用信息，在收到up2的使用信息后，cp将ud2上报的使用信息和所缓存的up1上报的使用信息进行合并，将合并后的信息向cdf/cgf/bs上报。本发明实施例的离线方案，也实现了在较为复杂的控制面和用户面分离场景下，例如，一个pdusession的用户面发生切换时，或者一个pdusession存在多个用户面时，用户的业务数据流在用户面之间迁移情况下的计费，使得离线计费可以支撑业务端到端的更低时延、且提高了网络的效率的优化部署，实现优化部署下数据业务的精准计费，提高网络效率和用户体验。以上主要从各个网元之间交互的角度对本申请实施例提供的方案进行了介绍。可以理解的是，上述cp,up或者ocs/ofcs，为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。本申请实施例可以根据上述方法示例对cp和ocs/ofcs进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。比如，在采用对应各个功能划分各个功能模块的情况下，图12示出了前述实施例中所涉及cp作为计费设备1200的一种可能的结构示意图。该计费设备1200包括判断模块1202，获取模块1206和处理模块1208。判断模块1202，用于确定用户设备ue在第一数据会话上传输的数据流需要迁移到第二数据会话上，所述第一数据会话是ue和第一用户面功能实体up间的数据会话；所述第二数据会话是所述ue和第二up间的数据会话，所述第一up和第二up是所述计费设备对应的up，所述第一数据会话和第二数据会话对应同一个pdusession。获取模块1206，用于获取第一up统计的所述数据流迁移前的计费信息。处理模块1208用于用于确定需要向第二up下发的所述数据流迁移后使用的配额，并下发给第二up。计费信息上报接口可以是diameter协议接口或者服务化接口。服务化接口的方式下，cp和计费系统间不建立计费会话，而是直接通过服务化消息进行交互，服务化消息(如：restful)是无状态的消息，每个消息携带完整的信息。而diameter协议接口的情况下，cp和计费系统之间需要建立计费会话。可选的，还包括会话模块1204，用于建立与计费系统之间的第一计费会话，并通过所述第一计费会话对所述第一up上的所述数据流计费；所述判断模块1202还用于确定所述数据流从第一up迁移到第二up后，所述第一up上无使用所述数据流对应的chargingkey的其他数据流，所述会话模块1204进一步用于为第二up上所述数据流使用所述第一计费会话进行计费。可选的，所述获取模块1206用于接收第一up上报的所述数据流迁移前的计费信息，并通过所述会话模块1204向计费系统上报所述计费信息，为第二up申请用于所述数据流的配额；所述会话模块1204用于接收所述计费系统下发的所述配额；所述处理模块1208根据所述计费系统下发的配额，生成向第二up下发的配额。可选的，所述处理模块1208用于根据获取的第一up统计的所述数据流迁移前的计费信息，确定剩余的可用配额，并根据所述剩余的可用配额生成向第二up下发的配额。可选的，所述获取模块1206用于接收第一数据会话中断触发第一up上报的计费信息。可选的，所述获取模块1206用于获取第二up上报的所述数据流对应的数据流开始事件后，第一up上统计的所述数据流迁移前的计费信息。可选的，所述判断模块1202用于确定所述数据流从第一up迁移到第二up后，所述第一up上存在使用所述数据流对应的chargingkey的其他数据流；所述获取模块1206进一步用于同时从所述第一up和第二up上获取所述数据流的计费信息。可选的，发所述判断模块1202进一步用于确定所述数据流从第一up迁移到第二up后，所述第一up上存在使用所述数据流对应的chargingkey的其他数据流；所述会话模块1204进一步用于为第二up上传输所述数据流的第二数据会话建立和计费系统的第二计费会话，通过第二计费会话向计费系统申请配额，所述处理模块1208进一步用于将申请的配额下发给第二up。需要说明的是，上述所有方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。以采用集成的方式划分各个功能模块的情况下，图13示出了上述实施例中所涉及的计费系统1300的一种可能的结构示意图，该计费系统1300包括：下发模块1302和接收模块1304，所述下发模块1302，用于向控制面功能实体cp下发指示信息，所述指示信息用于指示cp在所述cp对应的用户面功能实体up从第一up切换为第二up后，向所述ocs上报所述第一up切换前的计费信息；所述接收模块1304用于接收所述cp上报的所述第一up统计的切换前的计费信息。可选的，所述计费系统是在线计费系统ocs,所述指示信息随所述ocs下发给所述cp的配额一起下发。可选的，所述ocs接收所述cp上报的计费信息后，向所述cp下发新的配额。可选的，所述ocs接收所述cp上报的计费信息后，向所述cp下发给第二up，或同时给第一up和第二up的配额。需要说明的是，上述所有方法实施例涉及的计费系统执行的各步骤的所有相关内容均可以援引到上述对应功能模块的功能描述，在此不再赘述。其中，图12和图13实施例中的“模块”可以为专用集成电路(applicationspecificintegratedcircuit，asic)、电子线路、执行一个或多个软件或固件程序的处理器和存储器、组合逻辑电路和其他提供上述功能的组件。可选的，上述计费设备和计费系统通过计算机设备的形式来实现，上述接收模块、发送模块可以通过计算机设备的处理器、存储器和通信接口来实现，上述处理模块可以通过计算机设备的处理器和存储器来实现。应注意，尽管图3所示的计算机设备300仅仅示出了处理器302、存储器304、通信接口306和总线308，但是在具体实现过程中，本领域的技术人员应当明白，上述计费设备和计费系统还包含实现正常运行所必须的其他器件。同时，根据具体需要，本领域的技术人员应当明白，上述计费设备和计费系统还可包含实现其他附加功能的硬件器件。此外，本领域的技术人员应当明白，上述计费设备和计费系统也可仅仅包含实现本申请实施例所必须的器件，而不必包含图3中所示的全部器件。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本
技术领域：
的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。当前第1页12