Method and apparatus for supporting service API management in communication system

Abstract

The present invention relates to a method for efficiently managing a service application programming interface (API) by acquiring and utilizing information on an actual service API demand through a common API framework such that a subject actually providing the service API can dynamically expand or reduce a service capacity according to an actual API request demand in a mobile communication system and, more specifically, to a method and an apparatus for dynamically instantiating an API exposing function implemented to provide specific service APIs.

Description

Method and device for supporting service API management in a communication system

[0001] The present disclosure relates to a method for efficiently managing service APIs that can be provided in a communication system. Specifically, the present disclosure relates to a method and device for dynamically instantiating API exposing functions implemented to provide specific service APIs.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz (THz) band (for example, 3 THz band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] The publishing, registration, and discovery of service APIs available through mobile communication systems can be supported through a common API framework. In such a system, the entity that actually provides the service API (e.g., the API exposing function) must be able to dynamically scale service capacity based on actual API request demand. To achieve this, we propose a method for dynamically launching additional instances of a service API provider by acquiring and utilizing information about actual service API demand through the common API framework.

[0009] The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0010] Based on the discussion as described above, the present disclosure provides a method performed by a common application programming interface (API) framework (CAPIF) core function (CCF) of a communication system, comprising: receiving information on whether API exposing function (AEF) instantiation is supported from at least one of an API management function and an API publishing function; receiving a request related to an API from an API invoker; determining the AEF instantiation based on the information on whether the AEF instantiation is supported; performing an operation for the AEF instantiation when the AEF instantiation is determined; and transmitting a response to the request related to the API to the API invoker.

[0011] The above AEF instantiation is characterized by expanding an instance related to the AEF or changing the number of instances related to the AEF.

[0012] In addition, the information on whether the AEF instantiation is supported is characterized by including whether AEF dynamic instantiation is supported.

[0013] Additionally, the request related to the API is characterized in that it includes at least one of an onboard API caller request or a service API discovery request.

[0014] In addition, the method further includes a step of receiving information about an API provider domain management system from at least one of the API management function or the API publishing function,

[0015] A response to a request related to the above API includes at least one of information about a status related to AEF or information about a status related to an AEF service,

[0016] The above AEF-related instance is characterized in that it includes at least one of an AEF instance or an AEF service instance.

[0017] In addition, the present disclosure provides a method performed by an API invoker of a communication system, comprising the steps of: transmitting a request related to an API to a common application programming interface (API) framework (CAPIF) core function (CCF); and receiving a response to the request related to the API from the CCF, wherein, based on information on whether API exposing function (AEF) instantiation is supported, the AEF instantiation is determined by the CCF, and the AEF instantiation is characterized in that it expands an instance related to the AEF or changes the number of instances related to the AEF.

[0018] In addition, the present disclosure includes a common application programming interface (API) framework (CAPIF) core function (CCF) of a communication system, comprising: a transceiver; and a control unit connected to the transceiver, the control unit receiving information on whether API exposing function (AEF) instantiation is supported from at least one of an API management function and an API publishing function, receiving an API-related request from an API invoker, determining AEF instantiation based on the information on whether AEF instantiation is supported, performing an operation for AEF instantiation when the AEF instantiation is determined, and transmitting a response to the API-related request to the API invoker, wherein the AEF instantiation is characterized by expanding an instance related to the AEF or changing the number of instances related to the AEF.

[0019] In addition, the present disclosure relates to an API invoker of a communication system, comprising: a transceiver; and a control unit connected to the transceiver, transmitting a request related to an API to a common application programming interface (API) framework (CAPIF) core function (CCF), and receiving a response to the request related to the API from the CCF, wherein based on information on whether API exposing function (AEF) instantiation is supported, the AEF instantiation is determined by the CCF, and the AEF instantiation is characterized in that it expands an instance related to the AEF or changes the number of instances related to the AEF.

[0020] According to one embodiment of the present disclosure, in a communication system, information on actual service API demand can be acquired and utilized through a common API framework, and an instance of a service API providing device can be additionally dynamically driven.

[0021] The effects that can be obtained from the present disclosure are not limited to the effects mentioned in the various embodiments, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0022] FIG. 1 is a diagram illustrating an example of the structure of a common API (application programming interface) framework (CAPIF) according to one embodiment of the present disclosure.

[0023] FIG. 2 is a diagram illustrating an example of managing an AEF instance or AEF service instance based on API invoker onboarding according to one embodiment of the present disclosure.

[0024] FIG. 3 is a diagram illustrating an example of a CCF receiving a service API discovery request from an API invoker according to an embodiment of the present disclosure, performing an instantiation-related operation to increase an API exposing function (AEF) instance or an AEF service instance based on information obtained from at least one of an API management function (AMNF) or an API publish function (APF).

[0025] FIG. 4 is a diagram illustrating the structure of a network entity according to one embodiment of the present disclosure.

[0026] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings. The terms described below are defined based on their functions in the present invention. These terms may vary depending on the intent or custom of the user or operator, and therefore, their definitions should be determined based on the overall content of this specification.

[0027] In describing the embodiments, descriptions of technical contents that are well known in the technical field to which the present disclosure belongs and are not directly related to the present disclosure are omitted.

[0028] This is to convey the gist of the present disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0029] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect the actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0030] The advantages and features of the present disclosure and the methods for achieving them will become apparent with reference to the embodiments described in detail below together with the accompanying drawings.

[0031] However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided only to complete the composition of the present disclosure and to fully inform those skilled in the art of the disclosure of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

[0032] At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagrams can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flow diagram block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can be directed to a computer or other programmable data processing equipment for implementation in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flow diagram block(s). Since the computer program instructions can also be installed on a computer or other programmable data processing device, a series of operational steps can be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) can also provide steps for performing the functions described in the flowchart block(s).

[0033] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0034] Here, the term '~ unit' used in the present embodiment means software or hardware components such as FPGA (field programmable gate array) or ASIC (application-specific integrated circuit), and the '~ unit' performs certain roles. However, the '~ unit' is not limited to software or hardware. The '~ unit' may be configured to be on an addressable storage medium, and may be configured to play one or more processors. Accordingly, as an example, the '~ unit' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ units' may be combined into a smaller number of components and '~ units', or further separated into additional components and '~ units'. Additionally, the components and '~parts' may be implemented to play one or more central processing units (CPUs) within the device or secure multimedia card.

[0035] For the convenience of the following description, some terms and names defined in the 3rd generation partnership project (3GPP) standards (standards for 5G, NR, LTE, or similar systems) may be used. In addition, terms and names newly defined in next-generation communication systems (e.g., 6G, Beyond 5G systems) to which the present disclosure may be applied, or terms and names used in existing communication systems may be used. The use of such terms is not limited to the terms and names of the present disclosure, and may be equally applied to systems conforming to other standards, and may be modified into other forms without departing from the technical spirit of the present disclosure. Embodiments of the present disclosure may be easily modified and applied to other communication systems.

[0036] Additionally, it will be understood that singular expressions such as “a” and “the above” include plural expressions unless they clearly indicate otherwise in one embodiment of the present disclosure.

[0037] Additionally, in one embodiment of the present disclosure, the size in relation to blocks and the like may be expressed equally in length or size.

[0038] Additionally, in one embodiment of the present disclosure, terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but the components are not limited by these terms. These terms are used solely to distinguish one component from another. For example, without departing from the scope of the present disclosure, a first component could be referred to as a second component, and similarly, a second component could also be referred to as a first component.

[0039] Additionally, in one embodiment of the present disclosure, the term “and / or” includes a combination of a plurality of related described items or any one of a plurality of related described items.

[0040] In addition, the terms used in the embodiments of the present disclosure are only used to describe specific embodiments and are not intended to limit the present disclosure. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this specification, it should be understood that the terms "comprise" or "have" are intended to specify the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not exclude in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0041] Additionally, the terms “associated with” and “associated therewith” and their derivatives used in one embodiment of the present disclosure may mean include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicated with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, and the like.

[0042] Additionally, in the present disclosure, expressions such as "more than" and "less than" are used to determine whether a specific condition is satisfied or fulfilled. However, this is merely a description to express an example and does not exclude descriptions of more than or less than. Conditions described as "more than" may be replaced with "more than," conditions described as "less than" may be replaced with "less than," and conditions described as "more than and less than" may be replaced with "more than and less than."

[0043] Additionally, although the present disclosure describes embodiments using terms used in certain communication standards (e.g., long term evolution (LTE) and new radio (NR) defined by the 3rd generation partnership project (3GPP)), these are merely examples for illustrative purposes. The embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0044] Before delving into the detailed description of this disclosure, examples of possible interpretations of some terms used herein are provided. However, it should be noted that the interpretations provided below are not limited to these examples.

[0045] The terms used in this publication to refer to network entities, common API framework system objects, messages, and identification information are provided for convenience of explanation. Therefore, the present invention is not limited to the terms described below, and other terms that refer to objects with equivalent technical meanings may be used.

[0046] For convenience, the present invention uses terms and names defined in the 5G system standards, but is not limited by the terms and names, and can be equally applied to systems conforming to other standards.

[0047] FIG. 1 illustrates an example of the structure of a common API (application programming interface) framework (CAPIF) according to one embodiment of the present disclosure.

[0048] The system (100) may include one or more API callers (102, 104), a CAPIF core function (CCF) (106), an application program interface exposure function (AEF) (108), an API publishing function (110), and an API management function (112).

[0049] With respect to Fig. 1, the description of each function (device) related to the structure is as follows. The API invoker (or caller) (102, 104) may be a type of client installed in the terminal or a server provided by a third-party application provider that has entered into a service contract with a PLMN operator (or a communication network operator), and may correspond to an entity that calls and uses the service API. For example, an in-terminal client such as an edge enabler client in the terminal, a terminal manufacturer-provided client, or a communication network operator-provided client may correspond to the API invoker. In addition, a server such as an edge enabler server, an edge application server, an edge configuration server, or an Application Function may correspond to the API invoker.

[0050] According to one embodiment, the API invoker (102, 104) can obtain information about the service API it wants to use from the CAPIF core function (CCF) (106).

[0051] According to one embodiment, the CCF (106) may provide (or transmit) an information retrieval service for a service API to the API invoker (102, 104) by storing and publishing service API information. The information for the service API may include information about an API exposing function (AEF) (108) that acts as a communication entry point for calling the corresponding service API. The AEF (108) may correspond to a function (device) that actually supplies the service API to the API invoker. According to one embodiment, the AEF (108) may be implemented as one instance (e.g., an AEF instance (114)), and the AEF (108) may provide multiple service APIs. When the AEF (108) provides multiple service APIs, functions required to provide at least one service API may be implemented as one instance (e.g., an AEF service instance (116, 118, etc.)). AEF may include devices that provide service APIs, such as network functions installed in the operator's network (e.g., network exposure functions), (edge) application servers, or edge enabler servers.

[0052] According to one embodiment, an AEF service implemented as a single instance may be independently managed and instantiated by an API provider domain management system. According to one embodiment, a single AEF instance (114) may be implemented to include multiple AEF service instances, and lifecycle management may be performed for each AEF service instance by the API provider domain management system. The lifecycle management referred to in the present invention may include onboarding, instantiation, termination, etc. for a single instance (a single function instance or an instance of a service provided by a function).

[0053] According to one embodiment, the API publish function (or API publishing function, APF) (110) allows an API provider to register and publish service API information to the CCF so that API callers (102, 104) can search for the service API.

[0054] According to one embodiment, the API management function (112) may enable the API provider to perform monitoring of the service API or auditing (e.g., monitoring or inspection) of the service API call log.

[0055] In connection with one embodiment, an embodiment is disclosed relating to a method for enabling an in-terminal client to act as an API invoker and a method for enabling an in-terminal client to initiate a procedure that an existing API invoker performs with a CCF or AEF.

[0056] According to one embodiment, in addition to the EEC and application clients mentioned as entities that directly or indirectly perform service API invocation (or call) as clients within the terminal, the operation of all other application modules within the terminal or enabler clients for specific services (e.g., Service Enabler Architecture Layer Client, Unmanned Aerial System Application Enabler client, etc.) may also be included in the scope related to one embodiment.

[0057] Each step of the embodiment disclosed in FIG. 2 or FIG. 3 below may be performed with some of the steps omitted, or may be performed in combination.

[0058] FIG. 2 illustrates an example of managing an AEF instance or AEF service instance based on API invoker onboarding according to one embodiment of the present disclosure.

[0059] FIG. 2 illustrates an example in which a CCF, having received an onboarding request from an API invoker, performs instantiation-related operations to increase an API exposing function (AEF) instance or an AEF service instance based on information obtained from at least one of an API management function (AMNF) or an API publish function (APF), according to one embodiment of the present disclosure.

[0060] In step 210 of FIG. 2, CCF (106) and AMNF (112) may perform procedures related to registration of API provider domain functions (e.g., AEF (108), APF (110), etc.), and CCF (106) and APF (110) may perform procedures related to API initiation or API publication. The above steps may be omitted.

[0061] According to one embodiment, the CCF (106) may receive at least one of the following information from the AMNF (112): a List of API provider domain functions (at least one of the AEF (108), the APF (110), and the AMNF (112)), an API provider name, AEF dynamic instantiation support information, API provider domain management system information, and security information for management system API invocation.

[0062] In one embodiment, the AEF dynamic instantiation support information may include at least one of information on whether AEF instance addition expansion (scaling up or scaling out, or increasing the number of instances, etc.) is supported, and whether AEF service dynamic instantiation is supported (or whether increasing the number of instances or scaling out for a specific service or a specific API of AEF is supported).

[0063] According to one embodiment, the API provider domain management system information may include at least one of information such as an address and identifier, available APIs, and API provider ID for a subject device (e.g., an API provider domain management system) that performs overall lifecycle management, including deployment and onboarding, instantiation, termination, etc., for an AEF instance (114) or an AEF service instance (116, 118, etc.) located within a specific API provider domain.

[0064] According to one embodiment, the security information for management system API invocation may include security information required when making a call to a service provided by API provider domain management.

[0065] Additionally, in step 215, the CCF (106) may receive at least one of the following information from the APF (110): API publisher information (e.g., ID, authentication information, authorization information, etc.), service API name, list of public IP ranges of UEs, service API type, service API status, serving area information, AEF location, AEF interface details (IP address, port number, URI (uniform resource identifier)), protocol, instantiation status (instantiated, instantiation in progress, etc.), AEF dynamic instantiation information, or AEF service dynamic instantiation information. The above step may be omitted.

[0066] According to one embodiment, AEF dynamic instantiation information or AEF service dynamic instantiation information may include whether dynamic instantiation is supported for a service (or a specific service API) provided by AEF (108), management system information of the API provider domain to which AEF (108) belongs (e.g., information about a device that performs lifecycle management for AEF), etc.

[0067] According to one embodiment, the information that the APF (110) or AMNF (112) provides to the CCF (106) may include information about a target device for transmitting an instantiation request message for an AEF instantiation or AEF service instantiation operation (e.g., address information of the AMNF (112) or API provider domain management system and security information required at the time of the request, etc.).

[0068] According to one embodiment, when the CCF (106) receives an onboarding request from an API invoker (102, 104), it may request and receive information (e.g., an indication) from the APF (110) or AMNF (112) indicating that it is possible to request dynamic instantiation.

[0069] In step 220 of FIG. 2, the API invoker (102, 104) may transmit an Onboard API invoker request to the CCF (106). The API invoker (102, 104) may provide at least one of information such as APIs for enrollment, expected operation time, bulk onboarding indication, bulk size information, UE information, UE list information, UE group information, UE type information, and expected API invocation frequency to the CCF (106). According to an embodiment, when the API invoker is a device located in a terminal, at least one of terminal-related information (e.g., UE ID, UE IP address, UE capability information, etc.) or UE-related invocation target API list information may be provided to the CCF (106).

[0070] In step 225 of FIG. 2, the CCF (106) may determine whether to approve the onboard request of step 220 of FIG. 2 of the API invoker (102, 104). The above step may be omitted.

[0071] In step 230, if the CCF (106) determines onboarding approval for the API invoker (102, 104), it may determine whether to perform instantiation-related operations on the AEF that the API invoker can call or is permitted to use. The instantiation-related operations on the AEF (108) may include operations for expanding or increasing the number of AEF instances or AEF service instances (or instances providing specific API services provided by the AEF). The CCF (106) may determine to perform instantiation-related operations for expanding or increasing the number of AEF instances (114) or AEF service instances (116, 118, etc.) (or instances providing specific API services provided by the AEF, etc.) based on the information received from the API invoker (102, 104) in step 220 of FIG. 2 and the information received from the APF (110) or AMNF (112) in step 210 or step 215 of FIG. 2. The above steps may be omitted.

[0072] For example, if the CCF (106) receives information that instantiation is supported for a specific AEF instance from the APF (110) or AMNF (112) in step 210 or 215 of the preceding FIG. 2, when an onboarding request comes from the API invoker (102, 104), the CCF (106) can determine whether to perform an instantiation operation for an AEF instance for a certain AEF based on information provided by the API invoker (102, 104) (e.g., at least one of information such as APIs for enrollment, UE information, UE list information, UE group information, and UE type information).

[0073] According to one embodiment, the CCF (106) may determine that the API invoker (102, 104) will call only a specific service or a specific service API provided by the AEF (108) based on the information provided by the API invoker (102, 104), and based on the determination as above, the CCF (106) may decide to perform instantiation-related operations per AEF service instance rather than per AEF instance. For example, the CCF (106) may identify the AEF and the service or service API provided by the AEF based on the call target API information provided by the API invoker (102, 104), determine whether instantiation operation is required or possible per AEF service instance for the corresponding service or service API, and perform the related instantiation operation. To this end, the CCF (106) may consider information received from the APF (110) or AMNF (112) (e.g., AEF dynamic instantiation information or AEF service dynamic instantiation information, etc.) or information on whether instantiation can be performed in units of services or service APIs received from the AEF (108) in the previous step.

[0074] According to one embodiment, the CCF (106) may periodically receive AEF status information or AEF service API status information from the AMNF (112) or the APF (110) to determine whether instantiation is required for a specific AEF or AEF provided service. To this end, the CCF (106) may subscribe to an AEF or AEF service API status information notification service from the APF (110) or the AMNF (112).

[0075] In step 235 of FIG. 2, the CCF (106) may transmit a response message (e.g., onboard API invoker response) to the request message received in step 220 of FIG. 2 to the API invoker (102, 104). The message may include at least one of AEF status or AEF service API status information. The information about the AEF status or AEF service API status may include at least one of status information such as availability of a specific service provided by the AEF or AEF (108), instantiation in progress, etc.

[0076] In step 240 of FIG. 2, the CCF (106) may perform an operation for performing AEF instantiation or AEF service instantiation according to the decision made in step 225 or step 230 of FIG. 2.

[0077] According to one embodiment, the CCF (106) may transmit an instantiation request (e.g., an indirect request message) to the AMNF (112). The request message may include at least one of AEF information, AEF API information, terminal information, bulk size information, etc. The AMNF (112) may transmit an instantiation request to the API provider domain management system based on the information received from the CCF (106).

[0078] According to one embodiment, the CCF (106) may directly transmit an instantiation request message to the API provider domain management system (120) at step 245. The request message may include at least one of AEF information, AEF API information, terminal information, bulk size information, etc. At least one of step 240 or step 245 may be performed or may be omitted.

[0079] According to one embodiment, the CCF (106) may select a target device to which to send an AEF instantiation or AEF service instantiation request message based on information received from the APF (110) or AMNF in step 210 of FIG. 2.

[0080] In step 250, the CCF (106) sends an instantiation request message to the AMNF (112) or the API provider domain management system, and if it confirms that instantiation is in progress, it can update status information for the AEF or AEF service API (e.g., via instantiation in progress). The above step may be omitted.

[0081] In step 255 of FIG. 2, the API provider domain management system (120) that received an instantiation request from the CCF (106) or AMNF (112) can perform AEF instantiation or AEF service instantiation.

[0082] According to one embodiment, the API provider domain management system (120) may perform an instantiation operation to increase instances of the specified AEF or AEF service based on AEF-related information (e.g., service API identifier or name information, AEF identifier or name information, etc.) included in an instantiation request message received from the CCF (106) or the AMNF (112). In addition, when the API provider domain management system receives information that may indicate the degree of call demand for services that the AEF can provide, such as terminal list information, expected operation time, bulk size information, etc., from the CCF (106) or the AMNF (112), the API provider domain management system may determine how much the AEF instance (114) or the AEF service instance (116, 118, etc.) should be increased (e.g., how many instances should be driven through the instantiation operation, etc.).

[0083] According to one embodiment, the API provider domain management system (120) may perform an instantiation operation (AEF instantiation or AEF service instantiation) for the AEF or AEF service determined through the preceding operation.

[0084] In step 260 of FIG. 2, the API provider domain management system may transmit a response message to the request message received in step 240 or step 245 of FIG. 2 to AMNF (112) or CCF (106). The response message may include at least one of information indicating that instantiation has been completed or information indicating that instantiation has been determined and is in progress.

[0085] According to one embodiment, through step 265, the CCF (106) may update the status information of the AEF or the AEF service API status information based on the information included in the response message received from the AMNF (112) or the API provider domain management system. For example, when the CCF (106) receives instantiation completion information for the AEF or the AEF-provided service API from the AMNF or the API provider domain management system, the CCF (106) may update the status information of the AEF or the AEF service API status information to available or instantiation completed. The above step may be omitted.

[0086] In one embodiment, the CCF (106) may notify the API invoker (102, 104) that can use the AEF or AEF service API of updated service API status information when necessary or in certain circumstances (e.g., when the API invoker (102, 104) makes a subscription request to the CCF (106) for AEF status information or AEF service API status information).

[0087] FIG. 3 illustrates an example in which a CCF (106), having received a service API discovery request from an API invoker (102, 104), performs an instantiation-related operation to increase an API exposing function (AEF) instance or an AEF service instance based on information obtained from at least one of an API management function (AMNF) (112) or an API publish function (APF) (110), according to one embodiment of the present disclosure.

[0088] In step 310 of FIG. 3, CCF (106) and AMNF (112) may perform procedures related to registration of API provider domain functions (e.g., AEF, APF, etc.), and CCF (106) and APF (110) may perform procedures related to API initiation or API publication. The above steps may be omitted.

[0089] According to one embodiment, the CCF (106) may receive at least one of the following information from the AMNF (112): a List of API provider domain functions (at least one of AEF, APF, and AMNF), an API provider name, AEF dynamic instantiation support information, API provider domain management system information, security information for management system API invocation, etc.

[0090] In one embodiment, the AEF dynamic instantiation support information may include at least one of information on whether AEF instance addition expansion (scaling up or scaling out, or increasing the number of instances, etc.) is supported, and whether AEF service dynamic instantiation is supported (or whether increasing the number of instances or scaling out for a specific service or a specific API of AEF is supported).

[0091] According to one embodiment, the API provider domain management system information may include at least one of information such as an address and identifier, available APIs, and API provider ID for a subject device (e.g., an API provider domain management system) that performs overall lifecycle management, including deployment and onboarding, instantiation, termination, etc., for an AEF instance (114) or an AEF service instance (116, 118, etc.) located within a specific API provider domain.

[0092] According to one embodiment, the security information for management system API invocation may include security information required when making a call to a service provided by API provider domain management.

[0093] In step 315, the CCF (106) may receive at least one of the following information from the APF (110): API publisher information (e.g., ID, authentication information, authorization information, etc.), service API name, list of public IP ranges of UEs, service API type, service API status, serving area information, AEF location, AEF interface details (IP address, port number, URI), protocol, instantiation status (instantiated, instantiation in progress, etc.), AEF dynamic instantiation information, or AEF service dynamic instantiation information. The above step may be omitted.

[0094] In one embodiment, AEF dynamic instantiation information or AEF service dynamic instantiation information may include information such as whether dynamic instantiation is supported for a service (or a specific service API) provided by AEF, management system information of the API provider domain to which AEF belongs (e.g., information about a device that performs lifecycle management for AEF), etc.

[0095] According to one embodiment, the information that the APF (110) or AMNF (112) provides to the CCF (106) may include information about the target device for transmitting an instantiation request message for AEF instantiation or AEF service instantiation operation (e.g., address information of the AMNF or API provider domain management system and security information required at the time of the request, etc.).

[0096] According to one embodiment, when the CCF (106) receives a service API discovery request from an API invoker (102, 104), etc., the CCF (106) may request and receive information (e.g., indication) indicating that dynamic instantiation can be requested as needed from the APF (110) or AMNF (112).

[0097] In step 320 of FIG. 3, the API invoker (102, 104) may transmit a service API discovery request to the CCF (106). The API invoker (102, 104) may provide at least one of the following information to the CCF (106): service API information, AEF information, API invoker ID, preferred AEF location, service API KPI, bulk size information, UE information (identifier or IP address), UE list information, UE group information, UE type information, expected API invocation frequency, etc. When the API invoker (102, 104) is a device located in a terminal, at least one of terminal-related information (e.g., UE ID, UE IP address, UE capability information, etc.) or UE-related invocation target API list information may be provided to the CCF (106).

[0098] In step 325 of FIG. 3, the CCF (106) may determine whether to approve the service API discovery request of step 320 of FIG. 3 from the API invoker (102, 104), and may collect service API information corresponding to the requested information from the API registry. The above step may be omitted.

[0099] At step 330, if the CCF (106) determines from the APF (110) or AMNF (112) that the API invoker (102, 104) has a service API discovery request, the CCF (106) may determine whether to perform instantiation-related actions on the AEF that the API invoker (102, 104) can call or is permitted to use. The instantiation-related actions on the AEF may include actions to expand or increase the number of AEF instances (114) or AEF service instances (116, 118, etc.) (or instances that provide specific API services provided by the AEF). CCF (106) may decide to perform instantiation-related operations to expand or increase the number of AEF instances or AEF service instances (or instances providing specific API services provided by AEF, etc.) by considering the information received from the API invoker (102, 104) in step 320 of FIG. 3 and the information received from the APF (110) or AMNF (112) in step 310 or step 315 of FIG. 3. The above step may be omitted.

[0100] For example, if the CCF (106) receives information that instantiation is supported for a specific AEF instance from the APF (110) or AMNF (112) in step 310 of the preceding FIG. 3, when a service API discovery request comes from the API invoker (102, 104), the CCF (106) can determine whether to perform an instantiation operation for an AEF instance for a certain AEF based on information provided by the API invoker (102, 104) (e.g., at least one of request API information, UE information, UE list information, UE group information, UE type information, preferred AEF location, service API KPI, etc.).

[0101] According to one embodiment, the CCF (106) may determine that the API invoker (102, 104) will call only for a specific service or a specific service API provided by AEF that is the target of the service API discovery request, and based on the determination as above, the CCF (106) may decide to perform instantiation-related operations per AEF service instance rather than per AEF instance. For example, the CCF (106) may identify AEF and a service or service API provided by AEF based on the service API discovery target API information provided by the API invoker (102, 104), determine whether an instantiation operation is necessary and possible per AEF service instance for the corresponding service or service API, and perform the related instantiation operation. To this end, the CCF (106) may consider information received from the APF (110) or AMNF (e.g., AEF dynamic instantiation information or AEF service dynamic instantiation information, etc.) or information on whether instantiation can be performed in units of services or service APIs received from the AEF in the previous step.

[0102] In one embodiment, the CCF (106) may periodically receive AEF status information or AEF service API status information from the AMNF (112) or the APF (110) to determine whether instantiation is required for a specific AEF or AEF-provided service. To this end, the CCF may subscribe to an AEF or AEF service API status information notification service from the APF (110) or the AMNF (112).

[0103] According to one embodiment, the CCF (106) may receive information about the time required to run a specific AEF instance (114) or AEF service instance (e.g., AEF instantiation or AEF service instantiation time, etc.) from the APF (110), AMNF (112), or API provider domain management system, and may determine the timing of an AEF instantiation (or AEF service instantiation) request based on the information. For example, the CCF may determine whether to perform instantiation-related actions upon receiving an onboarding request from an API invoker (102, 104) or whether to perform instantiation-related actions upon receiving a service API discovery request from an API invoker (102, 104) based on the AEF instantiation (or AEF service instantiation) time.

[0104] In step 335 of FIG. 3, the CCF (106) may perform an operation for performing AEF instantiation or AEF service instantiation according to the decision made in step 325 or 330 of FIG. 3.

[0105] According to one embodiment, the CCF (106) may transmit an instantiation request (e.g., an indirect request message) to the AMNF (112). The request message may include at least one of AEF information, AEF API information, terminal information, bulk size information, etc. The AMNF (112) may transmit an instantiation request to the API provider domain management system based on the information received from the CCF (106). The above step may be omitted.

[0106] Alternatively, in step 340, the CCF (106) may directly transmit an instantiation request message to the API provider domain management system. The request message may include at least one of AEF information, AEF API information, terminal information, and bulk size information. The above step may be omitted.

[0107] According to one embodiment, the CCF (106) may select a target device to which to send an AEF instantiation or AEF service instantiation request message based on information received from the APF (110) or AMNF (112) in step 310 or 315 of FIG. 3.

[0108] In step 345, the CCF (106) sends an instantiation request message to the AMNF or API provider domain management system (120), and if it confirms that instantiation is in progress, it can update status information for the AEF or AEF service API (e.g., via instantiation in progress). The above step may be omitted.

[0109] In step 350 of FIG. 3, the API provider domain management system (120) that received an instantiation request from the CCF (106) or the AMNF (112) can perform AEF instantiation or AEF service instantiation. The API provider domain management system (120) can specify an AEF or AEF service based on AEF-related information (e.g., service API identifier or name information, AEF identifier or name information, etc.) included in the instantiation request message received from the CCF or the AMNF, and perform an instantiation operation to increase an instance of the specified AEF or AEF service. In addition, when the API provider domain management system (120) receives information that can indicate the level of call demand for services that AEF can provide, such as terminal list information, expected operation time, bulk size information, etc., from the CCF (106) or AMNF (112), it can determine how much to increase the number of AEF instances (114) or AEF service instances (116, 118, etc.) (e.g., how many instances to run through instantiation operations, etc.) based on the information.

[0110] According to one embodiment, the API provider domain management system (120) may perform an instantiation operation (AEF instantiation or AEF service instantiation) for the AEF or AEF service determined through the preceding operation.

[0111] In step 355 of FIG. 3, the API provider domain management system (120) may transmit a response message to the request message received in step 335 or 340 of FIG. 3 to AMNF (112) or CCF (106). The response message may include at least one of information indicating that instantiation has been completed or information indicating that instantiation has been determined and is in progress.

[0112] In step 360, the CF (106) may update the status information of the AEF or the AEF service API based on the information included in the response message received from the AMNF (112) or the API provider domain management system. For example, if the CCF receives instantiation completion information for the AEF or the AEF-provided service API from the AMNF (112) or the API provider domain management system, the CCF may update the status information of the AEF or the AEF service API to available or instantiation completed. The above step may be omitted.

[0113] In step 365 of FIG. 3, the CCF (106) may transmit a response message (e.g., service API discovery response) to the request message received in step 320 of FIG. 3 to the API invoker (102, 104). The message may include at least one of AEF status or AEF service API status information. Information about AEF status or AEF service API status may include at least one of status information such as availability of AEF or a specific service provided by AEF, instantiation in progress, etc.

[0114] FIG. 4 is a diagram illustrating the structure of a network entity according to one embodiment of the present disclosure.

[0115] The network entity illustrated in FIG. 4 may refer to an entity within a communication system to which the present disclosure may be applied. For example, it may refer to any of the network entities illustrated in FIGS. 1 to 3.

[0116] Referring to FIG. 4, a network entity may include a control unit (410) and a transceiver unit (420). In the present disclosure, the control unit may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0117] The transmitter / receiver (420) may be composed of a transmitter (423) and a receiver (426), and may transmit and receive signals with other network entities through the transmitter (423) and receiver (426).

[0118] The control unit (410) can control the overall operation of a network entity according to the embodiment proposed in the present disclosure. For example, the control unit (410) can control the signal flow between each block to perform operations according to the flowchart described above.

[0119] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0120] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of the present invention.

[0121] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage device, magnetic cassette. Or, they may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0122] Additionally, the program may be stored in an attachable storage device that is accessible via a communication network such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present invention via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present invention.

[0123] Meanwhile, the order of description in the drawings explaining the method of the present disclosure does not necessarily correspond to the order of execution, and the order of precedence may be changed or executed in parallel.

[0124] Alternatively, the drawings illustrating the method of the present disclosure may omit some components and include only some components without detracting from the essence of the present invention.

[0125] In the specific embodiments of the present disclosure described above, components included in the invention are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0126] While the detailed description of the present invention has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

Claims

1. In a method performed by a common application programming interface (API) framework (CAPIF) core function (CCF) of a communication system, A step of receiving information on whether API exposing function (AEF) instantiation is supported from at least one of the API management function and the API publishing function; A step of receiving an API-related request from an API invoker; A step of determining the AEF instantiation based on information on whether the AEF instantiation is supported; If the AEF instantiation is determined, a step of performing an operation for the AEF instantiation; and A step of transmitting a response to a request related to the API to the API caller, A method characterized in that the above AEF instantiation expands an instance related to the AEF or changes the number of instances related to the AEF.

2. In paragraph 1, A method characterized in that the information on whether the above AEF instantiation is supported includes whether AEF dynamic instantiation is supported.

3. In paragraph 1, A method characterized in that the request related to the above API includes at least one of an onboard API caller request or a service API discovery request.

4. In paragraph 1, Further comprising a step of receiving information about an API provider domain management system from at least one of the API management function or the API publishing function, A response to a request related to the above API includes at least one of information about a status related to AEF or information about a status related to an AEF service, A method characterized in that the instance related to the AEF comprises at least one of an AEF instance or an AEF service instance.

5. In a method performed by an API caller of a communication system, A step of transmitting an API-related request to a common application programming interface (API) framework (CAPIF) core function (CCF); and A step of receiving a response to a request related to the API from the CCF, Based on information about whether API exposing function (AEF) instantiation is supported, the AEF instantiation is determined by the CCF, A method characterized in that the above AEF instantiation expands an instance related to the AEF or changes the number of instances related to the AEF.

6. In paragraph 5, A request related to the above API includes at least one of an onboard API caller request or a service API discovery request, A method characterized in that the information on whether the above AEF instantiation is supported includes whether AEF dynamic instantiation is supported.

7. In paragraph 5, A response to a request related to the above API includes at least one of information about a status related to AEF or information about a status related to an AEF service, A method characterized in that the instance related to the AEF comprises at least one of an AEF instance or an AEF service instance.

8. In the common application programming interface (API) framework (CAPIF) core function (CCF) of the communication system, Transmitter and receiver; and A control unit connected to the above-mentioned transceiver, receiving information on whether API exposing function (AEF) instantiation is supported from at least one of an API management function or an API publishing function, receiving an API-related request from an API invoker, determining the AEF instantiation based on the information on whether the AEF instantiation is supported, performing an operation for the AEF instantiation when the AEF instantiation is determined, and transmitting a response to the API-related request to the API invoker, The above AEF instantiation is characterized by expanding an instance related to the AEF or changing the number of instances related to the AEF.

9. In paragraph 8, CCF characterized in that the information on whether the above AEF instantiation is supported includes whether AEF dynamic instantiation is supported.

10. In paragraph 8, CCF, characterized in that the request related to the above API includes at least one of an onboard API caller request or a service API discovery request.

11. In paragraph 8, The control unit further receives information about the API provider domain management system from at least one of the API management function or the API publishing function, A response to a request related to the above API includes at least one of information about a status related to AEF or information about a status related to an AEF service, A CCF characterized in that the instance related to the above AEF comprises at least one of an AEF instance or an AEF service instance.

12. For API callers of the communication system, Transmitter and receiver; and Connected to the above transmitter and receiver, transmits API-related requests to the common application programming interface (API) framework (CAPIF) core function (CCF), and A control unit for receiving a response to a request related to the API from the CCF, Based on information about whether API exposing function (AEF) instantiation is supported, the AEF instantiation is determined by the CCF, An API caller characterized in that the above AEF instantiation extends an instance related to AEF or changes the number of instances related to AEF.

13. In paragraph 12, An API caller characterized in that the information on whether the above AEF instantiation is supported includes whether AEF dynamic instantiation is supported.

14. In paragraph 12, An API caller characterized in that the request related to the above API includes at least one of an onboard API caller request or a service API discovery request.

15. In paragraph 12, A response to a request related to the above API includes at least one of information about a status related to AEF or information about a status related to an AEF service, An API caller characterized in that the instance related to the above AEF includes at least one of an AEF instance or an AEF service instance.

Images