Methods and apparatus for handling service API access in capif interconnection in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Accordingly, the embodiments disclosed herein relate to a method for handling an API access in a CAPIF interconnection in a wireless network (1000) by an API invoker (102). The method performed by an application programming interface (API) invoker includes transmitting, to a first common API framework (CAPIF) core function (CCF) entity in a first CAPIF provider, a security method request message including information on an API exposing function (AEF) entity registered to a second CCF entity in second CAPIF provider; and receiving, from the first CCF entity, a security method response message including a security method of the AEF entity which is used over a CAPIF-2 / 2e reference point for the AEF entity, wherein the API invoker is onboarded to the first CCF entity.

Description

METHODS AND APPARATUS FOR HANDLING SERVICE API ACCESS IN CAPIF INTERCONNECTION IN A WIRELESS COMMUNICATION SYSTEM

[0001] Embodiments disclosed herein relate to a wireless network, and more particularly to methods and systems (or wireless network) for handling an Application Programming interface (API) access in a Common Application Programming Interface Framework (CAPIF) interconnection in the wireless network

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “Sub 6GHz” bands such as 3.5GHz, but also in “Above 6GHz” bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz (THz) bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] There is a need in the art for solutions which will overcome the above mentioned drawback(s), among others.

[0009] The principal object of embodiments herein is to disclose methods and systems (or wireless network) for handling an Application Programming interface (API) access in a Common Application Programming Interface Framework (CAPIF) interconnection in the wireless network.

[0010] Another object of embodiments herein is to authenticate and authorize the service API access in the CAPIF interconnections.

[0011] Another object of embodiments herein is to securely transfer a security material used for authentication of the API invoker in a domain accessing service APIs in another trust domain.

[0012] Another object of embodiments herein is to validate an API invoker request based on an API invoker ID associated with CCF identity details.

[0013] Another object of embodiment herein is to retrieve a security technique selected and / or supported by an AEF by the API invoker in different trust domain via the CCFs.

[0014] Another object of embodiment herein is that the API Invoker ID includes an information of a domain (for example, Domain A) it is on-boarded, which will be used by the AEF / CCF or the entity in the domain B to resolve an internet protocol (IP) address of the on-boarded CCF (in domain A).

[0015] Another object of embodiment herein is that the API Invoker ID provides the information of the CCF (for example, Domain A) to the AEF and / or CCF in a second domain (domain B), which will be used by the AEF / CCF or the entity in the domain B to reach the CCF in the first domain (e.g., domain A).

[0016] Accordingly, the embodiments disclosed herein relate to a method for handling an API access in a CAPIF interconnection in a wireless network, the method comprises, sending, by an API invoker, an authentication initiation request to an API exposure Function (AEF) entity. The authentication initiation request includes at least one of: a CAPIF core function (CCF) assigned API invoker ID and a CCF identity information. The API invoker is onboarded and communicates with a first CCF entity in a first domain and the AEF entity is registered and communicates with a second CCF entity in a second domain. Further, the method comprises, receiving, by the API invoker, an authentication initiation response message from the AEF entity to initiate a secure session establishment based on the authentication initiation request. The method further comprises, initiating, by the API invoker, the secure session establishment among the API invoker, the AEF entity, the first CCF entity and the second CCF entity.

[0017] In an embodiment, the authentication initiation response message is generated by sending, by the AEF entity, a security information request to the second CCF to perform authentication and secure interface establishment with the API invoker upon determining that the AEF entity does not have a valid security information; sending, by the second CCF, the security information request to the first CCF to perform authentication and secure interface establishment between the API invoker and the AEF; receiving, by the first CCF, the security information request from the second CCF to perform authentication and secure interface establishment between the API invoker and the AEF, wherein the first CCF entity retrieves a valid security information to validate the API invoker based on the received API invoker identity; providing, by the first CCF, the valid security information in a response corresponding to the security information request to the AEF entity through the second CCF, via an interface; establishing, by the AEF entity, the secure TLS connection using the received security information in the security information response message; and sending, by the AEF entity, the authentication initiation response after successful establishment of TLS connection.

[0018] In an embodiment, the security information request comprises at least one of: the CCF assigned API invoker ID, the CCF identity information, at least one shareable service API, an AEF identity information, as the API invoker is registered to the first domain. The AEF adds at least one security technique selected by the AEF entity in the security information request sent to the second CCF.

[0019] In an embodiment, the CCF assigned API invoker ID indicates the CCF identity information in which the API invoker is onboarded or registered for the second CCF entity in the second domain to reach out to the first CCF in the first domain when the AEF entity and the second CCF receive the authentication initiation request from the API invoker onboarded in the first domain.

[0020] In an embodiment, the valid security information comprises at least one of: AEFPSK, and a root certificate of a CA.

[0021] In an embodiment, the authentication initiation response message is generated and sent to the API invoker upon successful establishment of secure TLS connection between API invoker and the AEF entity.

[0022] Accordingly, the embodiments disclosed herein relate to a method for handling an API access in a CAPIF interconnection in a wireless network. The method includes sending, by an API invoker, a security technique request to a first CCF. The security technique request includes an API invoker identity, at least one AEF detail, at least one security technique, a security capability information and a CCF identity information. The API invoker communicates with a first CCF entity in a first domain and an AEF entity and a second CCF entity in a second domain. Further, the method includes receiving, by the API invoker, a security technique response from the first CCF based on the security technique request, where the security technique response comprises the at least one AEF detail, a selected security technique and security information comprising a valid key (e.g., valid security information). In an example, for a TLS PSK security information, the valid key is AEFPSK.For TLS cert based authentication, the security information is root CA certificate.

[0023] In an embodiment, the security capability information indicating a list of security technique that the API invoker supports over a CAPIF reference point in which at least one service API wants to access with the AEF identity information. The API invoker identity provides an information of the first CCF in the first domain to the second CCF in the second domain. The AEF identity information indicates the information of the second CCF for the first CCF in the first domain to determine and identify the requested service APIs are exposed by the AEF entity in the second domain.

[0024] In an embodiment, the security technique response, is generated, from the first CCF by: determining, by the first CCF, that the service API requested by the API invoker is provided by the AEF entity in the second CCF based on the AEF identity information; sending, by the first CCF, an interconnection API publish request to the second CCF, where the interconnection API publish request comprises at least one of: an API invoker ID, the at least one service API, a category information of the at least one service API, an identity information associated with the second CCF, a shareable information, a CAPIF provider domain information, and an AEF identity information based on the determination, wherein the second CAPIF selects a security technique to be used over the CAPIF reference point for each requested AEF based on the security technique request; receiving, by the first CCF, an interconnection API publish response from the second CCF, wherein the interconnection API publish response comprises at least one selected security technique to be used over the CAPIF reference point for each requested AEF; and generating the security technique response based on the interconnection API publish response.

[0025] Accordingly, the embodiments disclosed herein relate to a method for handling an API access in a CAPIF interconnection in a wireless network. The method includes receiving, by an API exposure Function (AEF) entity, an authentication initiation request from the API invoker. The authentication initiation request includes at least one of: a CAPIF core function (CCF) assigned API invoker ID and a CCF identity information. The API invoker communicates with a first CCF entity in a first domain and the AEF entity communicates with a second CCF entity in a second domain. The method further includes receiving, by the AEF entity, an authentication initiation response message from the API invoker to initiate a secure session establishment based on the authentication initiation request.

[0026] Accordingly, the embodiments disclosed herein relate to a method for handling an API access in a CAPIF interconnection in a wireless network. The method includes receiving, by a first CCF, a security technique request from an API invoker. The security technique request includes the API invoker identity, at least one AEF detail, at least one security technique, a security capability information and a CCF identity information. Further, the method includes sending, by the first CCF, a security technique response to the API invoker based on the security technique request. The security technique response includes the at least one AEF detail, a selected security technique and security information comprising a valid security information.

[0027] Accordingly, the embodiments disclosed herein relate to a method for handling an API access in a CAPIF interconnection in a wireless network. The method includes receiving, by a first CCF, a security information request from a second CCF to perform authentication and secure interface establishment between an API invoker and an AEF entity. The first CCF entity retrieves a valid security information to validate the API invoker based on a received API invoker identity. The API invoker communicates with a first CCF entity in a first domain and the AEF entity communicates with a second CCF entity in a second domain. Further, the method comprises, providing, by the first CCF, the valid security information in a response corresponding to the security information request to the AEF entity through the second CCF via an interface.

[0028] Accordingly, the embodiments disclosed herein relate to a method for handling an API access in a CAPIF interconnection in a wireless network. The method includes receiving, by a second CCF, a security information request from an AEF entity to perform authentication and secure interface establishment with an API invoker upon determining that the AEF entity does not have a valid security information. The API invoker communicates with a first CCF entity in a first domain and the AEF entity communicates with a second CCF entity in a second domain. Further, the method comprises, sending, by the second CCF, the security information request to a first CCF to perform authentication and secure interface establishment between the API invoker and the AEF.

[0029] Accordingly, the embodiments disclosed herein relate to an API invoker, configured to send an authentication initiation request to an AEF entity, where the authentication initiation request includes at least one of: a CAPIF core function (CCF) assigned API invoker ID and a CCF identity information. The API invoker communicates with a first CCF entity in a first domain and the AEF entity communicates with a second CCF entity in a second domain. Further, the API invoker is configured to receive an authentication initiation response message from the AEF entity to initiate a secure session establishment based on the authentication initiation request. The API invoker is further configured to initiate the secure session establishment among the API invoker, the AEF entity, the first CCF entity and the second CCF entity.

[0030] Accordingly, the embodiments disclosed herein relate to an AEF including a processor, a memory, and a service API access handling controller. The service API access handling controller is coupled with the processor, and the memory. The service API access handling controller is configured to receive an authentication initiation request from the API invoker. The authentication initiation request includes at least one of: a CCF assigned API invoker ID and a CCF identity information. The API invoker communicates with a first CCF entity in a first domain and the AEF entity communicates with a second CCF entity in a second domain. Further, the service API access handling controller is configured to receive an authentication initiation response message from the API invoker to initiate a secure session establishment based on the authentication initiation request.

[0031] Accordingly, the embodiments disclosed herein relate to a first CCF including a processor, a memory, and a service API access handling controller. The service API access handling controller is coupled with the processor, and the memory. The service API access handling controller is configured to receive a security technique request from an API invoker, wherein the security technique request comprises the API invoker identity, at least one AEF detail, at least one security method, a security capability information and a CCF identity information. Further, the service API access handling controller is configured to send a security technique response to the API invoker based on the security technique request. The security technique response includes the at least one AEF detail, a selected security technique and security information comprising a valid security information.

[0032] Accordingly, the embodiments disclosed herein relate to a second CCF comprising a processor, a memory, and a service API access handling controller. The service API access handling controller is coupled with the processor, and the memory. The service API access handling controller is configured to receive a security information request from an AEF entity to perform authentication and secure interface establishment with an API invoker upon determining that the AEF entity does not have a valid security information, wherein the API invoker communicates with a first CCF entity in a first domain and the AEF entity communicates with a second CCF entity in a second domain. Further, the service API access handling controller is configured to send the security information request to a first CCF to perform authentication and secure interface establishment between the API invoker and the AEF. The second CCF is further configured to share a valid security information in a response corresponding to the security information request to the AEF entity through the first CCF via an interface.

[0033] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating at least one embodiment and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the scope thereof, and the embodiments herein include all such modifications.

[0034] The method and device provided in the application improve the performance of CSI, improving the scheduling efficiency of the communication system.

[0035] Aspects of the present disclosure provide efficient communication methods in a wireless communication system.

[0036] Embodiments herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the following illustratory drawings. Embodiments herein are illustrated by way of examples in the accompanying drawings, and in which:

[0037] FIG. 1 illustrates two organizations with a business relationship where each organization deployed CAPIF that may need to interoperate to allow API invokers in each trust domain to utilize service APIs from both CAPIFs, according to existing arts;

[0038] FIG. 2 depicts a functional architecture for CAPIF interconnection with multiple CAPIF provider domains, according to existing arts;

[0039] FIG. 3 is a sequence diagram depicting an authentication and authorization procedure during CAPIF interconnect, according to embodiments as disclosed herein;

[0040] FIG. 4 is depicting a procedure for retrieving by an API Invoker, AEF details from trust domain B of CAPIF provider, according to embodiments as disclosed herein;

[0041] FIG. 5A is a block diagram of the API invoker running in a UE or a server, for handling the API access in the CAPIF interconnection in a wireless network, according to embodiments as disclosed herein;

[0042] FIG. 5B is a block diagram of an AEF for handling the API access in the CAPIF interconnection in the wireless network, according to embodiments as disclosed herein;

[0043] FIG. 5C is a block diagram of a first CCF for handling the API access in the CAPIF interconnection in the wireless network, according to embodiments as disclosed herein;

[0044] FIG. 5D is a block diagram of a second CCF for handling the API access in the CAPIF interconnection in the wireless network, according to embodiments as disclosed herein;

[0045] FIG. 6 is a flow diagram of a method, implemented by the API invoker, for handling the API access in the CAPIF interconnection in the wireless network, according to embodiments as disclosed herein;

[0046] FIG. 7 is a flow diagram depicting a method for security negotiation between the API invoker and the AEF, for handling the API access in the CAPIF interconnection in the wireless network, according to embodiments as disclosed herein;

[0047] FIG. 8 is a flow diagram depicting a method, implemented by an AEF, for handling the API access in the CAPIF interconnection in the wireless network, according to embodiments as disclosed herein;

[0048] FIG. 9 is a flow diagram depicting the method, implemented by a first CCF, for handling the API access in the CAPIF interconnection in the wireless network, according to embodiments as disclosed herein;

[0049] FIG. 10 is a flow diagram depicting the method, implemented by a first CCF, for security negotiation between the API invoker and the AEF, according to embodiments as disclosed herein;

[0050] FIG. 11 is a flow diagram depicting the method, implemented by a second CCF, for security negotiation between the API invoker and the AEF, according to embodiments as disclosed herein;

[0051] FIG. 12 depicts a procedure for CAPIF Interconnect API publish, according to embodiments as disclosed herein;

[0052] FIG. 13 is a sequence diagram depicting, authentication and authorization procedure during a CAPIF Interconnect, according to embodiments as disclosed herein;

[0053] FIG. 14 is a block diagram of a terminal or user equipment (UE) according to an embodiment of the disclosure;

[0054] FIG. 15 is a block diagram of a base station (BS) according to an embodiment of the disclosure, and

[0055] FIG. 16 is a block diagram of a network entity according to an embodiment of the disclosure.

[0056] Hereinafter, embodiments of the disclosure will be described in detail with reference to the accompanying drawings.

[0057] In describing the embodiments, descriptions related to technical contents well-known in the art and not associated directly with the disclosure will be omitted. Such an omission of unnecessary descriptions is intended to prevent obscuring of the main idea of the disclosure and more clearly transfer the main idea.

[0058] For the same reason, in the accompanying drawings, some elements may be exaggerated, omitted, or schematically illustrated. Further, the size of each element does not completely reflect the actual size. In the drawings, identical or corresponding elements are provided with identical reference numerals or different reference numerals.

[0059] The advantages and features of the disclosure and ways to achieve them will be apparent by making reference to embodiments as described below in detail in conjunction with the accompanying drawings. However, the disclosure is not limited to the embodiments set forth below, but may be implemented in various different forms. The following embodiments are provided only to completely disclose the disclosure and inform those skilled in the art of the scope of the disclosure, and the disclosure is defined only by the scope of the appended claims. Throughout the specification, the same or like reference numerals designate the same or like elements. Furthermore, in describing the disclosure, a detailed description of known functions or constitution incorporated herein will be omitted in the case that it is determined that the description may make the subject matter of the disclosure unnecessarily unclear. The terms which will be described below are terms defined in consideration of the functions in the disclosure, and may be different according to users, intentions of the operators, or customs. Therefore, the definitions of the terms should be made based on the contents throughout the specification.

[0060] Herein, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, may be performed based on computer program instructions. These computer program instructions may be loaded collectively onto at least one processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which perform through any one of, or in any combination of, the at least one processor of the computer or other programmable data processing apparatus, create means for performing the functions specified in the flowchart block(s). These computer program instructions may also be stored in a non-transitory computer usable or computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer usable or computer-readable memory produce an article of manufacture including instruction means that perform the function specified in the flowchart block(s). The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable data processing apparatus to produce a computer executed process such that the instructions that perform on the computer or other programmable data processing apparatus provide steps for executing the functions specified in the flowchart block(s).

[0061] Further, each block may represent a module, segment, or portion of code, which includes one or more executable instructions for executing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks(or functions) shown in succession may in fact be performed substantially concurrently or the blocks may sometimes be performed in the reverse order, depending upon the functionality involved.

[0062] As used in embodiments of the disclosure, a “~unit” may refer to a software element or a hardware element, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), which performs a predetermined function. However, the term including the word “~unit” does not always have a meaning limited to software or hardware. The “~unit” may be constructed either to be stored in an addressable storage medium or to execute one or more processors. Therefore, the “~unit” includes, for example, software elements, object-oriented software elements, components such as class elements and task elements, processes, functions, properties, procedures, sub-routines, segments of a program code, drivers, firmware, micro-codes, circuits, data, database, data structures, tables, arrays, and parameters. The components and functions provided by the “~unit” may be either combined into a smaller number of components and a “~unit,” or divided into additional components and a “~unit.” Moreover, the components and “~units” may be implemented to reproduce one or more central processing units (CPUs) within a device or a security multimedia card. Further, in the embodiments, the “~unit” may include one or more processors.

[0063] It should be appreciated that the blocks in each flowchart and combinations of the flowcharts may be performed by one or more computer programs which include instructions. The entirety of the one or more computer programs may be stored in a single memory device or the one or more computer programs may be divided with different portions stored in different multiple memory devices.

[0064] Any of the functions or operations described herein can be processed by one processor or a combination of processors. The one processor or the combination of processors is circuitry performing processing and includes circuitry like an application processor (AP, e.g. a CPU), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth® chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, connectivity chips, a sensor controller, a touch controller, a finger-print sensor controller, a display driver integrated circuit (IC), an audio CODEC chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on chip (SoC), an IC, or the like.

[0065] It will be appreciated that various embodiments of the disclosure according to the claims and description in the specification can be realized in the form of hardware, software or a combination of hardware and software.

[0066] Any such software may be stored in non-transitory computer readable storage media. The non-transitory computer readable storage media store one or more computer programs (software modules), the one or more computer programs include computer-executable instructions that, when executed by one or more processors of an electronic device individually or collectively, cause the electronic device to perform a method of the disclosure.

[0067] Any such software may be stored in the form of volatile or non-volatile storage such as, for example, a storage device like read only memory (ROM), whether erasable or rewritable or not, or in the form of memory such as, for example, random access memory (RAM), memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a compact disk (CD), digital versatile disc (DVD), magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are various embodiments of non-transitory machine-readable storage that are suitable for storing a computer program or computer programs comprising instructions that, when executed, implement various embodiments of the disclosure. Accordingly, various embodiments of the present disclosure may provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a non-transitory machine-readable storage storing such a program.

[0068] Hereinafter, the determination of priority between A and B in the present disclosure may refer to various actions such as selecting the one having a higher priority based on a predefined priority rule and performing an operation corresponding thereto, or omitting or dropping an operation corresponding to the one having a lower priority.

[0069] Hereinafter, "A or B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0070] In addition, "at least one of A, B, and C" as described in the present disclosure may be understood to include A, or B, or C, or any combination of A, B, and C.

[0071] In addition, "at least one of A, B, or C" as described in the present disclosure may be understood to include A, or B, or C, or any combination of A, B, and C.

[0072] Furthermore, "A / B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0073] Furthermore, "A, B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0074] Furthermore, "A and B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0075] Furthermore, “if condition A and condition B are satisfied,” as described in the present disclosure, may not be limited to a case where both condition A and condition B are satisfied, but may be understood to include a case where either condition A or condition B is individually satisfied, both condition A and condition B are satisfied, or one or more additional conditions are satisfied in combination.

[0076] Furthermore, throughout this disclosure, ordinal terms such as "first," "second," "third," etc., (and similar qualifiers) are used merely to distinguish between different instances, occurrences, configurations, messages, stages, or aspects of elements, operations, or information as described herein. Unless the context clearly dictates otherwise, the use of such ordinal terms does not itself require that the elements, operations, or information distinguished by these terms be structurally different, numerically distinct, or substantively dissimilar. For example, a "first signal" and a "second signal" may refer to instances of the same signal transmitted at different times or containing the same core information despite minor variations, or they may refer to signals with different content or characteristics, depending on the specific context. Similarly, a "first value" and a "second value" may represent the same magnitude but measured or applied in different circumstances, or they may represent different magnitudes. The interpretation should be guided by the specific technical context, function, and relationship described in the relevant portion of the specification and claims.

[0077] Furthermore, the terms “first ~”, “second ~”, etc., as described in the present disclosure with respect to various elements (e.g., information, objects, operation, sequences, or the like), should not limit those elements. These terms may only be intended to distinguish one element from another, and may not be intended to indicate a specific order. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element.

[0078] Furthermore, even if “first ~” and “second ~” are described in the present disclosure, it may be understood that element(s) referred to by “first ~” and “second ~” may be the same or different. For example, in case of element(s) being information, first information and second information may both be same information and, in some cases, are separate and different information.

[0079] In addition, the terms “if ~” and “in case that ~” as used in the disclosure or claims may be interpreted to include the meanings of “when (or upon) ~,” “in response to ~,” “based on ~,” or “according to ~,” and may be used interchangeably with these expressions. In addition, expressions other than those exemplified herein may also be used, as long as they have substantially the same meaning and do not impair the technical features of the present disclosure.

[0080] For example, the physical layer signaling may be referred to as Layer 1 (L1) signaling and may include downlink control information (DCI). In addition, the higher layer signaling may include a medium access control (MAC) control message, a radio resource control (RRC) signaling message, a non-access stratum (NAS) signaling message, or an application layer message. The RRC signaling message may be referred to as L3 (layer 3) signaling. It should be noted, however, that the higher layer signaling is not limited to the aforementioned examples.

[0081] In addition, the term "not perform" as used in the present disclosure or claims may, in context, be understood to mean that the corresponding step is omitted or skipped. Such a term may be replaced with other terms having the same or substantially equivalent meaning.

[0082] In addition, "transmitting a message including A and B" as described in the present disclosure, may be understood as encompassing both (i) transmitting A and B in a single message, and (ii) transmitting A and B separately via multiple messages (e.g., transmitting a first message including A and a second message including B). This interpretation may also apply to messages that include two or more items (e.g., A, B, C), transmitted either together or separately.

[0083] In addition, "transmitting a message including A and transmitting a message including B" may also be interpreted as transmitting a message including A and B in a single message.

[0084] In the specific embodiments of the present disclosure described below, terms or components included in the disclosure may be expressed in singular or plural form depending on the specific embodiments presented. However, such singular or plural expressions are selected appropriately for convenience of description, and the present disclosure is not limited to a singular or plural number of components. A component expressed in the plural form may be implemented as a single component, and a component expressed in the singular form may be implemented as multiple components.

[0085] The drawings or flowcharts described below illustrate exemplary methods that may be implemented according to the principles of the present disclosure, and various modifications may be made to the methods illustrated in the flowcharts of the present disclosure. For example, although illustrated as a series of steps, various steps in each drawing or flowchart may overlap, occur in parallel, occur in a different order, or be repeated. In other examples, any step may be omitted or replaced with another step.

[0086] The methods and apparatuses proposed in the embodiments of the present disclosure are not limited to each embodiment individually, but may also be applied in combination of all or some of the embodiments proposed in the disclosure. Therefore, the embodiments of the present disclosure may be modified and applied without significantly departing from the scope of the present disclosure, as would be understood by those skilled in the art.

[0087] In this case, even if certain wordings are described differently across embodiments, they may be used interchangeably or in substitution or in combination if their underlying concepts are equivalent. For example, for the same or equivalent concept, even if one embodiment uses the expression "A" and another embodiment uses the expression "B", such expressions may be understood interchangeably, in substitution, or in combination.

[0088] The terms used in the following description to refer to access nodes, network entities, messages, interfaces between network entities, various types of identification information, and the like, are provided merely for the convenience of explanation by way of example. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may also be used. Such terms may also be interchangeable with terms defined in any 3rd generation partnership project　(3GPP) technical specifications (TS) where appropriate.

[0089] Hereinafter, a base station is an entity that allocates resources to terminals, and may be at least one of a gNode B, an eNode B, a Node B, a base station (BS), a wireless access unit, a BS controller, or a node on a network.

[0090] Furthermore, the base station of the present disclosure may include a split architecture comprising a central unit (CU) and a distributed unit (DU). In this structure, the CU is configured to process the higher layers of the control and user planes, while the DU is configured to process lower-layer radio resource functions. The embodiments of the present disclosure may be equally applicable to 5G base station architectures in which such CU and DU functional splits are implemented.

[0091] A terminal may include a UE, a mobile station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions.

[0092] In the disclosure, a downlink (DL) refers to a radio link through which a BS transmits a signal to a UE, and an uplink (UL) refers to a radio link through which a UE transmits a signal to a BS.

[0093] Furthermore, hereinafter, 5th generation (5G) mobile communication technologies (e.g., 5G new radio (NR)), 6th generation (6G) mobile communication technologies may be described by way of example, but the embodiments of the present disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, newly evolved mobile communication systems developed after 5G and 6G may be included. Furthermore, based on determinations by those skilled in the art, the embodiments of the present disclosure may also be applied to other communication systems (e.g., Wi-Fi systems) through some modifications without significantly departing from the scope of the present disclosure

[0094] In the following description, the terms physical channel and signal may be used interchangeably with data or control signal. For example, the term physical downlink shared channel (PDSCH) refers to a physical channel through which data is transmitted, but the term PDSCH may also be used to refer to the data itself. That is, in the present disclosure, the expression "transmit a physical channel" may be interpreted as being equivalent to the expression "transmit data or a signal via a physical channel."

[0095] Hereinafter, in the context of the present disclosure, higher layer signaling may refer to signaling corresponding to at least one or any combination of the following: master information block (MIB), system information block (SIB) or SIB M (M = 1, 2, ...), radio resource control (RRC), or medium access control (MAC) control element (CE), or a non-access stratum (NAS) signaling message, or an application layer message. The RRC signaling message may be referred to as L3 (layer 3) signaling.

[0096] In addition, L1 signaling may refer to signaling corresponding to at least one or any combination of signaling techniques using the at least one or any combination of the following physical layer channels or signaling: physical downlink control channel (PDCCH), downlink control information (DCI), user equipment (UE)-specific DCI, group-common DCI, common DCI, scheduling DCI (e.g., DCI used for scheduling downlink or uplink data), non-scheduling DCI (e.g., DCI not used for scheduling downlink or uplink data) physical uplink control channel (PUCCH), or uplink control information (UCI). The L1 signaling message may be referred to as a physical layer signaling.

[0097] Hereinafter, the expression that information is configured by the BS, as used in the present disclosure or claims, may, in context, be understood to mean that the terminal receives the corresponding information from the BS via a physical layer signaling or a higher layer signaling. Such an expression may be replaced with other terms having the same or substantially equivalent meaning.

[0098] Hereinafter, the operational principle of the present disclosure will be described in detail with reference to the accompanying drawings.

[0099] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0100] The words / phrases "exemplary", “example”, “illustration”, “in an instance”, “and the like”, “and so on”, “etc.”, “etcetera”, “e.g.,”, “i.e.,” are merely used herein to mean "serving as an example, instance, or illustration. Any embodiment or implementation of the present subject matter described herein using the words / phrases "exemplary", “example”, “illustration”, “in an instance”, “and the like”, “and so on”, “etc.”, “etcetera”, “e.g.”, “i.e.,” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0101] Embodiments herein may be described and illustrated in terms of blocks which carry out a described function or functions.　These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and may optionally be driven by a firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block.　Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure.　Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

[0102] It should be noted that elements in the drawings are illustrated for the purposes of this description and ease of understanding and may not have necessarily been drawn to scale. For example, the flowcharts / sequence diagrams illustrate the method in terms of the steps required for understanding of aspects of the embodiments as disclosed herein. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Furthermore, in terms of the system, one or more components / modules which comprise the system may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0103] The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any modifications, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings and the corresponding description. Usage of words such as first, second, third etc., to describe components / elements / steps is for the purposes of this description and should not be construed as sequential ordering / placement / occurrence unless specified otherwise.

[0104] The terms “AEF” and “AFE entity” are used interchangeably in the patent disclosure. The terms “first CCF” and “CCF-A” are used interchangeably in the patent disclosure. The terms “second CCF” and “CCF-B” are used interchangeably in the patent disclosure. The terms “first domain” and “domain-A” are used interchangeably in the patent disclosure. The terms “second domain” and “domain-B” are used interchangeably in the patent disclosure. The terms “security methods” and “security techniques” are used interchangeably in the patent disclosure.

[0105] Interconnection between two CAPIF providers (106a, 106b):

[0106] FIG. 1 illustrates two organizations with a business relationship where each organization deployed Common API framework (CAPIF) that may need to interoperate to allow Application Programming interface (API) invokers (102a, 102b) in each trust domain to utilize service APIs (104a, 104b) from both CAPIFs in a wireless network 1000. From each CAPIF provider's perspective, the other CAPIF provider (106b) is a 3rdparty.

[0107] A CAPIF-6 / CAPIF-6e reference point exists between CAPIF core functions (CCFs) (202a, 202b) (as shown in FIG. 2) within same trust domain of the CAPIF provider (106b), or CAPIF core functions deployed within a Public Land Mobile Network (PLMN) trust domain and within a 3rdparty trust domain.

[0108] The CAPIF-6 / CAPIF-6e reference point supports:

[0109] a. Publishing service APIs information between CAPIF trust domains; and

[0110] b. Discovering the service APIs information between CAPIF trust domains

[0111] API Invoker:The API invoker (102) is typically provided by a 3rdparty application provider who has a service agreement with a PLMN operator. The API invoker (102) may reside within the same trust domain as the PLMN operator network. The API invoker (102) may be either an application on a server or an application on a UE.

[0112] a. The API invoker (102) supports the following capabilities:

[0113] b. Triggering the API invoker (102) onboarding and offboarding;

[0114] c. Supporting an authentication by providing an API invoker identity and other information required for authentication of the API invoker (102);

[0115] Supporting mutual authentication with the CAPIF;

[0116] d. Obtaining authorization prior to accessing service APIs (104a, 104b);

[0117] e. Discovering service APIs information; and

[0118] f. Invoking service APIs (104a, 104b).

[0119] CAPIF Core Function (CCF):The CAPIF core function (202a, 202b) comprises of the following capabilities:

[0120] a. Authenticating the API invoker (102) based on identity and other information required for authentication of the API invoker (102);

[0121] b. Supporting mutual authentication with the API invoker (102);

[0122] c. Providing authorization for the API invoker (102) prior to accessing the service API (104a, 104b);

[0123] d. Publishing, storing and supporting discovery of service APIs information;

[0124] e. Controlling service API access based on PLMN operator configured policies;

[0125] f. Storing logs for service API invocations and providing service API invocation logs to authorized entities;

[0126] g. Charging based on logs of the service API invocations;

[0127] h. Monitoring service API invocations;

[0128] i. Onboarding a new API invoker and offboarding the API invoker (102);

[0129] j. Storing policy configurations related to CAPIF and service APIs (104a, 104b);

[0130] k. Support accessing the logs for auditing (e.g. detecting abuse);

[0131] l. Supports publishing, retrieving, unpublishing, updating, and discovering service APIs information with another CAPIF core function in CAPIF interconnection; and

[0132] m. Supports slice related API exposure in, e.g., API publish, API discovery, API invoker authorization, and API access control.

[0133] API Exposing Function (AEF):The API exposing function is a provider of the service APIs (104a, 104b) and is also the service communication entry point of service API (104a, 104b) to the API invokers (102). The API exposing function consists of the following capabilities:

[0134] a. Authenticating the API invoker (102) based on the identity and other information required for authentication of the API invoker (102) provided by the CAPIF core function (202a, 202b);

[0135] b. Validating authorization provided by the CAPIF core function (202a, 202b);

[0136] c. Logging the service API invocations at the CAPIF core function (202a, 202b); and

[0137] d. Hiding topology of the PLMN trust domain from the API invokers (102), depending on a configured policy.

[0138] The existing CAPIF procedures supporting interconnection are described in 3rdGeneration Partnership Project (3GPP)　Technical Specification (TS)　23.222 which includes service API publish, retrieval, update, unpublish and discovery over a CAPIF-6 / 6e reference point.

[0139] FIG. 2 is an example architecture depicting, the API provider domain functions registered in the CCF (202a, 202b) within the same trusted domain (such as, trust domain of first CAPIF provider (say, domain-A)) (106a). Multiple CCFs (202a, 202b) of different trust domains are connected via CAPIF-6e (when CCFs (202a, 202b) are in different CAPIF provider domain) (106b), in order to share service APIs (104a, 104b). API provider domain functions (e.g. AEF, Application publishing function, API management function) don't see the interconnected CCF in another domain, but the API provider domain function such as AEF of trust domain A, is able to provide AEF service APIs to the API invoker (102) onboarded in the CCF (202b) in a second trust domain (say, domain-B) via a CAPIF-2e interface.

[0140] As illustrated in the FIG. 2, an AEF (302) (as shown in FIG. 3) and / or the CCF (202b) of the second trust domain (domain B) needs to authenticate and authorize the API access (together with the CCF (202b) in the domain-B). The API invoker (102) obtains authorization from CCF (202a) in the first domain (i.e., domain A) for achieving API services through the AEF (302) of the trust domain (i.e. domain A). But an CAPIF interconnection framework does not communicate with the interconnected CCF in the CAPIF provider domain (i.e., first CCF (202a)), but still needs to be able to provide the AEF service APIs to the API invoker (102a) onboarded at the first CCF (202a).

[0141] The embodiments herein achieve methods and system for handling an API access in a CAPIF interconnection in the wireless network. The wireless network can be, for example, but not limited to a fourth generation (4G) network, a fifth generation (5G) network, a sixth generation (6G) network or the like.

[0142] Embodiments herein disclose an AEF authenticating and authorizing an API invoker (102) requesting service APIs (as the API invoker (102) is registered to a first CCF (202a) in a first domain). Embodiments herein disclose a second CCF (202b) validating the API invoker (102) requesting the service APIs (104a, 104b) in the second domain.

[0143] Embodiments herein disclose the API invoker (102) being provided with the selected security method by the AEF (302) by the first CCF (202a) to which API invoker (102) is onboarded (in same domain / different domain). Embodiments herein disclose that the API Invoker ID includes the information of the domain (for example, Domain A) it on-boarded, which will be used by the AEF (302) / CCF or any other entitled entity in the domain B to resolve the IP address of the on-boarded CCF (in the first domain).

[0144] Embodiments herein disclose that API Invoker ID provides the information of the CCF (for example, Domain A) to the AEF (302) and / or CCF in Domain B which will be used by the AEF (302) / CCF or the entity in the domain B to reach the CCF in the first domain.

[0145] The summary of the present invention:

[0146] a. The API invoker (102) (onboarded to the first CCF (202a)) and the AEF (302) (registered to the second CCF (202b)) should perform mutual authentication and authorization before providing access to service APIs (104a, 104b). In this proposal it is proposed that the first CCF (202a) generates and provides the PSK / root certificate to the second CCF (202b) for the service API (104a, 104b) supported by AEF (302) in the second CCF (202b).

[0147] b. The API invoker (102) / the first CCF (202a), based on the AEF details, determines that the requested service APIs (104a, 104b) are provided by the AEF (302) in the second CCF (202b) either during security method negotiation or authentication and authorization between the API invoker (102) and the AEF (302) by a (first security technique (using TLS-PSK), a second security technique (Using PKI) and a third security technique as specified in TS 33.122).

[0148] c. The second CCF (202b) provides the selected security method(s) to the API invoker (102) via the first CCF (202a).

[0149] d. When the AEF (302) receives the authentication initiation request message from the API invoker (102), the API invoker (102) should include the first CCF identity information in the request message so that the second CCF (202b) can contact the right first CCF (i.e., API invoker (102) onboarded one).

[0150] e. The first CCF (202a) selects the appropriate security materials based on the received API invoker ID, the AEF details, and the service API information and provides it to the AEF (302) via the second CCF (202b).

[0151] f. The first CCF (202a) selects the appropriate security materials based on the received API invoker ID, the AEF details, and the service API information and provides it to the AEF (302) via the second CCF (202b).

[0152] The proposed method facilitates secure service API access by the API invoker in different security domains. As the API invoker is onboarded in the first domain (i.e., domain A) and the service API is provided by exposure function in the second domain (i.e., domain B), it is necessary that the mutual authentication takes place between the API invoker and the AEF same as existing state of art. But since the API invoker is not authenticated by the CCF in the second domain security material generation and distribution between the first domain and the second domain as described in this invention is required to secure service API access.

[0153] Referring now to the drawings, and more particularly to FIGS. 3 through 13, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0154] FIG. 3 is the sequence diagram depicting an authentication and authorization procedure during CAPIF Interconnect in a wireless network 1000, according to embodiments as disclosed herein.

[0155] At step 1, a CAPIF-1e authentication and secure session is established between an API invoker (102) and a first CAPIF core function (or first CCF) (202a) in a first trust domain of a CAPIF provider (trust domain-A) (106a). In an example embodiment herein, the first CCF (202a) provides a validity timer value for a key AEFPSKfor secure access to APIs in the first CCF (202a). After a successful establishment of a Transport layer security (TLS) on the CAPIF-1e, the API invoker (102) and the first CCF (202a) derives a key AEFPSK.

[0156] At step 2a-2b, the Key AEFPSKis bound to an AEF (302) in the trust domain-A (i.e., first domain). The API invoker (102) and the CAPIF core function (202a) starts the validity timer for the key AEFPSK. In an embodiment herein, an API provider of the different trust domain (i.e., domain B in which API invoker (102) is not onboarded) pre-provisions required security materials and / or the security methods (or security techniques) supported and / or selected by the AEF (302) in trust domain B.

[0157] In an embodiment herein, the API invoker (102) is already in possession of the security materials for the AEF supported, and / or selected security methods, before initiating step 3 as part of the API provider pre-provisioning. In an embodiment, the pre-provisioning can happen as part of API invoker pre-provisioning of onboard related information.

[0158] At step 3, the API invoker (102) sends an authentication initiation request to the AEF (302) in the trust domain-B (i.e., second trust domain), where the request includes corresponding to the first CCF (202a), a CAPIF core function assigned API invoker ID and CCF identity information. At step 4, the AEF (302) checks for a valid key material (or valid security information), when the AEF (302) possesses the valid key material. When the AEF (302) does not possess the valid key material, the AEF (302) requests for security information from the second CAPIF Core Function (CAPIF Core Function-B) 306 to perform authentication and secure interface establishment with the API invoker (102). In an embodiment herein, as the API invoker (102) is registered to different trust domain (domain A), the AEF (302) includes at least one of: API invoker Id, a first CCF identity information, service APIs (shareable service APIs) (104a, 104b), AEF identity information and other possible parameters in the request to the second CCF (202b).

[0159] In an embodiment, the API invoker ID should indicate the CCF identity information in which the API invoker (102) is onboarded or registered in order for the second CCF (202b) in the second trust domain (i.e., trust domain B) to reach out to the first CCF (202a) in the first trust domain (i.e., trust domain A) when at least one of: the AEF (302) and / or the second CCF (202b), receives the authentication initiation request from the API invoker (onboarded in domain A) (102).

[0160] At step 5, the second CCF (202b) checks (or determines) for the stored information on the shareable APIs based on the CCF identity information and received API invoker identity, as the API invoker (102) is from different trust domain does not have the required security materials. At step 6, the second CCF (202b) requests for security information from the first CCF (202a), to perform authentication and secure interface establishment between the API invoker (102) and the AEF (302). In an embodiment herein, the AEF (302) includes the security method selected by it in the request message to the second CCF (202b).

[0161] In an embodiment herein, the AEF (302) includes in the request message to the second CCF (202b), at least one of: an API invoker ID of the API invoker (102), the first CCF identity information, the service API (104a, 104b) requested by the API invoker or service API supported by the API invoker (102), AEF identity information, and at least one security method selected and / or supported by the AEF (302).

[0162] At step 7, the first CCF (202a) authorizes the second CCF (202b) and the AEF (302), where the AEF (302) is requesting to, the first CCF (202a), a security material based on stored CAPIF interconnect API publish information for authorization. In an embodiment, the first CCF (202a) checks if it has the service level agreement with the second domain (i.e., domain B) for the authorization. In an embodiment, the first CCF (202a) authorizes the AEF (302) requesting the security material based on at least one of information provided by the API invoker (102) during security method negotiation and / or selection procedure i.e., each AEF identity information along with the service APIs (104a, 104b) supported or service APIs (104a, 104b) to which it needs the access.

[0163] At step 8, the first CCF (202a) retrieves an AEFPSKand / or a root certificate of a Certificate Authority (CA) and other possible security materials required to validate the API invoker (102) based on the received API invoker Identity. At step 9, the first CCF (202a) provides the security information related to a chosen security method (TLS-PSK: AEFPSKor the root certificate of the CA to validate the API invoker (102)) to the AEF (302), over a CAPIF-3 reference point.

[0164] At steps 10-11, after fetching relevant security information for authentication, the AEF (302) sends an authentication initiation response message to the API invoker (102) to initiate a TLS session establishment.

[0165] The API Invoker (102) and the AEF (302), performs mutual authentication using the key AEFPSKand / or the root certificate of the CA in order to establish the TLS session over the CAPIF-2e. After successful establishment of the TLS on CAPIF-2e reference point, the API exposing function authorizes the API invoker's service API invocation request based on authorization information obtained from CAPIF core function.

[0166] AEF supported security method selection when API invoker and AEF is in different trust domain:

[0167] FIG. 4 depicts the procedure for retrieving, by the API invoker (102), the AEF details from the second trust domain (i.e., trust domain B) of the CAPIF provider (106b), according to embodiments as disclosed herein.

[0168] At step 1, mutual authentication based on a client and a server certificates shall be established using TLS between the API invoker (102) and the CAPIF core function-A (first CCF) (202a). In an example embodiment, the client can be without limitation a UE, registered with CAPIF provider of first trust domain of CAPIF provider (trust domain-A) (106a), where the server is associated with a second trust domain of CAPIF provider (trust domain-B) (106b).

[0169] At step 2, the API invoker (102) sends CAPIF-2 / 2e security capability information to the first CCF (202a), in a security technique request message, indicating a list of security methods that the API invoker (102) supports over the CAPIF-2 / 2e reference point, the service APIs (104a, 104b), it wants to access with the AEF identity information.

[0170] In an embodiment herein, an API Invoker ID is included in the request message that provides the information of the first CCF (202a) (for example, Domain A IP address / fully qualified domain name (FQDN)) to the second CCF (202b). In an embodiment herein, the AEF identity information included in the request message indicates the information of the second CCF (202b) (for example Domain B IP address / FQDN) for the first CCF (202a), to determine and identify the requested service APIs (104a, 104b) are exposed by an AEF (302), in domain B (different trust domain).

[0171] At step 3, the first CCF (202a) determines that the service APIs (104a, 104b) requested by the API invoker (102) is provided by the AEF (302) in second CCF (another trust domain-B) (202b). The CCFs (202a and 202b) in different domains must establish a trust relationship, often based on a federation agreement. This agreement outlines trust anchors, accepted certificates, and techniques for verifying tokens or credentials.

[0172] At step 4, the first CCF (202a) determines to publish the service API or the service API category information to the second CCF (202b) based on the shareable information for the service API (104a, 104b) or the service API category information. The first CCF (202a) sends an interconnection API publish request to the second CCF (202b), with the details of at least one of API invoker ID, service APIs (104a, 104b) or category information of the service APIs (104a, 104b); along with the identity information of the second CCF (202b), shareable information and CAPIF provider domain information when allowed to share, and AEF identity information.

[0173] At step 5, the second CCF (202b) selects a security method to be used over the CAPIF-2 / 2e reference point for each requested AEF, taking into account the information from the API invoker (102) and / or first CCF (202a), and the AEF capabilities. In an embodiment herein, the second CCF (202b) authorizes the request based on the service level agreement between the first trust domain (i.e., trust domain A) and the second trust domain (i.e., trust domain B). In an embodiment herein, security token as described in one of the embodiments herein is sent in the CAPIF Interconnect API publish request and / or Interconnect service API requests. The security materials to verify the token is provided to the second CCF (202b) as part of the service level agreement.

[0174] At step 6, the second CCF (202b), provides the interconnection API publish response to the first CCF (202a), indicating success or failure result and triggers notifications to subscribed API invokers (102). In an embodiment herein, the first CCF (202a) provides the shareable APIs, AEF identity information to the second CCF (202b) along with the selected security method and security information based on the selected security method for each service APIs (104a, 104b) requested from the AEF (302) in trust domain B.

[0175] At step 7, the first CCF (202a) sends the Security Method Response message to the API invoker (102), indicating the selected security method for each AEF (302) in the domain B as per the request and the security information related to the security method. The API invoker (102), uses this method in the subsequent communication establishment with the API exposing function over CAPIF-2 / 2e reference point.

[0176] FIG. 5A is a block diagram of the API invoker (102) running in a UE or a server (500A), for handling the API access in the CAPIF interconnection in a wireless network, according to embodiments as disclosed herein.

[0177] The UE or the server (500a) includes the API invoker (102), a processor (510a), a communicator (520a), a memory (530a) and a service API access handling controller (540a). The processor (510a) is coupled with the API invoker (102), the communicator (520a), the memory (530a) and the service API access handling controller (540a).

[0178] The API access handling controller (540a) sends a security technique request to the first CCF (202a). In an embodiment, the security technique request includes the API invoker identity, the at least one AEF detail, the at least one security technique, the security capability information and the CCF identity information. In an embodiment herein, the API invoker (102) communicates with the first CCF (202a) in the first domain and the AEF (302) and the second CCF (202b) in the second domain.

[0179] Further, the service API access handling controller (540a) can receive the security technique response from the first CCF (202a) based on the security technique request. The security technique response includes the at least one AEF detail, the selected security technique and the security information comprising the valid security information. In an embodiment herein, the valid security information comprises at least one of: AEFPSK, and a root certificate of a CA. In an example, for a TLS PSK security information, the valid key is AEFPSK.For TLS cert based authentication, the security information is root CA certificate. In an embodiment herein, the API invoker (102), can receive an authentication initiation response message, when the AEF (302) has the valid security information.

[0180] In an embodiment herein, the service API access handling controller (540a) can send the authentication initiation request to the AEF (302). The authentication initiation request includes at least one of: the CCF assigned API invoker ID and the CCF identity information. Further, the API access handling controller (540a) can receive an authentication initiation response message from the AEF (302) to initiate the secure session establishment based on the authentication initiation request. The service API access handling controller (540a) further can initiate the secure session establishment among the API invoker (102), the AEF (302), the first CCF (202a) and the second CCF (202b).

[0181] The API access handling controller (540a) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0182] Further, the processor (510a) is configured to execute instructions stored in the memory (530a) and to perform various processes. The communicator(520a) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (530a) also stores instructions to be executed by the processor (510a). The memory (530a) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (530a) may, in some examples, be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted that the memory (530a) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0183] Although the FIG. 5A shows various hardware components of the UE or the server (500) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the UE or the server (500) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the UE or the server (500).

[0184] FIG. 5B is the block diagram of the AEF (302) for handling the API access in the CAPIF interconnection in the wireless network (1000), according to embodiments as disclosed herein. In an embodiment, the AEF (302) includes a processor (510b), a communicator (520b), a memory (530b), and a service API access handling controller (540b). The processor (510b) is coupled with the communicator (520b), the memory (530b), and the service API access handling controller (540b).

[0185] In an embodiment herein, the service API access handling controller (540b) can receive the authentication initiation request from the API invoker (102). The authentication initiation request includes at least one of: the CCF assigned API invoker ID and the CCF identity information. In an embodiment, the API invoker (102) communicates with the first CCF (202a) in the first domain and the AEF (302) communicates with the second CCF (202b) in the second domain. Further, the service API access handling controller (540b) can receive the authentication initiation response message from the API invoker (102) to initiate the secure session establishment based on the authentication initiation request.

[0186] The API access handling controller (540b) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0187] Further, the processor (510b) is configured to execute instructions stored in the memory (530b) and to perform various processes. The communicator(520b) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (530b) also stores instructions to be executed by the processor (510b). The memory (530b) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (530b) may, in some examples, be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted that the memory (530b) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0188] Although the FIG. 5B shows various hardware components of the AEF entity (302) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the AEF entity (302) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the AEF entity (302).

[0189] FIG. 5C is the block diagram of the first CCF (202a) for handling the API access in the CAPIF interconnection in the wireless network (1000), according to embodiments as disclosed herein. In an embodiment, the CCF (202a) includes a processor (510c), a communicator (520c), a memory (530c), and a service API access handling controller (540c). The processor (510c) is coupled with the communicator (520c), the memory (530c), and the service API access handling controller (540c).

[0190] In an embodiment herein, the service API access handling controller (540c) can receive a security technique request from the API invoker (102). The security technique request comprises the API invoker identity, the at least one AEF detail, the at least one security method, the security capability information and the CCF identity information. Further, the service API access handling controller (540c) can send the security technique response to the API invoker (102) based on the security technique request. The security technique response includes the at least one AEF detail, the selected security technique and the security information comprising the valid security information.

[0191] The API access handling controller (540C) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0192] Further, the processor (510C) is configured to execute instructions stored in the memory (530C) and to perform various processes. The communicator(520C) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (530C) also stores instructions to be executed by the processor (510C). The memory (530C) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (530C) may, in some examples, be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted that the memory (530C) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0193] Although the FIG. 5C shows various hardware components of the first CCF (202a) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the first CCF (202a) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the first CCF (202a).

[0194] FIG. 5D is the block diagram of the second CCF (202b) for handling the API access in the CAPIF interconnection in the wireless network (1000), according to embodiments as disclosed herein. The second CCF (202b) includes a processor (510d), a communicator (520d), a memory (530d), and a service API access handling controller (540d). The processor (510d) is coupled with the communicator (520d), the memory (530d), and the service API access handling controller (540d).

[0195] In an embodiment herein, the service API access handling controller (540d) can receive the security information request from the AEF (302) to perform authentication and secure interface establishment with the API invoker (102) upon determining that the AEF (302) does not have the valid security information for authentication. Further, the service API access handling controller (540d) can send the security information request to the first CCF (202a) to perform authentication and secure interface establishment between the API invoker (102) and the AEF (302). Further, the service API access handling controller (540d) can share the valid security information in a response corresponding to the security information request to the AEF (302) through the first CCF (202a) via the interface.

[0196] The API access handling controller (540d) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0197] Further, the processor (510D) is configured to execute instructions stored in the memory (530D) and to perform various processes. The communicator(520D) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (530D) also stores instructions to be executed by the processor (510D). The memory (530D) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (530D) may, in some examples, be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted that the memory (530D) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0198] Although the FIG. 5D shows various hardware components of the second CCF (202b) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the second CCF (202b) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the second CCF (202b).

[0199] FIG. 6 is the flow diagram 6000 of a method implemented, by the API invoker (102), for handling the API access in the CAPIF interconnection in the wireless network (1000), according to embodiments as disclosed herein.

[0200] At step 602, the method includes sending the authentication initiation request to the AEF (302). The authentication initiation request includes at least one of: the CCF assigned API invoker ID and the CCF identity information. In an embodiment herein, the security information request includes at least one of: the CCF assigned API invoker ID, the CCF identity information, at least one shareable service API, the AEF identity information. The API invoker (102) communicates with the first CCF entity (202a) in the first domain and the AEF entity (302) communicates with the second CCF entity (202b) in the second domain

[0201] At step 604, the method comprises receiving the authentication initiation response message from the AEF (302) to initiate the secure session establishment based on the authentication initiation request. At step 606, the method comprises, initiating the secure session establishment among the API invoker (102), the AEF (302), the first CCF (202a) and the second CCF (202b).

[0202] FIG. 7 is the flow diagram 7000 depicting a method for security negotiation between the API invoker (102) and the AEF (302), for handling the API access in the CAPIF interconnection in the wireless network (1000), according to embodiments as disclosed herein.

[0203] At step 702, the method includes sending, by the API invoker (102), the security technique request to the first CCF (202a). The security technique request includes the API invoker identity, the at least one AEF detail, the at least one security technique, the security capability information and the CCF identity information. The API invoker (102) communicates with the first CCF (202a), in the first domain and the AEF entity (302) and the second CCF (202b) in a second domain.

[0204] At step 704, the method comprises receiving, by the API invoker (102), the security technique response from the first CCF (202a) based on the security technique request, wherein the security technique response comprises the at least one AEF detail, a selected security technique and security information comprising the valid security information.

[0205] FIG. 8 is the flow diagram 8000 depicting a method, implemented by an AEF (302), for handling the API access in the CAPIF interconnection in the wireless network (1000), according to embodiments as disclosed herein.

[0206] At step 802, the method comprises, receiving the authentication initiation request from the API invoker (102). In an embodiment herein, the authentication initiation request includes at least one of: the CCF assigned API invoker ID and the CCF identity information, where the API invoker communicates with a first CCF (202a) in a first domain and the AEF (302) communicates with a second CCF (202b) in a second domain.

[0207] At step 804, the method comprises receiving the authentication initiation response message from the API invoker (102), to initiate the secure session establishment based on the authentication initiation request.

[0208] FIG. 9 is the flow diagram 9000 depicting the method implemented by the first CCF (202a), for handling the API access in the CAPIF interconnection in the wireless network (1000), according to embodiments as disclosed herein.

[0209] At step 902, the method comprises, receiving the security technique request from the API invoker (102). In an embodiment herein, the security technique request comprises the API invoker identity, the at least one AEF detail, the at least one security method, the security capability information and the CCF identity information. At step 904, the method comprises, sending the security technique response to the API invoker (102) based on the security technique request, wherein the security technique response comprises the at least one AEF detail, the selected security technique and security information comprising the valid security information.

[0210] FIG. 10 is the flow diagram 10000 depicting the method, implemented by the first CCF (202a), for security negotiation between the PAI invoker 302 and the AEF (302), according to embodiments as disclosed herein.

[0211] At step 1002, the method includes receiving the security information request from the second CCF (202b), to perform authentication and secure interface establishment between the API invoker (102) and the AEF (302). In an embodiment herein, the first CCF (202a) retrieves the valid security information to validate the API invoker (102) based on a received API invoker identity, wherein the API invoker (102) communicates with the first CCF (202a) in the first domain and the AEF (302) communicates with the second CCF (202b) in a second domain. In an embodiment herein, the valid security information comprises at least one of: AEFPSK, and a root certificate of a CA. At step 1004, the method comprises, providing, by the first CCF 304, the valid security information in a response corresponding to the security information request to the AEF (302) through the second CCF (202b) via the interface.

[0212] FIG. 11 is the flow diagram 1100 depicting the method, implemented by the second CCF (202b), for security negotiation between the PAI invoker 302 and the AEF (302), according to embodiments as disclosed herein.

[0213] At step 1102, the method comprises receiving, by the second CCF (202b), the security information request from the AEF (302) to perform authentication and secure interface establishment with the API invoker (102), upon determining that the AEF (302) does not have the valid security information. In an embodiment herein, the API invoker (102) communicates with the first CCF (202a) in the first domain and the AEF (302) communicates with the second CCF (202b) in the second domain.

[0214] At step 1104, the method comprises, sending, by the second CCF (202b), the security information request to the first CCF (202a), to perform authentication and secure interface establishment between the API invoker (102) and the AEF (302). At step 1106, the method comprises sharing the valid security information in a response corresponding to the security information request to the AEF entity through the first CCF via an interface.

[0215] CAPIF interconnect API publish:

[0216] FIG. 12 depicts a procedure for CAPIF Interconnect API publish, according to embodiments as disclosed herein.

[0217] FIG. 12 depicts the method 3000S for publishing API for CAPIF Interconnect according to embodiments as disclosed herein. The plurality of CCFs (202a, 202b) of different domains is establishing a trust relationship. The trust relationship is often based on a federation agreement. This agreement outlines trust anchors, accepted certificates, and techniques for verifying tokens or credentials. A second CAPIF core function (CAPIF Core Function-B) 306 in a second trust domain of CAPIF provider (trust domain B) (106b) can share service APIs (104a, 104b) with a first CCF (202a), from the API publish function of the trust domain-B.

[0218] At step 1, the second CCF (202b) determines to publish the service API (104a, 104b) or service API category information to the first CCF (202a), based on the shareable information for the service APIs (104a, 104b) or the service APIs category information. The second CCF (202b) sends the interconnection API publish request to the first CCF (202a) with the details of: at least one of service APIs (104a, 104b) and the category information of the service APIs (104a, 104b). Further, the interconnection API publish request includes, identity information of the second CCF (202b), shareable information, CAPIF provider domain (trust domain-B) information when allowed for sharing with the first CCF (202a), and AEF identity information.

[0219] In an embodiment herein, at least one of the first CCF (202a) and the second CCF (202b) initiates a CAPIF interconnect API request when an API invoker (102) requests for the AEF supported security techniques, wherein the API invoker (102) is onboarded to the first CCF (202a) in its domain A.

[0220] In an embodiment herein, during a CAPIF interconnect API request or response procedure, the API invoker (102) requesting for at least one service API (104a, 104b) in CAPIF interconnect is provided with the supported security method of AEF onboard to the second CCF (202b), and required security material for the authentication and authorization.

[0221] In an embodiment herein, the first CCF (202a) and the second CCF (202b) during the CAPI interconnect request or response procedure, shares AEF identity details, as part of the information related to sharable service APIs (104a, 104b), wherein the AEF identity details include, CCF identity information (IP address, FQDN like so) which is used to identify the trust domain of the AEF (302), corresponding to the second CCF (202b).

[0222] In an embodiment herein, the CAPIF interconnect API request or response procedure is triggered on demand i.e., whenever the API invoker (102) in trust domain-A, initiates the authentication request with the AEF (302) in trust domain-B.

[0223] At step 2, the first CCF (202a) stores the service API information or service API category provided by the second CCF (202b). In an embodiment herein, the service API information includes at least one of, Service API (104a, 104b):AEF (mapping of the service API (104a, 104b) provided by an AEF), Service API:AEF: CCF identity information, Service API:AEF: CCF identity information of its own domain: CCF identity information of a visited domain (i.e., a domain to be visited to get service APIs).

[0224] At step 3, the first CCF (202a), provides a response to the second CCF (202b), wherein the response comprises at least one of: an interconnection API publish response, and a CAPIF interconnect service API response to the FIRST CCF indicating success or failure result and triggers notifications to subscribed API invokers (102).

[0225] In an embodiment herein, the first CCF (202a) can provide provides the shareable APIs AEF identity information to the second CCF (202b), in the response.

[0226] In an embodiment herein, the first CCF (202a) provides its own supported service API information in the response. In an embodiment herein, the service API information includes at least one of: Service API:AEF (mapping of the service API provided by an AEF), Service API: AEF: CCF identity information, Service API:AEF: CCF identity information of its own domain: CCF identity information of the visited domain (to be visited to get service APIs).

[0227] Authentication and authorization procedure during a CAPIF Interconnect:

[0228] FIG. 13 is the sequence diagram 3000S depicting, authentication and authorization procedure during a CAPIF Interconnect, according to embodiments as disclosed herein.

[0229] At step 1, CAPIF-1e authentication and secure session establishment is performed between an API Invoker (102) and the first CCF (202a). At step 2, after successful establishment of the TLS session over CAPIF-1e the API invoker (102), sends a CAPIF interconnect token request message to the first CCF (202a).

[0230] At step 3, the first CCF (202a) verifies the Access Token Request message per OAuth 2. At step 4, if the first CCF (202a) successfully verifies the request message, the first CCF (202a), generates an access token specific to the API invoker (102) and return it to the API invoker (102), in an Access Token Response message.

[0231] At step 5, on CAPIF-2e, the API invoker (102) authenticates to the AEF (302), by establishing a TLS session with the AEF (302) based on the authentication and authorization method (i.e. Server (AEF) side certificate authentication or certificate-based mutual authentication) as indicated by the first CCF (202a). The following procedure shall be performed prior to establishment of TLS session.

[0232] At step 6, with successful authentication to the AEF (302), on CAPIF-2e, the API invoker (102) shall initiate invocation of a 3GPP northbound API with the AEF (302). The security token received from the first CCF (202a) shall be sent along with the northbound API invocation request as per OAuth 2.0.

[0233] At step 7, the AEF (302) validates the security token. The AEF (302) verifies the integrity of the token by verifying a CAPIF core function signature.

[0234] In an embodiment herein, the AEF (302), is provided with the required security materials for verification by the first CCF (202a) via the second CCF (202b).

[0235] In an embodiment herein, in case of interconnection the AEF (302) requests the second CCF (domain B) (202b), to verify the security token. The second CCF (202b) is in possession of the required security material to verify the security token which was assigned to the API invoker (102) by the first CCF (202a).

[0236] If validation of the security token is successful, the AEF (302) verifies the API invoker's Northbound API invocation request against the authorization claims in the security token, ensuring that the API Invoker has access permission for the requested service API (104a, 104b).

[0237] In an embodiment herein, table 1 describes the security token in case of CAPIF interconnection:

[0238] ParameterDescriptionexpREQUIRED. The expiration time of the access token. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew (not to exceed 30 seconds).client_idREQUIRED. The identifier of the API Invoker making the API request as previously established with the CAPIF Core Function through onboarding.issREQUIRED. The CCF identity information required to validate the authenticity of the issuerscopeREQUIRED. A string containing a space-delimited list, comprising of the following as scopes associated with this token:- List of Services per AEF (e.g. "AEF1:Service1,Service2,Service3,...,ServiceX;AEF2:Service1,Service2,Service3,...,ServiceZ")- List of Sharable services per AEF (e.g. "AEF1:Service1,Service2,Service3,...,ServiceX;AEF2:Service1,Service2,Service3,...,ServiceZ")

[0239] In an embodiment herein, in the CAPIF interconnect scenario, the API invoker ID is associated with the second CCF (202b); i.e., when the API invoker (102) onboards the first CCF (202a), the first CCF (202a), assigns two API invoker ID:

[0240] a. API invoker ID-A - To be used within the same trust domain, and

[0241] b. API invoker ID-B - To be used in trust domain B

[0242] In an embodiment herein, the same API invoker ID-B to be used by the API invoker (102) to access all the shareable service APIs (104a, 104b) provided by the AEFs in different trust domain.

[0243] In an embodiment herein, the first CCF (202a) assigns unique API invoker ID for the API invoker (102) to be identified distinguishly in each trust domain.

[0244] At step 8, after successful verification of the security token and authorization claims of the API invoker 302, the requested northbound API is invoked.

[0245] FIG. 14 is a block diagram of a terminal or user equipment (UE) 1400 according to an embodiment of the disclosure. The UE of Fig.14 corresponds to the UE of FIG. 5a.

[0246] The terminal is an electronic device capable of wireless communication, may include a User Equipment (UE), a portable phone, a smartphone, a tablet, an Internet of things (IoT) device, etc., having various form factors, and may perform wireless communication with a base station (BS) through a wireless channel.

[0247] Referring to FIG. 14, the UE 1400 may include at least one transceiver (hereinafter, referred to as simply “transceiver”) 1401, at least one processor (hereinafter, referred to as simply “processor”) 1402, and at least one memory (hereinafter, referred to as simply “memory”) 1403. According to at least one or a combination of methods corresponding to the embodiments described in the present disclosure, the transceiver 1401, the processor 1402, and the memory 1403 of the UE 1400 may operate. However, components of the UE 1400 are not limited to the exemplary components illustrated in FIG. 14. In another embodiment, the UE 1400 may further include additional components in addition to the above-mentioned components, or some components may be omitted. Further, in some embodiments, any combination of the transceiver 1401, the processor 1402, or the memory 1403 may be integrated in the form of one component.

[0248] The transceiver 1401 may be a communication circuit or communication circuitry that enables the UE 1400 to perform wireless communication with a node or an entity of a network. For example, the transceiver 1401 may enable the UE 1400 to transmit or receive a signal to or from a BS through cellular communication, or to transmit or receive a signal to or from another UE through cellular communication. For example, the transceiver 1401 may support at least one of various cellular communication technologies including 3rd generation (3G), 4th generation (4G), long term evolution (LTE), 5th generation (5G) NR, 6th generation (6G), and various cellular wireless communication technologies supported by the transceiver (1401) may include all subsequent generations of evolved wireless communications.

[0249] According to an embodiment, the UE 1400 may include a plurality of transceivers. For example, in the case of supporting evolved-universal terrestrial radio access-new radio (E-UTRA-NR) sual connectivity (EN-DC), the UE 1400 may include a first transceiver supporting the 4G LTE wireless communication and a second transceiver supporting the 5G NR wireless communication. According to another embodiment, in the case of supporting NR-dual connectivity (NR-DC), the UE 1400 may include a plurality of transceivers supporting the 5G NR wireless communication. According to still another embodiment, in the case of supporting near field wireless communication, the UE 1400 may separately include a transceiver supporting at least one standard in the group of wireless communication protocol standards as defined in the protocol standards for Bluetooth®, wireless local area network (WLAN) network (including institute of electrical and electronics engineers (IEEE) 802.11-2016 standard or its amendments, e.g., 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be, without being limited thereto).

[0250] According to an embodiment, the transceiver 1401 may include various circuit structures used to transmit or receive signals to or from a BS through a wireless channel. The signals may include control information and data. For example, the transceiver 1401 may include a radio frequency (RF) transmitter for up-converting and amplifying the frequency of a transmitted signal and an RF receiver for low-noise-amplifying a received signal and down-converting the frequency thereof. The transceiver 1401 may output a signal received through a wireless channel to the processor 1402 and may transmit, through a wireless channel, a signal output from the processor 1402.

[0251] The processor 1402 may control general operations of the UE 1400 according to embodiments of the disclosure. The processor 1402 may be implemented by one or more integrated circuit (or circuitry) (IC) chips and may execute various data processings. The processor 1402 may include at least one electric circuit, and may execute instructions (or a program, codes, data, etc.) stored in the memory 1403, individually, collectively or in any combination thereof. Further, the processor 1402 may include a single-core processor or multi-core processor, and may include a processor assembly including a plurality of processing circuits (circuitry) according to a specific implementation scheme.

[0252] The processor 1402 may be electrically, operatively, or communicatively coupled to the transceiver 1401 to control the transceiver 1401.

[0253] The processor 1402 may include at least one processor (or processing circuitry), and the at least one processor may perform the following operations individually, collectively or in any combination thereof. For example, the processor 1402 may include a communication processor (CP) configured to control communication operations and an application processor (AP) configured to control execution of an upper layer (for example, an application layer) . In a specific embodiment, at least a part of the processor 1402 may be included in one chip and the other part of the processor 1402 may be included in another chip. Otherwise, at least one processor may be included in another component, for example, the transceiver 1401 or the memory 1403.

[0254] The processor 1402 may perform or control or cause an operation of the UE 1400 for executing at least one or a combination of methods according to embodiments of the disclosure. For example, the processor 1402 may control operations of the UE 1400 for processing a downlink signal received from a BS or generating and transmitting an uplink signal to a BS. To this end, the processor 1402 may execute a computer program, codes, or instructions stored in the memory 1403, so as to control other components of the UE 1400 to enable execution of various operations.

[0255] The memory 1403 corresponds to a hardware storage device capable of temporarily or permanently storing information and may include one or more storage media. For example, the memory 1403 may include a memory assembly including one or more storage media. For example, the one or more storage media may include permanent memory, such as a hard drive, flash memory, or read-only memory (ROM), semipermanent memory, such as random access memory (RAM), cache memory, or a combination thereof.

[0256] The memory 1403 may be electrically, operatively, or communicatively coupled to the processor 1402 and may be accessed by the processor 1402.

[0257] The memory 1403 may store a computer program, codes, or instructions executable by the processor 1402. According to an embodiment, a computer program, codes, or instructions executable by the processor 1402 may be either stored in a single memory device or separated and distributedly stored in two or more memory devices. By executing the instructions stored in the memory 1403, the processor 1402 may perform various functions according to an embodiment of the disclosure.

[0258] According to an embodiment of the disclosure, operations of the UE 1400 may be caused to be performed based on execution of instructions (or a computer program or codes) stored in the memory 1403 by at least one processor (or processing circuitry) configured to execute the same individually, collectively, or in any combination thereof, based on processing circuitry that is not configured to execute instructions, and / or based on components of processing circuitry that is not configured to execute instructions.

[0259] FIG. 15 is a block diagram of a base station (BS) 1500 according to an embodiment of the disclosure.

[0260] The BS 1500 may perform wireless communication with at least one user equipment (UE) located within the area of the BS 1500 through a wireless channel.

[0261] Referring to FIG. 15, the BS 1500 may include at least one transceiver (hereinafter, referred to as simply “transceiver”) 1501, at least one processor (hereinafter, referred to as simply “processor”) 1502, and at least one memory (hereinafter, referred to as simply “memory”) 1503. According to at least one or a combination of methods corresponding to the embodiments described in the present disclosure, the transceiver 1501, the processor 1502, and the memory 1503 of the BS 1500 may operate. However, components of the BS 1500 are not limited to the exemplary components illustrated in FIG. 15. In another embodiment, the BS 1500 may further include additional components in addition to the above-mentioned components, or some components may be omitted. Further, in some embodiments, any combination of the transceiver 1501, the processor 1502, or the memory 1503 may be integrated in the form of one component.

[0262] The transceiver 1501 may be a communication circuit or communication circuitry that enables the BS 1500 to perform wireless communication with a node or an entity of a network. For example, the transceiver 1501 may enable the BS 1500 to transmit or receive a signal to or from the UE 1400 through cellular communication, or to transmit or receive a signal to or from another network entity through wireless communication. For example, the transceiver 1501 may support various cellular communication technologies including 3rd generation (3G), 4th generation (4G), long term evolution (LTE), 5th generation (5G) NR, 6th generation (6G), and various cellular wireless communication technologies supported by the transceiver (1501) may include all subsequent generations of evolved wireless communications. According to an embodiment, the transceiver 1501 may include various circuit structures used to transmit or receive signals to or from a UE through a wireless channel. The signals may include control information and data. For example, the transceiver 1501 may include a radio frequency (RF) transmitter for up-converting and amplifying the frequency of a transmitted signal and an RF receiver for low-noise-amplifying a received signal and down-converting the frequency thereof. The transceiver 1501 may output a signal received through a wireless channel to the processor 1502 and may transmit, through a wireless channel, a signal output from the processor 1502.

[0263] Meanwhile, according to an embodiment of the present disclosure, the BS 1500 may perform communication with a node or an entity of a network through wired or wireless communication. For example, the BS 1500 may perform wired or wireless communication with an adjacent BS, or a node or an entity of a core network through a backhaul network. Although not illustrated in FIG. 15, when the BS 1500 performs wired communication, the BS 1500 may further include a separate network interface for wired communication in addition to the transceiver 1501. The network interface may be referred to as network interface circuitry or communication interface circuitry.

[0264] The processor 1502 may control general operations of the BS 1500 according to embodiments of the disclosure. The processor 1502 may be implemented by one or more integrated circuit (or circuitry) (IC) chips and may execute various data processings. The processor 1502 may include at least one electric circuit, and may execute instructions (or a program, codes, data, etc.) stored in the memory 1503, individually, collectively or in any combination thereof. Further, the processor 1502 may include a single-core processor or multi-core processor, and may include a processor assembly including a plurality of processing circuits (circuitry) according to a specific implementation scheme.

[0265] The processor 1502 may be electrically, operatively, or communicatively coupled to the transceiver 1501 to control the transceiver 1501.

[0266] The processor 1502 may include at least one processor (or processing circuitry), and the at least one processor may perform the following operations individually, collectively or in any combination thereof. In a specific embodiment, at least a part of the processor 1502 may be included in one chip and the other part of the processor 1502 may be included in another chip. Otherwise, at least one processor may be included in another component, for example, the transceiver 1501 or the memory 1503.

[0267] The processor 1502 may perform or control or cause an operation of the BS 1500 for executing at least one or a combination of methods according to embodiments of the disclosure. For example, the processor 1502 may control operations of the BS 1500 for generating and transmitting a downlink signal to a UE or processing an uplink signal received from a UE. Otherwise, the BS 1500 may transmit or receive a signal to or from a neighboring BS, transfer a signal received from a UE to an upper node of the network, or transmit a signal transferred from an upper node of the network to a UE. To this end, the processor 1502 may execute a computer program, codes, or instructions stored in the memory 1503, so as to control other components of the BS 1500 to enable execution of various operations.

[0268] The memory 1503 corresponds to a hardware storage device capable of temporarily or permanently storing information and may include one or more storage media. For example, the memory 1503 may include a memory assembly including one or more storage media. For example, the one or more storage media may include permanent memory, such as a hard drive, flash memory, or read-only memory (ROM), semipermanent memory, such as random access memory (RAM), cache memory, or a combination thereof.

[0269] The memory 1503 may be electrically, operatively, or communicatively coupled to the processor 1502 and may be accessed by the processor 1502.

[0270] The memory 1503 may store a computer program, codes, or instructions executable by the processor 1502. According to an embodiment, a computer program, codes, or instructions executable by the processor 1502 may be either stored in a single memory device or separated and distributedly stored in two or more memory devices. By executing the instructions stored in the memory 1503, the processor 1502 may perform various functions according to an embodiment of the disclosure.

[0271] According to an embodiment of the disclosure, operations of the BS 1500 may be caused to be performed based on execution of instructions (or a computer program or codes) stored in the memory 1503 by at least one processor (or processing circuitry) configured to execute the same individually, collectively, or in any combination thereof, based on processing circuitry that is not configured to execute instructions, and / or based on components of processing circuitry that is not configured to execute instructions.

[0272] The UE or the base station may perform various communication procedures related to the control plane or the user plane by cooperating with one or more network entities based on wireless communication. For example, the UE may communicate with network entity such as an Access and Mobility Management Function (AMF) or a Session Management Function (SMF) via the base station, or the base station may perform at least one communication procedure by directly transmitting and receiving signals to / from, or relaying signals between, the network entities.

[0273] The structure of the above-described network entity will be described in more detail with reference to the drawings.

[0274] FIG. 16 is a block diagram of a network entity 1600 according to an embodiment of the disclosure. The network entity of FIG.16 corresponds to the AEF of FIG. 5b, the first CCF of FIG. 5c, the second CCF of FIG. 5d, or the API invoker.

[0275] The network entity 1600 may include an entity (apparatus, device, or server, etc.) that performs one or more network functions (NFs) or a part of a network function constituting a core network (e.g., a 5th generation (5G) core (5GC)) in a communication system. In this case, multiple NFs may be implemented within a single network entity, or a single NF may be distributed and implemented across a plurality of network entities. In addition, when an NF is implemented within the network entity, the NF may be implemented in the form of software, and in such a case, a program for operating the NF may be stored in memory of the network entity 1600.

[0276] A single NF may be implemented by one or more instances, which may be deployed on the same network entity or distributed across multiple network entities to operate. The instance may be a software unit that logically executes a specific network function, and may be implemented in a form that is decoupled from physical hardware resources. Further, one or more NFs may be implemented in the form of one network slice to operate to satisfy specifications required by a particular service.

[0277] The NF may include at least one of an access and mobility management function (AMF), a session management function (SMF), a local session management function (L-SMF), a user plane function (UPF), a local user plane function (L-UPF), a policy control function (PCF), a unified data management (UDM), a unified data repository (UDR), a network exposure function (NEF), a network repository function (NRF), an application function (AF), a network slice selection function (NSSF), a network data analytics function (NWDAF), a network slice admission control function (NSACF), an authentication server function (AUSF), or a data network (DN).

[0278] Referring to FIG. 16, the network entity 1600 may include at least one network interface 1601, at least one processor 1602 (hereinafter, “processor”), and at least one memory 1603 (hereinafter, “memory”). As described above, a NF may be implemented in the form of a physical device such as the network entity 1600, or may be virtualized and executed in the form of an instance. When implemented as an instance, the NF need not necessarily include physical components as illustrated in FIG. 16. In such a case, the instance may be logically represented as comprising one or more logical functional elements.

[0279] According to at least one or a combination of methods corresponding to the embodiments described in the present disclosure, the network interface 1601, the processor 1602, and the memory 1603 of the network entity 1600 may operate. However, components of the network entity 1600 are not limited to the exemplary components illustrated in FIG. 16. In another embodiment, the network entity 1600 may further include additional components in addition to the above-mentioned components, or some components may be omitted. Further, in an embodiment, the network interface 1601, the processor 1602, or the memory 1603 may be integrated in the form of one component.

[0280] The network interface 1601 is a collective term for a transmitter part of the network entity 1600 and a receiver part of the network entity 1600, and may be a communication circuit for transmitting or receiving a signal to or from a user equipment (UE), a base station (BS), or another network entity. Here, the communication circuit may include both a communication circuit for wireless communication and a communication circuit for a wired communication. For example, the network interface 1601 may include a circuit, logic, hardware, etc., configured to exchange a control plane message or a user plane message with a UE, a BS, or other core network entities through wireless communication or wired communication. The network interface 1601 may operate using various protocols (e.g., non-access stratum (NAS) protocol). The network interface 1601 may also be referred to, for convenience of description or depending on implementation, as communication circuitry, network interface circuitry, or a communication interface circuitry.

[0281] The processor 1602 may control general operations of the network entity 1600 according to embodiments of the disclosure. The processor 1602 may be implemented by one or more integrated circuit (or circuitry) (IC) chips and may execute various data processings. The processor 1602 may include at least one electric circuit, and may execute instructions (or a program, codes, data, etc.) stored in the memory 1603, individually, collectively or in any combination thereof. Further, the processor 1602 may include a single-core processor or multi-core processor, and may include a processor assembly including a plurality of processing circuits (circuitry) according to a specific implementation scheme. Further, it should be noted that, according to another embodiment, in a case where NF is implemented in the form of an instance, the network function may be not necessarily configured by physical hardware.

[0282] According to an embodiment, the processor 1602 may be electrically, operatively, or communicatively coupled to the network interface 1601 to control the network interface 1601.

[0283] The processor 1602 may include at least one processor (or processing circuitry), and the at least one processor may perform the following operations individually, collectively or in any combination thereof. In a specific embodiment, at least a part of the processor 1602 may be included in one chip and the other part of the processor 1602 may be included in another chip. Otherwise, at least one processor may be included in another component, for example, the network interface 1601 or the memory 1603.

[0284] The processor 1602 may perform or control or cause an operation of the network entity 1600 for executing at least one or a combination of methods according to embodiments of the disclosure. For example, the processor 1602 may control operations of the network entity 1600 for exchanging a control plane message or a user plane message with a UE, a BS, or other core network entities through wireless or wired communication, using various protocols (e.g., NAS protocol). To this end, the processor 1602 may execute a computer program, codes, or instructions stored in the memory 1603, so as to control other components of the network entity 1600 to enable execution of various operations.

[0285] The memory 1603 corresponds to a hardware storage device capable of temporarily or permanently storing information and may include one or more storage media. For example, the memory 1603 may include a memory assembly including one or more storage media. For example, the one or more storage media may include permanent memory, such as a hard drive, flash memory, or read-only memory (ROM), semipermanent memory, such as random access memory (RAM), cache memory, or a combination thereof.

[0286] The memory 1603 may be electrically, operatively, or communicatively coupled to the processor 1602 and may be accessed by the processor 1602.

[0287] The memory 1603 may store a computer program, codes, or instructions executable by the processor 1602. According to an embodiment, a computer program, codes, or instructions executable by the processor 1602 may be either stored in a single memory device or separated and distributedly stored in two or more memory devices. By executing the instructions stored in the memory 1603, the processor 1602 may perform various functions according to an embodiment of the disclosure.

[0288] According to an embodiment of the disclosure, operations of the network entity 1600 may be caused to be performed based on execution of instructions (or a computer program or codes) stored in the memory 1603 by at least one processor (or processing circuitry) configured to execute the same individually, collectively, or in any combination thereof, based on processing circuitry that is not configured to execute instructions, and / or based on components of processing circuitry that is not configured to execute instructions.

[0289] The various actions, acts, blocks, steps, or the like in the method may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

[0290] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The elements include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0291] Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in at least one embodiment through or together with a software program written in e.g., Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means which could be e.g., hardware means like e.g., an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g., using a plurality of CPUs.

[0292] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

[0293] Meanwhile, although specific embodiments of the present disclosure have been described in detail, various modifications may be made without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims and equivalents thereof.

Claims

A method performed by an application programming interface (API) invoker, the method comprising:transmitting, to a first common API framework (CAPIF) core function (CCF) entity in a first CAPIF provider, a security method request message including information on an API exposing function (AEF) entity registered to a second CCF entity in second CAPIF provider; andreceiving, from the first CCF entity, a security method response message including a security method of the AEF entity which is used over a CAPIF-2 / 2e reference point for the AEF entity,wherein the API invoker is onboarded to the first CCF entity.The method of claim 1, wherein the security method is determined based on an API invoker identifier (ID) or a list of supported security methods of AEF.The method of claim 1, wherein the security method request message further includes and a list of security methods that the API invoker supports over the CAPIF-2 / 2e reference point.The method of claim 1, wherein the security method is selected by the first CCF entity or the second CCF entity.The method of claim 1, further comprising:transmitting, to the AEF entity, an authentication initiation request message including an API invoker ID and information on an identification of the first CCF entity;receiving, from the AEF entity, an authentication initiation response; andestablishing a transport layer security (TLS) connection with the AEF entity.The method of claim 5,wherein the TLS connection is established by using security information, andwherein the security information is associated with a TLS-pre-shared key (PSK) for an AEF_PSK.The method of claim 5, wherein the security information is determined based on at least one of the API invoker ID, the identification of the first CCF entity, or the information on the AEF entity.An application programming interface (API) invoker comprising:at least one processor; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the API invoker to:transmit, to a first common API framework (CAPIF) core function (CCF) entity in a first CAPIF provider, a security method request message including information on an API exposing function (AEF) entity registered to a second CCF entity in second CAPIF provider, andreceive, from the first CCF entity, a security method response message including a security method of the AEF entity which is used over a CAPIF-2 / 2e reference point for the AEF entity,wherein the API invoker is onboarded to the first CCF entity.The API invoker of claim 1, wherein the security method is determined based on an API invoker identifier (ID) or a list of supported security methods of AEF.The API invoker of claim 1, wherein the security method request message further includes and a list of security methods that the API invoker supports over the CAPIF-2 / 2e reference point.The API invoker of claim 1, wherein the security method response message is selected by the first CCF entity or the second CCF entity.The API invoker of claim 1, wherein the instructions further cause the API invoker to:transmit, to the AEF entity, an authentication initiation request message including an API invoker ID and information on an identification of the first CCF entity,receive, from the AEF entity, an authentication initiation response, andestablish a transport layer security (TLS) connection with the AEF entity.The API invoker of claim 12,wherein the TLS connection is established by using security information, andwherein the security information is associated with a TLS-pre-shared key (PSK) for an AEF_PSK.The API invoker of claim 12, wherein the security information is determined based on at least one of the API invoker ID, the identification of the first CCF entity, or the information on the AEF entity.One or more non-transitory computer-readable storage media storing computer-executable instructions that, when executed by at least one processor of an API invoker individually or collectively, cause the API invoker to perform operations, the operations comprising:transmitting, to a first common API framework (CAPIF) core function (CCF) entity in a first CAPIF provider, a security method request message including information on an API exposing function (AEF) entity registered to a second CCF entity in second CAPIF provider; andreceiving, from the first CCF entity, a security method response message including a security method of the AEF entity which is used over a CAPIF-2 / 2e reference point for the AEF entity,wherein the API invoker is onboarded to the first CCF entity.

Images