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

本申请涉及通信领域，尤其涉及一种计费方法及装置。

背景技术：

目前在线计费的基本机制是：计费触发功能(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比1的关系。如图1所示。servinggateway-c、pdngateway-c、tdf-c属于控制面，servinggateway-u、pdngateway-u、tdf-u属于用户面。控制面是计费触发点，完成计费触发功能，用户面是计费采集点，完成计费采集功能。

然而，在新一代网络架构中，为了在用户移动的过程中，具有更低的网络时延并提高网络的效率，在控制面保持不变的情况下，用户面可能发生切换。而且，一个用户可能同时使用本地业务(如打电话、发短信等运营商业务)和外部业务(如互联网访问)，为了提高访问效率，也可能会让用户同时连接多个用户面，每个用户面处理不同的业务场景。在这种情况下，会出现不同的用户面存在相同费率组的现象，使用目前的在线信控机制，会使得ocs授予的一个配额被分割到不同的用户面使用，而不同用户面上业务的配额使用存在很大差异(如速度)，会严重影响配额管理效率、成本和精确度。

技术实现要素：

本申请的实施例提供一种计费方法，能够解决具有多个用户面的网络架构下的在线计费的问题。

第一方面，提供了一种计费方法，包括会话管理功能smf确定每个用户面功能upf上路由的数据流及所述数据流对应的费率组chargingkey。对于每个upf，smf向在线计费系统ocs发送该upf上至少一个无可用配额的chargingkey的配额请求，smf接收ocs为该upf上的至少一个chargingkey授予的配额，smf向该upf下发授予的配额。smf接收至少一个upf上报的至少一个配额对应的配额使用信息。smf向ocs发送根据至少一个配额对应的配额使用信息生成的计费上报消息。

通过区分不同upf进行chargingkey对应的配额的授予和管理，可以提高控制信用授权的准确度，提高网络效率，解决了具有多个用户面的网络架构下在线计费的问题。

结合第一方面的实现方式，在第一方面第一种可能的实现方式中，每个配额请求中包含对应的upf的标识以及对应的chargingkey，smf将每个配额请求携带在同一个向ocs发送的配额请求消息中，其中，该配额请求消息携带至少一个upf的配额请求。

结合第一方面或第一方面的第一种可能的实现方式，在第二种可能实现的方式中，smf分别为每个upf向ocs发送配额请求消息，每个配额请求消息中包含对应的upf的计费标识，以及包含对应的upf上至少一个chargingkey的配额请求，每个配额请求中包含相应的chargingkey。

可以根据实际需求选择以上两种不同的请求配额的方式，使得方案的实现更灵活。

结合第一方面或第一方面的第一种至第二种可能的实现方式中的任意一种，在第三种可能实现的方式中，smf接收配额响应消息，配额响应消息中包含为每个upf上的至少一个chargingkey授予的配额，以及配额对应的upf的标识。

结合第一方面或第一方面的第一种至第三种可能的实现方式中的任意一种，在第四种可能实现的方式中，smf分别接收对应不同upf的配额响应消息，配额响应消息中包含对应的upf的计费标识，以及为对应的upf上的至少一个chargingkey授予的配额。

针对两种不同的请求配额的方式，本申请实施例也提供了两种返回授权配额的方式。

结合第一方面或第一方面的第一种至第四种可能的实现方式中的任意一种，在第五种可能实现的方式中，计费上报消息中包含至少一个配额对应的配额使用信息，还包含配额对应的upf的标识以及对应的chargingkey，计费上报消息携带至少一个upf的配额使用信息。

结合第一方面或第一方面的第一种至第五种可能的实现方式中的任意一种，在第六种可能实现的方式中，smf分别为每个upf向ocs发送计费上报消息，计费上报消息中包含对应的upf的计费标识，以及包含对应的upf上至少一个配额对应的配额使用信息。

针对两种不同的请求配额、授予配额的方式，本申请实施例也提供了两种上报配额使用信息的方式。

结合第一方面或第一方面的第一种至第六种可能的实现方式中的任意一种，在第七种可能实现的方式中，smf根据pcf下发或激活的策略确定每个upf上路由的数据流对应的chargingkey。

结合第一方面或第一方面的第一种至第七种可能的实现方式中的任意一种，在第八种可能实现的方式中，在smf确定每个upf上路由的数据流及该数据流对应的chargingkey之前，smf接收用户会话pdusession建立请求。

结合第一方面或第一方面的第一种至第八种可能的实现方式中的任意一种，在第九种可能实现的方式中，在smf接收ocs授予的配额之前，smf向ocs发起建立对应pdusession的在线计费会话请求。

结合第一方面或第一方面的第一种至第九种可能的实现方式中的任意一种，在第十种可能实现的方式中，在smf确定每个upf上路由的数据流及该数据流对应的chargingkey之前，smf执行upf选择或者upf重选择。

结合第一方面或第一方面的第一种至第十种可能的实现方式中的任意一种，在第十一种可能实现的方式中，smf在建立pdusession时执行upf选择，在smf为pdusession增加或删除upf锚点，或者调整upf间业务数据流时执行upf重选择。

结合第一方面或第一方面的第一种至第十一种可能的实现方式中的任意一种，在第十二种可能实现的方式中，upf为执行策略控制功能pcf下发的控制策略的upf，或者，upf为分流器classifier或者分支点branchingpoint。

结合第一方面或第一方面的第一种至第十二种可能的实现方式中的任意一种，在第十三种可能实现的方式中，当upf为classifier或branchingpoint时，smf接收classifier或者branchingpoint上报的配额使用信息，配额使用信息区分upf锚点。

结合第一方面或第一方面的第一种至第十三种可能的实现方式中的任意一种，在第十四种可能实现的方式中，smf根据业务类型、upf的负载、smf上配置的或从pcf接收的控制策略中的至少一种确定每个upf上路由的数据流。

第二方面，提供了一种计费方法，包括在线计费系统ocs接收来自会话管理功能smf的每个用户面功能upf上至少一个无可用配额的费率组chargingkey的配额请求。ocs向smf发送为至少一个无可用配额的chargingkey授予的配额。ocs接收来自smf的计费上报消息，计费上报消息包含至少一个配额对应的配额使用信息。

通过区分不同upf进行chargingkey对应的配额的授予和管理，可以提高控制信用授权的准确度，提高网络效率，解决了具有多个用户面的网络架构下在线计费的问题。

结合第二方面的实现方式，在第二方面第一种可能的实现方式中，每个配额请求中包含请求配额的upf的标识以及对应的chargingkey，配额请求携带在配额请求消息中，配额请求消息携带至少一个upf的配额请求。

结合第二方面或第二方面的第一种可能的实现方式，在第二种可能实现的方式中，每个upf上的配额请求携带在同一配额请求消息中，不同upf上的配额请求携带在不同配额请求消息中；每个配额请求消息中包含对应的upf的计费标识，以及包含对应的upf上至少一个chargingkey的配额请求。

结合第二方面或第二方面的第一种至第二种可能的实现方式中的任意一种，在第三种可能实现的方式中，ocs向smf返回配额响应消息，配额响应消息中包含为每个upf上的至少一个chargingkey授予的配额，以及配额对应的upf的标识。

结合第二方面或第二方面的第一种至第三种可能的实现方式中的任意一种，在第四种可能实现的方式中，ocs向smf分别发送对应不同upf的配额响应消息，配额响应消息中包含对应的upf的计费标识，以及为对应的upf上的至少一个chargingkey授予的配额。

结合第二方面或第二方面的第一种至第四种可能的实现方式中的任意一种，在第五种可能实现的方式中，计费上报消息中包含至少一个配额对应的配额使用信息，还包含配额对应的upf的标识以及对应的chargingkey，计费上报消息携带至少一个upf的配额使用信息。

结合第二方面或第二方面的第一种至第五种可能的实现方式中的任意一种，在第六种可能实现的方式中，每个upf上的配额使用信息携带在同一计费上报消息中，不同upf上的配额使用信息携带在不同计费上报消息中；每个计费上报消息中包含对应的upf的计费标识，以及包含对应的upf上至少一个配额对应的配额使用信息。

结合第二方面或第二方面的第一种至第六种可能的实现方式中的任意一种，在第七种可能实现的方式中，在ocs向smf授予配额之前，ocs接收来自smf的建立对应pdusession的在线计费会话请求。

第三方面，提供了一种计费方法，包括用户面功能upf接收来自会话管理功能smf的某一授予的配额；所述upf接收多个数据流，所述多个数据流使用所述配额，根据所述多个数据流对应的upf锚点，区分统计所述配额对应的配额使用信息；所述upf向所述smf发送所述配额对应的配额使用信息，所述配额使用信息包括区分upf锚点的配额使用值以及对应的upf锚点的标识。

结合第三方面的实现方式，在第三方面第一种可能的实现方式中，所述upf为分流器classifier或分支点branchingpoint。

第四方面，提供了一种计算设备，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算设备执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算设备运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述计算设备执行第一方面及第一方面任一可能的实现方式所述的方法。

第五方面，提供了一种计算设备，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算设备执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算设备运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述计算设备执行第二方面及第二方面任一可能的实现方式所述的方法。

第六方面，提供了一种计算设备，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算设备执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算设备运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述计算设备执行第三方面及第三方面任一可能的实现方式所述的方法。

第七方面，提供了一种计算机可读存储介质，其中存储有可执行的程序代码，该程序代码用以实现第一方面及第一方面的任意一种可能的实现方式所述的方法。

第八方面，提供了一种计算机可读存储介质，其中存储有可执行的程序代码，该程序代码用以实现第二方面及第二方面的任意一种可能的实现方式所述的方法。

第九方面，提供了一种计算机可读存储介质，其中存储有可执行的程序代码，该程序代码用以实现第三方面及第三方面的任意一种可能的实现方式所述的方法。

第十方面，提供了一种计费装置，包含用于执行第一方面及第一方面的任意一种可能的实现方式中的方法的模块。

第十一方面，提供了一种计费装置，包含用于执行第二方面及第二方面的任意一种可能的实现方式中的方法的模块。

第十二方面，提供了一种计费装置，包含用于执行第三方面及第三方面的任意一种可能的实现方式中的方法的模块。

根据本申请实施例提供的技术方案，通过区分不同upf进行chargingkey对应的配额的授予和管理，可以提高控制信用授权的准确度，提高网络效率，解决了具有多个用户面的网络架构下在线计费的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1是现有技术中控制面和用户面分离的网络架构的示意图；

图2是依据本申请一实施例的网络架构的示意图；

图3是依据本申请一实施例的计算机设备300的硬件结构示意图；

图4是依据本申请一实施例的计费方法400的示范性流程图；

图5是依据本申请一实施例的计费方法500的示范性流程图；

图6是依据本申请一实施例的计费方法600的示范性流程图；

图7是依据本申请一实施例的计费方法700的示范性流程图；

图8是依据本申请一实施例的计费方法800的示范性流程图；

图9是依据本申请一实施例的计费设备900的结构示意图；

图10是依据本申请一实施例的计费系统1000的结构示意图。

具体实施方式

本申请实施例涉及的网元名称本身不对设备构成限定。具体来说，会话管理功能这个名字本身对设备不构成限定，实际中，可以为其他名字，比如：会话管理器(sessionmanager)。策略控制功能这个名字本身对设备不构成限定，实际中，可以为其他名字，比如：策略控制器(policycontroller)。用户面功能这个名字本身对设备不构成限定，实际中，可以为其他名字，比如：用户面功能实体(userplanefunctionentity)。在线计费系统这个名字本身对设备不构成限定，实际中，可以为其他名字，比如：计费系统，或其他名字。在此进行统一说明，以下不再赘述。

本申请实施例的方案可以用于5g，以及未来的其他系统中。

图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)。

upf的功能包括完成与外部数据网交互的锚点功能(具有锚点功能的upf称为upf锚点)；数据包路由和转发；数据包检测，并执行pcf激活的控制策略的用户面部分。

pcf的功能包括生成并下发策略，或者激活smf上静态配置的策略，通过策略控制upf上路由的业务数据流的qos、门控、计费等。smf可以根据pcf下发的策略确定是否和ocs建立在线计费会话，以及确定业务数据流对应的chargingkey。

ocs的功能包括根据smf的请求进行配额授予，并根据smf上报的配额使用信息进行余额扣减或返还。

ue是具有用户永久身份(subscriberpermanentidentity，supi)或者国际移动用户识别码(internationalmobilesubscriberidentificationnumber，imsi)的设备，可以为具有sim/esim的手机、平板、电脑、iot设备、或者其他可以连接5g网络的设备。

smf、ocs和upf可以通过计算机设备的形式实现。图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是smf时，处理器302执行存储器304中保存的用于实现本申请实施例提供的技术方案的程序代码，以实现图4至图8实施例所示的方法。

当计算机设备300是ocs时，处理器302执行存储器304中保存的用于实现本申请实施例提供的技术方案的程序代码，以实现图4至图8实施例所示的方法。

当计算机设备300是upf时，处理器302还可以执行存储器304中保存的用于实现本申请实施例提供的技术方案的程序代码，以实现图4至图8实施例所示的方法。

本申请实施例中，通过区分不同upf进行配额申请和配额授予，使得不同upf上具有相同chargingkey时，不会因为不同upf上配额使用存在的差异而降低配额管理效率和精确度，能够提高控制信用授权的准确度，提高网络效率。

下面就结合具体实现，说明区分不同upf进行配额管理的过程。

图4是依据本申请一实施例的计费方法400的示范性流程图，以下结合具体步骤说明如何区分不同upf进行配额管理。计费方法400可以由图2所示的smf、ocs、upf来执行。

s401，smf接收到某一ue的pdusession建立请求，向ocs发起建立对应该pdusession的在线计费会话。

pdusession是建立在ue和提供pdu连接业务的数据网络(datanetwork，dn)之间的。而连接dn的是upf，因此也可以说pdusession是建立在ue和upf之间的。pdusession的建立由smf控制，因此ue会向smf发送pdusession建立请求，smf来选择与ue建立连接的upf。

在线计费会话建立在smf与ocs之间。为了对使用业务进行在线计费，ocs会为每个pdusession建立相应的在线计费会话。配额的请求和授予，以及包含配额使用量的计费信息的上报都通过为该pdusession建立的在线计费会话进行。

在接收到pdusession建立请求后，smf向pcf请求控制策略。控制策略中包含chargingkey、服务质量(qualityofservice，qos)控制、门控、应用检测等信息。smf根据控制策略确定需要为该pdusession建立在线计费会话。控制策略可以直接由pcf下发给smf，也可以预先配置在smf上，由pcf向smf下发指令来激活。

smf向ocs发送的建立在线计费会话的请求消息中携带用户标识。由于ue的ip地址有多个，为了避免ocs处出现管理混乱，使用supi或imsi来标识用户。

下面以diameter协议为例呈现建立在线计费会话的请求消息。需要说明的是，此处仅以diameter协议作为示例，本申请并不限定消息的格式，也可以使用其他消息格式，如restapi等。

s402，smf选择upf。

smf可以根据以下信息中的至少一种进行upf的选择：控制策略、upf的动态负载、支持同一数据网络名(datanetworkname，dnn)的upf相对静电容、smf中可用的upf位置、upf位置信息、upf能力和特殊uesession所需功能、数据网络名、pdusession类型、为pdusession选择的ssc模式、用户数据管理(userdatamanagement，udm)中的用户订阅文件、流量路由目的地、网络切片相关信息。

除了进行upf的选择，smf还确定需要执行计费统计功能的upf。在实际应用中，smf选择的upf中可能包含执行控制策略的upf以及不执行控制策略的upf。smf确定执行控制策略的upf为计费采集点，执行计费统计功能。本实施例中，smf选择的upf指执行控制策略的upf，因此这些upf执行计费统计功能。

smf只选择了一个upf时，该upf执行控制策略，执行计费统计功能。

s403，smf确定每个upf上路由的数据流及该数据流对应的chargingkey。

smf可以根据控制策略、业务类型、upf的负载等来确定每个upf上路由的数据流。

比如：对于某一类业务(如视频业务)，可以将其数据流指定到靠近ue的upf；对于qos带宽需求大的业务，可以将其数据流指定到带宽更高的upf；若某一upf的负载过大，则将数据流指定到负载更低的upf。

smf可以根据pcf下发或激活的控制策略来确定数据流对应的chargingkey。具体的，pcf下发或激活的控制策略中，包含了流模板、对应的chargingkey，smf根据所确定的upf及upf上的数据流分布情况，根据该控制策略中数据流和chargingkey的对应关系，确定对应的chargingkey。

s404，对于每个upf，smf向ocs发送该upf上至少一个无可用配额的chargingkey的配额请求，smf接收ocs为该upf上的所述至少一个chargingkey授予的配额，smf向该upf下发所述授予的配额。

对于每个upf的操作，具体通过下面的s4041、s4042和s4043进行说明。

s4041，smf向ocs发送该upf上至少一个无可用配额的chargingkey的配额请求。

并非所有chargingkey都需要使用配额，smf只为需要使用配额的chargingkey请求配额。

这里的无可用配额的chargingkey包括两种情况：第一，该chargingkey的初次配额申请之前，该chargingkey没有可以使用的配额；第二，之前为该chargingkey申请了配额，但由于该配额用完、过期等导致smf上无该chargingkey对应的配额可以使用。

由于不同upf上路由的数据流可能使用相同的chargingkey，为了避免配额管理时不同upf间相同chargingkey的配额使用相互干扰，smf为不同upf上相同chargingkey分别向ocs请求配额。

类似的，同一upf上路由的数据流可能使用不同的chargingkey，smf也分别为同一upf上不同chargingkey向ocs请求配额。

smf可以采用以下两种方法向ocs请求配额。

方法一：smf在配额请求中包括相应upf的标识以及对应的chargingkey，以upf的标识区分不同upf上的配额请求。smf通过s401中为该pdusession建立的在线计费会话向ocs发送配额请求消息。

具体的，同一个upf上多个chargingkey的配额请求，以及该pdusession的不同upf上的chargingkey的配额请求可以携带在同一个向ocs发送的配额请求消息中。也就是说：一个配额请求消息可以携带一个或多个upf上的配额请求，不同upf上的配额请求可能具有相同的chargingkey或者不同的chargingkey。

下面以diameter协议为例呈现方法一下的配额请求消息。需要说明的是，此处仅以diameter协议作为示例，本申请并不限定消息的格式，也可以使用其他消息格式，如restapi等。

此例中，配额请求消息中包含3个配额请求，分别是upf1上chargingkey1的配额请求、upf1上chargingkey2的配额请求、upf2上chargingkey2的配额请求。每个配额请求中包含相应的chargingkey，相应chargingkey所请求的配额以及相应upf的标识。upf1上chargingkey1的配额请求中还包含了业务标识service-identifier1，表示业务标识是service-identifier1的业务独享chargingkey1，其他业务不可使用chargingkey1。

方法二：smf分别为每个upf向ocs发送配额请求消息，每个配额请求消息中包含对应的upf的计费标识，以及包含对应的upf上至少一个chargingkey的配额请求，每个配额请求中包含相应的chargingkey。

这里的upf的计费标识用于指示该配额请求消息用于某一特定的upf的计费。该upf的计费标识可以是对应某一特定upf的pdusession计费会话的子计费会话标识，或者其他标识。smf会保存该upf的计费标识与upf之间的对应关系。

smf将s401中将该pdusession建立的在线计费会话分成多个子计费会话，为每个upf分配一个子计费会话，具体的，smf可以为每个upf分配一个子计费会话标识。每个子计费会话仅供一个upf使用。子计费会话的数量与upf的数量相同，每个子计费会话与一个upf一一对应。每个子计费会话有唯一会话标识，smf保存upf和子计费会话的对应关系。ocs以不同子计费会话区分管理配额。同一个upf上多个chargingkey的配额请求携带在同一个向ocs发送的配额请求消息中，不同upf上的配额请求不能携带在同一个配额请求消息中。每个upf的配额请求消息通过与该upf对应的子计费会话传输给ocs。

下面以diameter协议为例呈现方法二下的配额请求消息。需要说明的是，此处仅以diameter协议作为示例，本申请并不限定消息的格式，也可以使用其他消息格式，如restapi等。

此例中，与ufp1对应的配额请求消息中包含2个配额请求，分别是chargingkey1的配额请求和chargingkey2的配额请求。与upf2对应的配额请求消息中包含1个配额请求，为chargingkey2的配额请求。与ufp1对应的配额请求消息中包含upf1的计费标识cc-sub-session-id1，与ufp2对应的配额请求消息中包含upf2的计费标识cc-sub-session-id2。每个配额请求中包含chargingkey以及相应chargingkey所请求的配额。

需要说明的是，本申请实施例中，配额请求消息指smf向ocs发送的用来请求配额的消息，如diameterccr等，而配额请求为配额请求消息中携带的针对某一chargingkey的请求信息，如multiple-services-credit-control。

请求某一chargingkey的配额可以通过两种方式实现，一种是将请求的配额量发送给ocs，另一种是只向ocs发送请求，不携带具体配额量，由ocs确定授权的配额量。

s4042，smf接收ocs为该upf上所述至少一个chargingkey授予的配额。

该步骤中的upf上所述至少一个chargingkey与步骤s4041中的upf上至少一个无可用配额的chargingkey对应。

针对s4041中两种向ocs请求配额的方法，ocs也采用两种方法向smf返回授予的配额。

针对s4041中的方法一，ocs采用如下方法向smf返回授予的配额。

ocs将对同一个upf上至少一个chargingkey授予的配额，以及为该pdusession的不同upf上chargingkey授予的配额携带在同一个向smf返回的配额响应消息中。ocs以upf的标识区分不同upf上授予的配额，在配额响应消息中携带每个授予的配额对应的upf的标识。ocs通过s401中为该pdusession建立的在线计费会话向smf发送配额响应消息。

下面以diameter协议为例呈现对应于方法一的配额响应消息。需要说明的是，此处仅以diameter协议作为示例，本申请并不限定消息的格式，也可以使用其他消息格式，如restapi等。

针对s4041中的方法二，ocs采用如下方法向smf返回授予的配额。

ocs分别为每个upf返回配额响应消息，每个配额响应消息中包含对应的upf的计费标识，以及为该对应的upf上的至少一个chargingkey授予的配额。ocs将为同一个upf上多个chargingkey授予的配额携带在同一个配额响应消息中，不同upf上授予的配额携带在不同配额响应消息中。为每个upf返回的配额响应消息通过与该upf对应的子计费会话传输给smf。

下面以diameter协议为例呈现方法二下的配额响应消息。需要说明的是，此处仅以diameter协议作为示例，本申请并不限定消息的格式，也可以使用其他消息格式，如restapi等。

s4043，smf向该upf下发所述授予的配额。

smf根据配额与upf的对应关系将授予的配额下发给对应的upf。对应方法一，smf根据授予的配额及upf的标识的对应关系将授予的配额下发给对应的upf，对应方法二，smf根据upf的计费标识和upf的对应关系将授予的配额下发给对应的upf。

按照s4042中的示例，smf将ocs授予的配额1和2下发给upf1，将授予的配额3下发给upf2。

s405，smf接收至少一个upf上报的至少一个配额对应的配额使用信息。

同一个upf上不同chargingkey的配额使用相互独立。不同upf上配额的使用也相互独立，不论chargingkey相同与否。

配额使用信息的上报是在触发条件满足时进行的。同一upf上不同chargingkey可以具有相同的触发条件，也可以具有不同的触发条件。不同upf上相同的chargingkey可以具有相同的触发条件，也可以具有不同的触发条件。同一个upf上不同chargingkey的配额使用上报相互独立。不同upf上配额的使用上报也相互独立，不论chargingkey相同与否。触发条件包括配额用完、配额过期、ocs指定的上报条件满足(如qos更改、位置改变、接入类型变化等)、以及pdusession拆除。

假设upf1上chargingkey1的配额1用完，upf2上chargingkey2的配额3用完。此时触发条件满足，upf1向smf上报chargingkey1的配额使用信息，upf2向smf上报chargingkey2的配额使用信息。

s406，smf向ocs发送根据至少一个配额对应的配额使用信息生成的计费上报消息。

对于每个配额，smf根据该配额的配额使用信息确定该配额对应的upf以及对应的chargingkey，将该配额的配额使用信息、对应的upf以及对应的chargingkey通过计费上报消息发送给ocs。

针对s4041中的方法一，smf采用如下方法向ocs发送配额使用信息。

smf将同一个upf上多个配额的配额使用信息，以及该pdusession的不同upf上的配额的配额使用信息携带在同一个向ocs发送的计费上报消息中。smf以upf标识区分不同upf的配额使用信息。smf通过s401中为该pdusession建立的在线计费会话向ocs发送计费上报消息。

下面以diameter协议为例呈现方法一下的计费上报消息。需要说明的是，此处仅以diameter协议作为示例，本申请并不限定消息的格式，也可以使用其他消息格式，如restapi等。

本例中假定upf1上chargingkey1的配额1和upf2上chargingkey2的配额3满足触发条件，上报的计费消息如下。

此例中，计费上报消息中包含2个配额使用信息，分别是upf1上配额1的配额使用信息和upf2上配额3的配额使用信息。计费上报消息中包含配额1对应的chargingkey和upf标识，即chargingkey1和upf1；包含配额3对应的chargingkey和upf标识，即chargingkey2和upf2。此外，还包含了为相应chargingkey新申请的配额。在业务没有结束时，上报配额使用信息的同时申请新的配额。

针对s4041中的方法二，smf采用如下方法向ocs发送配额使用信息。

smf分别为每个upf向ocs发送计费上报消息，每个计费上报消息中包含对应的upf的计费标识，以及包含对应的upf上至少一个配额对应的配额使用信息。smf将同一个upf上多个配额的配额使用信息携带在同一个向ocs发送的计费消息中，不同upf上的配额的配额使用信息携带在不同计费上报消息中。每个upf的计费上报消息通过与该upf对应的子计费会话传输给ocs。

下面以diameter协议为例呈现方法二下的计费上报消息。需要说明的是，此处仅以diameter协议作为示例，本申请并不限定消息的格式，也可以使用其他消息格式，如restapi等。

ocs在接收到计费上报消息后根据费率组和配额使用信息进行计费。

在后续需要拆除pdusession时，如用户停止使用业务，smf通知所有该pdusession的upf上报配额使用信息，smf根据该配额使用信息生成计费上报消息发送给ocs，并拆除为该pdusession建立的在线计费会话。smf向ocs发送计费上报消息的方式可参考s406中的两种方式，此处不再赘述。

s401、s402、s403三个步骤的顺序可以改变。建立在线计费会话和请求配额可以合并在一个消息中，例如，在建立在线计费会话时，已经确定了数据流对应的chargingkey，则可以在建立在线计费会话的请求消息中携带配额请求。

根据本申请实施例提供的技术方案，通过区分不同upf进行chargingkey对应的配额的授予和管理，可以提高控制信用授权的准确度，提高网络效率，解决了具有多个用户面的网络架构下在线计费的问题。

图5是依据本申请一实施例的计费方法500的示范性流程图。不同于图4实施例，在图5实施例中，smf选择的upf中包含分流器(classifier)或分支点(branchingpoint)。smf确定classifier或branchingpoint作为计费采集点，执行计费统计功能。如果smf确定以执行控制策略的upf为计费采集点，执行计费统计功能，当classifier或者branchingpoint执行控制策略时，采用图5实施例所述的方法，当upf锚点执行控制策略时，采用图4实施例所述的方法。对于来自ue的上行数据流，上行数据流先经过classifier或branchingpoint，classifier或branchingpoint将数据流分流到不同的upf锚点；对于下行数据流，是下行数据流先经过不同的upf锚点，再经过classifier或branchingpoint，classifier或branchingpoint对下行数据流进行合并，下发给ue。

s501，smf接收到某一ue的pdusession建立请求，向ocs发起建立对应该pdusession的在线计费会话。

具体内容可参考图4实施例s401，此处不再赘述。

s502，smf确定classifier为执行计费统计功能的upf。

classifier或branchingpoint用于对用户面上的上行数据流进行分流(将来自ue的一个数据流分流到不同的upf锚点)及对下行数据流进行合并(将来自不同upf锚点的数据流合并成一个数据流下发给ue)，也是upf，其上会经过所有数据流。因此可以将classifier或branchingpoint作为计费采集点。

由于控制策略的执行会影响计费的准确性，例如，控制策略中的门控操作有可能导致丢包，而classifier或branchingpoint可能并不真正执行控制策略，此时如果按照经过classifier或branchingpoint的所有数据包进行计费，会导致扣费多于实际使用费用。因此，为了保证计费的准确性，classifier或branchingpoint上配置有所有pcf激活的控制策略，classifier或branchingpoint模拟执行控制策略后采集计费信息，这样就保证了所采集的计费信息和upf执行控制策略后产生的计费信息是一致的。

例如，假设一个pdusession包含upf1、upf2和classifier，smf确定classifier为执行计费统计功能的upf。如果upf1执行的控制策略为

policyrule1

{

flow1：丢弃；

}

policyrule2

{

flow2+flow3：chargingkey1，优先级为1；

}

policyrule3

{

flow3+flow4：chargingkey2，优先级为2

}

则为classifier也下发该控制策略。如果classifier检测到属于flow1的数据包，则模拟执行控制策略policyrule1。policyrule1指示丢弃，因此不进行计费统计(此时classifier不会真正丢弃该数据包，而是由执行policyrule1的upf执行丢弃操作)。如果classifier检测到属于flow3的数据包，则模拟执行控制策略。而flow3可以被chargingkey1和chargingkey2同时覆盖，但根据这两个chargingkey的优先级，数据流flow3会被匹配到chargingkey1，所以classifier或者branchingpoint将数据流flow3采用chargingkey1进行统计。

s503，smf确定classifier上路由的数据流及该数据流对应的chargingkey。

本实施例中，pdusession中包含多个upf，且其中包含一个classifier或者branchingpoint。由于classifier或者branchingpoint上会经过所有数据流，smf确定classifier或者branchingpoint上路由的数据流及分流规则。确定分流规则是为了确定数据流的路由路径，以完成数据流的传输。例如，pdusession中包含upf1、upf2、和upf3，其中upf3为classifier，执行计费统计功能，不执行控制策略。smf确定upf3上路由的数据流，还根据分流规则确定upf1和upf2上路由的数据流。。

s504，smf向ocs发送classifier上无可用配额的chargingkey的配额请求。

由于classifier执行计费统计功能，其上具有控制策略，因此classifier存储有每个数据流对应的chargingkey。

请求配额的具体过程可参考图4实施例s4041，此处不再赘述。

s505，smf接收ocs为classifier上无可用配额的chargingkey授予的配额。

ocs返回授予的配额的具体过程可参考图4实施例s4042，此处不再赘述。

s506，smf向classifier下发授予的配额。

本实施例中，classifier执行计费统计功能，因此smf将每个授权的配额下发给classifier。classifier模拟执行控制策略，生成配额使用信息。

s507，smf接收来自classifier的至少一个配额对应的配额使用信息。

对于不同upf上的配额，classifier在上报时区分upf。classifier向smf发送某一配额对应的配额使用信息时，配额使用信息包括区分upf锚点的配额使用值以及对应的upf锚点的标识。

假设upf1上chargingkey1的配额1用完，upf2上chargingkey2的配额3用完。此时触发条件满足，upf3向smf上报upf1上配额1的配额使用信息，以及upf2上配额3的配额使用信息。

具体过程可参考图4实施例s407。

s508，smf向ocs发送根据配额使用信息生成的计费上报消息。

具体过程可参考图4实施例s406。

通过区分不同upf进行chargingkey对应的配额的授予和管理，可以提高控制信用授权的准确度，提高网络效率，解决了具有多个用户面的网络架构下在线计费的问题。

在实际应用中，可能出现以下三种场景：

(1)upf1上的数据流迁移到upf2；

(2)pdusession中增加了upf；

(3)pdusession中删除了upf；

下面结合图6对第一种场景进行说明。

smf为pdusession建立了在线计费会话，并在该在线计费会话中为upf1、upf2上的数据流使用的chargingkey申请了配额。具体过程可以参考图4实施例s401至s404。

s601，smf确定upf1上的至少一个数据流需要迁移到upf2。

具体的，smf可以根据图4实施例s402中描述的进行upf选择的信息进行确定。

s602，smf或upf2判断当前upf2上是否有该至少一个数据流对应的chargingkey的可用配额，如果有，则该至少一个数据流使用upf2上相应chargingkey的可用配额。如果在upf2上，该至少一个数据流中部分数据流对应的chargingkey没有可用配额，则smf向ocs发送配额请求，为upf2上该部分数据流对应的chargingkey请求配额。

同样，若upf1上存在无可用配额的chargingkey，smf也为该无可用配额的chargingkey请求配额，向ocs发送配额请求。

smf请求配额的具体方式可以参考图4实施例s4041。

例如，upf1上路由的数据流包括stream1、stream2和stream3，对应的chargingkey分别为chargingkey1、chargingkey2和chargingkey3。其中stream1和stream2需要迁移到upf2。smf或upf1判断出upf1存在chargingkey3的可用配额，则smf不为upf1上chargingkey3向ocs请求配额。smf或upf2判断出upf2上存在chargingkey1的可用配额，不存在chargingkey2的可用配额。此时stream1使用upf2上chargingkey1的可用配额，smf不为upf2上chargingkey1向ocs请求配额，而为upf2上chargingkey2向ocs请求配额。

s603，ocs向smf发送为upf2上该部分数据流对应的chargingkey授予配额。

同样，ocs也为upf1上无可用配额的chargingkey授予配额。

具体过程可参考图4实施例s4042。

s604，smf向upf2发送授予的配额。

同样，smf也向upf1上无可用配额的chargingkey发送授予的配额。

s605，该至少一个数据流迁移到upf2。

s606，upf1或upf2向smf上报至少一个配额对应的配额使用信息。

具体过程可参考图4实施例s405。

s607，smf向ocs发送根据该配额使用信息生成的计费上报消息。

具体过程可参考图4实施例s406。

根据本申请实施例提供的技术方案，通过区分不同upf进行chargingkey对应的配额的授予和管理，简化了不同upf之间进行数据流切换时的处理过程，提高了网络效率。

下面结合图7对第二种场景进行说明。

smf为pdusession建立了在线计费会话，并在该在线计费会话中为upf1上的数据流对应的chargingkey申请了配额。具体过程可以参考图4实施例s401至s404。

s701，smf确定需要增加upf2进行数据流的路由。

具体的，smf可以根据图4实施例s402中描述的进行upf选择的信息进行确定。

s702，smf确定upf2上的数据流及对应的chargingkey。

具体过程可参考图4实施例s403。

s703，smf向ocs发送upf2上每个chargingkey的配额请求。

需要说明的是，本实施例中，在增加upf2之前，pdusession中不包含upf2，因此upf2上并不存在该pdusession的数据流对应的chargingkey的可用配额。因此smf会为upf2上的每个chargingkey请求配额。

具体过程可参考图4实施例s4041。

s704，ocs向smf发送为upf2上每个chargingkey授予的配额。

具体过程可参考图4实施例s4042。

s705，smf向upf2发送授予的配额。

s706，upf1或upf2向smf上报至少一个配额对应的配额使用信息。

具体过程可参考图4实施例s405。

假设upf1上路由数据流stream1和stream2，stream1使用chargingkey1，stream2使用chargingkey2。upf2上路由数据流stream3，stream3使用chargingkey2。当upf1上chargingkey1对应的触发条件满足，upf2上chargingkey2对应的触发条件满足，upf1向smf上报chargingkey1的配额使用信息，upf2向smf上报chargingkey2的配额使用信息。

s707，smf向ocs发送根据该配额使用信息生成的计费上报消息。

具体过程可参考图4实施例s406。

在s703至s705中，若upf1上存在无可用配额的chargingkey，smf也会为upf1申请配额，此处不再赘述。

本实施例中，新增的upf2可以为classifier或branchingpoint。在这种情况下，classifier或branchingpoint为计费采集点，执行计费统计功能。由于classifier或branchingpoint上会经过所有数据流，且classifier或branchingpoint对每个数据流模拟执行控制策略，因此在这种情况下，s706中由upf2(即classifier或branchingpoint)向smf发送配额使用信息，upf1不向smf发送配额使用信息。

举例来说，假设upf1上路由数据流stream1和stream2，stream1使用chargingkey1，stream2使用chargingkey2。新增的upf2为classifier，upf2上路由数据流stream1、stream2，还路由数据流stream3，stream3使用chargingkey2。当chargingkey1对应的触发条件满足时，classifier向smf上报chargingkey1的配额使用信息。当chargingkey2对应的触发条件满足时，classifier向smf上报chargingkey2的配额使用信息。upf1不向smf发送chargingkey1和chargingkey2的配额使用信息。

根据本申请实施例提供的技术方案，通过区分不同upf进行chargingkey对应的配额的授予和管理，简化了pdusession中新增upf时对计费信息的处理，提高了网络效率。

下面结合图8对第三种场景进行说明。

smf为pdusession建立了在线计费会话，并在该在线计费会话中为upf1和upf2上的数据流对应的chargingkey申请了配额。具体过程可以参考图4实施例s401至s404。

s801，smf确定需要删除upf2。

smf确定需要删除upf2时，确定upf2上不再路由数据流，原来upf2上的数据流对应的chargingkey也不再存在。

具体的，smf根据sscmode(如：为upf切换，先建立新的upf，等业务数据流都迁移到新的upf后，再删除旧的upf)、其他的smf规则等，确定需要删除upf。

smf确定upf1上的数据流及chargingkey，例如确定是否新增数据流，以及确定新增的数据流的chargingkey。后续smf还会为upf1上无可用配额的chargingkey申请配额，具体可参考图4实施例s404，此处不再赘述。

s802，smf通知upf2上报upf2上每个配额的配额使用信息。

s803，upf2向smf上报upf2上每个配额的配额使用信息。

假设upf2上的数据流为stream1和stream2，stream1对应chargingkey1，stream2对应chargingkey2。当upf2接收到来自smf的上报各配额使用信息的通知时，upf2向smf上报chargingkey1和chargingkey2的配额使用信息。

s804，smf向ocs发送根据该配额使用信息生成的计费上报消息。

具体过程可参考图4实施例s406。

smf删除upf2后，upf1上各chargingkey的配额不受影响，仍可继续使用。

本实施例中，删除的upf2可以为classifier或branchingpoint。在这种情况下，classifier或branchingpoint向smf上报每个配额的配额使用信息。由于classifier或branchingpoint上存储有每个upf上路由的每个数据流对应chargingkey，因此，在本实施例中，classifier或branchingpoint上报的是upf1和upf2上各chargingkey的配额的配额使用信息。

根据本申请实施例提供的技术方案，通过区分不同upf进行chargingkey对应的配额的授予和管理，简化了pdusession中删除upf时对计费信息的处理，提高了网络效率。

需要说明的是，确定某一upf上路由的数据流及该数据流对应的chargingkey，不一定会导致该upf上路由的数据流及该数据流对应的chargingkey发生变化。

本申请实施例中的upf都为执行计费统计功能的upf，这里的计费统计功能指的是在线计费统计功能。

图9是依据本申请一实施例的计费设备900的结构示意图。计费设备900包括处理模块902、发送模块904和接收模块906。计费设备900为图2中的smf，图3实施例中的计算机设备，以及图4至图8实施例中的smf。处理模块902可以用来执行图4实施例中的s402、s403，图5实施例中的s502、s503，图6实施例中的s601、s602，图7实施例中的s701、s702，图8实施例中的s801。接收模块906可以用来执行图4实施例中的s401、s4042、s405，图5实施例中的s501、s505、s507，图6实施例中的s603，图7实施例中的s704、s706，图8实施例中的s803。发送模块904可以用来执行图4实施例中的s4041、s4043、s406，图5实施例中的s504、s506、s508，图6实施例中的s602、s604、s607，图7实施例中的s703、s705、s707，图8实施例中的s802、s804。

图10是依据本申请一实施例的计费系统1000的结构示意图。计费系统1000包括接收模块1002和发送模块1004。计费系统1000为图2中的ocs，图3实施例中的计算机设备，以及图4至图8实施例中的ocs。接收模块1002可以用来执行图4实施例中的s4041、s406，图5实施例中的s504、s508，图6实施例中的s602、s607，图7实施例中的s703、s707，图8实施例中的s804。发送模块1004可以用来执行图4实施例中的s4042，图5实施例中的s505，图6实施例中的s603，图7实施例中的s704。

其中，图9和图10实施例中的“模块”可以为专用集成电路(applicationspecificintegratedcircuit，asic)、电子线路、执行一个或多个软件或固件程序的处理器和存储器、组合逻辑电路和其他提供上述功能的组件。可选的，上述计费设备和计费系统通过计算机设备的形式来实现，上述接收模块、发送模块可以通过计算机设备的处理器、存储器和通信接口来实现，上述处理模块可以通过计算机设备的处理器和存储器来实现。

应注意，尽管图3所示的计算机设备300仅仅示出了处理器302、存储器304、通信接口306和总线308，但是在具体实现过程中，本领域的技术人员应当明白，上述计费设备和计费系统还包含实现正常运行所必须的其他器件。同时，根据具体需要，本领域的技术人员应当明白，上述计费设备和计费系统还可包含实现其他附加功能的硬件器件。此外，本领域的技术人员应当明白，上述计费设备和计费系统也可仅仅包含实现本申请实施例所必须的器件，而不必包含图3中所示的全部器件。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。