Network slice based northbound service API exposure

Abstract

Systems and methods are disclosed that are related to network slice based northbound service Application Programming Interface (API) exposure for a cellular communications system. In one embodiment, a method performed by a core function of a common API framework for northbound APIs in a cellular communications system 5 comprises receiving, from an API publishing function associated to an API provider, a request to publish a service API, the request comprising network slice information for the service API. With such network slice based API exposure, the network operator can provide more relevant and controlled API to 3rd party, e.g., to enable more business use cases around network slices.

Description

NETWORK SLICE BASED NORTHBOUND SERVICE API EXPOSURERelated Applications

[0001] This application claims the benefit of international patent application serial number PCT / CN2023 / 113031, filed August 15, 2023, the disclosure of which is hereby incorporated herein by reference in its entirety.Technical Field

[0002] The present disclosure relates to a cellular communications system and, more specifically, to Application Programming Interface (API) exposure in a cellular communications system.Background

[0003] In 3rdGeneration Partnership Project (3GPP) Technical Specification (TS) 23.222 (see, e.g., V18.2.0) Common Application Programming Interface (API) Framework (CAPIF) for 3GPP northbound APIs is introduced. Within the standardization of CAPIF, 3GPP has addressed a variety of different processes, including onboarding / offboarding of Application Functions, service discovery and management, event subscription and notification, security, and charging.

[0004] The current specification API provider can publish their API with attributes such as API provider name, List of public Internet Protocol (IP) ranges of User Equipments (UEs), Serving Area Information, etc. An API invoker can then perform discovery based on these published attributes to discover desired APIs.Summary

[0005] Systems and methods are disclosed that related to network slice based northbound service Application Programming Interface (API) exposure for a cellular communications system. In one embodiment, a method performed by a core function of a common API framework for northbound APIs in a cellular communications system comprises receiving, from an API publishing function associated to an API provider, a request to publish a service API, the request comprising network slice information for the service API. With such network slice based API exposure, the network operator canprovide more relevant and controlled API to 3rdparty, e.g., to enable more business use cases around network slices.

[0006] In one embodiment, the method further comprises performing one or more actions based on the request to publish the service API. In one embodiment, the one or more actions comprise storing information about the service API including the network slice information for the service API.

[0007] In one embodiment, the network slice information for the service API comprises information that identifies one or more network slices for which the service API is requested to be published. In one embodiment, the network slice information for the service API comprises information that identifies one or more network slices for which the service API is to be discoverable. In one embodiment, the information that identifies the one or more network slices comprises one or more S-NSSAIs.

[0008] In one embodiment, the method further comprises receiving, from an API invoker, a service API discovery request comprising network slice information and sending, to the API invoker, a service API discovery response comprising information about one or more service APIs that satisfy the discovery request. In one embodiment, the service API and the network slice information for the service API satisfy the discovery request, and the service API discovery response comprises information about the service API. In one embodiment, the network slice information for the service API comprises information that identifies one or more network slices for the service API, the network slice information comprised in the service API discovery request comprises information that identifies one or more network slices for the service API discovery request, and at least one of the one or more network slices for the service API included in the one or more network slices for the service API discovery request.

[0009] In one embodiment, the method further comprises receiving, from the API invoker, a request for authorization to access the service API, the request for authorization comprising network slice information that identifies one or network slices for which authorization to access the service API is requested (e.g., one or more network slices of the API invoker) and sending, to the API invoker, an authorization response that indicates whether the API invoker is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested. In one embodiment, the method further comprises, responsive to receiving the request for authorization to access the service API, determining whether the APIinvoker is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested. In one embodiment, the network slice information for the service API comprises information that identifies one or more network slices for the service API, the network slice information comprised in the request for authorization to access the service API comprises information that identifies one or more network slices for the authorization to access the service API is requested, and determining whether the API invoker is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested comprises determining whether the one or more network slices for which authorization to access the service API is requested are included in the one or more network slices for the service API. In one embodiment, the authorization response comprises authorization information for enabling the API invoker to access the service API.

[0010] In one embodiment, the method further comprises receiving, from an API invoker, a request for authorization to access the service API, the request for authorization comprising network slice information that identifies one or network slices for which authorization to access the service API is requested (e.g., one or more network slices of the API invoker) and sending, to the API invoker, an authorization response that indicates whether the API invoker is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested. In one embodiment, the method further comprises, responsive to receiving the request for authorization to access the service API, determining whether the API invoker is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested. In one embodiment, the network slice information for the service API comprises information that identifies one or more network slices for the service API, the network slice information comprised in the request for authorization to access the service API comprises information that identifies one or more network slices for the authorization to access the service API is requested, and determining whether the API invoker is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested comprises determining whether the one or more network slices for which authorization to access the service API is requested are included in the one or more network slices for the service API. In one embodiment, the authorization responsecomprises authorization information for enabling the API invoker to access the service API.

[0011] In one embodiment, the method further comprises generating service API access information with network slice information. In one embodiment, the service API access information comprises information related to charging, logging, and / or auditing functions.

[0012] In one embodiment, the method further comprises receiving an onboarding request from an API invoker, the onboarding request comprising network slice information for the API invoker, and performing one or more actions related to onboarding the API invoker responsive to the onboarding request. In one embodiment, the one or more actions related to onboarding the API invoker comprise creating an access control policy for the API invoker taking into consideration the network slice information of the API invoker.

[0013] Corresponding embodiments of a core function of a common API framework for northbound APIs in a cellular communications system are also disclosed.

[0014] Corresponding embodiments of a network node for implementing a core function of a common API framework for northbound APIs in a cellular communications system are also disclosed.

[0015] Embodiments of a method performed by an API publishing function in a common API framework for northbound APIs in a cellular communications system are also disclosed. In one embodiment, a method performed by an API publishing function in a common API framework for northbound APIs in a cellular communications system comprises sending, to a core function of the common API framework, a request to publish a service API, the request comprising network slice information for the service API.

[0016] In one embodiment, the network slice information for the service API comprises information that identifies one or more network slices for which the service API is requested to be published. In one embodiment, the network slice information for the service API comprises information that identifies one or more network slices for which the service API is to be discoverable. In one embodiment, the information that identifies the one or more network slices comprises one or more S-NSSAIs.

[0017] Corresponding embodiments of an API publishing function in a common API framework for northbound APIs in a cellular communications system are also disclosed.

[0018] Corresponding embodiments of a network node for implementing an API publishing function in a common API framework for northbound APIs in a cellular communications system are also disclosed.

[0019] Embodiments of a method performed by an API invoker for a common API framework for northbound APIs in a cellular communications system are also disclosed. In one embodiment, a method performed by an API invoker for a common API framework for northbound APIs in a cellular communications system comprises sending, to a core function of the common API framework, a service API discovery request comprising network slice information and receiving, from the core function, a service API discovery response comprising information about one or more service APIs that satisfy the discovery request.

[0020] In one embodiment, the network slice information comprised in the service API discovery request comprises information that identifies one or more network slices for the service API discovery request, and at least one of one or more network slices for each of the one or more service APIs that satisfy the service API discovery request is included in the one or more network slices for the service API discovery request.

[0021] In one embodiment, the method further comprises sending, to the core function, a request for authorization to access a service API indicated the information comprised in the service API discovery response, the request for authorization comprising network slice information that identifies one or network slices for which authorization to access the service API is requested (e.g., one or more network slices of the API invoker, and receiving, from the core function, an authorization response that indicates whether the API invoker is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested. In one embodiment, the authorization response comprises authorization information for enabling the API invoker to access the service API.

[0022] In one embodiment, the method further comprises sending an onboarding request to the core function, the onboarding request comprising network slice information for the API invoker, and receiving an onboarding response from the core function.

[0023] Corresponding embodiments of an API invoker for a common API framework for northbound APIs in a cellular communications system are also disclosed.

[0024] Corresponding embodiments of a network node for implementing an API invoker for a common API framework for northbound APIs in a cellular communications system are also disclosed.Brief Description of the Drawings

[0025] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0026] Figure 1 illustrates one example of a cellular communications system in which embodiments of the present disclosure may be implemented;

[0027] Figure 2 illustrates a wireless communication system represented as a Fifth Generation (5G) network architecture composed of core Network Functions (NFs);

[0028] Figure 3 illustrates a 5G network architecture using service-based interfaces between the NFs in the Control Plane (CP);

[0029] Figure 4 illustrates an example functional model for the Common Application Programming Interface (API) Framework (CAPIF) embodiments disclosed herein;

[0030] Figure 5 illustrates a functional architecture for CAPIF interconnection with multiple CAPIF provider domains;

[0031] Figure 6 illustrates a procedure in accordance with embodiments of the present disclosure;

[0032] Figure 7 illustrates the onboarding process for the API invoker in more detail, in accordance with an embodiment of the present disclosure;

[0033] Figure 8 illustrates the authorization process for the API invoker in more detail, in accordance with an embodiment of the present disclosure;

[0034] Figure 9 illustrates a procedure related to usage of access control policy enhanced with network slice information, in accordance with one embodiment of the present disclosure;

[0035] Figure 10 is a schematic block diagram of a network node according to some embodiments of the present disclosure;

[0036] Figure 11 is a schematic block diagram that illustrates a virtualized embodiment of the network node according to some embodiments of the present disclosure; and

[0037] Figure 12 is a schematic block diagram of the network node according to some other embodiments of the present disclosure.Detailed Description

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

[0039] Radio Node: As used herein, a "radio node" is either a radio access node or a wireless communication device.

[0040] Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

[0041] Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network ExposureFunction (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0042] Communication Device: As used herein, a "communication device" is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehiclemounted mobile device, enabled to communicate voice and / or data via a wireless or wireline connection.

[0043] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and / or data via a wireless connection.

[0044] Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network / system.

[0045] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0046] Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0047] There currently exist certain challenge(s). In 5G with the increased need of network slices for enterprise, there is a need for customized network slices provided by the network operator. In this case, it is crucial to provide the correct service Application Programming Interface (API) to an API invoker based on the network slices. For example, Service API X could be applicable for an enhanced Mobile Broadband (eMBB) slice A but would not be applicable to a Gaming slice B for API invoker Y, and such service API publication, discovery, and API invoker authorization based on network slices is not provided in current 3GPP northbound APIs. 3GPP TS 23.222 defines a "northbound API" as "[a] service API exposed to higher-layer API invokers," defines an "API invoker" as "[the] entity which invokes the Common API Framework (CAPIF) or service APIs," and defines "Service API" as "[the] interface through which a component of the system exposes its services to API invokers by abstracting the services from the underlying mechanisms."

[0048] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Systems and methods are disclosed herein that provide an end-to-end flow for network slice based Service API publication, Service API discovery, and API invoker authorization. Systems and methods are also disclosed herein that provide support for network slice based API access control, logging and charging support in CAPIF.

[0049] Embodiments are disclosed herein that are based on the current 3GPP TS 23.222 (V18.2.0); however, the embodiments disclosed herein are not limited thereto. Embodiments disclosed herein introduce a network slice information element (IE) in the Service API publication procedure and the Service API discovery procedure, and enhance the CAPIF core function to enable an API invoker to retrieve authorization of service API access.

[0050] Certain embodiments may provide one or more of the following technical advantage(s). With the network slice based API exposure, telecommunication operators can provide more relevant and controlled API to 3rdparty to enable more business use cases around network slices.

[0051] Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 100 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC); however, theembodiments described herein are not limited to 5G and may be utilized in any similar system (e.g., 6G). In this example, the RAN includes base stations 102-1 and 102-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs), controlling corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. Likewise, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cell 104. The RAN may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106. Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108. The cellular communications system 100 also includes a core network 110, which in the 5G System (5GS) is referred to as the 5GC. The base stations 102 (and optionally the low power nodes 106) are connected to the core network 110.

[0052] The base stations 102 and the low power nodes 106 provide service to wireless communication devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication device 112. In the following description, the wireless communication devices 112 are oftentimes UEs, but the present disclosure is not limited thereto.

[0053] Figure 2 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 2 can be viewed as one particular implementation of the system 100 of Figure 1.

[0054] Seen from the access side the 5G network architecture shown in Figure 2 comprises a plurality of UEs 112 connected to either a RAN 102 or an Access Network (AN) as well as an AMF 200. Typically, the R(AN) 102 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shownin Figure 2 include a NSSF 202, an AUSF 204, a UDM 206, the AMF 200, a SMF 208, a PCF 210, and an Application Function (AF) 212.

[0055] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 112 and AMF 200. The reference points for connecting between the AN 102 and AMF 200 and between the AN 102 and UPF 214 are defined as N2 and N3, respectively. There is a reference point, Nil, between the AMF 200 and SMF 208, which implies that the SMF 208 is at least partly controlled by the AMF 200. N4 is used by the SMF 208 and UPF 214 so that the UPF 214 can be set using the control signal generated by the SMF 208, and the UPF 214 can report its state to the SMF 208. N9 is the reference point for the connection between different UPFs 214, and N14 is the reference point connecting between different AMFs 200, respectively. N15 and N7 are defined since the PCF 210 applies policy to the AMF 200 and SMF 208, respectively. N12 is required for the AMF 200 to perform authentication of the UE 112. N8 and N10 are defined because the subscription data of the UE 112 is required for the AMF 200 and SMF 208.

[0056] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 2, the UPF 214 is in the UP and all other NFs, i.e., the AMF 200, SMF 208, PCF 210, AF 212, NSSF 202, AUSF 204, and UDM 206, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0057] The core 5G network architecture is composed of modularized functions. For example, the AMF 200 and SMF 208 are independent functions in the CP. Separated AMF 200 and SMF 208 allow independent evolution and scaling. Other CP functions like the PCF 210 and AUSF 204 can be separated as shown in Figure 2. Modularized function design enables the 5GC network to support various services flexibly.

[0058] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enablessupport for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0059] Figure 3 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 2. However, the NFs described above with reference to Figure 2 correspond to the NFs shown in Figure 3. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 3 the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g. Namf for the service based interface of the AMF 200 and Nsmf for the service based interface of the SMF 208, etc. The NEF 300 and the NRF 302 in Figure 3 are not shown in Figure 2 discussed above. However, it should be clarified that all NFs depicted in Figure 2 can interact with the NEF 300 and the NRF 302 of Figure 3 as necessary, though not explicitly indicated in Figure 2.

[0060] Some properties of the NFs shown in Figures 2 and 3 may be described in the following manner. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. A UE 112 even using multiple access technologies is basically connected to a single AMF 200 because the AMF 200 is independent of the access technologies. The SMF 208 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 214 for data transfer. If a UE 112 has multiple sessions, different SMFs 208 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 212 provides information on the packet flow to the PCF 210 responsible for policy control in order to support QoS. Based on the information, the PCF 210 determines policies about mobility and session management to make the AMF 200 and SMF 208 operate properly. The AUSF 204 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 206 stores subscription data of the UE 112. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

[0061] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0062] Figure 4 illustrates a functional model for the CAPIF embodiments disclosed herein. Figure 4 is a reproduction of Figure 6.2.1-1 of 3GPP TS 23.222, and is described in the following excerpt from 3GPP TS 23.222:***** START EXCERPT FROM 3GPP TS 23.222 *****The CAPIF core function in the PLMN trust domain supports service APIs from both the PLMN trust domain and the 3rdparty trust domain having business relationship with PLMN. The API invokers may exist within the PLMN trust domain, or within the 3rdparty trust domain or outside of both the PLMN trust domain and the 3rdparty trust domain. The API provider domain 1 offers the service APIs from the PLMN operator. The API provider domain 2 offers the service APIs from the 3rdparty. When the 3rdparty API provider is a trusted 3rdparty of the PLMN, the API provider domain 1 also offers the service APIs from the 3rdparty.The API invoker 2 within the PLMN trust domain interacts with the CAPIF core function via CAPIF- 1, and invokes the service APIs in the PLMN trust domain via CAPIF-2 and invokes the service APIs in the 3rdparty trust domain via CAPIF-2e. The API invoker 3 within the 3rdparty trust domain interacts with the CAPIF core function via CAPIF- le, and invokes the service APIs in the PLMN trust domain via CAPIF-2e and invokes the service APIs in 1(1party trust domain via CAPIF-2. The API invoker 1 from outside the PLMN trust domain and 3rdparty trust domain, interacts with the CAPIF core function via CAPIF-le and invokes the service APIs in the PLMN trust domain and the service APIs in the 3rdparty trust domain via CAPIF-2e.The API exposing function, the API publishing function and the API management function of the API provider domain 1 within the PLMN trust domain interacts with the CAPIF core function via CAPIF-3, CAPIF-4 and CAPIF- 5 respectively. The API exposing function, the API publishing function and the API management function of the API provider domain 2 within the 3rdparty trust domain interacts with the CAPIF core function in the PLMN trust domain via CAPIF-3e, CAPIF-4e and CAPIF-5e respectively. The API exposing function within the PLMN trust domain and the 3rdparty trust domain provides the service APIs to the API invoker, offered by the respective trust domains.The interactions between the API exposing functions within the PLMN trust domain is via CAPIF-7 (not shown in the figure 6.2.1-1 for simplicity). The API exposing function within the PLMN trust domain interacts with the API exposing function in the 3rdparty trust domain via CAPIF-7e.NOTE 1: The communication between the API exposing function and the CAPIF core function, between the API publishing function and the CAPIF core function and between the API management function and the CAPIF core function over CAPIF-3 / 3e, CAPIF-4 / 4e and CAPIF-5 / 5e respectively can be API based.The detailed information of the APIs provided by the CAPIF core function is specified in clause 10.NOTE 2: The security aspects of CAPIF reference points are under S A3 responsibility and out of scope of the present document.*****ENDEXCERPT FROM 3GPP TS 23.222 *****

[0063] Figure 5 illustrates a functional architecture for CAPIF interconnection with multiple CAPIF provider domains. Figure 5 is a reproduction of Figure 6.2.2-1 of 3GPPTS 23.222. The architectural model for CAPIF interconnection illustrated in Figure 5 allows API invokers of a CAPIF provider to utilize the service APIs from the 3rdpartyCAPIF provider. Note that provider A and B can be the same provider, then CAPIF interconnection is within the same domain and CAPIF-6e is replaced by CAPIF-6.Further details can be found in the following excerpt from 3GPP TS 23.222.***** START EXCERPT FROM 3GPP TS 23.222 *****The CAPIF provider A and CAPIF provider B host the CAPIF in their trust domains. A business relationship exists between the CAPIF providers.The CAPIF providers in their respective trust domain hosts multiple CAPIF instances where each CAPIF instance consists of the CAPIF core function (local), the API provider domain and the API invokers. All interactions within the CAPIF instance is according to the functional model specified in clause 6.2.0.When multiple CAPIF instances are deployed by a CAPIF provider there may be a hierarchy associated with the multiple CAPIF core function deployed which allows:- the designated CAPIF core function of the CAPIF provider A to interconnect with the designated CAPIF core function of the CAPIF provider B; and- within CAPIF provider A, one or more CAPIF core function interacts with the designated CAPIF core function 1.The designated CAPIF core function of the CAPIF provider A provides the information about the CAPIF instances and service APIs deployed by the CAPIF provider A to the designated CAPIF core function of the CAPIF provider B and vice versa over CAPIF-6e reference point.The CAPIF core function 2 of CAPIF provider A provides the information about the service APIs to the CAPIF core function 1 over CAPIF-6 reference point.NOTE 1: VoidThe API invokers may exist within the trust domain of CAPIF provider A, or within the trust domain of CAPIF provider B or outside of the trust domains of both CAPIF provider A and CAPIF provider B. The API invoker of a CAPIF provider is onboarded with the CAPIF core function in the corresponding trust domain of the CAPIF provider.NOTE 2: For sake of simplicity, the service API interactions of API invokers of the CAPIF provider B are not shown. From each CAPIF provider's perspective the other CAPIF provider is a 3rdparty.One or more CAPIF core function can publish service APIs to the designated CAPIF core function over CAPIF-6 reference point and, also discover the service APIs from the designated CAPIF core function and vice versa over CAPIF-6 reference point.The API invoker within the trust domain of CAPIF provider A interacts with the CAPIF core function of the CAPIF provider A via CAPIF- 1 and discovers the service APIs of both CAPIF providers, and invokes the service APIs in the trust domain of CAPIF provider A via CAPIF-2 and invokes the service APIs in the trust domain of CAPIF provider B via CAPIF-2e. The API invoker from outside the trust domain of CAPIF providers, interacts with the CAPIF core function of the CAPIF provider A via CAPIF- le and invokes the service APIs in the trust domain of the CAPIF providers via CAPIF-2e.NOTE 3: The communication between the CAPIF core function of the CAPIF providers over CAPIF-6 or CAPIF-6e can be API based.The detailed information of the APIs provided by the CAPIF core function is specified in clause 10.NOTE 4: The security aspects of CAPIF reference points are under S A3 responsibility and out of scope of the present document.NOTE 5: All interactions among entities within the CAPIF provider domains (regardless if CAPIF is deployed in a PLMN, SNPN or 3rd party network) are ruled by the functional model in clause 6.2.0, the support of 3rd party API providers is as in clause 6.2.1, whereas the interconnection among CCFs is according to this clause.*****ENDEXCERPT FROM 3GPP TS 23.222 *****

[0064] It should be noted that CAPIF is part of a service layer above the core network and meant to work with 4G core exposure or 5G core exposure functions (i.e., the SCEF for 4G, the NEF for 5G) or other exposure functions in future core networks. The CAPIF exposes to the Vertical Applications Layer (VAL) the requested services supported by the underlying core network. It can also be collocated with the core network exposure function, if for example, only one type of core network is deployed. While not necessary, for more details, the interested reader is directed to 3GPP TS 23.222 Annex B. There, details are given related to implementation of the CAPIF architecture in a 4G or 5G core network. For example, in one example implementation, the CAPIF core function, the API exposing function, API publication function, and API management function are all implemented in a core network exposure function (e.g., the SCEF for 4G or the NEF for 5G). In another example implementation, the API exposing function, the API publishing function, and the API management function are implemented in a core network exposure function (e.g., the SCEF in 4G or the NEF in 5G) and the CAPIF core function is deployed alongside the SCEF / NEF.

[0065] Embodiments of the present disclosure include any one or more of the following aspects:• CAPIF Core function is enhanced to: o Support API repository to store the supported network slices o Onboard API invoker and store allowed network slices for API invoker o Support API access policy for a given API invoker per network slice• CAPIF- 1 / CAPIF-le is enhanced to enable the API invoker to: o Perform Service API discovery based on network slices o Obtain authorization information to access service API• CAPIF-4 / CAPIF-4e is enhanced to support the API provider to: o Register / Publish service API with network slices information• CAPIF-3 / CAPIF-3e is enhanced to support the API provider to: o Obtain API access policy information for API invoker to perform operation on network slice(s)• CAPIF-5 / CAPIF-5e is enhanced to enable the API management function to: o Get service API access log information with network slices• CAPIF-6 / CAPIF-6e enables CAPIF core function inter-connection for API publish and discovery.

[0066] Now, a description of a number of procedures that enable network slicebased service API exposure via CAPIF in accordance with embodiments of the present disclosure will be described.

[0067] Figure 6 illustrates a procedure in accordance with embodiments of the present disclosure. Note that not all steps of the procedure are required. The procedure of Figure 6 involves an API invoker 600, a CAPIF core function 602, an API publishing function 604 in an API provider domain 606, and an API exposing function 608 that exposes a number of Service APIs 610 in the API provider domain 606. The procedure of Figure 6 includes the following steps:

[0068] Step 612: The API publishing function 604 in the API provider domain 606 sends an API publish request to the CAPIF core function 602, e.g., over the CAPIF-4 or CAPIF-4e reference point. For each of one or more Service APIs published by the API publish request, the API publish request includes Service API information such as, e.g., Service API name, API provider name (optional), list of public IP ranges of UEs (optional), Service API type, Service API status (e.g., active, inactive), communication type, description, Service Area Information (optional), AEF location (optional), interface details (e.g., IP address, port number, Uniform Resource Indicator (URI)), protocols, version numbers, data format, Service Key Performance Indicators (KPIs) (optional). In addition, the API publish request includes, for each Service API, network slice information for the Service API. The network slice information for the Service API includes, for example, information about a network slice(s) of the Service API, where this network slice information includes, for example, a list of network slice related identifiers (e.g., a list of S-NSSAIs).

[0069] Step 614: The API invoker 500 sends an onboarding request (referred to herein as an "onboard API invoker request") to the CAPIF function 602, e.g., over the CAPIF-1 or CAPIF-le reference point. As described below, the onboard API invoker request includes onboarding information related to the API invoker 600 such as, e.g., network slice information of the API invoker 600 (e.g., information about a network slice of the API invoker 600 such as, e.g., one or more network slice identifiers (e.g., one or more S-NSSAIs).

[0070] Step 616: The CAPIF core function 602 performs onboarding approval with network slice permission and policy configuration per network slice (e.g., TransactionsPer Second (TPS), quota, etc.). The CAPIF core function 602 onboards the API invoker 600 with Network Slice access selection and configuration of API access policy with network slice configuration.

[0071] Step 618: The CAPIF core function 602 sends an onboard API invoker response to the API invoker 600.

[0072] Step 620: The API invoker 600 is onboarded.

[0073] Step 622: The API invoker 600 sends, to the CAPIF core function 602, a Service API discovery request for one or more network slices.

[0074] Step 624: The CAPIF core function 602 returns, to the API invoker 600, a list of Service APIs for the requested network slices.

[0075] Step 626: The API invoker 600 sends, to the CAPIF function 602 (e.g., via CAPIF-1 or CAPIF-le reference point), an authorization request for a Service API for the network slice(s).

[0076] Step 628: The CAPIF core function 602 performs an authorization process and sends resulting authorization information to the API invoker 600.

[0077] Step 630: The CAPIF core function 602 accesses the Service API, via the API exposing function 608 in the API provider. Domain 606, using the authorization information.

[0078] Step 632: The CAPIF core function 632 (e.g., to support AEF to get API access policy) generates service API access information with network slice information, e.g., to support charging / audit / logging function. The API access information includes, for example, information related to charging, information related to logging, and / or information related to auditing. While not necessary, for further information, the interested reader is directed to Chapters 4.4, 4.7, and 4.8 of 3GPP TS 23.222.

[0079] Step 634: The API exposing function 608 obtains, from the CAPIF core function 602, the API access and control policy (e.g., TPS, quota, etc.) for the network slice. Note that the API access and control policy may be provided to the API service provider so that the API service provider can have control of API request (e.g., if API invoker exceeds the quota, then the API service provider could reject the API invocation).

[0080] Further details regarding various steps of the procedure of Figure 6 are provided below.Step 612 - Enhanced Service API Publish with Network Slice Info

[0081] As discussed above, the Service API publish request of step 612 includes network slice information. In this regard, Table 1 below describes one example embodiment of the information flow service API publish request from the API publishing function 604 to the CAPIF core function 602. As shown, network slice information (e.g., Single Network Slice Assistance Information(s) (S-NSSAI(s)) of the network slice(s) of a Service API) is included in the service API publish request in this example as optional parameter as part of service API information. Table 1: Service API Publish RequestSteps 614-620 - Enhanced API Invoker Onboarding and Policy Configuration with Network Slice Information

[0082] Figure 7 illustrates the onboarding process for the API invoker 600 in more detail, in accordance with an embodiment of the present disclosure. This process corresponds to steps 614 to 620 of Figure 6. The steps of the process of Figure 7 are as follows:• Step 700: For enrollment of the API invoker 600 to be a recognized user of the CAPIF, the API invoker 600 triggers an onboard API invoker request towards the CAPIF core function 602, providing the information as required for the API management. Table 2 below provides an example embodiment of the information contained in the onboard API invoker request.• Step 702: The CAPIF core function 602 begins the onboarding process by verifying whether all the necessary information has been provided to onboard the API invoker 600, and further initiates a grant process. Successful onboarding results in provisioning of an API invoker profile which includes an identity for the API invoker 600. The authorization information and the list of APIs and the types of APIs that the API invoker can access subsequent to successful onboarding may also be created. The CAPIF core function 602 may create access control policy fsee Table 3 below for the onboarded API invoker 600 considering the network slice information. o NOTE 1: Completion of onboarding process can require explicit grant by the CAPIF administrator or the API management, which is left out-of- scope of the present disclosure. CAPIF can handle the grant process internally without the need of explicit grant by the CAPIF administrator. o NOTE 2: The API invoker profile includes at least the identity information for the API invoker 600, information required for the authentication and authorization by the CAPIF core function 602, and the CAPIF identity information.• Step 704: If the API invoker 600 has triggered the onboard API invoker request and is granted permission, the onboard API invoker response provides success indication including information from the provisioned API invoker profile which may include information to allow the API invoker 600 to be authenticated and to obtain authorization for service APIs.• Step 706: As a result of successful onboarding process, the CAPIF core function 602 is able to authenticate and authorize the API invoker 600.

[0083] Based on current flow of API invoker onboarding, in step 702 (or step 618 of Figure 6) onboarding approval, the authorization information and the list of APIs and the types of APIs that the API invoker 600 can access subsequent to successful onboarding may also be created, the CAPIF core function 602 may create access control policy for the API invoker and if the requested API supports network slice info, CAPIF core function 602 may include network slice info as part of the access control policy information.

[0084] Note that, if service API publish happens after onboarding, the CAPIF core function 602, updates access control policy based on Network Slice Info of the published service API.

[0085] The CAPIF core function 602 may create access control policy per network slice for the API invoker 600 with update to 3GPP TS 23.222 table E-l, as shown in Table 3 below.Table 2: Onboard API invoker requestTable 3Step 622 - Enhanced Service API Discovery with Network Slice

[0086] Table 4 below describes an example embodiment of the information included in the service API discovery request sent from the API invoker 600 to the CAPIF core function 602 in step 622. As illustrated in Table 4, network slice information (e.g., S- NSSAI(s)) is included in the Service API discovery request as optional parameter as part of query information so that CAPIF core function 602 can filter the relevant Service APIs.Table 8.7.2.1-1: Service API discover requestSteps 624-626 - API Invoker Authorization based on Network Slice Info

[0087] Figure 8 illustrates the authorization process for the API invoker 600 in more detail, in accordance with an embodiment of the present disclosure. This process corresponds to steps 626 and 628 of Figure 6. The steps of the process of Figure 8 are as follows:• Step 800: The API invoker 600 sends an obtain service API authorization request to the CAPIF core function 602 for obtaining permission to access the service API by including the API invoker identity information and any information required for authentication of the API invoker 600. The request may include Network Slice Info of the API invoker 600 and the desired Network Slice Info of the service API.• Step 802: The CAPIF core function 602 validates the authentication of the API invoker 600 (using authentication information) and checks whether the API invoker 600 is permitted to access the requested service API. If Network Slice Info of the API invoker 600 and desired Network Slice Info of the service API are received, the CAPIF core function 602 checks if the API invoker 600 is permitted to invoke the service API. For instance, the CAPIF core function 602 mav check that the Network Slice Info (e.g., S-NSSAI) of the API invoker 600 is included in the allowed Network Slice info for the indicated service API (e.g., allowed S- NSSAI(s) from which the service API mav be invoked).Step 804: Based on the API invoker's subscription information, the authorization information (e.g., token) to access the service API is sent to the API invoker 600 in an obtain service API authorization response.Steps 632 and 634 - CAPIF Core Function Support for API Access and Generate Access Information with Network Slices

[0088] To facilitate the API provider domain 606 (e.g., the API exposure function 608) to serve the API invoker 600 to access the Service API with network slice information, the CAPIF core function 602 is enhanced to consider network slice information with following:• CAPIF core function 602 enabled to support AEF to retrieve API access control policy as defined in chapter 2.7.1.2 of 3GPP TS 23.222;• CAPIF enabled to support AEF to trigger charging request with network slice information;• CAPIF core function 602 enabled to support API management function to send back API request log information with network slices included.Procedure to illustrate usage of access control policy (enhanced with network slice info)

[0089] Figure 9 illustrates a procedure related to usage of access control policy enhanced with network slice information, in accordance with one embodiment of the present disclosure. The steps of the procedure are as follows:

[0090] Step 900: The API invoker performs service API invocation according to the interface of the service API by sending a service API invocation request towards the AEF which exposes the service API towards the API invoker. The AEF acts as an access control entity.

[0091] Step 902: If the access control policy is not configured with AEF, then the AEF may obtain the access control policy configuration from the CAPIF core function (e.g., as described in clause 8.12 of 3GPP TS 23.222). The access control policy may include network slice information.

[0092] Step 904: Upon receiving the service API invocation request from the API invoker, the AEF checks for configuration for access control. As per the configuration for access control, the AEF performs access control on the service API invocation request as per the operator policy.

[0093] Step 906: The API invoker receives a service API invocation response for service API invocation from the AEF providing the service API.Example Implementations as Changes to 3GPP Specifications

[0094] Example implementations of example embodiments of the present disclosure will now be shown as a number of changes to existing 3GPP specifications. Additions are shown by underlined text and deletions are shown by double brackets (i.e., [[...]]). Note that not all of the following changes are required. Any one or more of the following changes may be implemented.*****FIRSTCHANGE TO 3GPP TS 23.222 *****2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.- For a specific reference, subsequent revisions do not apply.- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".[2] 3GPP TS 23.682: "Architecture enhancements to facilitate communications with packet data networks and applications".[3] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".[4] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".[5] 3GPP TR 26.981: "MBMS Extensions for Provisioning and Content Ingestion".[6] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging architecture and principles".[7] ETSI GS MEC 011 (VI.1.1): "Mobile Edge Computing (MEC); Mobile Edge Platform Application Enablement".[8] ETSI GS MEC 009 (VI.1.1): "Mobile Edge Computing (MEC); General Principles for Mobile Edge Service APIs".[9] GMA-ER_Autho4API-Vl_0-20141209-A: "Authorization Framework for Network APIs".

[0010] OMA-TS-REST_NetAPI_Common-Vl_0-20180116-A: "Common definitions for RESTful Network APIs".

[0011] GMA-TS-NGSI_Registration_and_Discovery-Vl_0-20120529-A: "NGSI Registration and Discovery".

[0012] 3GPP TS 33.122: "Security Aspects of Common API Framework for 3GPP Northbound APIs".[TS234351 3GPP TS 23.435: " Procedures for Network Slice Capability Exposure for Application Layer Enablement Service".*****NEXTCHANGE TO 3GPP TS 23.222 *****3.1 DefinitionsFor the purposes of the present document, the terms and definitions given in 3 GPP TR 21.905 [1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905 [1].API: The means by which an API invoker can access the service.API invoker: The entity which invokes the CAPIF or service APIs.API invoker profile: The set of information associated to an API invoker that allows that API invoker to utilize CAPIF APIs and service APIs.API exposing function: The entity which provides the service communication entry point for the service APIs.API exposing function location: The location information (e.g. civic address, GPS coordinates, data center ID) where the API exposing function providing the service API is located.CAPIF administrator: An authorized user with special permissions for CAPIF operations.Common API framework: A framework comprising common API aspects that are required to support service APIs.Designated CAPIF core function: The CAPIF core function which is configured as the serving CAPIF core function for interconnection.Network Slice Info: Information of network slice (e.g. a list of network slice related identifiers, as described in clause 8.4 of 3GPP TS 23.435 1TS234351). It may include network slice info of service API and / or network slice info of API invoker.Northbound API: A service API exposed to higher-layer API invokers.Onboarding: One time registration process that enables the API invoker to subsequently access the CAPIF and the service APIs.Resource: The object or component of the API on which the operations are acted upon.Resource owner: An entity (either a UE user or an MNO subscriber) capable of granting access to a protected resource related to the invoked API.Resource owner-aware northbound API access: An API invocation scenario where the API invoker needs an authorization from the resource owner.Service API: The interface through which a component of the system exposes its services to API invokers by abstracting the services from the underlying mechanisms.Serving Area Information: The location information for which the service APIs are being offered to.CAPIF provider domain: A domain that contains an instance of CAPIF core function and may contain API provider domains and API invokers. The CAPIF provider could be a PLMN, SNPN or 3rd party. Throughout this document, PLMN trust domain is often used as the typical deployment of a CAPIF provider domain however SNPN trust domain or 3rd party trust domain are applicable as well.PLMN trust domain: The entities protected by adequate security and controlled by the PLMN operator or a trusted 31(1party of the PLMN.SNPN trust domain: The entities protected by adequate security and controlled by the SNPN operator or a trusted 31(1party of the SNPN. 3rdparty trust domain: The entities protected by adequate security and controlled by the 3rdparty.For the purposes of the present document, the following terms and definitions given in 3GPP TS 32.240 [6] apply:Offline chargingOnline charging***** NEXT CHANGE TO 3GPP TS 23.222 *****8.3.2.1 Service API publish requestTable 8.3.2.1-1 describes the information flow service API publish request from the API publishing function to the CAPIF core function.Table 8.3.2.1-1 : Service API publish request***** NEXT CHANGE TO 3GPP TS 23.222 *****8.5.2.2 Service API get responseTable 8.5.2.2-1 describes the information flow service API get response from the CAPIF core function to the API publishing function. Table 8.5.2.2-1 : Service API get response***** NEXT CHANGE TO 3GPP TS 23.222 *****8.6.2.1 Service API update requestTable 8.6.2.1-1 describes the information flow service API update request from the API publishing function to the CAPIF core function. Table 8.6.2.1-1 : Service API update request***** NEXT CHANGE TO 3GPP TS 23.222 *****8.7.2.1 Service API discover requestTable 8.7.2.1-1 describes the information flow service API discover request from the API invoker to the CAPIF core function.Table 8.7.2.1-1 : Service API discover request***** NEXT CHANGE TO 3GPP TS 23.222 *****8.7.2.2 Service API discover response Table 8.7.2.2-1 describes the information flow service API discover response from the CAPIF core function to the API invoker.Table 8.7.2.2-1 : Service API discover response***** NEXT CHANGE TO 3GPP TS 23.222 *****8.25.2.1 Interconnection API publish request Table 8.25.2.1-1 describes the information flow interconnection API publish request from CAPIF core function to CAPIF core function.Table 8.25.2.1-1 : Interconnection API publish request***** NEXT CHANGE TO 3GPP TS 23.222 ***** 8.25.2.3 Interconnection service API discover requestTable 8.25.2.3-1 describes the information flow interconnection service API discover request from one CAPIF core function to another CAPIF core function.Table 8.25.2.3-1 : Interconnection service API discover request***** NEXT CHANGE TO 3GPP TS 23.222 *****8.25.2.4 Interconnection service API discover response Table 8.25.2.4-1 describes the information flow interconnection service API discover response from one CAPIF core function to another CAPIF core function.Table 8.25.2.4-1 : Interconnection service API discover response***** NEXT CHANGE TO 3GPP TS 23.222 ***** 8.1 .2.1 Onboard API invoker requestTable 8.1.2.1-1 describes the information flow onboard API invoker request from the API invoker to the CAPIF core function.Table 8.1.2.1-1 : Onboard API invoker request*****NEXTCHANGE TO 3GPP TS 23.222 *****8.1.3 ProcedureFigure 8.1.3-1 illustrates the procedure for onboarding the API invoker to the CAPIF. The security aspects of this procedure are specified in subclause 6.1 of 3GPP TS 33.122

[0012] .Pre-conditions:1. The API invoker is not a recognized user of the CAPIF.2. The API invoker has visibility to APIs information (e.g., API catalogue or dashboard - central place for the API provider to manage which APIs are displayed, giving API invokers the ability to enroll for).Figure 8.1.3-1 : Procedure for onboarding the API invoker to the CAPIF1. For enrollment of the API invoker to be a recognized user of the CAPIF, the API invoker triggers onboard API invoker request towards the CAPIF core function, providing the information as required for the API management.2. The CAPIF core function begins the onboarding process by verifying whether all the necessary information has been provided to onboard the API invoker, and further initiates a grant process. Successful onboarding results in provisioning API invoker profile which includes identity for the API invoker. The authorization information and the list of APIs and the types of APIs that the API invoker can access subsequent to successful onboarding may also be created. The CAPIF core function may create access control policy (see Table E-l) for the onboarded API invoker considering the network slice information.NOTE 1: Completion of onboarding process can require explicit grant by the CAPIF administrator or the API management, which is left out-of-scope of this solution. CAPIF can handle the grant process internally without the need of explicit grant by the CAPIF administrator.NOTE 2: The API invoker profile consists of at least the identity information for the API invoker, information required for the authentication and authorization by the CAPIF and the CAPIF identity information.3. If the API invoker has triggered the onboard API invoker request and is granted permission, the onboard API invoker response provides success indication including information from the provisioned API invoker profile which may include information to allow the API invoker to be authenticated and to obtain authorization for service APIs.4. As a result of successful onboarding process, the CAPIF core function is able to authenticate and authorize the API invoker.***** NEXT CHANGE TO 3GPP TS 23.222 *****8.11.3 ProcedureFigure 8.11.3-1 illustrates the procedure for obtaining authorization to access the service API.Pre-condition:1. The API invoker is onboarded and has received an API invoker identity.Figure 8.11.3-1 : Procedure for the API invoker obtaining authorization for service API access1. The API invoker sends an obtain service API authorization request to the CAPIF core function for obtaining permission to access the service API by including the API invoker identity information and any information required for authentication of the API invoker. The request may include Network Slice Info of the API invoker and the desired Network Slice Info of the service API.2. The CAPIF core function validates the authentication of the API invoker (using authentication information) and checks whether the API invoker is permitted to access the requested service API. If Network Slice Info of the API invoker and desired Network Slice Info of the service API are received, the CAPIF core function checks if the API invoker is permitted to invoke the service API. For instance, the CAPIF core function may check that the Network Slice Info of the API invoker is included in the allowed Network Slice info for the indicated service API.NOTE 1: The authentication process is specified in subclause 6.5.2.3 of 3GPP TS 33.122

[0012] .3. Based on the API invoker's subscription information the authorization information to access the service APIs is sent to the API invoker in the obtain service API authorization response.NOTE 2: The mechanism for distribution of the authorization information for the API invoker to the API exposing function is specified in subclause 6.5.2.3 of 3GPP TS 33.122

[0012] .***** NEXT CHANGE TO 3GPP TS 23.222 *****8.12.2.2 Obtain access control policy responseTable 8.12.2.2-1 describes the information flow obtain access control policy response from the CAPIF core function to the AEF.Table 8.12.2.2-1 : Obtain access control policy response*****NEXTCHANGE TO 3GPP TS 23.222 *****8.16.2.1 Service API invocation request The information flow service API invocation request from the API invoker to the AEF is service API specific and the complete detail of the service API invocation request is out of scope of the present document. Table 8.16.2.1-1 describes only the CAPIF related information elements which are included in the service API invocation request.Table 8.16.2.1-1 : Service API invocation request***** NEXT CHANGE TO 3GPP TS 23.222 *****8.20.3 ProcedureFigure 8.20.3-1 illustrates the procedure for charging the invocation of service APIs.Pre-conditions:1. Authorization details of the AEF are available with the CAPIF core function.Figure 8.20.3-1 : Procedure for charging the invocation of service APIs1. Upon invocation of service API(s) from one more API invokers, the AEF triggers an API invocation charging request and includes API invoker information (e.g. invoker's ID and IP address, location, timestamp, Network Slice Info) and service API information (e.g. service API name and version, invoked operation, input parameters, invocation result, Network Slice Info of the service API) towards the CAPIF core function.NOTE: These requests can be triggered asynchronously.2. The CAPIF core function performs a charging procedure which includes storing the information for access by authorized API management.3. The AEF receives the API invocation charging response from the CAPIF core function.***** NEXT CHANGE TO 3GPP TS 23.222 *****8.19.2.1 API invocation log requestTable 8.19.2.1-1 describes the information flow API invocation log request from the API exposing function to the CAPIF core function.Table 8.19.2.1-1 : API invocation log request***** NEXT CHANGE TO 3GPP TS 23.222 *****8.22.2.2 Query service API log responseTable 8.22.2.2-1 describes the information flow query service API log response from the CAPIF core function to the API management function.Table 8.22.2.2-1 : Query service API log response***** NEXT CHANGE TO 3GPP TS 23.222 *****Annex E (normative):Configuration data for CAPIFThe configuration data is stored in the CAPIF core function and provided by the CAPIF administrator.The configuration data for CAPIF is specified in table E-l.Table E-1 : Configuration data for CAPIF*****ENDCHANGES TO 3GPP TS 23.222 ***** *****FIRSTCHANGE TO 3GPP TS 23.435 *****9.2 RegistrationFor registration of the VAL server to be a recognized user of the CAPIF, the VAL server triggers the CAPIF Onboarding the API invoker procedure defined in 3GPP TS 23.222[3] clause 8.1. The NSCE server could be deployed with CAPIF core function. [[Editor's note: What additional information is needed (e.g. the mapping of slice ids to a VAL service) in onboarding request, and if needed, whether it is specific for NSCE service or generally applicable for CAPIF are FFS]]For de-registration of the VAL server, the VAL server triggers the CAPIF Offboarding the API invoker procedure defined in 3GPP TS 23.222[3] clause 8.2.*****NEXTCHANGE TO 3GPP TS 23.435 *****9.3.2.1.2 Initial ConfigurationFigure 9.3.2.1.2-1 illustrates the procedure of the initial slice API configuration. Pre-conditions:1. The VAL server has registered to receive NSCE services.Figure 9.3.2.1.2-1 : Initial Slice API configuration1. The VAL server sends a VAL application requirement request to the NSCE server. If CAPIF is used, the NSCE server acts as AEF. and the authorization is obtained by CCF. The preferred network slice related identifier is used by the VAL server to consume the service provided by the NSCE server.2. The NSCE server maps the VAL application requirement to a slice API which includes a list of APIs which is needed to be consumed as part of this service capability exposure.The NSCE server may also store the mapping of the slice API to the service API list and per service API information (e.g. data encoding, transport technology, API protocol and versions)3. The NSCE server registers to consume the corresponding APIs from the 5GS (NEF and OAM) and SEAL service producers. The NSCE server registers to the following:- to consume NEF monitoring events as specified in 3GPP TS 29.522 clause 5 e.g., network monitoring, slice status, analytics exposure, etc- to consume PM services and KPI monitoring from OAM- to consume SEAL services based on 3GPP TS 23.434If CAPIF is used, the subscription / registration requests are sent to the corresponding AEFs of the API provider's domain, and the authorization is obtained by CCF. The preferred network slice related identifier received in step 1 is used by the NSCE server to consume the service provided by 5GS / SEAL.4. The NSCE server sends a VAL application requirement response to notify on the result of the request and indicate whether the configuration of slice API is possible or not.5. The NSCE server sends the slice API information notification to the VAL server.*****ENDCHANGES TO 3GPP TS 23.435 *****Further Details

[0095] Figure 10 is a schematic block diagram of a network node 1000 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 1000 may be, for example, a network node that implements all or part of the functionality of the API invoker 600, the CAPIF core function 602, the API publishing function 604, or the API exposing function 608, as described herein, e.g., with respect to Figure 6, Figure 7, and / or Figure 8. As illustrated, the network node 1000 includes one or more processors 1004 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1006, and a network interface 1008. The one or more processors 1004 are also referred to herein as processing circuitry. The one or more processors 1004 operate to provide one or more functions of the network node 1000 as described herein (e.g., one or more functions of the API invoker 600, the CAPIF core function 602, the API publishing function 604, or the API exposing function 608, as described herein, e.g., with respect to Figure 6, Figure 7, and / or Figure 8). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1006 and executed by the one or more processors 1004.

[0096] Figure 11 is a schematic block diagram that illustrates a virtualized embodiment of the network node 1000 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of the network node 1000 in which at least a portion of the functionality of the network node 1000 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, the network node 1000 includes one or more processing nodes 1100 coupled to or included as part of a network(s) 1102. Each processing node 1100 includes one or more processors 1104 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1106, and a network interface 1108.

[0097] In this example, functions 1110 of the network node 1000 described herein (e.g., one or more functions of the API invoker 600, the CAPIF core function 602, the API publishing function 604, or the API exposing function 608, as described herein, e.g., with respect to Figure 6, Figure 7, and / or Figure 8) are implemented at the one or more processing nodes 1100 or distributed across the one or more processing nodes 1100and the control system 1002 and / or the radio unit(s) 1010 in any desired manner. In some particular embodiments, some or all of the functions 1110 of the network node 1000 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1100.

[0098] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 1000 or a node (e.g., a processing node 1100) implementing one or more of the functions 1110 of the network node 1000 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0099] Figure 12 is a schematic block diagram of the network node 1000 according to some other embodiments of the present disclosure. The network node 1000 includes one or more modules 1200, each of which is implemented in software. The module(s) 1200 provide the functionality of the network node 1000 described herein. This discussion is equally applicable to the processing node 1100 of Figure 11 where the modules 1200 may be implemented at one of the processing nodes 1100 or distributed across multiple processing nodes 1100.

[0100] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more ofthe techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0101] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

Claims

Claims1. A method performed by a core function (602) of a common Application Programming Interface, API, framework for northbound APIs in a cellular communications system, the method comprising: receiving (612), from an API publishing function (604) associated to an API provider, a request to publish a service API, the request comprising network slice information for the service API.

2. The method of claim 1, further comprising performing (612) one or more actions based on the request to publish the service API.

3. The method of claim 2, wherein the one or more actions comprise storing information about the service API including the network slice information for the service API.

4. The method of any of claims 1 to 3, wherein the network slice information for the service API comprises information that identifies one or more network slices for which the service API is requested to be published.

5. The method of any of claims 1 to 3, wherein the network slice information for the service API comprises information that identifies one or more network slices for which the service API is to be discoverable.

6. The method of claim 4 or 5, wherein the information that identifies the one or more network slices comprises one or more Single Network Slice Selection Assistance Informations, S-NSSAIs.

7. The method of any of claims 1 to 6, further comprising: receiving (622), from an API invoker (600), a service API discovery request comprising network slice information; sending (624), to the API invoker (600), a service API discovery response comprising information about one or more service APIs that satisfy the discovery request.

8. The method of claim 7, wherein the service API and the network slice information for the service API satisfy the discovery request, and the service API discovery response comprises information about the service API.

9. The method of claim 7 or 8, wherein the network slice information for the service API comprises information that identifies one or more network slices for the service API, the network slice information comprised in the service API discovery request comprises information that identifies one or more network slices for the service API discovery request, and at least one of the one or more network slices for the service API included in the one or more network slices for the service API discovery request.

10. The method of any of claims 7 to 9, further comprising: receiving (626; 800), from the API invoker (600), a request for authorization to access the service API, the request for authorization comprising network slice information that identifies one or more network slices for which authorization to access the service API is requested; sending (628; 804), to the API invoker (600), an authorization response that indicates whether the API invoker (600) is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested.

11. The method of claim 10, further comprising, responsive to receiving (626; 800) the request for authorization to access the service API, determining (802) whether the API invoker (600) is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested.

12. The method of claim 11, wherein: the network slice information for the service API comprises information that identifies one or more network slices for the service API; the network slice information comprised in the request for authorization to access the service API comprises information that identifies one or more network slices for the authorization to access the service API is requested, anddetermining (802) whether the API invoker (600) is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested comprises determining whether the one or more network slices for which authorization to access the service API is requested are included in the one or more network slices for the service API.

13. The method of any of claims 10 to 12, wherein the authorization response comprises authorization information for enabling the API invoker (600) to access the service API.

14. The method of any of claims 1 to 6, further comprising: receiving (626; 800), from an API invoker (600), a request for authorization to access the service API, the request for authorization comprising network slice information that identifies one or network slices for which authorization to access the service API is requested; sending (628; 804), to the API invoker (600), an authorization response that indicates whether the API invoker (600) is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested.

15. The method of claim 14, further comprising, responsive to receiving (626; 800) the request for authorization to access the service API, determining (802) whether the API invoker (600) is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested.

16. The method of claim 15, wherein: the network slice information for the service API comprises information that identifies one or more network slices for the service API; the network slice information comprised in the request for authorization to access the service API comprises information that identifies one or more network slices for the authorization to access the service API is requested, and determining (802) whether the API invoker (600) is authorized to access the service API for the one or more network slices for which authorization to access theservice API is requested comprises determining whether the one or more network slices for which authorization to access the service API is requested are included in the one or more network slices for the service API.

17. The method of any of claims 14 to 16, wherein the authorization response comprises authorization information for enabling the API invoker (600) to access the service API.

18. The method of any of claims 1 to 17, further comprising generating (632) service API access information with network slice information.

19. The method of claim 18, wherein the service API access information comprises information related to charging, logging, and / or auditing functions.

20. The method of any of claims 1 to 17, further comprising: receiving (614) an onboarding request from an API invoker (600), the onboarding request comprising network slice information for the API invoker (600); and performing (616) one or more actions related to onboarding the API invoker (600) responsive to the onboarding request.

21. The method of claim 20, wherein the one or more actions related to onboarding the API invoker (600) comprise creating an access control policy for the API invoker (600) based on the network slice information of the API invoker (600).

22. A core function (602) of a common Application Programming Interface, API, framework for northbound APIs in a cellular communications system, the core function (602) adapted to perform the method of any of claims 1 to 21.

23. A network node (1000) for implementing a core function (602) of a common Application Programming Interface, API, framework for northbound APIs in a cellular communications system, the network node (1000) comprising processing circuitry (1004; 1104) configured to cause the network node (1000) to perform the method of any of claims 1 to 21.

24. A method performed by an Application Programming Interface, API, publishing function (604) in a common API framework for northbound APIs in a cellular communications system, the method comprising: sending (612), to a core function (602) of the common API framework, a request to publish a service API, the request comprising network slice information for the service API.

25. The method of claim 24, wherein the network slice information for the service API comprises information that identifies one or more network slices for which the service API is requested to be published.

26. The method of claim 24, wherein the network slice information for the service API comprises information that identifies one or more network slices for which the service API is to be discoverable.

27. The method of claim 25 or 26, wherein the information that identifies the one or more network slices comprises one or more Single Network Slice Selection Assistance Informations, S-NSSAIs.

28. An Application Programming Interface, API, publishing function (604) in a common API framework for northbound APIs in a cellular communications system, the API publishing function (604) adapted to perform the method of any of claims 24 to 27.

29. A network node (1000) for implementing an Application Programming Interface, API, publishing function (604) in a common API framework for northbound APIs in a cellular communications system, the network node (1000) comprising processing circuitry (1004; 1104) configured to cause the network node (1000) to perform the method of any of claims 24 to 27.

30. A method performed by an Application Programming Interface, API, invoker (600) for a common API framework for northbound APIs in a cellular communications system, the method comprising:sending (622), to a core function (602) of the common API framework, a service API discovery request comprising network slice information; receiving (624), from the core function (602), a service API discovery response comprising information about one or more service APIs that satisfy the discovery request.

31. The method of claim 30, wherein the network slice information comprised in the service API discovery request comprises information that identifies one or more network slices for the service API discovery request, and at least one of one or more network slices for each of the one or more service APIs that satisfy the service API discovery request is included in the one or more network slices for the service API discovery request.

32. The method of any of claims 30 to 31, further comprising: sending (626; 800), to the core function (600), a request for authorization to access a service API indicated the information comprised in the service API discovery response, the request for authorization comprising network slice information that identifies one or network slices for which authorization to access the service API is requested; receiving (628; 804), from the core function (600), an authorization response that indicates whether the API invoker (600) is authorized to access the service API for the one or more network slices for which authorization to access the service API is requested.

33. The method of claim 32, wherein the authorization response comprises authorization information for enabling the API invoker (600) to access the service API.

34. The method of any of claims 30 to 33, further comprising: sending (614) an onboarding request to the core function (602), the onboarding request comprising network slice information for the API invoker (600); and receiving (618) an onboarding response from the core function (602).

35. An Application Programming Interface, API, invoker (600) for a common API framework for northbound APIs in a cellular communications system, the API invoker (600) adapted to perform the method of any of claims 30 to 34.

36. A network node (1000) for implementing an Application Programming Interface,API, invoker (600) for a common API framework for northbound APIs in a cellular communications system, the network node (1000) comprising processing circuitry (1004; 1104) configured to cause the network node (1000) to perform the method of any of claims 30 to 34.

Images