Network node and method therein for network function interconnection

Abstract

The present disclosure provides a method (300) in a first network function (NF). The method (300) comprises sending (310) authorization delegation information to a second NF, the authorization delegation information enabling the second NF to authorize a service application programming interface (API) access to an API invoker.

Description

Technical Field

[0001] This disclosure relates to communication technologies, and more specifically, to network nodes for interconnecting network functions and methods therein. Background Technology

[0002] The 3GPP Technical Specification (TS) 23.222, V19.0.0 introduced the Common Application Programming Interface (API) Framework (CAPIF) for 3GPP Northbound APIs, which is incorporated herein by reference in its entirety. Within the scope of CAPIF standardization, 3GPP addresses various processes, including application function onboarding / offboarding, service discovery and management, event subscription and notification, security, and accounting. TS 33.122, V18.2.0 specifies CAPIF security mechanisms, such as authentication, authorization, and interface security, which is also incorporated herein by reference in its entirety. Clause 6.5.2 of TS 33.122 specifies three authentication and authorization mechanisms. API callers learn the mechanisms supported by API Open Functions (AEF) from the CAPIF Core Functions (CCF), as specified in Clause 6.3.1.2 of TS 33.122.

[0003] Service federation between different service providers is crucial for application enablers to support service sharing. Two organizations with business relationships and each having deployed CAPIF may require interoperability to allow API callers in each trust domain to utilize service APIs from those two CAPIF providers, such as... Figure 1 As shown. In Figure 1 In this context, the interconnection between CAPIF provider A and CAPIF provider B allows API callers in the trust domain of CAPIF provider A to utilize service APIs from CAPIF provider B, and vice versa.

[0004] Figure 2A A more detailed architectural model for CAPIF interconnection is shown, which allows API callers of CAPIF providers to utilize service APIs from third-party CAPIF providers. Figure 2A In the architecture shown, API provider domain functions register with CCFs within the same trusted domain. CCFs connect via CAPIF-6e to share service APIs. API provider domain functions in one domain cannot see interconnected CCFs in another domain. API callers residing (registering) with one CAPIF provider can use service APIs provided in another domain via CAPIF-2e.

[0005] Figure 2BAn architectural model for CAPIF interconnection within the same CAPIF provider domain is shown, which allows API callers of CCF1 to utilize service APIs from CCF2. Both CCF1 and CCF2 are hosted within the trust domain of CAPIF provider A. Summary of the Invention

[0006] Clause 8.25 of TS 23.222 describes existing processes supporting CAPIF interconnection, including service API publishing / retrieval / updating / cancellation and discovery via the CAPIF-6 / 6e reference point. However, for CAPIF interconnection, authentication and / or authorization for API callers accessing service APIs are not yet specified. For example, in Figure 2A or Figure 2B In this context, when an API caller registered with (or served by) CCF1 requests access to a service API provided by an AEF registered with (or served by) CCF2, the existing procedures specified for non-interconnected scenarios (e.g., the procedures in Clause 8.11.3 of TS 23.222 and Clause 6.5.2 of TS 33.122) do not apply.

[0007] The purpose of this disclosure is to provide a network node and a method thereof capable of solving or at least mitigating at least one of the aforementioned problems.

[0008] According to a first aspect of this disclosure, a method in a first network function (NF) is provided. The method includes: sending authorization delegation information to a second NF, the authorization delegation information enabling the second NF to authorize service API access from an API caller.

[0009] In an embodiment, the authorization delegation information may include information required by the second NF to authorize access to the service API.

[0010] In this embodiment, the authorization delegation information may be sent in the interconnect API publishing request or in response to a request from a second NF.

[0011] In an embodiment, the method may further include sending a request to the second NF to revoke authorization to the API caller.

[0012] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0013] In an embodiment, the first NF and the second NF can each be a CCF.

[0014] According to a second aspect of this disclosure, a method in a second NF is provided. The method includes: receiving authorization delegation information from a first NF, the authorization delegation information enabling the second NF to authorize service API access to an API caller.

[0015] In an embodiment, the method may further include: receiving an authorization request from an API caller to access a service API, and sending an authorization response containing authorization information to the API caller for the API caller to access the service API.

[0016] In an embodiment, the method may further include: receiving a request from a first NF to revoke authorization to an API caller, and revoking authorization to the API caller in response to the request.

[0017] According to a third aspect of this disclosure, a method is provided in a first normalized network (NF). The method includes: receiving from a second NF an authorization request for an API caller to access a service API. The method further includes: sending an authorization response containing authorization information to the second NF for the API caller to access the service API.

[0018] In this embodiment, the authorization request may include information about the API caller.

[0019] In an embodiment, the method may further include sending a notification to the second NF indicating the revocation of authorization to the API caller.

[0020] According to a fourth aspect of this disclosure, a method in a second NF is provided. The method includes: sending an authorization request to a first NF requesting authorization for an API caller to access a service API. The method further includes: receiving an authorization response from the first NF containing authorization information for the API caller to access the service API.

[0021] In an embodiment, the method may further include sending authorization information to the API caller.

[0022] In an embodiment, the method may further include: receiving a notification from a first NF indicating the revocation of authorization for the API caller, and sending the notification to the API caller indicating the revocation of authorization for the API caller.

[0023] According to a fifth aspect of this disclosure, a method is provided in a first NF. The method includes receiving from a second NF information about access control policies or security information for authentication and / or authorization associated with an API caller.

[0024] In an embodiment, the method may further include sending a request for access control policies or security information to the second NF.

[0025] In an embodiment, the method may further include: receiving a request for access control policy or security information from the AEF, and sending information about the access control policy or security information to the AEF.

[0026] In an embodiment, information about access control policies or security information may be received as a response to a request to proceed to a second NF.

[0027] In an embodiment, security information may include one or more of the following: a key, the root certificate of the API caller, the root certificate of the second NF, or the certificate of the second NF.

[0028] According to a sixth aspect of this disclosure, a method is provided in a second NF. The method includes sending information about access control policies or security information for authentication and / or authorization associated with an API caller to a first NF.

[0029] In an embodiment, the method may further include: receiving a request for access control policies or security information from a first NF.

[0030] According to a seventh aspect of this disclosure, a method is provided in a first NF. The method includes: receiving a request for capability information regarding an AEF from a second NF. The method further includes: sending the capability information to the second NF.

[0031] In an embodiment, capability information may include security methods supported by AEF.

[0032] According to an eighth aspect of this disclosure, a method in a second NF is provided. The method includes: sending a request for capability information of an AEF to a first NF. The method further includes: receiving the capability information from the first NF.

[0033] According to a ninth aspect of this disclosure, a method is provided in a first NF. The method includes: receiving a notification from a second NF that an API caller is no longer valid. The method further includes: sending a notification message to an AEF indicating that the API caller is no longer valid.

[0034] In an embodiment, the method may further include: receiving a notification response message from the AEF indicating that security-related information associated with the API caller has been removed, and forwarding the notification response message to the second NF.

[0035] According to a tenth aspect of this disclosure, a method in a second NF is provided. The method includes sending a notification to a first NF that an API caller is no longer valid. The method further includes receiving a notification response message from the first NF, the notification response message indicating that security-related information associated with the API caller has been removed.

[0036] According to the eleventh aspect of this disclosure, a network node is provided. The network node includes a communication interface, a processor, and a memory. The memory contains instructions executable by the processor, such that the network node is configured to: when implementing a first NF, perform the method according to any one of the first, third, fifth, seventh, or ninth aspects described above; or when implementing a second NF, perform the method according to any one of the second, fourth, sixth, eighth, or tenth aspects described above.

[0037] According to the twelfth aspect of this disclosure, a computer-readable storage medium storing computer-readable instructions is provided. When executed by a processor of a network node, the computer-readable instructions configure the network node to: perform the method according to any one of the first, third, fifth, seventh, or ninth aspects when implementing a first NF, or perform the method according to any one of the second, fourth, sixth, eighth, or tenth aspects when implementing a second NF.

[0038] Through embodiments of this disclosure, a first NF (e.g., an NF serving AEF) and a second NF (e.g., an NF serving an API caller) can exchange information required for the API caller to authenticate and / or authorize access to service APIs opened by AEF, thereby enabling appropriate authentication and / or authorization of the API caller, for example, in a CAPIF interconnect. Attached Figure Description

[0039] The above and other objects, features and advantages will become more apparent from the following description of the embodiments, taken in conjunction with the accompanying drawings, in which:

[0040] Figure 1 This is a schematic diagram illustrating the interconnection between CAPIF providers;

[0041] Figure 2A and Figure 2B Each diagram illustrates the functional architecture of the CAPIF interconnect.

[0042] Figure 3 This is a flowchart illustrating a method in a first NF according to an embodiment of the present disclosure;

[0043] Figure 4 This is a flowchart illustrating a method in a second NF according to an embodiment of the present disclosure;

[0044] Figure 5 This is a flowchart illustrating a method in a first NF according to another embodiment of the present disclosure;

[0045] Figure 6This is a flowchart illustrating a method in a second NF according to another embodiment of the present disclosure;

[0046] Figures 7A to 7C This is a sequence diagram illustrating the process related to API caller authorization according to embodiments of this disclosure;

[0047] Figure 8 This is a flowchart illustrating a method in a first NF according to an embodiment of the present disclosure;

[0048] Figure 9 This is a flowchart illustrating a method in a second NF according to an embodiment of the present disclosure;

[0049] Figure 10A and Figure 10B This is a sequence diagram illustrating the process of acquiring strategies / information according to embodiments of the present disclosure;

[0050] Figure 11 This is a flowchart illustrating a method in a first NF according to an embodiment of the present disclosure;

[0051] Figure 12 This is a flowchart illustrating a method in a second NF according to an embodiment of the present disclosure;

[0052] Figure 13 This is a flowchart illustrating a method in a first NF according to another embodiment of the present disclosure;

[0053] Figure 14 This is a flowchart illustrating a method in a second NF according to another embodiment of the present disclosure;

[0054] Figure 15 This is a block diagram of network nodes according to embodiments of the present disclosure;

[0055] Figure 16 Examples of communication systems according to some embodiments of this disclosure are shown;

[0056] Figure 17 This is a block diagram of an exemplary host according to the various aspects described herein, the host may be Figure 16 An example of a host in a system;

[0057] Figure 18 This is a block diagram illustrating an exemplary virtualization environment in which functionality implemented by some embodiments can be virtualized;

[0058] Figure 19 A communication diagram is shown illustrating communication between an exemplary host and an exemplary UE via an exemplary network node through a partial wireless connection, according to some embodiments of the present disclosure; and

[0059] Figures 20A to 20F This is the diagram used in the appendix. Detailed Implementation

[0060] In this disclosure, a network function or NF (i.e., an NF instance) can be implemented as a network element on dedicated hardware, a software instance running on dedicated hardware, or a virtualized function instantiated on a suitable platform (e.g., cloud infrastructure). The term "network node" refers to any physical or virtual node configured to implement a network function.

[0061] The terms "an embodiment," "embodiment," and "exemplary embodiment" used in this specification indicate that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment must include that specific feature, structure, or characteristic. Furthermore, these expressions do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, those skilled in the art can implement that feature, structure, or characteristic in conjunction with other embodiments, whether explicitly described or not.

[0062] It should be understood that although the terms “first,” “second,” etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. The term “and / or” as used herein includes any and all combinations of one or more of the associated enumerations.

[0063] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein are also intended to include the plural forms. It should also be understood that the terms “comprising,” “including,” “having,” etc., as used herein, specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0064] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0065] Figure 3 This is a flowchart illustrating a method 300 according to an embodiment of the present disclosure. Method 300 may be performed by a first NF, which may be an NF serving an AEF (e.g., a CCF).

[0066] At box 310, the first NF sends authorization delegation information to the second NF, which enables the second NF to authorize the API caller to access the service API. Here, the second NF can be an NF that serves the API caller (e.g., a CCF).

[0067] In the example, the authorization delegation information may contain the information required by the second NF to authorize access to the service API. For example, the authorization delegation information may contain the information required to generate a token, which is then used to authorize the API caller to access the service API.

[0068] In the example, authorization delegation information can be sent in the Interconnect API posting request or in response to a request from the second NF (e.g., an authorization request).

[0069] In the example, the first NF can send a request to the second NF to revoke authorization for the API caller. This request can include information about the API caller, the AEF (Application Function), and the service API that the API caller was authorized to invoke. Then, after the second NF revokes or invalidates the authorization for the API caller, the first NF can receive a response from the second NF.

[0070] Figure 4 This is a flowchart illustrating a method 400 according to an embodiment of the present disclosure. Method 400 may be performed by a second NF, which may be an NF serving an API caller (e.g., a CCF).

[0071] At box 410, the second NF receives authorization delegation information from the first NF, which enables the second NF to authorize the API caller to access the service API. Here, the first NF can be an NF that serves AEF (e.g., CCF).

[0072] In the example, the authorization delegation information may contain the information required by the second NF to authorize access to the service API. For example, the authorization delegation information may contain the information required to generate a token, which is then used to authorize the API caller to access the service API.

[0073] In the example, authorization delegation information can be received in the Interconnect API posting request or as a response to a request to the first NF (e.g., an authorization request).

[0074] In the example, the second NF can receive an authorization request for accessing the service API from the API caller. This authorization request may contain information about the API caller and / or about the service API. The second NF can then send an authorization response containing authorization information for the API caller to access the service API. This authorization information may include a token subsequently used to authorize the API caller to access the service API.

[0075] In the example, the second NF can receive a request from the first NF to revoke authorization for the API caller. This request may contain information about the API caller, the AEF, and the service API. The second NF can then respond to this request by revoking or invalidating the authorization for the API caller and sending a response to the first NF accordingly.

[0076] Figure 5 This is a flowchart illustrating a method 500 according to an embodiment of the present disclosure. Method 500 may be performed by a first NF, which may be an NF serving an AEF (e.g., a CCF).

[0077] At box 510, the first NF receives an authorization request from the second NF authorizing the API caller to access the service API. Here, the second NF can be an NF that serves the API caller (e.g., a CCF). The authorization request may contain information about the API caller and / or information about the service API.

[0078] At box 520, the first NF sends an authorization response containing authorization information to the second NF, which is used by the API caller to access the service API. For example, the authorization information may include a token subsequently used to authorize the API caller to access the service API.

[0079] In the example, the first NF can send a notification to the second NF instructing the revocation of authorization for the API caller. For example, the first NF can revoke authorization for the API caller or invalidate that authorization.

[0080] Figure 6 This is a flowchart illustrating method 600 according to an embodiment of the present disclosure. Method 600 may be performed by a second NF, which may be an NF serving an API caller (e.g., a CCF).

[0081] At box 610, the second NF sends an authorization request to the first NF, authorizing the API caller to access the service API. Here, the first NF can be an NF that serves AEF (e.g., CCF). The authorization request may contain information about the API caller and / or information about the service API.

[0082] At box 620, the second NF receives an authorization response from the first NF containing authorization information used by the API caller to access the service API. For example, this authorization information may include a token subsequently used to authorize the API caller to access the service API.

[0083] In the example, the second NF can also send authorization information to the API caller.

[0084] In the example, the second NF can receive a notification from the first NF instructing the revocation of authorization for the API caller, and send a notification to the API caller instructing the revocation of authorization for the API caller.

[0085] The following will combine Figures 7A to 7C Further explanation of the above method: 300 to 600. In Figures 7A to 7C In each of the diagrams, assume that CCF-A serves AEF, and CCF-B serves the API caller requesting access to the service APIs exposed by AEF.

[0086] Figure 7A The process for publishing a service API for CAPIF interoperability is illustrated. As shown, at step 1, CCF-A obtains the service API to be shared with CCF-B from the API publishing function. At step 2, CCF-A sends an Interconnect API publishing request to CCF-B, which contains details of at least one of the service API or service API category information. CCF-A also determines whether CCF-B is capable of authorizing access to the service API; if so, it sends authorization delegation information to CCF-B in the Interconnect API publishing request. At step 3, CCF-B stores the service API information or service API category provided by CCF-A. At step 4, CCF-B provides CCF-A with an Interconnect API publishing response indicating a success or failure result and triggers notifications to subscribed API callers.

[0087] Figure 7B The authorization process for service API access is illustrated. It is assumed that: the API caller has discovered the service API provided by AEF; the API caller and CCF-B are in the same trust domain; AEF and CCF-A are in the same trust domain; CCF-A and CCF-B are interconnected and have a commercial agreement regarding service API authorization; and CCF-A is the authorization function on AEF for service API access.

[0088] like Figure 7BAs shown, in step 1, the API caller sends a service API authorization request to CCF-B to obtain permission to access the service API, including the API caller's identity information and any information necessary for authenticating the API caller. In step 2, after successfully authenticating / verifying the API caller, if CCF-B determines that it cannot authorize service API access on its own, it sends an API authorization request to CCF-A. CCF-B can include information about the API caller in this request, allowing CCF-A to perform the authorization. Alternatively, if CCF-A has already granted CCF-B permission to authorize service API access (e.g., in situations where...),... Figure 7A In the aforementioned authorization delegation information, CCF-B executes the authorization process specified in Clause 8.11.3 of TS 23.222 without interacting with CCF-A. In steps 3 and 4, based on the API caller's subscription information, the authorization information (via CCF-B) used to access the service API is sent to the API caller in the service API authorization retrieval response.

[0089] Figure 7C The process of revoking authorization for an API caller is illustrated. Here, it is assumed that CCF-A is triggered to revoke authorization for the API caller to access the service API. As shown in the figure, at step 1, if the service API authorization has already been delegated to CCF-B (e.g., in...), Figure 7A In the aforementioned authorization delegation information, CCF-A sends an API caller authorization revocation request to CCF-B. This request contains information about the API caller, AEF, and the service API. At step 2, CCF-B invalidates the API caller's authorization to access the service API. At step 3, CCF-B sends an API caller authorization revocation response to CCF-A.

[0090] As an alternative to steps 1 through 3, if CCF-A has already performed service API authorization, then in step 4, CCF-A sends an API caller authorization revocation notice to CCF-B. Then, in step 5, CCF-A invalidates the API caller's authorization to access the service API. In step 6, CCF-B sends an API caller authorization revocation notice to the API caller.

[0091] Figure 8 This is a flowchart illustrating a method 800 according to an embodiment of the present disclosure. Method 800 may be performed by a first NF, which may be an NF serving an AEF (e.g., a CCF).

[0092] At box 810, the first NF receives information from the second NF regarding access control policies or security information for authentication and / or authorization associated with the API caller. Here, the second NF may be an NF serving the API caller (e.g., a CCF).

[0093] For example, as shown in Table E-1 of TS 23.222, access control policies may include one or more of traffic restrictions, time restrictions, rate restrictions, etc. Security information may include information for authentication and / or authorization of the API caller, such as keys, the API caller's root certificate, the root certificate of the second NF, and / or the certificate of the second NF.

[0094] In the example, information about access control policies or security information may be received as a response to a request to proceed to the second NF.

[0095] In the example, for instance, before box 810, the first NF can send a request for access control policies or security information to the second NF.

[0096] In the example, for instance, before box 810, the first NF can receive requests for access control policies or security information from the AEF. For instance, after box 810, the first NF can send information about access control policies or security information to the AEF.

[0097] Figure 9 This is a flowchart illustrating a method 900 according to an embodiment of the present disclosure. Method 900 may be performed by a second NF, which may be an NF serving an API caller (e.g., a CCF).

[0098] At box 910, the second NF sends information about access control policies or security information for authentication and / or authorization associated with the API caller to the first NF. Here, the first NF may be an NF serving the AEF (e.g., a CCF).

[0099] For example, as shown in Table E-1 of TS 23.222, access control policies may include one or more of traffic restrictions, time restrictions, rate restrictions, etc. Security information may include information for authentication and / or authorization of the API caller, such as keys, the API caller's root certificate, the root certificate of the second NF, and / or the certificate of the second NF.

[0100] In the example, for instance, before box 910, the second NF can receive requests for access control policies or security information from the first NF.

[0101] In the example, information about access control policies or security information can be sent in response to a request from the first NF.

[0102] The following will refer to Figure 10A and Figure 10B Further explanation of methods 800 and 900 above. In Figure 10A and Figure 10B In each of the diagrams, assume that CCF-A serves AEF, and CCF-B serves the API caller requesting access to the service APIs exposed by AEF.

[0103] Figure 10A This illustrates the process of obtaining access control policies in CAPIF interoperability. It is assumed that AEF hosts service APIs but has no available policies for enforcing access control at AEF, CCF-B has available access control policies corresponding to one or more service APIs, and AEF and CCF-A are located in the same trust domain.

[0104] like Figure 10A As shown, in step 1, AEF sends an Access Control Policy Acquisition Request to CCF-A, including details of the hosted service API, to obtain the policy for enforcing access control on service API calls. In step 2, after successful authentication / verification of AEF, if CCF-A determines that it cannot independently authorize the service API access control policy, CCF-A sends an Access Control Policy Acquisition Request to CCF-B. In this request, CCF-A may also send the API caller ID received from AEF. Alternatively, if CCF-A has sufficient available access control policies, it executes the process specified in Clause 8.12.3 of TS 23.222 without interaction with CCF-B. In steps 3 and 4, CCF-B determines the appropriate access control policy for the service API based on the request sent by CCF-A and sends the access control policy information (via CCF-A) to AEF in the Access Control Policy Acquisition Response.

[0105] Figure 10B This illustrates the process of obtaining security information in CAPIF interoperability. It is assumed here that AEF has no security information available for authentication and / or authorization, CCF-B has security information available for authentication and / or authorization corresponding to one or more service APIs, and that AEF and CCF-A reside in the same trust domain.

[0106] like Figure 10BAs shown, at step 1, AEF sends a security information retrieval request to CCF-A, including details of the API caller and the hosted service API, to obtain authentication and / or authorization information to be used in the service API call. At step 2, after successful authentication / verification of AEF, if CCF-A determines that it does not have security information, CCF-A sends a security information retrieval request to CCF-B. On the other hand, if CCF-A has available security information, CCF-A performs the procedures specified in Clauses 8.14.3, 8.15.3, or 8.16.3 of TS 23.222 without interaction with CCF-B. At steps 3 and 4, the security information required for the service API call (via CCF-A) is sent to AEF in the security information retrieval response.

[0107] Figure 11 This is a flowchart illustrating a method 1100 according to an embodiment of the present disclosure. Method 1100 may be performed by a first NF, which may be an NF serving an AEF (e.g., a CCF).

[0108] At box 1110, the first NF receives a request for AEF capability information from the second NF. Here, the second NF can be an NF that serves the API caller (e.g., CCF).

[0109] At box 1120, the first NF sends capability information to the second NF.

[0110] In the example, capability information may include security methods supported by AEF, such as method 1, method 2, or method 3 as specified in clauses 6.5.2.1, 6.5.2.2, and 6.5.2.3 of TS 33.122.

[0111] Figure 12 This is a flowchart illustrating method 1200 according to an embodiment of this disclosure. Method 1200 may be performed by a second NF, which may be an NF serving an API caller (e.g., a CCF).

[0112] At box 1210, the second NF sends a request for AEF capability information to the first NF. Here, the first NF can be an NF that serves AEF (e.g., CCF).

[0113] At box 1220, the second NF receives capability information from the first NF.

[0114] In the example, capability information may include security methods supported by AEF, such as method 1, method 2, or method 3 as specified in clauses 6.5.2.1, 6.5.2.2, and 6.5.2.3 of TS 33.122.

[0115] Figure 13 This is a flowchart illustrating method 1300 according to an embodiment of the present disclosure. Method 1300 may be performed by a first NF, which may be an NF serving AEF (e.g., CCF).

[0116] At box 1310, the first NF receives a notification from the second NF that the API caller is no longer valid. Here, the second NF can be the NF that serves the API caller (e.g., CCF).

[0117] At box 1320, the first NF sends a notification message to the AEF indicating that the API caller is no longer valid.

[0118] In the example, for instance, after box 1320, the first NF may also receive a notification response message from the AEF indicating that security-related information associated with the API caller has been removed, and forward the notification response message to the second NF.

[0119] Figure 14 This is a flowchart illustrating method 1400 according to an embodiment of this disclosure. Method 1400 may be performed by a second NF, which may be an NF serving an API caller (e.g., a CCF).

[0120] At box 1410, the second NF sends a notification to the first NF that the application programming interface (API) caller is no longer valid. Here, the first NF can be an NF that serves AEF (e.g., CCF).

[0121] At box 1420, the second NF receives a notification response message from the first NF indicating that security-related information associated with the API caller has been removed.

[0122] In some embodiments, an NF node (e.g., a first NF node or a second NF node) is provided for implementing any of the methods 300 to 600, 800 to 900, and 1100 to 1400 described above. The NF node includes one or more units for performing the steps of any of the methods 300 to 600, 800 to 900, and 1100 to 1400 described above.

[0123] Figure 15 This is a block diagram of a network node 1500 according to an embodiment of the present disclosure.

[0124] Network node 1500 includes a communication interface 1510, a processor 1520, and a memory 1530.

[0125] Memory 1530 may contain instructions executable by processor 1520, such that network node 1500 is configured to perform, for example, previously combined, instructions when implementing the first NF. Figure 3The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to send authorization delegation information to a second NF when implementing the first NF, the authorization delegation information enabling the second NF to authorize service API access from the API caller.

[0126] In an embodiment, the authorization delegation information may include information required by the second NF to authorize access to the service API.

[0127] In this embodiment, the authorization delegation information may be sent in the interconnect API publishing request or in response to a request from a second NF.

[0128] In an embodiment, memory 1530 may also contain instructions executable by processor 1520, such that network node 1500 is configured to send a request to the second NF to revoke authorization to the API caller when implementing the first NF.

[0129] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0130] In an embodiment, the first NF and the second NF can each be a CCF.

[0131] Alternatively, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to perform, for example, previously combined, actions when implementing a second NF. Figure 4 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to receive authorization delegation information from the first NF when implementing the second NF, the authorization delegation information enabling the second NF to authorize service API access from the API caller.

[0132] In an embodiment, the authorization delegation information may include information required by the second NF to authorize access to the service API.

[0133] In this embodiment, the authorization delegation information may be received in the interconnect API publishing request or as a response to a request to the first NF.

[0134] In an embodiment, the memory 1530 may also contain instructions executable by the processor 1520, such that the network node 1500 is configured to receive an authorization request for accessing the service API from the API caller when implementing the second NF, and send an authorization response containing authorization information for the API caller to access the service API.

[0135] In an embodiment, the memory 1530 may also contain instructions executable by the processor 1520, such that the network node 1500 is configured to receive a request to revoke authorization of an API caller from the first NF when implementing the second NF, and revoke authorization of the API caller in response to the request.

[0136] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0137] In an embodiment, the first NF and the second NF can each be a CCF.

[0138] Alternatively, memory 1530 may contain instructions executable by processor 1520, such that network node 1500 is configured to perform, for example, previously combined, instructions when implementing the first NF. Figure 5 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, such that network node 1500, upon implementing the first NF, receives an authorization request from the second NF for an authorized API caller to access the service API, and sends an authorization response containing authorization information for the API caller to access the service API.

[0139] In this embodiment, the authorization request may include information about the API caller.

[0140] In an embodiment, the memory 1530 may also contain instructions executable by the processor 1520, such that the network node 1500 is configured to send a notification to the second NF indicating the revocation of authorization to the API caller when implementing the first NF.

[0141] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0142] In an embodiment, the first NF and the second NF can each be a CCF.

[0143] Alternatively, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to perform, for example, previously combined, actions when implementing a second NF. Figure 6 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to send an authorization request for an authorized API caller to access the service API to the first NF when implementing the second NF, and to receive an authorization response from the first NF containing authorization information for the API caller to access the service API.

[0144] In this embodiment, the authorization request may include information about the API caller.

[0145] In an embodiment, memory 1530 may also contain instructions executable by processor 1520, such that network node 1500 is configured to send authorization information to API callers when implementing the second NF.

[0146] In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520, such that the network node 1500, when implementing the second NF, receives a notification from the first NF indicating the revocation of authorization for the API caller, and sends a notification to the API caller indicating the revocation of authorization for the API caller.

[0147] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0148] In an embodiment, the first NF and the second NF can each be a CCF.

[0149] Alternatively, memory 1530 may contain instructions executable by processor 1520, such that network node 1500 is configured to perform, for example, previously combined, instructions when implementing the first NF. Figure 8 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to receive, upon implementing the first NF, information from the second NF regarding access control policies or security information for authentication and / or authorization associated with the API caller.

[0150] In an embodiment, the memory 1530 may also contain instructions executable by the processor 1520, such that the network node 1500 is configured to send a request for access control policies or security information to the second NF when implementing the first NF.

[0151] In an embodiment, the memory 1530 may also contain instructions executable by the processor 1520, such that the network node 1500 is configured to receive a request for access control policy or security information from the AEF when implementing the first NF, and to send information about the access control policy or security information to the AEF.

[0152] In an embodiment, information about access control policies or security information may be received as a response to a request to proceed to a second NF.

[0153] In an embodiment, security information may include one or more of the following: a key, the root certificate of the API caller, the root certificate of the second NF, or the certificate of the second NF.

[0154] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0155] In an embodiment, the first NF and the second NF can each be a CCF.

[0156] Alternatively, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to perform, for example, previously combined, actions when implementing a second NF. Figure 9 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to send information about access control policies or security information for authentication and / or authorization associated with the API caller to the first NF when implementing the second NF.

[0157] In an embodiment, the memory 1530 may also contain instructions executable by the processor 1520, such that the network node 1500 is configured to receive a request for access control policies or security information from the first NF when implementing the second NF.

[0158] In an embodiment, information about access control policies or security information may be sent in response to a request from a first NF.

[0159] In an embodiment, security information may include one or more of the following: a key, the root certificate of the API caller, the root certificate of the second NF, or the certificate of the second NF.

[0160] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0161] In an embodiment, the first NF and the second NF can each be a CCF.

[0162] Alternatively, memory 1530 may contain instructions executable by processor 1520, such that network node 1500 is configured to perform, for example, previously combined, instructions when implementing the first NF. Figure 11 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to receive a request for AEF capability information from a second NF and send capability information to the second NF when implementing the first NF.

[0163] In an embodiment, capability information may include security methods supported by AEF.

[0164] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0165] In an embodiment, the first NF and the second NF can each be a CCF.

[0166] Alternatively, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to perform, for example, previously combined, actions when implementing a second NF. Figure 12 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to send a request for AEF capability information to the first NF and receive capability information from the first NF when implementing the second NF.

[0167] In an embodiment, capability information may include security methods supported by AEF.

[0168] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0169] In an embodiment, the first NF and the second NF can each be a CCF.

[0170] Alternatively, memory 1530 may contain instructions executable by processor 1520, such that network node 1500 is configured to perform, for example, previously combined, instructions when implementing the first NF. Figure 13 The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, such that network node 1500, upon implementing the first NF, receives a notification from the second NF that the API caller is no longer valid, and sends a notification message to the AEF indicating that the API caller is no longer valid.

[0171] In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520, such that the network node 1500, upon implementing the first NF, receives a notification response message from the AEF indicating that security-related information associated with the API caller has been deleted, and forwards the notification response message to the second NF.

[0172] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0173] In an embodiment, the first NF and the second NF can each be a CCF.

[0174] Alternatively, memory 1530 may contain instructions executable by processor 1520, causing network node 1500 to perform, for example, previously combined, actions when implementing a second NF. Figure 14The described process involves actions. Specifically, memory 1530 may contain instructions executable by processor 1520, such that network node 1500, upon implementing the second NF, sends a notification to the first NF that the API caller is no longer valid, and receives from the first NF a notification response message indicating that security-related information associated with the API caller has been deleted.

[0175] In this embodiment, the first NF can serve the AEF, and the second NF can serve the API caller.

[0176] In an embodiment, the first NF and the second NF can each be a CCF.

[0177] This disclosure also provides at least one computer program product in the form of non-volatile or volatile memory, such as a non-transitory computer-readable storage medium, an electrically erasable programmable read-only memory (EEPROM), flash memory, and a hard disk drive. The computer program product includes a computer program. The computer program includes code / computer-readable instructions that, when executed by processor 1520, cause network node 1500 to perform, for example, the previously combined... Figures 3 to 6 , Figures 8 to 9 as well as Figures 11 to 14 The actions of the process described by any of the diagrams in the diagram.

[0178] Computer program products can be configured as computer program code structured into computer program modules. These computer program modules are essentially executable. Figures 3 to 6 , Figures 8 to 9 as well as Figures 11 to 14 The actions of any of the processes shown in the diagram.

[0179] The processor may be a single CPU (Central Processing Unit), but may also include two or more processing units. For example, the processor may include a general-purpose microprocessor, an instruction set processor and / or an associated chipset, and / or a special-purpose microprocessor such as an application-specific integrated circuit (ASIC). The processor may also include onboard memory for caching purposes. The computer program may be carried in a computer program product connected to the processor. The computer program product may include a non-transitory computer-readable storage medium storing the computer program. For example, the computer program product may be flash memory, random access memory (RAM), read-only memory (ROM), or EEPROM, and in alternative embodiments, the aforementioned computer program modules may be distributed as memory across different computer program products.

[0180] Figure 16 An example of a communication system 1600 according to some embodiments is shown.

[0181] In this example, communication system 1600 includes telecommunications network 1602, which includes access network 1604 (e.g., radio access network (RAN)) and core network 1606. Core network 1606 includes one or more core network nodes 1608. Access network 1604 includes one or more access network nodes, such as network nodes 1610a and 1610b (one or more of which may generally be referred to as network node 1610), or any other similar 3GPP access node or non-3GPP access point. Network node 1610 facilitates direct or indirect connections of user equipment (UE), such as connecting UEs 1612a, 1612b, 1612c, and 1612d (one or more of which may generally be referred to as UE 1612) to core network 1606 via one or more radio connections.

[0182] Examples of wireless communication via wireless connection include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wires, cables, or other conductors. Furthermore, in various embodiments, communication system 1600 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 1600 may include and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar types of systems.

[0183] UE 1612 can be any of a wide variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 1610 and other communication devices. Similarly, network node 1610 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE 1612 and / or with other network nodes or devices in telecommunication network 1602 to achieve and / or provide network access (e.g., wireless network access) and / or perform other functions (e.g., management in telecommunication network 1602).

[0184] In the depicted example, core network 1606 connects network node 1610 to one or more hosts, such as host 1616. These connections can be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1606 includes one or more core network nodes (e.g., core network node 1608) comprised of hardware and software components. The characteristics of these components may be substantially similar to those described with respect to UEs, network nodes, and / or hosts, such that the description thereof generally applies to the corresponding components of core network node 1608. Example core network nodes include one or more of the following functions: Network Repository Function (NRF), 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 Dehiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0185] Host 1616 may be owned or under the control of a service provider other than the operator or provider of access network 1604 and / or telecommunications network 1602, and may be operated by or on behalf of that service provider. Host 1616 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 alarms and monitoring centers, or any other such functions performed by the server.

[0186] Overall, Figure 16The communication system 1600 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.

[0187] In some examples, telecommunications network 1602 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 1602 can support network slicing, providing different logical networks for different devices connected to it. For example, telecommunications network 1602 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.

[0188] In some examples, UE 1612 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 1604 according to a predetermined schedule when triggered by internal or external events or in response to a request from access network 1604. Furthermore, 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 or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multiple radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) NR-Dual Connectivity (EN-DC).

[0189] In this example, hub 1614 communicates with access network 1604 to facilitate indirect communication between one or more UEs (e.g., UE 1612c and / or 1612d) and network nodes (e.g., network node 1610b). In some examples, hub 1614 may be a controller, router, content source and analyzer, or any other communication device described herein relating to the UE. For example, hub 1614 may be a broadband router that enables the UE to access core network 1606. As another example, hub 1614 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 1610, or via executable code, scripts, procedures, or other instructions in hub 1614. As another example, hub 1614 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 1614 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, hub 1614 can retrieve VR assets, video, audio, or other media or data related to perceived information via network nodes, and then provide them directly to the UE after performing local processing and / or adding additional local content. In yet another example, hub 1614 acts as a proxy server or orchestrator for the UE, particularly if one or more of the UEs are low-power IoT devices.

[0190] The hub 1614 can have a constant / persistent connection or an intermittent connection with the network node 1610b. The hub 1614 can also allow different communication schemes and / or scheduling between the hub 1614 and the UE (e.g., UE 1612c and / or UE 1612d) and between the hub 1614 and the core network 1606. In other examples, the hub 1614 is connected to the core network 1606 and / or one or more UEs via a wired connection. Furthermore, the hub 1614 can be configured to connect to an M2M service provider via the access network 1604, and / or to another UE via a direct connection. In some scenarios, a UE can establish a wireless connection with the network node 1610b while still being connected via the hub 1614 via a wired or wireless connection. In some embodiments, the hub 1614 can be a dedicated hub, meaning its primary function is to route communication from the network node 1610b to the UE and / or to the network node 1610b. In other embodiments, the hub 1614 may be a non-dedicated hub, that is, a device capable of operating to route communication between the UE and the network node 1610b, but also capable of operating as a communication start and / or end point for certain data channels.

[0191] Figure 17Based on the block diagram of the host 1700 described in this document, the host 1700 can be... Figure 16 The embodiment of host 1616. Host 1700 as used herein can be or include various combinations of hardware and / or software (including standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources in server clusters). Host 1700 can provide one or more services to one or more UEs.

[0192] The host 1700 includes processing circuitry 1702 operatively coupled via a bus 1704 to an input / output interface 1706, a network interface 1708, a power supply 1710, and a memory 1712. Other components may be included in other embodiments. The features of these components may be substantially similar to those described with respect to the device in the preceding figures, such that the description is generally applicable to the corresponding components of the host 1700.

[0193] Memory 1712 may include one or more computer programs, including one or more host applications 1714 and data 1716, which may include user data, such as data generated by the UE for the host 1700, or data generated by the host 1700 for the UE. Embodiments of the host 1700 may utilize only a subset or all of the illustrated components. Host application 1714 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Universal Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for various categories, types, or implementations of UEs (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). Host application 1714 may also provide user authentication and authorization checks and may periodically report health status, routing, and content availability to a central node (e.g., devices in the core network or devices at the edge of the core network). Therefore, host 1700 can select and / or indicate different hosts for over-the-top services for the UE. Host application 1714 can support various protocols, such as HTTP Live Streaming (HLS), Real-time Messaging Protocol (RTMP), Real-time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0194] Figure 18This is a block diagram illustrating a virtualization environment 1800 in which functionality implemented by some embodiments can be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device that may include a virtualization hardware platform, storage devices, and network resources. Virtualization as used herein can be applied to any device or component thereof described herein, and relates to implementations where at least a portion of the functionality is implemented as 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 virtualization environments 1800 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.

[0195] Application 1802 (which may also be referred to as a software instance, virtual application, network function, virtual node, virtual network function, etc.) operates in virtualization environment 1800 to implement some of the features, functions and / or benefits of some embodiments disclosed herein.

[0196] Hardware 1804 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (e.g., network interfaces, input / output interfaces, etc.). The software can be executed by the processing circuitry to instantiate one or more virtualization layers 1806 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1808a and 1808b (one or more of which may generally be referred to as VM 1808), and / or perform any functionality, features, and / or benefits described in relation to some embodiments described herein. Virtualization layer 1806 can present a virtual operating platform to VM 1808, which appears as network hardware.

[0197] VM 1808 includes virtual processing, virtual memory, virtual network or interface, and virtual storage, and can be run by a corresponding virtualization layer 1806. Different embodiments of instances of virtual device 1802 can be implemented on one or more VMs 1808, and these implementations can be made in different ways. In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV can be used to unify numerous network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage that can reside in data centers and customer premises equipment (CPE).

[0198] In the context of NFV, VM 1808 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 1808, along with the portion of hardware 1804 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 the specific network functions running on one or more VMs 1808 above hardware 1804 and corresponding to application 1802.

[0199] Hardware 1804 can be implemented in a standalone network node with general or specific components. Hardware 1804 can implement some functions via virtualization. Alternatively, hardware 1804 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 1810, which in particular oversees the lifecycle management of application 1802. In some embodiments, hardware 1804 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 1812, which can also be used for communication between hardware nodes and radio units.

[0200] Figure 19 A communication diagram is shown illustrating communication between host 1902 and UE 1906 via network node 1904 through a partial wireless connection according to some embodiments. Reference will now be made to... Figure 19 Describe the UE discussed in the preceding paragraphs (e.g., Figure 16 UE1612a in the network (e.g., UE1612a), network nodes (e.g. Figure 16 Network node 1610a) and host (e.g., Figure 16 Host 1616 and / or Figure 17 Example implementations of host 1700 in various embodiments.

[0201] Similar to host 1700, embodiments of host 1902 include hardware such as a communication interface, processing circuitry, and memory. Host 1902 also includes software stored in or accessible by host 1902 and executable by the processing circuitry. This software includes a host application operable to provide services to a remote user, such as UE 1906 connected via an over-the-top (OTT) connection 1950 extending between UE 1906 and host 1902. When providing services to a remote user, the host application can provide user data transmitted using OTT connection 1950.

[0202] Network node 1904 includes hardware that enables it to communicate with host 1902 and UE 1906. Connection 1960 can be a direct connection or via a core network (such as...). Figure 16 The connection between the core network (1606) and / or one or more other intermediate networks (e.g., one or more public, private, or hosted networks). For example, an intermediate network could be a backbone network or the Internet.

[0203] UE 1906 includes hardware and software, the software being stored in or accessible by UE 1906 and executable by the UE's processing circuitry. This software includes client applications (e.g., web browsers or operator-specific "applications") operable to provide services to human or non-human users via UE 1906, supported by host 1902. In host 1902, the executing host application can communicate with the executing client application via OTT connection 1950, which terminates between UE 1906 and host 1902. When providing services to a user, the UE's client application can receive request data from the host application of the host and, in response to that request data, provide user data. OTT connection 1950 can transmit both request data and user data. The UE's client application can interact with the user to generate user data provided to the host application via OTT connection 1950.

[0204] OTT connection 1950 can be extended via connection 1960 between host 1902 and network node 1904 and via wireless connection 1970 between network node 1904 and UE 1906 to provide connectivity between host 1902 and UE 1906. Connection 1960 and wireless connection 1970, which provide OTT connection 1950, have been abstractly drawn to illustrate communication between host 1902 and UE 1906 via network node 1904, without explicitly involving any intermediate devices and the precise routing of messages via these devices.

[0205] As an example of sending data via OTT connection 1950, in step 1908, host 1902 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 1906. In other embodiments, the user data is associated with UE 1906, which shares data with host 1902 without explicit human interaction. In step 1910, host 1902 initiates a transmission to UE 1906 carrying the user data. Host 1902 may initiate the transmission in response to a request sent by UE 1906. This request may be caused by human interaction with UE 1906 or by the operation of a client application executed on UE 1906. According to the teachings of the embodiments described throughout this disclosure, this transmission may be carried out via network node 1904. Therefore, in step 1912, in accordance with the teachings of the embodiments described throughout this disclosure, network node 1904 sends user data carried in a transmission initiated by host 1902 to UE 1906. In step 1914, UE 1906 receives the user data carried in the transmission, which can be performed by a client application running on UE 1906, associated with a host application running by host 1902.

[0206] In some examples, UE 1906 executes a client application that provides user data to host 1902. User data can be provided as a response to data received from host 1902. Therefore, in step 1916, UE 1906 can provide user data, which can be done by executing the client application. When providing user data, the client application may also consider user input received from a user via the input / output interface of UE 1906. Regardless of the specific manner in which user data is provided, UE 1906 initiates the transmission of user data to host 1902 via network node 1904 in step 1918. In step 1920, in accordance with the teachings of the embodiments described throughout this disclosure, network node 1904 receives user data from UE 1906 and initiates the transmission of the received user data to host 1902. In step 1922, host 1902 receives the user data carried in the transmission initiated by UE 1906.

[0207] One or more embodiments in various implementations improve the performance of OTT services provided to UE 1906 using OTT connection 1950, wherein wireless connection 1970 forms the final segment. More specifically, the teachings of these embodiments can improve data rates, latency, and power consumption, thereby providing benefits such as reduced user wait times, relaxed file size limits, improved content resolution, improved responsiveness, and extended battery life.

[0208] In the example scenario, host 1902 can collect and analyze plant status information. As another example, host 1902 can process audio and video data that may have been retrieved from the UE for creating mappings. As another example, host 1902 can collect and analyze real-time data to help control vehicle congestion (e.g., control traffic lights). As another example, host 1902 can store monitoring video uploaded by the UE. As another example, host 1902 can store or control access to media content such as video, audio, VR, or AR, which can be broadcast, multicast, or unicast to the UE. As other examples, host 1902 can be used for energy pricing, remote control of non-time-critical power loads to balance generation demand, location services, presentation services (e.g., compiling charts based on data collected from remote devices), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

[0209] In some examples, a measurement process may be provided for monitoring data rate, latency, and other factors that are the object of improvement in one or more embodiments. Optional network functions may also be present for reconfiguring the OTT connection 1950 between host 1902 and UE 1906 in response to changes in measurement results. The measurement process and / or the network functions for reconfiguring the OTT connection may be implemented in the software and hardware of host 1902 and / or UE 1906. In some embodiments, sensors (not shown) may be deployed in or associated with other devices traversed by the OTT connection 1950; the sensors may participate in the measurement process by providing values ​​of the monitored quantities exemplified above or by providing values ​​of other physical quantities from which the software can calculate or estimate the monitored quantities. Reconfiguring the OTT connection 1950 may include message formats, retransmission settings, preferred routing, etc.; reconfiguration does not require a direct change to the operation of network node 1904. Such processes and functions may be known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling that facilitates host 1902's measurement of throughput, propagation time, latency, etc. Measurements can be achieved by having the software use an OTT connection 1950 to send messages (especially empty or “virtual” messages) while monitoring propagation time, errors, etc.

[0210] While the computing devices described herein (e.g., UE, network node, host) may include combinations of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by processing circuitry that may process information, for example, by: converting acquired information into other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making a determination based on the results of the above processing. Furthermore, although components are depicted as a single box within a larger box or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions in any such component may be implemented in software or firmware, while computationally intensive functions may be implemented in hardware.

[0211] In some embodiments, some or all of the functions described herein may be provided by processing circuitry executing instructions stored in memory, which may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium; for example, these functions may be provided in a hard-wired manner. In any of these particular embodiments, the processing circuitry may be configured to perform the described functions regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by these functions are not limited to the processing circuitry itself or other components of the computing device, but can be enjoyed by the entire computing device and / or end user and the wireless network as a whole.

[0212] The present disclosure has been described above with reference to embodiments thereof. It should be understood that those skilled in the art can make various modifications, alterations, and additions without departing from the spirit and scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the specific embodiments described above, but is defined only by the appended claims.

[0213] This disclosure also includes changes to 3GPP TS 23.222 as described in Appendix A below and changes to 3GPP TS 33.122 as described in Appendix B below.

[0214] Appendix A

[0215]

[0216] Further discussion:

[0217] In TS 23.222 Figure 6 .2.2-1 illustrates the architecture model of CAPIF interconnection, which allows API callers of a CAPIF provider to utilize service APIs from third-party CAPIF providers.

[0218] Figure 6 2.2-1: High-level functional architecture of CAPIF interconnect with multiple CAPIF provider domains (see...) Figure 2A )

[0219] In the above architecture, API provider domain functions are registered with CCFs within the same trust domain. The CCFs connect via CAPIF-6e to share service APIs. API provider domain functions are unaware of interconnected CCFs in other domains. API callers registered with one CAPIF provider can use service APIs provided in another domain via CAPIF-2e.

[0220] * * * First Change * * * *

[0221] 8.11.3 Process

[0222] Figure 8 .11.3-1 illustrates the process of obtaining authorization to access the service API.

[0223] Prerequisites:

[0224] 1. The API caller has been registered and its identity has been received.

[0225] Figure 8 11.3-1: The process by which an API caller obtains authorization to access the service API (see...) Figure 20A )

[0226] 1. By sending a Service API Authorization Request to the CAPIF core functionality, including the API caller's identity information and any other information required to authenticate the API caller, the API caller obtains permission to access the Service API.

[0227] 2. The core CAPIF function (using authentication information) verifies the authentication of the API caller and, if the service API authorization is executed locally, checks whether the API caller is authorized to access the requested service API.

[0228] Note 1: The certification process is specified in subclause 6.5.2.3 of 3GPP TS 33.122

[12] .

[0229] 3. Based on the API caller's subscription information, send authorization information for accessing the service API to the API caller in the service API authorization retrieval response.

[0230] * * * Next change * * * *

[0231] 8.25.2.1 Interconnect API Posting Request

[0232] Table 8.25.2.1-1 describes the API publishing request for information flow interconnection from CAPIF core functionality to CAPIF core functionality.

[0233] Table 8.25.2.1-1: Interconnect API Posting Request

[0234]

[0235] * * * Next change * * * *

[0236] 8.25.2.9 Interconnect Update Service API Request

[0237] Table 8.25.2.9-1 describes the API request for information flow interconnection and update services from one CAPIF core function to another.

[0238] Table 8.25.2.9-1: Interconnection Update Service API Requests

[0239]

[0240] * * * Next change * * * *

[0241] 8.25.3.1 Service API Publishing for CAPIF Interconnect

[0242] This sub-clause describes the process of publishing service APIs for CAPIF interoperability.

[0243] Prerequisites:

[0244] 1. CCF-A and CCF-B are interconnected and belong to the same single trust domain of the same CAPIF provider, or to trust domains of different CAPIF providers.

[0245] 2. CCF-B is configured as the designated CAPIF core function in the trust domain of CAPIF provider A.

[0246] 3. When CCF-A and CCF-B belong to the trust domains of different CAPIF providers, the two CAPIF providers have a business agreement regarding the sharing of service APIs.

[0247] Figure 8 .25.3.1-1: Interconnect API Release (see...) Figure 7A )

[0248] 1. As described in Subclause 8.3.3, CCF-A obtains the service API to be shared with CCF-B from the API publishing function located in the same CAPIF provider domain as CCF-A, or as described in this procedure, obtains the service API to be shared with CCF-B from another CCF.

[0249] 2. Based on the shareable information or service API category information of the service API, CCF-A determines to publish the service API or service API category information to CCF-B. CCF-A sends an Interconnect API Publication Request to CCF-B, which includes details of at least one of the service API or service API category information, as well as CCF-A's identity information, shareable information, and CAPIF provider domain information (if sharing is permitted). API topology hiding may be enabled. CCF-A also determines whether CCF-B can authorize access to the service API and sends authorization delegation information to CCF-B in the Interconnect API Publication Request.

[0250] 3. CCF-B stores service API information or service API categories provided by CCF-A.

[0251] 4. CCF-B provides CCF-A with an interconnect API posting response indicating a success or failure result, and triggers notifications to subscribed API callers as described in Subclause 8.8.4.

[0252] * * * Next change * * * *

[0253] In version 8.25.3.x1, API callers obtain authorization to access service APIs within the CAPIF interconnect.

[0254] Prerequisites:

[0255] 1. The API caller has discovered the service API provided by AEF through the procedures specified in steps 1 and 2 of Clause 8.25.3.2.

[0256] 2. The API caller and CCF-B are located in the same trust domain.

[0257] 3. AEF and CCF-A are located in the same trust domain.

[0258] 4. CCF-A and CCF-B are interconnected, and both have a commercial agreement regarding the licensing of service APIs.

[0259] 5. CCF-A is an authorization feature for accessing service APIs on AEF.

[0260] Figure 8 .25.3.x1-1: The process by which an API caller obtains authorization to access the service API (see...) Figure 7B )

[0261] 1. By sending a Service API Authorization Acquisition Request to CCF-B, including the API caller's identity information and any other information required to authenticate the API caller, the API caller obtains permission to access the Service API.

[0262] 2. After successfully verifying the API caller's authentication, if CCF-B determines that it cannot complete the service API access authorization on its own, CCF-B sends an API authorization request to CCF-A. In this request, CCF-B may also send information about the API caller so that CCF-A can perform the authorization.

[0263] Note: If CCF-A has previously authorized CCF-B to authorize access to the service API, CCF-B will perform the procedures specified in Clause 8.11.3 without interacting with CCF-A.

[0264] 3-4. Based on the API caller's subscription information, the authorization information (via CCF-B) used to access the service API is sent to the API caller in the service API authorization retrieval response.

[0265] Version 8.25.3.x2 describes the process by which CAPIF revokes authorization for API callers in the CAPIF interconnect.

[0266] Prerequisites:

[0267] 1. CCF-A was triggered to revoke the authorization for the API caller to access the service API.

[0268] Figure 8 .25.3.x2-1: The procedure for revoking authorization for an API caller in a CAPIF interconnect (see...) Figure 7C )

[0269] 1. If the service API authorization has been delegated to CCF-B, CCF-A sends an API caller authorization revocation request to CCF-B, which includes details of the API caller, AEF, and service API.

[0270] 2. Upon receiving information to revoke authorization for an API caller to make a service API call, CCF-B invalidates the authorization of the API caller corresponding to the service API.

[0271] 3. CCF-B sends an API caller authorization revocation response to CCF-A.

[0272] 4. As an alternative to steps 1 to 3, if CCF-A performed service API authorization, CCF-A sends an API caller authorization revocation notice to CCF-B.

[0273] 5. CCF-A invalidates the authorization of the API caller corresponding to the service API.

[0274] 6. CCF-B sends API caller authorization revocation notices to API callers whose service API access authorization has been revoked.

[0275] 8.25.3.x3 The process of obtaining access control policies in CAPIF interconnect.

[0276] Prerequisites:

[0277] 1. AEF is hosting a service API, but AEF does not have a policy available to enforce access control.

[0278] 2. CCF-B has available access control policies corresponding to one or more service APIs.

[0279] 3. AEF and CCF-A are located in the same trust domain.

[0280] (See) Figure 10A )

[0281] 1. By sending an Access Control Policy Acquisition Request to CCF-A, including details of the hosted service API, AEF obtains the policies used to enforce access control on service API calls.

[0282] 2. After successfully verifying AEF authentication, if CCF-A determines that it cannot independently complete the authorization of service API access control policies, CCF-A sends an access control policy retrieval request to CCF-B. In this request, CCF-A may also send the API caller ID received from AEF.

[0283] Note 1: If CCF-A has sufficient available access control policies, CCF-A will execute the procedures specified in Clause 8.12.3 without interacting with CCF-B.

[0284] 3-4. CCF-B determines the appropriate access control policy for the service API based on the request sent by CCF-A. In the access control policy retrieval response, the access control policy information (via CCF-A) is sent to AEF.

[0285] Note 2: To maintain synchronization between AEF and CCF regarding policies cached at AEF, AEF may subscribe to policy update events at CCF-A according to the procedures in Clause 8.8.3, and receive notifications regarding any updated policies at CCF-A according to the procedures in Clause 8.8.4. Accordingly, if service API authorization is performed by CCF-B, CCF-A may subscribe to policy update events at CCF-B.

[0286] 8.25.3.x4 The process of obtaining security information in CAPIF interconnect.

[0287] Prerequisites:

[0288] 1. AEF has no security information available for authentication and / or authorization.

[0289] 2. CCF-B has security information corresponding to one or more service APIs that can be used for authentication and / or authorization.

[0290] 3. AEF and CCF-A are located in the same trust domain.

[0291] (See) Figure 10B )

[0292] 1. AEF sends a security information retrieval request to CCF-A with details including the API caller and the hosted service API to obtain authentication and / or authorization information that will be used in the service API call.

[0293] 2. After successfully verifying AEF's authentication, if CCF-A determines that it has no security information, CCF-A sends a security information retrieval request to CCF-B.

[0294] Note 1: If CCF-A has available security information, CCF-A will perform the procedures specified in Clauses 8.14.3, 8.15.3 or 8.16.3 without interacting with CCF-B.

[0295] 3-4. In the security information retrieval response, send the security information required for the service API call (via CCF-A) to AEF.

[0296] Note 2: CCF-A may subscribe to API caller onboarding events at CCF-B according to the procedure in Clause 8.8.3, and receive notifications about any onboarded API callers at CCF-B and their security-related onboarding information according to the procedure in Clause 8.8.4.

[0297] Appendix B

[0298]

[0299] ******* First change begins*******

[0300] 6.3.1.2 Negotiation of Security Methods

[0301] The API caller and the CAPIF core functionality should negotiate a security method for CAPIF-2e interface authentication and protection, which will be used by the API caller and API Open Functionality. After successful mutual authentication on the CAPIF-1e interface, the CAPIF core functionality should select a security method based on the service API subscribed to by the API caller, the access scenario (whether the API caller accesses the AEF before or during the service API call), and the AEF capabilities. The selected security method, along with the information required for authentication of the API caller at the AEF, should be sent to the API caller. This information may include the validity period of the CAPIF-2e credentials. Figure 6 As shown in .3.1-1.

[0302] Prerequisites:

[0303] 1. API callers have been integrated into CAPIF's core functionality.

[0304] Figure 6 3.1-1: Selection of the safety method to be used in the CAPIF-2 / 2e reference point (see...) Figure 20B )

[0305] 1. TLS should be used to establish mutual authentication between the API caller and the CAPIF core functionality, based on client and server certificates. The client certificate provided to the API caller upon successful onboarding should be used, as described in subclause 6.1 of this document.

[0306] 2. API callers can send CAPIF-2 / 2e security capability information to the CAPIF core functionality in a security method request message, indicating a list of security methods supported for each AEF at the CAPIF-2 / 2e reference point. API callers may include the addresses of the CAPIF core functionality serving each AEF.

[0307] 3. The CAPIF core function should consider the information from the API caller, the access scenario, and the AEF capabilities from step 2, and select a security method to use at the CAPIF-2 / 2e reference point for each request's AEF. The CAPIF core function may learn about the AEF capabilities during the AEF publication process as specified in Clauses 8.3.3, 8.6.3, 8.25.3.1, or 8.25.3.6 of TS23.222 [3]. If the CAPIF core function does not have AEF capability information, it should obtain the AEF capability information from the CAPIF core function serving that AEF.

[0308] 4. The CAPIF core functionality shall send a security method response message to the API caller, indicating the security method selected for each AEF and any security information associated with that security method. The API caller shall use this method when subsequently establishing communication with the API open functionality at the CAPIF-2 / 2e reference point, as described in subclause 6.5 of this document.

[0309] ******* Next change*******

[0310] 6.5.2.1 Method 1 – Using TLS-PSK

[0311] API callers and API open functions should follow the procedures outlined in this clause to establish private, secure sessions using a pre-shared key (PSK)-based TLS connection. CAPIF-1e authentication should be used to bootstrap the generation of the pre-shared key for CAPIF-2e TLS connections. It is assumed that both the API caller and the CAPIF core function are pre-configured with certificates. The TLS configuration file specified in Appendix E of TS33.310 [2] should be used.

[0312] Figure 6 Section 5.2.1-1 details the message flow between the API caller, the CAPIF core functionality, and the API open functionality to establish a secure CAPIF-2e interface using pre-shared keys for authentication.

[0313] Figure 6 5.2.1-1: Using TLS-PSK for CAPIF-2e interface authentication and protection (see...) Figure 20C )

[0314] 1. Establish a CAPIF-1e authentication and security session in accordance with the provisions of subclause 6.3.1 of this document. The CAPIF core functionality should provide the key AEF. PSK The validity timer value.

[0315] 2. After successfully establishing TLS on CAPIF-1e, the API caller and the CAPIF core functionality should export the key AEF. PSK .

[0316] Key AEF PSK It should be bound to AEF and exported as specified in Appendix A. API caller and CAPIF core functionality startup key AEF PSK The validity timer.

[0317] 3. The API caller should send an authentication initiation request to AEF, which includes the API caller ID assigned by the CAPIF core functionality.

[0318] If the API caller already has a valid AEF key PSK If so, steps 1 and 2 of this process can be skipped. In this case, the API caller begins the process from step 3.

[0319] Note: No space provided.

[0320] 4. If the AEF does not have a valid key, the AEF should request security information from the CAPIF core functionality to perform authentication and establish a secure interface with the API caller. The CAPIF core functionality provides the AEF with security information related to the selected security method (TLS-PSK: AEF) through the CAPIF-3 reference point. PSK The CAPIF core functionality should provide the key AEF. PSK The remaining validity timer value. If the CCF serving the API caller is different from the CCF serving the AEF, the procedure specified in Clause 8.25.3.x4 of TS 23.222 should be followed.

[0321] 5. Obtaining relevant security information for authentication (AEF) PSK Following this, AEF should send an authentication initiation response message to the API caller to initiate TLS session establishment. AEF starts a validity timer based on the value received from the CAPIF core functionality in step 4.

[0322] 6. API callers and AEF should use a key-based AEF. PSK Perform mutual authentication and establish a TLS session on CAPIF-2e.

[0323] After a successful TLS establishment on the CAPIF-2e reference point, the API open function should authorize the API caller's service API call request based on the authorization information obtained from the CAPIF core function, as specified in subclause 8.16 of TS 23.222 [3].

[0324] ******* Next change*******

[0325] 6.5.2.2 Method 2 – Using PKI

[0326] API callers and API open functions should follow the procedures outlined in this sub-clause to establish a dedicated secure session on CAPIF-2e using certificate-based mutual authentication TLS. It is assumed that both the API caller and the API open function have certificates pre-configured.

[0327] Figure 6 Section 5.2.2-1 details the message flow between the API caller, the CAPIF core functionality, and the API open functionality related to this security method.

[0328] Figure 6 5.2.2-1: Using certificate-based mutual authentication for CAPIF-2e interface authentication and protection (see...) Figure 20D )

[0329] 1. The API caller should send an authentication initiation request to AEF, which includes the API caller ID.

[0330] 2. The AEF shall request security information from the CAPIF core functionality to perform authentication and establish a secure interface with the API caller. The CAPIF core functionality provides the AEF with security information related to the selected security method (TLS-PKI) through the CAPIF-3 reference point. The CAPIF core functionality may return the root CA certificate of the API caller so that the AEF can verify the API caller's certificate. If the CCF serving the API caller is different from the CCF serving the AEF, the process specified in Clause 8.25.3.x4 of TS 23.222 shall be followed.

[0331] 3. After obtaining the relevant security information for authentication, AEF should send an authentication initiation response message to the API caller to initiate the TLS session establishment process.

[0332] 4. Then, the API caller and AEF should perform mutual authentication using the certificate and establish a TLS session on CAPIF-2e. Certificate-based authentication should follow the configuration files given in Clauses 6.1.3a and 6.1.4a of 3GPP TS 33.310 [2]. The PKI structure used for the certificate is not within the scope of this document.

[0333] After a successful TLS establishment on the CAPIF-2e reference point, the API open function should authorize the API caller's service API call request based on the authorization information obtained from the CAPIF core function, as specified in subclause 8.16 of TS 23.222 [3].

[0334] ******* Next change*******

[0335] 6.5.2.3 Method 3 – TLS with OAuth Token

[0336] This method describes in detail how to establish a secure channel at the CAPIF-1e and CAPIF-2e reference points and use a mechanism based on OAuth 2.0 [4] tokens to authorize and execute northbound API calls initiated by the API Open function in the direction of API calls. Figure 6 Section 5.2.3-1 details the secure information flow between the API caller, the CAPIF core functionality, and the API Open Functionality. It is assumed that the API caller, the CAPIF core functionality, and the AEF are all pre-configured with appropriate credentials and relevant information to establish a secure session.

[0337] According to OAuth 2.0 [4], the CAPIF core functionality should perform the functions of the authorization server and provide the token endpoint, the API caller should perform the functions of the client, and the API open functionality should perform the functions of the resource server. The API caller client (client endpoint) should be registered as a confidential client type with an authorization license type of "client credentials". Authorization should be pre-arranged in the CAPIF core functionality. The access token should follow the configuration file described in Appendix C.

[0338] Note: How to pre-arrange (pre-configure) authorization in the core functionality of CAPIF is not covered in this document.

[0339] Figure 6 5.2.3-1: Using access tokens for CAPIF-2e interface authentication and protection (see...) Figure 20E )

[0340] 1. CAPIF-1e authentication and secure session establishment shall be performed in accordance with the provisions of Subclause 6.3.1.

[0341] 2. After a TLS session is successfully established on CAPIF-1e as described in subclause 6.3.1 of this document, the API caller shall send an access token request message to the CAPIF core functionality in accordance with the OAuth 2.0 [4] specification.

[0342] 3. The core function of CAPIF should verify the access token request message in accordance with the OAuth 2.0 [4] specification.

[0343] 4. If the CAPIF core functionality successfully validates the access token request message, the CAPIF core functionality should generate an access token specific to the API caller and return the access token in the access token response message.

[0344] If the API caller already has a valid OAuth access token, steps 1 through 4 of this process can be skipped. In this case, the API caller begins the process from step 5.

[0345] Note 1: API callers can include the API caller ID and Onboard_Secret assigned by the CAPIF core functionality in the OAuth access token request message so that the CAPIF core functionality can verify the access token request.

[0346] Note 2: Void.

[0347] If the CCF serving the API caller is different from the CCF serving the AEF, and the CCF serving the API caller does not have sufficient authorization information, the CCF serving the API caller can request an access token from the CCF serving the AEF, or the CCF serving the API caller can request authorization information from the CCF serving the AEF and then use that authorization information to issue an access token. In the request, the CCF serving the API caller can also send information about the API caller so that the CCF serving the AEF can perform authorization.

[0348] 5. On CAPIF-2e, the API caller authenticates with the AEF by establishing a TLS session with the API open functionality using the authentication and authorization methods indicated by the CAPIF core functionality (i.e., server-side (AEF) certificate authentication or certificate-based mutual authentication). The following procedures should be performed before establishing a TLS session.

[0349] The API caller should send an authentication initiation request to AEF, which includes the API caller ID.

[0350] The AEF should request security information from the CAPIF core functionality to perform authentication and secure interface establishment with the API caller. The CAPIF core functionality provides the AEF with security information related to the selected security method (TLS with an OAuth token) via a CAPIF-3 reference point. The CAPIF core functionality may return the root CA certificate of the API caller so that the AEF can verify the API caller's certificate. If the CCF serving the API caller is different from the CCF serving the AEF, the process specified in Clause 8.25.3.x4 of TS 23.222 should be followed.

[0351] After obtaining the relevant security information for authentication, AEF should send an authentication initiation response message to the API caller to initiate the TLS session establishment process.

[0352] 6. After successfully authenticating with AEF on CAPIF-2e, the API caller should initiate a call to the AEF's 3GPP Northbound API. The access token received from the CAPIF core should be sent along with the Northbound API call request in accordance with OAuth 2.0 [4].

[0353] 7. API opening functionality should verify access tokens. AEF verifies the integrity of access tokens by verifying the CAPIF core functionality signature. If the access token verification is successful, AEF should verify the API caller's northbound API call request against the authorization statement in the access token to ensure that the API caller has access rights to the requested service API. If the token is signed by the CCF serving the API caller, and AEF does not know the root certificate of the CCF serving the API caller, then AEF should obtain the root certificate of the CCF serving the API caller from the CCF serving AEF.

[0354] 8. After successfully verifying the access token and the API caller's authorization statement, the requested northbound API should be invoked, and an appropriate response should be returned to the API caller.

[0355] ******* Next change*******

[0356] 6.8 Security process for API caller de-stationing

[0357] Prerequisites:

[0358] 1. The API caller has successfully registered.

[0359] Figure 6 .8-1: The secure process for API caller deportation (see Figure 20F )

[0360] 0. A TLS session was successfully established between the CAPIF core functionality and the API caller.

[0361] 1. An event occurs within the API caller to trigger the exit action.

[0362] Note: The rules regarding events that trigger exit are not covered in this document.

[0363] 2. The API caller should send an API caller deregistration request message to the CAPIF core functionality. This message includes the CAPIF core functionality-specific API caller ID assigned by the CAPIF core functionality during the onboarding process.

[0364] 3. The CAPIF core functionality should verify the API caller ID received in step 2 and check if the API caller has a corresponding configuration file. After successfully verifying the API caller ID and its configuration file, the CAPIF core functionality should deregister the API caller and delete its configuration file. This includes deleting the API caller certificate, service API authentication and authorization information, and the onboarding key (if applicable). Depending on the operator's policy, the CAPIF core functionality may retain information about deregistered API callers.

[0365] 4. The core function of CAPIF is to send a logout response message to the API caller, which indicates that the API caller has successfully logged out.

[0366] 5. API callers should remove information such as API caller ID, service API authentication / authorization information, API caller certificate, and Onboard_Secret (if applicable).

[0367] 6. The core functionality of CAPIF should dismantle the TLS session with the API caller.

[0368] 7. The CAPIF core functionality should send an event notification message to the API Open functionality to indicate that the API caller is no longer valid. In the case of CAPIF interoperability, the CAPIF core functionality serving the API caller sends this notification message to the CAPIF core functionality serving the API Open functionality. The CAPIF core functionality serving the API Open functionality should remove the security-related information associated with the API caller and send an event notification message to the API Open functionality.

[0369] 8. API opening functionality should remove security-related information associated with the API caller, such as AEF, based on the methods previously used to authenticate the API caller. PSK(as described in subclause 6.5.2.1 TLS-PSK method), root certificate for verifying API caller certificate (as described in subclause 6.5.2.2 PKI method), and access token (as described in subclause 6.5.2.3 OAuth 2.0 method).

[0370] 9. API open functionality should remove the TLS connection with the API caller.

[0371] 10. The API Open feature should return an event notification response message indicating that the security-related information associated with the API caller has been successfully removed, and therefore the API caller is no longer an authorized user. In the case of CAPIF interoperability, this confirmation message is sent through the CAPIF core function serving the API Open feature to the CAPIF core function serving the API caller.

[0372] ******* Next change*******

[0373] 6.X CAPIF-6 / 6e reference point safety procedures

[0374] To ensure the security of the interfaces between CAPIF core functions (i.e., CAPIF-6 / 6e):

[0375] - Unless otherwise specified, 3GPP TS 33.210

[10] shall be applied to secure messages at reference points; and

[0376] - Unless otherwise specified in this document, 3GPP TS 33.310 [2] may be applied to situations where certificates are used in conjunction with the security mechanisms of 3GPP TS 33.210 [X].

[0377] IPsec tunnels can be terminated using the SEG specified in 3GPP TS 33.210

[10] within the trusted domain.

[0378] ******* Change complete*******.

Claims

1. A method (300) in a first network function NF, comprising: Send (310) authorization delegation information to the second NF, the authorization delegation information enabling the second NF to authorize service API access to the application programming interface API caller.

2. The method (300) according to claim 1, wherein, The authorization delegation information includes the information required by the second NF to authorize access to the service API.

3. The method (300) according to claim 1 or 2, wherein, The authorization delegation information is sent in the interconnect API publishing request or in response to a request from the second NF.

4. The method (300) according to any one of claims 1 to 3, further comprising: Send a request to the second NF to revoke the authorization of the API caller.

5. The method (300) according to any one of claims 1 to 4, wherein, The first NF serves the API Exposure Function (AEF), and the second NF serves the API caller.

6. The method (300) according to any one of claims 1 to 5, wherein, The first NF and the second NF are each the core functional CCF of the general API framework CAPIF.

7. A method (400) in a second network function NF, comprising: The second NF receives (410) authorization delegation information from the first NF, which enables the second NF to authorize service API access to the application programming interface (API) caller.

8. The method (400) according to claim 7, further comprising: Receive an authorization request to access the service API from the API caller; as well as Send an authorization response containing authorization information to the API caller, the authorization information being used by the API caller to access the service API.

9. The method (400) according to claim 7 or 8, further comprising: Receive a request from the first NF to revoke authorization to the API caller; as well as In response to the request, the authorization to the API caller is revoked.

10. A method (500) in a first network function NF, comprising: Receive (510) a request from the second NF to authorize the API caller to access the service API; as well as Send an authorization response (520) containing authorization information to the second NF, the authorization information being used by the API caller to access the service API.

11. The method (500) according to claim 10, wherein, The authorization request contains information about the API caller.

12. The method (500) according to claim 10 or 11, further comprising: Send a notification to the second NF instructing the revocation of authorization for the API caller.

13. The method (500) according to any one of claims 10 to 12, wherein, The first NF serves the API Exposure Function (AEF), and the second NF serves the API caller.

14. The method (500) according to any one of claims 10 to 13, wherein, The first NF and the second NF are each the core functional CCF of the general API framework CAPIF.

15. A method (600) in a second network function NF, comprising: Send a (610) request to the first NF to authorize the API caller to access the service API; as well as Receive (620) an authorization response containing authorization information from the first NF, the authorization information being used by the API caller to access the service API.

16. The method (600) according to claim 15, further comprising: Send the authorization information to the API caller.

17. The method (600) according to claim 15 or 16, further comprising: Receive a notification from the first NF indicating the revocation of authorization for the API caller; as well as Send a notification to the API caller instructing the revocation of authorization for the API caller.

18. A method (800) in a first network function NF, comprising: Receive (810) from the second NF information about access control policies or security information for authentication and / or authorization associated with the API caller.

19. The method (800) according to claim 18, further comprising: Send a request for the access control policy or the security information to the second NF.

20. The method (800) according to claim 19, further comprising: Receive requests for the access control policy or the security information from the API Open Function (AEF); as well as Send information about the access control policy or the security information to the AEF.

21. The method (800) according to any one of claims 18 to 20, wherein, Information about the access control policy or the security information is received as a response to a request to proceed to the second NF.

22. The method (800) according to any one of claims 18 to 21, wherein, The security information includes one or more of the following: a key, the root certificate of the API caller, the root certificate of the second NF, or the certificate of the second NF.

23. The method (800) according to any one of claims 18 to 22, wherein, The first NF serves the API Exposure Function (AEF), and the second NF serves the API caller.

24. The method (800) according to any one of claims 18 to 24, wherein, The first NF and the second NF are each the core functional CCF of the general API framework CAPIF.

25. A method (900) in a second network function NF, comprising: Send (910) to the first NF information about access control policies or security information for authentication and / or authorization associated with the API caller.

26. The method (900) according to claim 25, further comprising: Receive a request for the access control policy or the security information from the first NF.

27. A method (1100) in a first network function NF, comprising: Receive (1110) a request from the second NF for information on the Application Programming Interface (API) Exposure Functionality (AEF) capabilities; as well as Send the capability information (1120) to the second NF.

28. The method (1100) according to claim 27, wherein, The capability information includes the security methods supported by the AEF.

29. The method (1100) according to claim 27 or 28, wherein, The first NF serves the AEF, and the second NF serves the API caller.

30. The method (1100) according to any one of claims 27 to 29, wherein, The first NF and the second NF are each the core functional CCF of the general API framework CAPIF.

31. A method (1200) in a second network function NF, comprising: Send a request (1210) to the first NF for information on the ability of the Application Programming Interface (API) to expose the Functionality of the Application (AEF); as well as Receive the capability information (1220) from the first NF.

32. A method (1300) in a first network function NF, comprising: Receive a notification from the second NF that the API caller is no longer valid (1310); as well as Send a (1320) notification message to the API Open Function (AEF) indicating that the API caller is no longer valid.

33. The method (1300) according to claim 32, further comprising: Receive a notification response message from the AEF, the notification response message indicating that security-related information associated with the API caller has been removed; as well as The notification response message is forwarded to the second NF.

34. The method (1300) according to claim 32 or 33, wherein, The first NF serves the AEF, and the second NF serves the API caller.

35. The method (1300) according to any one of claims 32 to 34, wherein, The first NF and the second NF are each the core functional CCF of the general API framework CAPIF.

36. A method (1400) in a second network function NF, comprising: Send a (1410) notification to the first NF that the API caller is no longer valid; as well as A notification response message (1420) is received from the first NF, indicating that security-related information associated with the API caller has been removed.

37. A network node (1500) comprising a communication interface (1510), a processor (1520), and a memory (1530), the memory (1530) including instructions executable by the processor (1520) such that the network node (1500) is configured to: perform the method according to any one of claims 1 to 6, 10 to 14, 18 to 24, 27 to 30, or 32 to 35 when implementing a first network function NF, or perform the method according to any one of claims 7 to 9, 15 to 17, 25 to 26, 31, or 36 when implementing a second NF.

38. A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor of a network node, configure the network node to: perform the method according to any one of claims 1 to 6, 10 to 14, 18 to 24, 27 to 30, or 32 to 35 when implementing a first network function NF, or perform the method according to any one of claims 7 to 9, 15 to 17, 25 to 26, 31, or 36 when implementing a second NF.

Images