Network exposure API abuse protection

Abstract

Embodiments include methods performed by a security function of a communication network. Such methods include determining the following: that application programming interface (API) requests from one or more consumers have degraded performance of the communication network, and at least one recommended action to mitigate the degraded performance due to the API requests. The API requests are via a network exposure function (NEF) of the communication network. Such methods include sending, to one or more network functions (NFs) of the communication network, an indication of the at least one recommended action. Other embodiments include complementary methods for a network data analytics function (NWDAF), as well as network equipment configured to implement security functions and NWDAFs, and thereby to perform such methods.

Description

[0001] NETWORK EXPOSURE API ABUSE PROTECTION

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to application programming interfaces (APIs) and more specifically to techniques to protect against abuse of APIs that expose certain communication network functionality.

[0004] BACKGROUND

[0005] API security is relevant and / or important consideration during design (including planning, creating, and verifying) and runtime (including preproduction, release, configuration, and monitoring). Conventionally, API security techniques fall into the following four areas:

[0006] • Design-time discovery - analysis of code to find APIs, generate and / or ensure that they are correctly documented.

[0007] • Design time API security testing - extensions of software / application testing during development.

[0008] • Runtime discovery - checking what APIs are accessible / exposed in the actual deployment.

[0009] • Runtime API threat protection - which typically includes both preventive “posture management” with further testing and configuration checking, and reactive, detection and response, controls.

[0010] The present disclosure focuses on the last of these areas: runtime API threat protection. Runtime threats may occur even when access control mechanisms are available and correctly configured, such as when an adversary gains access to the API through stolen / leaked credentials or other type of unauthorized intrusion. Currently available products in this area are designed for general use in enterprise environments. It is unknown whether such products may be - or have been - used for runtime API threat protection in communication networks, such as in fifthgeneration (5G) wireless networks.

[0011] SUMMARY

[0012] Most existing API protection solutions deal with top- 10 vulnerabilities identified by the Open Worldwide Application Security Project (OWASP), which focus generally on security misconfigurations. However, such solutions are generally unable to identify more stealthy attacks that involve a combination of multiple API calls during runtime - possibly from several different entities (or attackers) - where each API call itself may be or seem harmless. This problem or scenario may be characterized as runtime “abuse” of the API. Existing protection techniques against runtime abuse are often deployed as a gateway or proxy, in front of the exposed API but only with very limited insight into how the protected system behaves in response to the incoming API requests. Accordingly, better solutions are needed.

[0013] An object of embodiments of the present disclosure is to provide techniques that improve protection against runtime abuse of network exposure APIs in a communication network, such as providing, enabling, and / or facilitating solutions to exemplary problems summarized above and described in more detail below.

[0014] Some embodiments include exemplary methods (e.g., procedures) performed by a security function of a communication network.

[0015] These exemplary methods include determining the following: that API requests from one or more consumers have degraded performance of the communication network, and at least one recommended action to mitigate the degraded performance due to the API requests. The API requests are via a network exposure function (NEF) of the communication network. These exemplary methods also include sending, to one or more network functions (NFs) of the communication network, an indication of the at least one recommended action.

[0016] In some embodiments, determining that API requests from one or more consumers have degraded performance of the communication network includes the following operations:

[0017] • receiving the following information from the NEF for each of a plurality of API requests from a plurality of different consumers: an identifier of the consumer making the API request, and an identifier of the API request;

[0018] • receiving network performance information from one or more of the following of the communication network: a radio access network (RAN), and at least one NF;

[0019] • correlating the received network performance information with the information received from the NEF, thereby obtaining correlated information; and

[0020] • detecting, based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network.

[0021] In some of these embodiments, the network performance information includes one or more of the following:

[0022] • processing load information for the at least one NF;

[0023] • processing load information for one or more network nodes of the communication network;

[0024] • RAN traffic scheduling information; and

[0025] • performance information related to handling of API requests and corresponding responses. In other embodiments, determining that API requests from one or more consumers have degraded performance of the communication network includes receiving the following information from a network data analytics function (NWDAF) of the communication network:

[0026] • an indication that API requests from one or more consumers have degraded performance of the communication network, and

[0027] • respective identifiers of the one or more consumers.

[0028] In such embodiments, the at least one recommended action is determined based on the received information.

[0029] In some of these embodiments, these exemplary methods also include sending to the NWDAF one or more rules for detecting degraded performance of the communication network due to API requests. The information received from the NWDAF is based on the one or more rules. In some of these embodiments, the information received from the NWDAF also includes one or more of the following: identifiers of the API requests that have degraded performance, and RAN traffic scheduling information that indicates the degraded performance.

[0030] In some embodiments, the indication is sent to the NEF. In other embodiments, the indication is sent to a policy control function (PCF) via the NEF.

[0031] Other embodiments include exemplary methods (e.g., procedures) performed by a network data analytics function (NWDAF) of a communication network. In general, these exemplary methods are complementary to the exemplaiy methods performed by a security function, as summarized above.

[0032] These exemplary methods include, for each of a plurality of API requests from a plurality of different consumers, the NWDAF receives the following information from an NEF of the communication network: an identifier of the consumer making the API request, and an identifier of the API request. These exemplary methods also include receiving network performance information from one or more of the following of the communication network: a RAN, and at least one NF.

[0033] These exemplary methods also include correlating the received network performance information with the information received from the NEF, thereby obtaining correlated information. These exemplary methods also include detecting, based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network. These exemplary methods also include sending the following information to a security function of the communication network: an indication that API requests from one or more consumers have degraded performance of the communication network, and respective identifiers of the one or more consumers. In some embodiments, the network performance information includes one or more of the following:

[0034] • processing load information for the at least one NF ;

[0035] • processing load information for one or more network nodes of the communication network;

[0036] • RAN traffic scheduling information; and

[0037] • performance information related to handling of API requests and corresponding responses.

[0038] In some embodiments, these exemplary methods also include receiving the one or more rules from the security function. In some embodiments, the information sent to the security function also includes one or more of the following: identifiers of the API requests that have degraded performance, and RAN traffic scheduling information that indicates the degraded performance.

[0039] Other embodiments and variants of the exemplary methods summarized above are described herein. Other embodiments include security functions and NWDAFs configured to perform the exemplary methods summarized above, as well as network equipment configured to implement such security functions and NWDAFs. Other embodiments include non-transitory, computer-readable media storing computer-executable instructions that, when executed by processing circuitry, configure or cause such security functions and NWDAFs to perform operations corresponding to the exemplary methods summarized.

[0040] These and other embodiments described herein may provide various benefits and / or advantages. For example, embodiments may provide a more tailored and / or targeted solution for protection of network exposure APIs. Embodiments may improve runtime protection by information sharing to facilitate event correlation and attribution of bad outcomes to particular actors / requestors. Also, embodiments may facilitate detection of stealthy attacks that involve a combination of multiple requests possibly originating from multiple separate entities, even when each individual request appears harmless. Embodiments may also provide targeted mitigation actions to address problematic requests.

[0041] Other objects, features, and advantages of embodiments of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below.

[0042] BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments. FIG. 1 shows an exemplary 5G network architecture.

[0044] FIG. 2 illustrates a system according to some embodiments.

[0045] FIG. 3 illustrates a system according to some embodiments.

[0046] FIG. 4 illustrates a system according to some embodiments.

[0047] FIG. 5 illustrates a sequence diagram according to some embodiments.

[0048] FIG. 6 illustrates a sequence diagram according to some embodiments.

[0049] FIG. 7 illustrates a flowchart according to some embodiments.

[0050] FIG. 8 illustrates a sequence diagram according to some embodiments.

[0051] FIG. 9 illustrates a sequence diagram according to some embodiments.

[0052] FIG. 10 illustrates a sequence diagram according to some embodiments.

[0053] FIG. 11 illustrates an abuse pattern specified as a JSON according to some embodiments.

[0054] FIG. 12 illustrates an exemplary method (e.g., procedure) for a security function according to some embodiments.

[0055] FIG. 13 illustrates an exemplary method (e.g., procedure) for an NWDAF according to some embodiments.

[0056] FIG. 14 is a block diagram of an apparatus according to some embodiments.

[0057] FIG. 15 shows a communication system according to some embodiments.

[0058] FIG. 16 shows a network node according to some embodiments.

[0059] FIG. 17 shows a block diagram of a virtualization environment in which some embodiments may be virtualized.

[0060] DETAILED DESCRIPTION

[0061] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0062] In general, all terms used herein are to be interpreted according to their ordinary meaning to a person of ordinary skill in the relevant technical field, unless a different meaning is expressly defined and / or implied from the context of use. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise or clearly implied from the context of use. The operations of any methods and / or procedures disclosed herein do not have to be performed in the exact order disclosed, unless an operation is explicitly described as following or preceding another operation and / or where it is implicit that an operation must follow or precede another operation. Any feature of any embodiment disclosed herein can apply to any other disclosed embodiment, as appropriate. Likewise, any advantage of any embodiment described herein can apply to any other disclosed embodiment, as appropriate.

[0063] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system and can be applied to any communication system that may benefit from them.

[0064] Currently the fifth generation (5G) of cellular systems is being specified within the Third- Generation Partnership Project (3GPP). 5G is developed for maximum flexibility to support a variety of use cases. These include enhanced mobile broadband (eMBB), machine type communications (MTC), ultra-reliable low latency communications (URLLC), side-link device- to-device (D2D), and several other use cases. 5G was first specified in Release 15 (Rel-15) and continues to evolve through subsequent releases.

[0065] At a high level, the 5G System (5GS) includes an access network (AN) and a core network (CN). The AN provides user equipment (UEs) connectivity to the CN, e.g., via RAN nodes such as gNBs or ng-eNBs. The 5G CN (also called “5GC”) uses a service based architecture (SBA) in which network functions (NFs) provide various services to one or more service consumers. This may be done, for example, using Hyper Text Transfer Protocol / Representational State Transfer (HTTP / REST) application programming interfaces (APIs). In general, the various services are self-contained functionalities that can be changed and modified in an isolated manner without affecting other services.

[0066] FIG. 1 shows an exemplary non-roaming reference architecture for a 5G network (100). These include the following 3GPP-defined NFs and SBA interfaces:

[0067] • Application Function (AF, with Naf interface) - interacts with the 5GC to provision information to the network operator and to subscribe to certain events happening in operator's network. An AF offers applications for which service is delivered in a different layer (i.e., transport layer) than the one in which the service has been requested (i.e., signaling layer), the control of flow resources according to what has been negotiated with the network. An AF communicates dynamic session information to PCF (via N5 interface), including description of media to be delivered by transport layer. Alternately, an AF may be located outside of but still interact with the 5GS through NEF (defined below).

[0068] • Policy Control Function (PCF, 120, with Npcf interface) - supports unified policy framework to govern the network behavior, via providing PCC rules (e.g., on the treatment of each service data flow that is under PCC control) to the SMF via the N7 reference point. PCF provides policy control decisions and flow based charging control, including service data flow detection, gating, QoS, and flow-based charging (except credit management) towards the SMF. The PCF receives session and media related information from the AF and informs the AF of traffic (or user) plane events.

[0069] User Plane Function (UPF, 140) - supports handling of user plane traffic based on the rules received from SMF, including packet inspection and different enforcement actions (e.g., event detection and reporting). UPFs communicate with the RAN (170, e.g., NG- RNA) via the N3 reference point, with SMFs (discussed below) via the N4 reference point, and with an external packet data network (PDN) via the N6 reference point. The N9 reference point is for communication between two UPFs.

[0070] • Session Management Function (SMF, 130, with Nsmf interface) - interacts with the decoupled traffic (or user) plane, including creating, updating, and removing Protocol Data Unit (PDU) sessions and managing session context with the User Plane Function (UPF), e.g., for event reporting. For example, SMF performs data flow detection (based on filter definitions included in PCC rules), online and offline charging interactions, and policy enforcement.

[0071] • Charging Function (CHF, with Nchf interface) - responsible for converged online charging and offline charging functionalities. It provides quota management (for online charging), re-authorization triggers, rating conditions, etc. and is notified about usage reports from the SMF. Quota management involves granting a specific number of units (e.g., bytes, seconds) for a service. CHF also interacts with billing systems.

[0072] Access and Mobility Management Function (AMF, 150, with Namf interface) - terminates the RAN CP interface and handles all mobility and connection management of UEs (210). AMFs communicate with UEs via the N1 reference point and with the RAN (e.g., NG-RAN) via the N2 reference point.

[0073] • Network Exposure Function (NEF, 110, with Nnef interface) - acts as the entry point into operator's network, by securely exposing to AFs the network capabilities and events provided by 3GPP NFs and by providing ways for the AF to securely provide information to 3GPP network. For example, NEF provides a service that allows an AF to provision specific subscription data (e g., expected UE behavior) for various UEs.

[0074] • Network Repository Function (NRF, with Nnrf interface) - provides service registration and discovery, enabling NFs to identify appropriate services available from other NFs.

[0075] • Network Slice Selection Function (NSSF, with Nnssf interface) - a “network slice” is a logical partition of a 5G network that provides specific network capabilities and characteristics, e.g., in support of a particular service. A network slice instance is a set of NF instances and the required network resources (e.g., compute, storage, communication) that provide the capabilities and characteristics of the network slice. The NSSF enables other NFs (e.g., AMF) to identify a network slice instance that is appropriate for a UE’s desired service.

[0076] • Authentication Server Function (AUSF, with Nausf interface) - based in a user’s home network (HPLMN), it performs user authentication and computes security key materials for various purposes.

[0077] • Network Data Analytics Function (NWDAF, 160, with Nnwdaf interface) - provides network analytics information (e.g., statistical information of past events and / or predictive information) to other NFs on a network slice instance level.

[0078] • Location Management Function (LMF, with Nlmf interface) - supports various functions related to determination of UE locations, including location determination for a UE and obtaining any of the following: DL location measurements or a location estimate from the UE; UL location measurements from the NG RAN; and non-UE associated assistance data from the NG RAN.

[0079] • Unified Data Management function (UDM, with Nudm interface) -) supports generation of 3GPP authentication credentials, user identification handling, access authorization based on subscription data, and other subscriber-related functions. To provide this functionality, the UDM uses subscription data (including authentication data) stored in the 5GC unified data repository (UDR). In addition, UDR supports storage and retrieval of policy data by the PCF, as well as storage and retrieval of application data by NEF.

[0080] As briefly mentioned above, existing API protection solutions have various problems, issues, and / or difficulties that cause them to provide inadequate protection against runtime API abuse. Some example scenarios that illustrate these problems, issues, and / or difficulties are given below.

[0081] In one example scenario (“A”), a malicious API consumer may seek to cause a negative impact on the Quality of Experience (QoE) of one or more user equipment (UE(s)) or services by misusing a Quality of Service (QoS) on demand (QoD) API. One covert way of doing this is to increase contention for the specific UE or services by increasing priorities of contending flows for other UEs connected to the same cell. This malicious use is stealthy since each individual QoD API call may not be or seem malicious but the totality of API calls has a detrimental effect on QoE for affected UEs / services. In the exploratory phase of such an attack, the attacker may first use location API to determine and / or track when UEs that could contend with the victim UE connect to the same cell as the UE. After a sufficient number of UEs (or a sufficient amount of UE traffic on a specific service) have been identified, the attacker calls the QoD API to increase the priority of some frequently used service on these unknowingly collaborating UEs. The increased contention for prioritized traffic in the cell may cause the victim UE to be traffic starved, especially if it is possible to give the contending traffic flows higher priority through the API calls.

[0082] In another example scenario (“B”), a malicious actor may seek a more general reduction in UE QoE by creating an excessive amount of load for the RAN and / or NFs such as PCF, UDM, SMF, AMF, UPF, etc. One way to accomplish this is to create many requests for QoS handling of traffic with partially invalid identifiers, while another way is to create an excess load of different monitoring tasks. Again, each API call may not be or seem malicious or burdensome but the totality of API calls that are carefully configured to trigger many messages between NFs could create high load situations, which could affect various aspects of UE QoE.

[0083] These two scenarios are only exemplary and other scenarios of API abuse are also possible. An obstacle to detecting and mitigating these types of stealthy and / or multistep attacks is that conventional API security functions have limited awareness of how the API requests affect the NFs serving the requests by performing the requested functionality. Also, these serving NFs typically lack contextual information about the origins of the requests, making attribution of bad outcomes to specific actors difficult.

[0084] Moreover, conventional solutions are typically limited in their ability to correlate API requests through long sequences and across APIs. Furthermore, existing solutions often are deployed as security gateways that API requests need to pass through before reaching the API(s) being protected. Such solutions are often agnostic about the application being protected.

[0085] In contrast, embodiments of the present disclosure may provide a more tailored and / or targeted solution for protection of network exposure APIs. Some embodiments include a new security control for network exposure APIs. This security control takes advantage of increased sharing of information between NFs in the network - in particular between the new security control and various NFs - and the shared information is also used to achieve more domain- semantic awareness. For example, embodiments include communication network (e.g., 5G) domain-specific awareness. Embodiments may improve runtime protection by information sharing (e g., feedback and / or feedforward information). This information sharing, in turn, may enable event correlation (e.g., including sequences of events, and events across APIs), and attribution of bad outcomes (which comes into play in event correlation). Embodiments also provide for targeted mitigation actions to address the requests that are causing the problem.

[0086] Security event correlation techniques have been used conventionally to detect and predict incremental threats such as multi-step or targeted attacks (advanced persistent threats) and other causal sequences of abnormal events. The use of security event correlation techniques also makes it possible to reduce the volume of the original event data stream by grouping events and eliminating event redundancy. Since there are a variety of event correlation techniques, there is a need to choose the most appropriate technique based on the purpose and available resources. The paper "Systematic literature review of security event correlation methods" by I. Kotenko, et al. in IEEE Access 10 (2022):43387-43420 presents a systematization of security event correlation methods into several categories, such as publication year, applied correlation methods, knowledge extraction methods, used data sources, architectural solutions, and quality evaluation of correlation methods.

[0087] As briefly mentioned above, existing protection techniques against runtime abuse are often deployed as a gateway or proxy, in front of the exposed API but only with very limited insight into how the protected system behaves in response to the incoming API requests. For example, gateway-based techniques have very limited awareness about effects of incoming requests have on network resources. On the other hand, embodiments of the present disclosure provide information sharing that facilitates mitigating actions against requests from specific originators (or API consumers) that are misbehaving, even if such requests have already been admitted. For example, in case of abuse of QoD, embodiments may take action to reverse QoD-related reservations of network resources. As another example, in the case of a Denial of Service (DoS) attack, embodiments may shed load specific to those that are causing problems.

[0088] Some embodiments may include an additional security function for providing runtime protection. The security function may interact with NFs that are being protected to provide NF- aware semantic security-handling of API requests. FIG. 2 illustrates a system 200 having a security function 204 according to these embodiments. In particular, the security function 204 is in communication with and operably coupled to an NEF 202 (which, although not shown, may be replaced by an API gateway having corresponding functionality). NEF 202 includes various security-related functions including access control 202a, syntactic filter (e.g., rule-based) 202b, and rate limiting function 202c. Sensor / injector 206 is interposed between the northbound interface (NBI) of NEF 202, and sensor 208 is interposed between the southbound interface (SBI) of NEF 202. Sensor / injector 206 and sensor 208 may each communicate with security function 208 in one-way or two-way communication.

[0089] In the arrangement shown in FIG. 2, security function 204 may be co-located with NEF 202 and the security-related functions in NEF 202. Other alternative arrangements are also possible, such as integrating security function 204 (with its sensor and injector points 206, 208) into NEF 202, or locating security function 204 outside the 5GC in a Security Operations Center (SOC, not shown). Integrating security function 204 into NEF 202 may reduce latency of handling requests, while management aspects of security function 204 would make sense to co-locate with other security management in the SOC. In some embodiments, security function 204 may be supported by a companion application in the NWDAF that assists with data collection and correlation. The following disclosure is based on this arrangement of an NWDAF companion application.

[0090] Some embodiments of security function 204 include an exchange (or sharing) of information with NFs in the communication network (e.g., CN and RAN) that it is protecting. In accordance with these embodiments, FIG. 3 illustrates information flow for scenario A outlined above. Certain reference numbers used in FIG. 2 are also used in FIG. 3. A QoS request from AF 302 is received by NEF 202, which makes a request to the PCF in 5GC 304. The PCF looks up subscription information, makes an authorization check, and signals the SMF in 5GC 304. The SMF sends QoS rules to the UPF in 5GC 304 and to RAN 308 via the AMF in 5GC 304 This signaling is indicated by arrows with circular arrowheads while responses are indicated by arrows with square arrowheads. 5GC 304 and RAN 308 are part of a public land mobile network (PLMN) 306, which may be a 5G network.

[0091] FIG. 4 illustrates detection and mitigation signaling for scenario A described above, according to some embodiments. Certain reference numbers used in FIGS. 2-3 are also used in FIG. 4. Initially, AF 302 sends an API request via NEF 202. Security function 204 stores auxiliary information about the request such as identifiers (IDs) of the request originator and the request itself. Security function 204 analyzes request history (e.g., past requests, including from the same, similar, or related originator) and the current request’s content, and flags the request if determined that it may be suspicious. For example, which requests to flag as “suspicious” may be defined through policies, as described in more detail below. Security function 204 also shares this request information with the companion application in the NWDAF that correlates information from different NFs.

[0092] The NWDAF also receives or retrieves network performance information, such as information about traffic or load that has not been scheduled by the RAN (i.e., starvation due to congestion or outage) and / or missed API requests due to high signaling load. The NWDAF correlates the received network performance information with corresponding API (or exposure) requests and determines whether particular API consumer(s) (e.g., AF 302) has / have a harmful impact on the network. This correlation may be performed according to a rule-based mechanism.

[0093] If API requests causing a harmful impact are by the same API consumer or from a set of untrusted API consumers, the NWDAF can indicate this in feedback to the security function 204. For example, this indication or feedback from NWDAF may include traffic impact information that the NWDAF received from the RAN schedulers. In some variants, security function 204 may subscribe to feedback notifications (or alerts) from the NWDAF about correlated events that suggest attacks and / or API abuse. Based on this indication from the NWDAF, security function 204 may take appropriate action such as sending a feedforward notification (or “hint”) to the PCF (or other NFs) via NEF 202 to mitigate impact of harmful API requests on affected NFs and / or the RAN.

[0094] To summarize the operations shown in FIG. 4, the NWDAF application collects information about consumer API calls from NEF and traffic scheduling from RAN, correlates the collected information, and provides feedback on network status to the security function 204. Upon detection of a security condition, the security function 204 provides feedforward “hints” for NFs to take mitigating actions.

[0095] FIG. 5 illustrates a sequence diagram according to some embodiments. Certain reference numbers used in FIGS. 2-3 are also used in FIG. 5. In operation 1, as security function 204 is started up, it provisions correlation (or detection) rules to NWDAF 502.

[0096] FIG. 6 illustrates a sequence diagram according to some embodiments. In particular, FIG. 6 shows a simplified diagram for the detection of abuse in Scenario A, which involves the QoD API. However, the principles illustrated by FIG. 6 are equally applicable to other APIs. Certain reference numbers used in FIGS. 2-5 are also used in FIG. 6. As shown, NEF 602, PCF 604, SMF 606, UPF 608, AMF 610, gNB 612, NWDAF 502, and security function 204 are in communication with each other.

[0097] To summarize the operations in FIG. 6 at a high level, information is shared from NEF 602 to the application in the NWDAF 502 about API requests. Once normal signaling is completed and User Plane (UP) traffic is flowing, information is collected from RAN nodes, including the gNB scheduler state. The NWDAF 502 application correlates the received information and may trigger a notification to the security function 204 if certain steps are detected.

[0098] The operations shown in FIG. 6 are described in more detail below. Although the operations shown in FIG. 6 are given numerical labels, this is done to facilitate the following explanation rather than to require or imply any particular operational order, unless expressly stated otherwise. Some of the messages indicated here may be described further in 3GPP Technical Specifications (TS) 23.502, 29.512, 29.514, and / or other applicable standards.

[0099] In operation 1, NEF 602 receives an API request, which is shown as an Nnef_AFsessionWithQoS request. The API request may be from an AF 302. In operation 2, NEF 602 sends an Npcf_PolicyAuthorization_Create request to PCF 604 in response to the API request received at operation 1. In operation 3, NEF 602 sends information about the API request to NWDAF 502. The API request information may be pushed to NWDAF 502 or may be pulled by NWDAF 502 (e.g., from logs). NWDAF 502 may use this information to perform its correlation function as described elsewhere herein. In operation 4, NEF 602 responds with an Nnef AFsessionWithQoS response to the AF 302 who initiated the request in operation 1. In operation 5, PCF 604 sends an Npcf_SMPolicyControl_UpdateNotify request to SMF 606. In operation 6, SMF 606 sends anN4 Session Modification Request to UPF 608. In operation 7, UPF 608 sends an N4 Session Modification Response to SMF 606. In operation 8, SMF 606 sends an NlN2MessageTransfer to AMF 610.

[0100] In operation 9, AMF 610 sends an N2 message to gNB 612. In operation 10, gNB 612 sends a response to AMF 610. In operation 11, AMF 610 sends a response to SMF 606. In operation 12, SMF 606 sends a Npcf_SMPolicyControl_UpdateNotify response to PCF 604. In operation 13, PCF 604 sends aNpcf_PolicyAuthorization_Create response to NEF 602.

[0101] In operation 14, during UP traffic, gNB 612 sends information from the radio scheduler to NWDAF 502. The scheduler information may be pushed to NWDAF 502 or may be pulled by NWDAF 502 (e.g., from logs). The scheduler information may include information about network performance, such as carried traffic vs. offered traffic.

[0102] In operation 15, NWDAF 502 performs correlation as described elsewhere herein. For example, NWDAF 502 uses the received scheduler information to correlate network performance issues to particular API requests and / or consumers that originate such API requests. In operation 16, NWDAF 502 notifies security function 204 of the result of its correlation. Security function 204 may, in response to the notification, take preventative measures, including sending hints to appropriate NFs to inform the NFs about the possible abuse, such as described below.

[0103] FIG. 7 illustrates a decision process for scenario A according to some embodiments. In particular, FIG. 7 shows sub-processes 700 and 710, both for the NWDAF application.

[0104] Sub-process 700 will be described first. In operation 702, an API request is received. In operation 704, the received API request is stored.

[0105] Sub-process 710 will now be described. In operation 712, scheduler information is received. This may include scheduler information from the gNB in the RAN. In operation 714, this received information is analyzed to determine whether a UE faces severe shortage (being “starved”) in getting its traffic scheduled.

[0106] If this is determined not to be the case (“no”), sub-process 710 proceeds to completion in operation 722. If this is determined to be the case (“yes”), sub-process 710 proceeds to operation 716 where the received information is further analyzed to determine if the issue was preceded by many location requests through exposure API (information from NEF).

[0107] If this is determined not to be the case (“no”), sub-process 710 proceeds to completion in operation 722. If this is determined to be the case (“yes”), sub-process 710 proceeds to operation 718 where it is determined whether QoS (re)mappings to high priority were performed for traffic related to the UEs in the vicinity of (e.g., same cell as) the UE experiencing traffic starvation.

[0108] If this is determined not to be the case (“no”), sub-process 710 proceeds to completion in operation 722. If this is determined to be the case (“yes”), sub-process 710 proceeds to operation 720 where the NWDAF application notifies the security function that a sequence of events indicating API abuse has occurred, along with identifiers (IDs) of the API consumers) originating the problematic requests and of the problematic requests themselves.

[0109] Sub-process 710 may be a result of the NWDAF having been provided with correlation rules (e g., FIG. 5), it may be hard-coded into the NWDAF, or the NWDAF may determine the decision process in some other way Other decision processes, including other correlation rules, are also within the scope of disclosed embodiments.

[0110] Upon receipt of the notification of abuse, the security function may provide feedforward indications (e.g., recommendations or “hints”) for mitigating actions. FIG. 8 shows a sequence diagram according to some embodiments. In particular, FIG. 8 illustrates mitigation interactions following detection of Scenario A. Certain reference numbers used in FIGS. 2-6 are also used in FIG. 8. At a high level, security function 204 sends hints through the NEF 602 to affected NFs to indicate that conditions have been detected that are likely caused by incoming requests through the exposure API, and provides information on which requests were involved and / or what action to take. In this case, for scenario A, the relevant request IDs are provided to the PCF 604, and the PCF 604 can choose to cancel those QoS reservations for targeted mitigation.

[0111] The operations shown in FIG. 8 are outlined below. Although the operations shown in FIG. 8 are given numerical labels, this is done to facilitate the following explanation rather than to require or imply any particular operational order, unless expressly stated otherwise. Some of the messages indicated here are described further in 3GPP Technical Specifications (TS) 23.502, 29.512, 29.514, and / or other applicable standards.

[0112] In operation 1, security function 204 sends a notification to NEF 602. The notification includes a report of possible API abuse, and the corresponding API consumer and request IDs associated with the possible abuse. NEF 602 may use this information to take action itself or to further alert appropriate NFs of the possible abuse as described herein.

[0113] In operation 2, NEF 602 provides a hint to PCF 604. The hint may include the same information received from the security function 204, and may also include other information from the NEF 602. In operation 3, PCF 604 may make a policy-based decision on whether to take action. For example, PCF 604 may decide to ignore the possible abuse by the API consumer, or may alternatively decide to take some mitigating action to correct the abuse and / or prevent further abuse, such as operations 4-12 shown within a conditional block. In operation 4, PCF 604 sends an Npcf SMPolicyControl UpdateNotify request to SMF 606. In operation 5, SMF 606 sends an N4 Session Modification Request to UPF 608. In operation 6, UPF 608 sends an N4 Session Modification Response to SMF 606. In operation 7, SMF 606 sends an NlN2MessageTransfer to AMF 610. In operation 8, AMF 610 sends an N2 message to gNB 612.

[0114] In operation 9, gNB 612 sends a response to AMF 610. In operation 10, AMF 610 sends a response to SMF 606. In operation 11, SMF 606 sends a Npcf_SMPolicyControl_UpdateNotify response to PCF 604. In operation 12, PCF 604 sends the mitigation action taken to security function 204. Security function 204 may use this information as it continues to process and analyze API requests for possible abuse as described herein. In operation 13, PCF 604 sends a Npcf_PolicyAuthorization_Create response to NEF 602.

[0115] FIGS. 9 and 10 described below show corresponding interaction diagrams for a variant of scenario B where many QoS subscription requests are made to the system to generate high control plane load. Here, API requests and NF load conditions are shared with the application in NWDAF. Correlation is performed similarly as previously described, and mitigation actions can be triggered to perform targeted shedding of load related to the API consumer identified to be the cause of the high load. In this case, the first mitigation step is to let the affected NF, e.g., the PCF, know which load to shed to handle the overload condition (FIG. 10). The NEF could also, depending on policy, prevent the condition before the load reaches the core by specifically rate limiting the originating API consumer.

[0116] In particular, FIG. 9 shows simplified API abuse detection interactions for scenario B, according to some embodiments. Certain reference numbers used in FIGS. 2-6 are also used in FIG. 9. Note that as shown at the leftmost side of the figure, there are many requests arriving at the NEF 602. Four arrows are used to indicate this, but there may be fewer than four request, or more than four requests, and in general, there may be many more than four requests. To facilitate clarity, the resulting messages have been drawn as a single thicker arrow in the rest of the diagram, with each message corresponding to an individual API request.

[0117] The operations shown in FIG.9 are outlined below. Although the operations shown in FIG. 9 are given numerical labels, this is done to facilitate the following explanation rather than to require or imply any particular operational order, unless expressly stated otherwise. Some of the messages indicated here are described further in 3GPP TS 23.502, 29.512, 29.514, and / or other applicable standards.

[0118] In operation 1, NEF 602 receives an API request, which is shown as an Nnef_AFsessionWithQoS request. The API request may be from AF 302. In operation 2, NEF 602 sends an Npcf Policy Authorization Create request to PCF 604 in response to the API request received at operation 1.

[0119] In operation 3, NEF 602 sends information about the API request to NWDAF 502. The API request information may be pushed to NWDAF 502 or may be pulled (e.g., from logs). NWDAF 502 may use this information to perform its correlation function as described herein. In operation 4, NEF 602 responds with an Nnef_AFsessionWithQoS response to the AF 302 who initiated the request in operation 1.

[0120] In operation 5, PCF 604 sends NF load information to NWDAF 502. The NF load information may be pushed to NWDAF 502 or may be pulled. NWDAF 502 may use this information to perform its correlation function as described elsewhere herein. In operation 6, PCF 604 sends an Npcf_SMPolicyControl_UpdateNotify request to SMF 606.

[0121] In operation 7, SMF 606 sends NF load information to NWDAF 502. The NF load information may be pushed to NWDAF 502 or may be pulled. NWDAF 502 may use this information to perform its correlation function as described elsewhere herein. In operation 8, SMF 606 sends an N4 Session Modification Request to UPF 608. In operation 9, UPF 608 sends NF load information to NWDAF 502. The NF load information may be pushed to NWDAF 502 or may be pulled. NWDAF 502 may use this information to perform its correlation function as described herein.

[0122] In operation 10, UPF 608 sends an N4 Session Modification Response to SMF 606. In operation 11, SMF 606 sends an NlN2MessageTransfer to AMF 610. In operation 12, AMF 610 sends NF load information to NWDAF 502. The NF load information may be pushed to NWDAF 502 or may be pulled. NWDAF 502 may use this information to perform its correlation function as described herein.

[0123] In operation 13, AMF 610 sends an N2 message to gNB 612. In operation 14, gNB 612 sends NF load information to NWDAF 502. The NF load information may be pushed to NWDAF 502 or may be pulled. NWDAF 502 may use this information to perform its correlation function as described herein. In operation 15, gNB 612 sends a response to AMF 610. In operation 16, AMF 610 sends a response to SMF 606.

[0124] In operation 17, SMF 606 sends aNpcf_SMPolicyControl_UpdateNotify response to PCF 604. In operation 18, PCF 604 sends a Npcf_PolicyAuthorization_Create response to NEF 602. In operation 19, NWDAF 502 performs correlation as described elsewhere herein. For example, NWDAF 502 uses the information it has collected to correlate bad network conditions to particular API requests and / or consumers that originate such API requests.

[0125] In operation 20, NWDAF 502 notifies security function 204 of the result of its correlation. Security function 204 may, in response to the notification, take preventative measures, including sending hints to appropriate NFs to inform the NFs about the possible abuse, such as described herein.

[0126] In addition, FIG. 10 shows a sequence diagram of mitigation interactions following detection of overload condition in PCF for scenario B, according to some embodiments. Certain reference numbers used in FIGS. 2-6 are also used in FIG. 10.

[0127] The operations shown in FIG.10 are outlined below. Although the operations shown in FIG. 10 are given numerical labels, this is done to facilitate the following explanation rather than to require or imply any particular operational order, unless expressly stated otherwise. Some of the messages indicated here are described further in 3GPP TS 23.502, 29.512, 29.514, and / or other applicable standards.

[0128] In operation 1 , security function 204 sends a notification to NEF 602. The notification may include an indication of possible abuse and an identifier of the corresponding API consumer. In operation 2, NEF 602 sends a hint to PCF 604. The hint may include the same information received from the security function 204, and may also include other information generated by the NEF 602.

[0129] In operation 3, PCF 604 performs overload control targeted load shedding, e.g., using the provided information in step 2 that indicates which requests (or API consumer’s requests) to target. For example, PCF 604 may start rejecting requests to keep latency low for the requests it has accepted and continues to accept. The shedding may be targeted, e.g., so that it rejects requests from API consumers that have been flagged as being possible abusers. In operation 4, PCF 604 sends the mitigation action taken to the security function 204.

[0130] In some embodiments and variants, service / node / NF availability monitoring may also be performed in a similar manner as discussed above for scenario B. For example, such monitoring may be added as an extension to scenario B. This may be beneficial to avoid excess load that would cause a service / node / NF to fail or crash.

[0131] As discussed above, there are several noteworthy characteristics of exposure API abuse. For example, abuse through the exposure interface may involve a sequence of one or more calls to network APIs of same / different types. Additionally, these calls can happen over a period of time. These sequences of calls can result in negative effects for subscribers at the user plane (e g., QoD application starvation) or undesirable control plane effects (e.g., network node CPU / memory / signaling overload). Even so, the individual events seen above - i.e. API requests through exposure and the negative effects seen in the network - can appear to be a part of normal network behavior if the originator of the requests has valid credentials.

[0132] In order to detect such exposure API abuse, there needs to be awareness of abuse patterns at the application layer that may not be obvious by looking at individual events. Therefore, in some embodiments, an NWDAF companion application continuously monitors events over a period of time and correlates the occurrence of these events with an understanding of telco semantics and business context. These events can be of different types, such as any of the following:

[0133] • Requests for services over network exposure;

[0134] • Network events (e.g. traffic starvation for a user, cell, etc.);

[0135] • Responses generated by the network for incoming API requests;

[0136] • Events relating to statistical measures (e g. threshold for number of failures for allocating QoD subscriptions has been hit);

[0137] • Network node level events (e.g. NF memory / CPU / signaling overload, etc.); and

[0138] • API invoker level events (e g., change of API invoker origin IP).

[0139] In some embodiments, a security policy can be used to specify known abuse patterns (or indicators of attack) to look for, with the security policy being provisioned to the companion NWDAF application that performs event correlation (see FIG. 5). For example, security policies may be defined to identify “suspicious” requests such as those that are similar to previous requests (e.g., same originating AF and same type, etc.) and have resulted in high NF load and / or alerts of possible abuse (from the security function itself, or from NWDAF companion function.) As another example, security policies may be defined to identify patterns of known misuse / abuse, such as from the top-10 API security risks identified by OWASP (https: / / owasp.org). Some specific examples of these top- 10 API security risks include repeated attempts to brute force (guess) identifiers for a broken object level authorization (BOLA) vulnerability and information scraping. Alternatively, there could be a weaker indication of suspiciousness, such as repeated similar requests at an unusually high rate.

[0140] The NWDAF application in this case would monitor for the occurrence of these specified abuse pattems / events and may use known event correlation mechanisms to determine whether an attack has occurred and signal an alert back to the security function (see FIGS. 6-9). In other embodiments, the security function performs this event correlation itself by using information provided from network feedback for events relating to network events (e.g. traffic starvation) and network node level events (e g. NF overload).

[0141] In some embodiments, the subscriber / consumer can flag a UE to be a ‘sensitive UE’ requiring protection from the security function via a management interface / API. For instance, a drone or a healthcare related UE (e.g., patient support / monitor) running QoD reliant critical applications can be examples. In this case, the security function policy may specify certain additional abuse patterns to look for involving the presence of these ‘sensitive UE’s for instance, additional checks for location monitoring requests for sensitive UEs, changes to QoD subscriptions relating to these sensitive UEs, etc. This can in some instances increase confidence in the detection results and reduce incidence of false positive alerts.

[0142] FIG. 11 shows an example of specifying abuse patterns as a policy JavaScript Object Notation (JSON) in the security function, according to some embodiments. This may be provisioned to the NWDAF companion application. In particular, FIG. 11 shows a specified “event chain” that specifies a set of unique abuse pattern indicators to look for in the API environment. These patterns are populated by using domain understanding of the communication network and API exposure behavior, and may be customized by the operator using a management interface to the security function.

[0143] The abuse patterns are composed of different types of events to look for in the environment. Examples include network events such as traffic starvation, node level events such as overload, etc. The abuse patterns can also be specified using various logical operators (e.g., AND, OR, etc.), comparison operators (e.g., greater than, less than, etc.), mathematical operators (e.g., PLUS), and / or expression-type operators as part of the specified policy, along with any other relevant rules.

[0144] In some embodiments, the policy may also specify the action to be taken by the security function when an abuse pattern is detected in the environment. For instance, for the first abuse pattern with ruleid=l in FIG. 11, the recommended action is to remap priorities of offending flows. In some embodiments, the policy may also specify the information to be sent in the feedforward message to the network from the security function. For example, in the abuse pattern with ruleid=2 in FIG. 11, the ‘data_shared_with_nf property specifies that the feedforward information includes the ‘suspicious_subscription_list’ which is the list of QoD subscriptions set up by suspicious API consumers. This information can be used by the CN nodes to selectively shed load from these consumers.

[0145] In some embodiments and variants, anomalous user data exposure may also be captured by a policy similar to the one described in relation to FIG. 11. For example, there may be a misuse detection policy that looks for API recon activity followed by data gathering for a number of users (e.g., iterating on different user IDs) by repeated enquiries to the UDM.

[0146] The information sharing discussed in the present disclosure may be performed in various ways. For example, the information sharing could be done using standardized messages, by gathering information from logs, or by some mixture of these actions.

[0147] The embodiments described above can be further illustrated with reference to FIGS. 12- 13, which depict exemplary methods (e.g., procedures) for a security function and an NWDAF, respectively. Put differently, various features of the operations described below correspond to various embodiments described above. The exemplary methods shown in FIGS. 12-13 can be complementary to each other such that they can be used cooperatively to provide benefits, advantages, and / or solutions to problems described herein. Although the exemplary methods are illustrated in FIGS. 12-13 by specific blocks in particular orders, the operations corresponding to the blocks can be performed in different orders than shown and can be combined and / or divided into operations having different functionality than shown. Optional blocks and / or operations are indicated by dashed lines.

[0148] More specifically, FIG. 12 illustrates an exemplary method (1200) for a security function of a communication network, according to various embodiments of the present disclosure. The exemplary method shown in FIG. 12 can be performed by any appropriate security function (or network equipment configured to implement such function) such as described elsewhere herein.

[0149] The exemplary method includes the operations of block 1230, where the security function determines that API requests from one or more consumers have degraded performance of the communication network. The API requests are via a network exposure function (NEF) of the communication network. The security function also determines at least one recommended action to mitigate the degraded performance due to the API requests. The exemplary method also includes the operations of block 1240, where the security function sends, to one or more network functions (NFs) of the communication network, an indication of the at least one recommended action.

[0150] In some embodiments, determining that API requests from one or more consumers have degraded performance of the communication network in block 1230 includes the following operations, labelled with corresponding sub-block numbers:

[0151] • (1231) receiving the following information from the NEF for each of a plurality of API requests from a plurality of different consumers: an identifier of the consumer making the API request, and an identifier of the API request;

[0152] • (1232) receiving network performance information from one or more of the following of the communication network: a radio access network (RAN), and at least one NF;

[0153] • (1233) correlating the received network performance information with the information received from the NEF, thereby obtaining correlated information; and

[0154] • (1234) detecting, based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network.

[0155] In some of these embodiments, the network performance information includes one or more of the following:

[0156] • processing load information for the at least one NF ; • processing load information for one or more network nodes of the communication network;

[0157] • RAN traffic scheduling information; and

[0158] • performance information related to handling of API requests and corresponding responses.

[0159] In other embodiments, determining that API requests from one or more consumers have degraded performance of the communication network in block 1230 includes the operations of sub-block 1235, where the security function receives the following information from a network data analytics function (NWDAF) of the communication network:

[0160] • an indication that API requests from one or more consumers have degraded performance of the communication network, and

[0161] • respective identifiers of the one or more consumers.

[0162] In such embodiments, the at least one recommended action is determined based on the received information.

[0163] In some of these embodiments, the exemplary method also includes the operations of block 1220, where the security function sends to the NWDAF one or more rules for detecting degraded performance of the communication network due to API requests. The information received from the NWDAF in sub-block 1235 is based on the one or more rules.

[0164] In some of these embodiments, the information received from the NWDAF also includes one or more of the following: identifiers of the API requests that have degraded performance, and RAN traffic scheduling information that indicates the degraded performance. In some variants of these embodiments, the information received from the NWDAF includes at least one of the following:

[0165] • a plurality of identifiers of respective different consumers whose API requests have degraded performance; and

[0166] • a plurality of identifiers of a plurality of different API requests that have degraded performance.

[0167] In other variants of these embodiments, the RAN traffic scheduling information indicates one or more of the following:

[0168] • one or more cells of the communication network, in which performance has been degraded;

[0169] • a portion of offered traffic in the one or more cells that has not been scheduled; and

[0170] • identifiers of one or more user equipment (UEs) operating in the one or more cells, whose traffic has been prioritized. In some of these embodiments, the exemplary method also includes the operations of block 1210, where the security function sends to the NWDAF a subscription for notifications of degraded network performance due to API requests. The information is received from the NWDAF in sub-block 1235 based on the subscription.

[0171] In some of the embodiments described above, the degraded performance includes reduced capacity in a cell of the communication network for traffic associated with one or more UEs due to traffic associated with other UEs operating in the cell. For example, the one or more UEs may be “starved” or “blocked” by the other UEs. Also, the one or more rules include the following: a first number of API requests related to location tracking of the one or more UEs, and a second number of API requests related to increased prioritization of the traffic associated with the other UEs. In some variants of these embodiments, the at least one recommended action to mitigate the degraded performance due to the API requests includes decreasing prioritization of traffic for or from the other UEs. Note that “ruleid”: l in FIG. 11 shows an example of such rules and recommended action.

[0172] In other of the embodiments described above, the degraded performance includes excessive processing load on at least one NF of the communication network. Also, the one or more rules include at least one of the following: a first number of API requests related to network monitoring, and a second number of API requests that resulted in failed setup of quality - of-service on demand (QoD) flows. In some variants of these embodiments, the at least one recommended action to mitigate the degraded performance due to the API requests includes shedding traffic load associated with the one or more consumers whose API requests have degraded performance. Also, the indication of the at least one recommended action includes one or more of the following: the identifiers of the one or more consumers, and identifiers of the API requests that have degraded performance. Note that “ruleid”:2 in Figure 11 shows an example of such rules and recommended action.

[0173] In some embodiments, the indication is sent in block 1240 to the NEF. In other embodiments, the indication is sent in block 1240 to a policy control function (PCF) via the NEF. In some of these embodiments, the exemplary method also includes the operations of block 1250, where the security function receives one of the following from the PCF: a confirmation that the at least one recommended action was taken, or an indication of another action taken to mitigate the degraded performance due to the API requests.

[0174] In addition, FIG. 13 illustrates an exemplary method (1300) for an NWDAF of a communication network, according to various embodiments of the present disclosure. The exemplary method shown in FIG. 13 can be performed by any appropriate NWDAF (or network equipment configured to implement such function) such as described elsewhere herein. The exemplary method includes the operations of block 1330, where for each of a plurality of API requests from a plurality of different consumers, the NWDAF receives the following information from a network exposure function (NEF) of the communication network: an identifier of the consumer making the API request, and an identifier of the API request. The exemplary method also includes the operations of block 1340, where the NWDAF receives network performance information from one or more of the following of the communication network: a RAN, and at least one NF.

[0175] The exemplary method also includes the operations of block 1350, where the NWDAF correlates the received network performance information with the information received from the NEF, thereby obtaining correlated information. The exemplary method also includes the operations of block 1360, where the NWDAF detects, based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network. The exemplary method also includes the operations of block 1370, where the NWDAF sends the following information to a security function of the communication network: an indication that API requests from one or more consumers have degraded performance of the communication network, and respective identifiers of the one or more consumers.

[0176] In some embodiments, the network performance information includes one or more of the following:

[0177] • processing load information for the at least one NF ;

[0178] • processing load information for one or more network nodes of the communication network;

[0179] • RAN traffic scheduling information; and

[0180] • performance information related to handling of API requests and corresponding responses.

[0181] In some embodiments, the exemplary method also includes the operations of block 1320, where the NWDAF receives the one or more rules from the security function.

[0182] In some embodiments, the information sent to the security function also includes one or more of the following: identifiers of the API requests that have degraded performance, and RAN traffic scheduling information that indicates the degraded performance. In some of these embodiments, the information sent to the security function includes at least one of the following:

[0183] • a plurality of identifiers of respective different consumers whose API requests have degraded performance; and

[0184] • a plurality of identifiers of a plurality of different API requests that have degraded performance. In other of these embodiments, the RAN traffic scheduling information indicates one or more of the following:

[0185] • one or more cells of the communication network, in which performance has been degraded;

[0186] • a portion of offered traffic in the one or more cells that has not been scheduled; and

[0187] • identifiers of one or more user equipment (UEs) operating in the one or more cells, whose traffic has been prioritized.

[0188] In some embodiments, the exemplary method also includes the operations of block 1310, where the NWDAF receives from the security funebon a subscription for notifications of degraded network performance due to API requests. The information is sent to the security function in block 1370 based on the subscription.

[0189] In some embodiments, the degraded performance includes reduced capacity in a cell of the communication network for traffic associated with one or more UEs due to traffic associated with other UEs in the cell. For example, the one or more UEs may be “starved” or “blocked” by the other UEs. In such embodiments, the one or more rules include the following: a first number of API requests related to location tracking of the one or more UEs, and a second number of API requests related to increased prioritization of the traffic associated with the other UEs. In some of these embodiments, at least one recommended action to mitigate the degraded performance due to the API requests includes decreasing prioritization of traffic for or from the other UEs. Note that “ruleid”: 1 in FIG. 11 shows an example of such rules and recommended action.

[0190] In other embodiments, the degraded performance includes the degraded performance includes excessive processing load on at least one NF of the communication network. In such case, the one or more rules include at least one of the following: a first number of API requests related to network monitoring, and a second number of API requests that resulted in failed setup of quality-of-service on demand (QoD) flows. In some of these embodiments, the at least one recommended action to mitigate the degraded performance due to the API requests includes shedding traffic load associated with the one or more consumers whose API requests have degraded performance, and the indication of the at least one recommended action includes one or more of the following: the identifiers of the one or more consumers, and identifiers of the API requests that have degraded performance. Note that “ruleid”:2 in FIG. 11 shows an example of such rules and recommended action.

[0191] FIG. 14 is a block diagram of apparatus 1400 according to some embodiments. In some variants, apparatus 1400 may be configured as a security function to perform operations of the exemplary method shown in FIG. 12 or other operations attributed to a security function in various embodiments described above. In other variants, apparatus 1400 may be configured as an NWDAF to perform operations of the exemplary method shown in FIG. 13 or other operations attributed to an NWDAF in various embodiments described above.

[0192] As shown in FIG. 14, apparatus 1400 may comprise: processing circuitry (PC) 1402, which may include one or more processors (P) 1455 (e.g., a general purpose microprocessor and / or one or more other processors, such as an application specific integrated circuit (ASIC), field- programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., apparatus 1400 may be a distributed computing apparatus); at least one network interface 1448 comprising a transmitter (Tx) 1445 and a receiver (Rx) 1447 for enabling apparatus 1400 to transmit data to and receive data from other nodes connected to a network 1410 (e.g., an Internet Protocol (IP) network) to which network interface 1448 is connected (directly or indirectly) (e.g., network interface 1448 may be wirelessly connected to the network 1410, in which case network interface 1448 is connected to an antenna arrangement); and a storage unit (a.k.a., “data storage system”) 1408, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. Interface 1460 may connect PC 1402 and storage unit 1408, interface 1462 may connect PC 1402 and network interface 1448, and interface 1464 may connect network interface 1448 and network 1410. In embodiments where PC 1402 includes a programmable processor, a computer program product (CPP) 1441 may be provided. CPP 1441 includes a computer readable medium (CRM) 1442 storing a computer program (CP) 1443 comprising computer readable instructions (CRI) 4344. CRM 1442 may be anon-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 1444 of computer program 1443 is configured such that when executed by PC 1402, the CRI causes apparatus 1400 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus 1400 may be configured to perform steps described herein without the need for code. That is, for example, PC 1402 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0193] FIG. 15 shows an example of a communication system 1500 in accordance with some embodiments. In this example, communication system 1500 includes a telecommunication network 1502 that includes an access network 1504 (e.g., RAN) and a core network 1506, which includes one or more core network nodes 1508. Access network 1504 includes one or more access network nodes, such as network nodes 1510a-b (one or more of which may be generally referred to as network nodes 1510), or any other similar 3GPP access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, telecommunication network 1502 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in telecommunication network 1502 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in telecommunication network 1502, including one or more network nodes 1510 and / or core network nodes 1508.

[0194] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e. g. , rApp), or any combination thereof (the adj ective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. Network nodes 1510 facilitate direct or indirect connection of UEs, such as by connecting UEs 1512a-d (one or more of which may be generally referred to as UEs 1512) to core network 1506 over one or more wireless connections.

[0195] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 1500 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. Communication system 1500 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system. UEs 1512 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with network nodes 1510 and other communication devices. Similarly, network nodes 1510 are arranged, capable, configured, and / or operable to communicate directly or indirectly with UEs 1512 and / or with other network nodes or equipment in telecommunication network 1502 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in telecommunication network 1502.

[0196] In the depicted example, core network 1506 connects network nodes 1510 to one or more hosts, such as host 1516. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1506 includes one or more core network nodes (e.g., 1508) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of core network node 1508. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0197] Host 1516 may be under the ownership or control of a service provider other than an operator or provider of access network 1504 and / or telecommunication network 1502, and may be operated by the service provider or on behalf of the service provider. Host 1516 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server

[0198] As a whole, communication system 1500 of FIG. 15 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0199] In some examples, telecommunication network 1502 is a cellular network that implements 3GPP standardized features. Accordingly, telecommunication network 1502 may support network slicing to provide different logical networks to different devices that are connected to telecommunication network 1502. For example, telecommunication network 1502 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0200] In some examples, UEs 1512 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to access network 1504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from access network 1504. Additionally, a UE may be configured for operating in single- or multi-RAT or multi -standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0201] In the example, hub 1514 communicates with access network 1504 to facilitate indirect communication between one or more UEs (e.g., 1512c and / or 1512d) and network nodes (e.g., 1510b). In some examples, hub 1514 may be a controller, router, content source and analytes, or any of the other communication devices described herein regarding UEs. For example, hub 1514 may be a broadband router enabling access to core network 1506 for the UEs. As another example, hub 1514 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1510, or by executable code, script, process, or other instructions in hub 1514. As another example, hub 1514 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, hub 1514 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, hub 1514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which hub 1514 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, hub 1514 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices. Hub 1514 may have a constant / persistent or intermittent connection to network node 1510b. Hub 1514 may also allow for a different communication scheme and / or schedule between hub 1514 and UEs (e.g., 1512c and / or 1512d), and between hub 1514 and core network 1506. In other examples, hub 1514 is connected to core network 1506 and / or one or more UEs via a wired connection. Moreover, hub 1514 may be configured to connect to an M2M service provider over access network 1504 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with network nodes 1510 while still connected via hub 1514 via a wired or wireless connection. In some embodiments, hub 1514 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to network node 1510b. In other embodiments, hub 1514 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1510b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0202] In some embodiments, core network node 1508 or host 1516 may be configured to perform operations attributed to a security function in various methods or procedures described above, including the exemplary method shown in FIG. 12. In some embodiments, core network node 1508 may be configured to perform operations attributed to an NWDAF in various methods or procedures described above, including the exemplary method shown in FIG. 13.

[0203] FIG. 16 shows a network node 1600 in accordance with some embodiments. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (e.g., radio base stations, Node Bs, eNBs, gNBs), and O-RAN nodes or components of an O-RAN node (e g., O-RU, O-DU, O-CU).

[0204] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0205] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base starion controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0206] Network node 1600 includes processing circuitry 1602, memory 1604, communication interface 1606, and power source 1608. Network node 1600 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which network node 1600 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, network node 1600 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1604 for different RATs) and some components may be reused (e.g., a same antenna 1610 may be shared by different RATs). Network node 1600 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1600, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1600.

[0207] Processing circuitry 1602 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1600 components, such as memory 1604, to provide network node 1600 functionality.

[0208] In some embodiments, processing circuitry 1602 includes a system on a chip (SOC). In some embodiments, processing circuitry 1602 includes one or more of radio frequency (RF) transceiver circuitry 1612 and baseband processing circuitry 1614. In some embodiments, RF transceiver circuitry 1612 and baseband processing circuitry 1614 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1612 and baseband processing circuitry 1614 may be on the same chip or set of chips, boards, or units.

[0209] Memory 1604 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by processing circuitry 1602. Memory 1604 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions (collectively denoted computer program 1604a, which may be in the form of a computer program product) capable of being executed by processing circuitry 1602 and utilized by network node 1600. Memory 1604 may be used to store any calculations made by processing circuitry 1602 and / or any data received via communication interface 1606. In some embodiments, processing circuitry 1602 and memory 1604 is integrated.

[0210] Communication interface 1606 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, communication interface 1606 comprises port(s) / terminal(s) 1616 to send and receive data, for example to and from a network over a wired connection. Communication interface 1606 also includes radio frontend circuitry 1618 that may be coupled to, or in certain embodiments a part of, antenna 1610. Radio front-end circuitry 1618 comprises filters 1620 and amplifiers 1622. Radio front-end circuitry 1618 may be connected to an antenna 1610 and processing circuitry 1602. The radio front-end circuitry may be configured to condition signals communicated between antenna 1610 and processing circuitry 1602. Radio front-end circuitry 1618 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1 18 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1620 and / or amplifiers 1622. The radio signal may then be transmitted via antenna 1610. Similarly, when receiving data, antenna 1610 may collect radio signals which are then converted into digital data by radio front-end circuitry 1618. The digital data may be passed to processing circuitry 1602. In other embodiments, the communication interface may comprise different components and / or different combinations of components

[0211] In certain alternative embodiments, network node 1600 does not include separate radio front-end circuitry 1618, instead, processing circuitry 1602 includes radio front-end circuitry and is connected to antenna 1610. Similarly, in some embodiments, all or some of RF transceiver circuitry 1612 is part of communication interface 1606. In still other embodiments, communication interface 1606 includes one or more ports or terminals 1616, radio front-end circuitry 1618, and RF transceiver circuitry 1612, as part of a radio unit (not shown), and communication interface 1606 communicates with baseband processing circuitry 1614, which is part of a digital unit (not shown).

[0212] Antenna 1610 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. Antenna 1610 may be coupled to radio front-end circuitry 1618 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, antenna 1610 is separate from network node 1600 and connectable to network node 1600 through an interface or port.

[0213] Antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0214] Power source 1608 provides power to the various components of network node 1600 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 1608 may further comprise, or be coupled to, power management circuitry to supply the components of network node 1600 with power for performing the functionality described herein. For example, network node 1600 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of power source 1608. As a further example, power source 1608 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The batteiy may provide backup power should the external power source fail.

[0215] Embodiments of network node 1600 may include additional components beyond those shown in FIG. 16 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1600 may include user interface equipment to allow input of information into network node 1600 and to allow output of information from network node 1600. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 1600.

[0216] In some embodiments, network node 1600 may be configured to perform operations attributed to a security function in various methods or procedures described above, including the exemplary method shown in FIG. 12. In some embodiments, network node 1600 may be configured to perform operations attributed to an NWDAF in various methods or procedures described above, including the exemplary method shown in FIG. 13.

[0217] FIG. 17 is a block diagram illustrating a virtualization environment 1700 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1700 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1700 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0218] Applications 1702 (which may alternatively be called software instances, virtual appliances, network funebons, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1700 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. For example, one or more virtual nodes 1702 may be configured to perform operations atributed to a security function in various methods or procedures described above, including the exemplary method shown in FIG. 12. Likewise, one or more virtual nodes 1702 may be configured to perform operations atributed to an NWDAF in various methods or procedures described above, including the exemplary method shown in FIG. 13.

[0219] Hardware 1704 includes processing circuitry, memoiy that stores software and / or instructions (collectively denoted computer program 1704a, which may be in the form of a computer program product) executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1706 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1708a- 1708b (one or more of which may be generally referred to as VMs 1708), and / or perform any of the funetons, features and / or benefits described in relation with some embodiments described herein. Virtualization layer 1706 may present a virtual operating platform that appears like networking hardware to the VMs 1708. VMs 1708 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1706. Different embodiments of the instance of a virtual appliance 1702 may be implemented on one or more of VMs 1708, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0220] In the context of NFV, each VM 1708 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine Each VM 1708, and that part of hardware 1704 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1708 on top of the hardware 1704 and corresponds to the application 1702.

[0221] Hardware 1704 may be implemented in a standalone network node with generic or specific components. Hardware 1704 may implement some functions via virtualization. Alternatively, hardware 1704 may be part of a larger cluster of hardware (e g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration function 1710, which, among others, oversees lifecycle management of applications 1702. In some embodiments, hardware 1704 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1712 which may alternatively be used for communication between hardware nodes and radio units.

[0222] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above described exemplary embodiments. Moreover, any combination of the above-described embodiments in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0223] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

[0224] The following is a concise description of certain embodiments in an enumerated format.

[0225] Al. A method for providing runtime protection, performed by a security function, the method comprising: detecting a request from an application function (AF) through a Network Exposure Function (NEF); storing auxiliary information about the request; analyzing the request; and sending information about the request to a Network Data Analytics Function (NWDAF).

[0226] A2. The method of embodiment Al, wherein analyzing the request further comprises analyzing request history about previously detected requests.

[0227] A3. The method of any one of embodiments A1-A2, further comprising receiving security information from the NWDAF related to the request, and wherein analyzing the request further comprises analyzing the security information.

[0228] A3a. The method of embodiment A3, wherein the security information from the NWDAF includes feedback on network status.

[0229] A4. The method of any one of embodiments Al -A3, further comprising: determining that a likelihood that the request is harmful exceeds a threshold; and sending towards the NEF a message indicating one or more mitigating actions.

[0230] A4a. The method of embodiment A4, wherein the message includes one or more request IDs identifying harmful requests.

[0231] A5. The method of any one of embodiments A1-A4, further comprising providing correlation rules to the NWDAF.

[0232] A6. The method of any one of embodiments A1-A5, wherein the auxiliary information includes one or more of: (i) an origin of the request; and (ii) an identifier (ID) of the request. Bl. A method for providing runtime protection, performed by a Network Data Analytics Function (NWDAF), the method comprising: receiving, from a security function, information about a request from an application function (AF); receiving network information; correlating received network information with the request to determine if a consumer has a harmful impact on the network; and if the consumer has a harmful impact on the network, sending a message to the security function comprising security information related to the request.

[0233] B2. The method of embodiment Bl, wherein the security information in the message to the security function includes feedback on network status.

[0234] B3. The method of any one of embodiments B1-B2, wherein the network information includes information about load that has not been carried, congestion, and / or missed requests due to high signaling load.

[0235] B4. The method of any one of embodiments B1-B3, wherein correlating received network information with the request to determine if a consumer has a harmful impact on the network comprises applying a rule-based mechanism.

[0236] B5. The method of embodiment B4, wherein applying the rule-based mechanism comprises determining if a set of criteria is true and, as a result of determining that the set of criteria is true, determining that the consumer has a harmful impact on the network.

[0237] B6. The method of embodiment B5, wherein the set of criteria includes: (i) a user equipment (UE) is experiencing traffic starvation; (ii) a number of location requests through an exposure API exceeds a first threshold; and (iii) one or more quality of service (QoS) mappings to high priority was performed for traffic related to one or more UEs in results for the location requests and within a distance to the UE experiencing traffic starvation not exceeding a second threshold.

[0238] B7. The method of any one of embodiments B1-B6, further comprising receiving correlation rules from the security function. B8. The method of any one of embodiments B1-B7, further comprising continuously monitoring events over a period of time to gather the network information, wherein the events include one or more of: (i) requests for services over network exposure, (ii) network events, (iii) responses generated by the network for incoming API requests, (iv) events relating to statistical measures, (v) network node level events, and (vi) API invoker level events.

[0239] Cl. A security function comprising: processing circuitry (1402); and a memory, the memory containing instructions (1444) executable by the processing circuitry (1402), whereby when executed the processing circuitry (1402) is configured to: detect a request from an application function (AF) through a Network Exposure Function (NEF); store auxiliary information about the request; analyze the request; and send information about the request to a Network Data Analytics Function (NWDAF).

[0240] C2. The security function of embodiment Cl, wherein the processing circuitry is further configured to perform the steps of any one of embodiments A2-A6.

[0241] DI. A Network Data Analytics Function (NWDAF) comprising: processing circuitry (1402); and a memory, the memory containing instructions (1444) executable by the processing circuitry (1402), whereby when executed the processing circuitry (1402) is configured to: receive, from a security function, information about a request from an application function (AF); receive network information; correlate received network information with the request to determine if a consumer has a harmful impact on the network; and if the consumer has a harmful impact on the network, send a message to the security function comprising security information related to the request.

[0242] D2. The NWDAF of embodiment C2, wherein the processing circuitry is further configured to perform the steps of any one of embodiments B2-B8. El. A computer program (1443) comprising instructions which when executed by processing circuitry (1402) of a node (1400), causes the node (1400) to perform the method of any one of embodiments A1-A6 and B1-B8.

[0243] E2. A carrier containing the computer program (1443) of embodiment El, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (1442)

Claims

CLAIMS1. A method performed by a security function of a communication network, the method comprising: determining (1230) the following: that application programming interface, API, requests from one or more consumers have degraded performance of the communication network, wherein the API requests are via a network exposure function, NEF, of the communication network; and at least one recommended action to mitigate the degraded performance due to the API requests; and sending (1240), to one or more network functions, NFs, of the communication network, an indication of the at least one recommended action.

2. The method of claim 1, wherein determining (1230) that API requests from one or more consumers have degraded performance of the communication network comprises: receiving (1231) the following information from the NEF for each of a plurality of API requests from a plurality of different consumers: an identifier of the consumer making the API request, and an identifier of the API request; receiving (1232) network performance information from one or more of the following of the communication network: a radio access network, RAN, and at least one NF; correlating (1233) the received network performance information with the information received from the NEF, thereby obtaining correlated information; and detecting (1234), based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network.

3. The method of claim 2, wherein the network performance information includes one or more of the following: processing load information for the at least one NF; processing load information for one or more network nodes of the communication network;RAN traffic scheduling information; andperformance information related to handling of API requests and corresponding responses.

4. The method of claim 1, wherein: determining that API requests from one or more consumers have degraded performance of the communication network comprises receiving the following information from a network data analytics function, NWDAF, of the communication network: an indication that API requests from one or more consumers have degraded performance of the communication network, and respective identifiers of the one or more consumers; the at least one recommended action is determined based on the received information.

5. The method of claim 4, further comprising sending to the NWDAF one or more rules for detecting degraded performance of the communication network due to API requests, wherein the information received from the NWDAF is based on the one or more rules.

6. The method of any of claims 4-5, wherein the information received from the NWDAF also includes one or more of the following: identifiers of the API requests that have degraded performance; and radio access network, RAN, traffic scheduling information that indicates the degraded performance.

7. The method of claim 6, wherein the information received from the NWDAF includes at least one of the following: a plurality of identifiers of respective different consumers whose API requests have degraded performance; and a plurality of identifiers of a plurality of different API requests that have degraded performance.

8. The method of claim 7, wherein the RAN traffic scheduling information indicates one or more of the following: one or more cells of the communication network, in which performance has been degraded; a portion of offered traffic in the one or more cells that has not been scheduled; andidentifiers of one or more user equipment, UEs, operating in the one or more cells, whose traffic has been prioritized.

9. The method of any of claims 3-8, further comprising sending to the NWDAF a subscription for notifications of degraded network performance due to API requests, wherein the information is received from the NWDAF based on the subscription.

10. The method of any of claims 2-3 and 5-9, wherein: the degraded performance includes reduced capacity in a cell of the communication network for traffic associated with one or more user equipment, UEs, due to traffic associated with other UEs in the cell; and the one or more rules include the following: a first number of API requests related to location tracking of the one or more UEs, and a second number of API requests related to increased prioritization of the traffic associated with the other UEs.

11. The method of claim 10, wherein the at least one recommended action to mitigate the degraded performance due to the API requests includes decreasing prioritization of traffic for or from the other UEs.

13. The method of any of claims 2-3 and 5-9, wherein: the degraded performance includes excessive processing load on at least one NF of the communication network; and the one or more rules include at least one of the following: a first number of API requests related to network monitoring, and a second number of API requests that resulted in failed setup of quality-of-service on demand, QoD, flows.

14. The method of claim 13, wherein the at least one recommended action to mitigate the degraded performance due to the API requests includes shedding traffic load associated with the one or more consumers whose API requests have degraded performance, and the indication of the at least one recommended action includes one or more of the following: the identifiers of the one or more consumers, and identifiers of the API requests that have degraded performance.

15. The method of any of claims 1-14, wherein the indication is sent to one of the following: the NEF; or a policy control function, PCF, via the NEF.

16. The method of claim 15, further comprising receiving (1250) one of the following from the PCF: a confirmation that the at least one recommended action was taken, or an indication of another action taken to mitigate the degraded performance due to the API requests.

17. A method performed by a network data analytics function, NWDAF, of a communication network, the method comprising: for each of a plurality of application programming interface, API, requests from a plurality of different consumers, receiving (1330) the following information from a network exposure function, NEF, of the communication network: an identifier of the consumer making the API request, and an identifier of the API request; receiving (1340) network performance information from one or more of the following of the communication network: a radio access network, RAN, and at least one network function, NF ; correlating (1350) the received network performance information with the information received from the NEF, thereby obtaining correlated information; and detecting (1360), based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network; and sending (1370) the following information to a security function of the communication network: an indication that API requests from one or more consumers have degraded performance of the communication network, and respective identifiers of the one or more consumers.

18. The method of claim 17, wherein the network performance information includes one or more of the following: processing load information for the at least one NF; processing load information for one or more network nodes of the communication network;RAN traffic scheduling information; and performance information related to handling of API requests and corresponding responses.

19. The method of any of claims 17-18, further comprising receiving (1320) the one or more rules from the security function.

20. The method of any of claims 17-19, wherein the information sent to the security function also includes one or more of the following: identifiers of the API requests that have degraded performance; andRAN traffic scheduling information that indicates the degraded performance.

21. The method of claim 20, wherein the information sent to the security function includes at least one of the following: a plurality of identifiers of respective different consumers whose API requests have degraded performance; and a plurality of identifiers of a plurality of different API requests that have degraded performance.

22. The method of claim 20, wherein the RAN traffic scheduling information indicates one or more of the following: one or more cells of the communication network, in which performance has been degraded; a portion of offered traffic in the one or more cells that has not been scheduled; and identifiers of one or more user equipment, UEs, operating in the one or more cells, whose traffic has been prioritized.

23. The method of any of claims 17-22, further comprising receiving (1310) from the security function a subscription for notifications of degraded network performance due to API requests, wherein the information is sent to the security function based on the subscription.

24. The method of any of claims 17-23, wherein: the degraded performance includes reduced capacity in a cell of the communication network for traffic associated with one or more user equipment, UEs, due to traffic associated with other UEs in the cell; and the one or more rules include the following: a first number of API requests related to location tracking of the one or more UEs, and a second number of API requests related to increased prioritization of the traffic associated with the other UEs.25 The method of claim 24, wherein the at least one recommended action to mitigate the degraded performance due to the API requests includes decreasing prioritization of traffic for or from the other UEs.

26. The method of any of claims 17-23, wherein: the degraded performance includes excessive processing load on at least one NF of the communication network; and the one or more rules include at least one of the following: a first number of API requests related to network monitoring, and a second number of API requests that resulted in failed setup of quality-of-service on demand, QoD, flows.

27. The method of claim 26, wherein the at least one recommended action to mitigate the degraded performance due to the API requests includes shedding traffic load associated with the one or more consumers whose API requests have degraded performance, and the indication of the at least one recommended action includes one or more of the following: the identifiers of the one or more consumers, and identifiers of the API requests that have degraded performance.

28. Network equipment (1400, 1508, 1600, 1702) arranged to implement a security function (204) of a communication network (100, 306, 1502), the network equipment comprising: communication interface circuitry (1606, 1704) configured to communicate with one or more other network functions, NFs (110, 120, 160, 502, 602, 604) of the communication network; and processing circuitry (1602, 1704) operably coupled to the communication interface circuitry, wherein the processing circuitry and interface circuitry are configured to: determine the following: that application programming interface, API, requests from one or more consumers have degraded performance of the communication network, wherein the API requests are via a network exposure function, NEF, of the communication network; and at least one recommended action to mitigate the degraded performance due to the API requests; and send, to one or more NFs of the communication network, an indication of the at least one recommended action.

29. The network equipment of claim 28, wherein the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to any of the methods of claims 2-16.

30. Network equipment (1400, 1508, 1600, 1702) arranged to implement a security function (204) of a communication network (100, 306, 1502), the network equipment being configured to: determine the following: that application programming interface, API, requests from one or more consumers have degraded performance of the communication network, wherein the API requests are via a network exposure function, NEF, of the communication network; and at least one recommended action to mitigate the degraded performance due to the API requests; and send, to one or more network functions, NFs, of the communication network, an indication of the at least one recommended action.

31. The network equipment of claim 30, being further configured to perform operations corresponding to any of the methods of claims 2-16.

32. Non-transitory, computer-readable medium (1604, 1704) storing computer-executable instructions that, when executed by processing circuitry (1602, 1704) associated with a security function (204) of a communication network (100, 306, 1502), configure the security function to perform operations corresponding to any of the methods of claims 1-16.

33. Computer program product (1604a, 1704a) comprising computer-executable instructions that, when executed by processing circuitry (1602, 1704) associated with a security function (204) of a communication network (100, 306, 1502), configure the security function to perform operations corresponding to any of the methods of claims 1-16.

34. Network equipment (1400, 1508, 1600, 1702) arranged to implement a network data analytics function, NWDAF (160, 502) of a communication network (100, 306, 1502), the network equipment comprising:communication interface circuitry (1606, 1704) configured to communicate with a security function (204) and a network exposure function, NEF (110, 202, 602) of the communication network; and processing circuitry (1602, 1704) operably coupled to the communication interface circuitry, wherein the processing circuitry and interface circuitry are configured to: for each of a plurality of application programming interface, API, requests from a plurality of different consumers, receive the following information from the NEF: an identifier of the consumer making the API request, and an identifier of the API request; receive network performance information from one or more of the following of the communication network: a radio access network, RAN (170, 612, 1504) and at least one network function, NF (120, 130, 140, 150, 604, 606, 608, 610); correlate the received network performance information with the information received from the NEF, thereby obtaining correlated information; and detect, based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network; and send the following information to the security function: an indication that API requests from one or more consumers have degraded performance of the communication network, and respective identifiers of the one or more consumers.

35. The network equipment of claim 34, wherein the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to any of the methods of claims 18-27.

36. Network equipment (1400, 1508, 1600, 1702) arranged to implement a network data analytics function, NWDAF (160, 502) of a communication network (100, 306, 1502), the network equipment being configured to: for each of a plurality of application programming interface, API, requests from a plurality of different consumers, receive the following information from a network exposure function, NEF (110, 202, 602) of the communicationnetwork: an identifier of the consumer making the API request, and an identifier of the API request; receive network performance information from one or more of the following of the communication network: a radio access network, RAN (170, 612, 1504) and at least one network function, NF (120, 130, 140, 150, 604, 606, 608, 610); correlate the received network performance information with the information received from the NEF, thereby obtaining correlated information; and detect, based on the correlated information and one or more rules, that API requests from the one or more consumers have degraded performance of the communication network; and send the following information to a security function (204) of the communication network: an indication that API requests from one or more consumers have degraded performance of the communication network, and respective identifiers of the one or more consumers.

37. The network equipment of claim 36, being further configured to perform operations corresponding to any of the methods of claims 18-27.

38. Non-transitory, computer-readable medium (1604, 1704) storing computer-executable instructions that, when executed by processing circuitry (1602, 1704) associated with a network data analytics function, NWDAF (160, 502) of a communication network (100, 306, 1502), configure the NWDAF to perform operations corresponding to any of the methods of claims 17- 27.

39. Computer program product (1604a, 1704a) comprising computer-executable instructions that, when executed by processing circuitry (1602, 1704) associated with a network data analytics function, NWDAF (160, 502) of a communication network (100, 306, 1502), configure the NWDAF to perform operations corresponding to any of the methods of claims 17-27.

Images