WO2023156026A1 - Activation des journaux d'api de service dans un système de communication sans fil - Google Patents

Activation des journaux d'api de service dans un système de communication sans fil Download PDF

Info

Publication number
WO2023156026A1
WO2023156026A1 PCT/EP2022/057714 EP2022057714W WO2023156026A1 WO 2023156026 A1 WO2023156026 A1 WO 2023156026A1 EP 2022057714 W EP2022057714 W EP 2022057714W WO 2023156026 A1 WO2023156026 A1 WO 2023156026A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
service
logs
request
apis
Prior art date
Application number
PCT/EP2022/057714
Other languages
English (en)
Inventor
Emmanouil Pateromichelakis
Dimitrios Karampatsis
Original Assignee
Lenovo (Singapore) Pte. Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lenovo (Singapore) Pte. Ltd filed Critical Lenovo (Singapore) Pte. Ltd
Publication of WO2023156026A1 publication Critical patent/WO2023156026A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/06—Generation of reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences

Definitions

  • the subject matter disclosed herein relates generally to the field of enabling service API logs in a wireless communications system.
  • This document defines a network node in a wireless communications system, and a method in a network node in a wireless communications system.
  • API application programming interface
  • Wireless communications networks such as those defined by the 3 rd Generation Partnership Project (3GPP) use many APIs for providing services between nodes and functions within the communications network. Further, some APIs are exposed to third- party applications to allow such third-party applications to consume services provided by a node or function within the communications network. In such an instance the third- party application may be a service consumer.
  • APIs are offered by the Mobile Network Operator (MNO) and Edge Cloud Service Provider (ECSP), for example.
  • the APIs may comprise Network Exposure Function (NEF) APIs, Network Data Analytics Function (NWDAF) APIs, Mobile Edge Computing (MEC) APIs, Service Enabler Application Layer (SEAL) APIs, and Radio Access Network Intelligent Controller (RIC) APIs, for example. Some of these APIs may report similar parameters or affect the same resources. APIs relating to a service may be referred to as Service APIs.
  • a problem with having a plurality of APIs reporting similar parameters or affect the same resources is that a decision is required to determine which API to use for a particular situation.
  • Disclosed herein are procedures for enabling service API logs in a wireless communications system. Said procedures may be implemented by network node in the wireless communications system. The disclosed procedures may facilitate the use of predictive analytics for enabling a consumer, such as an Application Server or a client, to decide which API to invoke for consuming a service.
  • a network node in a wireless communications system for collecting and providing service API logs to a consumer of a service API, the service API for a service produced by one or more service producers in the wireless communications system, the network node comprising a transceiver and a processor.
  • the transceiver is arranged to receive a request for obtaining service API invocation logs for one or more invokers within a service area, the request comprising a requirement for required service API information.
  • the processor is arranged to: determine from the request a set of service API logs to be collected for one or more service APIs within the service area; obtain the set of service API logs; process the service API logs based on the requirement for service API information, the type of the consumer, the service API type, or a combination thereof.
  • the transceiver is further arranged to transmit the processed service API logs based on the request.
  • the method is for collecting and providing service API logs to a consumer of a service API, the service API for a service produced by a service producer in the wireless communications system.
  • the method comprises receiving 410 a request for obtaining service API invocation logs for one or more invokers within a service area, the request comprising a requirement for service API information.
  • the method further comprises determining 420 from the request a set of service API logs to be collected for one or more service APIs within the service area, and obtaining 430 the set of service API logs.
  • the method further comprises processing 440 the service API logs based on the requirement for service API information, the type of the consumer, the service API type, or a combination thereof, and transmitting 450 the processed service API logs based on the request.
  • Figure 1 illustrates the architecture for enabling edge applications in accordance with 3GPP TS 23.558 v 17.2.0;
  • Figure 2 depicts a user equipment apparatus that may be used for implementing the methods described herein;
  • Figure 3 depicts further details of the network node that may be used for implementing the methods described herein;
  • Figure 4 illustrates a method in a network node in a wireless communications system
  • FIG. 5 illustrates a system for implementing a solution presented herein
  • Figure 6 is a signaling diagram illustrating a method for processing service API logs at an AD AES or SEAL;
  • Figure 7 illustrates a system 700 for implementing another solution presented herein.
  • Figure 8 illustrates a method of operation of the system.
  • aspects of this disclosure may be embodied as a system, apparatus, method, or program product. Accordingly, arrangements described herein may be implemented in an entirely hardware form, an entirely software form (including firmware, resident software, micro-code, etc.) or a form combining software and hardware aspects.
  • the disclosed methods and apparatus may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
  • VLSI very-large-scale integration
  • the disclosed methods and apparatus may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.
  • the disclosed methods and apparatus may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.
  • methods and apparatus may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/ or program code, referred hereafter as code.
  • the storage devices may be tangible, non-transitory, and/ or non-transmission.
  • the storage devices may not embody signals. In certain arrangements, the storage devices only employ signals for accessing code.
  • the computer readable medium may be a computer readable storage medium.
  • the computer readable storage medium may be a storage device storing the code.
  • the storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
  • a storage device More specific examples (a non-exhaustive list) of the storage device would include the following: 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), a portable compact disc read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
  • a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.
  • references throughout this specification to an example of a particular method or apparatus, or similar language means that a particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the method and apparatus described herein.
  • reference to features of an example of a particular method or apparatus, or similar language may, but do not necessarily, all refer to the same example, but mean “one or more but not all examples” unless expressly specified otherwise.
  • the terms “including,” “comprising,” “having,” and variations thereof mean “including but not limited to,” unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise.
  • the terms “a,” “an,” and “the” also refer to “one or more” unless expressly specified otherwise.
  • a list with a conjunction of “and/ or” includes any single item in the list or a combination of items in the list.
  • a list of A, B and/ or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.
  • a list using the terminology “one or more of’ includes any single item in the list or a combination of items in the list.
  • one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.
  • a list using the terminology “one of’ includes one and only one of any single item in the list.
  • “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C.
  • a member selected from the group consisting of A, B, and C includes one and only one of A, B, or C, and excludes combinations of A, B, and C.”
  • “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.
  • the code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/ act specified in the schematic flowchart diagrams and/or schematic block diagrams.
  • the code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions /acts specified in the schematic flowchart diagrams and/ or schematic block diagram.
  • each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s).
  • the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.
  • APIs may be used in a 3GPP wireless communications network to provide control, application enablement and management services.
  • APIs are offered by the Mobile Network Operator (MNO) and Edge Cloud Service Provider (ECSP), for example.
  • the APIs may comprise Network Exposure Function (NEF) APIs, Network Data Analytics Function (NWDAF) APIs, Mobile Edge Computing (MEC) APIs, Service Enabler Application Layer (SEAL) APIs, and Radio Access Network Intelligent Controller (RIC) APIs, for example.
  • NEF Network Exposure Function
  • NWDAAF Network Data Analytics Function
  • MEC Mobile Edge Computing
  • SEAL Service Enabler Application Layer
  • RIC Radio Access Network Intelligent Controller
  • data analytics services are provided by the NWDAF (TS 23.288 vl7.3.0) and aim to support network data analytics services in 5G Core network.
  • NWDAF Network Functions
  • AF Application Function
  • OAM Operation Administration and Management
  • UE user equipment
  • QoS Quality of Service
  • DN Data Network
  • 5GS 5G System
  • the statistics /predictions may be supported and/or enhanced by collecting data from different domains based on the consumer needs.
  • Such collection can be from the 5GS via northbound APIs (NWDAF, Management Data Analytics Service (MDAS)), an application specific layer, a DN (e.g., data may be related to collecting HD maps, camera feeds, sensor data, data related to edge/cloud resources, data related to application server status (e.g., load of EAS/AS), or data from the UE side (e.g.
  • NWDAF Management Data Analytics Service
  • MDAS Management Data Analytics Service
  • a DN e.g., data may be related to collecting HD maps, camera feeds, sensor data, data related to edge/cloud resources, data related to application server status (e.g., load of EAS/AS), or data from the UE side (e.g.
  • the application data collection may be provided by different sources (e.g. vertical-specific server, application of the UE, EAS, 3 rd party server, SEAL).
  • sources e.g. vertical-specific server, application of the UE, EAS, 3 rd party server, SEAL.
  • SEAL 3 rd party server
  • An application service provider needs to be aware of the API status of the service APIs provided by the underlying communications systems which can be potentially consumed for the application service. For example, in one case multiple Public Land Mobile Networks (PLMNs) may offer similar services and as such the ASP would choose from which Mobile Network Operator (MNO) APIs should be invoked for consuming services.
  • the service refers to a control, management or application enablement service
  • the application service is for example the V2X, loT, eMBB application which is provided by the application service provider (ASP) and uses the wireless communication system to provide communication between two or more applications.
  • Service APIs provide a mechanism for exposing services to the applications which operate the application service. For example, a Core Network service is exposed via a NEF API to a V2X application server for supporting the V2X application service.
  • a service may be provided by the MNO or by an edge/ cloud provider (e.g. a Hyperscaler).
  • the edge/ cloud provider may consume MNO services and re-sell them to the ASP, or may provide its own telco services.
  • the ASP may wish to choose whether to invoke an API from either the MNO or from the Edge Cloud Service Provider (ECSP).
  • ECSP Edge Cloud Service Provider
  • One criterion upon which this choice may be based is the service performance and availability.
  • the service performance and availability of both the MNO and ECSP can be determined from collected API status and/ or analytics.
  • NWDAF instances may provide analytics for the AF and reside in edge, regional or core clouds.
  • the API producer is the NWDAF instance (or the NEF instance).
  • the ASP may determine which NWDAF to use by making a prediction based on the determined NWDAF API load and stability analytics.
  • An application server at the ASP and/ or vertical side may be deployed as an edge native application.
  • the main drivers for edge native application development include the light and simplified design and the support for application portability.
  • the support for API analytics at the edge is useful for such edge native applications to allow for dynamically deciding to scale-in from the edge to the cloud in heavy load situations, or scale out from the cloud to the edge to improve the quality of experience for the end user.
  • Some services may be offered with different granularity by different domains of the MNO or from the UE side.
  • 1) network QoS monitoring and prediction can be provided by the 5G core (5GC)
  • 2) performance monitoring including QoS for a specific area or a service profile can be provided by OAM
  • 3) application QoS monitoring end to end QoS between two or more applications using 5GS for communicating) by the app of the UE
  • QoS and/ or Quality of Experience (QoE) calculated at the edge All these offerings are provided via QoS APIs but may have different granularities. Accordingly, it may be beneficial for the ASP to select, based on the API conditions, what service to consume and what API to call.
  • APIs include Location API, Data Collection API, Analytics API. These APIs can be provided by different services and deployed by different domains. This capability will allow for predicting which API is the best to use based on the feature to be exposed and the exposure level required by the App Server [0033]
  • This document provides a mechanism by which API logs in a wireless communications network are collected and exposed to an ASP. Further, this document provides a mechanism by which the ASP may select which service API to invoke for consuming a service.
  • the NWDAF provides analytics services at the 5GC side and can expose the analytics to other NFs via Service Based Interface (SBI) APIs and to AF via NEF or Common API Framework (CAPIF) APIs.
  • SBI Service Based Interface
  • CAPIF Common API Framework
  • Some analytics services collect data from user-plane sessions (from UPF and/ or AF) and are necessary for the application server to get predictions or statistics from NWDAF. Examples of such analytics services are the following:
  • Observed Service Experience related network data analytics include: Service experience for a UE or a group UEs or any UE in an Application or a set of Applications over a specific UP path (UPF, DNAI and Edge Cloud server);
  • WLAN performance analytics UE UL/DL data rate and traffic volume
  • NWDAF collects UE UL/DL data rate and traffic volume from UPF and N4 session level data
  • NWDAF gets from UPF or AF: UL/DL throughput and peak UL/DL throughput
  • the Management Data Analytics Service is defined in SA5, TS 28.533 vl7.1.0).
  • the MDAS provides data analytics of different network related parameters including for example load level and/ or resource utilization.
  • the MDAS for a network function (NF) can collect the NF’s load related performance data, e.g. resource usage status of the NF.
  • the analysis of the collected data is per area, slice or slice subnet, and may provide forecast of resource usage information in a predefined future time. This analysis may also recommend appropriate actions e.g. scaling of resources, admission control, load balancing of traffic, etc.
  • AD AES Application Data Analytics Enabler Server
  • SA6, TR 23.700-36 will provide application data analytics services (stats/predictions) to optimize the application service operation by notifying the application specific layer, and potentially 5GS, for expected/ predicted application service parameters changes considering both on-network and off-network deployments (e.g. related to application QoS parameters).
  • the retrieved data alone may not be sufficient to calculate a prediction.
  • the data analytics service may also run models, which may be simulations of what-if scenarios for deriving different sets of data per worst case scenario. Such modelling may be useful for the vertical customers, since the MNO can guarantee a certain predictive performance based on the modelling.
  • the exposure of APIs to third parties can be performed via NEF/CAPIF or via Exposure Governance Management Function (EGMF) or via enablement APIs.
  • EGMF Exposure Governance Management Function
  • SA2 some examples of NEF APIs related to the exposure to verticals and/ or ASPs are shown in the following table.
  • Nnef_APISupportCapability may provide support for awareness on availability or expected level of a service API.
  • an AF may subscribe to receive notification about the availability or expected level of support of a service API for a UE or a group of UEs. As a result of such a subscription, the AF is then notified about the availability or expected level of support of a service API for a UE or a group of UEs.
  • MnS Management Services
  • EGMF Exposure Governance Management Function
  • BSS Business Support System
  • llhis details can be found at 3GPP TR 28.824 v0.5.0.
  • SA6 a list of APIs can be provided to the third-party application servers
  • APIs are defined for different types of enablement services, as follows: • Edge Applications (EDGEAPP, TS 23.558 vl7.2.0)
  • V2XAPP Vehicle-to-Everything Applications
  • Some of the exposed API re-use or abstract the capabilities provided by NEF services.
  • Such APIs include the Location Services exposure, QoS APIs, UP path information, for example.
  • CAPIF Common API Framework
  • CAPIF Core Function is a repository of all, PLMN and third-party, service APIs
  • API Exposing Function is the provider of the services as APIs
  • API Invoker is typically the applications that require service from the service providers
  • API management function enables the API provider to perform administration of the service APIs, this includes auditing the service API invocation logs received from the CAPIF core function, and Monitoring the events reported by the CAPIF core function, etc.;
  • API publishing function enables the API provider to publish the service APIs information in order to enable the discovery of service APIs by the API invoker.
  • the CAPIF is hosted within the PLMN operator network or trust domain.
  • the API invoker is typically provided by a third-party application provider that has a service agreement with the PLMN operator.
  • the API invoker may reside within the same trust domain as the PLMN operator network.
  • the API invoker within the PLMN trust domain interacts with the CAPIF via CAPIF-1 and CAPIF-2.
  • the API invoker from outside the PLMN trust domain interacts with the CAPIF via CAPIF-1 e and CAPIF-2e.
  • the API exposing function, the API publishing function and the API management function of the API provider domain are together known as API provider domain functions.
  • API provider domain functions within the PLMN trust domain interact with the CAPIF core function via CAPIF-3, CAPIF-4 and CAPIF-5 respectively.
  • ETSI defined Mobile Edge Computing allows the exposure of APIs from RAN to MEC platforms.
  • the exposure of APIs from UE/RAN to the service provider may relate to the UE location information, Bandwidth management, Radio Network Information (RNI).
  • RNI Radio Network Information
  • the ETSI document GS MEC 012 v2.1.5 specifies the RNI API exposure from RAN to MEC.
  • Radio Network Information Service is a service that provides radio network related information to MEC applications and to MEC platforms. The granularity of the radio network information may be adjusted based on parameters such as information per cell, per User Equipment, per QoS class or it may be requested over period of time.
  • the Radio Network Information may be used by the MEC applications and MEC platform to optimize the existing services and to provide new type of services that are based on up-to-date information on radio conditions.
  • FIG. 1 illustrates the architecture for enabling edge applications in accordance with 3GPP TS 23.558 v 17.2.0.
  • Figure 1 shows a system 100 comprising a user equipment (UE) 110, a 3GPP Core Network 120, an Edge Data Network 130, and an edge configuration server (ECS) 140.
  • UE 110 comprises at least one Application Client (AC) 112 and an Edge Enabler Client (EEC) 114.
  • the Edge Data Network 130 comprises at least one Edge Application Server (EAS) 132 and an Edge Enabler Server (EES) 134.
  • EAS Edge Application Server
  • EES Edge Enabler Server
  • the Edge Enabler Server (EES) 134 provides supporting functions needed for Edge Application Servers 132 and Edge Enabler Client 114, such as: a) provisioning of configuration information to Edge Enabler Client 114, b) enabling exchange of application data traffic with the Edge Application Server 132; c) interacting with 3GPP Core Network 120 for accessing the capabilities of network functions either directly (e.g. via PCF) or indirectly (e.g. via SCEF/NEF/SCEF+NEF); d) supports external exposure of 3GPP network capabilities to the Edge Application Server(s) 132 over EDGE-3.
  • the Edge Enabler Client (EEC) 114 provides supporting functions needed for Application Client(s) 112, such as retrieval and provisioning of configuration information to enable the exchange of Application Data Traffic with the Edge Application Server 132; and discovery of Edge Application Servers 132 available in the Edge Data Network 130.
  • the Edge Configuration Server (ECS) 140 provides supporting functions needed for the Edge Enabler Client 114 to connect with an Edge Enabler Server 134.
  • the functionalities of the Edge Configuration Server 140 are related to the provisioning of edge configuration information to the EEC 114, which are used for establishing connection with EES 134.
  • the Edge Application Server (EAS) 132 is the application server resident in the Edge Data Network 130, performing the server functions.
  • the Application Client (AC) 112 is the application resident in the UE 110 performing the client function.
  • O-RAN [https:/ /www. o-ran.org/] is an alliance which investigates the virtualization of access domain and considers the virtualization of control functionalities (Radio Resource Management / Radio Resource Control (RRC/RRM)) to a newly defined RAN Intelligent Controller (RIC) which may be co-located with the gNB or can be deployed for a cluster of gNBs.
  • RRC/RRM Radio Resource Management / Radio Resource Control
  • RIC RAN Intelligent Controller
  • the RRM/RRC functionalities can be either flexibly located either at the CU/DU or to dedicated RIC controllers, e.g. Near-real-time (Near-RT) RIC and Non-real-time (Non-RT) RIC.
  • O-RAN is discussing the QoE/ QoS optimization as possible Al-enabled feature which is deployed at the near-RT RIC (as third-party xAPP or proprietary xAPP) .
  • the task of checking QoS upgrade / downgrade may be assisted by the use of RIC; and the interfaces which need to be considered are Open APIs.
  • Near-RT RIC provides a set of APIs to third-party applications (which may be xApps).
  • Such APIs include:
  • Al related APIs APIs allowing to access Al related functionality (Al is the interface between the OAM of the O-RAN operator and the RIC).
  • E2 related APIs APIs allowing to access E2 related functionality and associated xApp Subscription Management and Conflict Mitigation functionality (E2 is the interface between the RAN nodes aka E2 nodes, and the RIC).
  • Management APIs APIs allowing to access management related functionality. These are used for services such as O1 Termination, management services and logging, tracing, metrics collection.
  • SDL APIs APIs allowing to access Shared Data Layer (SDL) related functionality.
  • Enablement APIs APIs between xApps and API enablement functionality.
  • 3GPP analytics such as those provided by NWDAF, MDAS, and AD AES) do not provide analytics services in relation to an API status, API load, or success and failures, and further these do not consider predictions made in relation to the API and which may be used by a consumer.
  • the Application Function is able to receive API availability and service level based on a request. However, this is only for the control plane / NEF APIs and it is not based on analytics, and as such no notion of API status prediction is known.
  • the CAPIF can provide service API logs based on API invoker. However this does not cover the collective API logs for all present and past API invokers which utilize(d) the target service API. Further, CAPIF has no capability to perform an analytics service such as making predictions based on the logs.
  • HTTP logs servers could provide support for API logs collection (usually this is internal servers, not standardized), however due to the fact that there are multiple types of APIs spanning across different domains, such an entity would need to be specified and be enhanced to collect logs from multiple domains and further modified to process and abstract logs before exposing them to the service provider.
  • SBA Service-Based Architecture
  • FIG. 2 depicts a user equipment apparatus 200 that may be used for implementing the methods described herein.
  • the user equipment apparatus 200 is used to implement one or more of the solutions described above.
  • the user equipment apparatus 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.
  • the input device 215 and the output device 220 may be combined into a single device, such as a touchscreen.
  • the user equipment apparatus 200 does not include any input device 215 and/ or output device 220.
  • the user equipment apparatus 200 may include one or more of: the processor 205, the memory 210, and the transceiver 225, and may not include the input device 215 and/ or the output device 220.
  • the transceiver 225 includes at least one transmitter 230 and at least one receiver 235.
  • the transceiver 225 may communicate with one or more cells (or wireless coverage areas) supported by one or more base units.
  • the transceiver 225 may be operable on unlicensed spectrum.
  • the transceiver 225 may include multiple UE panels supporting one or more beams.
  • the transceiver 225 may support at least one network interface 240 and/ or application interface 245.
  • the application interface(s) 245 may support one or more APIs.
  • the network interface(s) 240 may support 3GPP reference points, such as Uu, Nl, PC5, etc. Other network interfaces 240 may be supported, as understood by one of ordinary skill in the art.
  • the processor 205 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations.
  • the processor 205 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller.
  • the processor 205 may execute instructions stored in the memory 210 to perform the methods and routines described herein.
  • the processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225.
  • the processor 205 may control the user equipment apparatus 200 to implement the above-described UE behaviors.
  • the processor 205 may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions.
  • OS application-domain and operating system
  • baseband radio processor also known as “
  • the memory 210 may be a computer readable storage medium.
  • the memory 210 may include volatile computer storage media.
  • the memory 210 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/ or static RAM (“SRAM”).
  • the memory 210 may include non-volatile computer storage media.
  • the memory 210 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device.
  • the memory 210 may include both volatile and non-volatile computer storage media.
  • the memory 210 may store data related to implement a traffic category field as describe above.
  • the memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the apparatus 200.
  • the input device 215 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like.
  • the input device 215 may be integrated with the output device 220, for example, as a touchscreen or similar touch-sensitive display.
  • the input device 215 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen.
  • the input device 215 may include two or more different devices, such as a keyboard and a touch panel.
  • the output device 220 may be designed to output visual, audible, and/ or haptic signals.
  • the output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user.
  • the output device 220 may include, but is not limited to, a Liquid Crystal Display (“LCD”), a Light- Emitting Diode (“LED”) display, an Organic LED (“OLED”) display, a projector, or similar display device capable of outputting images, text, or the like to a user.
  • LCD Liquid Crystal Display
  • LED Light- Emitting Diode
  • OLED Organic LED
  • the output device 220 may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus 200, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like. [0074] The output device 220 may include one or more speakers for producing sound. For example, the output device 220 may produce an audible alert or notification (e.g., a beep or chime).
  • an audible alert or notification e.g., a beep or chime
  • the output device 220 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 220 may be integrated with the input device 215.
  • the input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display.
  • the output device 220 may be located near the input device 215.
  • the transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks.
  • the transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals and also to receive messages, data, and other signals.
  • the processor 205 may selectively activate the transceiver 225 (or portions thereof) at particular times in order to send and receive messages.
  • the transceiver 225 includes at least one transmitter 230 and at least one receiver 235.
  • the one or more transmitters 230 may be used to provide UL communication signals to a base unit of a wireless communications network.
  • the one or more receivers 235 may be used to receive DL communication signals from the base unit.
  • the user equipment apparatus 200 may have any suitable number of transmitters 230 and receivers 235.
  • the trans mi tter(s) 230 and the receiver(s) 235 may be any suitable type of transmitters and receivers.
  • the transceiver 225 may include a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.
  • the first transmitter/ receiver pair may be used to communicate with a mobile communication network over licensed radio spectrum and the second transmitter/ receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example a single chip performing functions for use with both licensed and unlicensed radio spectrum.
  • the first transmitter/receiver pair and the second transmitter/receiver pair may share one or more hardware components.
  • certain transceivers 225, transmitters 230, and receivers 235 may be implemented as physically separate components that access a shared hardware resource and/ or software resource, such as for example, the network interface 240.
  • One or more transmiters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a single hardware component, such as a multitransceiver chip, a system-on-a-chip, an Application-Specific Integrated Circuit (“ASIC”), or other type of hardware component.
  • One or more transmiters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a multi-chip module.
  • Other components such as the network interface 240 or other hardware components/ circuits may be integrated with any number of transmiters 230 and/ or receivers 235 into a single chip.
  • the transmitters 230 and receivers 235 may be logically configured as a transceiver 225 that uses one more common control signals or as modular transmitters 230 and receivers 235 implemented in the same hardware chip or in a multi-chip module.
  • FIG. 3 depicts further details of the network node 300 that may be used for implementing the methods described herein.
  • the network node 300 may be one implementation of an entity in the wireless communications network.
  • the network node 300 includes a controller 305, a memory 310, an input device 315, an output device 320, and a transceiver 325.
  • the input device 315 and the output device 320 may be combined into a single device, such as a touchscreen.
  • the network node 300 does not include any input device 315 and/ or output device 320.
  • the network node 300 may include one or more of: the controller 305, the memory 310, and the transceiver 325, and may not include the input device 315 and/ or the output device 320.
  • the transceiver 325 includes at least one transmiter 330 and at least one receiver 335.
  • the transceiver 325 communicates with one or more remote units 200.
  • the transceiver 325 may support at least one network interface 340 and/ or application interface 345.
  • the application interface(s) 345 may support one or more APIs.
  • the network interface(s) 340 may support 3GPP reference points, such as Uu, Nl, N2 and N3. Other network interfaces 340 may be supported, as understood by one of ordinary skill in the art.
  • the controller 305 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations.
  • the controller 305 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller.
  • the controller 305 may execute instructions stored in the memory 310 to perform the methods and routines described herein.
  • the controller 305 is communicatively coupled to the memory 310, the input device 315, the output device 320, and the transceiver 325.
  • the memory 310 may be a computer readable storage medium.
  • the memory 310 may include volatile computer storage media.
  • the memory 310 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/ or static RAM (“SRAM”).
  • the memory 310 may include non-volatile computer storage media.
  • the memory 310 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device.
  • the memory 310 may include both volatile and non-volatile computer storage media.
  • the memory 310 may store data related to establishing a multipath unicast link and/ or mobile operation.
  • the memory 310 may store parameters, configurations, resource assignments, policies, and the like, as described above.
  • the memory 310 may also stores program code and related data, such as an operating system or other controller algorithms operating on the network node 300.
  • the input device 315 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like.
  • the input device 315 may be integrated with the output device 320, for example, as a touchscreen or similar touch-sensitive display.
  • the input device 315 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen.
  • the input device 315 may include two or more different devices, such as a keyboard and a touch panel.
  • the output device 320 may be designed to output visual, audible, and/ or haptic signals.
  • the output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user.
  • the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user.
  • the output device 320 may include a wearable display separate from, but communicatively coupled to, the rest of the network node 300, such as a smart watch, smart glasses, a heads-up display, or the like.
  • the output device 320 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.
  • the output device 320 may include one or more speakers for producing sound.
  • the output device 320 may produce an audible alert or notification (e.g., a beep or chime).
  • the output device 320 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 320 may be integrated with the input device 315.
  • the input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display.
  • the output device 320 may be located near the input device 315.
  • the transceiver 325 includes at least one transmitter 330 and at least one receiver 335.
  • the one or more transmitters 330 may be used to communicate with the UE, as described herein.
  • the one or more receivers 335 may be used to communicate with network functions in the PLMN and/ or RAN, as described herein.
  • the network node 300 may have any suitable number of transmitters 330 and receivers 335.
  • the transmitter(s) 330 and the receiver(s) 335 may be any suitable type of transmitters and receivers.
  • a network node in a wireless communications system for collecting and providing service API logs to a consumer of a service API, the service API for a service produced by one or more service producers in the wireless communications system, the network node comprising a transceiver and a processor.
  • the network node may be a network node 300 comprising a processor 305 and a transceiver 325.
  • the transceiver is arranged to receive a request for obtaining service API invocation logs for one or more invokers within a service area, the request comprising a requirement for required service API information.
  • the processor is arranged to: determine from the request a set of service API logs to be collected for one or more service APIs within the service area; obtain the set of service API logs; process the service API logs based on the requirement for service API information, the type of the consumer, the service API type, or a combination thereof.
  • the transceiver is further arranged to transmit the processed service API logs based on the request.
  • the request for obtaining service API invocation logs for one or more invokers within a service area may comprise an application service profile, an application service requirement, an API identifier, an API type, a data collection event, an area of validity, a reporting configuration, or a combination thereof.
  • the request may comprise a subscription or a one-time request.
  • the application service profile may be similar to the application service type e.g. V2X, IOT, eMBB, or the application type within a service type (e.g. platooning application within V2X service type).
  • the application service profile may indicate whether it is group based, the KPIs to be used, application traffic types and schedules.
  • the processor determining a set of service API logs to be obtained for one or more service APIs within the service area may be based on the application service profile or requirement, the API availability at the area of validity, the permissions of the consumer, the exposure capabilities of the API producer of the target API, or a combination thereof.
  • the permissions of the consumer may vary and can be read or written accordingly.
  • the permissions of the consumer may recommend a change or cancel an action previously executed.
  • the API producer can be the service producer or another entity on behalf of the service producer (e.g. an exposure function).
  • the request may be received from a consumer.
  • the consumer may be a third- party application server, an application of a UE, an API invoker, an AF, an application data analytics enablement entity, or a combination thereof.
  • Figure 4 illustrates a method in a network node in a wireless communications system.
  • the method is for collecting and providing service API logs to a consumer of a service API, the service API for a service produced by a service producer in the wireless communications system.
  • the method comprises receiving 410 a request for obtaining service API invocation logs for one or more invokers within a service area, the request comprising a requirement for service API information.
  • the method further comprises determining 420 from the request a set of service API logs to be collected for one or more service APIs within the service area, and obtaining 430 the set of service API logs.
  • the method further comprises processing 440 the service API logs based on the requirement for service API information, the type of the consumer, the service API type, or a combination thereof, and transmitting 450 the processed service API logs based on the request.
  • the wireless communications system may comprise one or more network nodes and one or more wireless communications devices.
  • the network node may comprise an application enablement layer (e.g. SEAL, EES), the API-LSE, CCF, HTTP logs server, API logs server, or a CAPIF entity, for example.
  • the set of service API logs can be collected or fetched at the network node.
  • the network node may comprise a control entity at a communications platform.
  • the control entity may be for at least one wireless communication network.
  • the communications platform may be an edge or cloud or a middleware platform operated by a network operation.
  • the communications platform may be an edge and/ or cloud provider or a third-party vertical service provider.
  • the type of the consumer may correspond to one or more of: a consumer being a further network node, a consumer being a trusted 3rd party application, an un-trusted 3rd party application, an application enablement server or client, an application data analytics enablement server or client, a CAPIF entity, a management domain service or function.
  • the request for exposure may comprise a request to anonymize and/ or hide an API invoker’s identity.
  • the service API may relate to a service produced by a plurality of service providers.
  • the service API may be a control plane API, an OAM API, an edge API, or a client-server API, for example.
  • the service API type may be defined as the set of service APIs which are being invoked to expose similar service (or service targeting the same resources and parameters).
  • One example of service API type is the Location API, or QoS monitoring API which may be provided by different entities and sometimes with different granularity and reporting requirements.
  • the step of processing may comprise configuring, and or anonymizing the service API logs.
  • the service producer and service API producer may be the same entity, however it is possible that the service API producer is different.
  • the service API producer may be a gateway function.
  • the gateway function may be, for example, NEF, EGMF, AEF.
  • the service area may be the coverage area over which the service is provided, and can be represented as the geographical area (set of coordinates), the topological area (set of cells), the data network area (the set of EDNs), or civic addresses, for example.
  • the service area may also be defined in the time dimension, for example the time for which a service is requested at the target area.
  • the request for obtaining service API invocation logs for one or more invokers within a service area may comprise an application service profile, an application service requirement, an API identifier, an API type, a data collection event, an area of validity, a reporting configuration, or a combination thereof.
  • the request may comprise a subscription or a one-time request.
  • the application service profile may be similar to the application service type e.g. V2X, IOT, eMBB, or the application type within a service type (e.g. platooning application within V2X service type).
  • the application service profile may indicate whether it is group based, the KPIs to be used, application traffic types and schedules.
  • the determination of a set of service API logs to be obtained for one or more service APIs within the service area may be based on the application service profile or requirement, the API availability at the area of validity, the permissions of the consumer, the exposure capabilities of the API producer of the target API, or a combination thereof.
  • the permissions of the consumer may vary and can be read or written accordingly.
  • the permissions of the consumer may recommend a change or cancel an action previously executed.
  • the API producer can be the service producer or another entity on behalf of the service producer (e.g. an exposure function).
  • the request may be received from a consumer.
  • the consumer may be a third- party application server, an application of a UE, an API invoker, an AF, an application data analytics enablement entity, or a combination thereof.
  • the requirement for service API information may comprise a level of exposure and/ or abstraction of the service API information. Processing of the service API logs may be performed according to the level of exposure and/ or abstraction of the service API information indicated in the requirement for service API information. The processing of the service API logs may comprise aggregating service API logs retrieved from a plurality of API invokers and anonymizing them.
  • Obtaining service API logs may comprise: requesting service API logs information from at least one API producer; and receiving the requested service API logs.
  • the API producer may be an API database.
  • the service API logs may be obtained from the service producer and/ or an exposure function.
  • the exposure function may be associated with the service producer.
  • the exposure function may be a gateway function.
  • the obtained service API logs may be historical service API logs, real-time API data corresponding to ongoing API invocations, or a combination thereof.
  • the service API comprise a NEF API, an OAM API, an enablement API, a MEC API, a RIC API, a slice API, a client-server API, a local UE API, or a combination thereof.
  • the RIC API may be defined in O-RAN for near-RT RIC.
  • the RIC API may be between the RIC modules and the xApps in O-RAN architecture.
  • the enablement API may comprise an API between the enablement layer and the application specific layer.
  • the enablement API may be a SEAL-S API for example (as specified in 3GPP TS7.434 V17.4.0), or an EDGE-3 and EDGE-5 APIs (as specified in 3GPP TS 7.558 vl7.2.0).
  • the client-server API may provide a service between an enablement server and an enablement client. Examples of such an API are EDGE-1 and EDGE-4 in 3GPP TS 7.558 vl 7.2.0.
  • the local UE API may provide a service between the application of the UE and the enablement layer of the UE or UE modem.
  • the slice API may be a bundled API tailored for a given slice (e.g. V2X slice API comprises a set of NEF APIs, OAM APIs, client-server APIs).
  • the service API may be a client-server API, the request includes one or more notification methods, and the service API logs related to the client-server APIs are processed based on the one or more notification methods.
  • the service API logs related to the client-server APIs may indicate an optimal notification method for a given area.
  • the notification method may comprise at least one of websockets, long polling, or be OEM specific e.g. Apple Push Notification Service (APNS).
  • APNS Apple Push Notification Service
  • the service API logs related to the client-server APIs may indicate an optimal notification method for a given area.
  • the obtained set of service API logs indicate the operator’s network to be used for a future API invocation for a given area and time horizon.
  • the wireless communication system may comprise a plurality of networks, each network operated by a different network operator.
  • the service API logs may be obtained from each of the plurality of networks.
  • This document presents a solution that provides new functionality for API logs collection by way of an API logs server residing at an edge/ cloud platform.
  • FIG. 5 illustrates a system 500 for implementing a solution presented herein.
  • the system 500 comprises a UE 510, a RAN 520, a Core Network User plane function (CN-U) 532, a Core Network Control plane function (CN-C) 534, an OAM 540, an EDN 550 and at least one Application Server 560.
  • the UE 510, the RAN 520, the CN- U 532, the CN-C 534, the OAM 540, and the EDN 550 are elements of a wireless communications system.
  • the UE 510 comprises Application Enablement Clients 510, and is arranged to execute Applications 514.
  • the Applications 514 and Application Servers 560 are external to the wireless communications system.
  • the EDN 550 comprises a MEC 552, which may provide RIC services, an API Logs Server 554, at least one Application Enablement Server 556, and an API Analytics Enabler 558.
  • the UE 510 may be a UE 110, 200, 610.
  • Each of the Application server 560 and edge data network 550 may comprise a network node 300.
  • the API Logs Server 554 includes a memory arranged to store API logs.
  • the API logs may be stored in a database in the memory, the database arranged to collect and store logs and usage of APIs for services exposed in the wireless communications network.
  • Such APIs may include OAM APIs, 5GC APIs, MEC APIs, Enablement APIs, and/ or RIC APIs.
  • Logs include the API invocation success/ errors, API throttling/ rate limitation events, number of API invocations for a given time and area and/ or slice.
  • the API Logs Server 554 includes a processor arranged to: classify the telco- provided APIs offering the same service (for example Location APIs from 5GC, SEAL LMS, UE, MEC) and aggregating the logs of all invokers for the target service APIs hiding the API invokers information (other than the requestor) before exposing the aggregated API logs.
  • a processor arranged to: classify the telco- provided APIs offering the same service (for example Location APIs from 5GC, SEAL LMS, UE, MEC) and aggregating the logs of all invokers for the target service APIs hiding the API invokers information (other than the requestor) before exposing the aggregated API logs.
  • the API Logs Server 554 further includes a transceiver arranged to receive a request for API logs for one or more service APIs; request/ receive or fetch historical API invocation data for the target service APIs; request/ receive real time API invocation data for the target service API; and transmit the requested API logs.
  • a subscription request is received by the API Logs Server 554 for collecting API logs for one or more service APIs.
  • the service APIs include all types of telco-provided APIs.
  • the service APIs may relate to a service exposed in the wireless communications network.
  • the subscription request includes the event ID for API logs collection and sub-filters (e.g. QoS Monitoring API including sub-filters identifying one or more UEs, applications), as well as the service area, PLMN ID, domain ID (e.g. MD ID), exposure gateway ID (e.g. NEF ID, SEAL ID), application/UE session ID, and optionally the data producer ID (if not identified by the exposure gateway).
  • the service area may be defined by topological, geographical, civic addresses, EDN service area, or even temporally.
  • the request may include the exact APIs, or the API type without specifying the source. For example, QoS monitoring API, analytics for UE Location API in a given service area.
  • the request may also indicate the PLMN ID of the requested API analytics. It may happen that multiple PLMNs can provide a service and the Application Server determines that it should find the best API producer to select among different MNO networks.
  • the API Logs Server 554 upon receiving the subscription request, if the event type is not for specific API but for an API type, maps the API type to the available APIs in the service area defined at the request.
  • the API analytics enabler maps to “5GC#1 provided service API”, “5GC#2 provided service API”, SEAL LMS #1 provided, UE provided service API, MEC platform.
  • API logs server 554 requests and then receives, or fetches, from the database API logs for the target service API.
  • the retrieved API logs are based on the request or the mapping).
  • API Logs include, for example, the API invocation success /errors, API throttling/ rate limitation events, number of API invocations for a given time and area and/ or slice.
  • the report may also include the list of API invokers’ IDs (or anonymized the number of API invokers), service API invoker source type (NF type that initiated the API request, list of IP addresses (if not anonymized), service API name, version, invoked operations, input parameters, invocation result, time and area information.
  • the API exposing identity information can be reported.
  • the exposing identity information may comprise the identity of the exposing function which provided the logs to the API logs server 554.
  • the exposing function may comprise at least one of AEF, NEF, EGMF.
  • the API logs server 554 evaluates whether the API logs are sufficient for exposing to the consumer. If not, the API logs server 554 requests from the API producer or the API exposing function (indicated at the logs) additional logs for ongoing API invocations for the target service APIs.
  • the API logs server 554 receives the additional API logs for the target service APIs based on the request. Such real-time logs may need to pass an auditing step, so some interaction with API management function may be needed.
  • the API logs server 554 may process the API logs to generate a report.
  • the report may be an API logs report.
  • the processing may comprise aggregating and abstracting the API logs, for hiding the API invokers information (other than the requestor) before exposing the aggregated API logs in the report.
  • Such abstraction may be different per exposure level of the consumer (which can be an API analytics enabler or an edge application or a cloud application) .
  • An example aggregation might involve the number of invocations of a NEF API at EDN area #1 between these dates and times are 1000, the success ratio of invocations, the API load information, the logs on throttling events or rate limitation events.
  • the API logs for client-server APIs may include the stats per notification method e.g. http long polling (pull) or web-sockets (push) for a given API.
  • the API logs server 554 sends the report to the consumer.
  • FIG. 6 is a signaling diagram illustrating a method 600 for processing service API logs at an AD AES or SEAL.
  • the illustrated system comprises a UE 610, an API producer 620 within the wireless communications network, a logs database 630, an API Logs Service Enabler (API-LSE) 640 and an Application Server 650.
  • the UE 610 comprises an application (App#l) 612, a local API Logs Service Enabler 614 and a modem 616 for communication with the wireless communications network.
  • the UE 610 may be a UE 110, 200, 510.
  • Each of the API Producer 620 and App server 650 may comprise a network node 300.
  • the API-LSE 640 may comprise an API logs server 554.
  • the logs database 630 may comprise an edge database.
  • the local API Logs Service Enabler 614 may be a local instance or a client of the API-LSE 640.
  • the local API Logs Service Enabler 614 may be a client counterpart of the API-LSE 640.
  • the method 600 commences at 681 with the consumer 650 making a subscription request for collecting API logs to the API logs service enabler (API-LSE) 640.
  • the consumer 650 may comprise an application server or API invoker or an application of one or more UEs, or the ADAE-S.
  • the API-LSE 640 is the logs service producer or mediator between the Logs database 630 and the consumer 650.
  • the API- LSE 640 may be implemented at an HTTP logs server, or an edge API logs database or a SEAL server.
  • the subscription request includes the requestor ID (e.g. App Server ID, AD AES ID), the UE ID or App ID for which the API logs request applies (e.g.
  • the subscription may provide the telco service API type to be exposed (e.g.
  • the API-LSE 640 authorizes the subscription request and requests or fetches from the logs database 630 all historical API invocation logs for the target API.
  • Historical API invocation logs for a plurality of APIs may be fetched if the type of API is provided and indicates a plurality of target APIs.
  • Such fetch/ request can be via a new fetch API or can be up to implementation, such as a platform internal procedure, or can be performed in a service based manner.
  • the request may include: the originated requestor ID (e.g.
  • the logs database 630 may be an ADRF or an embedded database at the platform where the API-LSE 640 resides.
  • the API-LSE 640 receives the data for the target API(s) based on the request in 682.
  • the API-LSE 640 may also request and receive from the producer(s) of the target API(s), API status information and real-time API logs. Such a request may be different based on the type of the producer. In particular, the following considerations are relevant where the producer is a NEF/SCEF, an OAM, an MEC, a SEAL, and UE application.
  • NEF/SCEF Where the API producer is a NEF/SCEF the API availability and service level can be requested (e.g. via invoking a Nnef_APISupportCapability API) for the target API. Such a request may indicate the originated API invoker and the ongoing logs from other API invocations.
  • the response will indicate the API status and availability and may also provide details for other NEF API invocations for the specific service area (here this data will be anonymized).
  • NEF API status logs information include: number of ongoing NEF API calls for the target API, success rate of invocations, NEF API failure or throttling events etc.
  • OAM Where the API producer is an OAM, then the request or subscription may be for Management Services API status information. This may be sent directly to the Management Services producer or via EGMF or via a management exposure gateway and may include the requested API type, API availability indication in a target area, number of API invocations for target API, API invocation logs for ongoing requests within a target area or for API invokers of a certain type (e.g. V2X servers, eMBB servers). The response may include the requested information and for the case of requiring other invokers’ information, some anonymization may be provided.
  • V2X servers e.g. V2X servers, eMBB servers
  • MEC Where the API producer is a MEC, the request or subscription may be for MEC API status information. For example, for RNIS APIs the number of ongoing invocations, failure/ throttling events, API load information, etc. can be part of the reporting required by the API-LSE 640.
  • SEAL/EDGEAPP Where the API producer is a SEAL/EDGEAPP, RIC and other API producers then a similar request or subscription may be needed as above.
  • API information may be about ongoing client-server API status information. Apart from the previous information on the API status, this request may also include the reporting of logs for a given API notification method (WebSocket, long polling, OEM specific) that is used.
  • API notification method WebSocket, long polling, OEM specific
  • the relevant API producer 620 fetches the requested API status information and optionally will anonymize the data before sending a response.
  • the API-LSE 640 receives the additional API logs for the target service APIs based on the request. Such real-time logs may need to pass through an auditing process, so some interaction with an API management function may be needed.
  • the API-LSE 640 processes the API logs before generating a report.
  • the processing may comprise aggregating and abstracting the API logs, so as to hide the API invokers information (other than the requestor) before exposing the aggregated API logs.
  • Such abstraction may be different per exposure level of the consumer 650 (which can be an API analytics enabler or an edge application or a cloud application).
  • An example of such aggregation is: the number of invocations of a NEF API at EDN area #1 between particular dates and times are 1000, the success ratio of invocations, the API load information, the logs on throttling events or rate limitation events.
  • the API-LSE 640 optionally stores the aggregated API logs to the Logs Database 630.
  • the API-LSE 640 sends the requested API log report to the consumer 650 based on the request.
  • Figure 7 illustrates a system 700 for implementing another solution presented herein. This is for the case when CAPIF is used for the northbound API exposure.
  • the API-LSE functionality may be located in different CAPIF entities based on the implementation (e.g. in AEF, CCF, API Management Function). Also, there can be interaction between multiple CAPIF domains and inter-CCF communication may be required.
  • the system 700 comprises a first Common API Framework (CAPIF) core function 720, an API invoker 730, an NEF 740, and a second CAPIF Core Function (CCF#2) 750.
  • the NEF 740 may alternatively comprise an SCEF or an AD AES.
  • the NEF 740 comprises an API exposing function (AEF-1) 742, and API publishing function 744, and API management function 746.
  • An API-LSE Service 760 may be implemented at any of the locations indicated by a star in figure 7.
  • the API-LSE Service 760 may be implemented at the first CCF 720, the API exposing function (AEF-1) 742, the API management function 746, or the CCF#2 750.
  • the API invoker 730 may be a UE 110, 200, 510, 610, a network node 130, 300, or a server 560, 650.
  • FIG. 8 illustrates a method 800 of operation of the system 700.
  • Method 800 commences at 821 with a subscribing entity 710 (which may be the AD AES 740, an application server, an application client, or the API invoker 730) sends an event subscription request to the API-LSE 760 to receive notification of events related to the API logs collection.
  • a subscribing entity 710 which may be the AD AES 740, an application server, an application client, or the API invoker 730
  • Table 4 gives an example of such an event subscription request.
  • the API-LSE 760 upon receiving the event subscription request from the subscribing entity 710, the API-LSE 760 checks for the relevant authorization for the event subscription.
  • the API-LSE 760 stores the subscription information. [0148] At 823, the API-LSE 760 sends an event subscription response indicating successful operation.
  • the API-LSE 760 triggers API invocation log pull request towards the CAPIF core function.
  • the API invocation log pull request indicates the API (or list of APIs) for which logs are required. Examples of information elements included in such a message are given in table 5.
  • the CCF 720 authorizes the request and fetches the API logs from the storage unit. CCF 720 then sends 826 the requested information to the API-LSE 760 via an API invocation log pull/ fetch response message. Table 6 gives some examples of information elements included in such a message
  • API invocation log pull/ fetch response [0151]
  • the API-LSE 760 authorizes and anonymizes the API logs (if not performed by CCF 720) and abstracts based on exposure level, the exposure level can be known based on pre-configuration by the OAM or based on the subscription and type of invoker.
  • the API-LSE 760 sends event notifications to all the subscribing entities that have subscribed for the event matching the criteria. If a notification reception information is available as part of the subscribing entity event subscription, then the notification reception information is used by the API-LSE 760 to send event notifications to the subscribing entity.
  • the notification may include the following parameters: the event ID, the service API name and/ or type, the abstracted or anonymized API logs (for example number of failure API invocations, API availability, frequency and occurrence of API version changes, API location changes for the target API, API throttling events, number of API invocations for a given area and time, API load statistics for a given edge network, etc.), the time and area where the reporting occurs and is valid.
  • the abstracted or anonymized API logs for example number of failure API invocations, API availability, frequency and occurrence of API version changes, API location changes for the target API, API throttling events, number of API invocations for a given area and time, API load statistics for a given edge network, etc.
  • AD AES application enablement layer
  • SEAL SEAL-DD
  • SEAL-DD SEAL-DD
  • CAPIF entities CCF or AEF or API management function
  • the described capability covers the client-server APIs and can be used to expose information based on the API notification method- signaling over SA6 / RIC / MEC defined interfaces for operating API-LSE (impact depends on the implementation) .
  • the role of API Logs Server Enabler as part of 3GPP SA6 defined enablement layer (e.g. SEAL) is defined.
  • the enabler collects logs from an edge database or logs servers in different domains or directly from the API producers.
  • This advantageously introduces a value added service residing at an API logs server (e.g. HTTP server) to collect logs from heterogenous API producers and provide the aggregation of the API status /conditions for different types of APIs while keeping the anonymity of the API invokers.
  • Such capability may also provide the selection among different API producers or domains (e.g. different MNOs or different platforms) which can be candidates to offer similar service information (e.g. QoS monitoring or Location reporting for a UE).
  • a CAPIF is used for northbound API exposure.
  • the API-LSE functionality may be located in different CAPIF entities based on the implementation (e.g. in AEF, CCF, API Management Function) or can be an enablement entity (e.g. AD AES) which provides services to the CAPIF entities. Also, there can be interaction between multiple CAPIF domains and inter-CCF communication may be required. According to such an arrangement, where the CAPIF currently is storing logs, it may also provide logs to API management function.
  • the service API logs are stored and fetched for a given API invoker.
  • the API logs are collected for multiple invokers and from multiple sources and granularities (e.g. historical and real time data) for a given service API. This tends to allow the CCF to store and process API logs collectively and offer this as a service to the subscriber (e.g. API invoker).
  • Such service tends to provide an optimization of the current CAPIF functionalities to allow the API invoker to acquire a holistic view of the expected service API performance.
  • a method for collecting and providing API logs to a consumer of a service API comprises: receiving a request for obtaining service API invocation logs for one or more invokers within a service area, wherein the request providing a requirement for service API information mapping the request to collect API logs to a requirement to collect logs for one or more service APIs within the service area; obtaining the API logs related to the identified service APIs; configuring the API logs based on the request for exposure; transmitting the configured API logs based on the request.
  • the method may be performed at API-LSE, CCF, HTTP logs server, edge logs capability.
  • the service API can a control plane API, a OAM API, an edge API, a client-server API.
  • API logs can be collected or fetched at the entity implementing the method. Configuring the API logs based on the request for exposure may comprise processing the API logs. The processing may comprise anonymizing and/ or hiding an API invoker’s identity.
  • the request can be a subscription or one time request, and comprises an application service profile or requirement, an API identifier, an API type, a data collection event, an area of validity, a reporting configuration, or a combination thereof.
  • the mapping of a request to collect API logs may be based on the application service profile or requirement, the API availability at the area of validity, the permissions of the consumer, the exposure capabilities of the API producer of the target API, or a combination thereof.
  • the consumer may be a third-party application server, an application of a UE, an API invoker, an AF, an application data analytics enablement entity, or a combination thereof.
  • Configuring the API logs may comprise aggregating the API logs for multiple API invokers and anonymizing them.
  • Obtaining API logs may comprise requesting API logs information from one or more API producers and/ or databases- receiving API logs information.
  • the API logs may be derived based on historical API logs, real-time API data corresponding to ongoing API invocations, or a combination thereof.
  • the API may comprise a NEF API, an OAM API, an enablement API, a MEC API, a RIC API, a slice API, a client-server API, a local UE API, or a combination thereof.
  • the API logs collection related to the client-server APIs can be based on the notification method.
  • the notification method may comprise: websockets, long polling, OEM specific e.g. APNS.
  • the API logs related to the client-server APIs may indicate an optimal notification method for a given area.
  • the API logs may indicate the operator’s network to be used for a future API invocation for a given area and time horizon.
  • the method may also be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal Processor (DSP) or similar, causes the processor to carry out the hereinbefore described methods.
  • DSP Digital Signal Processor
  • the described methods and apparatus may be practiced in other specific forms.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Il est proposé un nœud de réseau dans un système de communications sans fil pour collecter et fournir des journaux d'API de service à un consommateur d'API de service, l'API de service pour un service produit par un ou plusieurs producteurs de services dans le système de communications sans fil, le nœud de réseau comprenant un émetteur-récepteur et un processeur. L'émetteur-récepteur est conçu pour recevoir une demande d'obtention de journaux d'invocation d'API de service pour un ou plusieurs invocateurs dans une zone de service, la demande comprenant une exigence d'informations d'API de service requises. Le processeur est conçu pour : déterminer, à partir de la demande, un ensemble de journaux d'API de service à collecter pour une ou plusieurs API de service dans la zone de service ; obtenir l'ensemble de journaux d'API de service ; et traiter les journaux d'API de service en fonction du besoin d'informations sur les API de service, du type de consommateur, du type d'API de service, ou d'une combinaison de ces éléments. L'émetteur-récepteur est en outre conçu pour transmettre les journaux d'API de service traités en fonction de la demande.
PCT/EP2022/057714 2022-02-18 2022-03-23 Activation des journaux d'api de service dans un système de communication sans fil WO2023156026A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GR20220100153 2022-02-18
GR20220100153 2022-02-18

Publications (1)

Publication Number Publication Date
WO2023156026A1 true WO2023156026A1 (fr) 2023-08-24

Family

ID=81327274

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/057714 WO2023156026A1 (fr) 2022-02-18 2022-03-23 Activation des journaux d'api de service dans un système de communication sans fil

Country Status (1)

Country Link
WO (1) WO2023156026A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210279119A1 (en) * 2017-05-02 2021-09-09 Samsung Electronics Co., Ltd. Method and apparatus for providing network-based northbound application programming interface in a wireless communication system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210279119A1 (en) * 2017-05-02 2021-09-09 Samsung Electronics Co., Ltd. Method and apparatus for providing network-based northbound application programming interface in a wireless communication system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; Stage 2 (Release 17)", vol. SA WG6, no. V17.5.0, 24 June 2021 (2021-06-24), pages 1 - 118, XP052029581, Retrieved from the Internet <URL:https://ftp.3gpp.org/Specs/archive/23_series/23.222/23222-h50.zip 23222-h50.doc> [retrieved on 20210624] *
ANONYMOUS: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Common API Framework for 3GPP Northbound APIs (Release 15)", 3GPP STANDARD; TECHNICAL REPORT; 3GPP TR 23.722, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V15.1.0, 3 April 2018 (2018-04-03), pages 1 - 65, XP051450926 *

Similar Documents

Publication Publication Date Title
WO2022194359A1 (fr) Configuration d&#39;interface de programmation d&#39;application indépendante de la plateforme
US11570054B2 (en) Device and method for providing control plane/user plane analytics
US10798577B2 (en) Unified data repository proxy
US20240056496A1 (en) Method and Apparatus for Selecting Edge Application Server
WO2023156026A1 (fr) Activation des journaux d&#39;api de service dans un système de communication sans fil
WO2023156025A1 (fr) Activation d&#39;analyse d&#39;api de service dans un système de communication sans fil
WO2024046588A1 (fr) Collecte et distribution de données dans un réseau de communication sans fil
WO2024027943A1 (fr) Interactions et interopérations de fonctions analytiques dans un réseau de communication sans fil
WO2023110162A1 (fr) Facturation de fournisseurs de services d&#39;application couplés à des réseaux de communication sans fil
WO2024088591A1 (fr) Apprentissage fédéré par agrégation de modèles dans un réseau de communication sans fil visité
US20240129876A1 (en) Systems and methods for analytics and information sharing between a radio access network and a core network
US20230216929A1 (en) Apparatus, methods, and computer programs
WO2024088572A1 (fr) Enregistrement et découverte de clients d&#39;apprentissage fédéré externes dans un système de communication sans fil
WO2024088590A1 (fr) Apprentissage fédéré par découverte de clients dans un réseau de communication sans fil visité
WO2022261972A1 (fr) Appareils, procédés et programmes informatiques
WO2023105485A1 (fr) Détermination de données d&#39;application et/ou d&#39;analyses
WO2023104346A1 (fr) Détermination de données et/ou d&#39;analyses d&#39;applications
US20240056362A1 (en) Apparatus, methods, and computer programs
WO2023099040A1 (fr) Collecte de données de performance dans un réseau de communication sans fil
WO2024027941A1 (fr) Amélioration de la précision d&#39;analyse dans un réseau de communication sans fil
WO2023057079A1 (fr) Adaptations basées sur une exigence de continuité de service
WO2023179890A1 (fr) Calcul de la consommation d&#39;énergie de service d&#39;application dans un réseau de communication sans fil
WO2024088551A1 (fr) Évaluation de la précision d&#39;analyse dans un réseau de communication sans fil
WO2024022597A1 (fr) Procédés et appareils de prise en charge d&#39;imputation de frais d&#39;un service fédéré
WO2023138798A1 (fr) Amélioration de la confiance d&#39;analyse de réseau à l&#39;aide d&#39;un jumeau numérique

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22717188

Country of ref document: EP

Kind code of ref document: A1