Method and apparatus for supporting access to network capability exposure service for a ue

Abstract

The present disclosure relates to a communication technique and a system for integrating a 5G communication system with IoT technology to support higher data transmission rates than those of a 4G system. The present disclosure relates to a wireless communication system, and more specifically, the present disclosure relates to an application layer network structure and a method for providing edge computing services in a cellular wireless communication system (5G System). A method for supporting a network function opening service of a terminal according to one embodiment of the present invention may include: a step of transmitting a first request message including a serving PLMN ID to a first network entity; a step of receiving a first response message from the first network entity including first information related to network function opening of a serving PLMN corresponding to the serving PLMN ID; a step of transmitting a second request message to a second network entity, wherein the second request message includes at least one of a terminal ID, the serving PLMN ID, or an AC profile; a step of receiving a second response message from the second network entity including second information related to network function opening corresponding to at least one of the serving PLMN ID or the AC profile; and a step of calling an API based on the first information and the second information.

Description

Technology Field

[0001] The present disclosure relates to the field of wireless communication, and in particular to a method and apparatus for supporting network function opening services for a terminal using a common application program interface framework (common API framework: CAPIF). Background Technology

[0003] Efforts are being made to develop improved 5G communication systems or pre-5G communication systems to meet the increasing demand for wireless data traffic following the commercialization of 4G communication systems. For this reason, 5G communication systems or pre-5G communication systems are referred to as systems beyond 4G networks or systems after LTE systems.

[0004] To achieve high data transmission rates, 5G communication systems are being considered for implementation in the mmWave band (e.g., the 60 GHz band). To mitigate path loss and increase the transmission distance of radio waves in the mmWave band, beamforming, massive MIMO, full Dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and large-scale antenna technologies are being discussed for 5G communication systems.

[0005] In addition, to improve the network of the system, the development of technologies such as advanced small cell, advanced small cell, cloud radio access network (cloud RAN), ultra-dense network, Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation is taking place in 5G communication systems.

[0006] In addition, advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), as well as advanced access technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access) are being developed in 5G systems.

[0007] Meanwhile, 3GPP, which is responsible for cellular mobile communication standards, is proceeding with standardization by naming a new core network structure as 5G Core (5GC) in order to evolve from the existing 4G LTE system to the 5G system.

[0008] 5GC supports the following differentiated features compared to the Evolved Packet Core (EPC), the network core for existing 4G.

[0009] First, the Network Slice function is introduced in 5GC. As a requirement for 5G, 5GC must support various types of terminals and services; e.g., enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communications (URLC), and Massive Machine Type Communications (mMTC). Each of these terminals / services has different requirements for the core network. For instance, eMBB services require high data rates, while URLLC services require high stability and low latency. The Network Slice method is a technology proposed to satisfy these diverse service requirements.

[0010] Network slicing is a method of creating multiple logical networks by virtualizing a single physical network, and each Network Slice Instance (NSI) can have different characteristics. Therefore, by having a Network Function (NF) suited to each NSI, various service requirements can be satisfied. By allocating an NSI that matches the characteristics of the service required by each terminal, various 5G services can be efficiently supported.

[0011] Second, 5GC facilitates support for the network virtualization paradigm by separating mobility management and session management functions. In existing 4G LTE, all terminals could receive services from the network through signaling exchanges with a single core device called a Mobility Management Entity (MME), which was responsible for registration, authentication, mobility management, and session management functions. However, in 5G, as the number of terminals increases explosively and the mobility and traffic / session characteristics that need to be supported become more segmented depending on the terminal type, supporting all functions in a single device like an MME inevitably leads to reduced scalability, which requires adding entities for each necessary function. Therefore, to improve scalability in terms of the functional / implementation complexity and signaling load of the core device responsible for the control plane, various functions are being developed based on a structure that separates mobility management and session management functions. The problem to be solved

[0013] The present disclosure proposes a method for configuring relevant information in a terminal that is necessary for a client within the terminal to directly or indirectly access network open services supported by a 3GPP core network.

[0014] The present disclosure proposes a method for authenticating whether a terminal can use network open services in order to configure relevant information necessary to directly or indirectly access network open services supported by a 3GPP core network on the terminal. means of solving the problem

[0016] A method for supporting a network function opening service of a terminal according to one embodiment of the present invention may include: a step of transmitting a first request message including a serving PLMN ID to a first network entity; a step of receiving a first response message from the first network entity including first information related to network function opening of a serving PLMN corresponding to the serving PLMN ID; a step of transmitting a second request message to a second network entity, wherein the second request message includes at least one of a terminal ID, the serving PLMN ID, or an AC profile; a step of receiving a second response message from the second network entity including second information related to network function opening corresponding to at least one of the serving PLMN ID or the AC profile; and a step of calling an API based on the first information and the second information.

[0017] A terminal for supporting a network function opening service according to one embodiment of the present invention may include: a transceiver; and a control unit that controls the transceiver to transmit a first request message including a serving PLMN ID to a first network entity, controls the transceiver to receive a first response message including first information related to network function opening of a serving PLMN corresponding to the serving PLMN ID from the first network entity, controls the transceiver to transmit a second request message to a second network entity, wherein the second request message includes at least one of a terminal ID, the serving PLMN ID, or an AC profile, controls the transceiver to receive a second response message including second information related to network function opening corresponding to at least one of the serving PLMN ID or the AC profile from the second network entity, and calls an API based on the first information and the second information. Effects of the invention

[0019] According to the present disclosure, by having the terminal participate in the use of a network open service, it is easy to reflect the service status of a client within the terminal, and the terminal can directly perform management regarding the provision of terminal and subscriber information of said terminal stored within the network to the outside. Brief explanation of the drawing

[0021] FIG. 1 is a diagram showing an application layer network structure and interface supporting edge computing according to one embodiment of the present disclosure. FIG. 2 is a diagram showing the network structure and interface of a 5G system according to one embodiment of the present disclosure. FIG. 3 is a diagram showing the structure of a common application program interface framework according to one embodiment of the present disclosure. FIG. 4 is a diagram illustrating a procedure for transmitting configuration information necessary to use a network function opening service according to one embodiment of the present disclosure to a terminal. FIG. 5 is a diagram illustrating a procedure for setting information related to a network function opening service in a UDM according to one embodiment of the present disclosure. FIG. 6 is a diagram illustrating a procedure for setting information related to a network function opening service in a UDR according to one embodiment of the present disclosure. FIG. 7 is a diagram illustrating a procedure for transmitting information related to network function opening services through an edge enabler layer according to one embodiment of the present disclosure. FIG. 8 is a diagram illustrating an indirect API call procedure of the EEC to an NEF or AEF according to one embodiment of the present disclosure. FIG. 9 is a diagram illustrating an indirect API call procedure of the EEC to the CCF according to one embodiment of the present disclosure. FIG. 10 is a diagram illustrating the procedure for calling an API of the EEC for an NEF according to one embodiment of the present disclosure. FIG. 11 is a diagram showing the configuration of a terminal according to one embodiment of the present disclosure. FIG. 12 is a diagram showing the configuration of a network entity according to one embodiment of the present disclosure. Specific details for implementing the invention

[0022] Embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. Furthermore, in describing the present disclosure, detailed descriptions of related known functions or configurations are omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the present disclosure. Additionally, terms used below are defined in consideration of their functions in the present invention, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout this specification. For the same reason, some components in the accompanying drawings are exaggerated, omitted, or schematically depicted. Furthermore, the size of each component does not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numeral. The advantages and features of the technical concept according to the present disclosure, and the methods for achieving them, will become clear by referring to the embodiments described in detail below with reference to the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the present disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components. Furthermore, in describing the present disclosure, if it is determined that a detailed description of a related function or configuration might unnecessarily obscure the essence of the technical concept according to the present disclosure, such detailed description is omitted. Additionally, the terms described below are defined considering their functions in the present disclosure, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout the specification.

[0023] Hereinafter, the base station is an entity that performs resource allocation for terminals and may be at least one of an eNode B, Node B, BS (Base Station), RAN (Radio Access Network), AN (Access Network), RAN node, wireless access unit, base station controller, or a node on a network. The terminal may include a UE (User Equipment), MS (Mobile Station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. In the present invention, the downlink (DL) refers to the wireless transmission path of a signal transmitted by the base station to the terminal, and the uplink (UL) refers to the wireless transmission path of a signal transmitted by the terminal to the base station. Furthermore, although the embodiments of the present disclosure are described below using an LTE or LTE-A system as an example, the embodiments of the present disclosure may be applied to other communication systems having similar technical backgrounds or channel types. For example, 5th generation mobile communication technology (5G, new radio, NR) developed after LTE-A may be included in a system to which the embodiments of the present disclosure can be applied, and the 5G below may be a concept that includes existing LTE, LTE-A, and other similar services. Furthermore, the embodiments of the present disclosure may be applied to other communication systems with some modifications made at the discretion of a person skilled in the art, without departing significantly from the scope of the present invention. In this case, it will be understood that each block of the processing flowcharts and combinations of the flowcharts may be executed by computer program instructions.

[0024] Since these computer program instructions can be loaded onto the processor of a general-purpose computer, a computer for special purposes, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means for performing the functions described in the flowchart block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement functions in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing means of instruction for performing the functions described in the flowchart block(s). Since the computer program instructions can also be loaded onto the computer or other programmable data processing equipment, the instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a computer-executable process can also provide steps for performing the functions described in the flowchart block(s).

[0025] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). Also, it should be noted that in some alternative examples of execution, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order according to the corresponding function. In this case, the term “part” as used in the embodiments of the present disclosure refers to software or hardware components such as a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), and the “part” may perform certain roles. However, the “part” is not limited to software or hardware. The “part” may be configured to reside in an addressable storage medium or may be configured to run one or more processors. Accordingly, as an example, 'part' includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, 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 'parts' may be combined into a smaller number of components and 'parts' or further separated into additional components and 'parts'. Furthermore, the components and 'parts' may be implemented to utilize one or more CPUs within a device or secure multimedia card. Additionally, in an embodiment, 'part' may include one or more processors.

[0026] Terms used in this disclosure to refer to network entities and objects of edge computing systems, terms to refer to messages, terms to refer to identification information, etc., are examples provided for convenience of explanation. Accordingly, this disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0027] For convenience, the present disclosure uses terms and names defined in 5G system specifications, but is not limited to the said terms and names and can be applied in the same way to systems conforming to other specifications.

[0029] FIG. 1 is a diagram showing an application layer network structure and interface supporting edge computing according to one embodiment of the present disclosure.

[0030] Referring to FIG. 1, a terminal (User Equipment, UE) (101) may include at least one application client (AC) (102) and an edge enabler client (EEC) (103). The application client (102) may be an application-level client to be provided to a user when an edge computing service is provided.

[0031] Additionally, the terminal (101) may include a communication processor (CP) (not shown) for communicating with another wireless communication network, for example, at least one or two mobile communication networks.

[0032] The 3GPP network (104) is exemplified as a representative mobile communication network and may include, for example, an EPC and / or 5GC. The 3GPP network (104) may include base stations that communicate directly with the terminal (101) over-the-air (OTA) and may include a core network configuration above them. If the 3GPP network includes a 5GC, it may include an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Policy Control Function (PCF), a User Plane Function (UPF), etc.

[0033] In addition, if the EPC is used as the Core Network (CN), it may include network nodes corresponding to 5GC.

[0034] Additionally, Edge Data Networks can be implemented through network slicing techniques, and Edge Data Networks can all be configured in the same form. Taking the configuration of one Edge Data Network (105) as an example, it may include an Edge Hosting Platform, an Edge Enabler Server (EES) (107), one or more Edge Application Servers (EAS) (106), and an Orchestrator for Edge Hosting Platform. Additionally, the Edge Enabler Server (106) may include an Edge Enabler Client Manager, an Edge Enabler Platform, and an Edge Enabler API Server.

[0035] Network functions can be defined as follows, some of which are illustrated in FIG. 1.

[0036] 3GPP network (104): May include a 3GPP Radio Access Network (RAN) and a core network.

[0037] One or more Edge Data Networks (105): Data networks of 5G core networks or packet data networks of EPC networks, which may be data networks that include functions for providing edge computing services such as Edge Hosting Platform Edge Enabler Servers.

[0038] One or more application clients (AC) (102): Applications that run on the mobile operating system of the terminal (101), which can be identified as an application identifier in the 5G core network, and in an environment that provides a mobile operating system, the AC can be identified as an operating system identifier (OS Identifier) ​​and an application identifier unique to each operating system (OSAppID).

[0039] One or more Edge Application Servers (Edge Application Server or Edge Application, EAS) (106): Application server programs that run on a virtual machine (VM) image or virtualization container running in an Edge Hosting Environment, which may be server programs that are executed by objectifying a VM image and may be called Edge Applications.

[0040] Edge Configuration Server (ECS) (108): A server that provides configuration information for an edge data network (105) to a terminal (101), and may be an initial connection server that can receive configuration information for the terminal (101) to use mobile edge computing (MEC) services.

[0041] Edge Hosting Platform: May be platform software that includes a virtualization layer capable of running multiple edge applications. In this disclosure, Edge Hosting Platform may be used interchangeably with Edge Hosting Environment.

[0042] Orchestrator for Edge Hosting Platform: This may be a management system that manages the edge hosting platform and the lifecycle of edge applications running on the edge hosting platform. It may perform the functions of an orchestrator as defined by ETSI MANO (European Telecommunication Standards Institute Management and Network Operation).

[0043] Edge Enabler Server (EES) (107): A server for providing edge computing services, which may be a server that provides a list of applications available on an edge hosting platform to a terminal (101) (Edge Enabler Client Manager), manages configuration information for edge applications running on an edge computing hosting platform, and provides an Application Programming Interface (API) to edge applications for functions provided by the 3GPP network.

[0044] Edge Enabler Client (EEC) (103): A software module of a terminal (101), which may be a software agent having functions for providing edge computing services. It may perform functions such as an authentication function for accessing the edge computing server of the terminal, a function to obtain connection information for the edge data network (105) and EES (107) in conjunction with ECS (108), a function to obtain information about one or more EAS (106) from EES (107), and a function to route traffic from one or more ACs (102) within the terminal to one or more EAS (106) based on information about one or more EAS (106).

[0045] The application network structure for edge computing support of FIG. 1 can be managed by a mobile communication operator and a separate edge computing operator, and as a result, multiple separate edge computing operators may exist within a single mobile communication operator network. The application layer network structure for edge computing support of FIG. 1 can support the configuration of such operators.

[0046] The application layer network structure disclosed in FIG. 1 can support multiple edge computing operators within a single mobile communication network. The application layer network structure can transmit configuration information to a terminal for connecting to multiple edge computing service providers available within a single mobile communication network and edge computing networks installed by the providers.

[0047] The application layer network structure disclosed in FIG. 1 can transmit configuration information to a terminal for connecting to an edge network service provider selected by the mobile communication operator among a plurality of edge computing operators existing within a single mobile communication network and an edge computing network installed by the selected edge network service provider.

[0049] FIG. 2 is a diagram showing a network structure and interface of a 5G system according to one embodiment of the present disclosure. A network entity included in the network structure of the 5G system of FIG. 2 may include a network function (NF) depending on the system implementation.

[0050] Referring to FIG. 2, the network structure of the 5G system (200) may include various network entities. For example, the 5G system (200) may include an access and mobility management function (core) access and mobility management function (AMF) (203), a session management function (SMF) (204), a policy control function (PCF) (208), an application function (AF) (209), unified data management (UDM) (207), a data network (DN) (206), a user plane function (UPF) (205), a radio access network (R)AN) (202), and a terminal, i.e., a user device (UE) (201).

[0051] Each NF of the 5G system (200) supports the following functions.

[0052] The AMF (203) provides functions for managing connectivity and mobility at the UE level, and can be connected to one AMF per UE by default. Specifically, the AMF (203) provides signaling between CN nodes for mobility between 3GPP access networks, termination of radio access network (RAN) CP interfaces (i.e., N2 interfaces), termination of NAS (non-access stratum) signaling (N1), NAS signaling security (NAS ciphering and integrity protection), AS security control, registration management (registration area management), connection management, idle mode UE reachability (including control and execution of paging retransmission), mobility management control (subscription and policy), support for intra-system mobility and inter-system mobility, support for network slicing, SMF selection, lawful intercept (for AMF events and interfaces to LI systems), provision of session management (SM) message delivery between the UE and the SMF, transparent proxy for SM message routing, access authentication, access authorization including roaming authorization checks, and the UE and It supports functions such as providing SMS message delivery between SMSFs, security anchor function (SAF), and / or security context management (SCM). Some or all of the functions of the AMF (103) may be supported within a single instance of a single AMF.

[0053] DN (206) means, for example, operator services, internet access, or third-party services. DN (206) transmits a downlink protocol data unit (PDU) to UPF (205) or receives a PDU transmitted from UE (201) from UPF (205).

[0054] The PCF (208) receives information about packet flow from the application server and provides the function of determining policies such as mobility management and session management. Specifically, the PCF (208) supports functions such as supporting a unified policy framework for controlling network behavior, providing policy rules so that control plane function(s) (e.g., AMF, SMF, etc.) can enforce policy rules, and implementing a front end to access relevant subscription information for policy decisions within the user data repository (UDR).

[0055] The SMF (204) provides session management functions, and if a UE has multiple sessions, each session can be managed by a different SMF. Specifically, the SMF (204) supports session management (e.g., session establishment, modification, and termination, including maintaining a tunnel between the UPF (205) and (R)AN (202) nodes), UE IP address allocation and management (optional authentication), selection and control of UP functions, traffic steering setup for routing traffic from the UPF (205) to appropriate destinations, termination of interfaces toward policy control functions, enforcement of policy and QoS (quality of service) control parts, lawful interception (for SM events and interfaces to LI systems), termination of SM parts of NAS messages, downlink data notification, initiation of AN-specific SM information (transmitted to (R)AN (202) via N2 through the AMF (203)), determination of the session's SSC mode, roaming functions, etc. Some or all of the functions of the SMF (204) can be supported within a single instance of the SMF.

[0056] The UDM (207) stores user subscription data, policy data, etc. The UDM (207) includes two parts: an application front end (FE) (not shown) and a user data repository (UDR) (not shown).

[0057] UPF (205) transmits downlink PDUs received from DN (206) to UE (201) via (R)AN (202) and transmits uplink PDUs received from UE (201) to DN (206) via (R)AN (202). Specifically, the UPF (205) supports functions such as an anchor point for intra / inter RAT mobility, an external PDU session point for interconnection to a data network, packet routing and forwarding, packet inspection and policy rule enforcement in the user plane, lawful intercept, traffic usage reporting, an uplink classifier to support routing of traffic flows to a data network, a branching point to support multi-homed PDU sessions, QoS handling for the user plane (e.g., packet filtering, gating, uplink / downlink rate enforcement), uplink traffic verification (SDF mapping between service data flow (SDF) and QoS flow), transport level packet marking within the uplink and downlink, downlink packet buffering, and downlink data notification triggering. Some or all of the functions of UPF (205) can be supported within a single instance of UPF.

[0058] AF (209) interacts with the 3GPP core network to provide services (e.g., support for application impact on traffic routing, access to network capability exposure, and interaction with policy frameworks for policy control).

[0059] (R)AN(202) is a general term for a new radio access network that supports both evolved E-UTRA, which is an evolved version of 4G radio access technology, and new radio access technology (new radio: NR) (e.g., gNB).

[0060] The gNB provides functions for radio resource management (i.e., radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to UEs on uplink / downlink (i.e., scheduling)), IP (Internet Protocol) header compression, encryption and integrity protection of user data streams, selection of an AMF upon UE attachment when routing to an AMF is not determined from information provided to the UE, routing of user plane data to UPF(s), routing of control plane information to an AMF, connection setup and termination, scheduling and transmission of paging messages (originating from the AMF), scheduling and transmission of system broadcast information (originating from the AMF or operation and maintenance: O&M), measurement and measurement reporting setup for mobility and scheduling, transport-level packet marking on the uplink, session management, support for network slicing, QoS flow management, and data It supports features such as mapping to a wireless bearer, support for UEs in inactive mode, distribution of NAS messages, NAS node selection, wireless access network sharing, dual connectivity, and tight interworking between NR and E-UTRA.

[0061] UE (201) refers to a user device. The user device may be referred to by terms such as terminal, ME (mobile equipment), MS (mobile station). Additionally, the user device may be a portable device such as a laptop, mobile phone, PDA (personal digital assistant), smartphone, multimedia device, etc., or it may be a non-portable device such as a PC (personal computer) or vehicle-mounted device.

[0062] Meanwhile, FIG. 2 illustrates a reference model for the case where a UE (201) accesses a DN (110) using a single PDU session for convenience of explanation, but the present disclosure is not limited thereto.

[0063] The UE (201) can access two (i.e., local and central) data networks simultaneously using multiple PDU sessions. In this case, two SMFs may be selected for different PDU sessions. However, each SMF may have the ability to control both the local UPF and the central UPF within the PDU session.

[0064] Additionally, the UE (201) may simultaneously access two data networks (i.e., local and central) provided within a single PDU session.

[0065] In the 3GPP system, a conceptual link connecting NFs within a 5G system is defined as a reference point. For example, the reference point(s) included in the 5G system (200) of FIG. 2 are as follows.

[0066] - N1: Reference point between UE (201) and AMF (203)

[0067] - N2: Reference point between (R)AN(202) and AMF(203)

[0068] - N3: Reference point between (R)AN(202) and UPF(205)

[0069] - N4: Reference point between SMF (204) and UPF (205)

[0070] - N5: Reference point between PCF (208) and AF (209)

[0071] - N6: Reference point between UPF (205) and DN (206)

[0072] - N7: Reference point between SMF (204) and PCF (208)

[0073] - N8: Reference point between UDM (207) and AMF (203)

[0074] - N9: Reference point between 2 core UPFs (205)

[0075] - N10: Reference point between UDM (207) and SMF (204)

[0076] - N11: Reference point between AMF (203) and SMF (204)

[0077] - N14: Reference point between 2 AMFs (203)

[0078] - N15: Reference point between PCF and AMF in non-roaming scenarios, reference point between PCF and AMF within the visited network in roaming scenarios

[0080] FIG. 3 is a diagram showing the structure of a common application program interface framework according to one embodiment of the present disclosure.

[0081] Referring to FIG. 3, a common application program interface framework (CAPIF) (300) includes at least one API invoker (301), a CAPIF core function (CCF) (302), an API exposing function (AEF) (303), an API publishing function (304), and an API management function (305). The at least one API invoker (301) may generally be a server provided by a third-party application provider that has entered into a service contract with a PLMN (public land mobile network) operator, and is an entity that invokes and uses a service API. For example, the at least one API invoker (301) may include an EES, an EAS, or an ECS. According to one embodiment, the at least one API invoker (301) may obtain information about the service API to be used from the CCF (302). CCF (302) is a functional entity that can be configured to accumulate all common aspects of a service API. CCF (302) can be configured for authentication, monitoring, logging authorization, and discovery common to all service APIs. According to one embodiment, CCF (302) can provide an information discovery service for a service API to an API caller (301) by storing and publishing information about a service API. Information about a service API may include information about a communication entry point calling the service API and information about an AEF (303). An AEF (303) is a functional entity that can be configured to supply one or more service APIs to at least one API caller (301).According to one embodiment, an API caller (301) may be directly connected to the AEF (303) to call a service API. According to one embodiment, the API caller (301) may not be directly connected to the API publishing function (304) and the API management function (305). The API publishing function (304) may be configured to publish a library of service APIs onto the CCF (302). According to one embodiment, using the API publishing function (304), an API provider may register and publish information about a service API on the CCF (302) so that at least one API caller (301) can search for the service API. The API management function (305) enables the API provider to perform monitoring of the service API, logging of service API call logs, and auditing, etc. The CAPIF (300) includes one or more interfaces / reference points. One or more interfaces include CAPIF-1 (not shown), CAPIF-1e, CAPIF-2 (not shown), CAPIF-2e, CAPIF-3, CAPIF-4, and CAPIF-5 interfaces. For example, CAPIF-1e and CAPIF-2e interfaces exist between the CCF (302) and an AEF (303) access point for at least one API caller (301) (existing outside the PLMN trust domain). According to one embodiment, one or more interfaces are 3GPP (3. rd The CAPIF (300) function is defined in the 3GPP TS 23.222 standard (generation partnership project). According to one embodiment, security for the CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4, and CAPIF-5 interfaces may support Transport Layer Security (TLS) as defined in the 3GPP TS 23.222 standard.

[0083] Hereinafter, according to various embodiments of the present disclosure, a method for a client within a terminal (e.g., an EEC or application client) to operate as an API caller and a method for the client within the terminal to initiate a procedure performed by an existing API caller with a CCF or AEF are described.

[0085] FIG. 4 is a diagram illustrating a procedure for transmitting configuration information necessary to use a network function opening service according to one embodiment of the present disclosure to a terminal.

[0086] Referring to FIG. 4, in step 410, the terminal (401) sends a PDU session establishment request message to the AMF (402). The PDU session establishment request message sent by the terminal (401) to the AMF (402) may include information regarding the API invocation capability related to network exposure (network exposure or network capability exposure) of the terminal (401). The information regarding the API invocation capability may include at least one of information regarding whether a dedicated client performing the API call is installed within the terminal (401), information regarding the type of client, or information regarding whether the modem within the terminal (401) can interact with the client.

[0087] Referring to FIG. 4, in step 410, the terminal (401) sends a PDU session establishment request message to the AMF (402). The PDU session establishment request message sent by the terminal (401) to the AMF (402) may include information regarding the terminal (401)'s API invocation capability related to network exposure or network capability exposure. Information regarding API call capability may include, in addition to an indicator indicating simple API call capability, at least one of the following: information regarding whether a dedicated client (401-2) performing API calls is installed within the terminal (401), information regarding the type of client, or information regarding whether a modem (401-3) within the terminal (401) can interact with the client. Furthermore, the PDU session creation request message transmitted by the terminal (401) to the AMF (402) may further include user consent regarding the terminal subscriber sharing terminal-related information outside the 3GPP network. In this case, such user consent may be limited to consent to sharing information related to service usage received through the session outside. Additionally, the user consent may include a specification regarding information(s) that can be shared outside the 3GPP network for each available service.

[0088] According to one embodiment, a dedicated client (401-2) that performs API calls may include a network exposure client (NEC) for interacting with a network exposure function (NEF) (405), a CAPIF client for interacting with a CCF (405), and an edge enabler client (EEC) if the terminal (401) supports interaction with an edge computing system. At least one of the NEC, CAPIF client, or EEC may be installed on the terminal, and the NEC, CAPIF client, and EEC may be able to interact with each other. For example, an EDGE-5 interface provided by the EEC may be connected to the NEC or CAPIF client.

[0089] In step 415, the AMF (402) transmits the PDU session creation request message received from the terminal (401) to the SMF (403). For example, the AMF (402) may transmit the PDU session creation request message received from the terminal (401) to the SMF (403) in the format of the Nsmf_PDU session_CreateSMContextRequest message defined in the 3GPP TS 23.502 standard, including information regarding the terminal (401)'s ability to call APIs related to network function opening.

[0090] In step 420, the SMF (403), having received a PDU session creation request message from the AMF (402), requests terminal subscriber information from the UDM (404). For example, the SMF (403) may request terminal subscriber information by sending a Nudm_SDM_Get message defined in the 3GPP TS 23.502 standard to the UDM (404), including information regarding the terminal (401)'s ability to call APIs related to network function opening.

[0091] In step 425, if the UDM (404) contains information regarding the ability to call APIs related to network function opening of the terminal received from the SMF (403), the UDM (404), having received information regarding terminal subscribers from the SMF (403), checks whether the terminal subscriber has the authority to call APIs related to network function opening services. For example, the UDM (404) can check whether the terminal subscriber has the authority to call APIs related to network function opening services through API call subscriber information configured within the UDM (404). The API call subscriber information may include a list of services that can be API called for the terminal subscriber and information on the call endpoint address (e.g., a fully qualified domain name (FQDN), uniform resource identifier (URI) information, or an IP address, etc.). According to one embodiment, if the information regarding the ability to call APIs related to network function opening of the terminal includes information (ID or type) about a client that performs API calls installed in the terminal, the UDM (404) can select information about service APIs that the client can call. According to one embodiment, if the UDM (404) does not receive information from the SMF (403) regarding the ability to call APIs related to network function opening of the terminal, the UDM (404) determines whether to provide information to the SMF (403) regarding whether to allow API calls related to network function opening services accessible to the terminal subscriber, in accordance with the operator policy set in the UDM (404).

[0092] In step 430, the UDM (404) provides the SMF (403) with information regarding whether to allow API calls related to network function opening services accessible to the terminal subscriber. The information regarding whether to allow API calls related to network function opening services accessible to the terminal subscriber provided by the UDM (404) to the SMF (403) may include at least one of the following information.

[0093] - NEF Information: NEF ID, NEF endpoint address, NEF service region information, a list of service APIs that can be called through the NEF, information on application functions (AFs) compatible with the NEF (e.g., application ID, application function ID, endpoint address, application client ID, etc.), information on application services compatible with the NEF (e.g., application service name or application provider information), edge computing service provider information, or information on allowed call methods for APIs provided by the NEF (e.g., direct API invocation or indirect API invocation).

[0094] - CCF Information: CCF ID, CCF endpoint address, CCF service area information (e.g., tracking area (TA), geolocation code (GLC), data network access identifier (DNAI), etc.), data network name or network slice information (single-network slice selection assistance information: S-NSSAI) required to create a PDU session to access the CCF, CCF provider information (e.g., provider ID), a list of service APIs that can be called through the CCF, information on allowed calling methods for APIs provided by the CCF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the service APIs, or a list of PLMN IDs available for service provided by the CCF (PLMN ID list)

[0095] - AEF Information: AEF ID, AEF endpoint address, AEF service region information (e.g., TA, GLC, or DNAI, etc.), list of callable service APIs, information on application functions compatible with the AEF (e.g., application ID, application function ID, endpoint address, application client ID, etc.), information on application services compatible with the AEF (e.g., application service name or application provider information), data network name or network slice information required to create a PDU session to connect to the AEFF, information on edge computing service providers compatible with the AEF, information on allowed calling methods for APIs provided by the AEF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the service APIs, or a list of IDs of PLMNs available for service provided by the AEF.

[0096] In step 435, the SMF (403) transmits to the AMF (402) information (e.g., NEF information, CCF information, or AEF information) regarding whether API calls related to network function opening services accessible to the terminal subscriber, which is provided by the UDM (404), are allowed, in order to transmit this information to the terminal (401). For example, the SMF (403) may transmit to the AMF (402) information regarding whether API calls related to network function opening services accessible to the terminal subscriber, which is provided by the UDM (404), using the Namf_Communication_N1N2MessageTransfer service defined in the 3GPP TS 23.502 standard.

[0097] In step 440, the AMF (402) transmits to the terminal (401) information (e.g., NEF information, CCF information, or AEF information) regarding whether API calls related to network function opening services accessible to the terminal subscriber are allowed, which is provided by the SMF (403). For example, the SMF (403) may transmit to the terminal (401) the information provided by the SMF (403) by including it in the protocol configuration option of the response message to the PDU session creation request message of step 410.

[0098] In step 445, the modem (401-3) within the terminal (401) transmits information (e.g., NEF information, CCF information, or AEF information) related to whether API calls related to network function opening services accessible to the terminal subscriber, which is provided by the AMF (402), to an upper layer application client (AC) (401-1) and / or a dedicated client (e.g., EEC, CAPIF client, or NEC) (401-2).

[0099] In step 450, a dedicated client (401-2) and / or application client (401-1) within the terminal (401) can call a network function open service API using information (e.g., NEF information, CCF information, or AEF information) regarding whether the provided terminal subscriber allows access to network function open service related API calls.

[0100] Although FIG. 4 describes an embodiment in which a terminal (401) receives configuration information necessary for using a network function opening service while performing a PDU session establishment procedure, the scope of the present disclosure may include an embodiment in which information regarding whether to allow API calls related to the network function opening service accessible to the terminal subscriber described in FIG. 3 is transmitted from the UDM to the terminal via the SMF during the execution of a PDU session modification procedure initiated by the terminal or network.

[0102] FIG. 5 is a diagram illustrating a procedure for setting information related to a network function opening service in a UDM according to one embodiment of the present disclosure.

[0103] Referring to FIG. 5, in step 505, the CCF or AEF (501) provides CCF information or AEF information to the NEF (502) as an AF. For example, the CCF or AEF (501) may provide CCF information or AEF information through the Nnef_ParameterProvision_Create / Update / Delete request message defined in the 3GPP TS 23.502 standard. The CCF information or AEF information may include at least one of the following information.

[0104] - CCF Information: CCF ID, CCF endpoint address, CCF service region information (e.g., TA, GLC, or DNAI, etc.), data network name or network slice information required to create a PDU session to access the CCF, CCF provider information (e.g., provider ID), information on allowed call methods for service APIs provided by the CCF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the relevant service APIs, or a list of IDs of PLMNs available for the service provided by the CCF (PLMN ID list)

[0105] - AEF Information: AEF ID, AEF endpoint address, AEF service region information (e.g., TA, GLC, DNAI, etc.), list of callable service APIs, information on application functions compatible with the AEF (e.g., application ID, application function ID, endpoint address, application client ID, etc.), information on application services compatible with the AEF (e.g., application service name or application provider information), data network name or network slice information required to create a PDU session to connect to the CCF, information on edge computing service providers compatible with the AEF, information on allowed calling methods for APIs provided by the AEF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the service APIs, or a list of IDs of PLMNs available for service provided by the AEF.

[0106] According to one embodiment, CCF information or AEF information may be provided together with a terminal ID (UE ID) and / or a terminal group ID (UE group ID). If provided together with a terminal (group) ID, the UDM (502) adds the CCF information or AEF information to the subscriber information of the terminal corresponding to that ID.

[0107] In step 510, NEF (502) transmits the CCF information or AEF information received from CCF or AEF (501) to UDM (503). For example, NEF (502) may transmit the CCF information or AEF information to UDM (503) by including it in a Nudm_ParameterProvision_Create / Update / Delete request message defined in the 3GPP TS 23.502 standard.

[0108] In step 515, the UDM (503) may store the CCF information or AEF information received from the NEF (502) within the UDM (503) and additionally store it in the UDR (504). For example, the UDM (503) may transmit the CCF information or AEF information to the UDR (504) through the Nudr_DM_Create / Update service operation defined in the 3GPP TS 23.502 standard, and the UDR (504) may store the CCF information or AEF information. According to one embodiment, the UDM (503) may determine which type of subscriber information to store the CCF information or AEF information received from the NEF (502) (i.e., determine the subscription data type) based on the type of core network function (e.g., access and mobility management, session management, etc.) associated with the service API provided by the CCF or AEF (501). For example, if the service API provided by the CCF or AEF (501) is related to the quality of service (QoS) control of the session, the CCF information or AEF information can be stored in the session management subscription data of the terminal.

[0109] In step 520, the UDM (503) reports to the NEF (502) that the CCF information or AEF information has been successfully established. For example, the UDM (503) may notify the NEF (502) that the CCF information or AEF information has been successfully established by sending a Nudm_ParameterProvision_Create / Update / Delete response message defined in the 3GPP TS 23.502 standard to the NEF (502) in response to the Nudm_ParameterProvision_Create / Update / Delete request message of step 510.

[0110] In step 525, NEF (502) reports to CCF or AEF (501) whether the setting of CFF information or AEF information within UDM (503) received from UDM (503) has been successful. For example, NEF (502) may notify whether the setting of CCF information or AEF information within UDM (503) has been successful by sending an Nnef_ParameterProvision_Create / Update / Delete response message defined in the 3GPP TS 23.502 standard in response to the Nnef_ParameterProvision_Create / Update / Delete request message of step 505.

[0111] In addition to the method of setting CCF information and / or AEF information online to the 5G core network as described in the embodiment of FIG. 5, such information may be stored in the UDM through other routes. For example, local configuration may be performed offline in the UDM according to a service level agreement between the operator and the provider of the CCF or AEF.

[0113] FIG. 6 is a diagram illustrating a procedure for setting information related to a network function opening service in a UDR according to one embodiment of the present disclosure.

[0114] Referring to FIG. 6, in step 605, the CCF or AEF (603) generates an AF request message containing CCF information or AEF information as an AF. For example, the CCF or AEF (603) may generate the AF request message through the Nnef_ServiceParameter_Create / Update / Delete service operation defined in the 3GPP TS 23.502 standard. The CCF information or AEF information may include at least one of the following information.

[0115] - CCF Information: CCF ID, CCF endpoint address, CCF service region (e.g., TA, GLC, or DNAI, etc.), data network name or network slice information required to create a PDU session to access the CCF, CCF provider information (e.g., provider ID), information on allowed call methods for service APIs provided by the CCF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the relevant service APIs, or a list of IDs of PLMNs available for service provided by the CCF.

[0116] - AEF Information: AEF ID, AEF endpoint address, AEF service region (TA, GLC, or DNAI, etc.), list of callable service APIs, information on application functions compatible with the AEF (e.g., application ID, application function ID, endpoint address, application client ID, etc.), information on application services compatible with the AEF (e.g., application service name or application provider information), data network name or network slice information required to create a PDU session to connect to the CCF, information on edge computing service providers compatible with the AEF, information on allowed calling methods for APIs provided by the AEF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the service APIs, or a list of IDs of PLMNs available for service provided by the AEF.

[0117] According to one embodiment, CCF information or AEF information may be provided together with a terminal ID or a terminal group ID. If provided together with a terminal (group) ID, the UDM adds the CCF information or AEF information to the subscriber information of the terminal corresponding to that ID.

[0118] In step 610, the CCF or AEF (603) provides the CCF information or AEF information generated in step 605 to the NEF (602). For example, the CCF or AEF (603) may provide the CCF information or AEF information through the Nnef_ServiceParameter_Create / Update / Delete request message defined in the 3GPP TS 23.502 standard.

[0119] In step 615, the NEF (602) transmits the CCF information or AEF information received from the CCF or AEF (603) to the UDR (601), and the UDR (601) stores the CCF information or AEF information received from the NEF (602). According to one embodiment, the UDR (501) may determine (i.e., determine the type of subscriber information) to store the CCF information or AEF information received from the NEF (502) in the type of subscriber information (e.g., access and mobility management, session management, etc.) related to the service API provided by the CCF or AEF (603). For example, if the service API provided by the CCF or AEF (603) is related to QoS control of a session, the CCF information or AEF information may be stored in the terminal's session management subscriber information. According to one embodiment, the UDR (601) may report to the NEF (602) whether the storage of the CCF information or AEF information was successful. For example, if a service API call is not allowed for the terminal, the NEF (602) may be notified that the storage of CCF information or AEF information has failed. According to one embodiment, the UDR (601) may independently determine whether a service API call for the terminal is allowed, or the UDR (601) may request the UDM to check whether a service API call for the terminal is allowed.

[0120] In step 620, NEF (602) reports to CCF or AEF (603) whether the CFF information or AEF information within UDR (601) received from UDR (601) has been successfully saved. For example, NEF (602) may notify whether the CCF information or AEF information within UDR (601) has been successfully saved by sending an Nnef_ServiceParameter_Create / Update / Delete response message defined in the 3GPP TS 23.502 standard in response to the Nnef_ServiceParameter_Create / Update / Delete request message of step 610.

[0122] FIG. 7 is a diagram illustrating a procedure for transmitting information related to network function opening services through an edge enabler layer according to one embodiment of the present disclosure.

[0123] Referring to FIG. 7, in step 705, the EEC (701) transmits a service request message from the terminal to the ECS (702). The service request message from the terminal transmitted by the EEC (701) to the ECS (702) may include a serving PLMN ID (information on the PLMN identifier currently connected to the terminal). For example, the EEC (701) may include the serving PLMN ID in a service provisioning request message defined in the 3GPP TS 23.558 standard and transmit it to the ECS (702).

[0124] In step 710, the ECS (702) checks for information regarding the network function opening NF (e.g., NEF, SCEF,…) of the terminal's current serving PLMN, or information regarding the CCF or AEF. According to one embodiment, the ECS (702) may check the terminal's subscriber information by interacting with a UDM or edge computing service subscriber database server and check whether direct API calls are allowed or supported. If direct API calls are allowed or supported for the terminal or the terminal's internal EEC (701), the ECS (702) may provide the terminal with communicable NEF information, CCF information, or AEF information. For example, the ECS (702) may respond to the service provisioning request message received in step 705 by including the NEF information, CCF information, or AEF information in a service provisioning response message defined in the 3GPP TS 23.558 standard and delivering it to the terminal. NEF information, CCF information, or AEF information may include at least one of the following information.

[0125] - NEF Information: NEF ID, NEF endpoint address, NEF service region information, a list of service APIs that can be called through the NEF, information on application functions (AFs) compatible with the NEF (e.g., application ID, application function ID, endpoint address, application client ID, etc.), information on application services compatible with the NEF (e.g., application service name or application provider information), edge computing service provider information, or information on allowed call methods for APIs provided by the NEF (e.g., direct API invocation or indirect API invocation).

[0126] - CCF Information: CCF ID, CCF endpoint address, CCF service region information (e.g., TA, GLC, or DNAI, etc.), data network name or network slice information required to create a PDU session to access the CCF, CCF provider information (e.g., provider ID), a list of service APIs that can be called through the CCF, information on allowed calling methods for APIs provided by the CCF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the service APIs, or a list of PLMN IDs available for service provided by the CCF (PLMN ID list)

[0127] - AEF Information: AEF ID, AEF endpoint address, AEF service region information (e.g., TA, GLC, or DNAI, etc.), a list of service APIs callable through the AEF, information on application functions compatible with the AEF (e.g., application ID, application function ID, endpoint address, application client ID, etc.), information on application services compatible with the AEF (e.g., application service name or application provider information), data network name or network slice information required to create a PDU session to connect to the CCF, information on edge computing service providers compatible with the AEF, information on allowed call methods for APIs provided by the AEF (e.g., direct API calls or indirect API calls), information on whether topology hiding is supported for the service APIs, or a list of IDs of PLMNs available for service usage provided by the AEF.

[0128] According to one embodiment, the ECS (702) may provide the EEC (701) with local NEF support and / or a list of APIs supported by the NEF or CCF. According to one embodiment, the ECS (702) may provide the EEC (701) with AF ID information of the ECS (702).

[0129] In step 715, the EEC (701) transmits a registration request message or an EAS discovery message to the EES (703). The registration request message or EAS discovery message transmitted by the EEC (701) to the EES (703) may include at least one of an E terminal ID, a serving PLMN ID, or an AC profile. For example, the EEC (701) may transmit to the EES (703) an EEC registration request message or an EAS discovery request message defined in the 3GPP TS 23.558 standard, including at least one of a terminal ID, a serving PLMN ID, or an AC profile. The AC profile information may include API list information required for the service of the corresponding AC. According to one embodiment, the EES (703) may check the API list required for the service of the AC included in the AC profile information received from the EEC (701), determine an NEF, CCF, or AEF capable of providing the APIs, and provide the corresponding service. According to one embodiment, the EES (703) can verify the serving PLMN ID received from the EEC (701) and use the verified serving PLMN ID to determine which information to provide, NEF information, CCF information, or AEF information.

[0130] In step 720, the EES (703) may select and provide to the terminal information regarding the network function opening of a PLMN (e.g., an NEF installed in the PLMN) (NEF information), information regarding a CCF (CCF information), or information regarding an AEF (AEF information) corresponding to the serving PLMN ID or AC profile information provided by the EEC (701). According to one embodiment, the EES (703) may check through the UDM which PLMN the terminal (the terminal where the EEC (701) is installed) is currently connected to, based on the policy set internally by the EEC (701) or the serving PLMN ID not provided by the EEC (701), and provide information regarding any one of the NEF, CCF, or AEF that is accessible in the PLMN the terminal is currently connected to (i.e., one of NEF information, CCF information, or AEF information). According to one embodiment, the EES (703) may request a UDM or a separate edge computing service subscriber database server to verify information about the subscriber to determine whether direct API calls are allowed or supported for the terminal or the subscriber using the EEC (701). According to one embodiment, if the EEC (701) provides AC profile information in step 715, the EES (703) may verify whether network function opening is supported for the EAS providing services to the AC. For example, the EES (703) may verify within a core network device (e.g., UDM or UDR) or an edge computing service subscriber database whether the application service provider (ASP ID or EAS provider ID)-mobile network operator (MNO) service level agreement (SLA) for the EAS provider ID contains an indicator indicating whether direct API calls from the terminal are allowed or supported.

[0131] In step 725, EES (703) provides NEF information, CCF information, or AEF information to EEC (701). For example, EES (703) may include NEF information, CCF information, or AEF information in an EEC registration response (EEC registration response) message or EAS discovery response (EAS discovery response) message defined in the 3GPP TS 23.558 standard and transmit it to EEC (701) in response to the EEC registration request message or EAS discovery request message of step 715.

[0132] According to one embodiment, the NEF information provided by the EES (703) may include an NEF ID, an NEF endpoint address, a list of service APIs that can be called through the NEF, and an indicator indicating whether direct API calls are allowed or supported for the APIs provided by the NEF. When the EES (703) provides NEF information to the EEC (701), it may also provide the AF ID of the EES (701). The AF ID of the EES (703) may be included in the API call message and transmitted to the NEF when the EEC (701) subsequently accesses the NEF and calls the API. The AF ID of the EES (703) received from the EEC (701) may be used by the NEF for authentication purposes regarding which AF the service is for and for service purposes. If authentication is the purpose, the EEC (701) may provide the relevant AF ID and terminal ID together to the NEF when calling the NEF's service API.

[0133] According to one embodiment, if the terminal's serving PLMN supports CAPIF, the EES (703) may select CCF or AEF instead of NEF and provide CCF information or AEF information to the EEC (701). According to another embodiment, the EES (703) may provide only AEF information (information about an AEF that provides a service API available for the EEC (701) or the terminal where the EEC (701) is installed) to the EEC (701) (without providing CCF information, which is information about a CCF). When providing CCF information or AEF information, the EES (703) may provide it including an indicator indicating whether direct API calls for CCF and AEF, respectively, are allowed or supported. The EES (703) may provide the AF ID of the EES (703) to the EEC (701) along with the CCF information or AEF information.

[0134] In step 730, EEC (701) performs the necessary service API calls using NEF information, CCF information, or AEF information provided by EES (703) and ECS (702). The method of calling the necessary service API follows the method specified by the directive provided by EES (703) and ECS (702) indicating whether direct API calls are allowed. When EEC (701) calls the service API provided by NEF, CCF, or AEF, EEC (701) may include the AF ID provided by EES (703) or ECS (702) in the service API call request message.

[0136] FIG. 8 is a diagram illustrating an indirect API call procedure of the EEC to an NEF or AEF according to one embodiment of the present disclosure.

[0137] Referring to FIG. 8, in step 805, the EEC (801) sends an API call trigger request message to the ECS or EES (802). The API call trigger request message sent by the EEC (801) to the ECS or EES (802) may include at least one of the following information.

[0138] - Request API name, terminal ID, ID and address information of the NEF or AEF, call trigger request descriptor, user consent (e.g., consent to provide information necessary to use the API service from the 3GPP network to an external ECS or EES)

[0139] According to one embodiment, the EEC (801) can perform an API call request by including a call trigger request indicator and the target service API information within a request message for another service provided by the ECS or EES (802) (e.g., a service provisioning request message, an EAS discovery request message, or an application context relocation request message, etc.) instead of sending a separate API call trigger request message to the ECS or EES (802).

[0140] In step 810, the EES or ECS (802) uses information within the API call trigger request message received from the EEC (801) to determine which NEF or AEF to communicate with to call a service API, and performs the service API call operation by sending an API call request message to the selected NEF or AEF (803). According to one embodiment, if the core network connected to the EES or ECS (802) supports a local NEF (or local network function opening), the API call request message can be sent to a local NEF located close to the EES or ECS (802) by considering at least one of the terminal location, the DNAI of the EES or ECS (802), and the service area of ​​the EES or ECS (802).

[0141] In step 815, the NEF or AEF (803) sends a response message for the API call request message received from the ECS or EES (802). The response message sent by the NEF or AEF (803) to the ECS or EES (802) may include the result of the API call. According to one embodiment, if the NEF or AEF (803) does not support the corresponding service API or if another NEF or AEF is more suitable to provide the service API (e.g., due to overload or if there is an NEF or AEF located closer), the response message sent by the NEF or AEF (803) to the ECS or EES (802) may include the ID and address information of the other NEF or AEF along with the API call failure code.

[0142] In step 820, EES or ECS (802) sends a response message to EEC (801) containing the result of the API call trigger request (the API call result received from NEF or AEF (803)).

[0144] FIG. 9 is a diagram illustrating an indirect API call procedure of the EEC to the CCF according to one embodiment of the present disclosure.

[0145] Referring to FIG. 9, in step 905, the EEC (901) sends an API call trigger request message to the ECS or EES (802). The API call trigger request message sent by the EEC (901) to the ECS or EES (902) may include at least one of the following information.

[0146] - Request API name, terminal ID, ID and address information of CCF, NEF, or AEF, call trigger request descriptor, user consent (e.g., consent to provide information necessary to use the API service from the 3GPP network to an external ECS or EES)

[0147] According to one embodiment, the EEC (901) can perform an API call request by including a call trigger request indicator and the target service API information within a request message for another service provided by the ECS or EES (902) (e.g., a service provisioning request message, an EAS discovery request message, or an application context relocation request message, etc.) instead of sending a separate API call trigger request message to the ECS or EES (902).

[0148] In step 910, if the ECS or EES (902) supports interoperability with the CCF (903), it sends an API discovery request message to the CCF (903). The ECS or EES (902) may send an API discovery request message to the CCF (902) to discover an NEF or AEF for the API call trigger request from the EEC (901). The API discovery request message sent by the ECS or EES (902) to the CCF (903) may include user consent received from the EEC (901) (e.g., consent to provide information necessary for using the API service to an external ECS or EES on the 3GPP network).

[0149] In step 915, CCF (903) sends a response message to ECS or EES (902) for the API term search request message received from ECS or EES (902). The response message sent by CCF (903) to ECS or EES (902) may include information about NEF or AEF (904) that can provide the requested service API (e.g., ID and address information of the NEF or AEF).

[0150] In step 920, ECS or EES (902) performs a service API call operation by sending an API call request message to NEF or AEF (903) using the address information of NEF or AEF (904) included in the response message received from CCF (903).

[0151] In step 925, the NEF or AEF (904) sends a response message for the API call request message received from the ECS or EES (902). The response message sent by the NEF or AEF (904) to the ECS or EES (902) may include the result of the API call. According to one embodiment, if the NEF or AEF (904) does not support the corresponding service API or if another NEF or AEF is more suitable to provide the service API (e.g., due to overload or if there is an NEF or AEF located closer), the response message sent by the NEF or AEF (904) to the ECS or EES (902) may include the ID and address information of the other NEF or AEF along with the API call failure code.

[0152] In step 930, EES or ECS (902) sends a response message to EEC (901) containing the result of the API call trigger request (the API call result received from NEF or AEF (904)).

[0154] FIG. 10 is a diagram illustrating the procedure for calling an API of the EEC for an NEF according to one embodiment of the present disclosure.

[0155] Referring to FIG. 10, in step 1005, the UDM (1003) provides the NEF (1002) with information about terminals for which direct API calls are allowed (or supported), such as a terminal ID or terminal group ID, such as an MSISDN (mobile station ISDN (integrated services digital network) number definition) or a GPSI (generic public subscription identifier). According to one embodiment, the information about the terminal may be provided along with the AF ID of the application server providing services to the terminal. According to one embodiment, the UDM (1003) may provide the NEF (1002) with information about application clients or EECs (1001) for which direct API calls are allowed. For example, the UDM (1003) may provide the application client ID or EEC ID to the NEF (1002) along with the terminal ID. In this case, it indicates that direct API calls are allowed only for specific application clients or EECs within the terminal. According to one embodiment, the UDM (1003) may select an NEF (1002) capable of providing services at the location of the terminal and provide a list of terminal IDs or terminal group IDs for which direct API calls are allowed (or supported). According to one embodiment, the UDM (1003) may provide information about terminals for which direct API calls are allowed (or supported) to the NEF (1002), and simultaneously perform a subscription to receive notifications when a related event (e.g., a terminal connecting to the NEF) occurs. According to one embodiment, when the UDM (1001) provides information about terminals for which direct API calls are allowed (or supported) to the NEF (1002), it may provide a list of service APIs for which the terminal subscriber or user has agreed to use, or information that can be shared externally, along with the information about the terminal.

[0156] In step 1010, the NEF (1002) sends a response message to the UDM (1003) containing an indicator indicating whether the reception and storage of information for a terminal that is allowed (or supported) to make direct API calls was successful.

[0157] In step 1015, a client within the terminal (e.g., an EEC or application client) (1001) sends an API call request message to the NEF (1002). The API call request message sent by the client within the terminal (1001) to the NEF (1002) may include at least one of the following information.

[0158] - Name of the API to be called, input values ​​required to use the API service to be called, AF information associated with the API service to be called (e.g., address information of ECS, EES, or EAS and AF ID), terminal ID, calling client ID (EEC ID or application client ID), user consent (e.g., consent to provide information required to use the API service to an external AF, such as an ECS or EES, or an external server within the 3GPP network)

[0159] According to one embodiment, a client (EEC or application client) (1001) within a terminal can send an API call request message to NEF (1002) when at least one of the following conditions is satisfied.

[0160] (1) Application client installation completed on the terminal,

[0161] (2) An application client within the terminal performs a service request to the EEC,

[0162] (3) When the application client is executed,

[0163] (4) When the application client is running and generates and sends traffic toward the application server

[0164] (5) When the quality of service deteriorates while the application client is receiving service from the application server,

[0165] (6) When terminal-related information needs to be received from the 3GPP core network

[0166] According to one embodiment, the NEF (1002) interacts with the network functions of the associated core network in accordance with an API call request message received from a client (EEC or application client) (1001) within the terminal. According to one embodiment, if steps 1005 and 1010 are not performed, the NEF (1002) may interact with the UDM to authenticate the terminal that sent the API call request message to it. For example, the NEF (1002) may provide the ID of the terminal to the UDM and check whether direct API calls are allowed (or supported) for the terminal. According to one embodiment, if the NEF (1002) receives a report from the UDM that direct API calls are not allowed (or supported) for the terminal or that there is no related subscriber information, the NEF (1002) rejects the terminal's API call request.

[0167] In step 1020, the NEF (1002) sends a response message containing the result of the API call request to a client (EEC or application client) (1001) within the terminal.

[0169] After successfully completing a service API call request according to the embodiments of FIGS. 8, 9, and 10, a client within the terminal (EEC or application client) may request to stop using the service API. For example, the client within the terminal may send a message requesting the suspension or cancellation of use of the service API to the device that sent the API call request message. The message requesting the suspension or cancellation of use of the service API may include information such as the target API name, information about the AF that wants to stop using the service among the AFs currently using the target API service (e.g., address information of ECS, EES, or EAS and AF ID), or a terminal ID and / or terminal group ID. Additionally, even if the client within the terminal has not performed a service API call request as in FIGS. 8, 9, and 10, but wishes to stop using the service API for the terminal that is currently being called and used by an external AF, the client within the terminal may likewise perform a request action to stop or cancel the use of a specific service API.

[0171] FIG. 11 is a diagram showing the configuration of a terminal according to one embodiment of the present disclosure.

[0172] Referring to FIG. 11, a terminal (1100) communicating with a base station or other network entity in a wireless communication system may include a transceiver (1101), a control unit (1102), and a storage unit (1103). The control unit (1102) may be defined as a circuit or application-specific integrated circuit or at least one processor.

[0173] The transceiver (1101) can transmit and receive signals with a base station or other network entities. The transceiver (1101) can, for example, transmit an API call trigger request message to an ECS or EES according to the embodiment described above.

[0174] The control unit (1102) can control the overall operation of the terminal according to various embodiments proposed in the present disclosure. For example, the control unit (1102) can control the signal flow between each block to perform operations according to the procedure described above with reference to FIGS. 3 to 10. For example, the control unit (1102) can control overall operations related to specific service API calls according to the embodiments described above.

[0175] The storage unit (1103) can store at least one of the information transmitted and received through the transmission and reception unit (1101) and the information generated through the control unit (1102). For example, the storage unit (1103) can store the result of an API call trigger request according to the above-described embodiment.

[0177] FIG. 12 is a diagram showing the configuration of a network entity according to one embodiment of the present disclosure.

[0178] The network entities of FIG. 12 may include, for example, ECS, NEF, CCF, and AEF.

[0179] Referring to FIG. 12, a network entity (1200) communicating with another entity or terminal in a wireless communication system may include a transceiver (1201), a control unit (1202), and a storage unit (1203). The control unit (1202) may be defined as a circuit or application-specific integrated circuit or at least one processor.

[0180] The transmitting and receiving unit (1201) can transmit and receive signals with other network entities or terminals. The transmitting and receiving unit (1201) can, for example, receive an API call request from a client (EEC or application client) within the terminal or transmit information related to the aforementioned API call to the terminal.

[0181] The control unit (1202) can control the overall operation of the network entity (1200) according to the embodiments proposed in the present disclosure. For example, the control unit (1202) can control the signal flow between each block to perform operations according to the procedure described above with reference to FIGS. 3 to 10. For example, the control unit (1202) can control the operations proposed in the present disclosure to generate information related to the API call described above in the embodiments described above.

[0182] The storage unit (1203) can store at least one of the information transmitted and received through the transmission and reception unit (1201) and the information generated through the control unit (1202). For example, the storage unit (1203) can store information related to the API call described above according to the above-described embodiment.

[0184] Although this specification describes EECs and application clients mentioned as entities that directly or indirectly perform service API calls as clients within the terminal, the operation of all other application modules or enabler clients for specific services within the terminal (e.g., service enabler architecture layer client, unmanned aerial system application enabler client, etc.) in addition to EECs and application clients may also be included within the scope of this disclosure.

[0185] The operations of the base station or terminal described above can be realized by providing a memory device storing the corresponding program code in any component within the base station or terminal device. That is, the control unit of the base station or terminal device can execute the operations described above by reading the program code stored in the memory device using a processor or CPU (Central Processing Unit) and executing it.

[0186] Various components of entities, base stations, or terminal devices and modules described herein may be operated using hardware circuits, such as, for example, complementary metal oxide semiconductor-based logic circuits, firmware, software, and / or a combination of hardware and firmware and / or software embedded in a machine-readable medium. For example, various electrical structures and methods may be implemented using electrical circuits such as transistors, logic gates, and application-specific semiconductors.

[0187] Although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

Claim 1 A method performed by a terminal (user equipment) in a wireless communication system, comprising: a step of transmitting a first request message to a network entity that includes information regarding the terminal's ability to call an API (Application Programming Interface); a step of receiving a first response message from the network entity in response to the first request message that includes information regarding whether to allow an API call; and a step of calling the API based on information regarding whether to allow an API call, wherein the information regarding whether to allow an API call includes at least one of Network Exposure Function (NEF) information, Common API Framework (CAPIF) Core Function (CCF) information, and API Exposing Function (AEF) information. Claim 2 In claim 1, information regarding the ability of the terminal to call an API (Application Programming Interface) comprises at least one of: an indicator indicating that the terminal has the ability to call the API; information regarding whether a client for performing the API call is installed; information regarding the type of the client; and information regarding whether a modem within the terminal can interact with the client. Claim 3 A method according to claim 1, wherein the first request message further includes information indicating consent to share information related to the terminal from the network to the outside. Claim 4 delete Claim 5 A method according to claim 1, wherein the NEF information comprises at least one of: a NEF identifier (ID), an NEF endpoint address, NEF service area information, a list of service APIs that can be called through the NEF, information on application functions (AF) that can be linked with the NEF, information on application services that can be linked with the NEF, information on edge computing service providers, or information on call methods allowed for APIs provided by the NEF. Claim 6 A method according to claim 1, wherein the CCF information comprises at least one of: a CCF identifier (ID), a CCF endpoint address, CCF service area information, a data network name or network slice information (single-network slice selection assistance information: S-NSSAI) required for creating a PDU session to access the CCF, CCF provider information, a list of service APIs that can be called through the CCF, information on the call methods allowed for the APIs provided by the CCF, information on whether topology hiding is supported for the APIs, or a list of service-available PLMN IDs provided by the CCF. Claim 7 A method according to claim 1, wherein the AEF information comprises at least one of: an AEF identifier (ID), an AEF endpoint address, AEF service area information, a list of callable service APIs, information on application functions compatible with the AEF, information on application services compatible with the AEF, a data network name or network slice information required for creating a PDU session to connect to the AEF, information on edge computing service providers compatible with the AEF, information on call methods allowed for APIs provided by the AEF, information on whether topology hiding is supported for the APIs, or a list of service-available PLMN IDs provided by the AEF (PLMN ID list). Claim 8 A method performed by a network entity in a wireless communication system comprises: receiving a first request message from a terminal (user equipment) that includes information regarding the terminal's ability to call an API (Application Programming Interface); determining whether the terminal has the authority to call an API based on the information regarding the terminal's ability to call an API; and transmitting a first response message to the terminal that includes information regarding whether to allow an API call as a response to the first request message, wherein the information regarding whether to allow an API call includes at least one of Network Exposure Function (NEF) information, Common API Framework (CAPIF) Core Function (CCF) information, and API Exposing Function (AEF) information. Claim 9 In claim 8, information regarding the ability of the terminal to call an API (Application Programming Interface) comprises at least one of: an indicator indicating that the terminal has the ability to call the API; information regarding whether a client for performing the API call is installed; information regarding the type of the client; and information regarding whether a modem within the terminal can interact with the client. Claim 10 delete Claim 11 ◈Claim 11 was abandoned upon payment of the registration fee.◈ In claim 8, the NEF information comprises at least one of: a NEF identifier (ID), an NEF endpoint address, NEF service area information, a list of service APIs that can be called through the NEF, information on application functions (AF) that can be linked with the NEF, information on application services that can be linked with the NEF, information on edge computing service providers, or information on call methods allowed for APIs provided by the NEF. Claim 12 ◈ Claim 12 was abandoned upon payment of the registration fee. ◈ Method of claim 8, wherein the CCF information comprises at least one of: a CCF identifier (ID), a CCF endpoint address, CCF service area information, a data network name or network slice information (single-network slice selection assistance information: S-NSSAI) required for creating a PDU session to access the CCF, CCF provider information, a list of service APIs that can be called through the CCF, information on the call methods allowed for the APIs provided by the CCF, information on whether topology hiding is supported for the APIs, or a list of service-available PLMN IDs provided by the CCF. Claim 13 ◈Claim 13 was abandoned upon payment of the registration fee.◈ In claim 8, the above AEF information comprises at least one of: an AEF identifier (ID), an AEF endpoint address, AEF service area information, a list of callable service APIs, information on application functions compatible with the AEF, information on application services compatible with the AEF, a data network name or network slice information required for creating a PDU session to access the AEF, information on edge computing service providers compatible with the AEF, information on call methods allowed for APIs provided by the AEF, information on whether topology hiding is supported for the APIs, or a list of service-available PLMN IDs provided by the AEF. Claim 14 A terminal (user equipment) in a wireless communication system comprises: a transceiver; and at least one processor, wherein the at least one processor is configured to perform the following operations: transmitting a first request message containing information regarding the terminal’s ability to call an API (Application Programming Interface) to a network entity; receiving a first response message from the network entity in response to the first request message containing information regarding whether to allow an API call; and calling the API based on the information regarding whether to allow an API call, wherein the information regarding whether to allow an API call is configured to include at least one of Network Exposure Function (NEF) information, Common API Framework (CAPIF) Core Function (CCF) information, and API Exposing Function (AEF) information. Claim 15 A network entity in a wireless communication system comprises: a transceiver; and at least one processor, wherein the at least one processor is configured to perform the following operations: receiving a first request message from a terminal (user equipment) that includes information regarding the terminal's ability to call an API (Application Programming Interface); determining whether the terminal has the authority to call an API based on the information regarding the terminal's ability to call an API; and transmitting a first response message to the terminal that includes information regarding whether to allow an API call in response to the first request message, wherein the information regarding whether to allow an API call is configured to include at least one of Network Exposure Function (NEF) information, Common API Framework (CAPIF) Core Function (CCF) information, and API Exposing Function (AEF) information.

Images