Application programming interface (API) billing based on API object level

Abstract

Embodiments of the present disclosure relate to application programming interface (API) billing based on an API object level. A method performed by an API open function (AEF) in a universal application programming interface (API) framework (CAPIF) is provided. The method includes receiving, from an API caller, a request to invoke a serving API for an API object lifecycle or access operation of an API object. The method includes determining that an API object lifecycle or access operation is associated with at least one API object-related trigger condition of a satisfied charging event. The method includes triggering a CAPIF core function to report charging information for a charging event to a charging function. And the method includes sending a response to the request to the API caller.

Description

Technical Field

[0001] This disclosure relates generally to telecommunications, and more particularly to processes within a generic application programming interface (API) framework for API billing based on API objects. Background Technology

[0002] A telecommunications system can be viewed as a facility that enables a communication session between two or more entities, such as user terminals, base stations, and / or other nodes, by providing carrier waves between various entities involved in the communication path. For example, a telecommunications system can be provided through a communication network and one or more compatible communication devices. The communication session can include, for example, data communications used to carry communications such as voice, video, email, text messages, multimedia, and / or content data. Non-limiting examples of the services provided include two-way or multiplexed calls, data communication or multimedia services, and access to data network systems such as the Internet.

[0003] In a wireless telecommunications system, at least a portion of a communication session between at least two stations occurs over a wireless link. Examples of wireless telecommunications systems include Public Land Mobile Networks (PLMNs), satellite-based communication systems, and various wireless local area networks (WLANs). Some wireless systems can be divided into cells and are therefore often referred to as cellular systems.

[0004] Users can access the telecommunications system through appropriate communication equipment or terminals. The user's communication equipment may be referred to herein as a user equipment (UE) or simply user equipment. The communication equipment is equipped with appropriate signal receiving and transmitting means to enable communication, such as enabling access to the communication network via an access node or enabling direct communication with other user equipment. The communication equipment can access carriers provided by stations (e.g., base stations in a cell) and transmit and / or receive communication on those carriers.

[0005] Telecommunication systems and associated equipment typically operate according to a given standard or specification that defines what the various entities associated with the communication system are allowed to do and how they should operate. Communication protocols and / or parameters used to connect the various entities are also usually defined. An example of a telecommunications system is the Universal Mobile Telecommunications System (UMTS). Other examples of telecommunications systems are Long Term Evolution (LTE) networks, LTE-Advanced networks, and so-called 5G or New Radio (NR) networks. NR is being standardized by the 3rd Generation Partnership Project (3GPP). Summary of the Invention

[0006] The example implementations of this disclosure relate to telecommunications, and more particularly to processes within a generic application programming interface (API) framework for API billing based on API objects. This disclosure includes, but is not limited to, the following example implementations.

[0007] Some example implementations provide an apparatus for implementing API Open Functionality (AEF) in the Universal Application Programming Interface (API) Framework (CAPIF), the apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute instructions such that the apparatus at least: receives from an API caller a request to invoke a service API for an API object lifecycle or access operation; determines that the API object lifecycle or access operation is associated with at least one API object-related triggering condition for a met billing event; triggers CAPIF core functionality to report billing information for the billing event to the billing function; and sends a response to the request to the API caller.

[0008] Some example implementations provide a method executed by the API Exposure Function (AEF) in the Universal Application Programming Interface (API) Framework (CAPIF), which includes: receiving from an API caller a request to invoke a service API for an API object lifecycle or access operation of an API object; determining that the API object lifecycle or access operation is associated with at least one API object-related trigger condition for a met billing event; triggering CAPIF core functionality to report billing information of the billing event to the billing function; and sending a response to the API caller to the request.

[0009] Some example implementations provide an apparatus for implementing the core functionality of the Universal Application Programming Interface (API) Framework (CAPIF), the apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute instructions such that the apparatus at least: receives at least one trigger from the API Open Function (AEF), the at least one trigger indicating that at least one API object-related trigger condition for a billing event is satisfied, the at least one API object-related trigger condition being associated with the API object lifecycle or access operation of an API object to a service API for an API object lifecycle or access operation call; determines billing information for the billing event based on the at least one trigger; reports the billing information to the billing function for a billing process; and receives a response from the billing function indicating the result of the billing process.

[0010] Some example implementations provide a method executed by the core functionality of the Universal Application Programming Interface (API) Framework (CAPIF), which includes: receiving at least one trigger from the API Open Function (AEF), the at least one trigger indicating that at least one API object-related trigger condition for a billing event is satisfied, the at least one API object-related trigger condition being associated with the API object lifecycle or access operation of an API object for a service API invoked for the API object lifecycle or access operation; determining billing information for the billing event based on the at least one trigger; reporting the billing information to the billing function for the billing process; and receiving a response from the billing function indicating the result of the billing process.

[0011] These and other features, aspects, and advantages of this disclosure will become apparent from the following detailed description and the accompanying drawings, which are briefly described below. This disclosure includes any combination of two, three, four, or more features or elements set forth herein, regardless of whether such features or elements are explicitly combined or otherwise referenced in the particular example implementation described herein. This disclosure is intended to be read voluntarily, such that any separable feature or element of this disclosure, in any aspect and example implementation thereof, shall be considered composable unless the context of this disclosure clearly indicates otherwise.

[0012] Therefore, it should be understood that this brief overview is provided only to outline some example implementations in order to provide a basic understanding of some aspects of this disclosure. Consequently, it should be understood that the above example implementations are merely illustrative and should not be construed as reducing the scope or spirit of this disclosure in any way. Other example implementations, aspects, and advantages will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate by way of example the principles of some of the described example implementations. Attached Figure Description

[0013] After providing a general description of an example implementation of this disclosure, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and in the drawings:

[0014] Figure 1 The present disclosure illustrates a telecommunications system comprising one or more Public Land Mobile Networks (PLMNs) coupled to one or more external data networks, implemented according to some examples.

[0015] Figure 2 The deployment of a PLMN is shown based on some examples;

[0016] Figure 3 A more detailed description is given based on some examples. Figure 2 All aspects of the deployment;

[0017] Figure 4A functional model of resource owner-aware northbound API access in the Common Application Programming Interface (API) Framework (CAPIF) is shown, based on some examples.

[0018] Figure 5 This is a signaling diagram of the Instant Event Billing (IEC) process for API objects used in the service API of CAPIF, implemented according to some examples;

[0019] Figure 6 This is a signaling diagram of the post-event billing (PEC) process for API objects used in the service API of CAPIF, implemented based on some examples;

[0020] Figure 7 It is a signaling diagram of the process of an API object with cell reservation for event charging (ECUR) for the service API in CAPIF, implemented according to some examples;

[0021] Figure 8 This is a flowchart illustrating the various steps in a method executed by the API-opened functionality in CAPIF, implemented according to various examples;

[0022] Figure 9 This is a flowchart illustrating the various steps in a method executed by the CAPIF core functionality, implemented according to various examples; and

[0023] Figure 10 The device is shown based on some examples. Detailed Implementation

[0024] Some implementations of this disclosure will now be described more fully below with reference to the accompanying drawings, which illustrate some, but not all, implementations of this disclosure. In fact, various implementations of this disclosure may be embodied in many different forms and should not be construed as limited to those described herein; rather, these example implementations are provided to make this disclosure thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art. The same reference numerals throughout refer to the same elements.

[0025] Unless otherwise specified or the context clearly indicates, references to "first," "second," etc., should not be construed as implying a particular order. A feature described as being above another feature (unless otherwise stated or the context clearly indicates) may be below that feature, and vice versa; and similarly, a feature described as being to the left of another feature may be to the right of that feature, and vice versa. Furthermore, while references may be made herein to quantitative measurements, values, geometric relationships, etc., any one or more of these (if not all) may be absolute or approximate, unless otherwise stated, to account for acceptable variations that may occur, such as those due to engineering tolerances, etc.

[0026] As used herein, unless otherwise stated or the context clearly indicates, "or" in the operand set is "inclusive or" and therefore true if and only if one or more of those operands are true, and "exclusive or" (i.e., false) if all operands are true. Thus, for example, "[A] or [B]" is true if [A] is true, or if [B] is true, or if both [A] and [B] are true. Furthermore, the articles "a" and "an" mean "one or more" unless otherwise specified or the context clearly indicates the singular form. Additionally, it should be understood that, unless otherwise stated, the terms "data," "content," "digital content," and "information," and similar terms, are sometimes used interchangeably. The term "network" can refer to a group of interconnected computers, including clients and servers; and within a network, these computers can be interconnected directly or indirectly in various ways, including via one or more switches, routers, gateways, access points, etc.

[0027] This disclosure discusses systems and architectures, and although specific terminology may be used, they are broadly applicable to a wide range of technologies. For example, while this disclosure may refer to technologies from 3GPP, such as Global System for Mobile Communications (GSM), UMTS, LTE, Advanced LTE, 5G NR, Advanced 5G, and 6G; however, this disclosure is equally relevant to non-3GPP technologies, such as IEEE 802, Bluetooth, and Bluetooth Low Energy. The exemplary implementations of this disclosure described herein also refer to Public Land Mobile Networks (PLMNs) and Mobile Network Operators (MNOs), but the exemplary implementations are similarly applicable to Standalone Non-Public Networks (SNPNs) and the individual entities operating these networks. Furthermore, while some examples and figures focus on Radio Access Networks (RANs) and 3GPP access, the exemplary implementations are applicable to any type of network access. This includes not only 5G or 6G 3GPP access, but also non-3GPP access, such as wired access, untrusted non-3GPP access, and trusted non-3GPP access connected to the 5G or 6G core network using the Wireless Access Gateway Function (W-AGF), Non-3GPP Interoperability Function (N3IWF), or Trusted Non-3GPP Gateway Function (TNGF).

[0028] Furthermore, as used in this application, the term "circuit system" may refer to one or more or all of the following: (a) a purely hardware circuit implementation (such as an implementation in an analog and / or digital circuit system only); (b) a combination of hardware circuitry and software, such as (if applicable): (i) a combination of (multiple) analog and / or digital hardware circuitry with software / firmware, and (ii) any part of (multiple) hardware processors having software (including (multiple) digital signal processors, software, and (multiple) memories that work together to enable a device such as a mobile phone or server to perform various functions); or (c) (multiple) hardware circuitry and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may be absent when operation is not required.

[0029] The above definition of circuit system applies to all uses of the term in this application, including in any claim. As a further example, as used in this application, the term circuit system also covers only the implementation of hardware circuitry or processors (or processors) or a portion thereof and their accompanying software and / or firmware. For example, if applicable to a particular claim element, the term circuit system also covers baseband integrated circuits or processor integrated circuits for mobile devices (such as user equipment), or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0030] Figure 1 A telecommunications system 100 implemented according to various examples of this disclosure is illustrated. A telecommunications system typically includes one or more telecommunications networks. As shown, for example, the system includes one or more PLMNs 102 coupled to one or more other external data networks 104, particularly including a wide area network (WAN) such as the Internet. Each PLMN includes a core network (CN) 106, such as an Evolved Packet Core (EPC) for LTE, a 5G core network (5GC), etc.; and each of the core network and the Internet is coupled to one or more RANs 108 implementing one or more Radio Access Technologies (RATs), air interfaces, etc. As used herein, "network device" means any suitable device on the network side of a telecommunications network. Examples of suitable network devices are described in more detail below.

[0031] Furthermore, the system includes one or more radio units, which may be referred to differently as User Equipment (UE) 110, terminal equipment, terminal device, mobile station, etc. The UE is typically a device configured to communicate with network equipment or other UEs in a telecommunications network. The UE can be a portable computer (e.g., laptop computer, notebook computer, tablet computer), a mobile phone (e.g., cellular phone, smartphone), a wearable computer (e.g., smartwatch), etc. In other examples, the UE can be an Internet of Things (IoT) device, an Industrial IoT (IIoT) device, a vehicle equipped with Vehicle-to-Everything (V2X) communication technology, etc. In some examples, as described by 3GPP, the UE can be a Narrowband IoT (NB-IoT) device, an Enhanced Machine Type Communication (eMTC) device, a Reduced Capability (RedCap) device, an Environmental IoT device, etc.

[0032] In operation, these UEs 110 can be configured to connect to one or more RANs 108 via radio access nodes according to their specific radio access technologies, thereby accessing a specific CN 106 of PLMN 102 or accessing one or more external data networks 104 (e.g., the Internet). External data networks can be configured to provide Internet access, operator services, third-party services, etc. For example, the International Telecommunication Union (ITU) has categorized 5G mobile network services into three classes: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC) or massive Internet of Things (MIoT).

[0033] Examples of radio access technologies include 3GPP radio access technologies such as GSM, UMTS, LTE, Advanced LTE, 5G NR, Advanced 5G, and 6G. Other examples of radio access technologies include IEEE 802 technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.15 (including 802.15.1 (WPAN / Bluetooth), 802.15.4 (Zigbee), and 802.15.6 (WBAN), Bluetooth, Bluetooth Low Energy (BLE), Ultra Wideband (UWB), etc. Generally, radio access technology can refer to any 2G, 3G, 4G, 5G, 6G, or higher generation mobile communication technology and its different versions, as well as any other radio access technologies that can be arranged to cooperate with such mobile communication technologies to provide access to a mobile network operator (MNO) under CN 106.

[0034] In various examples, RAN 108 can be configured as one or more macro cells, micro cells, pico cells, femtocells, etc. RAN typically includes one or more radio access nodes configured to interact with UE 110. In various examples, radio access nodes can be referred to as base stations (BS), access points (APs), base transceiver stations (BTS), node Bs (NBs), evolved NBs (eNBs), macro BSs, NBs (MNBs) or eNBs (MeNBs), home BSs, NBs (HNBs) or eNBs (HeNBs), next-generation NBs (gNBs), enhanced gNBs (en-gNBs), next-generation eNBs (ng-eNBs), etc. RAN may include some type of network control / management entity responsible for controlling the radio access nodes. The network control / management entity and the radio access nodes can be separate or integrated into a single device. The network control / management entity may include processing circuitry configured to perform various management functions, etc. The processing circuitry may be associated with memory, computer-readable storage media, or a database for maintaining the information required for the management functions.

[0035] RAN 108 can be centralized or distributed. In various examples, RAN components can be interconnected via Ethernet, Gigabit Ethernet, Asynchronous Transfer Mode (ATM), fiber optic, dark fiber, passive wavelength division multiplexing (WDM), WDM passive optical network (WDM-PON), optical transport network (OTN), time-sensitive network (TSN), and / or any other data link layer network (which may include radio links). RAN can be connected to CN 106 via one or more gateways, network functions, etc.

[0036] Understandably, PLMN 102 can be deployed in many different ways. In a 4G LTE network, EPC is CN and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) is RAN; and E-UTRAN includes one or more eNBs (radio access nodes) configured to connect UEs to E-UTRAN for access to EPC. Figure 2 Network 200 is shown, such as a 5G network or a 6G network. As shown, 5GC 202 is CN 106, and Next Generation (NG) Radio Access Network (NG-RAN) 204 is RAN 108; and NG-RAN includes one or more gNBs 206 (Radio Access Nodes) configured to connect UE 110 to NG-RAN, thereby accessing 5GC (sometimes called NGC). The term "gNB" in 5G can correspond to eNB in ​​4G LTE.

[0037] Specifically, some 4G LTE and 5G deployments are considered standalone (SA) deployments. Other networks combine 4G LTE and 5G technologies and are referred to as non-standalone (NSA) networks. In some deployments, the E-UTRAN includes one or more ng-eNBs configured to communicate with the 5GC and may also be configured to communicate with one or more gNBs. Similarly, in another deployment, the NG-RAN may include one or more en-gNBs configured to communicate with the EPC and may also be configured to communicate with one or more other eNBs. In various instances, a single UE110, dual-mode, or multi-mode UE can support multiple (two or more) RANs, thus being configured to connect to multiple RANs, such as 4G LTE and 5G networks.

[0038] Figure 3 More specifically, aspects of a deployment 200 for an MNO network, implemented according to several examples, are depicted. As shown, the MNO deployment includes a 5GC 202 and an NG-RAN 204 with one or more gNBs 206 configured to connect the UE 110 to the NG-RAN, thereby accessing the 5GC. The 5GC may include multiple network functions (NFs) partitioned between the control plane and the user plane. Specifically, the 5GC may include, for example, Access and Mobility Management Function (AMF) 302, Session Management Function (SMF) 304, User Plane Function (UPF) 306, Policy Control Function (PCF) 308, Charging Function (CHF) 310, Unified Data Management (UDM) 312, Network Open Function (NEF) 314, and / or Application Function (AF) 316. Other examples of suitable NFs include Unified Data Repository (UDR), Network Repository Function (NRF), Network Slice Selection Function (NSSF), etc. The server hosting the application is also shown, which is referred to as Application Server (AS) 318.

[0039] In the control plane, AMF 302 is configured to provide UE-based authentication, authorization, mobility management, etc. PCF 308 is responsible for policy enforcement and management, controlling Quality of Service (QoS), and subscriber resource allocation. PCF can promote efficient resource utilization, optimize network performance, and deliver a high-quality user experience. CHF 310 provides converged billing capabilities. CHF manages and processes billing information for various services and resources.

[0040] SMF 304 is configured to provide various functions, including Session Management (SM), UE Internet Protocol (IP) address allocation and management, UPF 306 selection and control, policy application and QoS control, lawful interception, termination of the SM portion of NAS messages, Downlink Data Notification (DNN), roaming functions, handling local implementation to apply QoS against Service Level Agreements (SLAs), charging data collection, and charging interface functions. If the UE 110 has multiple sessions, a different SMF can be assigned to each session to manage each session separately, and different functions may be provided per session.

[0041] UDM 312 serves as a centralized repository for user-related subscription and authentication data. UDM manages user authentication, authorization, and profile information, ensuring secure and authorized access to 5GC 202.

[0042] UPF 306 supports a variety of user plane operations and functions, such as packet routing and forwarding, traffic processing (e.g., QoS enforcement), anchor points for intra / inter-RAT mobility (where applicable), packet inspection and policy rule enforcement, lawful interception (UP collection), traffic accounting and reporting, etc. UPF is the interconnection point between the 5GC and at least one external data network (DN) 320 (i.e., the ingress or egress point for the DN), and routes packets to and from the DN. The DN can be configured to provide Internet access, carrier services, third-party services, etc.

[0043] AF 316 can interact with 5GC 202 to enable the deployment of specific services and applications. AF communicates with other NFs to request and manage network resources, thereby ensuring the network adapts to the requirements of different applications and services. NEF 314 allows authorized third-party applications and services to access specific network functions and services in a controlled manner. NEF enables network capabilities to be exposed to external entities, thereby promoting innovation and the development of new services.

[0044] In some deployments (such as network 200), the operation of the gNB 206 or other radio access nodes can be performed at least partially in a central / centralized unit (CU) (such as a server, host, or node) operatively coupled to a distributed unit (DU) (such as a radio head end / node). Node operations can also be distributed among multiple servers, hosts, or nodes. It should also be understood that the division of labor between 5GC 202 (or other CN) operations and gNB (or other radio access node) operations can vary depending on the implementation.

[0045] 5G network architecture can be based on so-called CU-DU partitioning. A gNB-CU (central node) can control one or more gNB-DUs. A gNB-CU can control multiple spatially separated gNB-DUs, each acting at least as a transmit / receive (Tx / Rx) node. However, in some example implementations, a gNB-DU (also referred to as a DU) can include, for example, the Radio Link Control (RLC), Media Access Control (MAC) layer, and Physical (PHY) layer, while a gNB-CU (also referred to as a CU) can include layers above the RLC layer, such as the Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC), and Internet Protocol (IP) layer. Other functional partitioning is also possible. Those skilled in the art are likely familiar with the Open Systems Interconnection (OSI) model and the functions within each layer.

[0046] In some example implementations, the server or CU can generate a virtual network through which the server communicates with radio nodes. Generally, virtual networking can involve the process of combining hardware and software network resources and functions into a single, software-based management entity, the virtual network. Such a virtual network can provide flexible operational allocation between the server and the radio head end / node. In practice, any digital signal processing task can be performed in the CU or DU, and the boundaries of responsibility transferred between the CU and DU can be chosen depending on the implementation.

[0047] In 3GPP, the Common Application Programming Interface (API) Framework (CAPIF) defines a standardized set of interfaces and protocols for Network Functions (NFs) to expose their capabilities to external applications and other NFs. CAPIF defines a common API structure, data format, and communication protocols for cross-NF access to northbound APIs, enabling different applications and NFs to interact with each other regardless of their implementation details. CAPIF provides mechanisms (e.g., publishing service APIs, authorization, logging, and accounting) to support service API operations. CAPIF enables one or more API callers to discover and communicate with service APIs from API providers.

[0048] Figure 4 The functional model 400 of CAPIF is shown. As illustrated, CAPIF can be hosted within a PLMN trust domain 402, including an MNO or a Standalone Non-Public Network (SNPN). An API caller 404 can request access to the NF via the CAPIF API. The API caller can be provided by a third-party application provider with an SLA to the MNO network. The API caller can reside either outside or within the same trust domain as the PLMN.

[0049] Within the PLMN trust domain, CAPIF includes CAPIF Core Functions (CCF) 406 and API Provider Domain 408, and the API Provider Domain includes API Open Functions (AEF) 410, API Release Functions (APF) 412 and API Management Functions (AMF) 414 (together referred to as API Provider Domain Functions).

[0050] CAPIF core function 406 performs login and logout for API callers (404). The CAPIF core function handles authentication, authorization, and service API discovery requests from API callers. It verifies the API caller's identity, checks permissions, and provides the API caller with the information needed to invoke the service API via the API Opening function. API Opening function 410 is the provider of the service API and serves as the entry point for service communication from the service API to the API caller. API Publishing function 412 enables the API provider to publish service API information so that API callers can discover the service API, and API Management function 414 enables the API provider to manage the service API.

[0051] As also shown in the figure, CAPIF includes multiple reference points between the various entities. API callers 404 within the PLMN trust domain 402 interact with the CAPIF core functionality 406 via CAPIF-1 and with the API open functionality 410 via CAPIF-2. API callers from outside the PLMN trust domain interact with the CAPIF core functionality via CAPIF-1e and with the API open functionality via CAPIF-2e. The API open functionality, API publishing functionality 412, and API management functionality 414 of the API provider domain 408 interact with the CAPIF core functionality via the corresponding entities in CAPIF-3, CAPIF-4, and CAPIF-5 (or CAPIF-3e, CAPIF-4e, and CAPIF-5e if the API provider domains are not in the same PLMN trust domain).

[0052] As also shown in the figure, CAPIF may include enhancements to support Resource Owner-Aware Northbound API Access (RNAA), which allows the Resource Owner (RO) to authorize API calls. In other words, RNAA is an API call scenario where the API caller requires authorization from the Resource Owner. As shown in the figure, CAPIF core function 406 may include authorization function 416. Resource Owner (RO) function 418 can interact with the authorization function in the CAPIF core function via CAPIF-8, and the RO can communicate with the authorization function to manage resource owner consent. In the context of RNAA, a resource is an object or component of an API that operates on it. The RO is a UE user or MNO subscriber who can grant access to protected resources associated with the invoked API via the Resource Owner function, and the RO function is the entity that implements the authorization of resource access and manages and revokes the authorization of resource access.

[0053] CAPIF can be implemented in any of a variety of different ways. In some examples, API caller 404 can be implemented by UE 110, AF 316, AS 318, Service Capability Server (SCS), etc. Similarly, in some examples, the CAPIF core function 406 and API provider domain functions (API opening function 410, API publishing function 412, API management function 414) can be implemented by NEF 314, Service Capability Opening Function (SCEF), etc.

[0054] In CAPIF, the API caller 404 can be deployed in several different ways. For example, the API caller can be deployed as an AF on UE110 (e.g., as a third-party application), or as an AF on a UE that supports several other third-party applications deployed on the UE. In another example, the API caller can be deployed as an AF on the network, such as AF 316. The resource owner can be considered to be connected via the UE and can interact with the CAPIF core functionality, which provides authorization functionality 416 for authentication and authorization, using the resource owner functionality 418 deployed on the UE. That is, the CAPIF core functionality can provide authorization functionality to allow granting permission to the API caller to access resources provided by the service API.

[0055] It is foreseeable that APIs will play a crucial role in 6G (and even 5G Advanced). For example, the European flagship 6G initiative Hexa-X has illustrated this scenario by encapsulating access to different domains (e.g., radio, core) via the same NF (which will eventually be open). Network monetization relies on APIs that open network capabilities to external parties; and on billing for usage by external parties (formerly known as offline billing), or on allowing / disallowing their use, for example, based on subscription details from external parties (formerly known as online billing).

[0056] To support network monetization that relies on APIs, API usage must be monitored and logged by the billing system. In existing 5G billing systems, API billing is based on the number of API call requests or notifications. However, because network monetization is largely based on openness, a flexible billing framework that goes beyond simply counting API messages is crucial for supporting rich monetization use cases. The current 5G ecosystem does not allow for such granularity for API billing, and CAPIF400 is not yet suitable for API billing.

[0057] An API includes high-level concepts related to how applications use it, and these high-level concepts are typically represented as objects on which operations are performed. In the context of CAPIF 400, an API object for a service API can be a resource on which one or more service operations can be performed. As explained in more detail below, these API objects include generic API objects and subscription-specific objects, which can be used in API billing to better represent API resource usage than simply counting, notifying, or transacting API requests.

[0058] In light of the foregoing, the example implementation of this disclosure provides a solution where API objects can be represented in billing. In this respect, the example implementation provides a solution for API billing based on API objects, such as generic API objects or subscription objects. For these different object classes, protocol primitives used in the representational state transition API (RESTful API) can be defined so that they can be mapped to billing triggers associated with these high-level concepts. In principle, the example implementation of this disclosure can also be applied to other API protocols, such as CoAP (Cooperative Application Protocol) and gRPC remote procedure calls, as long as these provide similar service operations and the API involves the persistence of API objects.

[0059] According to the example implementation, the service API includes one or more API objects to which one or more service operations can be performed, and the service operations may include one or more API object lifecycle operations (e.g., create, delete) and / or one or more API object access operations (e.g., read, update). API object lifecycle / access operations may be associated with at least one triggering condition for a billing event. When the triggering condition for a billing event is met, CAPIF core function 406 may be triggered to report billing information for the billing event to CHF 310. In some examples, billing information may be reported to CHF via or through the Billing Trigger Function (CTF) or Billing Enable Function (CEF), such as by using a service-based interface (Nchf) exposed by CHF. Figure 4 As shown, in some examples, the CAPIF core functionality can be enhanced to include a billing module 420 for this purpose. And in some example implementations, the API caller 404 can implement an API consumer, while the API open functionality 410 can implement an API producer.

[0060] As described above, API objects can include generic API objects and subscription-specific API objects, which may depend on the service API and be determined when the service API is designed. API objects have a lifecycle, and their creation, reading, updating, and deletion (CRUD) can be triggered by API consumers. API objects can be created by API producers (e.g., API Open Functionality 410) and persistently stored in a container of the API producer, which enables creation operations from API consumers (e.g., API caller 404). These API objects are typically represented as resources in APIs that follow REST principles, such as APIs provided to external consumers by 5GC 202. These resources can be identified using resource prototypes such as documentation, collections, or storage.

[0061] In RESTful APIs, there are two common patterns for API object creation: creation via HTTP POST and creation via HTTP PUT. In the first pattern, the POST request used to create the API object addresses a container resource, and the API producer can generate an identifier for the new object or document resource created within the container. In the second pattern, the API consumer can generate an identifier for the new API object, concatenate the container resource's URI with that identifier, and use a PUT request to address the resulting resource URI. Resources that follow these patterns include collection prototypes (created by POST) and storage prototypes (created by PUT), as well as the actual object referenced by the document prototype. At this point, the API object can be a collection resource, a storage resource, or a document resource.

[0062] In some examples, billing triggers for a generic API object may include API object lifecycle operations such as API object creation (HTTP POST or initial HTTP PUT) and API object deletion (HTTP DELETE), as these operations define the API object's lifecycle. Billing information reported to CHF 310 for billing events related to the generic API may include, for example, object identification information and a time indication of creation or deletion (e.g., a timestamp). In some examples, billing triggers may include API object access operations such as API object reading (via HTTP GET) and API object updating (via HTTP PATCH or HTTP PUT); in the case of creation via HTTP PUT, this begins with a second HTTP PUT request. In some examples, API object lifecycle operations (creation and deletion) may be considered required triggers, while API object access operations (reading and updating) may be optional.

[0063] Another type of API object is the subscription API object, which is also managed through a lifecycle triggered by API consumers, either explicitly using CRUD operations or implicitly as a side effect of managing other general-purpose API objects. The difference between subscription API objects and general-purpose API objects is that they include one or more triggering conditions for one or more (event) notifications that can be generated by the subscription API object. Typically, in a REST API that supports notification emission, each notification is associated with exactly one subscription object.

[0064] Notifications generated by a subscribed API object can be billed, but the number of notifications generated (and the resulting costs) can be unknown, leading to unpredictable cost issues. Therefore, subscription-based billing may be more user-friendly. API producers can define API objects as subscriptions, or more specifically, as subscription API objects. Subscribing to notifications can be the primary purpose of an API object (in which case, the API object can be called an explicitly subscribed API object), or a side effect of creating specific API objects for different purposes (in which case, the API object can be called an implicitly subscribed API object).

[0065] In some examples, multiple notifications may be associated with the subscription API object that generated those notifications. If both notification billing and subscription billing are supported, the billing information used for a notification may include information indicating the subscription API object that generated the notification.

[0066] Figure 5 , Figure 6 and Figure 7This is a signaling diagram of the billing process for API objects of the service API in CAPIF 400, implemented according to various examples. Specifically, Figure 5 This is signaling diagram 500, which is based on some examples of the process for instant event billing (IEC) for API objects. Figure 6 This is signaling diagram 600, based on some example implementations of a post-event billing (PEC) process for API objects. Figure 7 Signaling diagram 700 is a process for event accounting (ECUR) with cell reservation for API objects, implemented according to some examples.

[0067] exist Figure 5 , Figure 6 and Figure 7 In the billing process shown, the API object can be a general API object or a subscription API object. When a service API call request is for an API object creation or deletion operation, a billing event for the API object's lifecycle operations can be triggered. When a service API call request is for an API object read or update operation, a billing event for the API object's access operation can be triggered.

[0068] again, Figure 5 This is a signaling diagram 500 illustrating the process of Instant Event Billing (IEC) for API objects of a service API in CAPIF 400, implemented according to some examples. As shown, API caller 404 may send a service API call request to API opening function 410 in step 501 as a request for API object lifecycle / access operations on the API object of the service API. API opening function may check in step 502 whether the API caller is authorized to call the service API, and perhaps also whether the API caller is authorized to call the service API for API object lifecycle / access operations on the API object.

[0069] API Open Function 410 can determine that an API object lifecycle / access operation is associated with the triggering conditions of a met billing event, and trigger the billing module 420 of CAPIF core function 406 to report the billing information of the billing event to CHF 310 for use in the billing process. As shown in the figure, for example, API Open Function can send a trigger to the billing module corresponding to the request in step 503a, such as via CAPIF-3. In this case, the trigger can be an API object lifecycle trigger for API object lifecycle operations, or an API object access trigger for API object access operations.

[0070] The billing module 420 of CAPIF core function 406 can determine billing information based on the billing information that triggers a billing event; and the billing module can report billing information to CHF 310 via a billing information (data) request in step 503b. Billing information may include, for example, API object identifier, API object type (general API object or subscription API object), API object lifecycle / access operations (e.g., creation, deletion, reading, update), etc. In some examples of billing via API objects, operations on API objects can be omitted from the billing information to CHF.

[0071] CHF 310 can perform the billing process based on billing information used for billing events; and CHF can respond to the billing module 420 of CAPIF core function 406 in step 503c, such as by responding with the billing information. In some examples, the response from CHF may include information indicating the result of the billing process. In some examples, the billing module may notify API open function 410 about the result of the billing process in step 503d.

[0072] API opening function 410 can execute service logic for the invoked service API in step 504 to perform API object lifecycle / access operations on the API object, thereby satisfying the request for the API object lifecycle / access operations. Then, API opening function can return a service API call response to the API caller in step 505 as the result of the service API call.

[0073] Figure 6 This is signaling diagram 600 for the post-event billing (PEC) process of an API object for a service API in CAPIF 400, implemented according to some examples. As shown, API caller 404 may send a service API call request to API opening function 410 in step 601 as a request for API object lifecycle / access operations on the API object of the service API. API opening function may check in step 602 whether the API caller is authorized to call the service API, and perhaps also whether the API caller is authorized to call the service API for API object lifecycle / access operations on the API object.

[0074] API opening function 410 can execute service logic for the invoked service API in step 603 to perform API object lifecycle / access operations on the API object, thereby satisfying the request for the API object lifecycle / access operations. Then, API opening function can return the service API call response to the API caller in step 604 as the result of the service API call.

[0075] Similar to before, API Open Function 410 can determine the association between the API object lifecycle / access operation and the triggering conditions of a met billing event, and trigger the billing module 420 of CAPIF core function 406 to report the billing information of the billing event to CHF 310 for use in the billing process. As shown in the figure, for example, API Open Function can send a trigger corresponding to the request (e.g., API object lifecycle trigger, API object access trigger) to the billing module in step 605a, such as via CAPIF-3.

[0076] The billing module 420 of CAPIF core function 406 can determine billing information based on the billing information that triggers a billing event; and the billing module can report billing information to CHF 310 via a billing information (data) request in step 605b. Billing information may include, for example, API object identifier, API object type (general API object or subscription API object), API object lifecycle / access operations (e.g., creation, deletion, reading, update), etc. In some examples of billing via API objects, operations on API objects can be omitted from the billing information to CHF.

[0077] CHF 310 can perform the billing process based on billing information used for billing events; and CHF can respond to the billing module 420 of CAPIF core function 406 in step 605c, such as by responding with the billing information. In some examples, the response from CHF may include information indicating the result of the billing process. In some examples, the billing module may notify API open function 410 about the result of the billing process in step 605d.

[0078] Figure 7 This is a signaling diagram 700 illustrating a process for an API object with a cell-reserved Event Accounting (ECUR) for a service API in CAPIF 400, implemented according to some examples. As shown, API caller 404 may send a service API call request to API opening function 410 in step 701 as a request for an API object lifecycle / access operation on the API object of the service API. API opening function may check in step 702 whether the API caller is authorized to call the service API, and perhaps also whether the API caller is authorized to call the service API for API object lifecycle / access operations on the API object.

[0079] API Open Function 410 can determine the association between the API object lifecycle / access operation and the triggering conditions of a met billing event, and trigger the billing module 420 of CAPIF core function 406 to report the billing information of the billing event to CHF 310 for use in the billing process. As shown in the figure, for example, API Open Function can send a trigger corresponding to the request (e.g., API object lifecycle trigger, API object access trigger) to the billing module in step 703a, such as via CAPIF-3. During the ECR process, this trigger can indicate the initialization reserved by the unit.

[0080] The billing module 420 of CAPIF core function 406 can determine billing information based on the billing information that triggers a billing event; and the billing module can report billing information to CHF 310 in step 703b via a billing information (data) request (initial). Billing information may include, for example, API object identifier, API object type (general API object or subscription API object), API object lifecycle / access operations (e.g., create, delete, read, update), etc. In some examples of billing via API objects, operations on API objects can be omitted from the billing information to CHF.

[0081] CHF 310 can determine whether service API call processing can continue, such as billing information based on billing events and cost limits for requests to API object lifecycle / access operations; and CHF can respond to the billing module 420 of CAPIF core function 406 in step 703c, such as responding with billing information (initial). In some examples, the response from CHF may include information indicating whether service API processing can continue. In some examples, the billing module may notify API opening function 410 in step 703d about whether service API processing can continue.

[0082] Assuming service API processing can continue, API Open Function 410 can execute the service logic of the invoked service API in step 704 to perform API object lifecycle / access operations on the API object, thereby satisfying the request for the API object lifecycle / access operation. Then, API Open Function can again trigger the billing module 420 of CAPIF core function 406 to report billing information of the billing event to CHF 310 for the billing process. At this point, API Open Function can send a trigger corresponding to the request (e.g., API object lifecycle trigger, API object access trigger) to the billing module in step 705a, such as via CAPIF-3. This trigger can indicate the termination reserved by the unit.

[0083] The billing module 420 of CAPIF core function 406 can report billing information to CHF310 in step 705b via a billing information (data) request (termination). Similar to before, the billing information may include, for example, API object identifier, API object type (general API object or subscription API object), operations on the API object (e.g., creation, deletion, reading, updating), etc.

[0084] CHF 310 can disable cell reservations and perform the billing process based on cell reservations and billing information for billing events; and CHF can respond to the billing module 420 of CAPIF core function 406 in step 705c, such as responding with billing information. In some examples, the response from CHF may include information indicating the result of the billing process. In some examples, the billing module can notify API opening function 410 of the result of the billing process in step 705d. API opening function can then return a service API call response to the API caller in step 706 as the result of the service API call.

[0085] To further illustrate some aspects of the example implementations, the following is a trigger table based on some examples for billing events associated with API object lifecycle / access operations on API objects, including generic API objects and subscription API objects.

[0086] The following is a trigger table based on some examples, which targets CHF Call Data Record (CDR) billing information related to API object lifecycle / access operations on API objects, including general API objects and subscription API objects.

[0087] In some examples, the structure of the billing CDR billing information can be enhanced to provide further details of billing by taking into account the specific information of the API object.

[0088] Figure 8This is a flowchart illustrating various steps in method 800 performed by the API Open Function (AEF) in the Common Application Programming Interface (API) Framework (CAPIF), implemented according to various examples. The method includes receiving a request from an API caller to invoke a service API for an API object's lifecycle or access operation, as shown in box 802. The method includes determining that the API object's lifecycle or access operation is associated with at least one API object-related triggering condition for a met billing event, as shown in box 804. The method includes triggering CAPIF core functionality to report billing information for the billing event to the billing function, as shown in box 806. And the method includes sending a response to the request to the API caller, as shown in box 808.

[0089] In some examples, the service API is one of at least one service API provided by AEF and available for invocation.

[0090] In some examples, API objects are created by the API producer and persistently stored in the API producer's container.

[0091] In some examples, the API object is a subscription resource for a service API, which includes one or more triggering conditions for one or more notifications generated by the subscription resource.

[0092] In some examples, the request targets an API object lifecycle operation, which is either an API object creation operation or an API object deletion operation.

[0093] In some examples, the request is for an API object access operation, which is either an API object read operation or an API object update operation.

[0094] In some examples, method 800 also includes collecting API consumption information related to API object access operations on the API object. In some of these examples, the CAPIF core functionality is triggered at box 806 to report billing information that includes API consumption information.

[0095] In some examples, at least one API object-related triggering condition includes a request for an API object lifecycle or access operation, and the CAPIF core functionality is triggered at box 806 to report billing information when the request is received.

[0096] In some examples, at least one API object-related trigger condition includes a response to a request for an API object lifecycle or access operation, and triggers the CAPIF core functionality at box 806 to report billing information when the response is sent.

[0097] In some examples, at least one API object-related trigger condition includes a request for an API object lifecycle or access operation, and a response to the request for the API object lifecycle or access operation. In some of these examples, triggering the CAPIF core function at box 806 includes: when a request is received, triggering the CAPIF core function to report initial billing information indicating the cell reservation for a billing event. Triggering the CAPIF core function also includes, when a response is sent, triggering the CAPIF core function to report billing information indicating the termination of the cell reservation.

[0098] Figure 9 This is a flowchart illustrating the steps of method 900 performed by the core functionality of the Common Application Programming Interface (API) Framework (CAPIF) according to various examples. The method includes receiving at least one trigger from an API Open Function (AEF) indicating that at least one API object-related trigger condition for a billing event is satisfied, the at least one API object-related trigger condition being associated with an API object lifecycle or access operation of an API object to a service API, as shown in box 902. The method includes determining billing information for the billing event based on the at least one trigger, as shown in box 904. The method includes reporting the billing information to a billing function used for the billing process, as shown in box 906. And the method includes receiving a response from the billing function indicating the result of the billing process, as shown in box 908.

[0099] In some examples, at box 906, billing information is reported to the billing function via or through the billing trigger function or the billing enable function.

[0100] In some examples, method 900 also includes sending a notification to the AEF indicating the result of the billing process.

[0101] In some examples, API objects are created by the API producer and persistently stored in the API producer's container.

[0102] In some examples, the API object is a subscription resource for a service API, which includes one or more triggering conditions for one or more notifications generated by the subscription resource.

[0103] In some examples, the service API is invoked by AEF from the API caller by a service API call request for operations on the lifecycle of the API object or access to the API object, and AEF sends a response to the API caller to that request.

[0104] In some examples, the request targets an API object lifecycle operation, which is either an API object creation operation or an API object deletion operation.

[0105] In some examples, the request is for an API object access operation, which is either an API object read operation or an API object update operation.

[0106] In some examples, at least one API object-related trigger condition includes a request for an API object lifecycle or access operation. In some of these examples, when a request is received by the AEF from the API caller, at least one trigger is received at box 902, and billing information is determined at box 904 and reported at box 906.

[0107] In some examples, at least one API object-related trigger condition includes a response to a request for an API object lifecycle or access operation. In some of these examples, when the response is sent by AEF to the API caller, at least one trigger is received at box 902, and billing information is determined at box 904 and reported at box 906.

[0108] In some examples, at least one API object-related trigger condition includes a request for an API object lifecycle or access operation, and a response to the request for the API object lifecycle or access operation. In some of these examples, at boxes 902, 904, and 906 respectively, receiving at least one trigger, determining, and reporting billing information includes: receiving a first trigger when a request is received by the AEF from the API caller, and determining and reporting initial billing information indicating unit reservation for the billing event. And receiving at least one trigger, determining, and reporting billing information includes: receiving a second trigger, and determining and reporting billing information indicating unit reservation termination when the response is sent by the AEF to the API caller.

[0109] According to the example implementations of this disclosure, the telecommunications system 100 or PLMN 102 and its components, such as UE 110, CN 106, RAN 108, 5GC 202, NG-RAN 204, gNB 206, AMF 302, SMF 304, UPF 306, UDM 308, UDR 310, NEF 312, AF 314, AS 316, API caller 404, CAPIF core function 406, API opening function 410, resource owner function 418, and / or billing module 420, can be implemented in various ways. Components used to implement the system and its components may include hardware, firmware, software, or combinations thereof. In some examples, one or more devices may be configured to function as or otherwise implement the system and its components shown and described herein. In examples involving more than one device, the devices may be connected or communicate with each other in a variety of different ways, such as directly or indirectly via wired or wireless networks.

[0110] Based on some example implementations, regarding Figure 8 At least some of the methods in the described method 800 can be performed by a device including components for performing functions corresponding to the steps of the method. Similarly, regarding Figure 9 At least some of the methods in the described method 900 can be performed by means of a device that includes components for performing functions corresponding to the steps of the method. Examples of suitable means may include CAPIF core functionality, API open functionality, NF (e.g., UDM, UDR, NEF, AF, AS, SCS, SCEF, CHF) or any suitable means such as a server, host, or node.

[0111] Figure 10 An apparatus 1000 implemented according to some examples of the present disclosure is shown, wherein components for performing various functions include hardware, which is independent or directed by one or more computer programs from a computer-readable storage medium or other memory (such as computer memory). The apparatus may include one or more of each of a plurality of components, such as, for example, a processing circuitry system 1002 connected to a computer-readable storage medium or other memory 1004.

[0112] The processing circuit system 1002 may consist of one or more processors individually, or in combination with one or more computer-readable storage media. The processing circuit system is typically any portion of computer hardware capable of processing information, such as, for example, data, computer programs, and / or other suitable electronic information. The processing circuit system comprises a collection of electronic circuits, some of which may be packaged as integrated circuits or multiple interconnected integrated circuits (integrated circuits are sometimes more commonly referred to as “chips”). The processing circuit system may be configured to execute computer programs, which may be stored on the processing circuit system or otherwise stored in memory 1004 (on the same device or another device).

[0113] The processing circuitry system 1002 can be multiple processors, a multi-core processor, or some other type of processor, depending on the specific implementation. Furthermore, the processing circuitry system can be implemented using multiple heterogeneous processor systems, where a main processor and one or more auxiliary processors reside on a single chip. As another illustrative example, the processing circuitry system can be a symmetric multiprocessor system containing multiple processors of the same type. In yet another example, the processing circuitry system can be embodied as or otherwise include one or more ASICs, FPGAs, etc. Therefore, although the processing circuitry system can be able to execute a computer program to perform one or more functions, various example processing circuitry systems can be able to perform one or more functions without the assistance of a computer program. In any instance, the processing circuitry system can be appropriately programmed to perform functions or operations according to the example implementations of this disclosure.

[0114] Memory 1004 is typically any computer hardware component capable of temporarily and / or permanently storing information such as, for example, data, computer programs, instructions 1006 (e.g., computer-readable program code), and / or other suitable information. The memory may include volatile and / or non-volatile memory and may be fixed or removable. Examples of suitable memory include recording media, random access memory (RAM), read-only memory (ROM), hard disk drives, flash memory, thumb drives, removable computer floppy disks, optical disks, or combinations thereof.

[0115] Memory 1004 is a non-transient device capable of storing information. An example of a suitable memory is a computer-readable storage medium, distinguishable from a computer-readable transmission medium capable of carrying information from one location to another. Examples of suitable computer-readable transmission media include electronic carrier signals, telecommunication signals, or combinations thereof. As used herein, the term "non-transient" is a limitation on the medium itself (i.e., tangible, not a signal), not a limitation on the persistence of data storage (e.g., RAM versus ROM). The term "computer-readable medium" as used herein generally refers to a computer-readable storage medium or a computer-readable transmission medium. A computer-readable medium is any entity or device capable of storing and carrying information such as one or more computer programs or portions thereof.

[0116] In addition to memory 1004 (e.g., a computer-readable storage medium), processing circuitry 1002 may be connected to one or more interfaces for displaying, sending, and / or receiving information. These interfaces may include communication interface 1008 and / or one or more user interfaces (e.g., a display, a user input interface). The communication interface may be configured to send information to and / or receive information from other devices, networks, etc. The communication interface may be configured to send and / or receive information via physical (wired) and / or wireless communication links. Examples of suitable communication interfaces include network interface controllers (NICs), wireless NICs (WNICs), etc.

[0117] Processing circuitry system 1002 executes instructions 1006 or stores instructions in memory 1004, supporting combinations of operations for implementing example implementations of this disclosure. In this way, apparatus 1000 may include at least one processing circuitry system and at least one memory coupled to the at least one processing circuitry system, wherein the at least one processing circuitry system is configured to execute instructions stored in the at least one memory. It will also be understood that one or more functions and combinations of functions may be implemented by a dedicated hardware-based computer system and / or processing circuitry system performing the specified function, or a combination of dedicated hardware and program code instructions.

[0118] Some example implementations of this disclosure can also be executed as a computer process defined by one or more computer programs or portions thereof. Example implementations of this disclosure can be executed by executing at least a portion of a computer program including instructions. The computer program can be in source code form, object code form, or some intermediate form. The computer program can be stored in a computer-readable medium readable by a computer, processing circuit system, or other suitable device. As indicated above, for example, the computer program can be stored in memory, such as a computer-readable storage medium. Additionally or alternatively, for example, the computer program can be stored in a computer-readable transmission medium. The coding of software used to perform example implementations of this disclosure is entirely within the scope of those skilled in the art.

[0119] It will be understood that any suitable instructions can be loaded from memory or a computer-readable medium (e.g., a computer-readable storage medium, a computer-readable transmission medium) onto a computer, processing circuitry system, or other programmable means to produce a particular machine such that the particular machine becomes a component for implementing the functions described herein. Instructions can also be stored in a computer-readable medium that can direct a computer, processing circuitry system, or other programmable means to operate in a particular manner to produce a particular machine or a particular article of manufacture. In some examples, instructions stored in a computer-readable medium can produce an article of manufacture in which the article of manufacture becomes a component for implementing the functions described herein. Instructions can be retrieved from a computer-readable medium and loaded onto a computer, processing circuitry system, or other programmable means to configure the computer, processing circuitry system, or other programmable means to perform operations to be performed on, by, or through the computer, processing circuitry system, or other programmable means.

[0120] The fetching, loading, and execution of instructions, including program code instructions, can be performed sequentially, such that one instruction is fetched, loaded, and executed at a time. In some example implementations, fetching, loading, and / or execution can be performed in parallel, such that multiple instructions are fetched, loaded, and / or executed together. The execution of program code instructions can produce computer-implemented processes such that instructions executed by a computer, processing circuitry system, or other programmable device provide operations for implementing the functions described herein.

[0121] As explained above and reiterated below, this disclosure includes, but is not limited to, the following example implementations.

[0122] Clause 1. A method performed by the API Open Function (AEF) in the Universal Application Programming Interface (API) Framework (CAPIF), the method comprising: receiving from an API caller a request to invoke a service API for an API object lifecycle or access operation of an API object; determining that the API object lifecycle or access operation is associated with at least one API object-related trigger condition of a met billing event; triggering CAPIF core functionality to report billing information of the billing event to the billing function; and sending a response to the API caller to the request.

[0123] Clause 2. The method described in Clause 1, wherein the service API is one of at least one service API provided by AEF and available for invocation.

[0124] Clause 3. The method described in Clause 1 or Clause 2, wherein the API object is created by the API producer and persistently stored in the API producer's container.

[0125] Clause 4. The method according to any one of Clauses 1 to 3, wherein the API object is a subscription resource of the service API, and the subscription resource includes one or more triggering conditions for one or more notifications generated by the subscription resource.

[0126] Clause 5. The method according to any one of Clauses 1 to 4, wherein the request is directed to an API object lifecycle operation, and the API object lifecycle operation is an API object creation operation or an API object deletion operation.

[0127] Clause 6. The method according to any one of Clauses 1 to 5, wherein the request is directed to an API object access operation, and the API object access operation is an API object read operation or an API object update operation.

[0128] Clause 7. The method according to Clause 6, wherein the method further includes collecting API consumption information related to API object access operations on API objects, and wherein the CAPIF core function is triggered to report billing information including API consumption information.

[0129] Clause 8. The method according to any one of Clauses 1 to 7, wherein at least one API object-related triggering condition includes a request for the API object's lifecycle or access operation, and upon receiving the request, the CAPIF core functionality is triggered to report billing information.

[0130] Clause 9. The method according to any one of Clauses 1 to 8, wherein at least one triggering condition related to the API object includes a response to a request for an API object lifecycle or access operation, and triggers the CAPIF core functionality to report billing information when the response is sent.

[0131] Clause 10. The method according to any one of Clauses 1 to 9, wherein at least one API object-related triggering condition includes a request for an API object lifecycle or access operation, and a response to the request for an API object lifecycle or access operation, and triggering the CAPIF core function includes: when the request is received, the CAPIF core function is triggered to report initial billing information indicating the unit reserved for the billing event; and when the response is sent, the CAPIF core function is triggered to report billing information indicating the unit reserved for termination.

[0132] Clause 11. An apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute the instructions to cause the apparatus to perform the method of any one of Clauses 1 to 10.

[0133] Clause 12. An apparatus comprising components for performing the method as described in any one of Clauses 1 to 10.

[0134] Clause 13. A computer-readable medium comprising instructions that, in response to execution by at least one processing circuitry system, cause a device to perform the method described in any one of Clauses 1 to 10.

[0135] Clause 14. A computer-readable storage medium comprising instructions that, in response to execution by at least one processing circuitry system, cause a device to perform any one of Clauses 1 to 10.

[0136] Clause 15. A computer program comprising instructions that, in response to execution by at least one processing circuitry system, cause a device to perform the method described in any one of Clauses 1 to 10.

[0137] Clause 16. A method performed by the core functionality of a Universal Application Programming Interface (API) Framework (CAPIF), the method comprising: receiving at least one trigger from an API Open Function (AEF), the at least one trigger indicating that at least one API object-related trigger condition for a billing event is satisfied, the at least one API object-related trigger condition being associated with an API object lifecycle or access operation of an API object for a service API invoked for an API object lifecycle or access operation; determining billing information for the billing event based on the at least one trigger; reporting the billing information to a billing function for a billing process; and receiving a response from the billing function indicating the result of the billing process.

[0138] Clause 17. The method described in Clause 16, wherein billing information is reported to the billing function via or through a billing trigger function or a billing enable function.

[0139] Clause 18. The method of Clause 16 or Clause 17, wherein the method further comprises sending a notification to the AEF indicating the result of the billing process.

[0140] Clause 19. The method according to any one of Clauses 16 to 18, wherein the API object is created by the API producer and persistently stored in the API producer's container.

[0141] Clause 20. The method according to any one of Clauses 16 to 19, wherein the API object is a subscription resource of the service API, and the subscription resource includes one or more triggering conditions for one or more notifications generated by the subscription resource.

[0142] Clause 21. The method according to any one of Clauses 16 to 20, wherein the service API is invoked by a service API call request received by AEF from the API caller for an API object lifecycle or access operation of the API object, and the response to the request is sent by AEF to the API caller.

[0143] Clause 22. The method described in accordance with Clause 21, wherein the request is directed to an API object lifecycle operation, and the API object lifecycle operation is an API object creation operation or an API object deletion operation.

[0144] Clause 23. The method described in accordance with Clause 21 or Clause 22, wherein the request is directed to an API object access operation, and the API object access operation is an API object read operation or an API object update operation.

[0145] Clause 24. The method according to any one of Clauses 21 to 23, wherein at least one API object-related triggering condition includes a request for an API object lifecycle or access operation, and wherein at least one trigger is received when the request is received by the AEF from the API caller, and billing information is determined and reported.

[0146] Clause 25. The method according to any one of Clauses 21 to 24, wherein at least one API object-related triggering condition includes a response to a request for an API object lifecycle or access operation, and wherein at least one trigger is received when the response is sent by the AEF to the API caller, and billing information is determined and reported.

[0147] Clause 26. The method according to any one of Clauses 21 to 25, wherein at least one API object-related triggering condition includes a request for an API object lifecycle or access operation, and a response to a request for an API object lifecycle or access operation, and receiving at least one trigger, determining and reporting billing information includes: receiving a first trigger when a request is received by the AEF from the API caller, and determining and reporting billing information indicating initialization of unit reservation for a billing event; and receiving a second trigger when a response is sent by the AEF to the API caller, and determining and reporting billing information indicating termination of unit reservation.

[0148] Clause 27. An apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute the instructions to cause the apparatus to perform a method as described in any one of Clauses 16 to 26.

[0149] Clause 28. An apparatus comprising components for performing the method as described in any one of Clauses 16 to 26.

[0150] Clause 29. A computer-readable medium comprising instructions that, in response to execution by at least one processing circuitry system, cause a device to perform any one of Clauses 16 to 26.

[0151] Clause 30. A computer-readable storage medium comprising instructions that, in response to execution by at least one processing circuitry system, cause a device to perform any one of Clauses 16 to 26.

[0152] Clause 31. A computer program comprising instructions that, in response to execution by at least one processing circuitry system, cause a device to perform any one of Clauses 16 to 26.

[0153] Benefiting from the teachings presented in the foregoing description and associated drawings, those skilled in the art to which this disclosure pertains will conceive of numerous modifications and other implementations of the set of disclosures set forth herein. Therefore, it should be understood that this disclosure is not limited to the specific implementations disclosed, and that modifications and other implementations are intended to be included within the scope of the appended claims. Furthermore, while the foregoing description and associated drawings describe exemplary implementations in the context of certain exemplary combinations of elements and / or functions, it should be understood that different combinations of elements and / or functions can be provided by alternative implementations without departing from the scope of the appended claims. In this regard, for example, non-combinations of elements and / or functions are also contemplated in some of the appended claims compared to those explicitly described above. Although specific terms are used herein, they are used only in a general and descriptive sense and not for limiting purposes.

Claims

1. An apparatus for implementing API Exposure Functionality (AEF) in the Universal Application Programming Interface (CAPIF) framework, the apparatus comprising: At least one memory, the at least one memory being configured to store instructions; as well as At least one processing circuitry system is configured to access the at least one memory and execute the instructions such that the device at least: Receive requests from the API caller to invoke service APIs that perform lifecycle or access operations on API objects. Determine that the lifecycle of the API object or the access operation is associated with at least one API object-related triggering condition of a billing event that is met; Trigger the CAPIF core functionality to report the billing information of the billing event to the billing function; as well as Send a response to the request to the API caller.

2. The apparatus of claim 1, wherein the service API is one of at least one service API provided by the AEF and available for invocation.

3. The apparatus of claim 1, wherein the API object is created by the API producer and persistently stored in the API producer's container.

4. The apparatus of claim 1, wherein the API object is a subscription resource of the service API, the subscription resource including one or more triggering conditions for one or more notifications generated by the subscription resource.

5. The apparatus of claim 1, wherein the request is directed to an API object lifecycle operation, and the API object lifecycle operation is an API object creation operation or an API object deletion operation.

6. The apparatus of claim 1, wherein the request is directed to an API object access operation, and the API object access operation is an API object read operation or an API object update operation.

7. The apparatus of claim 6, wherein the at least one processing circuitry is configured to execute the instructions to cause the apparatus to further collect API consumption information related to the API object access operation to the API object, and The CAPIF core function is triggered to report the billing information, which includes the API consumption information.

8. The apparatus of claim 1, wherein the at least one API object-related triggering condition includes the request for the API object's lifecycle or access operation, and when the request is received, the CAPIF core function is triggered to report the billing information.

9. The apparatus of claim 1, wherein the at least one API object-related triggering condition includes the response to the request for the API object's lifecycle or access operation, and when the response is sent, the CAPIF core function is triggered to report the billing information.

10. The apparatus of claim 1, wherein the at least one API object-related triggering condition includes the request for the API object's lifecycle or access operation, and the response to the request for the API object's lifecycle or access operation, and the apparatus is configured to trigger the CAPIF core function by: The device is configured to: When the request is received, the CAPIF core function is triggered to report the initial billing information reserved by the unit that indicates the billing event; as well as When the response is sent, the CAPIF core function is triggered to report billing information indicating the termination of the unit's reserved space.

11. An apparatus for implementing the core functionality of the CAPIF (Capability-Based Application Programming Interface) framework, the apparatus comprising: At least one memory, the at least one memory being configured to store instructions; as well as At least one processing circuitry system is configured to access the at least one memory and execute the instructions such that the device at least: Receive at least one trigger from the API Open Function (AEF), the at least one trigger indicating that at least one API object-related trigger condition of the billing event is met, the at least one API object-related trigger condition being associated with the API object lifecycle or access operation of the API object for the service API that is invoked for the API object lifecycle or access operation. Billing information for the billing event is determined based on the at least one trigger; During the billing process, the billing information is reported to the billing function. as well as Receive a response from the billing function indicating the result of the billing process.

12. The apparatus of claim 11, wherein the billing information is reported to the billing function via or through a billing trigger function or a billing enable function.

13. The apparatus of claim 11, wherein the at least one processing circuitry is configured to execute the instructions such that the apparatus further sends a notification to the AEF indicating the result of the billing process.

14. The apparatus of claim 11, wherein the API object is created by the API producer and persistently stored in the API producer's container.

15. The apparatus of claim 11, wherein the API object is a subscription resource of the service API, the subscription resource including one or more triggering conditions for one or more notifications generated by the subscription resource.

16. The apparatus of claim 11, wherein the service API is invoked by a service API invocation request received by the AEF from the API caller for the API object's lifecycle or access operation, and a response to the request is sent by the AEF to the API caller.

17. The apparatus of claim 16, wherein the request is directed to an API object lifecycle operation, and the API object lifecycle operation is an API object creation operation or an API object deletion operation.

18. The apparatus of claim 16, wherein the request is directed to an API object access operation, and the API object access operation is an API object read operation or an API object update operation.

19. The apparatus of claim 16, wherein the at least one API object-related triggering condition includes the request for a lifecycle or access operation of the API object, and When the request is received by the AEF from the API caller, at least one trigger is received, and the billing information is determined and reported.

20. The apparatus of claim 16, wherein the at least one API object-related triggering condition includes the response to the request for the API object's lifecycle or access operation, and When the response is sent by the AEF to the API caller, at least one trigger is received, and the billing information is determined and reported.

21. The apparatus of claim 16, wherein the at least one API object-related trigger condition includes the request for the API object's lifecycle or access operation, and the response to the request for the API object's lifecycle or access operation, and causes the apparatus to receive the at least one trigger, determine and report the billing information including: The device is such that: When the request is received by the AEF from the API caller, a first trigger is received, and the initial billing information indicating the unit reserved for the billing event is determined and reported; as well as When the response is sent by the AEF to the API caller, a second trigger is received, and billing information indicating the termination reserved by the unit is determined and reported.

Images