Application traffic charging for distributed computing

Abstract

The disclosure relates to methods, apparatus and computer-readable storage media for application traffic charging for distributed computing. In a method, a first apparatus transmits, to a second appa

Description

FIELD

[0001] Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for application traffic charging for distributed computing. BACKGROUND

[0002] 5G data connectivity domain charging and charging management are being studied and discussed. A Session Management Function (SMF) embedding the Charging Trigger Function (CTF) generates charging events towards the Charging Function (CHF) for data connectivity converged charging. The charging functions specified for the 5G data connectivity charging includes protocol data unit (PDU) session in SMF, service data flows (SDF) within PDU session and Quality of Service (QoS) flows within PDU session. SUMMARY

[0003] In a first aspect of the present disclosure, there is provided a first apparatus. The first apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to: transmit, to a second apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; and receive, from the second apparatus, a first charging data response.

[0004] In a second aspect of the present disclosure, there is provided a second apparatus. The second apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to: receive, from a first apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; open a charging data record for the application; and transmit, to the first apparatus, a first charging data response.

[0005] In a third aspect of the present disclosure, there is provided a method. The method comprises: transmitting, to a second apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; and receiving, from the second apparatus, a first charging data response.

[0006] In a fourth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a first apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; opening a charging data record for the application; and transmitting, to the first apparatus, a first charging data response.

[0007] In a fifth aspect of the present disclosure, there is provided a first apparatus. The first apparatus comprises means for transmitting, to a second apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; and means for receiving, from the second apparatus, a first charging data response.

[0008] In a sixth aspect of the present disclosure, there is provided a second apparatus. The second apparatus comprises means for receiving, from a first apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; means for opening a charging data record for the application; and means for transmitting, to the first apparatus, a first charging data response.

[0009] In a seventh aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the third aspect or the fourth aspect.

[0010] It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Some example embodiments will now be described with reference to the accompanying drawings, where:

[0012] FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

[0013] FIG. 2 illustrates a signaling flow for a process of application traffic charging according to some example embodiments of the present disclosure;

[0014] FIG. 3 illustrates a signaling flow for a process of application traffic charging according to some example embodiments of the present disclosure;

[0015] FIG. 4 illustrates a signaling flow for a process of application traffic charging according to some example embodiments of the present disclosure;

[0016] FIG. 5 illustrates a signaling flow for a process of application traffic charging according to some example embodiments of the present disclosure;

[0017] FIG. 6 illustrates a flowchart of a method implemented at a first apparatus according to some example embodiments of the present disclosure;

[0018] FIG. 7 illustrates a flowchart of a method implemented at a second apparatus according to some example embodiments of the present disclosure;

[0019] FIG. 8 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

[0020] FIG. 9 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

[0021] Throughout the drawings, the same or similar reference numerals represent the same or similar element. DETAILED DESCRIPTION

[0022] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

[0023] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0024] References in the present disclosure to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0025] It shall be understood that although the terms “first,” “second,”..., etc. in front of noun(s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun(s). For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0026] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0027] As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and / or “including”, when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0029] As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessors), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0030] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term 5 circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular 10 network device, or other computing or network device.

[0031] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Narrow Band Internet of Things (NB-IoT) and so on. 15 Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourth generation (4G), 4.5G, the fifth generation (5G), the sixth generation (6G) communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0032] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP), for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

[0033] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE), an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node). In the following description, the terms “terminal device”, “communication device”, “terminal”, “user equipment” and “UE” may be used interchangeably.

[0034] As used herein, the term “resource,” “transmission resource,” “resource block,” “physical resource block” (PRB), “uplink resource,” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and / or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.

[0035] As discussed above, 5G data connectivity domain charging and charging management are being studied. The SMF embedding the CTF generates charging events towards the CHF for data connectivity converged charging. The charging functions specified for the 5G data connectivity charging includes PDU session in SMF, SDF within PDU session and QoS flows within PDU session.

[0036] The SMF may collect the following charging information for converged charging: • usage of the access and core network resources: the charging information shall describe the amount of data delivered to and forwarded from the UE; • usage duration: duration of PDU session is counted as the time interval from PDU session establishment to PDU session release; • user: the charging information shall provide the actual UE addresses used by the user for the PDU session; • data network: the charging information shall describe the data network addresses with a level of accuracy as determined by the Data Network Name (DNN); • usage of the external data networks: the charging information shall describe the amount of data sent and received to and from the external data network. External networks can be identified by the DNN; • start time: identifying the time when the PDU session was started; • user location: Home Public Land Mobile Network (HPLMN), Visited Public Land Mobile Network (VPLMN), inside / outside presence reporting area, plus optional higher-accuracy location information.

[0037] Triggered by the Policy and Charging Control (PCC) rules received from the policy control function (PCF) or preconfigured information available at SMF, as well as from the CHF for online charging method via quota management mechanisms, the SMF provides Usage Reporting Rules (URR) to the User Plane Function (UPF) for controlling how usage reporting is performed.

[0038] The UPF supports reporting of usage information to the SMF. The UPF can be capable to support reporting based on different triggers, including: • Periodic reporting with period defined by the SMF; • Usage thresholds provided by the SMF; and / or • Report on demand received from the SMF.

[0039] Conventionally, the operator may be able to configure pre-defined PCC Rules in the SMF or dynamic PCC Rules in the PCF that include at least an application identifier for SDF detection, charging control information, i.e. charging key and optionally the Sponsor identifier or the Application Server Provider (ASP) identifier or both. Depending on the service level agreements (SLAs) between the operator and the ASP, it may be possible for the ASP to provide individual packet flow descriptions (PFDs) or the full set of PFDs for each application identifier maintained by the ASP to the SMF via the PFD Management service in the Network Exposure Function (NEF) (PFDF). The PFDs become part of the application detection filters in the SMF / UPF and therefore are used as part of the logic to detect traffic generated by an application.

[0040] For sponsored data connectivity, the PCF uses the Sponsor Identity to construct a Monitoring key for monitoring the volume, time, or both volume and time of user plane traffic, and invoke usage monitoring on the SMF.

[0041] Currently, studies are made with respect to the following aspects: (1) Whether and how to support traffic sent to / from PDU Session Anchor (PSA) after being processed by Edge Hosting Environment, e.g. when there is no communication possibility between the local part of the Data Network (DN) and central part of the DN (e.g. due to usage of private IP address, lack of secure tunnel); (2) Whether and how to support traffic being routed between two Edge Application Server (EASs) located in two different Edge Environments when there is no pre-established communication path between the two local part of the DNs.

[0042] However, traditional solutions about routing processed traffic between two local DNs (EASs) are not applicable to current studies. Charging aspects of the processed traffic sent from / to local part of a DN (L-DN) to / from central part of the DN (C-DN) covered independent from UE subscription / PDU session need to be studied.

[0043] More specifically, there is a need to enable 5G Operators to charge certain application traffic that may not be associated with any specific PDU session and / or the application traffic that is simply transported via the 5G network without being associated with certain specific UE or its ongoing PDU session.

[0044] For the conventional solutions, it is not clear how the charging of the processed traffic at a Local Data Network (L-DN) and / or a Central Data Network (C-DN) should be handled. It may be assumed that the charging can be handled as part of UE PDU session. However, once the UE traffic reaches to L-DN for processing, the L-DN sends the processed traffic to the C-DN via 5GC. After the processing in L-DN, the traffic is not UE traffic anymore. Moreover, such traffic cannot be associated with charging of a given end-user as handling partial / distributed processing at local / edge side and further processing at C-DN is a requirement / preference from application provider or infrastructure owner (in case of private network and handling UE traffic within premises for security reasons). Therefore, charging the processed traffic further to UE subscription is not a proper and fair way.

[0045] In addition to this, the assumption may also include that there may not be direct connectivity between the L-DN and C-DN. This means that there needs to be some possibility for the central part, to load, reload the software of the application on a local Data Network Access Identifier (DNAI), as well as to configure it. It is likely that the application instances on different DNAIs (e.g. central / local) may need to exchange traffic not directly related with the invocation of an application instance on the local DNAI by an end-user.

[0046] As the current charging mechanism is specified for PDU session in SMF, SDF within PDU session and QoS flows within PDU session, it is not possible to charge application provider and / or infrastructure owner who requests partial / distributed computing.

[0047] According to conventional solutions, once UE traffic reaches the L-DN and the processed traffic is sent to the C-DN, it may no longer be considered UE traffic. It is unclear how to handle the charging of this processed traffic at the L-DN and / or C-DN, as the processing occurs at the local / edge side and on the infrastructure owner / application provider side. This creates challenges in applying current charging mechanisms for the application traffic that is transported to the L-DN and / or C-DN without being associated with a specific UE or its ongoing PDU session.

[0048] To solve the above and / or other potential issues, embodiments of the present disclosure propose a solution to enable usage reporting and charging of the transmission of the processed application traffic from / to L-DN to / from C-DN and / or between data network to another data network. The proposed solution enables proper charging by using an application identifier (ID) for each application session. Application traffic at the L-DN or C-DN may be charged, even when it is not associated with a specific UE or PDU session.

[0049] Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0050] FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented. In the communication environment 100, there may be several devices / nodes, including but not limited to, the first apparatus 110 and the second apparatus 120.

[0051] In the following, for the purpose of illustration, some example embodiments are described with the first apparatus 110 operating as a device or apparatus that implements a Session Management Function (SMF) or a Network Exposure Function (NEF) and the second apparatus 120 may operate as a device or apparatus that implements a Charging Function (CHF). However, in some example embodiments, operations described in connection with the first apparatus 110 may be implemented at another device or apparatus that implements a different network function from SMF or NEF, for example. Likewise, operations described in connection with the second apparatus 120 may be implemented at another device or apparatus that implements a different network function from CHF.

[0052] Communications in the communication environment 100 may be implemented according to any proper communication protocol(s), comprising, but not limited to, cellular communication protocols of the first generation (1G), the second generation (2G), the third generation (3G), the fourth generation (4G), the fifth generation (5G), the sixth generation (6G), and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and / or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Division Multiple (OFDM), Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and / or any other technologies currently known or to be developed in the future.

[0053] FIG. 2 illustrates a signaling flow 200 for a process of application traffic charging according to some example embodiments of the present disclosure. For the purposes of discussion, the signaling flow 200 will be discussed with reference to FIG. 1, for example, by using the first apparatus 110 and the second apparatus 120. In some example embodiments, the first apparatus 110 may implement a SMF or a NEF, and the second apparatus 120 may implement a CHF.

[0054] The first apparatus 110 transmits (205) a first charging data request to the second apparatus 120. The first charging data request includes an application identifier (application ID) related to an application for the second apparatus 120 to start a charging session related to the application. It is to be understood that the session for charging may be independent of or irrelevant to a user or an ongoing user’s session.

[0055] The second apparatus 120 receives (210) the first charging data request from the first apparatus 110, and opens (215) a charging data record (CDR) for the application. Then, the second apparatus 120 transmits (220) a first charging data response to the second apparatus. Correspondingly, the first apparatus 110 receives (225) first charging data response from the second apparatus 120, and may know that the charging associated with the application is initiated.

[0056] In some example embodiments, the charging may be associated with traffic exchanging with a data network which comprises one or more Local Data Networks (L-DNs) or a Central Data Network (C-DN).

[0057] In example embodiments of the present disclosure, when the SMF sets up a tunnel between L-DN and C-DN, the SMF invokes a Charging Data Request with the Application Identifier (ID) instead of the User ID. This is different from conventional cases where the first apparatus 110, e.g., SMF, based charging relates to a PDU sessions for a UE, and the SMF invokes Charging Data Request indicating the target User ID (Subscription Permanent Identifier (SUPI)) at the start of a PDU Session.

[0058] Table 1 shows an example of a structure of a Charging Data Request message from the SMF to enable Application-specific charging. Specifically, Table 1 shows the CDR charging data request message content for Application. Table Information Element Category for converged charging Description Application Identifier Oc This field indicates the Application that requires partial / distributed computing, hence, establishment of a tunnel between a local part of DN and central part or another local part of DN. UPF IDs Oc This field holds the UPF identifiers used to identify the UPFs (C-UPF and L-UPF). These fields shall only be included when either quota is requested per UPF, or used units are reported per UPF Application-specific Charging Information Om This field holds the 5G data connectivity specific information.

[0059] Alternatively, in some example embodiments, when there is an AF request (Invocation Request) or an NF notification to NEF that may trigger NEF to create / terminate CDR at CHF or notify AF regarding the charging information, it’s required also to do some changes / corrections in the NEF which may allow the Application Identification and converged charging detailed message format. Table 2 shows an example of a structure of a Charging Data Request message from the NEF to enable Applicationspecific charging. Specifically, Table 2 shows an NEF Charging Data Request Message Content for Application. Table 2 Information Element Category Description Session Identifier Oc Described in TS 32.290

[57] Subscriber Identifier Om Described in TS 32.290

[57] Application Identifier Oc This field holds the identifier of the Application NF Consumer Identification M Described in TS 32.290

[57] Charging Identifier Invocation Timestamp ..........Qm.......... M Described in TS 32.290

[57] Described in TS 32.290

[57] Invocation Sequence Number M Described in TS 32.290

[57] Retransmission Indicator - This field is not applicable. One-time Event Oc Described in TS 32.290

[57] , One-time Event Type Oc Described in TS 32.290

[57] , Notify URI - This field is only applicable for the notification of abort charging. Supported Features Oc Described in TS 32.290

[57] Triggers Oc This field is described in TS 32.290

[57] and holds the NEF specific triggers described in clause 5.4.1.2 Multiple Unit Usage Oc This field contains the parameters for the quota management request and / or usage reporting. Rating Group M Described in TS 32.290

[57] Requested Unit Oc Described in TS 32.290

[57] Used Unit Container Oc Described in TS 32.290

[57] NEF API Charging Information Om This field holds the NEF API specific infonnation described in clause 6.3.1.4

[0060] In addition to the above, Table 3 shows an example of supported fields in Charging Data Request message for Application. In Table 3, “CEF” represents the Charging Enablement Function and “E” represents an event. Table 3 Information Element Analytics and Performance CEF Supported Operation Types E Session Identifier E Subscriber Identifier - Application Identification E NF Consumer Identification E Charging Identifier - Invocation Timestamp E Invocation Sequence Number E One-time Event E One-time Event Type E Retransmission Indicator E Notify URI - Supported Features E Sendee Specification Information E Triggers E Multiple Unit Usage - 5G VNGM Charging Information E

[0061] Based on the received information from SMF, the second apparatus 120, e.g., CHF, may generate CDR(s) and policy counters for the given Application ID and may provide the policy counter. The CDR(s) used in the second apparatus 120 may be 5 implemented in various ways. For example, it may have a newly proposed structure of Application-specific Charging Information. Table 4 shows an example of a structure of Application-specific charging information, whereby application-specific charging information used for 5G data connectivity charging may be provided within this Application-specific charging information. 15 Table 4 Information Element Category* Description Charging Id Om This field holds the Charging Identifier for Application session. Application Id Om This field shall identify the Application ID for which a start or stop of traffic is reported. SMF Charging Id Om This field holds a string that, be provided from the SMF instead of Charging Id, if supported. Data Network Name Identifiers M This field contains the identifier of the DNNs (pair of DNNs) the L-DN and C-DN are belongs to. DNN Selection Mode Oc This field indicates whether the requested DNN corresponds to an explicitly subscribed DNN or to the usage of a wildcard subscription. Application session start Time Oc This field holds the timestamp when application session starts. Application session stop Time Oc This field holds the timestamp when application session terminates. Diagnostics Oc This field holds a detailed reason for the release of the application session and complements the "Change Condition" information. Enhanced Diagnostics Oc This field holds a more detailed reason for the release of the Application session, when a set of causes are applicable. Charging Characteristics** Oc This field holds the Charging Characteristics for this application session. Charging Characteristics Selection Mode Oc This field holds information about how the "Charging Characteristics" was selected. Session Stop Indicator Oc This field indicates to the CHF that the application session has been terminated. Unit Count Inactivity Timer Oc This field holds the threshold for the time period when no units has been counted by the SMF. It holds either the value configured in SMF, if it is supported, or the value to be used as received from the CHF. A value of zero indicates that this mechanism shall not be used. QFI / Traffic Class Usage Reports Om This field holds a list of containers per QFI / Traffic Class with volumes reported, each container is time stamped. QoS Flow / Traffic Class Id Om This field holds the QoS flow Identifier (QFI) / Traffic Class Identifier Start Timestamp Oc This field holds the start timestamp of the collected usage. End Timestamp Oc This field holds the end timestamp of the collected usage. Downlink Volume Oc This field holds the amount of used volume in downlink direction. Uplink Volume Oc This field holds the amount of used volume in uplink direction.

[0062] In the above Table 4, ‘M’ represents a mandatory IE, ‘Oc’ represents Operator Provisional Conditional (up to the operator to used it) and ‘Om’ is Operator Provisional Mandatory. Operator may pre-provision charging characteristics in SMF. 5

[0063] In some example implementations, the second apparatus 120, e.g., CHF, may maintain, by using the EAS(s), charging information related with traffic exchanged between L-DN and C-DN (or between 2 L-DN(s)) for an Application Identifier (ID) in addition to the existing counters for PDU sessions or for a terminal device, e.g., a UE. This charging information may allow to charge an application that has requested the 3GPP Core Network (e.g. 5GC) to support connectivity and traffic exchange between distributed and centralized Edge Application Servers (EASs). This charging information may also involve maintaining spending limits policy counters for the related application traffic

[0064] As the application (identified by the Application ID) that requires partial / distributed computing in L-DN and C-DN or in L-DN and L-DN is not available to the second apparatus 120, e.g., CHF, the first apparatus 110, e.g., SMF, may provide this information to the second apparatus 120 (e.g., CHF). In some example embodiments, the first charging data request may further include information of the application identifier that requires partial / distributed computing in data networks. For example, when the first apparatus 110, e.g., SMF, sets up a tunnel between L-DN and C-DN due to Application Function (AF) provided EAS Deployment Information (EDI) or Traffic Influence (TI) indicating that partial / distributed computing is needed, the SMF may provide the AF identifier (ID) (that is provided as part of EDI or TI) to CHF, e.g., via N40.

[0065] In addition or alternatively, in some example embodiments, the first charging data request may further include a variety of parameters, such as, but not limited to, Data Network Name (DNN) identifiers of a Local Data Network (L-DN) and a Central Data Network (C-DN), DNN identifiers of two L-DNs, an application session start time, an application session stop time, diagnostics or enhanced diagnostic information on release of the session, charging characteristics of the session, session stop for indicating termination of the session, a Quality of Service Flow Identifier (QFI) / traffic class usage report, a traffic class identifier, an Edge Application Server (EAS) / Local Data Network (L-DN), an identifier of Local UPF (L-UPF), an identifier of a further L-UPF, or an identifier of Central-UPF (C-UPF).

[0066] Optionally, the charging data record may be updated. In some example embodiments, the first apparatus 110 may transmit (230), to the second apparatus 120, a second charging data request with the application identifier for updating the charging data record. The second apparatus 120 may receive (235) the second charging data request from the first apparatus 110 and may update (240) the charging data record for the application based on the second charging data request. Then, the second apparatus 120 may transmit (245) a second charging data response to the first apparatus 110. Upon receiving (250) the second charging data response from the second apparatus 120, the first apparatus 110 may be aware that the updating is performed. In this way, the charging data record (CDR) may be updated efficiently and timely. As such, the first apparatus 110 can always records the latest information about the charging data.

[0067] In some example implementations, in addition to indicating the updating of the charging data record, the second charging data request may further include one or more changes of charging conditions. The changes may include, but not limited to, a Quality of Service (QoS) / traffic class change, an Edge Application Server (EAS) change, removal of a L-DN to Central Data Network (C-DN) tunnel, or establishment of another L-DN to C-DN tunnel, removal of a L-DN to another L-DN tunnel, establishment of another L-DN to L-DN tunnel, and / or the like.

[0068] When the second apparatus 120, e.g., CHF, receives the second charging data request (e.g., Charging Data Request [Update] with Application ID as discussed with respect to FIG. 3 below) with the change conditions identified in the following Table 5, the charging information may be added in the specific Application charging CHF CDR, and the CDR may remain open, as the default supported mechanism. As shown, Table 5 illustrates an example of triggers for CHF CDR charging information addition - for Application. Table 5 Trigger Conditions Applicable for converged charging Change of Charging conditions QoS / traffic class change Yes EAS change Yes Removal of L-DN to C-DN tunnel Yes Establishment of another L-DN to C-DN tunnel Yes Removal of a L-DN to another L-DN tunnel Yes Establishment of another L-DN to L-DN tunnel Yes Limit per Rating Group Expiry of data time limit per RG Yes Expiry of data volume limit per RG Yes Expiry of data event limit per RG Yes Quota management triggers Time threshold reached Yes Volume threshold reached Yes Unit threshold reached Yes Time quota exhausted Yes Volume quota exhausted Yes Unit quota exhausted Yes Expiry of quota validity time Yes Re-authorization request by CHF Yes Trigger Conditions Applicable for converged charging Change of Charging conditions QoS / traffic class change Yes EAS / L-DN Location change Yes Removal of L-DN to C-DN tunnel Yes Establishment of another L-DN to C-DN tunnel Yes Limit per Rating Group Expiry of data time limit per RG Yes Expiry of data volume limit per RG Yes Expiry of data event limit per RG Yes Quota management triggers Time threshold reached Yes Volume threshold reached Yes Unit threshold reached Yes Time quota exhausted Yes Volume quota exhausted Yes Unit quota exhausted Yes Expiry of quota validity time Yes Re-authorization request by CHF Yes

[0069] In addition or alternatively, the second charging data request may indicate that a quota is requested for an application identifier related to an application in a start of service data flow. For example, the first apparatus 110, e.g., SMF, may create a Charging Identifier for an application and send a Charging Data Request with the Application ID of the application to the second apparatus 120, e.g., CHF. In the case where a "start of service data flow" needs quota from the CHF, the SMF may request quota for the specific Application ID.

[0070] As for the CHF, it may open the CDR for this application and send a Charging Data Response to the SMF that includes the Application ID of the application. In the case where "start of service data flow" needs quota from CHF, the CHF may update CDR for the specific application and send a Charging Data Response to the SMF including the quota for the Application ID of the specific application.

[0071] It is to be understood that although in some examples the SMF and CHF are used as examples to discuss the first apparatus 110 and the second apparatus 120, they are just discussed for illustration, rather than suggesting any limitations. In another example embodiment, CHF selection / profile at NRF also is also updated to consider Range(s) of Application IDs.

[0072] Optionally, the charging associated with the session may be terminated. In some example embodiments, the first apparatus 110 may transmit (255), to the second apparatus 120, a third charging data request with the application identifier for terminating charging associated with the session.

[0073] The second apparatus 120 upon receiving (260) the third charging data request from the first apparatus 110, may close (265) the charging data record for the application and then transmit (270), to the first apparatus 110, a third charging data response to the third charging data request. Correspondingly, the first apparatus 110 may receive (275) the third charging data response from the second apparatus 120 and thus may be aware that the charging data record for the application is closed.

[0074] In this way, the charging data record (CDR) may be closed timely when it is not needed any more, which facilitates the management of the CDR(s) at the first apparatus 110.

[0075] In some example embodiments, the first apparatus 110 may exchange with a third apparatus quota related information received from the second apparatus, an application identifier to be associated with the data session supported by the third apparatus, and / or the like. The third apparatus may be a device implementing a User Plane Function (UPF), which is also referred to as “UPF” in some example embodiments for purpose of discussion. In some example implementations, the first apparatus 110 may determine a pair of Data Network Access Identifiers (DNAIs) based on the at least one parameter and transmit the pair of DNAIs to the second apparatus 120.

[0076] In some example embodiments, the first apparatus 110 may transmit the application identifier to a device implementing a Network Repository Function (NRF). Then, the first apparatus 110 may receive, from the device implementing the NRF, information about at least one instance of the CHF associated with the application identifier.

[0077] Optionally, in some example embodiments, the second apparatus 120 may obtain charging information related to the traffic exchanged with the data networks for the application identifier based on the charging data record for the application. Then, the second apparatus 120 may determine a spending limit counter for the application identifier based on the charging information. It is to be understood that this policy is a spending policy.

[0078] In addition to the above, optionally, the second apparatus 120 may provide the spending limit counter for the application identifier in response to a request of a policy controller. It is also to be understood that the policy related to the spending limit counter is a spending policy.

[0079] Additionally, in some example embodiments, there may be some impacts on the CHF service consumer. Specifically, a CHF service consumer may convey the Range(s) or lists of Application IDs along other parameters, to invoke the Nnrf_NFDiscovery service for the CHF instance(s) and CHF service(s) instance(s) discovery.

[0080] Still further, it is to be understood that, although some example embodiments indicate that the proposed solutions applies to any kind of access, this does not mean only 5G or 6G 3GPP access but also Non-3GPP access (e g., Wireline access, Untrusted non-3GPP access, Trusted non-3GPP access using a Wireline Access Gateway Function (W-AGF) / Wireline Access Gateway Function (N3IWF) / Trusted Non-3GPP Gateway Function (TNGF) to a 5G core or to a 6G Core), even though only 5G NR / RAN and 5GC are mentioned as access and Core network in some example embodiments discussed below.

[0081] More details will be discussed below with reference to FIGS. 3 to 5.

[0082] FIG. 3 illustrates a signaling flow 300 for a process of application traffic charging according to some example embodiments of the present disclosure. The signaling flow 300 involves a plurality of devices / nodes implementing different network functions, such as, a CHF 301, a SMF 302, a PCF 303, a NEF 304, an AF 305, an L-EAS 306, an L-PSA UPF 307, a C-PSA UPF 308 and a C-EAS 309.

[0083] It is to be understood that although the signaling flow 300 discussed with respect to the example embodiments of FIG. 3 is related to the case involving a L-DN and a C-DN, the procedure discussed in FIG. 3 also applies to the case of two L-DNs. For example, in the latter case, the C-PSA UPF 308 may be replaced with another L-PSA UPF and the C-EAS 309 may be replace with another L-EAS.

[0084] In the example embodiments discussed with respect to FIG. 3, the SMF 302 may be considered as an implementation of the first apparatus 110 discussed in FIGS. 1 and 2, and the CHF 301 may be considered as an implementation of the second apparatus 120 discussed in FIGS. 1 and 2. It is to be understood that the CHF 301 and the SMF 302 are just examples for discussion, rather than suggesting any limitations.

[0085] The example embodiments discussed with respect to FIG. 3 propose enhancements to the procedure of establishing a tunnel between local and central parts of DN 1. When the SMF 302 receives EDI and determines as part of the EDI that it needs to select C-PSA UPF 308 and L-PSA UPF 307 and then establish a tunnel(s) in between, the SMF 302 (via CTF) also triggers Charging Data Request including the Application ID to CHF 301.

[0086] FIG. 3 shows charging aspects related enhancements to procedure of establishing a tunnel between local and central parts of DN. At 311, the AF 305 requests to establish a tunnel between local and central parts of DN. At 312, the SMF 302 is triggered to retrieve AF 305 provided EDI.

[0087] At 313, the SMF 302 performs a L-PSA UPF and C-PSA UPF selection based on the retrieved information. Specifically, at this step, the SMF 302 decides to establish tunnel for processed traffic between L-PSA UPF 307 and C-PSA UPF 308, and thus also triggers the following step 313ch-a. Accordingly, the SMF 302 selects L-PSA UPF 307 and C-PSA UPF 308.

[0088] At 313ch-a, the SMF 302 transmits a charging data request (e.g., Charging Data Request [Initial]) with the Application ID to the CHF 301. Specifically, at this step, the SMF 302 creates a Charging Identifier for the Application, and sends the Charging Data Request [initial] with Application ID (and possibly with one or more other parameters listed in the above Table 4 such as QFI / traffic class Usage Reports and QoS Flow / traffic class Id) to CHF for authorization for the Application to start a session. This session may be for exchanging traffic not directly related with the invocation of an application instance on the local DNAI by an end-user. Alternatively, this session may be for exchanging traffic directly related with the invocation of an application instance on the local / central part of DN by an end-user.

[0089] At 313ch-b, the CHF 301 opens a CDR for this Application ID.

[0090] At 313ch-c, the CHF 301 transmits a charging data response (e.g., Charging Data Response [Initial]) that may include the Application ID to the SMF 302.

[0091] At 314, the SMF 302 transmits a N4 session establishment request (including PDR-1 and FAR-1) to the C-PSA UPF 308. At 314-1, the C-PSA UPF 308 performs the session configuration and UL TEID selection. The UL TEID is responded to SMF 302 at 315, which will be used to configure L-PSA UPF 307 to forward L-EAS 306’s UL traffic to C-EAS 309 via C-PSA UPF 308.

[0092] As shown in FIG. 3, at 315, the C-PSA UPF 308 transmits a N4 session establishment response (including UL TEID of the tunnel) to the SMF 302.

[0093] At 316, the SMF 302 transmits a N4 session establishment request (including UL TEID of the tunnel, PDR-2 and FAR-2) to the L-PSA UPF 307. At 316-1, L-PSA UPF 307 performs the tunnel configuration and DL TEID selection. The DL TEID is responded to SMF 302 in 317, which will be used to configure C-PSA UPF 308 to forward C-EAS’s DL traffic to L-EAS 306 via L-PSA UPF 307.

[0094] At 316-2, there is a UL communication related to the L-PSA UPF 307 and the C-PSA UPF 308. The UL tube at 316-2 shows the UL data plane traffic between the L-PSA UPF 307 and the C-PSA UPF 308. At 316-3, there may be first uplink data from L-EAS 306 to C-EAS 309. It has to be noted that steps 314-317 may take place before or after step 313-cha 313-chb. The steps 314 and 316 may also contain N4 rules related with charging on this N4 session. The N4 sessions created at steps 314 / 316 do not depend on a PDU session and are not associated with an UE IP address but may be associated with an EAS IP address.

[0095] At 317ch-a, the SMF 302 transmits a charging data request with the Application ID for updating to the CHF 301. For example, the SMF 302 may transmit a charging data request for updating (e.g., Charging Data Request [Update]) to the CHF 301. This step may occur in case "start of service data flow" needs quota from the CHF 301, for the SMF 302 to request quota for the specific Application ID. Specifically, in that case, the charging data request transmitted at 317ch-a may indicate that a quota is requested for an application ID at the start of service data flow. When at 317ch-a or 321ch-a, the SMF requests quota or indicate quota consumption to the CHF, the SMF may provide a Charging key and / or a Service Identifier (Charging key and / or a Service Identifier as defined in TS 23.503 Table 6.3.1 “The PCC rule information in 5GC“) that it has determined based on local policies related with the DNN and the slice (S-NSSAI) associated with the corresponding tunnel (e.g. between L-DN and C-DN). These local policies may associate tunnels between a L-DN and central DN C-DN with different Charging key and / or Service Identifier than for tunnels between local L-DN(s);

[0096] At 317ch-b, the CHF 301 updates CDR for this Application ID.

[0097] At 317ch-c, the CHF 301 transmits a charging data response (e.g., Charging Data Response [Update]) for Application ID to the SMF 302. That is, the CHF 301 acknowledges by sending Charging Data Response [Update] possibly including the Application ID to the SMF 302.

[0098] Optionally, in some example embodiments, the SMF 302 may exchange with another apparatus, e.g., UPF, quota related information received from the CHF 301, an application ID to be associated with the data session supported by the UPF, and / or the like.

[0099] At 318, the SMF 302 transmits a N4 session update request (including PDR-3 and FAR-3) the L-PSA UPF 307.

[0100] At 319, the L-PSA UPF 307 transmits a N4 session update response to the SMF 302.

[0101] At 320, the SMF 302 transmits a N4 session update request (including DL TEID of the tunnel, PDR-4 and FAR-4) to the C-PSA UPF 308. At 320-1, there may be a downlink (DL) transmission related to the L-PSA UPF 307 and the C-PSA UPF 308. As shown by the DL tube at 320-1, there is a DL data plane traffic between the L-PSA UPF 307 and the C-PSA UPF 308. At 320-2, there may be first downlink data from C-EAS 309 to L-EAS 306.

[0102] At 321, the C-PSA UPF 308 transmits a N4 session update response to the SMF 302.

[0103] From Steps 314 to 317 and Steps 318 to 321, UPF (e g., the C-PSA UPF 308) reports usage to SMF 302 based on the reporting triggering configured by SMF. The following example embodiments provide further details on what information as part of Application Identification IE within the Usage Report from UPF is included for the SMF 302.

[0104] Specifically, these example embodiments propose enhancements to the existing information exchange between the SMF and UPF. The SMF may include an application identifier to associate the data session supported by UPF and quota related information to the UPF. The UPF may include these information elements when it reports usage in Usage Report.

[0105] The SMF 302 may then use the quota and application identifier into information provided to the CHF about the pair of corresponding DNAI(s). The CHF 301 may then maintain different sets of CDR information for different pairs of DNAI.

[0106] Still referring to FIG. 3, at 321ch-a, the SMF 302 transmits a charging data request with the application identifier for terminating charging associated with the session. Specifically, the SMF 302 may send a Charging Data Request [Termination] to the CHF 301 for terminating the charging associated with PDU sessions, with the trigger "End of Application Session".

[0107] At 321ch-b, the CHF 301 closes CDR for this Application ID.

[0108] At 321ch-c, the CHF 301 acknowledges by transmitting a Charging Data Response [Termination] (for Application ID) to the SMF 302.

[0109] It is to be understood that the steps from 317ch-a to 317ch-c for quota request from CHF 301 regarding the Application ID are not applicable for Converged PEC charging scenario. The proposed enhancements may be applied to message flows captured for PDU session charging in other suitable cases with the inclusion of Application ID in the request or response message(s) for opening, updating or closing the CDR as discussed above.

[0110] In order to achieve this, in some example embodiments, Nchf ConvergedCharging service may be enhanced to include Application ID as part of input parameters of Nchf ConvergedCliarging Create / Update / Release / Xotif'y service.

[0111] In this case, there may be a need to update the following charging scenarios taking in account the business model applied: • Post Event Charging (PEC), • Immediate Event Charging (IEC), • Event Charging with Unit Reservation (ECUR), • Session Charging with Unit Reservation (SCUR).

[0112] As an alternative to the above embodiments discussed mainly with reference to the CHF and SMF, the proposed Application Identifier / Application Identification may be used by CHF for converged charging when NEF sends Charging Data Request following either an API Invocation Request (as shown in FIG. 4) or a notification from an NF (as shown in FIG. 5).

[0113] FIG. 4 illustrates a signaling flow 400 for a process of application traffic charging according to some example embodiments of the present disclosure. The signaling flow 400 involves a plurality of devices / nodes implementing different network functions, such as, a CHF 401 and a NEF 402.

[0114] In the example embodiments discussed with respect to FIG. 4, the NEF 402 may be considered as an implementation of the first apparatus 110 discussed in FIGS. 1 and 2, and the CHF 401 may be considered as an implementation of the second apparatus 120 discussed in FIGS. 1 and 2. It is to be understood that the CHF 401 and the NEF 402 are just examples for discussion, rather than suggesting any limitations.

[0115] In the signaling flow 400, an API Invocation Request to NEF 402 triggers the charging data request with Application Identifier to CHF 401. At 411, the NEF 402 receives the API invocation Request, e.g., from an AF.

[0116] At 411ch-a, the NEF 402 sends a charging data request (e.g., Charging Data Request [Event]) for the specific Application ID to CHF for the received API Invocation.

[0117] At 411ch-b, the CHF 401 creates a CDR for this API Invocation for this Application ID.

[0118] At 411ch-c, the CHF 401 acknowledges and grants authorization by sending a charging data response (e.g., Charging Data Response [Event]) for the specific Application ID to the NEF 402.

[0119] At 412, the NEF 402 performs the actions needed to fulfil the API invoked.

[0120] At 413, if authorized, the NEF 402 continues the API invocation processing and sends the API Invocation Response.

[0121] FIG. 5 illustrates a signaling flow 500 for a process of application traffic charging according to some example embodiments of the present disclosure. The signaling flow 500 involves a plurality of devices / nodes implementing different network functions, such as, a CHF 401 and a NEF 402.

[0122] In the example embodiments discussed with respect to FIG. 5, the NEF 402 may be considered as an implementation of the first apparatus 110 discussed in FIGS. 1 and 2, and the CHF 401 may be considered as an implementation of the second apparatus 120 discussed in FIGS. 1 and 2. It is to be understood that the CHF 401 and the NEF 402 are just examples for discussion, rather than suggesting any limitations.

[0123] In the signaling flow 500, an API Notification from NEF based on notification from NF triggers charging data request with Application Identifier to CHF. At 511, the NEF 402 receives a notification from an NF.

[0124] At 511ch-a, the NEF 402 sends a charging data request (e.g., Charging Data Request [Event]) for the specific Application ID to CHF for the Notification.

[0125] At 51 Ich-b, the CHF 401 creates a CDR for this Notification for this Application ID.

[0126] At 511ch-c, the CHF 401 acknowledges and grants authorization by sending a charging data response (e.g., Charging Data Response [Event]) for the specific Application ID to the NEF 402.

[0127] At 512, the NEF 402 sends the notification to AF.

[0128] At 513, the NEF 402 receives acknowledgement for the notification.

[0129] In some further example embodiments of the present disclosure, enhancements to the NnrfNFManagementNFRegister service are proposed. The NnrfJNFManagementJNF Regis ter service invoked by CHF for CHF instance(s) and CHF service(s) instance(s) registration may include but not limited to: • Range(s) of SUPIs, • Range(s) of GPSIs, • Range(s) of PLMNs, • CHF Group ID, • CHF set ID, • CHF service set ID, • Locality.

[0130] These parameters may be used by CHF service consumer(s) invoking the Nnrf_NFDiscovery service for the CHF instance(s) and CHF service(s) instance(s) discovery. In one solution, the existing list of parameters is enhanced to also include Range(s) or List of Application IDs. In an example, SMF may query NRF with Nnrf NFDiscovery service with a (or list of) Application ID(s). NRF checks the registered CHF instances that in particularly has the provided (list of) Application ID(s), and NRF responds back to SMF with the CHF instance(s) for the given Application ID(s).

[0131] The Range(s) of Application IDs may be also considered as part of the Nnrf NFManagement NFRegister service or CHF profile as stored in the NRF.

[0132] FIG. 6 shows a flowchart of an example method 600 implemented at a first apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the first apparatus 110 in FIG. 1

[0133] At block 610, the first apparatus 110 transmits, to a second apparatus 120, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application.

[0134] At block 620, the first apparatus 110 receives, from the second apparatus 120, a first charging data response.

[0135] In some example embodiments, the method 600 further comprises: transmitting, to the second apparatus, a second charging data request with the application identifier for updating; and receiving, from the second apparatus, a second charging data response.

[0136] In some example embodiments, the second charging data request further comprises at least one of the following change of charging conditions: a Quality of Service (QoS) / traffic class change, an Edge Application Server (EAS) change, removal of a L-DN to Central Data Network (C-DN) tunnel, or establishment of another L-DN to C-DN tunnel, removal of a L-DN to another L-DN tunnel, or establishment of another L-DN to L-DN tunnel.

[0137] In some example embodiments, the second charging data request indicates that a quota is requested for an application identifier in a start of service data flow.

[0138] In some example embodiments, the method 600 further comprises: transmitting, to the second apparatus, a third charging data request with the application identifier for terminating charging associated with the session; and receiving, from the second apparatus, a third charging data response.

[0139] In some example embodiments, the first charging data request further comprises information of the application identifier that requires partial / distributed computing in data networks.

[0140] In some example embodiments, the first charging data request further comprises at least one of the following parameters: Data Network Name (DNN) identifiers of a Local Data Network (L-DN) and a Central Data Network (C-DN), DNN identifiers of two L-DNs, an application session start time, an application session stop time, diagnostics or enhanced diagnostic information on release of the session, charging characteristics of the session, session stop for indicating termination of the session, a Quality of Service flow Identifier (QFI) / traffic class usage report, a traffic class identifier, an Edge Application Server (EAS) / Local Data Network (L-DN), an identifier of Local UPF (L-UPF), an identifier of a further L-UPF, or an identifier of Central-UPF (C-UPF).

[0141] In some example embodiments, the method 600 further comprises: exchanging with a third apparatus, at least one of the following: quota related information received from the second apparatus, or an application identifier to be associated with the data session supported by the third apparatus.

[0142] In some example embodiments, the third apparatus implementing a User Plane Function (UPF).

[0143] In some example embodiments, the method 600 further comprises: determining a pair of Data Network Access Identifiers (DNAIs) based on the at least one parameter; and transmitting, to the second apparatus, the pair of DNAIs.

[0144] In some example embodiments, the method 600 further comprises: transmitting the application identifier to a device implementing a Network Repository Function (NRF); and receiving, from the device implementing the NRF, information about at least one instance of Charging Function (CHF) associated with the application identifier.

[0145] In some example embodiments, the charging is associated with traffic exchanging with a data network which comprises one or more Local Data Networks (L-DNs) or a Central Data Network (C-DN).

[0146] In some example embodiments, the session for charging is independent of a user or an ongoing user’s session.

[0147] In some example embodiments, the first apparatus implements a Session Management Function (SMF) or a Network Exposure Function (NEF), and the second apparatus implements a Charging Function (CHF).

[0148] FIG. 7 shows a flowchart of an example method 700 implemented at a second apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the second apparatus 120 in FIG. 1.

[0149] At block 710, the second apparatus 120 receives, from a first apparatus 110, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application.

[0150] At block 720, the second apparatus 120 opens a charging data record for the application.

[0151] At block 730, the second apparatus 120 transmits, to the first apparatus, a first charging data response.

[0152] In some example embodiments, the method 700 further comprises: receiving, from the first apparatus, a second charging data request with the application identifier for updating; updating the charging data record for the application based on the second charging data request; and transmitting, to the first apparatus, a second charging data response.

[0153] In some example embodiments, the second charging data request further comprises at least one of the following change of charging conditions: a Quality of Service (QoS) / traffic class change, an Edge Application Server (EAS) change, removal of a L-DN to Central Data Network (C-DN) tunnel, or establishment of another L-DN to C-DN tunnel, removal of a L-DN to another L-DN tunnel, or establishment of another L-DN to L-DN tunnel.

[0154] In some example embodiments, the second charging data request indicates that quota is requested for an application identifier in a start of service data flow.

[0155] In some example embodiments, the method 700 further comprises: receiving, from the first apparatus, a third charging data request with the application identifier for terminating charging associated with the session; close the charging data record for the application; and transmitting, to the first apparatus, a third charging data response to the third charging data request.

[0156] In some example embodiments, the first charging data request further comprises information of the application identifier that requires partial / distributed computing in data networks.

[0157] In some example embodiments, the first charging data request further comprises at least one of the following parameters: Data Network Name (DNN) identifiers of a Local Data Network (L-DN) and a Central Data Network (C-DN), DNN identifiers of two L-DNs, an application session start time, an application session stop time, diagnostics or enhanced diagnostic information on release of the session, charging characteristics of the session, session stop for indicating termination of the session, a Quality of Service flow Identifier (QFI) / traffic class usage report, a traffic class identifier, an Edge Application Server (EAS) / Local Data Network (L-DN), an identifier of Local UPF (L-UPF), an identifier of a further L-UPF, or an identifier of Central-UPF (C-UPF).

[0158] In some example embodiments, the method 700 further comprises: obtaining charging information related to the traffic exchanged with the data networks for the application identifier based on the charging data record for the application; and determining a spending limit counter for the application identifier based on the charging information.

[0159] In some example embodiments, the method 700 further comprises: providing the spending limit counter for the application identifier in response to a request of a policy controller.

[0160] In some example embodiments, the charging is associated with traffic exchanging with a data network which comprises one or more Local Data Networks (L-DNs) or a Central Data Network (C-DN).

[0161] In some example embodiments, the first apparatus implements a Session Management Function (SMF) or a Network Exposure Function (NEF), and the second apparatus implements a Charging Function (CHF).

[0162] In some example embodiments, a first apparatus capable of performing any of the method 600 (for example, the first apparatus 110 in FIG. 1) may comprise means for performing the respective operations of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The first apparatus may be implemented as or included in the first apparatus 110 in FIG. 1.

[0163] In some example embodiments, the first apparatus comprises means for transmitting, to a second apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; and means for receiving, from the second apparatus, a first charging data response.

[0164] In some example embodiments, the first apparatus further comprises: means for transmitting, to the second apparatus, a second charging data request with the application identifier for updating; and means for receiving, from the second apparatus, a second charging data response.

[0165] In some example embodiments, the second charging data request further comprises at least one of the following change of charging conditions: a Quality of Service (QoS) / traffic class change, an Edge Application Server (EAS) change, means for removal of a L-DN to Central Data Network (C-DN) tunnel, or means for establishment of another L-DN to C-DN tunnel, means for removal of a L-DN to another L-DN tunnel, or means for establishment of another L-DN to L-DN tunnel.

[0166] In some example embodiments, the second charging data request indicates that a quota is requested for an application identifier in a start of service data flow.

[0167] In some example embodiments, the first apparatus further comprises: means for transmitting, to the second apparatus, a third charging data request with the application identifier for terminating charging associated with the session; and means for receiving, from the second apparatus, a third charging data response.

[0168] In some example embodiments, the first charging data request further comprises information of the application identifier that requires partial / distributed computing in data networks.

[0169] In some example embodiments, the first charging data request further comprises at least one of the following parameters: Data Network Name (DNN) identifiers of a Local Data Network (L-DN) and a Central Data Network (C-DN), DNN identifiers of two L-DNs, an application session start time, an application session stop time, diagnostics or enhanced diagnostic information on release of the session, charging characteristics of the session, means for session stop for indicating termination of the session, a Quality of Service flow Identifier (QFI) / traffic class usage report, a traffic class identifier, an Edge Application Server (EAS) / Local Data Network (L-DN), an identifier of Local UPF (L-UPF), an identifier of a further L-UPF, or an identifier of Central-UPF (C-UPF).

[0170] In some example embodiments, the first apparatus further comprises: means for exchanging with a third apparatus, at least one of the following: means for quota related information received from the second apparatus, or an application identifier to be associated with the data session supported by the third apparatus.

[0171] In some example embodiments, the third apparatus implementing a User Plane Function (UPF).

[0172] In some example embodiments, the first apparatus further comprises: means for determining a pair of Data Network Access Identifiers (DNAIs) based on the at least one parameter; and means for transmitting, to the second apparatus, the pair of DNAIs.

[0173] In some example embodiments, the first apparatus further comprises: means for transmitting the application identifier to a device implementing a Network Repository Function (NRF); and means for receiving, from the device implementing the NRF, information about at least one instance of Charging Function (CHF) associated with the application identifier.

[0174] In some example embodiments, the charging is associated with traffic exchanging with a data network which comprises one or more Local Data Networks (L-DNs) or a Central Data Network (C-DN).

[0175] In some example embodiments, the session for charging is independent of a user or an ongoing user’s session.

[0176] In some example embodiments, the first apparatus implements a Session Management Function (SMF) or a Network Exposure Function (NEF), and the second apparatus implements a Charging Function (CHF).

[0177] In some example embodiments, the first apparatus further comprises means for performing other operations in some example embodiments of the method 600 or the first apparatus 110. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the first apparatus.

[0178] In some example embodiments, a second apparatus capable of performing any of the method 700 (for example, the second apparatus 120 in FIG. 1) may comprise means for performing the respective operations of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The second apparatus may be implemented as or included in the second apparatus 120 in FIG. 1.

[0179] In some example embodiments, the second apparatus comprises means for receiving, from a first apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; means for opening a charging data record for the application; and means for transmitting, to the first apparatus, a first charging data response.

[0180] In some example embodiments, the second apparatus further comprises: means for receiving, from the first apparatus, a second charging data request with the application identifier for updating; means for updating the charging data record for the application based on the second charging data request; and means for transmitting, to the first apparatus, a second charging data response.

[0181] In some example embodiments, the second charging data request further comprises at least one of the following change of charging conditions: a Quality of Service (QoS) / traffic class change, an Edge Application Server (EAS) change, means for removal of a L-DN to Central Data Network (C-DN) tunnel, or means for establishment of another L-DN to C-DN tunnel, means for removal of a L-DN to another L-DN tunnel, or means for establishment of another L-DN to L-DN tunnel.

[0182] In some example embodiments, the second charging data request indicates that quota is requested for an application identifier in a start of service data flow.

[0183] In some example embodiments, the second apparatus further comprises: means for receiving, from the first apparatus, a third charging data request with the application identifier for terminating charging associated with the session; close the charging data record for the application; and means for transmitting, to the first apparatus, a third charging data response to the third charging data request.

[0184] In some example embodiments, the first charging data request further comprises information of the application identifier that requires partial / distributed computing in data networks.

[0185] In some example embodiments, the first charging data request further comprises at least one of the following parameters: Data Network Name (DNN) identifiers of a Local Data Network (L-DN) and a Central Data Network (C-DN), DNN identifiers of two L-DNs, an application session start time, an application session stop time, diagnostics or enhanced diagnostic information on release of the session, charging characteristics of the session, means for session stop for indicating termination of the session, a Quality of Service flow Identifier (QFI) / traffic class usage report, a traffic class identifier, an Edge Application Server (EAS)ZLocal Data Network (L-DN), an identifier of Local UPF (L-UPF), an identifier of a further L-UPF, or an identifier of Central-UPF (C-UPF).

[0186] In some example embodiments, the second apparatus further comprises: means for obtaining charging information related to the traffic exchanged with the data networks for the application identifier based on the charging data record for the application; and means for determining a spending limit counter for the application identifier based on the charging information.

[0187] In some example embodiments, the second apparatus further comprises: means for providing the spending limit counter for the application identifier in response to a request of a policy controller.

[0188] In some example embodiments, the charging is associated with traffic exchanging with a data network which comprises one or more Local Data Networks (L-DNs) or a Central Data Network (C-DN).

[0189] In some example embodiments, the first apparatus implements a Session Management Function (SMF) or a Network Exposure Function (NEF), and the second apparatus implements a Charging Function (CHF).

[0190] In some example embodiments, the second apparatus further comprises means for performing other operations in some example embodiments of the method 700 or the second apparatus 120. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the second apparatus.

[0191] FIG. 8 is a simplified block diagram of a device 800 that is suitable for implementing example embodiments of the present disclosure. The device 800 may be provided to implement a communication device, for example, the first apparatus 110 or the second apparatus 120 as shown in FIG. 1. As shown, the device 800 includes one or more processors 810, one or more memories 820 coupled to the processor 810, and one or more communication modules 840 coupled to the processor 810.

[0192] The communication module 840 is for bidirectional communications. The communication module 840 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 840 may include at least one antenna.

[0193] The processor 810 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 800 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0194] The memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 824, an electrically programmable read only memory (EPROM), a flash memory, a hard disk, a compact disc (CD), a digital video disk (DVD), an optical disk, a laser disk, and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 822 and other volatile memories that will not last in the power-down duration.

[0195] A computer program 830 includes computer executable instructions that are executed by the associated processor 810. The instructions of the program 830 may include instructions for performing operations / acts of some example embodiments of the present disclosure. The program 830 may be stored in the memory, e.g., the ROM 824. The processor 810 may perform any suitable actions and processing by loading the program 830 into the RAM 822.

[0196] The example embodiments of the present disclosure may be implemented by means of the program 830 so that the device 800 may perform any process of the disclosure as discussed with reference to FIG. 1 to FIG. 7. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0197] In some example embodiments, the program 830 may be tangibly contained in a computer readable medium which may be included in the device 800 (such as in the memory 820) or other storage devices that are accessible by the device 800. The device 800 may load the program 830 from the computer readable medium to the RAM 822 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e g., RAM vs. ROM).

[0198] FIG. 9 shows an example of the computer readable medium 900 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 900 has the program 830 stored thereon.

[0199] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0200] Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non-transitory computer readable medium. The computer program product includes computerexecutable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0201] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0202] In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[0203] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0204] Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

[0205] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A first apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to:transmit, to a second apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; andreceive, from the second apparatus, a first charging data response.

2. The first apparatus of claim 1, wherein the first apparatus is caused to:transmit, to the second apparatus, a second charging data request with the application identifier for updating; andreceive, from the second apparatus, a second charging data response.

3. The first apparatus of claim 2, wherein the second charging data request further comprises at least one of the following change of charging conditions:a Quality of Service (QoS) / traffic class change,an Edge Application Server (EAS) change,removal of a L-DN to Central Data Network (C-DN) tunnel, orestablishment of another L-DN to C-DN tunnel,removal of a L-DN to another L-DN tunnel, orestablishment of another L-DN to L-DN tunnel.

4. The first apparatus of claims 2 and 3, wherein the second charging data request indicates that a quota is requested for an application identifier in a start of service data flow.

5. The first apparatus of any of claims 1 to 4, wherein the first apparatus is causedto:transmit, to the second apparatus, a third charging data request with the application identifier for terminating charging associated with the session; andreceive, from the second apparatus, a third charging data response.

6. The first apparatus of any of claims 1 to 5, wherein the first charging data request further comprises information of the application identifier that requires partial / distributed computing in data networks.

7. The first apparatus of any of claims 1 to 6, wherein the first charging data request further comprises at least one of the following parameters:Data Network Name (DNN) identifiers of a Local Data Network (L-DN) and a Central Data Network (C-DN),DNN identifiers of two L-DNs,an application session start time,an application session stop time,diagnostics or enhanced diagnostic information on release of the session,charging characteristics of the session,session stop for indicating termination of the session,a Quality of Service flow Identifier (QFI) / traffic class usage report,a traffic class identifier,an Edge Application Server (EAS) / Local Data Network (L-DN),an identifier of Local UPF (L-UPF),an identifier of a further L-UPF, oran identifier of Central-UPF (C-UPF).

8. The first apparatus of any of claims 1 to 7, wherein the first apparatus is caused to:exchange with a third apparatus, at least one of the following:quota related information received from the second apparatus, oran application identifier to be associated with the data session supported by the third apparatus.

9. The first apparatus of claim 8, wherein the third apparatus implementing a User Plane Function (UPF).

10. The first apparatus of claim 8 or 9, wherein the first apparatus is caused to:determine a pair of Data Network Access Identifiers (DNAIs) based on the at least one parameter; andtransmit, to the second apparatus, the pair of DNAIs.

11. The first apparatus of any of claims 1 to 10, wherein the first apparatus is caused to:transmit the application identifier to a device implementing a Network Repository Function (NRF); andreceive, from the device implementing the NRF, information about at least one instance of Charging Function (CHF) associated with the application identifier.

12. The first apparatus of any of claims 1 to 11, wherein the charging is associated with traffic exchanging with a data network which comprises one or more Local Data Networks (L-DNs) or a Central Data Network (C-DN).

13. The first apparatus of any of claims 1 to 12, wherein the session for charging is independent of a user or an ongoing user’s session.

14. The first apparatus of any of claims 1 to 13, wherein the first apparatus implements a Session Management Function (SMF) or a Network Exposure Function(NEF), and the second apparatus implements a Charging Function (CHF).

15. A second apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to:receive, from a first apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application;open a charging data record for the application; andtransmit, to the first apparatus, a first charging data response.

16. The second apparatus of claim 15, wherein the second apparatus is caused to:receive, from the first apparatus, a second charging data request with the application identifier for updating;update the charging data record for the application based on the second charging data request; andtransmit, to the first apparatus, a second charging data response.

17. The second apparatus of claim 16, wherein the second charging data request further comprises at least one of the following change of charging conditions:a Quality of Service (QoS) / traffic class change,an Edge Application Server (EAS) change,removal of a L-DN to Central Data Network (C-DN) tunnel, orestablishment of another L-DN to C-DN tunnel,removal of a L-DN to another L-DN tunnel, orestablishment of another L-DN to L-DN tunnel.

18. The second apparatus of claim 16, wherein the second charging data requestindicates that quota is requested for an application identifier in a start of service data flow.

19. The second apparatus of any of claims 15 to 18, wherein the second apparatus is caused to:receive, from the first apparatus, a third charging data request with the application identifier for terminating charging associated with the session;close the charging data record for the application; andtransmit, to the first apparatus, a third charging data response to the third charging data request.

20. The second apparatus of any of claims 15 to 19, wherein the first charging data request further comprises information of the application identifier that requires partial / distributed computing in data networks.

21. The second apparatus of any of claims 15 to 20, wherein the first charging data request further comprises at least one of the following parameters:Data Network Name (DNN) identifiers of a Local Data Network (L-DN) and a Central Data Network (C-DN),DNN identifiers of two L-DNs,an application session start time,an application session stop time,diagnostics or enhanced diagnostic information on release of the session,charging characteristics of the session,session stop for indicating termination of the session,a Quality of Service flow Identifier (QFI) / traffic class usage report,a traffic class identifier,an Edge Application Server (EAS) / Local Data Network (L-DN),an identifier of Local UPF (L-UPF),an identifier of a further L-UPF, oran identifier of Central-UPF (C-UPF).

22. The second apparatus of any of claims 15 to 21, wherein the second apparatus is caused to:obtain charging information related to the traffic exchanged with the data networks for the application identifier based on the charging data record for the application; anddetermine a spending limit counter for the application identifier based on the charging information.

23. The second apparatus of claim 22, wherein the second apparatus is caused to:provide the spending limit counter for the application identifier in response to a request of a policy controller.

24. The second apparatus of any of claims 15 to 23, wherein the charging is associated with traffic exchanging with a data network which comprises one or more Local Data Networks (L-DNs) or a Central Data Network (C-DN).

25. The second apparatus of any of claims 15 to 24, wherein the first apparatus implements a Session Management Function (SMF) or a Network Exposure Function (NEF), and the second apparatus implements a Charging Function (CHF).

26. A method comprising:transmitting, to a second apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; andreceiving, from the second apparatus, a first charging data response.

27. A method comprising:receiving, from a first apparatus, a first charging data request comprising anapplication identifier related to an application for a second apparatus to start a charging session related to the application;opening a charging data record for the application; andtransmitting, to the first apparatus, a first charging data response.

28. A first apparatus comprising:means for transmitting, to a second apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application; andmeans for receiving, from the second apparatus, a first charging data response.

29. A second apparatus comprising:means for receiving, from a first apparatus, a first charging data request comprising an application identifier related to an application for the second apparatus to start a charging session related to the application;means for opening a charging data record for the application; andmeans for transmitting, to the first apparatus, a first charging data response.

30. A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of any of claim 26 or 27.

Images