Trust management for access to a service provided by a network function producer in a network

Abstract

A computer implemented method performed by a first computing device is provided for trust management for access to a service provided by a NFP in a network. The method includes receiving (500) an identity of a NFC that made a request to access a service provided by a NFP of a specified type. The method further includes accessing (502) stored information including (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC. The method further includes making (504) a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

Description

TRUST MANAGEMENT FOR ACCESS TO A SERVICE PROVIDED BY A NETWORK FUNCTION PRODUCER IN A NETWORKTECHNICAL FIELD

[0001] The present disclosure relates generally to computer-implemented methods for trust management for access to a service provided by a network function producer (NFP) in a network, and related methods and devices.BACKGROUND

[0002] National Institute of Standards and Technology (NIST) special publication (SP) 800-207, for example, explains concepts for a zero-trust architecture, where a user / system (also known as “subject”) tries to access a resource. See e.g., https: / / csrc.nist.gov / publications / detail / sp / 800-207 / final. The concepts include that a policy decision point (PDP) can have two tasks:• Decide to provide access to the resource (with a policy engine (PE), for example), and• Establish or shut down communication path from the user of a resource to the resource (with a policy administration (PA), for example). PA is an interface between a PE and a policy enforcement point (PEP) that can signal to the PEP to establish or shutdown a connection.

[0003] Further, a PEP can serve as a system gateway for activating, monitoring, and terminating connections between users and their resources.SUMMARY

[0004] There currently exist certain challenges. Security risks may exist as a result of a network function (NF) (e.g., a network function consumer (NFC)) requesting to access services of another NF (e.g., a NFP)). Such a security risk may be due to an authentication token being compromised during an authentication process of the requesting NF or as a result of software that the requesting NF uses that allows exploits, for example. Operations for identifying whether a NF requesting such service access is trustworthy or not trustworthy may be lacking.

[0005] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0006] Some embodiments provide a computer-implemented method performed by a first computing device for trust management for access to a service provided by a NFP in a network. The method includes receiving an identity of a NFC that made a request to access a service provided by a NFP of a specified type. The method further includes accessing stored information including (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC. The historical behavior includes data about historical requests that the NFC made towards at least one NF. The method further includes making a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

[0007] Other embodiments provide a computer-implemented method performed by a second computing device including a NFP in a network. The method includes receiving a communication to monitor requests of a NFC for a period of time. The method further includes monitoring the requests of the NFC.

[0008] Other embodiments provide a first computing device. The first computing device is configured for trust management for access to a service provided by a NFP in a network. The first computing device includes processing circuitry and memory coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the first computing device to perform operations. The operations include to receive an identity of a NFC that made a request to access a service provided by a NFP of a specified type. The operations further include to access stored information including (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC. The historical behavior includes data about historical requests that the NFC made towards at least one NF. The operations further include to make a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

[0009] Some embodiments provide a non-transitory computer readable medium including program code to be executed by processing circuitry of a first computing device. Execution of the program code causes the program code to perform operations including to receive an identity of a NFC that made a request to access a service provided by a NFP of a specified type. The operations further include to access stored information including (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC. The historical behavior includes data about historical requests that the NFC made towards at least one NF. Theoperations further include to make a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

[0010] Other embodiments provide a second computing device including a NFP in a network. The second computing device includes processing circuitry and memory coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the second computing device to perform operations. The operations include to receive a communication to monitor requests of a NFC for a period of time. The operations further include to monitor the requests of the NFC.

[0011] Some embodiments provide a non-transitory computer readable medium including program code to be executed by processing circuitry of a second computing device. Execution of the program code causes the program code to perform operations including to receive a communication to monitor requests of a NFC for a period of time. The operations further include to monitor the requests of the NFC.

[0012] Certain embodiments may provide one or more of the following technical advantage(s). Based on inclusion of operations for making a determination, based on at least one of a score and a confidence level for the score, on whether to trust an NFC that made a request to access a service provided by a NFP of a specified type, trust management for access to the service(s) may be provided. Moreover, the determination on whether to trust the NFC may be more efficient due to the determination may occur faster than in approaches that use patches for vulnerabilities in software included in the requesting NFC, for example. Further, the score and / or the confidence level on the score may be provided for the requesting NFC irrespective of the NFC’s availability for providing data.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of the present disclosure. In the drawings:

[0014] Figure 1 is a schematic drawing illustrating an example a system and message flow in a 5G core network in accordance with some embodiments;

[0015] Figure 2 is a schematic drawing illustrating an example of a structure for a database according to some embodiments;

[0016] Figure 3 is a schematic drawing illustrating an example of interactions with a database in accordance with some embodiments;

[0017] Figures 4A and 4B is a sequence diagram showing operations of an example process in accordance with some embodiments;

[0018] Figure 5 is a flowchart illustrating example operations of a first computing device in accordance with some embodiments;

[0019] Figure 6 is a flowchart illustrating example operations of a second computing device in accordance with some embodiments;

[0020] Figure 7 is a block diagram of a computing device in accordance with some embodiments;

[0021] Figure 8 is a block diagram of a communication system in accordance with some embodiments; and

[0022] Figure 9 is a block diagram of a virtualization environment in accordance with some embodiments.DETAILED DESCRIPTION

[0023] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, in which examples of embodiments of the present disclosure are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present / used in another embodiment.

[0024] In a third generation partnership project (3GPP) network, in some use cases a network function(s) (NF(s)) may take the role of a PEP and a PDP. In a first use case example, for a fifth generation (5G) service access when a user equipment (UE) attaches to the network and authenticates, and a radio bearer is established, the Access and Mobility Management Function (AMF) may be the PEP, and the Unified Data Management (UDM) and Policy Control Function (PCF) may be PDPs, and a UE may be a ’’user” requesting access to the resource. In a second example, for a NF service access, a service communication proxy (SCP) may be a PEP; a network repository function (NRF) may be a PDP; and a consumer NF may be a ’’user” requesting access to the resource.

[0025] While some examples of the present disclosure are directed to NF service access involving a SCP that is a PEP, a NRF that is a PDP, and a consumer NF (NFC) (also referred to herein as an NF that requests to access services of another NF), the present disclosure is not so limited and includes any node that includes any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein.

[0026] Moreover, while some examples includes a 5G network and / or 5G network architecture, the present disclosure is not so limited and includes other networks and network architectures. For example, other networks include, without limitation, sixth generation (6G) and beyond networks.

[0027] In an example, NF service access in a 5G network architecture includes a NFC that requests to access services of another NF, and a NF provider of a service (also referred to herein as a NF Producer (NFP)). A NF(s) can register to a NRF as an NFP. The NRF can make the registered NF and its services discoverable to other NFs (e.g., to NFCs). In 3GPP release 15, for example, communication between a NFC and a NFP was direct. In 3GPP release 16, a SCP was introduced, which is a node that can mediate between NFCs and NFPs.

[0028] For a NF wanting to communicate with another NF, either directly or via a SCP, Open Authentication (OAuth) 2.0, token-based authentication can be used. A disadvantage of this type of authentication, however, can include that if a token is compromised, an attacker in possession of an encryption key, can gain access to the services of an NF at least until the token expires.

[0029] Even if an NF has authenticated, an NF may pose a security threat if the NF is using certain software libraries or running in specific configuration. For example, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) publishes software with exploited vulnerabilities (see e.g., CISA, Alert AA22-117A, 2021 Top Routinely Exploited Vulnerabilities https: / / www.cisa.gov / uscert / ncas / alerts / aa22-117a). Using such software to build NFs can constitute a threat and, therefore, in such a case the NF is not to be trusted. Moreover, exploits typically are not discovered at the time a software is built. To the contrary, typically, an exploit(s) may be discovered later, and then the vendor of the software may need to provide a security patch to fix the exploit(s). In more serious cases, other libraries providing functionality may need to be considered or the software may need to be written from scratch. In such a situation, not only is there lead-time on behalf of the vendor of the software but additional time may be needed for the deployed software to be patched.

[0030] Thus, from the perspective of an NFC for example, risks from security perspective may exist, such as due to an authentication token being potentially compromised or because ofa third party software that the NFC uses allowing exploits. Operations may be lacking for identifying which NFs requesting service access are trustworthy and which are not trustworthy.

[0031] Some approaches may use a trust measurement function for calculating a trust score for a NF, as part of an authentication process. The trust measurement function, however, may rely solely on data from that NF to calculate the trust score. Thus, for the trust score to be calculated, a process (e.g., a long process) of retrieving measurement data from the NF may be needed. As a consequence, NFs may be prohibited, or essentially prohibited, from accessing services of other NFs until the score is calculated. Such a delay may be critical in case of UE authentication, for example, where an AMF wants to use services of a UDM and may mean that a user may not be able to attach to the network for some time. It is additionally noted that a trust calculation may not be a one-time process. In context of exploits and security risks, for example, the trust score may need to be recalculated multiple times, such as during upgrades of the NF or periodically, as new exploits may continue to be discovered.

[0032] Other approaches may assume that NFs can share data such as execution logs with a trust management function, which may not be standardized and may limit applicability to multi-vendor environments.

[0033] Examples of the present disclosure include a system and operations for distributed trust management. Some examples include a distributed trust function. The distributed trust function can include multiple instances of a risk score function (RSF) and a trust analysis function (TAF). In some examples, the TAF can analyze behavior of a function of a specific type of NF (also referred to herein as “NFType”) and configuration, and can submit this information to a distributed database. The RSF, in some examples, can retrieve collective reports from the distributed database and make an assessment on whether a NF is risky or not. The distributed database can also allow for other entities to submit an assessment that may influence the risk score, e.g. from the European Union Agency for Cybersecurity (ENISA) or CISA.

[0034] In a non-limiting example, a process for risk assessment / reporting may trigger a risk calculation for an NFC(s), on a service discovery request (or after several discovery requests, which may be configurable by design), of the NFC(s) towards a NRF / SCP. Depending on a value of the risk score, the NRF / SCP can then allow the request, quarantine the NFC (e.g., block the request and further data traffic to and from the NFC), monitor behavior of the NFC, or deny the discovery request completely. Decoupling the risk calculation from the authentication process may allow for more frequent vetting of NFCs.

[0035] Thus, in this example, rather than using a single NF as source of data, the risk score (also referred to herein as a trust score) calculation retrieves data from multiple NFs of a similar type. Similarity of a type can be determined by a function that measures similarity, and NFs of a similar type may be the same type. As a consequence, in contrast to other approaches, the operations of this example may be faster to calculate a trust score for NFs during bootstrapping, as well as throughout a NFC lifetime.

[0036] Moreover, in examples herein, NFs do not need to report their data to calculate the risk score. Rather, the risk score may be calculated by maintaining information (e.g., a list of public information) of exploits and security threats and comparing the information to deployment and upgrade information of the NF, and / or by observing the NF’s behavior. Additionally, calculation of risk score may not be part of the authentication process, but rather part of the service discovery process (e.g., implemented at a NRF), which may assist in compliance with standards.

[0037] Examples include a multi-vendor mechanism for zero-trust NF service access.

[0038] Some embodiments provide a computer implemented method performed by a first computing device for trust management for access to a service provided by a NFP in a network. The method includes receiving (operation 500 in Figure 5) an identity of a NFC that made a request to access a service provided by a NFP of a specified type. The method further includes accessing (operation 502 in Figure 5) stored information including (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC. The historical behavior includes data about historical requests that the NFC made towards at least one NF. The method further includes making (operation 504 in Figure 5) a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

[0039] The method of some embodiments further includes performing (operation 512 in Figure 5) one of (i) handle the request to access the service based on the determination, or (ii) forward the determination to a SCP.

[0040] In some embodiments, the at least one NF includes at least one NF of a similar type-

[0041] The determination on how to handle the request can include a determination of at least one of (i) allow the request, (ii) block the request and further data traffic to and from the NFC, (iii) monitor behavior of the NFC, and (iv) deny the request.

[0042] The first computing device of some embodiments includes a NRF.

[0043] Some examples include an SCP that is a PEP and an NRF that is a PDP. In such examples, given a request for NFP service access from an NFC, the SCP retrieves and forwards the identity of the NFC to NRF. As part of the operations, the SCP also can send an access token request to the NRF. Subsequently, the NRF assesses whether to trust the NFC, by accessing a RSF, which can use information contained in a database (e.g., a threat intelligence database) to calculate a risk score.

[0044] For example, in some embodiments, an SCP allows access to a NFP to monitor the subsequent requests. Further, in some embodiments, an SCP allows access to a NFP for the request. In yet other embodiments, an SCP blocks the request and further data traffic to and from the NFC.

[0045] Further, in some examples, the risk score calculated for the NFC uses information from the database. Information is the database may be not only related to an NFC being compromised or spoofed, but also to the software revision, vendor etc. of the NFC that may indicate vulnerabilities or are known to be exploited. In such examples, depending on the risk score provided by RSF, the NRF decides how to handle the NFC’s discovery request. For example, in case of a high risk score, the NRF can instruct the SCP to block the request; or in case of a low risk score, the NRF may instruct the SCP to allow the request.

[0046] Alternatively, and in an example where the risk score is within specified boundaries in which the NRF is not able to reach a conclusive decision, the NRF can request that the SCP route the request(s) of the NFC to an NFP with monitoring capabilities for a duration of a monitoring period, until a conclusion on the trustworthiness of the NFC can be reached.

[0047] Figure 1 is a schematic drawing illustrating an example a system 100 and message flow in a 5G core network according to some embodiments. System 100 includes two public land mobile networks (PEMNs), PLMN and PLMN2 of at least one mobile network operator. PLMN includes a requesting NFC 102, SCP 104, NRF 106, risk scoring function (RSF) 108, NFP 110, monitoring NFP 112 (NFP_Mon 112), and threat analysis function (TAF) 114b. PLMN 2 includes TAF 114a and NRF database 116 (NRFDB 116). PLMN and PLMN 2, respectively, are communicatively connected with threat intelligence database 118. Network function vendors (NFV - Vendor 1 through NFV- Vendor X) include, for example, third parties or an architecture component (e.g., European Telecommunication Standards Institute (ETSI) network function virtualization orchestration (NFVO)) communicatively connected to the threat intelligence database 118. Publishing authorities 1 through X also are communicatively connected to threat intelligence database 118 and can provide to the database 118 information concerning exploited software (as discussed further herein).

[0048] In the example in Figure 1, SCP 104 is a PEP and NRF 106 is a PDP, mediating for service access from NFC 102 towards NFP 110. As previously discussed, however, this is a non-limiting example. Different configurations may be used such as, e.g., an NRF can be both a PEP and a PDP (which may include a transparent SCP or no SCP), or an SCP can be both a PEP and a PDP (e.g., full delegation to the SCP). However, for ease of discussion, nonlimiting examples herein are discussed where an NRF acts as a PDP and a SCF acts as a PEP.

[0049] In a service discovery request towards SCP 104, NFC 102 may provide the NFType of the NFP it is requesting service access from. Then, SCP 104 may, either directly or indirectly, make a selection from a list of NFPs that match conditions set in the discovery request and return a response to the NFC 102. A database 118 (e.g., a threat intelligence database) may contain a list of profiles, e.g., NFProfiles, which, in turn may contain information about the type and status of respective NFPs.

[0050] In some examples, NRF 106 verifies the trustworthiness of the NFC 102 using behavioral heuristics and the database 118 (e.g., a distributed database) of known exploits and vulnerabilities.

[0051] The stored information about the NFC can include at least one of (i) known vulnerabilities of the NFC provided to the stored information, (ii) a type, version, and / or vendor identifier for the NFC from at least one operator in the network, and (iii) a risk level of software used in the NFC.

[0052] For example, database 118 can include information (e.g., a list) of software libraries or programs used to implement the NFC 102. The information can include a software bill of materials (SBOM), such as at least a vendor, a name, and a version of software. Additionally, the information may include a list of software vulnerabilities and known exploits, an assessment of their severity / impact, etc. Further, the information may include an identification of known malicious identities and / or trusted identities. The information may originate from different data sources belonging to different administrative domains. As a consequence, the database 118 may be implemented as a distributed database, such as a distributed ledger.

[0053] In some embodiments, data about historical requests includes a frequency, a distribution of historical requests in a time domain, and a content of at least one historical request of the NFC towards at least one NF of the same type as the specified type in the NFC. The distribution of historical requests in a time domain can include, for example, a distribution of the historical requests on a periodical basis, a uniform basis, a normal basis, etc.

[0054] In some embodiments, the stored information includes information stored in a distributed database. The distributed database can be a distributed ledger. The distributed ledger can be a multi-layer blockchain.

[0055] Figure 2 is a schematic drawing illustrating an example of a structure for the database 118. The structure in this example is in form of a distributed ledger, specifically a multi-layer blockchain.

[0056] In the example shown in Figure 2, the illustrated data structure is non-limiting and values for data fields are merely an example values. For example, blocks from Tier 1 (home network identifier (HNI), status, etc.) may exist in the same tier as NF metadata (Tier 2, as illustrated). Moreover, information may not exist in a block(s), but rather may exist as tables in a relational database or hashes in a distributed hash table, etc.

[0057] In the example in Figure 2, Tier 1 (e.g., the first layer) includes blocks having a hash (e.g., block hashes df32a53, a 55263f, and eadf234, respectively, in the example in Figure 2). The respective blocks can include information about owners in a mobile network. In this example, the owners are public operators and are identified by their HNI value (e.g., HNI 111 342 and HNI 184 554 as shown in the example in Figure 2). Operators can register and unregister at Tier 1 by changing the status field (e.g., Status “register” or “unregister” in the example in Figure 2).

[0058] Tier 2 in the example in Figure 2 includes information about NFs in the respective operator’ s network. In this example, the information includes the NF type (PCF and UDM in the example in Figure 2), NF version (2.5.1 and 1.0.1 in the example in Figure 2), and a vendor identifier ( a vendor name in the example in Figure 2).

[0059] Tier 3 in the example in Figure 2 includes information about the behavior of a NF. This information can be added by a TAF 114a, 114b shown in Figure 1 (discussed further herein). While Figure 1 shows two instances of a TAF 114a, 114b, there can be one or more instances of a TAF (any one or more of which is referred to herein as TAF 114). Moreover, TAF 114 can be included in a first computing device (e.g., NRF 106) or can be a separate node(s) as shown in the example in Figure 1. TAF 114 can use behavioral heuristics to identify whether to trust or not an NFC 102 based on behavior of the NFC 102. Behavior of the NFC 102 can include a frequency, a distribution, and / or a content of requests the NFC 102 makes towards an NFP (e.g., NFP 110).

[0060] Tier 4 in the example in Figure 2 includes information about a threat risk of a software stack included in the particular NF. As previously discussed, a NF can be based on a number of software libraries, and a software library may be open source. When combined withinformation from trust-informative authorities, for example, a risk assessment can be provided. As illustrated in the example in Figure 2, the risk assessment can be on a quantitative scale, which can be translated from qualitative information. For example, a national vulnerability database can include a risk calculator based on severity as illustrated in the following from https: / / nvd.nist.gov / vuln / detail / CVE-2023-23397:NVD Vulnerability Severity RatingsNVD provides qualitative severity ratings of “Low”, “Medium”, and “High” for CVSS v2.0 base score ranges in addition to the severity ratings for CVSS v3.0 as they are defined in theCVSS v3.0 specification.CVSS v2.0 Ratings CVSS v3.0 RatingsSeverity Base Score Range Severity Base Score RangeNone 0.0Low 0.0-3.9 Low 0.1-3.9Medium 4.0-6.9 Medium 4.0-6.9High 7.0-10.0 High 7.0-8.9Critical 9.0-10.0

[0061] This risk assessment can be translated to a normalized score for a specific software and version that can be stored in database 118 in the example shown in Figure 2.

[0062] Figure 3 is a schematic drawing illustrating an example of interactions with a database 118. As previously referenced, various information can be included in the database 118. The information can include a behavioral analysis for a given NFC, added to a threat analysis tier by a TAF 114. The information also can include a threat analysis for a given NFC 102 that combines information about a software stack of used by the NFC 102, which may be found as part of a blueprint used to deploy the NFC 102 in a cloud environment 100. The blueprint can be supplied by a cloud infrastructure as a service system, for example. For example, if a ETSI management and orchestration (MANO) standard is followed, a network slice management function (NSMF) may provide this information. CISA / ENISA or other authorities may provide a threat assessment for the software and version of the software, which can be compared to a software stack provided by NSMF or other function, and a threat analysis matrix (or other structure) for an NFC can be submitted to the threat intelligence database 118. An example of such a matrix is shown in the threat analysis tier structure shown in the example in Figure 2. The comparison can be performed, as shown in the example in Figure 3, as a risk score extraction.

[0063] In the example shown in Figure 3, RSF 108 produces a risk score and a confidence on the risk score. The risk score indicates a trustworthiness of an NFC 102. TAF 114 applies behavioral heuristics on whether NFC 102 is to be trusted or not (e.g., NFC 102 is trusted if the confidence on the risk score produced by RSF 108 is greater than a specified threshold value, as discussed further herein). It is noted that both RSF 108 and TAF 114 can be logical entities and, thus, can be collocated with NRF 106, SCP 104, or another node of the network (e.g., a core network), such as a network data and analytics function (NWDAF); or they can be standalone functions (e.g., provided by the operator or another third party). Optionally, TAF 114 also can subscribe to a NWDAF to retrieve security-related information pertaining to the NFC 102, such as abnormal NF behavior, network performance, NF load, etc.

[0064] Figures 4A and 4B is a sequence diagram showing operations of an example. In operation 1 (which corresponds to operation 1 in Figure 1), NFC 102 requests a NF of a particular NF Type (e.g., UDM) indicated, e.g., by a parameter target-nf-type. Additionally, NFC 102 also may include other parameters with the request such as a preferred version (or versions) of an application program interface (API), supported features, etc. The NFC 102 can also include about itself, such as its own NF Type, its fully qualified domain name (FQDN), and its instance identifier, for example. Other information also may be included, such as a network slice or network slices that NFC 102 belongs to, for example.

[0065] NRF 106 may authenticate NFC 102 using OAuth2 a database with information about the NFC 102, such as an NFProfile. The information can include two parameters pertaining to the trustworthiness of an NFC referred to in examples herein as NFRisk and NFConfidence. Depending on the values of NFRisk and NFConfidence, in operation 2, NRF 106 and / or SCP 104 engage in different behavior with regard to how they process the request of operation 1.

[0066] In a first example (shown as alternative 1 in operation 7 in Figure 1 and in operations 3-9 in Figure 4A), if the NFConfidence of the trustworthiness of the NFC 102 is less than or equal to a first specified threshold, then the NRF 106 accepts the discovery request of the NFC 102, but in operation 3 of Figure 4A, directs the SCP 104 to route all NFC 102 requests to a NFP 112 with monitoring capabilities (NFP_Mon 112 in Figure 1, which corresponds to NFPM 112 in Figures 4 A and 4B). It is noted that this threshold also can be configurable, e.g., set by a customer / operator. In operation 4 of Figure 4A, SCP 104 sends an acknowledgement to NRF 106.

[0067] In operation 5 of Figure 4A, NRF 106 sends a list of NFPs of the type of NF from the request; and in operation 6, NFC 102 selects a NFP from the list. NFC 102, in operation 7 in Figure 4A sends a request to SCP 104 for NF service access from the selected NFP.

[0068] In operation 8 in Figure 4A, SCP 104 routes all NFC 102 requests to NFPM 112; and in operation 9, NFPM 112 sends an acknowledgement to NFC 102 via SCP 104. The selected NFP 112, trusted a priori by NRF 106, is of the NFType the NFC 102 requested, and provides monitoring capabilities. For example, NFP 112 may use a packet sniffer such as libpcap (see e.g., https: / / www.tcpdump.org), and redirect information on captured traffic from and to the NFC 102, to the TAF 114. Network traffic heuristics that can be used include, without limitation:Monitoring the content of packets from the NFC 102 to NFP 112 (and vice-versa) for errors (syntax / logical etc.) and / or for patterns on parameter values.Monitoring deltas between service requests from NFC 102 toward NFP 112 and comparing them to expected periodicity.Monitoring the sequence of requests and comparing them to reference sequences (e.g., request with content B following request with content A, etc.)

[0069] In this first example, this information is identified by NFPMon 112 and recorded over a period of time (e.g., over a MONITORING_PERIOD.) Subsequently, at the end of monitoring period, in operation 10 in Figure 4A, NFPMon 112 sends information collected to TAF 114. In operation 11, TAF 114 uses this information, and information stored in the threat intelligence database 118, to calculate the risk in the form of NFRisk and NFConfidence. In operation 12 in Figure 4A, TAF 114 sends an update to the NFC information (e.g., NFProfile) to NFPM 112; and in operation 13, NFPM 112, database 118, and NFP 110 synchronize.

[0070] In operation 14 in Figure 4A, NRF 106 pulls the NFRisk and NFConfidence from RSF 108 ( or alternatively, from the database 118). In operation 15, if the NFConfidence is greater than a first specified threshold and the NFCredibiity lower than a second specified threshold, NRF 106 instructs SCP 104 to deny further service requests from the specific NFC 102 (e.g., block further data traffic to / from NFC 102).

[0071] For example, in some embodiments, when the confidence level is less than a first specified threshold, the determination includes to allow the request and to initiate routing of subsequent requests of the NFC to a NFP of the specified type of NF to monitor the subsequent requests of the NFC for a time period.

[0072] The method of some embodiments of the first computing device further includes receiving (operation 506 in Figure 5) information from the NFP that monitored the requests ofthe NFC. The information includes at least one of (i) a content of packets between the NFC and the NFP that monitored the requests for errors and / or for a pattern of values for at least one parameter that matches a specified type of NFP, (ii) a plurality of deltas between respective requests from a plurality of requests from the NFC towards the NFP that monitored the requests and a comparison of the deltas to an expected periodicity for the subsequent requests, and (iii) a sequence of the requests from the NFC and a comparison of the sequence to a reference sequence. The method can further include updating (operation 508 in Figure 5) the score and the confidence on the score based on the information from the NFP that monitored the requests and the stored information.

[0073] In some embodiments, when the updated score is less than a second specified threshold and the updated confidence level is greater than the first specified threshold, the determination includes initiation of a denial of the request and of the subsequent requests of the NFC.

[0074] Some embodiments provide a computer-implemented method performed by a second computing device including a NFP in a network. The method includes receiving (operation 600 in Figure 6) a communication to monitor requests of a NFC for a period of time; and monitoring (operation 602 in Figure 6) the requests of the NFC.

[0075] The monitoring (602) can include collecting information including at least one of (i) a content of packets between the NFC and the NFP for errors and / or for a pattern of values for at least one parameter that matches a specified type of NFP, (ii) a plurality of deltas between respective requests from a plurality of requests from the NFC towards the NFP and a comparison of the deltas to an expected periodicity for the subsequent requests, and (iii) a sequence of the requests from the NFC and a comparison of the sequence to a reference sequence.

[0076] The method of some embodiment of the second computing device includes sending(operation 604 in Figure 6) the information to one of a first computing device comprising a NRF and a third computing device comprising a TAF.

[0077] In a second example (shown as alternative 2 in Figure 1 and in operations 16-18 in Figure 4A), if the NFRisk is less than a second specified threshold and NFConfidence is greater than a first specified threshold, then the NFC 102 is not trusted. As shown in Figure 4A, an acknowledgement in sent form SCP 104 to NRF 106 in operation 16; and NRF 106, in operation 17, sends a communication to NFC 102 denying the request (e.g., a 403 Forbidden the discovery request of NFC 102). In operation 18, NRF 106 sends a communication to SCP 104 to block further data traffic to / from NFC 102.

[0078] For example, in some embodiments, when the score is less than a second specified threshold and the confidence level on the score is greater than a first specified threshold, the determination includes initiation of a denial of the request and a block of subsequent requests of the NFC.

[0079] In a third example (shown as alternative 3 in Figure 1 and in operations 19-26 in Figure 4B), if the NFRisk is greater than or equal to a second specified threshold and NFConfidence is greater than or equal to a first specified threshold, then normal NF Service access via SCP is carried out. In operation 19, NRF 106 sends a communication to SCP 104 to configure access for NFC 102; and in operation 20, SCP 104 sends an acknowledgement to NRF 106.

[0080] In operation 21 of Figure 4A, NRF 106 sends to NFC 102 a list of NFPs of the type of NF from the request; and in operation 22, NFC 102 selects a NFP from the list. NFC 102, in operation 23 in Figure 4A sends a request to SCP 104 for NF service access from the selected NFP.

[0081] In operation 24, SCP 104 routes the request to the selected NFP of the requested target-nf-type. In operation 25, SCP 104 sends the request for NF service access to the selected NFP 110; and in operation 26, the selected NFP 110 sends an acknowledgement to NFC 102 via SCP 104.

[0082] For example, in some embodiments, when the score is greater than a second specified threshold and the confidence level on the score is greater than a first specified threshold, the determination includes initiation of allowing the request.

[0083] In some embodiments, the method further includes initiating (operation 510 in Figure 5) routing the request to an NFP.

[0084] RSF 108 can be included in the first computing device (e.g., NRF 106) or can be a separate node(s) as shown in the example in Figure 1.

[0085] As previously discussed, database 118 can be a distributed database. The distributed database can have different implementations.

[0086] In a first non-limiting example, there are dedicated networks (e.g., private 5G networks) having the same enterprise owner, and mobile operators of public networks with a presence in multiple countries. For example, an automotive manufacturer such as Tesla, may have different dedicated mobile networks in different parts of the world (e.g., U.S., Europe and China). In such a case, the database 118 can be a centralized entity, collecting information where RSFs 108 and TAFs 114 belonging to different mobile networks can retrieve and submit information respectively.

[0087] Similarly, large operators such as tier-1 mobile operators (e.g., Vodafone), may have a presence in multiple countries. The mobile networks may be managed by different legal entities in different countries, but may belong to the same administrative entity. In such a case, the overarching organization may permit exchange of information between NFs of different mobile networks.

[0088] In both cases, it is noted that the exchange of data may be bound by data export rules such as the EU’s General Data Protection Regulation (GDPR).

[0089] In a second non-limiting example, there are different administrative entities operating dedicated networks or public networks. An example includes different public operators such as Telenor and Tele2, or different enterprise owners of dedicated networks such as Tesla and Ford. In such cases, a distributed database 118, such as a distributed ledger can be implemented due to its replicability, immutability, and consensus mechanisms.

[0090] A replicability mechanism can include that in every moment in time, respective participating entities in the ledger have the same copy of the data. Immutability can include that once data is written to the ledger it cannot be removed. Replicability and immutability may help ensure a level of security and trust between participating entities. They can also help in accountability / attribution of responsibility, as audit paths can be established and erroneous transactions can be located to the source. A consensus mechanism can include that for any data to be added to the ledger, all entities must concede. This may help establish the accuracy of the data.

[0091] It is noted, however, that database 118 is not limited to a specific implementation of a distributed ledger, instead different approaches may be used including, without limitation, blockchain, distributed hash tables (DHTs), etc. Database 118 may be a private database (as opposed to a public database where anyone can pull or push information), as some form of authentication / encryption may need to be employed in order to guarantee the legitimacy of all participating network owners. Implementations of a private database (e.g., private ledger) can include, for example, federated and private blockchains.

[0092] In some embodiments, the score is calculated based on (i) calculating a respective initial score for a respective operator from a plurality of operators in the network based on the data about the NFC including at least one of a name of software used to implement the NFC, a version of the software, and a vendor of the software, (ii) calculating a total initial score comprising an average of the respective initial scores, (iii) calculating an average of the historical behavior of the NFC, and (iv) calculating an average of the total initial score and the average of historical behavior of the NFC.

[0093] A non-limiting example process for calculation of a risk score is as follows. The process can be executed at RSF 108, which can retrieve data from database 118. RSF 108 can receive a request from SCP 104 or NRF 106 to provide a risk score. In the request, information about the NFC 102 (e.g., NFType, NFVersion, and / or NFVendor) is also provided. The example process for calculation of a risk score is shown below:Let NFCID = {NFCNFType, NFCNFVersion, NFCNFVendor} the information in the risk calculation requestStep 1 : Retrieve threat analysis information from M operators from the threat analysis layer intelligent trust database for the given NFCID, TANFCID = list {HNI,list{ timestamp, list{swname, swvendor, swriSk} } }. o For every operator (HNI) in TANFCID with K threat analysis records of NFC■ Calculate risk scoreo Calculate total risk from threat analysis from M operators as the weighted average of all risk scores from all operators (some operators may have more weight than others):ThreatNFCiDStep 2: Retrieve behavioral analysis information from the intelligent trust database for the given NFCID, BANFCID = list{HNI, list {timestamp, request_number, request_distribution, request_content_patterns, request_sequence_patterns } } o Set BehaviorSetNFCiD to empty set o For every operator HNIk in BANFCID with X t behavior analysis records of NFC■ Set BehaviorNFCiD_HNik = 0■ If B ANFCiD.request_number > THRESHOLD and BANFCiD-timestamp < THRESHOLD2• Increase BehaviorNFCiD_HNik by AMOUNT1■ Else• Decrease BehaviorNFCiD_HNik by AMOUNT 1■ If B ANFCiD.request_distribution matches known distribution (e.g., NORMAL, UNIFORM, etc.), with r2> THRESHOLDS• Increase BehaviorNFCiD_HNik by AMOUNT2Else• Decrease BehaviorNFCiD_HNik by AMOUNT2■ If B ANFCiD.request_eontent_patterns matches known content pattern then increase or decrease BehaviorNFCio_HNik by AMOUNTS based on the rule for the known patent match■ If B ANFCio.request_sequence_patterns matches known sequence pattern then increase or decrease BehaviorNFCio_HNik by AMOUNT4 based on the rule for the known sequence match■ If BehaviorNFCio_HNik < 0, then BehaviorNFCio_HNik = 0 else if BehaviorNFCio_HNik > 1, then BehaviorNFCio_HNik = 1■ Add BehaviorNFCio_HNik to BehaviorSetNFCio o Calculate BehaviorSetNFCio by doing an averaging (or weighed averaging) on BehaviorSetNFCio- Step 3: Calculate and return risk score by doing an averaging (or weighted averaging) between ThreatNFCio and BehaviorSetNFCio.

[0094] Technical advantages of embodiments may include faster assessment of risk of an NFC, and / or an ability to calculate risk of an NFC irrespective of the NFC’s availability for providing data.

[0095] Operations of a first computing device (e.g., NRF 106) can be performed by the computing device 700 of Figure 7. Operations of the first computing device have been discussed with reference to the flow chart of Figure 5 according to some embodiments of the present disclosure. For example, modules may be stored in memory 704, in score component 718, and / or threat analysis component 720 of Figure 7, and these modules may provide instructions so that when the instructions of a module are executed by respective first computing device processing circuitry 702, computing device 700 performs respective operations of the flow chart.

[0096] Various operations from the flow chart of Figure 5 may be optional with respect to some embodiments of first computing devices and related methods. For example the operations of blocks 506-512 may be optional.

[0097] Operations of a second computing device (e.g., monitoring NFP 112) can be performed by the computing device 700 of Figure 7. Operations of the second computing device have been discussed with reference to the flow chart of Figure 6 according to some embodiments of the present disclosure. For example, modules may be stored in memory 704of Figure 7, and these modules may provide instructions so that when the instructions of a module are executed by respective second computing device processing circuitry 702, computing device 700 performs respective operations of the flow chart.

[0098] Various operations from the flow chart of Figure 6 may be optional with respect to some embodiments of second computing devices and related methods. For example the operation of block 604 may be optional.

[0099] Figure 7 is a block diagram of a computing device 700 in accordance with some embodiments. The computing device can include at least one of a network node, a computer, a server, and cloud-based nodes or components of a cloud.

[0100] As shown in Figure 7, the computing device 700 includes processing circuitry 702 that is operatively coupled to memory 704, and communication interface 706, and / or any other component, or any combination thereof. Certain computing devices may utilize all or a subset of the components shown in Figure 7. The level of integration between the components may vary from one computing device to another computing device. Further, certain computing devices may contain multiple instances of a component, such as multiple processors, memories, etc.

[0101] The processing circuitry 702 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine -readable computer programs in the memory 704, score component 718, and / or threat analysis component 720. The processing circuitry 702 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, FPGAs, ASICs, etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or DSP, together with appropriate software; or any combination of the above. For example, the processing circuitry 702 may include multiple CPUs.

[0102] In the example, the communication interface 706 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a display, a monitor, a printer, another output device, or any combination thereof. An input device may allow a user to capture information into the computing device 700. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, a forcesensor, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a USB port may be used to provide an input device and an output device.

[0103] The memory 704, score component 718, and / or threat analysis component 720 and / or their components may be or be configured to include memory such as RAM, ROM, PROM, EPROM, EEPROM, magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 704, score component 718, and / or threat analysis component 720 includes one or more application programs, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data. The memory 704, score component 718, and / or threat analysis component 720 may store, for use by the computing device 700, any of a variety of various operating systems or combinations of operating systems.

[0104] The memory 704, score component 718, and / or threat analysis component 720 may be configured to include a number of physical drive units, such as RAID, flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, HD-DVD optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, HDDS optical disc drive, external mini-DIMM, SDRAM, external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a UICC including one or more SIMs, such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an eUICC, iUICC or a removable UICC commonly known as ‘SIM card.’ The memory 704, score component 718, and / or threat analysis component 720 may allow the computing device 700 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 704, score component 718, and / or threat analysis component 720 which may be or comprise a device- readable storage medium.

[0105] The processing circuitry 702 may be configured to communicate with a network using the communication interface 706. The communication interface 706 may comprise one or more communication subsystems. The communication interface 706 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another computing device, local computing device, edge node, cloud node, etc.). Each transceiver may include a transmitter and / or a receiver appropriate to provide network communications (e.g., optical, electrical, and so forth).

[0106] In the illustrated embodiment, communication functions of the communication interface 706 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the GPS to determine a location, another like communication function, or any combination thereof. Communications may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, CDMA, WCDMA, GSM, LTE, NR, UMTS, WiMax, Ethernet, TCP / IP, SONET, ATM, QUIC, HTTP, and so forth.

[0107] Figure 8 shows an example of a communication system 800 in accordance with some embodiments.

[0108] In the example, the communication system 800 (also referred to herein as a network) includes a telecommunication network 802 that includes an access network 804, such as a RAN, and a core network 806, which includes one or more core network nodes 808. The access network 804 includes one or more access network nodes, such as network nodes 810a and 810b (one or more of which may be generally referred to as network nodes 810), or any other similar 3GPP access node or non-3GPP access point. The network nodes 810 facilitate direct or indirect connection of UE, such as by connecting UEs 812a, 812b, 812c, and 812d (one or more of which may be generally referred to as UEs 812) to the core network 806 over one or more wireless connections. A computing device (e.g., computing device 106, 108, 112, 114) can be a core network node 808 or another node comprising a computing device in communication system 800 (including cloud-based node as illustrated in the example in Figure 1).

[0109] 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, the communication system 800 may include any number of wired or wireless networks, computing devices, 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. The communication system 800 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0110] The UEs 812 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with thenetwork nodes 810 and other communication devices. Similarly, the network nodes 810 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 812 and / or with other network nodes or equipment in the telecommunication network 802 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 802.

[0111] In the depicted example, the core network 806 connects the network nodes 810 to one or more hosts, such as host 816. 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. The core network 806 includes one more core network nodes (e.g., core network node 808) 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 the core network node 808. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), AMF, Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), UDM, Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0112] The host 816 may be under the ownership or control of a service provider other than an operator or provider of the access network 804 and / or the telecommunication network 802, and may be operated by the service provider or on behalf of the service provider. The host 816 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.

[0113] As a whole, the communication system 800 of Figure 8 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 andElectronics 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.

[0114] In some examples, the telecommunication network 802 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 802 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 802. For example, the telecommunications network 802 may provide URLLC services to some UEs, while providing eMBB services to other UEs, and / or mMTC / Massive loT services to yet further UEs.

[0115] In some examples, the UEs 812 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 804 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 804. 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 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).

[0116] In the example, the hub 814 communicates with the access network 804 to facilitate indirect communication between one or more UEs (e.g., UE 812c and / or 812d) and network nodes (e.g., network node 810b). In some examples, the hub 814 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 814 may be a broadband router enabling access to the core network 806 for the UEs. As another example, the hub 814 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 810, or by executable code, script, process, or other instructions in the hub 814. As another example, the hub 814 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, the hub 814 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 814 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 814 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub814 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0117] The hub 814 may have a constant / persistent or intermittent connection to the network node 810b. The hub 814 may also allow for a different communication scheme and / or schedule between the hub 814 and UEs (e.g., UE 812c and / or 812d), and between the hub 814 and the core network 806. In other examples, the hub 814 is connected to the core network 806 and / or one or more UEs via a wired connection. Moreover, the hub 814 may be configured to connect to an M2M service provider over the access network 804 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 810 while still connected via the hub 814 via a wired or wireless connection. In some embodiments, the hub 814 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 810b. In other embodiments, the hub 814 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 810b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0118] Figure 9 is a block diagram illustrating a virtualization environment 900 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 900 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a computing device, 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 900 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a SMO 910 Framework via an O-2 interface.

[0119] Applications 902 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in thevirtualization environment 900 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0120] Hardware 904 includes processing circuitry, memory that stores software and / or instructions 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 906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 908a and 908b (one or more of which may be generally referred to as VMs 908), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 906 may present a virtual operating platform that appears like networking hardware to the VMs 908.

[0121] The VMs 908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 906. Different embodiments of the instance of a virtual appliance 902 may be implemented on one or more of VMs 908, 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.

[0122] In the context of NFV, a VM 908 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 908, and that part of hardware 904 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 908 on top of the hardware 904 and corresponds to the application 902.

[0123] Hardware 904 may be implemented in a standalone network node with generic or specific components. Hardware 904 may implement some functions via virtualization. Alternatively, hardware 904 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 (SMO) 910, which, among others, oversees lifecycle management of applications 902. In some embodiments, hardware 904 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 viaone 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 912 which may alternatively be used for communication between hardware nodes and radio units.

[0124] Although the computing devices described herein may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the computing device, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processor and the network interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0125] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to theprocessing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0126] In certain embodiments, a first computing device (106, 700) is provided. The first computing device is configured for trust management for access to a service provided by a NFP in a network. The first computing device includes processing circuitry 702; and memory 704, 718, 720 coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the first computing device to perform operations. The operations include to perform some or all of the functionality described herein.

[0127] In certain embodiments, a non-transitory computer readable medium 704, 718, 720 including program code to be executed by processing circuitry 702 of a first computing device 106, 700 is configured for trust management for NF service access in a network. Execution of the program code causes the program code to perform operations. The operations include to perform some or all of the functionality described herein.

[0128] In certain embodiments, a second computing device (112, 700) is provided. The second incudes a NFP in a network. The second computing device includes processing circuitry 702; and memory 704 coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the second computing device to perform operations. The operations include to perform some or all of the functionality described herein.

[0129] In certain embodiments, a non-transitory computer readable medium 704 including program code to be executed by processing circuitry 702 of a second computing device 112, 700 including a NFP in a network. Execution of the program code causes the program code to perform operations. The operations include to perform some or all of the functionality described herein.

[0130] Further definitions and embodiments are discussed below.

[0131] In the above-description of certain embodiments of the present disclosure, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which concepts of the present disclosure belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0132] When an element is referred to as being “connected”, “coupled”, “responsive”, or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected”, “directly coupled”, “directly responsive”, or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, “coupled”, “connected”, “responsive”, or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and / or clarity. The term “and / or” (abbreviated “ / ”) includes any and all combinations of one or more of the associated listed items.

[0133] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another element / operation. Thus a first element / operation in some embodiments could be termed a second element / operation in other embodiments without departing from the teachings of concepts of the present disclosure. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0134] As used herein, the terms “comprise”, “comprising”, “comprises”, “include”, “including”, “includes”, “have”, “has”, “having”, or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components, or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions, or groups thereof. Furthermore, as used herein, the common abbreviation “e.g.”, which derives from the Latin phrase “exempli gratia,” may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation “i.e.”, which derives from the Latin phrase “id est,” may be used to specify a particular item from a more general recitation.

[0135] Example embodiments are described herein with reference to block diagrams and / or flowchart illustrations of computer-implemented methods, apparatus (systems and / or devices) and / or computer program products. It is understood that a block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computercircuit, and / or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and / or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions / acts specified in the block diagrams and / or flowchart block or blocks, and thereby create means (functionality) and / or structure for implementing the functions / acts specified in the block diagrams and / or flowchart block(s).

[0136] These computer program instructions may also be stored in a tangible computer- readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions / acts specified in the block diagrams and / or flowchart block or blocks. Accordingly, embodiments of the present disclosure may be embodied in hardware and / or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as “circuitry,” “a module” or variants thereof.

[0137] It should also be noted that in some alternate implementations, the functions / acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Moreover, the functionality of a given block of the flowcharts and / or block diagrams may be separated into multiple blocks and / or the functionality of two or more blocks of the flowcharts and / or block diagrams may be at least partially integrated. Finally, other blocks may be added / inserted between the blocks that are illustrated, and / or blocks / operations may be omitted without departing from the scope of the present disclosure. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0138] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present disclosure. All such variations and modifications are intended to be included herein within the scope of present disclosure. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of the presentdisclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

Claims

Claims:

1. A computer implemented method performed by a first computing device for trust management for access to a service provided by a network function producer, NFP, in a network, the method comprising: receiving (500) an identity of a network function consumer, NFC, that made a request to access a service provided by a NFP of a specified type; accessing (502) stored information comprising (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC, the historical behavior comprising data about historical requests that the NFC made towards at least one NF; and making (504) a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

2. The method of Claim 1, further comprising: performing (512) one of (i) handle the request to access the service based on the determination, or (ii) forward the determination to a service communication proxy, SCP.

3. The method of any one of Claims 1 to 2, wherein the at least one NF comprises at least one NF of a similar type.

4. The method of any one of Claims 1 to 3, wherein the determination on how to handle the request comprises a determination of at least one of (i) allow the request, (ii) block the request and further data traffic to and from the NFC, (iii) monitor behavior of the NFC, and (iv) deny the request.

5. The method of any one of Claims 1 to 4, wherein the stored information about the NFC comprises at least one of (i) known vulnerabilities of the NFC provided to the stored information, (ii) a type, version, and / or vendor identifier for the NFC from at least one operator in the network, and (iii) a risk level of software used in the NFC.

6. The method of any one of Claims 1 to 5, wherein the data about historical requests comprises a frequency, a distribution of historical requests in a time domain, and a content of at least one historical request of the NFC towards at least one NF of the same typeas the specified type in the NFC.

7. The method of any one of Claims 1 to 6, wherein when the confidence level is less than a first specified threshold, the determination comprises to allow the request and to initiate routing of subsequent requests of the NFC to a NFP of the specified type of NF to monitor the subsequent requests of the NFC for a time period.

8. The method of Claim 7, further comprising; receiving (506) information from the NFP that monitored the requests of the NFC, the information comprising at least one of (i) a content of packets between the NFC and the NFP that monitored the requests for errors and / or for a pattern of values for at least one parameter that matches a specified type of NFP, (ii) a plurality of deltas between respective requests from a plurality of requests from the NFC towards the NFP that monitored the requests and a comparison of the deltas to an expected periodicity for the subsequent requests, and (iii) a sequence of the requests from the NFC and a comparison of the sequence to a reference sequence; and updating (508) the score and the confidence on the score based on the information from the NFP that monitored the requests and the stored information.

9. The method of Claim 8, wherein when the updated score is less than a second specified threshold and the updated confidence level is greater than the first specified threshold, the determination comprises initiation of a denial of the request and of the subsequent requests of the NFC.

10. The method of any of Claims 1 to 6, wherein when the score is less than a second specified threshold and the confidence level on the score is greater than a first specified threshold and, the determination comprises initiation of a denial of the request and a block of subsequent requests of the NFC.

11. The method of any one of Claims 1 to 6, wherein when the score is greater than a second specified threshold and the confidence level on the score is greater than a first specified threshold, the determination comprises initiation of allowing the request.

12. The method of Claim 11, further comprising: initiating (510) routing the request to an NFP.

13. The method of any one of Claims 1 to 12, wherein the score is calculated based on (i) calculating a respective initial score for a respective operator from a plurality of operators in the network based on the data about the NFC comprising at least one of a name of software used to implement the NFC, a version of the software, and a vendor of the software, (ii) calculating a total initial score comprising an average of the respective initial scores, (iii) calculating an average of the historical behavior of the NFC, and (iv) calculating an average of the total initial score and the average of historical behavior of the NFC.

14. The method of any one of Claims 1 to 13, wherein the stored information comprises information stored in a distributed database.

15. The method of Claim 14, wherein the distributed database comprises a distributed ledger.

16. The method of Claim 15, wherein the distributed ledger comprises a multi-layer blockchain.

17. The method of any one of Claims 1 to 16, wherein the first computing device comprises a network repository function, NRF.

18. The method of Claim 2 and Claim 17, wherein the SCP allows access to a NFP to monitor the subsequent requests.

19. The method of Claim 2 and Claim 17, wherein the SCP allows access to a network function produced, NFP, for the request.

20. The method of Claim 2 and Claim 17, wherein the SCP blocks the request and further data traffic to and from the NFC.

21. A computer- implemented method performed by a second computing device comprising a network function producer, NFP, in a network, the method comprising:receiving (600) a communication to monitor requests of a network function consumer, NFC, for a period of time; and monitoring (602) the requests of the NFC.

22. The method of Claim 21, wherein the monitoring (602) comprises collecting information comprising at least one of (i) a content of packets between the NFC and the NFP for errors and / or for a pattern of values for at least one parameter that matches a specified type of NFP, (ii) a plurality of deltas between respective requests from a plurality of requests from the NFC towards the NFP and a comparison of the deltas to an expected periodicity for the subsequent requests, and (iii) a sequence of the requests from the NFC and a comparison of the sequence to a reference sequence.

23. The method of Claim 22, further comprising: sending (604) the information to one of a first computing device comprising a network repository function, NRF, and a third computing device comprising a threat analysis function, TAF.

24. A first computing device (106, 700) configured for trust management for access to a service provided by a network function producer, NFP, in a network, the first computing device comprising: processing circuitry (702); memory (704, 718, 720) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the first computing device to perform operations comprising: receive an identity of a network function consumer, NFC, that made a request to access a service provided by a NFP of a specified type; access stored information comprising (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC, the historical behavior comprising data about historical requests that the NFC made towards at least one NF; and make a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

25. The first computing device of Claim 24, wherein the operations further comprise any of the operations of Claims 2 to 20.

26. A non-transitory computer readable medium (704, 718, 720) including program code to be executed by processing circuitry (702) of a first computing device (106, 700) configured for trust management for network function, NF, service access in a network, whereby execution of the program code causes the program code to perform operations comprising: receive an identity of a network function consumer, NFC, that made a request to access a service provided by a network function producer, NFP, of a specified type; access stored information comprising (i) a score that indicates a level of trust of the NFC based on data about the NFC and (ii) a confidence level on the score based on an analysis of historical behavior of the NFC, the historical behavior comprising data about historical requests that the NFC made towards at least one NF; and make a determination, based on at least one of the score and the confidence level on the score, on whether to trust the NFC.

27. A second computing device (112, 700) comprising a network function producer, NFP, in a network, the second computing device comprising: processing circuitry (704); memory (704) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the second computing device to perform operations comprising: receive a communication to monitor requests of a network function consumer, NFC, for a period of time; and monitor the requests of the NFC.

28. The second computing device of Claim 27, wherein the operations further comprise any of the operations of Claims 22 to 23.

29. A non-transitory computer readable medium (704) including program code to be executed by processing circuitry (902) of a second computing device (112, 700) comprising a network function producer, NFP, in a network, whereby execution of the program code causes the program code to perform operations comprising:receive a communication to monitor requests of a network function consumer, NFC, for a period of time; and monitor the requests of the NFC.

Images