Method and apparatus for conditional onboarding of an API invoker to common application programming interface framework in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The embodiments disclosed herein describe a method and system for conditional onboarding of an API Invoker (203) to a Common API Framework (CAPIF). The method involves conditional onboarding an API Invoker to a CAPIF involves receiving an onboard request with criteria information from the API Invoker (203). The network apparatus determines if the CAPIF Core Function (CCF) (103) supports the criteria. If supported, the API Invoker (203) is onboarded, and a confirmation message is sent. If not, an onboarding notification request is sent to the API Invoker (203), indicating why the criteria aren't met, and a response is received from the API Invoker (203). This process ensures that only compatible API Invokers are onboarded to the CAPIF. This solution ensures only valid onboarding's, better consumption of the CAPIF services by API invoker (203) and avoid the wastage of resources.

Description

METHOD AND APPARATUS FOR CONDITIONAL ONBOARDING OF AN API INVOKER TO COMMON APPLICATION PROGRAMMING INTERFACE FRAMEWORK IN A WIRELESS COMMUNICATION SYSTEM

[0001] The present application relates to wireless communication and more specifically relates to conditional on-boarding of an API Invoker to Common Application Programming Interface (API) framework.

[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] The principal object of the invention herein is to provide a method, a network apparatus, and an electronic device for conditional on-boarding of an API Invoker to a Common Application Programming Interface (API) framework.

[0009] Another objective of the invention herein is for on-boarding of a network apparatus comprising an API Invoker to CCF.

[0010] Another objective of the invention herein is to conditionally onboard an API Invoker based on criteria information received from the API Invoker.

[0011] Yet another objective of the invention herein is to notify the API Invoker by the CCF when onboarding criteria are not met.

[0012] Yet another objective of the invention herein is to allow an API Invoker to conditionally onboard to CCF by including specific criteria in its onboarding request. The API Invoker expresses its desire to join the CCF only if certain criteria are supported, and the CCF will assess the request to determine whether it can accommodate the specified criteria. If the CCF supports the criteria, the onboarding process occurs; otherwise, it does not.

[0013] Aspects of the disclosure are to address at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide efficient communication methods in a wireless communication system.

[0014] This invention is 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 drawings, in which:

[0015] FIG. 1 is a block diagram of a network apparatus for conditional onboarding an API Invoker to a CAPIF according to embodiments as disclosed herein.

[0016] FIG. 2 is a block diagram of an electronic device for conditional onboarding the API Invoker to the CCF according to embodiments as disclosed herein.

[0017] FIG. 3 is a flowchart that illustrates a method by a network apparatus for conditional onboarding the API Invoker to the CCF according to embodiments as disclosed herein.

[0018] FIG. 4 is a flowchart that illustrates a method by an electronic device for conditional onboarding the API Invoker to the CCF according to embodiments as disclosed herein.

[0019] FIG. 5 is a sequence diagram that illustrates a procedure for conditional onboarding the API Invoker at the CCF according to embodiments as disclosed herein.

[0020] FIG. 6 is a sequence diagram that illustrates a procedure for conditionally offboarding the API Invoker from the CCF according to embodiments as disclosed herein.

[0021] FIG. 7 is a sequence diagram that illustrates a notification procedure to renew the enrolment to the CCF onboarding notification request and response according to embodiments as disclosed herein.

[0022] FIG. 8 illustrates various hardware components of a network entity, according to the embodiments as disclosed herein.

[0023] FIG. 9 illustrates various hardware components of a UE, according to the embodiments as disclosed herein.

[0024] Aspects of the disclosure are to address at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide a terminal and a communication method thereof in a wireless communication system.

[0025] In an aspect, the objects are achieved by providing a method, device and network apparatus for conditional onboarding of an API Invoker to Common API framework. The method includes determining conditional onboarding an API Invoker to a CAPIF involves receiving an onboard request from the API Invoker of an electronic device, which includes onboarding criteria and information to be supported by the CCF of a network apparatus. The network apparatus determines whether the CCF supports the provided criteria. If the criteria are supported, onboarding based on a onboarding request message and a response is sent to the API Invoker. If the criteria are not supported, an onboarding notification message is sent, including a reason for failure, and the API Invoker responds accordingly.

[0026] In another aspect, the objects are achieved by providing the network apparatus for conditional onboarding an API Invoker to a CAPIF comprises a memory containing a CCF, a processor, and a conditionally onboard controller coupled to both the memory and the processor. The conditionally onboard controller receives an onboard request message from the API Invoker, which includes onboarding criteria and criteria information to be supported by the CCF of the network apparatus for onboarding. It then determines whether the criteria information is supported by the CCF. Based on this determination, the controller either onboards the API Invoker based on the onboard request message, transmitting the onboard request response message to the API Invoker if the criteria are supported, or transmits an onboarding notification request message if the criteria are not supported. The onboarding notification request message includes a notification reason indicating the criteria are not met, and the controller receives an onboarding notification response message from the API Invoker in response.

[0027] In yet another aspect, the objects are achieved by providing the electronic device for conditional onboarding an API Invoker to a CAPIF includes a memory containing the API Invoker, a processor, and a conditionally onboard controller coupled to both the memory and the processor. The conditionally onboard controller generates an onboard request message at the API Invoker, which includes onboarding criteria and criteria information to be supported by the CCF of the network apparatus for onboarding. It then transmits the onboard request message to the network apparatus and receives an onboard request response message when the CCF supports the required criteria information, onboarding with the API Invoker's based on onboard request message. Further, if the criteria information is not supported, the controller receives an onboarding notification request message from the network apparatus, which includes a notification reason indicating that the onboarding criteria are not met, and in response, the controller transmits an onboarding notification response message back to the network apparatus.

[0028] 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 preferred embodiments 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, and the embodiments herein include all such modifications.

[0029] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

[0030] The terms and words used in the following description and claims are not limited to their bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the disclosure is provided for illustration purpose only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

[0031] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.

[0032] Before undertaking the DETAILED DESCRIPTION below, it can be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The term "couple" and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The terms "transmit," "receive," and "communicate," as well as derivatives thereof, encompass both direct and indirect communication. The terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation. The term "or" is inclusive, meaning and / or. The phrase "associated with," as well as derivatives thereof, means to include, be included within, connect to, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term "controller" means any device, system or part thereof that controls at least one operation. Such a controller can be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller can be centralized or distributed, whether locally or remotely. The phrase "at least one of," when used with a list of items, means that different combinations of one or more of the listed items can be used, and only one item in the list can be needed. For example, "at least one of: A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C. For example, "at least one of: A, B, or C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A, B and C.

[0033] Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium capable of being accessed by a computer, such as Read-Only Memory (ROM), Random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. A "non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer-readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.

[0034] Terms used herein to describe the embodiments of the disclosure are not intended to limit and / or define the scope of the disclosure. For example, unless otherwise defined, the technical terms or scientific terms used in the disclosure shall have the ordinary meaning understood by those with ordinary skills in the art to which the disclosure belongs.

[0035] It should be understood that "first", "second" and similar words used in the disclosure do not express any order, quantity or importance, but are only used to distinguish different components.

[0036] As used herein, any reference to "an example" or "example", "an implementation" or "implementation", "an embodiment" or "embodiment" means that particular elements, features, structures or characteristics described in connection with the embodiment is included in at least one embodiment. The phrases "in one embodiment" or "in one example" appearing in different places in the specification do not necessarily refer to the same embodiment.

[0037] As used herein, "a portion of" something means "at least some of" the thing, and as such may mean less than all of, or all of, the thing. As such, "a portion of" a thing includes the entire thing as a special case, i.e., the entire thing is an example of a portion of the thing.

[0038] As used herein, the term "set" means one or more. Accordingly, a set of items can be a single item or a collection of two or more items.

[0039] In this disclosure, to determine whether a specific condition is satisfied or fulfilled, expressions, such as "greater than" or "less than" are used by way of example and expressions, such as "greater than or equal to" or "less than or equal to" are also applicable and not excluded. For example, a condition defined with "greater than or equal to" may be replaced by "greater than" (or vice-versa), a condition defined with "less than or equal to" may be replaced by "less than" (or vice-versa), etc.

[0040] It will be further understood that similar words such as the term "include" or "comprise" mean that elements or objects appearing before the word encompass the listed elements or objects appearing after the word and their equivalents, but other elements or objects are not excluded. Similar words such as "connect" or "connected" are not limited to physical or mechanical connection, but can include electrical connection, whether direct or indirect. "Upper", "lower", "left" and "right" are only used to express a relative positional relationship, and when an absolute position of the described object changes, the relative positional relationship may change accordingly.

[0041] Those skilled in the art will understand that the principles of the disclosure can be implemented in any suitably arranged wireless communication system. For example, although the following detailed description of the embodiments of the disclosure will be directed to LTE and / or 5G communication systems, those skilled in the art will understand that the main points of the disclosure can also be applied to other communication systems with similar technical backgrounds and channel formats with slight modifications without departing from the scope of the disclosure. The technical schemes of the embodiments of the application can be applied to various communication systems, and for example, the communication systems may include global systems for mobile communications (GSM), code division multiple access (CDMA) systems, wideband code division multiple access (WCDMA) systems, general packet radio service (GPRS) systems, long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, universal mobile telecommunications system (UMTS), worldwide interoperability for microwave access (WiMAX) communication systems, 5th generation (5G) systems or new radio (NR) systems, etc. In addition, the technical schemes of the embodiments of the application can be applied to future-oriented communication technologies. In addition, the technical schemes of the embodiments of the application can be applied to future-oriented communication technologies.

[0042] In order to meet the increasing demand for wireless data communication services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also called "Beyond 4G networks" or "Post-LTE systems".

[0043] The Common API Framework (CAPIF) is designed to facilitate the registration and management of API Invokers, enabling them to utilize northbound APIs effectively. According to the existing mechanism specified in TS 23.222 clause 8.1, the onboarding process involves the API Invoker sending an onboard API Invoker request. Upon successful verification of this request, the CAPIF Core Function (CCF) generates the API Invoker profile and responds with the necessary API Invoker information in the on-boarding response message. This process allows an application function to register itself as an API Invoker, subsequently enabling it to invoke northbound APIs with CAPIF support.

[0044] However, several challenges arise from this current mechanism, leading to inefficiencies and resource wastage. One significant issue is that after successfully on-boarding to the CAPIF, an API Invoker may discover that certain desired features or services are not supported by the CCF. This scenario forces the API Invoker to either off-board from the CAPIF or refrain from consuming the northbound APIs, resulting in a waste of resources such as compute power, storage, and management efforts.

[0045] The lack of comprehensive information about the available features and services before on-boarding exacerbates this problem. API Invokers might not have access to all necessary API information due to security reasons or to avoid implementation complexity. Consequently, the API information available to the API Invoker before on-boarding may be insufficient or outdated, failing to meet the API Invoker's requirements. For instance, an Augmented Reality (AR) or Virtual Reality (VR) application might need services from both the Network Exposure Function (NEF) for location and the xMB interface for media management. If the required API Exposing Function (AEF) providing xMB service is absent, it would be inappropriate for the API Invoker to onboard to the CCF.

[0046] Furthermore, with the increasing number of application clients (API Invokers) on User Equipment (UE) invoking northbound APIs with CAPIF assistance, the number of API Invokers on-boarding to the CCF could escalate significantly, potentially matching the scale of the number of UEs served by the network. This surge in on-boarding API Invokers would place a substantial burden on the CCF, leading to unnecessary consumption and allocation of resources.

[0047] Further, there is a need to address various subscriber-aware northbound API access (SNAAPP) requirements and support for API Invokers deployed on the UE accessing resources of other users. This includes considerations for applications on UE acting as API Invokers, which need to onboard to the CAPIF before consuming northbound APIs. The problem applies whether the API Invoker is on the network side (like an Application server or Application Function) or on the UE side.

[0048] Hence, it is desired to address the above-mentioned disadvantages or other short- comings or at least provide a useful alternative.

[0049] The present invention addresses the onboarding of API Invokers to the Common API Framework (CAPIF) and the associated challenges. When the API Invoker onboards to the CAPIF, certain features, such as support for specific security methods, may not be supported by the CAPIF. Consequently, the CAPIF services may not be utilized by the API Invoker, leading to the management of inactive API Invokers and unnecessary consumption of resources. This issue is exacerbated when the API Invoker is on a User Equipment (UE), potentially increasing the number of API Invokers that the CAPIF needs to manage.

[0050] The existing system, as defined in the 3GPP TS 23.222 clause 8.1, involves the API Invoker sending an onboard API Invoker request. Upon successful verification, the CAPIF generates the API Invoker profile and responds with the API Invoker information in the onboarding response message. However, a drawback of this system is that if the API Invoker realizes post-onboarding that certain desired features or services are not supported, the API Invoker may offboard from the CAPIF or refrain from consuming northbound APIs via the registered CAPIF. This results in wasted resources for both the API Invoker and the CAPIF.

[0051] The features that the API Invoker may seek from the CAPIF, but which may not be supported, include the availability of certain service APIs, support for specific security methods, and interconnection with a given set of CAPIFs. Some implementations may not disclose all API information to API Invokers yet to be onboarded, possibly for security reasons. Consequently, the API Invoker may not have sufficient or up-to-date information to meet its onboarding requirements. For example, an AR / VR application may need services from both the Network Exposure Function (NEF) for location and the xMB interface for media management. However, the absence of an API Exposure Function (AEF) providing xMB service may render the onboarding to CAPIF inappropriate for the API Invoker.

[0052] The proposed invention introduces an enhanced CAPIF API Invoker onboarding procedure with criteria information. The API Invoker includes the onboarding criteria information in the API Invoker onboarding request. The CAPIF onboards the API Invoker only if it supports the criteria provided by the API Invoker. Additionally, post-onboarding, if the CAPIF does not meet the criteria, the invention proposes notifying the API Invoker so that it may take actions such as changing the criteria information or offboarding from the CAPIF. This invention aims to avoid unwanted API Invoker enrollments by allowing onboarding based on the API Invoker's criteria. This ensures valid onboardings, better consumption of CAPIF services by the API Invoker, and avoids the wastage of resources.

[0053] Referring now to the drawings, and more particularly to FIGS. 1 to 6, there are shown preferred embodiments.

[0054] FIG. 1 is a block diagram of a network apparatus (100) for conditional onboarding an API Invoker to a CAPIF. The network apparatus (100) includes a processor (101), a memory (102), a CCF (103), and the conditionally onboard controller (104).

[0055] The network apparatus (100) described herein can be user equipment (UE), smartphones, tablets, laptops, wearables, Internet of Things (IoT) devices, smart home devices, televisions, connected cars, USB modems, and the like, mobile phones, PCs (personal computers), computing devices, digital workstations, virtual machines, and personal digital assistants (PDAs), etc. These devices are equipped with various sensors and interfaces to support AR / VR applications, such as accelerometers, gyroscopes, cameras, and microphones, enabling immersive user experiences. The applications may include augmented reality (AR), virtual reality (VR), and mixed reality (MR). An AR / VR application may need services from both NEF (location) and xMB interface (for media management) for the API Invoker to onboard to CCF, which requires high data rates and low latency to function effectively. Further, the network apparatus (100) may support edge computing capabilities, allowing it to offload computationally intensive tasks to nearby servers, reducing the processing burden on the device itself.

[0056] The processor (101) is responsible for executing instructions and managing the overall operation of the network apparatus (100), including the enhanced mechanism of conditional onboarding an API Invoker to a CAPIF. The processor (101) communicates with the memory (102), the CCF (103), and the conditionally onboard controller (104). The processor (101) is configured to execute instructions stored in the memory (102) and to perform various processes for real-time data processing in AR / VR applications. The processor (101) may include one or a plurality of processors, maybe a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU). The processor may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor. The processor may include multiple cores and is configured to execute the instructions stored in the memory.

[0057] The memory (102) stores the operating system, application software, and temporary data used by the processor (101). The memory (102) stores a large amount of data and information. The memory (102) stores instructions to be executed by the processor (101). The memory (102) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (102) 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 (102) is non-movable. In some examples, the memory (102) can be configured to store larger amounts of information than the memory. In an example, a non-transitory storage medium may store data that can over time change (e.g., in Random Access Memory (RAM) or cache).

[0058] The conditionally onboard controller (104) is hardware designed for conditional onboarding the API Invoker to the CAPIF. The Conditionally onboard Controller (104) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0059] The conditionally onboard controller (104) ensures that enabling onboarding enhancement to the API invokers promotes better adoption of the CAPIF services and enrolment of the API invokers. The conditionally onboard controller (104) handles the API Invoker, indicating conditional onboarding wishes to onboard to the CCF only if certain criteria are supported. When the conditionally onboard controller (104) initiates a process to the criteria information in the onboarding request, it indicates that it wishes to be onboarded to the CCF (103) if the CCF (103) supports the criteria.

[0060] In an embodiment, the conditionally onboard controller (104) evaluates the urgency of notifying the API Invoker (203) by the CCF (103) when onboarding criteria are not met. It is a waste of resources (compute, storage, management, etc.) for the API Invoker (203) and the CCF (103) to perform the onboarding and maintain the API Invoker profile information if the criteria are not satisfied. The conditionally onboard controller (104) determines whether the criteria information is supported by the CCF (103) of the network apparatus (100). If supported, onboarding of the API Invoker based on the onboarding request message and sends an onboard request response message. If not supported, it sends an onboarding notification request message to the API Invoker (203) including a reason why the criteria are not met and then receives an onboarding notification response from the API Invoker.

[0061] The evaluation of urgency by the conditionally onboard controller (104) optimizes the use of network resources. By determining the necessity of onboarding based on predefined criteria, the proposed solution ensures that only those API Invokers that meet the required standards are onboarded. This selective onboarding process helps in maintaining the efficiency and performance of the network apparatus (100). It prevents unnecessary consumption of computational power, storage space, and management efforts. When the criteria are not met, the conditionally onboard controller (104) sends a detailed onboarding notification request message. This message not only informs the API Invoker about the unsuccessful onboarding attempt but also provides specific reasons for the failure or this notification request message can be at later point of time after onboarding the API Invoker (203) to CCF (103) to inform the API Invoker (203) about CCF (103) not meeting the onboarding criteria. This transparency allows the API Invoker to understand the deficiencies and make necessary adjustments to meet the criteria in future attempts.

[0062] FIG. 2 is a block diagram of an electronic device for conditional onboarding the API Invoker to the CAPIF. The electronic device (200) includes a processor (201), a memory (202), an API Invoker (203), and the conditionally onboard controller (204).

[0063] The electronic device (200) described herein can be User equipment (UE), smartphones, tablets, laptops, wearables, Internet of Things (IoT) devices, smart home devices, television, connected car, USB modems, and the like, mobile phone, PC, personal computer, computing device, digital workstation devices, virtual machines, and a personal digital assistant (PDA), etc. These devices are equipped with various sensors and interfaces to support AR / VR applications such as accelerometers, gyroscopes, cameras, and microphones, enabling immersive user experiences. The applications may include augmented reality (AR), virtual reality (VR), and mixed reality (MR). An AR / VR application may need services from both NEF (location) and xMB interface (for media management) for the API Invoker (203) to onboard to CCF (103), which require high data rates and low latency to function effectively. Further, the electronic device (200) may support edge computing capabilities, allowing it to offload computationally intensive tasks to nearby servers, reducing the processing burden on the device itself.

[0064] The processor (201) is responsible for executing instructions and managing the overall operation of the electronic device (200), including the enhanced mechanism of conditional onboarding an API Invoker (203) to a CAPIF. The processor (201) communicates with the memory (202), the API Invoker (203), and the conditionally onboard controller (204). The processor (201) is configured to execute instructions stored in the memory (202) and to perform various processes for real-time data processing in AR / VR applications. The processor (201) may include one or a plurality of processors, maybe a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an Artificial Intelligence (AI) dedicated processor such as a neural processing unit (NPU). The processor may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor. The processor may include multiple cores and is configured to execute the instructions stored in the memory.

[0065] The memory (202) stores the operating system, application software, and temporary data used by the processor (201). The memory (202) stores a large amount of data and information. The memory (202) stores instructions to be executed by the processor (201). The memory (202) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (202) 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 (202) is non-movable. In some examples, the memory (202) can be configured to store larger amounts of information than the memory. In an example, a non-transitory storage medium may store data that can over time change (e.g., in Random Access Memory (RAM) or cache).

[0066] The Conditionally onboard Controller (204) is a hardware component designed for the conditional onboarding of an API Invoker (203) to a CAPIF. The Conditionally onboard Controller (204) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0067] When the Conditionally onboard Controller (204) initiates an onboard process, it includes criteria information in the onboarding request, indicating that it wishes to be onboarded to the CCF if the CCF supports the criteria. The controller generates an onboard request message from the API Invoker (203) that includes the onboarding criteria and the criteria information required by the CCF (103) of the network apparatus (100). This message is transmitted to the network apparatus (100), and the controller waits for a response.

[0068] If the CCF (103) supports the criteria, the onboard the API Invoker (203) based on the onboard request message when the criteria information is supported by the CCF (103) and transmitting an onboard request response message to the API Invoker (203), and the controller receives an onboard request response message. Further, if the CCF (103) does not support the criteria, the controller receives an onboarding notification request with a reason for failure and responds with an onboarding notification response message.

[0069] In an embodiment, the Conditionally onboard Controller (204) has the ability to renew or cancel the enrollment of the API Invoker in the CCF (103) of the network apparatus (100) based on the notification reason.

[0070] FIG. 3 is a flowchart (300) that illustrates a method by a network apparatus for conditional onboarding of an API Invoker (203) to a CCF (103). At step 301, the method includes receiving by a network apparatus (100) an onboard request message from the API Invoker (203) of an electronic device (200).

[0071] At step 302, the method determines whether the criteria information in the onboard request message from the API Invoker (203) is supported by the CCF (103) of the network apparatus (100). The onboarding criteria indicate that the API Invoker (203) wishes to onboard itself to the CCF (103) only when the CCF (103) supports the criteria information.

[0072] In an embodiment, the criteria information includes factors such as the availability of AEFs that serve a set of service APIs, support for security methods, security support for specific AEFs, AEF types, service APIs, or service API categories, and the interconnection with a set of CCFs.

[0073] In an embodiment, the set of service APIs may include one or more of Network Exposure Function Service APIs, SEAL service APIs, etc. Further support for security methods includes one or more of TLS-PSK, TLS-PKI, TLS-OAUTH etc.

[0074] At step 303, the method includes transmitting an onboarding notification request message to the API Invoker (203). If it does not support the criteria information, it will transmit an onboarding notification request message to the API Invoker (203).

[0075] At step 304, the method includes receiving an onboarding notification response message from the API Invoker (203) in response to the onboarding notification request message. In an embodiment, the method includes transmitting an onboarding notification request message to the API Invoker (203) when the criteria information is not supported by the CCF (103), wherein the onboarding notification request message comprises a notification reason indicating onboarding criteria is not met, and receiving an onboarding notification response message from the API Invoker (203) in response to the onboarding notification request message.

[0076] At step 305, the method includes onboarding the API Invoker (203) based on the onboard request message. At step 306, the method includes transmitting an onboard request response message to the API Invoker (203). In an embodiment, the method includes onboarding the API Invoker (203) based on the onboard request message when the criteria information is supported by the CCF (103) and transmitting an onboard request response message to the API Invoker (203).

[0077] FIG. 4 is a flowchart (400) that illustrates a method by the electronic device (200) for conditional onboarding of an API Invoker (203) to a CCF (103).

[0078] At step 401, the method includes generating by the electronic device (200) an onboard request message at the API invoker (203). The method includes generating by an electronic device (200) an onboard request message at the API invoker (203), wherein the onboard request message includes an onboarding criteria and criteria information to be supported by a CCF (103) of a network apparatus (100) to onboard the API invoker (203). The onboarding criteria indicate that the API Invoker (203) wishes to onboard itself to the CCF (103) only when the CCF (103) supports the criteria information.

[0079] In an embodiment, the criteria information includes factors such as the availability of AEFs that serve a set of service APIs, support for security methods, security support for specific AEFs, AEF types, service APIs, or service API categories, and the interconnection with a set of CCFs.

[0080] In an embodiment, the set of service APIs may include one or more of Network Exposure Function Service APIs, SEAL service APIs, etc. Further support for security methods includes one or more of TLS-PSK, TLS-PKI, TLS-OAUTH etc.

[0081] At step 402, the method includes transmitting by the API invoker (203) at the electronic device (200) the onboard request message to the network apparatus (100).

[0082] At step 403, the method includes when the criteria information is not supported by the CCF (103), receiving by the API invoker (203) at the electronic device (200) an onboard request response message from the network apparatus (100). The method includes receiving by the API invoker at the electronic device an onboarding notification request message when the criteria information is not supported by the CCF of the network apparatus, wherein the onboarding notification request message comprises a notification reason indicating onboarding criteria is not met, and sending by the API invoker an onboarding notification response message to the CCF of the network apparatus in response to the onboarding notification request message.

[0083] At step 404, the method includes when the criteria information is supported by the CCF (103), receiving by the API invoker (203) at the electronic device (200) an onboard request response message from the network apparatus (100). The method includes receiving by the API invoker (203) at the electronic device (200) an onboard request response message from the network apparatus (100) when the CCF (103) of the network apparatus (100) supports the criteria information required by the API invoker (203). The method includes comprising renewing or canceling by the API invoker at the electronic device (200) an enrollment of the API invoker (203) in the CCF (103) of the network apparatus based on the notification reason.

[0084] FIG. 5 is a sequence diagram (500) that illustrates a procedure for conditional on boarding the API Invoker (203) at the CCF (103).

[0085] At step 1, the API Invoker (203) sends the Onboard API Invoker request message to the CCF (103), to onboard itself to the CAPIF, as specified in 3GPP TS 23.222, along with additional onboarding criteria information. The API Invoker (203), to indicate to the CCF (103) that the API Invoker (203) wishes to onboard itself to the CCF (103) only if the CCF (103) supports certain criteria, then the API Invoker (203) includes the criteria in onboarding criteria information in the onboard API invoker (203) request message.

[0086] In an embodiment, the onboarding criteria information may include, the information about AEFs serving certain set of service API(s), availability of AEFs serving a set of service APIs, Security methods, interconnection with a given set of CCFs and like so. The onboard API Invoker (203) request from the API invoker to the CCF (103) includes the information elements as mentioned in the table below,

[0087]

[0088] In an embodiment, the criteria information includes factors such as the availability of AEFs that serve a set of service APIs, support for security methods, security support for specific AEFs, AEF types, service APIs, or service API categories, and the interconnection with a set of CCFs.

[0089] In an embodiment, the set of service APIs may include one or more of Network Exposure Function Service APIs, SEAL service APIs, etc. Further support for security methods includes one or more of TLS-PSK, TLS-PKI, TLS-OAUTH etc.

[0090] At step 2, onboarding approval, if the CCF (103) supports the criteria information as per onboarding criteria from the API Invoker (203) upon receipt of onboard API invoker (203) request message, the CCF (103) begins the onboarding process by verifying whether all the necessary information has been provided to onboard the API invoker (103), if the onboard API Invoker request message includes criteria information, then verifying whether the CCF can support the criteria information, and further initiates a grant process. The CCF shall proceed further with API Invoker (203) onboarding procedure, only if the CCF supports the criteria information from the API Invoker. Successful onboarding results in provisioning of API Invoker (203) profile which includes identity for the API Invoker, the authorization information and the list of APIs and the types of APIs that the API invoker can access subsequent to successful on boarding may also be created.

[0091] At step 3, Onboard API Invoker (203) response when the CCF (103) responds, if the API Invoker (203) is granted permission and successfully onboarded to the CCF then the onboard API Invoker (203) response provides information related to onboarded API Invoker (203) or, if the API Invoker (203) is not granted permission, then the onboard API Invoker (203) response provides failure indication including information the details for failure and CCF (103) may provide additional information that the CCF (103) supports, which could be used by API Invoker during retry onboarding

[0092] At step 4, API Invoker (203) onboarding includes when the CCF (103) responds, if the API Invoker (203) is granted permission, the on board API invoker response provides success indication including information from the provisioned API invoker profile / API Invoker (203) enrolment details, which may include information to allow the API Invoker (203) to be authenticated and to obtain authorization for service APIs.

[0093] FIG. 6 is a sequence diagram (600) that illustrates a procedure for conditional off-boarding the API Invoker (203) from the CCF (103). In an embodiment, the CCF (103) off-boards the API Invoker based on certain criteria. The CCF (103) may decide to off-board an API Invoker automatically without any explicit off-boarding request from the API Invoker.

[0094] At step 1, the CCF (103) may take such off-boarding decisions based on certain criteria like no API access activity for a certain period, heavy / abnormal API activity, or on-boarding criteria information from the API Invoker that is no longer supported / fulfilled by the CCF (103).

[0095] At step 2, the CCF (103) off-boards the API Invoker / cancels the API Invoker's enrolment from CAPIF and informs the API Invoker about the off-boarding.

[0096] At step 3, in the off-board API invoker request message, the CCF removes the API Invoker's on-boarding profile / enrolment information. The API Invoker acknowledges the off-boarding from the CAPIF. The CCF may not cancel the API Invoker's enrolment information and include the reason for off-boarding the API Invoker (203).

[0097] At step 4, in response, the API Invoker (203) may express a desire to renew the API Invoker's enrolment through new criteria information, renew request indication, etc.

[0098] In an embodiment, the conditionally onboard controller (204) renews or cancels the enrolment of the API Invoker (203) in the CCF (103) of the network apparatus (100) based on the notification reason.

[0099] FIG. 7 is a sequence diagram (700) that illustrates a notification procedure to renew the enrolment to CCF (103) onboarding notification request & response. In an embodiment, the CCF (103) onboards the API Invoker (203) based on certain criteria. The CCF (103) may decide to onboard an API Invoker (203) based on a triggering onboard notification from the CCF.

[0100] At step 1, the CCF (103) may take the onboarding notification request, indicating the onboarding criteria information from the API Invoker is no longer supported / fulfilled by the CCF (103).

[0101] At step 2, the CCF (103) may onboard the API Invoker (203) based on the onboarding notification response and informs the API Invoker (203) about the onboarding.

[0102] At step 3, in the onboard API invoker (203) request message, the API Invoker may renew the enrolment to CCF (103) as per clause 8.1 of 3GPP TS 23.222 or cancel the enrolment to CCF as per clause 8.2 of 3GPP TS 23.222. The API Invoker acknowledges the off-boarding from the CAPIF.

[0103] In an embodiment, a method for conditional on-boarding of the API Invoker to the common API framework provides a method for the CCF (103) to conditionally onboard an API Invoker (203) based on criteria information from the API Invoker. The API Invoker (203) mentions the criteria information in the on-boarding request, indicating that the API Invoker (203) wishes to be onboarded only if the CCF supports the criteria information from the API Invoker. The CCF, based on criteria information, onboards the API Invoker based on the onboard request message when the criteria information is supported by the CCF and transmits an onboard request response message to the API Invoker. In one aspect, the objects are achieved by providing a system and method for onboarding of the API Invoker (203) to CAPIF. Further, the disclosure provides a method for auto offboarding of the API Invoker (203) by the CCF (103) without an explicit request from the API Invoker.

[0104] In an embodiment, the onboarding criteria information may be provided within other information elements like onboarding information. In an embodiment, upon receipt of the onboard API invoker (203) request message, the CAPIF core function begins the onboarding process by verifying whether all the necessary information has been provided to onboard the API invoker. If the onboard API invoker (203) request message includes criteria information, then verifying whether the CCF (103) can support the criteria information and further initiates a grant process. The CCF (103) shall go further with the API invoker (203) onboarding procedure only if the CCF (103) supports the criteria information from the API invoker. Successful onboarding results in the provisioning of the API invoker profile, which includes identity for the API Invoker (203), the authorization information, and the list of APIs and the types of APIs that the API Invoker (203) can access subsequent to successful onboarding may also be created.

[0105] In an embodiment, the criteria information from the API invoker (203) in the onboard API invoker request may tag the importance information to different criteria provided, like expected (mandatory criteria), desirable (good to have), and any additional categories like so. Based on the importance information from the API invoker, the CCF (103) takes this information into consideration for deciding on onboarding the API invoker (203). For example, if the tag indicates expected, then the CCF onboards only if the criteria are met; if the tag indicates desirable, then the CCF may onboard the API invoker even if the criteria are not met and shall inform the API invoker about the same, etc.

[0106] In an embodiment, the method includes conditional onboarding of an API invoker to a CAPIF, which involves generating an onboard request message at the API invoker, which includes onboarding criteria and criteria information to be supported by the CCF (103) of a network apparatus (100). This onboard request message is transmitted from the API invoker (203) to the network apparatus (100). If the CCF of the network apparatus (100) supports the required criteria information, the API invoker receives an onboard request response message. If the CCF does not support the required criteria, the API invoker (203) receives an onboarding notification request message, which includes a notification reason indicating that the onboarding criteria are not met. In response to this notification request, the API invoker sends an onboarding notification response message back to the CCF of the network apparatus.

[0107] Hence, the proposed invention introduces an innovative solution to the key issue by enabling the CCF (103) to onboard an API invoker (203) to CAPIF based on meeting the criteria information from the API invoker (203). Initial onboarding of the API invoker is avoided when the CCF (103) does not meet the criteria information is provided by the API invoker (203). Potentially, this results in the API invoker actively consuming the CAPIF services / northbound APIs. Also, the solution proposes the CCF (103) sending a notification to the API invoker when the CCF cannot meet the onboarding criteria request from the API invoker. Thus, the enhanced onboarding and notification procedures result in avoiding any unnecessary onboarding, managing dormant API invoker profile information at the CCF, and enhancing the experience of onboarding management.

[0108] FIG. 9 illustrates various hardware components of a network entity, according to the embodiments as disclosed herein.

[0109] Referring to FIG. 9, the network entity includes a transceiver (910), a memory (920), and a processor (930). The transceiver (910), the memory (920), and the processor (930) of the network entity may operate according to a communication method of the network entity described above. However, the components of the terminal are not limited thereto. For example, the network entity may include fewer or a greater number of components than those described above. However, the components of the network entity are not limited thereto. For example, the network entity may include more or fewer components than those described above. In addition, the processor (930), the transceiver (910), and the memory (920) may be implemented as a single chip. Also, the processor (930) may include at least one processor. In addition, the network entity of FIG. 9 may include entities performing a network function in the above description.

[0110] The network entity includes at least one entity of a core network. For example, the network entity includes an AMF, a session management function (SMF), a policy control function (PCF), a network repository function (NRF), a user plane function (UPF), a network slicing selection function (NSSF), an authentication server function (AUSF), a UDM and a network exposure function (NEF), but the network entity is not limited thereto.

[0111] The transceiver (910) collectively refers to a network entity receiver and a network entity transmitter, and may transmit / receive a signal to / from a base station or a UE. The signal transmitted or received to or from the base station or the UE may include control information and data. In this regard, the transceiver (910) may include an RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and an RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver (910) and components of the transceiver (910) are not limited to the RF transmitter and the RF receiver.

[0112] The transceiver (910) may receive and output, to the processor (930), a signal through a wireless channel, and transmit a signal output from the processor (930) through the wireless channel.

[0113] The memory (920) may store a program and data required for operations of the network entity. Also, the memory (920) may store control information or data included in a signal obtained by the network entity. The memory (920) may be a storage medium, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0114] The processor (930) may control a series of processes such that the network entity operates as described above. For example, the transceiver (910) may receive a data signal including a control signal, and the processor (930) may determine a result of receiving the data signal.

[0115] FIG. 10 illustrates a structure of a UE according to an embodiment of the disclosure.

[0116] As shown in FIG. 10, the UE according to an embodiment may include a transceiver (1010), a memory (1020), and a processor (1030). The transceiver (1010), the memory (1020), and the processor (1030) of the UE may operate according to a communication method of the UE described above. However, the components of the UE are not limited thereto. For example, the UE may include more or fewer components than those described above. In addition, the processor (1030), the transceiver (1010), and the memory (1020) may be implemented as a single chip. Also, the processor (1030) may include at least one processor. Furthermore, the UE of FIG. 10 corresponds to the network apparatus (100) of the FIG. 1 or the electronic device (200) of the FIG. 2.

[0117] The transceiver (1010) collectively refers to a UE receiver and a UE transmitter, and may transmit / receive a signal to / from a base station or a network entity. The signal transmitted or received to or from the base station or a network entity may include control information and data. The transceiver (1010) may include a RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and a RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver (1010) and components of the transceiver (1010) are not limited to the RF transmitter and the RF receiver.

[0118] Also, the transceiver (1010) may receive and output, to the processor (1030), a signal through a wireless channel, and transmit a signal output from the processor (1030) through the wireless channel.

[0119] The memory (1020) may store a program and data required for operations of the UE. Also, the memory (1020) may store control information or data included in a signal obtained by the UE. The memory (1020) may be a storage medium, such as read-only memory (ROM), random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0120] The processor (1030) may control a series of processes such that the UE operates as described above. For example, the transceiver (1010) may receive a data signal including a control signal transmitted by the base station or the network entity, and the processor (1030) may determine a result of receiving the control signal and the data signal transmitted by the base station or the network entity.

[0121] Those skilled in the art will understand that the various illustrative logical blocks, modules, circuits, and steps described in this application may be implemented as hardware, software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various illustrative components, blocks, modules, circuits, and steps are generally described above in the form of their functional sets. Whether such function sets are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Technicians may implement the described functional sets in different ways for each specific application, but such design decisions should not be interpreted as causing a departure from the scope of this application.

[0122] In the above-described embodiments of the disclosure, all operations and messages may be selectively performed or may be omitted. In addition, the operations in each embodiment do not need to be performed sequentially, and the order of operations may vary. Messages do not need to be transmitted in order, and the transmission order of messages may change. Each operation and transfer of each message can be performed independently.

[0123] Although the figures illustrate different examples of user equipment, various changes may be made to the figures. For example, the user equipment can include any number of each component in any suitable arrangement. In general, the figures do not limit the scope of this disclosure to any particular configuration(s). Moreover, while figures illustrate operational environments in which various user equipment features disclosed in this patent document can be used, these features can be used in any other suitable system.

[0124] The various illustrative logic blocks, modules, and circuits described in this application may be implemented or performed by a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logics, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general purpose processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0125] The steps of the method or algorithm described in this application may be embodied directly in hardware, in a software module executed by a processor, or in a combination thereof. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, register, hard disk, removable disk, or any other form of storage medium known in the art. A storage medium is coupled to a processor to enable the processor to read and write information from / to the storage media. In an alternative, the storage medium may be integrated into the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and the storage medium may reside in the user terminal as discrete components.

[0126] In one or more designs, the functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, each function may be stored as one or more pieces of instructions or codes on a computer-readable medium or delivered through it. The computer-readable medium includes both a computer storage medium and a communication medium, the latter including any medium that facilitates the transfer of computer programs from one place to another. The storage medium may be any available medium that can be accessed by a general purpose or special purpose computer.

[0127] While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

Claims

1.A method performed by an application programming interface (API) invoker entity in a wireless communication system, the method comprising:transmitting, to a common API framework (CAPIF) core function (CCF) entity, a request message including information on an onboard criteria,wherein the information on the onboard criteria indicates that the API invoker entity wishes to onboard to the CCF entity in case that the onboard criteria is supported.2.The method of claim 1,wherein an onboarding procedure is performed for the API invoker entity based on the onboard criteria being supported.3.The method of claim 1,wherein the information on the onboard criteria includes at least one of information on a security method, information on a service API, or information on an API exposing function (AEF).4.The method of claim 1, further comprising:receiving, from the CCF entity, information related with an onboard criteria which is not met.5.A method performed by a common API framework (CAPIF) core function (CCF) entity in a wireless communication system, the method comprising:receiving, from an application programming interface (API) invoker entity, a request message including information on an onboard criteria,wherein the information on the onboard criteria indicates that the API invoker entity wishes to onboard to the CCF entity in case that the onboard criteria is supported.6.The method of claim 5, further comprising:identifying whether the onboard criteria is being supported; andin case that the onboard criteria is being supported, performing an onboarding procedure for the API invoker entity.7.The method of claim 5,wherein the information on the onboard criteria includes at least one of information on a security method, information on a service API, or information on an API exposing function (AEF).8.The method of claim 5, further comprising:transmitting, to the API invoker entity, information related with an onboard criteria which is not met.9.An application programming interface (API) invoker entity in a wireless communication system, the API invoker entity comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:transmit, to a common API framework (CAPIF) core function (CCF) entity, a request message including information on an onboard criteria,wherein the information on the onboard criteria indicates that the API invoker entity wishes to onboard to the CCF entity in case that the onboard criteria is supported.10.The API invoker entity of claim 9,wherein an onboarding procedure is performed for the API invoker entity based on the onboard criteria being supported.11.The API invoker entity of claim 9,wherein the information on the onboard criteria includes at least one of information on a security method, information on a service API, or information on an API exposing function (AEF).12.The API invoker entity of claim 9, at least one processor is further configured to:receive, from the CCF entity, information related with an onboard criteria which is not met.13.A common API framework (CAPIF) core function (CCF) entity in a wireless communication system, the CCF entity comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:receive, from an application programming interface (API) invoker entity, a request message including information on an onboard criteria,wherein the information on the onboard criteria indicates that the API invoker entity wishes to onboard to the CCF entity in case that the onboard criteria is supported.14.The CCF entity of claim 13, at least one processor is further configured to:identify whether the onboard criteria is being supported; andin case that the onboard criteria is being supported, perform an onboarding procedure for the API invoker entity.15.The CCF entity of claim 13,wherein the information on the onboard criteria includes at least one of information on a security method, information on a service API, or information on an API exposing function (AEF).

Images