resource owner permissioned application programming interface (API) access to resources

Abstract

Embodiments include methods for application programming interface (API) exposure function (AEF) of a communication network. The methods include receiving, from an API invocation entity, a request to invoke an API for a resource in the communication network. The resource is owned by a resource owner, and an access token is included in the request. The methods include determining whether the access token is a resource owner-aware northbound API access (RNAA) token. When it is determined that the access token is a RNAA token, such methods include verifying integrity of the RNAA token, but refraining from verifying resource owner permission of the API invocation entity to access the resource, and invoking the API for the resource according to the request when the verification of the integrity of the RNAA token is successful. Other embodiments include complementary methods for NFs and AEFs configured to perform such methods.

Description

Technical Field

[0001] This application generally relates to the field of wireless communication networks, and more specifically, to techniques for improving the security of application programming interfaces (APIs) used in communication networks. Background Technology

[0002] Currently, fifth-generation (5G) cellular systems, also known as New Radio (NR), are being standardized within the Third Generation Partnership Project (3GPP). NR is being developed to achieve maximum flexibility to support a wide variety of distinct use cases. These use cases include enhanced mobile broadband (eMBB), ultra-low latency critical communications (URLCC), sidelink device-to-device (D2D), and several others. 5G was initially defined in 3GPP Release 15 (Rel-15) and has continued to evolve through subsequent releases.

[0003] One change in 5G networks is the modification and / or replacement of traditional peer-to-peer interfaces and protocols established in previous-generation networks through a service-based architecture (SBA). In SBA, network functions (NFs) in the 5G core network (5GC) provide services to one or more service consumers. Generally, various services are self-contained functions, which can be changed and modified in an isolated manner without affecting other services.

[0004] For example, the Unified Data Management (UDM) function supports the generation of 3GPP authentication credentials, user identity processing, access authorization based on subscription data, and other subscriber-related functions. The Network Openness Function (NEF) acts as the entry point to the operator's 5G core network (5GC) by securely opening network capabilities and events provided by other NFs and by providing Application Functions (AFs) with a way to securely provide information to (or receive information from) the 5GC. The Network Repository Function (NRF) allows each NF to discover services provided by other NFs.

[0005] 3GPP specifications define multiple northbound application programming interfaces (APIs), including those defined in 3GPP TS 23.682 (v18.0.0) and 3GPP TR 26.981 (v17.0.0). To avoid duplication and inconsistencies between different API specifications, 3GPP has defined a Common API Framework (CAPIF), which includes common aspects applicable to all northbound service APIs. Note that the term "service API" refers to an interface through which system components expose their services to API callers by isolating services from underlying mechanisms, while the term "northbound API" (or "northbound service API") refers to the service API exposed to higher-level API callers.

[0006] Figure 1 This illustrates some typical business relationships involved in CAPIF. API callers are typically provided by third-party application providers who have service agreements with the CAPIF provider. The API provider hosts one or more service APIs and has a service API agreement with the CAPIF provider to provide these service APIs to API callers. The CAPIF provider and the API provider can belong to the same organization (e.g., a PLMN operator), in which case the business relationship between them is within a single organization. Alternatively, the CAPIF provider and the API provider can belong to different organizations, in which case a business relationship between them is mandatory.

[0007] Figure 2 This is a functional model diagram of CAPIF. The core CAPIF function (CCF, 220) is hosted within the PLMN operator network. API callers (210) are typically provided by third-party application providers with service agreements with the CAPIF provider. API callers can reside within the same trust domain as the PLMN operator network. The API provider domain's API Open Function (AEF, 230), API Publishing Function (APF, 240), and API Management Function (250) are collectively referred to as API provider domain functions. The AEF is the entity that serves as the service communication entry point for providing the API.

[0008] 3GPP TS 33.122 (v18.1.0) defines the security architecture of CAPIF. One security process is the authorization of API callers by the AEF, which is further specified in Section 8.16 of 3GPP TS 23.222 (v18.1.0) and Section 6.5 of 3GPP TS 33.122. Another process specified in Section 6.5.3 of 3GPP TS 33.122 is the resource owner authorization before CAPIF allows access to resources via the northbound API. According to this process, the CCF checks the resource owner authorization, and if authorization has been granted, the CCF issues an access token to the API caller for use against the corresponding AEF, which can be a NEF or a similar function in the Service Enablement Architecture Layer (SEAL, discussed further below). The API caller presents the access token to the AEF, and the AEF provides services to the API caller after verifying the access token. User location information is an example of a resource controlled by resource owner authorization.

[0009] 3GPP has specified that SEAL supports vertical applications on 5G networks. SEAL services include group management, configuration management, location management, identity management, key management, and network resource management. SEAL provides these services to various Vertical Application Layers (VALs) that can run on top of SEAL, corresponding to various applications. Specifically, the UE may include a SEAL group management client that communicates with a corresponding SEAL group management server inside (or outside) the 5GC. The group management client provides group management services to VAL clients within the UE that communicate with corresponding VAL servers inside (or outside) the 5GC. The VAL servers also communicate with the SEAL group management server.

[0010] The 3GPP standard specifies various methods for locating a UE operating in an NR network (e.g., determining the location of the UE, locating the UE, and / or determining the location of the UE). Generally, the location node configures the target device (e.g., the UE) and / or RAN nodes (e.g., gNB, ng-eNB, etc.) to perform one or more location measurements according to one or more location methods. For example, location measurements may include timing (and / or timing difference) measurements of the UE, network, and / or satellite transmissions. The location measurement values ​​are used by the target device, the measurement node, and / or the location node to determine the location of the target device.

[0011] 3GPP TS 23.273 (v18.3.0) specifies 5G Location Services (LCS). The two LCS procedures specified in 3GPP TS 23.272 are 5GC Mobility Termination Location Request (MT-LR) and Side Link (SL) MT-LR. Note that SL is a type of device-to-device (D2D) communication where UEs communicate directly with each other, rather than indirectly via the 3GPP RAN. Both 5GC-MT-LR and SL-MT-LR include privacy mechanisms, where permission to share UE location information with the AF is stored in the UE privacy profile in the UDM, as specified in Table 5.2.3.3.1-1 of 3GPP TS 23.502 (v18.3.0). Summary of the Invention

[0012] When the resource owner is aware that CAPIF is used to expose user location information to the AF, privacy checks will be performed more than once in different locations. Additionally, the UE privacy profile will be stored in multiple locations: in the CAPIF layer and UDM for location services, and in the CAPIF layer and SEAL. This can create various redundancies and increase the complexity of permission checks in 5GC.

[0013] The purpose of embodiments of this disclosure is to address these and other problems, challenges and / or difficulties associated with restricting access to resources by authorized resource owners, thereby facilitating the advantageous deployment of CAPIF in 5G networks.

[0014] Some embodiments include exemplary methods (e.g., procedures) for API Open Functions (AEF) for communication networks (e.g., 5GC).

[0015] These exemplary methods include receiving a request from an API calling entity to invoke an API for a resource in a communications network. The resource is owned by a resource owner, and the request includes an access token. These exemplary methods include determining whether the access token is a resource owner-aware Northbound API Access (RNAA) token. When it is determined that the access token is an RNAA token, these exemplary methods include the following operations:

[0016] • Verify the integrity of the RNAA token, but refrain from verifying the resource owner's permission for the API calling entity to access the resource; and

[0017] • When the integrity of the RNAA token is successfully verified, the API for that resource is invoked based on the request.

[0018] In some embodiments, the access token is determined to be an RNAA token based on the access token including an identifier of the resource owner. In some embodiments, when it is determined that the access token is not an RNAA token, these exemplary methods include the following operations:

[0019] • Verify the resource owner's permission for the API caller to access the resource; and

[0020] • When the verification of the resource owner's permission for the API calling entity to access the resource is successful, the API for that resource is invoked according to the request.

[0021] In some of these embodiments, when verification of permission to access the resource owner fails, these exemplary methods also include avoiding invoking the API for the resource based on the request.

[0022] In some embodiments, the API is associated with a network function (NF) of a communication network, and invoking the API for the resource includes sending a request to the NF for the resource, wherein the request includes an indication that permission has been obtained from the resource owner for the API-calling entity to access the resource.

[0023] Other embodiments include exemplary methods (e.g., processes) for NFs used in communication networks (e.g., 5GC).

[0024] These exemplary methods include receiving an API call from the AEF of a communication network for a resource within the communication network. The resource is owned by a resource owner, and the call represents an API calling entity. These exemplary methods determine whether the request includes an indication that permission has been obtained from the resource owner to access the resource. When it is determined that the request includes this indication, these exemplary methods include the following operations:

[0025] • Avoid verifying the resource owner's permission for the API calling entity to access the resource;

[0026] • Obtain the resource from the communication network; and

[0027] • Send the acquired resources to AEF.

[0028] In some embodiments, when it is determined that the request does not include the instruction, these exemplary methods further include the following operations:

[0029] • Verify the resource owner's permission for the API caller to access the resource; and

[0030] • When the verification of the resource owner's permission for the API calling entity to access the resource is successful:

[0031] o Obtain the resource from the communication network, and

[0032] o sends the acquired resources to AEF.

[0033] In some of these embodiments, these exemplary methods further include: avoiding obtaining the resource from the communication network when verification of the resource owner's permission for the API calling entity to access the resource fails.

[0034] In some embodiments, the API is associated with an NF, and a call to the API includes a request for that resource.

[0035] Other embodiments include AEF and NF (or network devices configured to perform operations corresponding to any of the exemplary methods described herein). Other embodiments include a non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry, configure the AEF and NF to perform operations corresponding to any of the exemplary methods described herein.

[0036] The embodiments disclosed herein can provide various benefits and / or advantages. For example, by avoiding redundant privacy checks, the embodiments can eliminate the processing of UE privacy profiles at different layers and / or network entities required in conventional solutions. Furthermore, the embodiments can improve the efficiency of security processes when using a CAPIF architecture in a network. More generally, the embodiments can improve the security of CAPIF in 5G networks.

[0037] These and other objects, features, and advantages of this disclosure will become apparent when read in conjunction with the accompanying drawings, which are briefly described below. Attached Figure Description

[0038] Figure 1 This illustrates some typical service relationships involved in the Common API Framework (CAPIF) of 3GPP networks.

[0039] Figure 2 This is the functional model diagram of CAPIF.

[0040] Figure 3 An exemplary 5G network architecture is shown.

[0041] Figure 4 A signaling diagram is shown for an exemplary process used by API callers to authorize access to a service API.

[0042] Figure 5 A signaling diagram illustrating an exemplary process for CAPIF-2e interface authentication and protection using access tokens is shown.

[0043] Figure 6 A block diagram of the functional model for SEAL-based group management is shown.

[0044] Figure 7 An exemplary location information subscription request process is shown as specified in section 9.3.7 of 3GPP TS 23.434 (v18.6.0).

[0045] Figure 8 An exemplary on-demand location information reporting process is shown, as specified in section 9.3.4 of 3GPP TS 23.434 (v18.6.0).

[0046] Figure 9 An exemplary off-network location information reporting process is shown, as specified in section 9.5.4 of 3GPP TS 23.434 (v18.6.0).

[0047] Figures 10 to 11 A signaling diagram illustrating an exemplary process for authorizing access to resources based on RNAA tokens according to various embodiments of this disclosure is shown.

[0048] Figure 12 Exemplary methods (e.g., processes) for API Open Functions (AEF) in a communication network according to various embodiments of this disclosure are shown.

[0049] Figure 13 Exemplary methods (e.g., processes) for network functions (NFs) in a communication network according to various embodiments of this disclosure are shown.

[0050] Figure 14 Communication systems according to various embodiments of the present disclosure are shown.

[0051] Figure 15 Network nodes according to various embodiments of this disclosure are shown.

[0052] Figure 16 Some embodiments of this disclosure illustrate virtualized environments in which virtualization can be performed. Detailed Implementation

[0053] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0054] Generally, unless explicitly defined and / or implied by the context of use, all terms used herein are to be interpreted according to their ordinary meaning to those skilled in the art. Unless otherwise expressly stated or clearly implied by the context of use, all references to “an / element, device, component, apparatus, step, etc.” should be openly interpreted as referring to at least one instance of an element, device, component, apparatus, step, etc. Unless explicitly described as an operation following or preceding another operation and / or implied that an operation must follow or precede another operation, the operation of any methods and / or processes disclosed herein need not be performed in the exact order disclosed. Where appropriate, any feature of any embodiment disclosed herein may be applied to any other disclosed embodiment. Similarly, where appropriate, any advantage of any embodiment described herein may be applied to any other disclosed embodiment.

[0055] In addition, the following terms are used throughout the description given below:

[0056] • Radio Access Node: As used herein, a “radio access node” (or equivalently, a “radio network node,” “radio access network node,” or “RAN node”) can be any node in a radio access network (RAN) that operates to wirelessly transmit and / or receive signals. Some examples of radio access nodes include, but are not limited to, base stations (e.g., gNBs in 3GPP 5G / NR networks or enhanced node Bs or eNBs in 3GPP LTE networks), base station distributed components (e.g., CUs and DUs), high-power or macro base stations, low-power base stations (e.g., micro, pico, femto, or femto base stations), integrated access backhaul (IAB) nodes, transport points (TPs), transport receiver points (TRPs), remote radio units (RRUs or RRHs), and relay nodes.

[0057] • Core Network Node: As used in this document, a “core network node” is any type of node in the core network. Some examples of core network nodes include, for example, Mobility Management Entity (MME), Serving Gateway (SGW), PDN Gateway (P-GW), Policy and Charging Rules Function (PCRF), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Charging Function (CHF), Policy Control Function (PCF), Authentication Server Function (AUSF), Location Management Function (LMF), etc.

[0058] • Wireless Device: As used herein, a “wireless device” (or “WD” for short) is any type of device capable of, configured to, arranged to, and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Wireless communication may involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information over the air. Unless otherwise stated, the term “wireless device” is used interchangeably herein with the term “user equipment” (or “UE” for short), which have a different meaning from the term “network node”.

[0059] • Radio node: As used herein, “radio node” can be a “radio access node” (or equivalent term) or a “wireless device”.

[0060] • Network Node: As used herein, a “network node” is any node that is part of the radio access network (e.g., radio access node or equivalent term) or the core network (e.g., the core network node discussed above) of a cellular communication network. Functionally, a network node is a node that is capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with wireless devices and / or with other network nodes or devices in the cellular communication network, to provide and / or enable radio access to wireless devices, and / or to perform other functions (e.g., management) in the cellular communication network.

[0061] • Node: As used herein, the term “node” (without prefix) can be any type of node capable of operating in or with a wireless network (including RAN and / or core network), including radio access nodes (or equivalent terms), core network nodes, or wireless devices. However, the term “node” may be limited to a particular type (e.g., radio access node, IAB node) based on its specific characteristics in any given context.

[0062] The above definitions are not exclusive. In other words, the various terms used above may be interpreted and / or described elsewhere in this disclosure using the same or similar terms. However, if such other interpretations and / or descriptions conflict with the above definitions, the above definitions shall prevail.

[0063] Note that the description given herein focuses on 3GPP cellular communication systems, and therefore 3GPP terminology or similar terms are frequently used. However, the concepts disclosed herein are not limited to 3GPP systems and can be applied to any system that can benefit from the concepts, principles, and / or embodiments described herein.

[0064] At a high level, a 5G system (5GS) consists of an access network (AN) and a core network (CN). The AN provides the UE to the CN, for example, via a base station (e.g., a gNB or ng-eNB hereinafter). The CN includes various network functions (NFs) that provide a variety of functions, such as session management, connection management, accounting, authentication, etc.

[0065] Figure 3 An exemplary non-roaming reference architecture for a 5G network (300) is shown. These include the following NFs and service-based interfaces defined by 3GPP:

[0066] • Application Function (AF, with NAF interface) interacts with the 5GC to provide information to the network operator and subscribe to specific events occurring in the operator's network. AF provides applications that deliver services at a different layer (i.e., the transport layer) than the layer that has already requested the service (i.e., the signaling layer), controlling flow resources based on content already negotiated with the network. AF transmits dynamic session information to the PCF (via the N5 interface), including a description of the media to be transmitted by the transport layer.

[0067] • The Policy Control Function (PCF, with an NPCF interface) supports a unified policy framework for managing network behavior by providing PCC rules (e.g., regarding the processing of each service data flow under PCC control) to the SMF via the N7 reference point. The PCF provides the SMF with policy control decisions and flow-based charging control (including service data flow detection, gating, QoS, and flow-based charging (in addition to credit management)). The PCF receives session and media-related information from the AF and notifies the AF of service (or user) plane events.

[0068] • User Plane Function (UPF) – Supports processing user plane traffic based on rules received from the SMF, including packet inspection and various execution actions (e.g., event detection and reporting). The UPF communicates with the RAN (e.g., NG-RNA) via reference point N3, with the SMF (discussed below) via reference point N4, and with the external Packet Data Network (PDN) via reference point N6. Reference point N9 is used for communication between two UPFs.

[0069] • Session Management Function (SMF, with Nsmf interface) interacts with the decoupled business (or user) plane, including creating, updating, and deleting Protocol Data Unit (PDU) sessions and managing session contexts using User Plane Functions (UPF), such as for event reporting. For example, SMF performs data flow inspection (based on filter definitions included in PCC rules), online and offline billing interactions, and policy enforcement.

[0070] • The Billing Function (CHF, with an Nchf interface) is responsible for integrating online and offline billing functions. The Billing Function provides quota management (for online billing), reauthorization triggers, rating conditions, etc., and is notified of usage reports from the SMF. Quota management involves granting a specific number of units (e.g., bytes, seconds) to a service. The CHF also interacts with the accounting system.

[0071] • Access and Mobility Management Function (AMF, with Namf interface) terminates the RAN CP interface and handles all mobility and connectivity management for the UE (similar to the MME in the EPC). The AMF communicates with the UE via the N1 reference point and with the RAN (e.g., NG-RAN) via the N2 reference point.

[0072] • Network Open Function (NEF) with Nnef interface – This serves as an entry point to the operator's network by securely opening network capabilities and events provided by the 3GPP NF to the AF and by providing the AF with a way to securely provide information to the 3GPP network. For example, NEF provides services that allow the AF to provide specific subscription data (e.g., expected UE behavior) for various UEs.

[0073] • Network repository functionality with NnRF interface (NRF, 210) – provides service registration and discovery, enabling NFs to identify and / or discover appropriate services available from other NFs.

[0074] • 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 features, such as supporting specific services. A network slice instance is a collection of NF instances that provide the capabilities and features of a network slice and the required network resources (e.g., compute, storage, communication). NSSF enables other NFs (e.g., AMFs) to identify network slice instances suitable for the UE's desired services.

[0075] • Authentication Server Functionality with Nausf Interface (AUSF) – Based on the user’s Home Network (HPLMN), it performs user authentication and computes security key material for various purposes.

[0076] • Network Data Analysis Functionality (NWDAF) with Nnwdaf interface – provides network analysis information (e.g., statistics and / or predictions of past events) to additional NFs at the network slice instance level.

[0077] • Location Management Function (LMF) with Nlmf interface – Supports various functions related to UE location determination, including UE location determination and obtaining any of the following: DL location measurement or location estimate from the UE; UL location measurement from the NGRAN; and non-UE associated auxiliary data from the NGRAN.

[0078] • Unified Data Management (UDM) functionality with Nudm interface – supports 3GPP authentication credential generation, user identity processing, access authorization based on subscription data, and other subscriber-related functions. To provide this functionality, UDM uses subscription data (including authentication data) stored in the 5GC Unified Data Repository (UDR).

[0079] The services provided by various Service Providers (NFs) consist of "service operations," which are finer-grained divisions of the overall service functionality. The interaction between service consumers and producers can be of the "request / response" or "subscription / notification" type. In the latter type, the service consumer NF (or equivalently, the "consumer NF") requests the service producer NF (or equivalently, the "producer NF") to establish a subscription so that the service consumer NF can receive notifications from the service producer NF under the conditions specified in the subscription.

[0080] As briefly mentioned above, 3GPP has defined the Common API Framework (CAPIF), which includes common aspects applicable to any northbound service API. (The above is combined with...) Figures 1 to 2 CAPIF has been described, and the following description will refer to it. Figures 1 to 2 3GPP TS 33.122 (v17.1.0) defines the security architecture for CAPIF, including the process by which AEF authorizes API callers.

[0081] Figure 4 A signaling diagram is shown for an exemplary procedure for an API caller to authorize access to a service API, which is further specified in Section 8.16 of 3GPP TS 23.222 (v18.1.0) and Section 6.5 of 3GPP TS 33.122. Although Figure 4 The operations shown are given numerical labels, but this is done for illustrative purposes and not to require or imply any particular order of operations, unless otherwise explicitly stated.

[0082] In operation 1, the API caller (410) triggers a service API call request to the AEF (430), including the service API to be called. Note that the API caller can trigger several service API calls asynchronously. The API caller can provide authorization information in the request.

[0083] In Operation 2, upon receiving a service API call request, AEF checks whether the API caller is authorized to invoke the service API based on authorization information. In Operation 2a, if AEF does not have the information required to authorize the service API call (e.g., the API caller is not included in the request), AEF obtains the authorization information from the CAPIF core functionality (CCF, 420).

[0084] In operation 3, AEF executes the service logic for the called service API. In operation 4, the API caller receives the service API call response as the result of the service API call.

[0085] 3GPP TS 33.122 specifies the use of the OAuth 2.0 protocol for API callers who include authorization information in Operation 1. IETF RFC 6749 specifies the roles of authorization server, authorization client, and resource server in the OAuth 2.0 framework. To obtain... Figure 4 The authorization information provided in Operation 1 indicates that CCF acts as the authorization server, while the API caller acts as both the client and the resource server.

[0086] Figure 5 A signaling diagram illustrating an exemplary process for CAPIF-2e interface authentication and protection using OAuth 2.0 access tokens is shown, which is further specified in section 6.5.2.3 of 3GPP TS 33.122. Although Figure 5 The operations shown are given numerical labels, but this is done for illustrative purposes and not to require or imply any particular order of operations, unless otherwise explicitly stated.

[0087] In Operation 1, CAPIF-1e authentication and secure session establishment are performed as specified in Section 6.3.1 of 3GPP TS 33.122. In Operation 2, after a Transport Layer Security (TLS) session is successfully established via CAPIF-1e, the API caller (510) sends an access token request message to the CCF (520) in accordance with IETF RFC 6749. The API caller may include the API caller ID and Onboard_Secret assigned by the CCF in the access token request message to enable the CCF to verify the access token request.

[0088] In Operation 3, the CCF verifies the access token request message according to IETF RFC 6749. If the CCF successfully verifies the access token request message, in Operation 4, the CCF generates an access token specific to the API caller and returns the access token in the access token response message.

[0089] In Operation 5, on CAPIF-2e, the API caller establishes a TLS session with the AEF (530) based on the authentication and authorization method indicated by the CCF (specifically, server-side (AEF) certificate authentication or certificate-based mutual authentication). The API caller and the AEF may perform other procedures prior to establishing the TLS session, as further specified in 3GPP TS 33.122.

[0090] In Operation 6, after successful AEF authentication on CAPIF-2e, the API caller initiates a 3GPP northbound API call to the AEF. The API caller, in accordance with IETF RFC 6749, sends the access token received from the CCF along with the northbound API call request. In Operation 7, the AEF verifies the access token, including verifying its integrity based on the CCF signature. If the access token verification is successful, the AEF verifies the API caller's northbound API call request against the authorization statement in the access token, ensuring that the API caller has permission to access the requested service API.

[0091] In operation 8, after successfully verifying the API caller's access token and authorization statement, the requested northbound API is invoked and an appropriate response is returned to the API caller.

[0092] As briefly mentioned above, 3GPP Release 18 CAPIF includes the feature of Resource Owner Aware Northbound API Access (RNAA). This feature requires authorization from the resource owner to grant access to an owned resource if an API call results in access to that resource. User location information is an example of a resource controlled by the resource owner's authorization. As specified in Section 6.5.3 of 3GPP TS33.122, RNAA uses the OAuth 2.0 framework, where the API caller acts as an OAuth 2.0 client, the CCF acts as an OAuth 2.0 authentication server providing the access token for RNAA, and the AEF acts as the resource server. The access token for RNAA includes the resource owner ID, the API caller ID, and other claims.

[0093] According to the RNAA process, the CCF checks the resource owner's permission, and if permission is granted, the CCF issues an access token to the API caller for use against the corresponding AEF, which can be a NEF or a similar function in the Service Enablement Architecture Layer (SEAL, discussed further below). The API caller presents the access token to the AEF with a call request. The AEF checks the request against the token, including the resource owner ID. Because the token includes the resource owner ID, no additional UE authentication is required during the API call. Furthermore, the access token should be able to restrict the API caller to a specific resource (e.g., location, QoS, PDN connection state). If the request is verified against the access token, the AEF provides the requested service to the API caller, who then accesses the resource owner's resource (e.g., user location) via the API call.

[0094] 3GPP TS 23.273 (v18.3.0) specifies the LCS for 5G, including the 5GC Mobile Termination Location Request (MT-LR) and Side Link (SL) MT-LR procedures. Both 5GC-MT-LR and SL-MT-LR include privacy mechanisms, where permission to share UE location information with the AF is stored in the UE privacy profile in the UDM, as specified in Table 5.2.3.3.1-1 of 3GPP TS 23.502 (v18.3.0).

[0095] Section 6.1.2 of 3GPP TS 23.273 describes the 5G-MT-LR procedure for commercial LCS. The LCS client, NF, or AF (via NEF) sends a request to the Gateway Mobile Location Center (GMLC) for the location and selectable speed of a target UE, identified by a Common Public Subscription Identifier (GPSI) or Subscription Permanent Identifier (SUPI). The LCS client, AF, or NF making the request needs to be authorized to use the commercial LC.

[0096] In operation 2 of this procedure, the GMLC invokes the Nudm_SDM_Get service operation on the target UE's UDM to obtain the UE's privacy settings identified by GPSI or SUPI. The UDM returns the target UE's privacy profile checked by the GMLC. If locating the target UE is not permitted, the remaining operations of the procedure are skipped.

[0097] In operation 3, the GMLC invokes the Nudm_UECM_Get service operation to the target UE's UDM via PSI or SUPI. The UDM returns the network address of the target UE's current serving AMF. In operation 5, the GMLC invokes the Namf_Location_ProvidePositioningInfo service operation to the AMF to request the UE's current location. If the privacy check in operation 2 indicates that the UE must be notified or must be notified via privacy verification, and if the UE supports LCS notification (based on UE capability information), then in operation 7, the AMF sends a notification invocation message to the target UE, indicating the LCS client's identity and service type (if both supported and available) and whether privacy verification is required.

[0098] If the privacy check in Operation 2 indicates that further privacy checks are required, then in Operation 16, the GMLC performs additional privacy checks to determine whether the GMLC can forward location information to the LCS client or AF, or to send a notification if the result of the privacy check requires notification and verification based on the current location. An example where such additional privacy checks are needed is when the target UE user has defined different privacy settings for different geographic locations.

[0099] Section 6.20.3 of 3GPP TS 23.273 describes the SL-MT-LR procedure involving the Location Management Function (LMF) in 5GC. This procedure enables the LCS client or AF to obtain ranging / SL positioning results for a group of n UEs (n≥2) (i.e., UE1, UE2...UEn). The LCS client or AF (via NEF) sends an LCS service request for the ranging / SL positioning results of the n UEs to the GMLC. These n UEs can be identified by their respective application layer IDs, GPSI, or SUPI.

[0100] In operation 2, the GMLC invokes the Nudm_SDM_Get service operation on the UDM of each of the n target UEs (identified by GPSI or SUPI) to obtain the corresponding UE LCS privacy profile. The GMLC checks the corresponding UE privacy profile, and if locating a specific UE is not allowed, it skips the rest of the procedure for that UE.

[0101] In operation 3, the GMLC uses the GPSI or SUPI of each UE to sequentially call the Nudm_UECM_Get service operation to the UDM of each of the n UEs (whose GPSI or SUPI is available). The GMLC selects the UE that initiated ranging / SL positioning (referred to as UE1) and selects the corresponding serving AMF. In operation 5, the GMLC calls the Namf_Location_ProvidePositioningInfo service operation to the AMF serving UE1 to request the SL positioning / ranging results of the n UEs.

[0102] If the privacy check instruction in Operation 2 must notify UE1 or must notify UE1 via privacy verification, and if the UE supports LCS notification (based on the UE capability information), then in Operation 7, the AMF sends a notification invocation message to UE1 indicating the identity and service type of the LCS client (if both supported and available) and whether privacy verification is required.

[0103] As briefly mentioned above, 3GPP has defined the Service Enablement Architecture Layer (SEAL) to support vertical applications on 5G networks. SEAL services include group management, configuration management, location management, identity management, key management, and network resource management. SEAL provides these services to the Vertical Application Layer (VAL) that can run on top of SEAL (e.g., corresponding to various applications).

[0104] SEAL can use various information for VAL group management, including VAL group ID, group member UE ID, general group configuration, group data network name (DNN), single network slice selection assistance information (S-NSSAI), group size, group leader, group location information, enabled VAL services, VAL service-specific information, PDU session type, etc. This information is further specified in Section 10 of 3GPP TS 23.434 (v18.6.0) and Clause 7.2.1.4 of 3GPP TS 29.549 (v17.8.0).

[0105] Figure 6 A block diagram of a functional model for SEAL-based group management is shown. The VAL UE may include a SEAL group management client that communicates with a corresponding SEAL group management server outside the 3GPP network via a GM-UU interface. The group management client provides group management services to the UE VAL client within the UE via a GM-C interface. The VAL client communicates with a corresponding VAL server outside the 3GPP network via a VAL-UU interface. The VAL server also communicates with the SEAL group management server via a GM-S interface.

[0106] The group management server interacts with the NEF of the 3GPP network via the N33 reference point to perform group management procedures for 5G Virtual Network (5GVN) groups. Group management functions defined by 3GPP SA6 involve group creation, group information querying, group member updates, group announcements and joining, and group member leaving. Members of a VAL group can communicate with each other, but are "invisible" to members of other VAL groups. Even so, inter-group communication can be achieved via the N19 reference point in the 5GC, which connects two UPFs, for directly routing services between different PDU sessions without using [other methods / methods]. Figure 2 The N6 reference point is shown.

[0107] SEAL also includes its own privacy mechanism for location information sharing. Figure 7 An exemplary location information subscription request process as specified in Section 9.3.7 of 3GPP TS 23.434 (v18.6.0) is illustrated. In Operation 1, the VAL server sends a location information subscription request to the location management server (SEAL LM server) to subscribe to the location information of one or more VAL users (or VAL UEs). This request may include indications for supplementary location information and location QoS, indicating location accuracy, response time, and QoS category, as defined in Section 4.1b of 3GPP TS 23.273. In Operation 2, the location management server checks whether the VAL server is authorized to initiate a location information subscription request for the UE, i.e., whether the VAL server is authorized to obtain the UE's location information. Figure 7 The remaining operations shown are described in section 9.3.7 of 3GPP TS 23.434 (v18.6.0) and may involve 3GPP CN (e.g., 5GC), such as Figure 5 As shown.

[0108] Figure 8 An exemplary on-demand location information reporting process, as specified in Section 9.3.4 of 3GPP TS 23.434 (v18.6.0), is illustrated. In Operation 1, based on configurations such as periodic location information timers or location information requests from other entities (e.g., another location management client, VAL server, etc.), the location management server initiates an immediate request for location information to the location management client. In Operation 2, the location management server sends the location information request to the location management client. In Operation 3, the VAL user (or VAL UE) is notified and asked for permission to share its location. For example, the VAL user can accept or reject the request.

[0109] In operation 4, the location management client immediately responds to the location management server with a report containing location information that is recognized by the location management server and usable by the location management client (if the location management client was authorized in operation 3). In operation 5, upon receiving the report, the location management server updates the location of the reporting location management client. If the location management server has not previously reported location information for a location management client, it stores the reported location information of that client.

[0110] Figure 9 An exemplary off-network location information reporting procedure is illustrated as specified in Section 9.5.4 of 3GPP TS 23.434 (v18.6.0). This procedure involves on-demand location reporting from Location Management Client 1 residing in UE-1 to Location Management Client 2 residing in UE-2. UE-1 and UE-2 are within each other's SL communication range and know each other's Layer 2 IDs. The VAL service user in UE-1 is authorized to request a location report from UE-2 and requests UE-2 to perform a location report immediately.

[0111] In Operation 1, based on configurations such as a periodic location information timer, Location Management Client 1 initiates an immediate request for location information to Location Management Client 2 by sending an off-network location request to Location Management Client 2. This message includes the information elements specified in Table 9.5.2.7-1 of 3GPP TS 23.434 (v18.6.0).

[0112] In operation 2, UE-2 (or its VAL user) is notified and asked for permission to share its location. The VAL user can, for example, accept or reject the request. In operation 3, if permission is received from the VAL user, location management client 2 includes a report containing location information identified by location management client 1 and usable by location management client 2. This message includes the information elements specified in Table 9.5.2.8-1 of 3GPP TS 23.434 (v18.6.0).

[0113] In operation 4, upon receiving the off-network location report trigger configuration response message, location management client 1 sends an off-network location management response message. This message includes the information elements specified in clause 9.5.2.3 of 3GPP TS 23.434 (v18.6.0).

[0114] In summary, when a resource owner is aware that CAPIF is used to expose user location information to the AF, privacy checks will be performed more than once in different places. For example, CAPIF AEF will perform privacy checks (e.g., before allowing a requester to make an API call) Figure 5 Operation 7), and GMLC will also perform privacy checks (e.g., 5GC-MT-LR Operation 2). Additionally, the UE privacy profile will be stored in multiple locations: in the CAPIF layer and UDM for location services, and / or in the CAPIF layer and SEAL for SEAL services. This redundant privacy checks and redundant UE privacy profile storage can introduce complexity to location services and other services that support user privacy.

[0115] The embodiments of this disclosure address these and other problems, challenges, and / or difficulties by providing a novel, flexible, and efficient technique in which the CCF (acting as an authorization server) issues RNAA access tokens to API callers. When an API caller presents an access token to the AEF, the AEF (e.g., NEF, SEAL location management server, etc.) bypasses its routine privacy checks based on the determination that it is an RNAA token that has undergone privacy checks, and also includes verified user authorization for the request in the request to the LCS providing entity (e.g., GMLC or a third-party LM server). For example, when the GMLC receives such a request with user authorization indication, the GMLC avoids retrieving the UE privacy profile from the UDM and directly performs the remaining steps of the LCS procedure (e.g., 5GC-MT-LR) based on the indicated user authorization.

[0116] The embodiments disclosed herein can provide various benefits and / or advantages. For example, by avoiding redundant privacy checks, the embodiments can eliminate the processing of UE privacy profiles at different layers and / or network entities required in conventional solutions. Furthermore, the embodiments can improve the efficiency of security processes when using a CAPIF architecture in a network.

[0117] Figure 10 A signaling diagram illustrating an exemplary process for authorizing access to resources based on RNAA tokens according to various embodiments of this disclosure is shown. Specifically, Figure 10 The process in question pertains to UE location resources owned by the UE's user. This process occurs between AF (1030), NEF (1020, as AEF), and GMLC (1010). Although... Figure 10 The operations shown are given numerical labels, but this is done for illustrative purposes and not to require or imply any particular order of operations, unless otherwise explicitly stated.

[0118] In Operation 1, the AF (i.e., as the API caller) sends a request for the user's location to the NEF (i.e., as the AEF). This request includes an access token issued by the CCF, for example, based on... Figure 5 The process is illustrated. In this example, the access token is an RNAA token and implicitly indicates that permission has been granted by the resource owner, for example, according to... Figure 5 The process is illustrated. In operation 2, upon determining that the received access token is an RNAA token, the NEF avoids its routine privacy checks, including obtaining the UE privacy profile from the UDM.

[0119] In Operation 3, the NEF sends a request to the GMLC for the user's location resource. This request includes an indication that the user has been granted permission to access the resource, based on the RNAA token received in Operation 1. In Operation 4, based on the received indication, the GMLC circumvents its routine privacy checks, including obtaining the UE privacy profile from the UDM.

[0120] Notice, Figure 10 The procedure shown can be used in the 5GC-MT-LR and SL-MT-LR procedures briefly described above and detailed in 3GPP TS 23.373 (v18.3.0). Figure 10 The process shown can be combined with operations 2, 5 and 7 to 8 of the 5GC-MT-LR and SL-MT-LR processes.

[0121] Figure 11 A signaling diagram illustrating an exemplary process for authorizing access to resources based on RNAA tokens according to various embodiments of this disclosure is shown. Specifically, Figure 11The process in question targets UE location resources owned by the UE's user. Although Figure 11 The operations shown are given numerical labels, but this is done for illustrative purposes and not to require or imply any particular order of operations, unless otherwise explicitly stated.

[0122] Figure 11 The process shown is Figure 7 An improved version of the SEAL location information subscription request process, as shown and further specified in section 9.3.7 of 3GPP TS 23.434 (v18.6.0). Figure 11 The process shown is performed between the VAL server (1110), the location management server (1120), the location management client (1130), the 3GPP CN (1140, e.g., 5GC), and the third-party location management server (1150).

[0123] In Operation 1, the VAL server (i.e., as the API caller) sends a location information subscription request to the location management server (SEAL LM server, i.e., as the AEF) to subscribe to the location information of one or more VAL users (or VAL UEs). This request includes an access token issued by the CCF, for example, according to... Figure 5 The process is illustrated. In this example, the access token is an RNAA token and implicitly indicates that permission has been granted by the resource owner, for example, according to... Figure 5 The process is shown.

[0124] In Operation 2, upon determining that the received access token is an RNAA token, the location management server avoids checking whether the VAL server is authorized to initiate a location information subscription request for the UE, i.e., whether the VAL server is authorized to know the UE's location information. Instead, the location management server, for example, sends an indication to the location management client that user permission has been obtained based on the received RNAA token. In Operation 3, the location management server may optionally subscribe to the UE's location information from a 3GPP CN (e.g., GMLC) or a third-party location management server, and also provide an indication that user permission has been obtained. Based on this indication, the 3GPP CN (or the third-party location management server) can avoid performing further privacy checks.

[0125] Note that when triggered during offline interaction Figure 11 When the location management (LM) client obtains UE location information from the second LM client, the first LM client indicates that user authorization has been completed in the interaction with the second LM client (e.g., off-network location request).

[0126] You can refer to this. Figures 12 to 13 To further illustrate the above embodiments, Figures 12 to 13Exemplary methods (e.g., procedures) for AEF and NF are described respectively. In other words, the various features of the operations described below correspond to the various embodiments described above. Figures 12 to 13 The exemplary methods shown can be used in conjunction (e.g., in conjunction with each other and / or with other processes described herein) to provide the benefits, advantages, and / or solutions to the problems described herein. Although in 12 to Figure 13 These exemplary methods are illustrated by specific boxes in a particular order, but the operations corresponding to the boxes may be performed in a different order than shown, and may be combined and / or divided into operations with functions different from those shown. Optional boxes and / or operations are indicated by dashed lines.

[0127] Specifically, Figure 12 Exemplary methods (e.g., processes) for an AEF for a communication network are shown according to various exemplary embodiments of this disclosure. Figure 12 The exemplary method shown can be performed by any suitable AEF (e.g., NEF, SEAL location management server, etc.) described herein.

[0128] The exemplary method includes the operation at box 1210, wherein the AEF receives from an API calling entity a request to invoke an API for a resource in a communication network. The resource is owned by a resource owner, and the request includes an access token. The exemplary method also includes the operation at box 1220, wherein the AEF determines whether the access token is a resource owner-aware northbound API access (RNAA) token. When the access token is determined to be an RNAA token, the exemplary method includes the following operations labeled with the corresponding box numbers:

[0129] • (1230) Verify the integrity of the RNAA token, but avoid verifying the resource owner's permission for the API calling entity to access the resource; and

[0130] • When the integrity of the RNAA token is successfully verified, the API for the resource (1250) is invoked according to the request.

[0131] In some embodiments, the access token is determined to be an RNAA token based on the access token including an identifier of the resource owner. In some embodiments, when it is determined that the access token is not an RNAA token, the exemplary method includes the following operations marked with corresponding box numbers:

[0132] • (1240) Verify the resource owner's permission for the API calling entity to access the resource, where the "privacy check" discussed above is an example of such verification; and

[0133] • When the verification of the resource owner's permission for the API calling entity to access the resource is successful (e.g., box 1240), the API for the resource is invoked (1250) according to the request.

[0134] In some embodiments of these embodiments, when verification of permission to access the resource owner fails (e.g., in box 1240), the exemplary method also includes the operation of box 1260, wherein AEF avoids invoking the API for the resource based on the request.

[0135] In some embodiments, the access token includes an identifier of the API calling entity, and verifying the resource owner's permission for the API calling entity to access resource k in box 1240 includes the following operations marked with the corresponding subbox numbers:

[0136] • (1241) Obtain a privacy profile associated with the resource owner from the Unified Data Management (UDM) function of the communication network; and

[0137] • (1242) Determine whether the API calling entity is authorized to access the resource based on the privacy profile and the identifier of the API calling entity.

[0138] In some embodiments, the resource is the location of a user equipment (UE), and the resource owner is a user of the UE. In some embodiments, AEF is a Network Open Function (NEF) of a communication network. In other embodiments, AEF is a Service Enabled Architecture Layer (SEAL) location management server.

[0139] In some embodiments, the API is associated with a network function (NF) of a communication network, and the invocation of the API for that resource in block 1250 includes the operation in subblock 1251, wherein the AEF sends a request for the resource to the NF. The request includes an indication that permission has been obtained from the resource owner for the API-calling entity to access the resource. In some embodiments of these embodiments, the NF is a Gateway Mobility Center (GMLC). In some embodiments of these embodiments, the NF is an Access and Mobility Management Function (AMF).

[0140] In some embodiments, the API calling entity is one of the following: an application hosted by a user equipment (UE); an application function (AF) associated with a communication network; or a vertical application layer (VAL) server.

[0141] in addition, Figure 13 Exemplary methods (e.g., processes) for an NF for a communication network are shown according to various exemplary embodiments of the present disclosure. Figure 13 The exemplary method shown can be performed by any suitable NF, such as those described herein.

[0142] The exemplary method includes the operation at box 1310, wherein the NF receives an API call for a resource in the communication network from the AEF of the communication network. The resource is owned by a resource owner, and the call represents an API calling entity. The exemplary method includes the operation at box 1320, wherein the NF determines whether the call includes an indication that permission has been obtained from the resource owner to access the resource. When it is determined that the request includes this indication, the exemplary method includes the following operations labeled with the corresponding box numbers:

[0143] • (1330) Avoid verifying the resource owner's permission for the API calling entity to access the resource;

[0144] • (1350) Obtain the resource from the communication network, and

[0145] • (1360) Send the acquired resources to AEF.

[0146] In some embodiments, when it is determined that the request does not include the instruction, the exemplary method further includes the following operations marked with corresponding box numbers:

[0147] • (1340) Verify the resource owner's permission for the API calling entity to access the resource; and

[0148] • When the verification of the resource owner's permission for the API calling entity to access the resource is successful (e.g., in box 1340):

[0149] o(1350) obtains the resource from the communication network, and

[0150] o(1360) sends the acquired resources to AEF.

[0151] In some of these embodiments, the exemplary method also includes the operation of box 1370, wherein the NF avoids obtaining the resource from the communication network when verification of the resource owner's permission for the API calling entity to access the resource fails (e.g., in box 1340).

[0152] In some of these embodiments, the API call includes an identifier of the API calling entity, and verifying the resource owner's permission for the API calling entity to access the resource in 1340 includes the following operations marked with corresponding subframe numbers:

[0153] • (1341) Obtain a privacy profile associated with the resource owner from the Unified Data Management (UDM) function of the communication network; and

[0154] • (1342) Determine whether the API calling entity is authorized to access the resource based on the privacy profile and the identifier of the API calling entity.

[0155] In some of these embodiments, the API calling entity is one of the following: an application hosted by the UE, an AF associated with the communication network, or a VAL server.

[0156] In some embodiments, the resource is the location of the UE, and the resource owner is the user of the UE. In some embodiments, the AEF is the NEF of the communication network. In other embodiments, the AEF is the SEAL location management server.

[0157] In some embodiments, the API is associated with an NF, and a call to the API includes a request for a resource. In some embodiments, the NF is a GMLC. In other embodiments, the NF is an AMF.

[0158] Although various embodiments have been described above in relation to methods, apparatus, devices, computer-readable media, and receivers, those skilled in the art will readily understand that such methods can be implemented by various combinations of hardware and software, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, etc., in various systems.

[0159] Figure 14 An example of a communication system 1400 according to some embodiments is shown. In this example, the communication system 1400 includes a telecommunications network 1402, which includes an access network 1404 (e.g., a RAN) and a core network 1406, which includes one or more core network nodes 1408. The access network 1404 includes one or more access network nodes, such as network nodes 1410a to 1410b (one or more of which may generally be referred to as network node 1410), or any other similar 3GPP access node or non-3GPP access point. Furthermore, those skilled in the art will understand that network nodes are not necessarily limited to an implementation that is provided by a single vendor and integrates the radio and baseband portions. Therefore, it should be understood that network nodes include decomposed implementations or portions thereof. For example, in some embodiments, the telecommunications network 1402 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 1402 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or together with other nodes to perform one or more functions of any node in the telecommunications network 1402 (including one or more network nodes 1410 and / or core network nodes 1408).

[0160] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs), including O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs), managed software or software plug-ins (e.g., near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps)), RAN intelligent controllers (near real-time or non-real-time), or any combination thereof (the adjective "open" indicates support for the ORAN specification). Network nodes can support the specification by, for example, supporting interfaces defined by the ORAN specification (e.g., A1, F1, W1, E1, E2, X2, Xn interfaces, Open Fronthaul User Plane Interfaces, or Open Fronthaul Management Plane Interfaces). Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (described further below) where one or more network functions are virtualized. For example, a virtualization environment may include an open cloud (O-Cloud) computing platform orchestrated by a service management and orchestration framework via an O-2 interface or equivalent technology defined by the O-RAN Alliance. Network node 1410 facilitates direct or indirect connections for UEs, such as connecting UEs 1412a to 1412d (one or more of which may generally be referred to as UE 1412) to core network 1406 via one or more wireless connections.

[0161] Examples of wireless communication via wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wiring, cables, or other conductors. Furthermore, in various embodiments, communication system 1400 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals (whether via wired or wireless connections). Communication system 1400 may include any type of communication, telecommunications, data, cellular, radio network, and / or other similar system, and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar system.

[0162] UE 1412 can be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with network node 1410 and other communication devices. Similarly, network node 1410 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE 1412 and / or with other network nodes or devices in telecommunication network 1402 to implement and / or provide network access (such as wireless network access) and / or to perform other functions (such as management) in telecommunication network 1402.

[0163] In the depicted example, core network 1406 connects network node 1410 to one or more hosts (such as host 1416). These connections can be direct connections or indirect connections via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1406 includes one or more core network nodes (e.g., 1408) composed of hardware and software components. The characteristics of these components can be substantially similar to those described with respect to UEs, network nodes, and / or hosts, such that the description is generally applicable to the corresponding components of core network node 1408. Example core network nodes include 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 Unhiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0164] Host 1416 may be owned or under the control of a service provider other than the operator or provider of access network 1404 and / or telecommunications network 1402, and may be operated by or on behalf of that service provider. Host 1416 may host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data about various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

[0165] As a whole, Figure 14The communication system 1400 enables connectivity between the UE, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but 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 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (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.

[0166] In some examples, telecommunications network 1402 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 1402 can support network slicing to provide different logical networks to different devices connected to it. For example, telecommunications network 1402 can 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 IoT services to yet another UE.

[0167] In some examples, UE 1412 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to access network 1404 according to a predetermined schedule when triggered by an internal or external event or in response to a request from access network 1404. Additionally, the UE may be configured to operate in single-RAT mode, multi-RAT mode, or multi-standard mode. For example, the UE may operate using any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio Dual Connectivity (EN-DC).

[0168] In this example, hub 1414 communicates with access network 1404 to facilitate indirect communication between one or more UEs (e.g., 1412c and / or 1412d) and network nodes (e.g., 1410b). In some examples, hub 1414 may be a controller, router, content source and analyzer, or any other communication device described herein relating to the UE. For example, hub 1414 may be a broadband router that enables the UE to access core network 1406. As another example, hub 1414 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node 1410, or via executable code, scripts, procedures, or other instructions in hub 1414. As another example, hub 1414 may be a data collector that acts as a temporary storage device for UE data, and in some embodiments, may perform data analysis or other processing. As another example, hub 1414 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, hub 1414 can retrieve VR assets, video, audio, or other media or data related to perceived information via network nodes, and then provide them to the UE directly, after performing local processing, and / or after adding additional local content. In yet another example, hub 1414 acts as a proxy server or coordinator for the UE, particularly if one or more of the UEs are low-power IoT devices.

[0169] Hub 1414 may have a persistent / persistent or intermittent connection to network node 1410b. Hub 1414 may also allow different communication schemes and / or scheduling between hub 1414 and UEs (e.g., 1412c and / or 1412d) and between hub 1414 and core network 1406. In other examples, hub 1414 is connected to core network 1406 and / or one or more UEs via a wired connection. Furthermore, hub 1414 may be configured to connect to an M2M service provider via access network 1404 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 1410 while still being connected via hub 1414 through a wired or wireless connection. In some embodiments, hub 1414 may be a dedicated hub—that is, a hub whose primary function is to route communication from network node 1410b to UE / to network node 1410b. In other embodiments, the hub 1414 may be a non-dedicated hub, i.e., a device capable of operating to route communication between the UE and network node 1410b, but additionally capable of operating as a communication start point and / or endpoint for certain data channels.

[0170] In some embodiments, one or more core network nodes 1408 may be configured to perform the above descriptions of various embodiments (including...). Figures 12 to 13 Various operations belonging to AEF and NF in the exemplary method shown.

[0171] Figure 15 A network node 1500 according to some embodiments is shown. 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, NodeBs, eNBs, and gNBs), and O-RAN nodes or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0172] Base stations can be classified based on the coverage they provide (or, in other words, their transmission power levels); therefore, depending on the coverage provided, a base station can be called a femtobase, picobase, microbase, or macrobase. A base station can be a relay node or a relay donor for control relays. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). These remote radio units can be integrated with antennas to form an antenna-integrated radio, or they can be independent of antenna integration. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS).

[0173] Other examples of network nodes include multi-transmitter point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices (e.g., MSR BS), network controllers (e.g., radio network controllers (RNC) or base station controllers (BSC)), base transceiver stations (BTS), transmitter points, transmitter nodes, multi-cell / multicast coordination entities (MCE), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved serving mobility location centers (E-SMLC)) and / or minimized drive tests (MDT).

[0174] Network node 1500 includes processing circuitry 1502, memory 1504, communication interface 1506, and power supply 1508. Network node 1500 may consist of multiple physically separate components (e.g., NodeB and RNC components, or BTS and BSC components, etc.), each with its own corresponding components. In some scenarios where network node 1500 includes multiple separate components (e.g., BTS and BSC components), one or more of these separate components may be shared among multiple network nodes. For example, a single RNC may control multiple NodeBs. In such scenarios, each unique “NodeB and RNC pair” may, in some cases, be considered a single, separate network node. In some embodiments, network node 1500 may be configured to support multiple Radio Access Technologies (RATs). In such embodiments, some components may be replicated (e.g., separate memory 1504 exists for different RATs) and some components may be reused (e.g., the same antenna 1510 may be shared by different RATs). Network node 1500 may also include multiple sets of various components shown for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID, or Bluetooth wireless technologies). These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 1500.

[0175] Processing circuitry 1502 may include a combination of one or more of the following: a microprocessor, a controller, a central processing unit, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or any other suitable computing device, resource, or a combination of hardware, software, and / or coding logic operable to provide the functionality of network node 1500, either alone or in combination with other components of network node 1500 (e.g., memory 1504).

[0176] In some embodiments, the processing circuitry 1502 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 1502 includes one or more of a radio frequency (RF) transceiver circuitry 1512 and a baseband processing circuitry 1514. In some embodiments, the RF transceiver circuitry 1512 and the baseband processing circuitry 1514 may be on separate chips (or chipsets), boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuitry 1512 and the baseband processing circuitry 1514 may be on the same chip or chipset, board, or group of units.

[0177] Memory 1504 may include any form of volatile or non-volatile computer-readable memory, including but not limited to permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, optical discs (CDs), or digital video discs (DVDs)) and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuitry 1502. Memory 1504 may store any suitable instructions, data, or information, including computer programs, software, applications including logic, rules, codes, tables, and / or other instructions that can be executed by processing circuitry 1502 and used by network node 1500 (collectively referred to as computer program 1504a, which may be in the form of a computer program product). Storage device 1504 may be used to store any calculations performed by processing circuitry 1502 and / or any data received via communication interface 1506. In some embodiments, the processing circuitry 1502 and the memory 1504 are integrated together.

[0178] Communication interface 1506 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 1506 includes a port / terminal 1516 for transmitting and receiving data to and from the network, for example, via a wired connection. Communication interface 1506 also includes radio front-end circuitry 1518, which may be coupled to antenna 1510, or in some embodiments, is part of antenna 1110. Radio front-end circuitry 1518 includes a filter 1520 and an amplifier 1522. Radio front-end circuitry 1518 may be connected to antenna 1510 and processing circuitry 1502. Radio front-end circuitry 1518 may be configured to modulate the signal transmitted between antenna 1510 and processing circuitry 1502. Radio front-end circuitry 1518 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1518 may use a combination of filter 1520 and / or amplifier 1522 to convert the digital data into a radio signal with suitable channel and bandwidth parameters. The radio signal may then be transmitted via antenna 1510. Similarly, when receiving data, antenna 1510 can collect radio signals, which are then converted into digital data by radio front-end circuitry 1518. The digital data can then be passed to processing circuitry 1502. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0179] In some alternative embodiments, network node 1500 does not include a separate radio front-end circuitry 1518; instead, processing circuitry 1502 includes radio front-end circuitry and is connected to antenna 1510. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1512 is part of communication interface 1506. In still other embodiments, communication interface 1506 includes one or more ports or terminals 1516, radio front-end circuitry 1518, and RF transceiver circuitry 1512 as part of a radio unit (not shown), and communication interface 1506 communicates with baseband processing circuitry 1514, which is part of a digital unit (not shown).

[0180] Antenna 1510 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1510 may be coupled to radio front-end circuitry 1518 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1510 is decoupled from network node 1500 and may be connected to network node 1500 via an interface or port.

[0181] Antenna 1510, communication interface 1506, and / or processing circuitry 1502 can be configured to perform any receive operation and / or certain acquire operation described herein by a network node. Any information, data, and / or signals can be received from the UE, another network node, and / or any other network device. Similarly, antenna 1510, communication interface 1506, and / or processing circuitry 1502 can be configured to perform any transmit operation described herein by a network node. Any information, data, and / or signals can be transmitted to the UE, another network node, and / or any other network device.

[0182] Power supply 1508 provides power to the various components of network node 1500 in a form suitable for the various components (e.g., at the voltage and current levels required by each respective component). Power supply 1508 may also include or be coupled to power management circuitry to supply power to the components of network node 1500 for performing the functions described herein. For example, network node 1500 may be connected to an external power source (e.g., mains, power outlet) via input circuitry or an interface (e.g., cable), whereby the external power source supplies power to the power circuitry of power supply 1508. As another example, power supply 1508 may include a power source in the form of a battery or battery pack, which is connected to or integrated into the power circuitry. The battery can provide backup power if the external power source fails.

[0183] Implementations of network node 1500 may include more than Figure 15Additional components shown are provided to offer certain aspects of the functionality of the network node, including any of the functions described herein and / or any functionality required to support the topics described herein. For example, network node 1500 may include a user interface device to allow information to be input into and output from network node 1500. This allows users to perform diagnostic, maintenance, repair, and other management functions on network node 1500.

[0184] In some embodiments, one or more nodes 1500 may be configured to perform the above descriptions of various embodiments (including...). Figures 12 to 13 Various operations belonging to AEF and NF in the exemplary method shown.

[0185] Figure 16 This is a block diagram of a virtualization environment 1600 capable of virtualizing some embodiments. In this context, virtualization means creating a virtual version of an apparatus or device that may include a virtualized hardware platform, storage devices, and network resources. As used herein, virtualization can be applied to any device or component thereof described herein, and involves at least a portion of its functionality being implemented as an implementation of one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) in one or more virtual environments 1600 hosted by one or more hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Furthermore, in embodiments where virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes can be fully virtualized. In some embodiments, the virtualization environment 1600 includes components defined by the O-RAN Alliance, such as an open cloud environment orchestrated via an O-2 interface by a service management and orchestration framework.

[0186] Application 1602 (which may alternatively be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in virtualization environment 1600 to implement some features, functions, and / or benefits of some embodiments disclosed herein. In some embodiments, one or more virtual network functions 1602 may be configured to perform the above descriptions of various embodiments (including...) Figures 12 to 13 Various operations belonging to AEF and NF in the exemplary method shown.

[0187] Hardware 1604 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry (collectively referred to as computer program 1604a, which may be in the form of a computer program product), and / or other hardware devices described herein (e.g., network interface, input / output interface, etc.). The software may be executed by the processing circuitry to instantiate one or more virtualization layers 1606 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMs 1608a and 1608b (one or more of which may generally be referred to as VM 1608), and / or perform any functions, features, and / or benefits described in connection with some embodiments described herein. Virtualization layer 1606 may present a virtual operating platform to VM 1608, which appears as networked hardware.

[0188] VM 1608 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and can be run by a corresponding virtualization layer 1606. Different embodiments of instances of virtual device 1602 can be implemented on one or more VMs 1608, and these implementations can be carried out in different ways. In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV can be used to unify many types of network devices into industry-standard high-capacity server hardware, physical switches, and physical storage, which can reside in data centers and customer residential equipment.

[0189] In the context of NFV, VM 1608 can be a software implementation of a physical machine, whose running program behaves as if it were running on a physical, non-virtualized machine. Each VM 1608, along with the portion of hardware 1604 that executes that VM (whether it is dedicated hardware for that VM and / or hardware shared by that VM with other VMs), forms a separate virtual network element. Still within the context of NFV, the virtual network function is responsible for handling specific network functions operating within one or more VMs 1608 on top of hardware 1604 and corresponds to application 1602.

[0190] Hardware 1604 can be implemented in a standalone network node with general or specific components. Hardware 1604 can implement some functions via virtualization. Alternatively, hardware 1604 can be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed by management and orchestration function 1610, which in particular oversees the lifecycle management of application 1602. In some embodiments, hardware 1604 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that can be coupled to one or more antennas. The radio units can communicate directly with other hardware nodes via one or more suitable network interfaces and can be used in conjunction with virtual components to provide radio capabilities to virtual nodes (e.g., radio access nodes or base stations). In some embodiments, some signaling can be provided using a control system 1612, which can alternatively be used for communication between hardware nodes and radio units.

[0191] The foregoing merely illustrates the principles of this disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in light of the teachings herein. Therefore, it should be understood that those skilled in the art will be able to design numerous systems, arrangements, and processes that, while not expressly shown or described herein, embody the principles of this disclosure and are thus within its spirit and scope. As will be understood by those skilled in the art, various embodiments can be used together and interchangeably.

[0192] As used herein, the terminology may have its conventional meaning in the field of electronic, electrical and / or electronic equipment, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logic solid-state and / or discrete devices, computer programs or instructions for performing various tasks, processes, calculations, outputs and / or display functions, such as those described herein.

[0193] Any suitable steps, methods, features, functions, or benefits disclosed herein can be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include multiple such functional units. These functional units may be implemented by processing circuitry, which may include one or more microprocessors or microcontrollers and other digital hardware (which may include digital signal processors (DSPs), application-specific digital logic, etc.). The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in memory includes program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more techniques described herein. In some implementations, the processing circuitry may be used to cause the various functional units to perform corresponding functions according to one or more embodiments of this disclosure.

[0194] As described herein, devices and / or apparatuses may be represented by semiconductor chips, chipsets, or (hardware) modules including such chips or chipsets; however, this does not preclude the possibility that the functionality of a device or apparatus may be implemented as a software module (e.g., including a computer program or computer program product comprising executable software code portions for execution or running on a processor). Furthermore, the functionality of a device or apparatus may be implemented by any combination of hardware and software. A device or apparatus may also be considered as a combination of multiple devices and / or apparatuses, whether they functionally cooperate with each other or are independent of each other. Moreover, devices and apparatuses may be implemented in a distributed manner throughout a system, provided that the functionality of the device or apparatus is preserved. This principle and similar principles are considered to be known to those skilled in the art.

[0195] Unless otherwise defined, all terms used herein, including technical and scientific terms, shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will also be understood that the terms used herein should be interpreted as having the meaning consistent with their meaning in the context of this specification and related art, and not as in an ideal or overly formal form, unless so explicitly defined herein.

[0196] Additionally, certain terms used in this disclosure (including the specification and drawings) may be used synonymously in certain instances (e.g., "data" and "information"). It should be understood that while these terms (and / or other terms that may be synonymous with each other) may be used synonymously herein, there may be instances where such words are intended not to be used synonymously.

[0197] Embodiments of the technologies and apparatus described herein also include, but are not limited to, the following examples:

[0198] A1. A method for Application Programming Interface (API) Open Function (AEF) for a communication network, the method comprising:

[0199] Receive API calls for resources in the communication network from the API calling entity, where:

[0200] The resource is owned by the resource owner, and

[0201] API calls include access tokens;

[0202] Determine whether the access token is a resource owner-aware northbound API access (RNAA) token;

[0203] When it is determined that the access token is an RNAA token:

[0204] Avoid performing privacy checks on user permissions to access this resource; and

[0205] Send a request for the resource to the network function (NF) of the communication network, wherein the request includes an indication that the user has been granted permission to access the resource.

[0206] A2. The method according to embodiment A1, wherein when it is determined that the access token is not an RNAA token:

[0207] Perform privacy checks on the permission granted by the resource owner to access the resource; and

[0208] When a privacy check instructs permission to access the resource owner, a request for the resource is sent to the NF, wherein the request includes an instruction that the user has already been granted permission to access the resource.

[0209] A3. The method according to embodiment A2 further includes: avoiding requesting the resource from the NF when a privacy check indicates that no permission has been granted to the resource owner to access the resource.

[0210] A4. The method according to any one of embodiments A1 to A3, wherein performing the privacy check includes:

[0211] Obtain a privacy profile associated with the resource owner from the Unified Data Management (UDM) function of the communication network; and

[0212] Based on the privacy profile, determine whether the API calling entity is authorized to access the resource.

[0213] A5. The method according to any one of embodiments A1 to A4, wherein the resource is the location of a user equipment (UE) and the resource owner is a user of the UE.

[0214] A6. The method according to any one of embodiments A1 to A5, wherein AEF is one of the following:

[0215] Network Open Function (NEF) of communication networks, or

[0216] Service Enablement Architecture Layer (SEAL) Location Management Server.

[0217] A7. The method according to any one of embodiments A1 to A6, wherein NF is one of the following:

[0218] Gateway Mobility Location Center (GMLC) or Access and Mobility Management Function (AMF).

[0219] A8. The method according to any one of embodiments A1 to A7, wherein the API calling entity is one of the following: an application hosted by a user equipment (UE); an application function (AF) associated with a communication network; or a vertical application layer (VAL) server.

[0220] B1. A method for a network function (NF) in a communication network, the method comprising:

[0221] Receive requests for resources in the communication network from the Application Programming Interface (API) Open Function (AEF) of the communication network, where the resources are owned by the resource owner;

[0222] Determine whether the request includes instructions that permission has been obtained from the resource owner to access the resource;

[0223] When it is determined that the request includes the instruction:

[0224] Avoid performing privacy checks on user permissions to access this resource; and

[0225] Obtain the resource from the communication network; and

[0226] Send the acquired resources to AEF.

[0227] B2. The method according to embodiment B1, wherein when it is determined that the request does not include the instruction:

[0228] Perform privacy checks on the permission granted by the resource owner to access the resource; and

[0229] When a privacy check instructs permission to be granted to the resource owner to access the resource:

[0230] Obtain the resource from the communication network, and

[0231] Send the acquired resources to AEF.

[0232] B3. The method according to embodiment B2 further includes: avoiding requests to obtain the resource from the communication network when a privacy check indicates that no permission has been granted to the resource owner to access the resource.

[0233] B4. The method according to any one of embodiments B1 to B3, wherein performing the privacy check includes:

[0234] Obtain a privacy profile associated with the resource owner from the Unified Data Management (UDM) function of the communication network; and

[0235] Based on the privacy profile, determine whether one or more of the following items are authorized to access the resource: AEF, and the API call entity that AEF makes on its behalf to request the resource.

[0236] B5. The method according to embodiment B4, wherein the API calling entity is one of the following: an application hosted by a user equipment (UE); an application function (AF) associated with a communication network; or a vertical application layer (VAL) server.

[0237] B6. The method according to any one of embodiments B1 to B5, wherein the resource is the location of a user equipment (UE) and the resource owner is a user of the UE.

[0238] B7. The method according to any one of embodiments B1 to B6, wherein AEF is one of the following:

[0239] Network Open Function (NEF) of communication networks, or

[0240] Service Enablement Architecture Layer (SEAL) Location Management Server.

[0241] B8. The method according to any one of embodiments B1 to B7, wherein NF is one of the following:

[0242] Gateway Mobility Location Center (GMLC) or Access and Mobility Management Function (AMF).

[0243] C1. A network device configured to implement Application Programming Interface (API) Open Function (AEF) of a communication network, the network device comprising:

[0244] The communication interface circuit is configured to communicate with the application programming interface (API) calling entity of the communication network and the network function (NF) of the communication network; and

[0245] The processing circuit is operatively coupled to the communication interface circuit, wherein the processing circuit and the communication interface circuit are configured to perform operations corresponding to the method described according to any one of embodiments A1 to A8.

[0246] C2. A network device configured to implement an Application Programming Interface (API) Open Function (AEF) for a communication network, the network device further configured to perform operations corresponding to the method described according to any one of embodiments A1 to A8.

[0247] C3. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of a network device configured to implement an Application Programming Interface (API) Open Function (AEF) of a communication network, configure the network device to perform an operation corresponding to the method described according to any one of embodiments A1 to A8.

[0248] C4. A computer program product including computer-executable instructions that, when executed by processing circuitry of a network device configured to implement an Application Programming Interface (API) Open Function (AEF) of a communication network, configure the network device to perform an operation corresponding to the method described in any one of embodiments A1 to A8.

[0249] D1. A network device configured to implement network functions (NF) of a communication network, the network device comprising:

[0250] A communication interface circuit is configured to communicate with the network functions (NF) of a communication network, the NF including an Application Programming Interface (API) Open Function (AEF); and

[0251] The processing circuit is operatively coupled to the communication interface circuit, wherein the processing circuit and the communication interface circuit are configured to perform operations corresponding to the method described according to any one of embodiments B1 to B8.

[0252] D2. A network device configured to implement network functions (NF) of a communication network, the network device further configured to perform operations corresponding to the method described according to any one of embodiments B1 to B8.

[0253] D3. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of a network device configured to implement network functions (NF) of a communication network, configure the network device to perform operations corresponding to the method described according to any one of embodiments B1 to B8.

[0254] D4. A computer program product including computer-executable instructions that, when executed by processing circuitry of a network device configured to implement network functions (NF) of a communication network, configure the network device to perform an operation corresponding to the method described according to any one of embodiments B1 to B8.

Claims

1. A method for Application Programming Interface (API) Open Functionality (AEF) for communication networks, the method comprising: Receive (1210) a request from the API calling entity to invoke an API for a resource in the communication network, wherein the resource is owned by a resource owner and the request includes an access token; Determine whether the access token (1220) is a resource owner-aware northbound API access RNAA token; When it is determined that the access token is an RNAA token: Verify the integrity of the RNAA token (1240), but avoid verifying the resource owner's permission for the API calling entity to access the resource; and When the integrity of the RNAA token is successfully verified, the API for the resource is invoked (1250) according to the request.

2. The method according to claim 1, wherein, Based on the fact that the access token includes the identifier of the resource owner, the access token is determined to be an RNAA token.

3. The method according to any one of claims 1 to 2, wherein, When it is determined that the access token is not an RNAA token: Verify (1240) the resource owner's permission for the API calling entity to access the resource; as well as When the verification of the resource owner's permission for the API calling entity to access the resource is successful, the API for the resource is invoked (1250) according to the request.

4. The method according to claim 3, further comprising: When verification of permission to access the resource owner fails, avoid (1260) calling the API for the resource based on the request.

5. The method according to any one of claims 3 to 4, wherein, The access token includes an identifier of the API calling entity, and verifying (1240) the resource owner's permission for the API calling entity to access the resource includes: Obtain (1241) a privacy profile associated with the resource owner from the Unified Data Management (UDM) function of the communication network; and Based on the privacy profile and the identifier of the API call entity, determine (1242) whether the API call entity is authorized to access the resource.

6. The method according to any one of claims 1 to 5, wherein, The resource is the location of the user equipment (UE), and the resource owner is the user of the UE.

7. The method according to any one of claims 1 to 6, wherein, The AEF is one of the following: Network Open Function (NEF), or SEAL location management server, a service-enabled architecture layer.

8. The method according to any one of claims 1 to 7, wherein, The API is associated with a network function NF of the communication network, and calling (1250) the API for the resource includes sending (1251) a request for the resource to the NF, wherein the request includes an indication that permission has been obtained from the resource owner for the API calling entity to access the resource.

9. The method according to claim 8, wherein, The NF is one of the following: Gateway Mobility Center (GMLC); or Access and Mobility Management Function (AMF).

10. The method according to any one of claims 1 to 9, wherein, The API calling entity is one of the following: an application hosted by a user equipment (UE); an application function (AF) associated with the communication network; or a vertical application layer (VAL) server.

11. A method for a network function (NF) in a communication network, the method comprising: The application programming interface (API) open function (AEF) of the communication network receives (1310) an API call for a resource in the communication network, wherein the resource is owned by a resource owner and the call represents an API calling entity; Determine whether the call (1320) includes an indication that the resource owner has already granted permission for the API calling entity to access the resource; When it is determined that the call includes the instruction: Avoid (1330) verifying the resource owner's permission for the API calling entity to access the resource; Obtain the resources (1350) from the communication network; and Send the acquired resources (1360) to the AEF.

12. The method according to claim 11, wherein, When it is determined that the call does not include the instruction: Verify (1340) the resource owner's permission for the API calling entity to access the resource; as well as When the verification of the resource owner's permission for the API caller to access the resource is successful: Obtain the resources (1350) from the communication network, and Send the acquired resources (1360) to the AEF.

13. The method of claim 12, further comprising: When verification of the resource owner's permission for the API calling entity to access the resource fails, avoid (1370) obtaining the resource from the communication network.

14. The method according to any one of claims 12 to 13, wherein, The call to the API includes the identifier of the API calling entity, and verifying (1340) the resource owner's permission for the API calling entity to access the resource includes: Obtain (1341) a privacy profile associated with the resource owner from the Unified Data Management (UDM) function of the communication network; and Based on the privacy profile and the identifier of the API call entity, determine (1342) whether the API call entity is authorized to access the resource.

15. The method according to any one of claims 11 to 14, wherein, The API calling entity is one of the following: an application hosted by a user equipment (UE); an application function (AF) associated with the communication network; or a vertical application layer (VAL) server.

16. The method according to any one of claims 11 to 15, wherein, The resource is the location of the user equipment (UE), and the resource owner is the user of the UE.

17. The method according to any one of claims 11 to 16, wherein, The AEF is one of the following: The Network Open Function (NEF) of the communication network, or SEAL location management server, a service-enabled architecture layer.

18. The method according to any one of claims 11 to 17, wherein, The API is associated with the NF, and calls to the API include requests for the resource.

19. The method according to any one of claims 11 to 18, wherein, The NF is one of the following: Gateway Mobile Location Center (GMLC); or Access and Mobility Management Function (AMF).

20. A network device (1408, 1500, 1602) configured to implement the Application Programming Interface (API) Open Functions (AEF) (430, 530, 1020, 1120) of a communication network (300, 1140, 1406), said network device comprising: The communication interface circuits (1506, 1604) are configured to communicate with API calling entities (410, 510, 1030, 1110); as well as The processing circuitry (1502, 1604) is operatively coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured as follows: The API calling entity receives a request to invoke an API for a resource in the communication network, wherein the resource is owned by a resource owner, and the request includes an access token. Determine whether the access token is a resource owner-aware northbound API access RNAA token; When it is determined that the access token is an RNAA token: Verify the integrity of the RNAA token, but avoid verifying the resource owner's permission for the API calling entity to access the resource; and When the integrity of the RNAA token is successfully verified, the API for the resource is invoked according to the request.

21. The network device according to claim 20, wherein, The processing circuit and the communication interface circuit are further configured to perform operations corresponding to the method according to any one of claims 2 to 10.

22. A network device (1408, 1500, 1602) configured to implement the Application Programming Interface (API) Open Functions (AEF) (430, 530, 1020, 1120) of a communication network (300, 1140, 1406), said network device further configured to: Requests to invoke APIs for resources in the communication network are received from API calling entities (410, 510, 1030, 1110), wherein... The resource is owned by the resource owner, and the request includes an access token; Determine whether the access token is a resource owner-aware northbound API access RNAA token; When it is determined that the access token is an RNAA token: Verify the integrity of the RNAA token, but avoid verifying the resource owner's permission for the API calling entity to access the resource; as well as When the integrity of the RNAA token is successfully verified, the API for the resource is invoked according to the request.

23. The network device of claim 22 is further configured to perform an operation corresponding to the method of any one of claims 2 to 10.

24. A non-transitory computer-readable medium (1504, 1604) storing computer-executable instructions, which, when executed by processing circuitry (1502, 1604) of a network device (1408, 1500, 1602) configured to implement the Application Programming Interface Open Functions (AEF) (430, 530, 1020, 1120) of a communication network (300, 1140, 1406), configure the network device to perform an operation corresponding to the method according to any one of claims 1 to 10.

25. A computer program product (1504a, 1604a) comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processing circuit (1502, 1604) of a network device (1408, 1500, 1602) configured to implement the Application Programming Interface (API) Open Functions (AEF) (430, 530, 1020, 1120) of a communication network (300, 1140, 1406), configure the network device to perform an operation corresponding to the method according to any one of claims 1 to 10.

26. A network device (1408, 1500, 1602) configured to implement network function NF (1010, 1140) of a communication network (300, 1140, 1406), said network device comprising: The communication interface circuits (1506, 1604) are configured to communicate with the Application Programming Interface (API) Open Functions (AEF) (430, 530, 1020, 1120) of the communication network; and The processing circuitry (1502, 1604) is operatively coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured as follows: Receive API calls for resources in the communication network from the AEF, wherein the resources are owned by a resource owner and the calls represent API calling entities (410, 510, 1030, 1110). Determine whether the call includes an indication that the resource owner has already granted permission for the API calling entity to access the resource; When it is determined that the call includes the instruction: Avoid verifying the resource owner's permission for the entity making the API call to access the resource; Obtain the resources from the communication network; and Send the acquired resources to the AEF.

27. The network device according to claim 26, wherein, The processing circuit and the communication interface circuit are further configured to perform operations corresponding to the method according to any one of claims 12 to 19.

28. A network device (1408, 1500, 1602) configured to implement network function NF (1010, 1140) of a communication network (300, 1140, 1406), said network device further configured to: The application programming interface (API) open function (AEF) (430, 530, 1020, 1120) of the communication network receives API calls for resources in the communication network, wherein... The resource is owned by the resource owner, and the call represents the API call entity (410, 510, 1030, 1110). Determine whether the call includes an indication that the resource owner has already granted permission for the API calling entity to access the resource; When it is determined that the call includes the instruction: Avoid verifying the resource owner's permission for the entity making the API call to access the resource; Obtain the resources from the communication network; as well as Send the acquired resources to the AEF.

29. The network device of claim 28 is further configured to perform operations corresponding to the method of any one of claims 12 to 19.

30. A non-transitory computer-readable medium (1504, 1604) storing computer-executable instructions, which, when executed by processing circuitry (1502, 1604) of a network device (1408, 1500, 1602) configured to implement network functions NF (1010, 1140) of a communication network (300, 1140, 1406), configure the network device to perform an operation corresponding to the method according to any one of claims 11 to 19.

31. A computer program product (1504a, 1604a) comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processing circuit (1502, 1604) of a network device (1408, 1500, 1602) configured to perform an operation corresponding to the method according to any one of claims 11 to 19, shall be configured by the network device to perform an operation when executed by a processing circuit (1502, 1604) of a network device (1408, 1500, 1602) configured to implement a network function NF (1010, 1140) of a communication network (300, 1140, 1406).

Images