Controlling service API dissemination in a communication network system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Embodiments herein provide a method and system for controlling service API dissemination in a communication network system. The method includes generating, by an API invoker (102), a service API discover request message by adding an API invoker identity information. The API invoker identity information includes at least one of an authorized API invoker or the API invoker (102) yet to be onboarded. Further, the method includes transmitting the service API discover request message to a network apparatus (202) including a CCF (212). Further, the method includes receiving a service API discover response message from the network apparatus (202) in response to the service API discover request message. The service API discover response message includes a filtered list of service API information based on a dissemination criteria relevant for the API invoker (102) yet to be onboarded.

Description

CONTROLLING SERVICE API DISSEMINATION IN A COMMUNICATION NETWORK SYSTEM

[0001] The present disclosure is related to the field of wireless communication. More particularly, the present disclosure is related to a method and system for controlling service application programming interface (API) dissemination in a communication network system.

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

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

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

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

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

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

[0008] 3rd Generation Partnership Project (3GPP) TS 23.222, clause 8.1 and 8.2 specifies the mechanism for API Invoker on boarding to and off boarding from Common API Framework (CAPIF) Core Function (CCF). This mechanism enables an Application Function (AF) to register itself as an API Invoker. Successful API Invoker registration also means that the API Invoker is authenticated to the CCF, after which the API Invoker can invoke the northbound APIs with support of the CCF. For example, the API Invoker can discover the published service API information, according to the API invokers' interest. The API Invoker can subscribe to the CCF for events such as to know any changes in published service API information. One CCF can publish service API information into another CCF to support federation of Service APIs.

[0009] As stated in above, entities (for example API Invoker, CCF, etc.) have access to service API Information that is made available by the publishing entity. There is no control of what service API information is disseminated and to whom. However, there are industry requirements to restrict dissemination of service API information to the entities depending on the entity and the scenario (for example API Invoker yet to be onboarded, interconnected CCF, type of API publishing entity, API serving area). Such controlled dissemination of service API information is required to protect certain API information of the publishing entity that might reveal internals of their API deployment information. So it is desirable by the publishing entity to not disclose all the API information towards the entities accessing e.g., for security reasons.

[0010] Hence, is desirable to address the above mentioned problems and disadvantages or at least provide a useful alternative.

[0011] The principal object of the embodiments herein is to provide a system and method for controlling service API dissemination in a communication network system.

[0012] Another object of the embodiments herein is to provide a method (in API discovery response) for sharing filtered service API information according to the state of the API invoker, who is yet to be onboarded to the CCF.

[0013] Yet another object of the embodiments herein is to provide a method (either via service API publish mechanism or as a policy) for CCF possessing dissemination criteria or filter for service API information.

[0014] Yet another object of the embodiments herein is to provide a method for determining the dissemination of the service API information based on an entity requesting (API invoker, interconnected CCF), a scenario (for example API Invoker yet to be onboarded, interconnected CCF, type of API publishing entity, API serving area), and the like.

[0015] In an aspect, the objectives are achieved by providing a method for controlling service API dissemination in a communication network system. The method includes generating a service API discover request message by adding an API invoker identity information. The API invoker identity information includes at least one of an authorized API invoker or the API invoker yet to be onboarded. Further, the method includes transmitting the service API discover request message to a network apparatus including a CCF. Further, the method includes receiving a service API discover response message from the network apparatus in response to the service API discover request message. The service API discover response message includes a filtered list of service API information based on a dissemination criteria relevant for the API invoker yet to be onboarded.

[0016] In another aspect, the objectives are achieved by providing a method for controlling service API dissemination in a communication network system. The method includes receiving a service API discover request message from an API invoker. The service API discover request message includes API invoker identity information including at least one of an authorized API invoker or the API invoker yet to be onboarded, indicating an API invoker that discovers service APIs. Further, the method includes retrieving a dissemination criteria relevant for the API invoker yet to be onboarded upon receiving the service API discover request message. Further, the method includes generating a service API discover response message in response to the dissemination criteria retrieved. The service API discover response message includes a filtered list of service API information based on the dissemination criteria relevant for the API invoker yet to be onboarded. Further, the method includes transmitting the service API discover response message to the API invoker.

[0017] In another aspect, the objectives are achieved by providing an API invoker for controlling service API dissemination in a communication network system. The API invoker includes a first memory, a first processor, and a service API dissemination controller coupled to the first memory and the first processor. The service API dissemination controller generates a service API discover request message by adding an API invoker identity information. The API invoker identity information includes at least one of an authorized API invoker or the API invoker yet to be onboarded. Further, the service API dissemination controller transmits the service API discover request message to a network apparatus including a CCF. Further, the service API dissemination controller receives a service API discover response message from the network apparatus in response to the service API discover request message. The service API discover response message includes a filtered list of service API information based on a dissemination criteria relevant for the API invoker yet to be onboarded

[0018] In another aspect, the objectives are achieved by providing a network apparatus for controlling service API dissemination in a communication network system. The network apparatus includes a second memory, a second processor, and a network service API dissemination controller. The network service API dissemination controller receives a service API discover request message from an API invoker. The service API discover request message includes API invoker identity information including at least one of an authorized API invoker or the API invoker yet to be onboarded, indicating an API invoker that discovers service APIs. Further, the network service API dissemination controller retrieves a dissemination criteria relevant for the API invoker yet to be onboarded upon receiving the service API discover request message. Further, the network service API dissemination controller generates a service API discover response message in response to the dissemination criteria retrieved. The service API discover response message includes a filtered list of service API information based on the dissemination criteria relevant for the API invoker yet to be onboarded. Further, the network service API dissemination controller transmits the service API discover response message to the API invoker.

[0019] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood,however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications be made within the scope of the embodiments herein.

[0020] According to an embodiment of the disclosure, a system and method for controlling service API dissemination in a communication network system are provided.

[0021] These and other features, aspects, and advantages of the present embodiments are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0022] Fig. 1 is a block diagram that illustrates a schematic of an API invoker implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0023] Fig. 2 is a block diagram that illustrates a schematic of a network apparatus implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0024] Fig. 3 is a sequence diagram that illustrates a scenario of publish service APIs providing dissemination criteria according to an embodiment as disclosed herein.

[0025] Fig. 4 is a sequence diagram that illustrates a scenario of API discovery by an API invoker including yet to be onboarded invoker to an embodiment as disclosed herein.

[0026] Fig. 5 is a sequence diagram that illustrates a scenario of discovery of service APIs yet to be onboarded for sharing controlled service API information according to an embodiment as disclosed herein.

[0027] Fig. 6 is a flow diagram that illustrate a method for controlling service API dissemination in a communication network system by the API invoker according to an embodiment as disclosed herein.

[0028] Fig. 7 is a flow diagram that illustrate a method for controlling service API dissemination in a communication network system by the network apparatus according to an embodiment as disclosed herein.

[0029] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with a plurality of other embodiments to form new embodiments. The term "or"as used herein, refers to a non-exclusive or, unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples are not be construed as limiting the scope of the embodiments herein.

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

[0031] The accompanying drawings are used to help easily understand various technical features and it is understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the proposed method is construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. used herein to describe various elements, these elements are not be limited by these terms. These terms are generally used to distinguish one element from another.

[0032] In the prior art, there is a lack of control over the dissemination of service API information and the recipients of that information. There are specific requirements to limit the sharing of service API information based on the entity involved and the context (such as API invokers yet to be onboarded, interconnected CCFs, the type of API publishing entity, and the API's service area). This regulated dissemination of service API information is essential to safeguard sensitive details of the publishing entity's API deployment that could potentially expose internal workings. Thus, it is important for the publishing entity to restrict access to certain API information for security purposes.

[0033] The proposed solution discloses a system and method for controlling service API dissemination in a communication network system. This includes publishing the service APIs with dissemination criteria and the information to provide restricted access to the service API information. The method also includes sharing the service APIs information according to the dissemination criteria.

[0034] The terms northbound API and service API mean the same. They are used interchangeably throughout the disclosure.

[0035] The terms dissemination criteria and dissemination policy mean the same. They are used interchangeably throughout the disclosure.

[0036] Fig. 1 is a block diagram that illustrates a schematic of an API invoker (102) implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein. The API invoker (102) is part of a user equipment (UE) or is an application function (AF) on the network apparatus including the CCF. Examples of the UE (102) can include, but are not limited to, a terminal, Consumer Electronics (such as Mobile Phones and Smartphones), Tablets, Wearable Devices, Computing Devices (such as Laptops, Notebooks, Desktops, Workstations, etc.), IoT Devices, Automotive Systems (such as connected cars, Autonomous Vehicles, Vehicle-to-Everything (V2X) communication devices, etc.), Enterprise Devices such as robotics, Specialized Equipment (such as Medical Devices, Public Safety Devices, etc.), Media Devices (such as Gaming Consoles, Streaming Devices, etc.).

[0037] In an embodiment, in Fig. 1, the API invoker (102) includes a first processor (104), a first memory (106), a first I / O interface (108), and a service API dissemination controller(110) coupled to the first processor (104) and the first memory (106). The components are explained in further detail below.

[0038] The first processor (104) communicates with the first memory (106), the first I / O interface (108), and the service API dissemination controller(110). The first processor (104) is configured to execute instructions stored in the first memory (106) and to perform various processes. The first processor (104) includes one or a plurality of processors, is a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an Artificial Intelligence (AI) dedicated processor such as a neural processing unit (NPU).

[0039] The first memory (106) includes storage locations to be addressable through the first processor (104). The first memory (106) is not limited to a volatile memory and / or a non-volatile memory. Further, the first memory (106) includes a plurality of computer-readable storage media. The first memory (106) includes non-volatile storage elements. For example, non-volatile storage elements includes magnetic hard disks, optical disks, floppy disks, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

[0040] The first I / O interface (108) transmits the information between the first memory (106) and external peripheral devices. The peripheral devices are the input-output devices associated with the API invoker (102). Further, the service API dissemination controller(110) communicates with the first I / O interface (108) and the first memory (106). The service API dissemination controller(110) is coupled to the first memory (106) and the first processor (104). The service API dissemination controller(110) is an innovative hardware that are realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0041] In an embodiment, the service API dissemination controller(110) generates a service API discover request message by adding an API invoker identity information. The API invoker identity information includes at least one of an authorized API invoker or the API invoker (102) yet to be onboarded. The API invoker identity information includes identity information of the API invoker (102) discovering service APIs. Service APIs are interfaces that allow different entities to communicate with each other over the communication network. The service APIs enable the entities to request for services and exchange data amongst each other.

[0042] In an embodiment, the service API dissemination controller (110) transmits the service API discover request message to the network apparatus including the CCF. The CCF is a standardized framework defined by the 3GPP to harmonize the exposure and management of service APIs within telecommunication networks. The CCF enables network operators or entities to securely expose their services to external or third-party providers.

[0043] In an embodiment, the service API dissemination controller (110) receives a service API discover response message from the network apparatus in response to the service API discover request message. The service API discover response message includes a filtered list of service API information based on a dissemination criteria relevant for the API invoker (102) yet to be onboarded. The dissemination criteria includes filtered service API information that is accessible to a specific requesting entity (for example, the API invoker (102), CCF) or service API information that is allowed to be shared based on a specific criteria. The specific criteria is associated with the specific requesting entity based on a current scenario. For example, the scenario may include onboarding the API invoker (102), API discovery by the API invoker (102) yet to be onboarded, API publish to interconnect the CCF, and the like.

[0044] Fig. 2 is a block diagram that illustrates a schematic of the network apparatus (202) implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein. As shown, the network apparatus (202) includes a second processor (204), a second memory (206), a second I / O interface (208), and a network service API dissemination controller (210).

[0045] The network apparatus (202) includes various hardware and software components that facilitate communication between user equipment and network infrastructure. Examples of the network apparatus (202) can include, but is not limited to the CCF, Base Stations (such as macro cells, small cells, femtocells, picocells, etc.) for wireless communication, Antennas and RF Units (e.g., MIMO, beamforming) to enhance signal coverage and data throughput, Core Network Equipment (e.g., MMEs, S-GWs, P-GWs in 4G; AMFs, SMFs, UPFs in 5G) for data routing, mobility, and session control, Network Function Virtualization (NFV) and Software-Defined Networking (SDN) for dynamic resource allocation and scalability, Edge Computing Nodes (e.g., MEC servers) for low-latency processing, Backhaul and Transport Equipment (e.g., fiber-optic links, microwave relays, Ethernet switches) to connect base stations to the core network, Network Management Systems (NMS) and Operation Support Systems (OSS) for network configuration, fault management, and optimization, Radio Network Controllers (RNCs) in 3G, Distributed Units (DUs), and Centralized Units (CUs) in 5G, Network Slicing Components for virtualized resource allocation, Security elements (e.g., Firewalls, IDS, AAA Servers) for secure communication.

[0046] The network service API dissemination controller (210) is coupled to the second memory (206) and the second processor (204). The network service API dissemination controller (210) is an innovative hardware that are realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0047] In an embodiment, the network service API dissemination controller (210) receives a service API discover request message from the API invoker (102). The service API discover request message includes API invoker identity information indicating the API invoker (102) that discovers service APIs. The API invoker identity information includes identity information that can be at least one of an authorized API invoker or the API invoker (102) yet to be onboarded, indicating the API invoker (102) that discovers service APIs. The service APIs serve as important sources for communication and data exchange among different entities within the communication network, enabling them to collaborate and function cohesively. By ensuring that the identity of the API invoker (102) is accurately established and authenticated, service APIs can maintain security, manage access control, and facilitate efficient interactions across the communication network.

[0048] In an embodiment, the network service API dissemination controller (210) retrieves a dissemination criteria relevant for the API invoker (102) yet to be onboarded upon receiving the service API discover request message. The dissemination criteria includes filtered service API information that is accessible to a specific requesting entity (for example, the API invoker (202), CCF) or service API information that is allowed to be shared based on a specific criteria. The specific criteria is associated with the specific requesting entity based on a current scenario. For example, the scenario may include onboarding the API invoker (202), API discovery by the API invoker (102) yet to be onboarded, API publish to interconnect the CCF, and the like.

[0049] In an embodiment, the network service API dissemination controller (210) generates a service API discover response message in response to the dissemination criteria retrieved. The service API discover response message includes a filtered list of service API information based on the dissemination criteria relevant for the API invoker (102) yet to be onboarded. For instance, the filtered list of service API information is shared to the API invoker (102) based on a state of the API invoker (102) that is yet to be onboarded to the network apparatus (202). Further, the network service API dissemination controller (210) transmits the service API discover response generated to the API invoker (102).

[0050] Fig. 3 is a sequence diagram that illustrates a scenario of publish service APIs providing dissemination criteria according to an embodiment as disclosed herein. As shown in the sequence diagram, an API publishing function (302) and the network apparatus (202) including the CCF (212) are in communication with each other. Each step is explained in further detail below.

[0051] In step 1, the API publishing function (302) may send a service API publish request to the CCF (212), with the details of the service API, as specified in 3GPP TS 23.222, along with additional dissemination criteria and what needs to be restricted for further sharing to the requesting entity. Basically, the API publishing function (302) may indicate to the CCF (212) that the API publishing function (302) wishes to restrict the service API information for certain targets. For example, targets include onboarding the API invoker (102), API discovery by the API invoker (102) yet to be onboarded, API publish to interconnect the CCF (212), API publishing entity is 3rdparty, and the like. The service API publish request from the API publishing function (302) to the CCF (212) includes the information elements as mentioned in the table 1.

[0052] Information elementStatusDescriptionAPI publisher informationMThe information of the API publisher may include identity, authentication and authorization informationService API informationMThe service API information includes the service API name, API provider name (optional), List of public IP ranges of UEs (optional), service API type, service API status (e.g. active, inactive), communication type, description, Serving Area Information (optional), AEF location (optional), interface details (e.g. IP address, port number, URI), protocols, version numbers, data format, Service KPIs (optional), and Network Slice Info (optional).> Dissemination CriteriaOAPI publishing function indicates to the CCF that the API publishing function wishes to restrict the Service API information for certain targets (For example, onboarding API invoker, API discovery by API Invoker yet to be onboarded, API publish to interconnected CCF, like so).>> Restricted Service API informationOThe service API information that needs to be restricted based on the entity (for example API invoker, CCF) that is requesting the Service API information and the scenario (for example onboarding, API discovery, interconnection). For example, this information may include service API information that is accessible to all, service API information that is accessible to a specific set of targets, service API information that is allowed to be shared in specific set of procedures etc.Shareable informationO (see　NOTE)Indicates whether the service API or the service API category can be published to other CCFs. And if sharing, a list of CAPIF provider domain information where the service API or the service API category can be published is contained.NOTE: If the shareable information is not present, the service API is not allowed to be shared.

[0053] Table 1: Service API publish request

[0054] In step 2, upon receiving the service API publish request, the CCF (212) may checkswhether the API publishing function (302) is authorized to publish service APIs. If the check is successful, the service API information provided by the API publishing function (302) is stored at the CCF (212) (API registry), along with the dissemination criteria and the information to be restricted.

[0055] In step 3, the CCF (212) may provide a service API publish response to the API publishing function (302) indicating a success or a failure result.

[0056] In an embodiment, the service API information is subsequently disseminated by the CCF (212) as per the stored dissemination criteria, for example during API discovery.

[0057] In an embodiment, the dissemination Criteria and the information to be restricted may be included within the Service API information IE.

[0058] In an embodiment, the proposed solution is used in supporting the service API publish over CAPIF interconnection procedures. The dissemination criteria and restricted service API information is included in the service API publish procedures (i.e. Interconnection API publish request, Interconnection API unpublish request). The CCF (212) of the interconnection API Publish request message, takes the dissemination criteria and restricted service API information to consideration for sharing the service API information further, like in interconnection service API discovery procedures (i.e. Interconnection service API discover request and Interconnection service API discover response).

[0059] In an embodiment, the proposed solution is used in supporting the service API publish over CAPIF interconnection procedures, by the CCF (212) considering the dissemination criteria and restricted service API information from the API publishing function (302), to determine the service API information to be included in the service API publish procedures (i.e. Interconnection API publish request, Interconnection API unpublish request) for CAPIF Interconnection or in interconnection service API discovery procedures (i.e. Interconnection service API discover request and Interconnection service API discover response).

[0060] Fig. 4 is a sequence diagram that illustrates a scenario of API discovery by the API invoker (102) yet to be onboarded to an embodiment as disclosed herein. For instance, the API invoker (102) yet to be onboarded can also be referred to as an un-authenticated API invoker. As shown in the sequence diagram, the API invoker (102) yet to be onboarded and the network apparatus (202) including the CCF (212) are in communication with each other. The mechanism for service API discovery from the API invoker (102) who is yet to be onboarded to the CCF (212) is supported by the CCF (212). Each step is explained in further detail below.

[0061] In step 1, the API invoker (102) yet to be onboarded may send a API invoker yet to be onboarded service API discover request to the CCF (212). The request may include query information and information associated with the API invoker (102) yet to be onboardedi.e. The identity of the API invoker (102) that is necessarily recognizable by the CCF (212) as mentioned in table 2.

[0062] Information elementStatusDescriptionAPI invoker informationMAPI invoker information of the yet to be onboarded API invoker, discovering service APIsQuery informationMCriteria for discovering matching service APIs (e.g. service API type, Serving Area Information (optional), preferred AEF location (optional), required API provider name (optional), UE IP address (optional), interfaces, protocols, Service KPIs (optional), and Network Slice Info (optional)).(see　NOTE)NOTE: It should be possible to discover all the service APIs.

[0063] Table　2: API Invoker yet to be onboarded Service API discover request

[0064] At step 2, upon receiving the API invoker yet to be onboarded service API discover request, the CCF (212) may retrieve the stored service API information as per the query information in the API invoker yet to be onboarded service API discover request. Further, the CCF (212) applies the dissemination policy and performs filtering of service APIs information that can be shared to the API Invoker (102) yet to be onboarded.

[0065] At step 3, the CCF (212) may send an API invoker yet to be onboarded service API discover response to the API invoker (102) yet to be onboarded with the filtered list of service API information as mentioned in table 3.

[0066] Information elementStatusDescriptionResultMIndicates the success or failure of the discovery of the service API informationService API information(see　NOTE　2)O(see　NOTE　1)Filtered service APIs information that can be shared to the API invoker yet to be onboardedCAPIF core function identity informationO(see　NOTE　1)Indicates the CAPIF core function serving the service API category provided in the query criteriaNOTE　1: The service API information or the CAPIF core function identity information or both shall be present if the Result information element indicates that the service API discover operation is successful. Otherwise both shall not be present.NOTE　2: If topology hiding is enabled for the service API, the interface details shall be the interface details of AEF acting as service communication entry point for the service API.

[0067] Table　3: API Invoker yet to be onboarded Service API discover response

[0068] Fig. 5 is a sequence diagram that illustrates a scenario of discovery of service APIs for sharing controlled service API information according to an embodiment as disclosed herein. As shown in the sequence diagram, the API invoker (102) and the network apparatus (202) including the CCF (212) are in communication with each other. Each step is explained in further detail below.

[0069] In step 1, the API invoker (102) may send a service API discover request to the CCF (212). The request includes the identity of the API invoker (102), which may be identity information of the API invoker (102) discovering service APIs or information associated with the API invoker (102) yet to be onboarded, and may include query information as mentioned in table 4.

[0070] Information elementStatusDescriptionAPI invoker identity informationMIdentity information of the API invoker discovering service APIs or yet to be onboarded API Invoker informationQuery informationMCriteria for discovering matching service APIs (e.g. service API type, Serving Area Information (optional), preferred AEF location (optional), required API provider name (optional), UE IP address (optional), interfaces, protocols, Service KPIs (optional), and Network Slice Info (optional)).(see　NOTE)NOTE: It should be possible to discover all the service APIs.

[0071] Table　4: Service API discover request

[0072] At step 2, upon receiving the service API discover request, the CCF (212) may verify the identity of the API invoker (102) (via authentication). If authenticated, the CCF (212) retrieves the stored service API(s) information from the API registry of the CCF (212) as per the query information in the service API discover request. Further, the CCF (212) applies the discovery policy and performs filtering of service APIs information retrieved. If un-authenticated, the CCF (212) retrieves the stored service API information as per the query information in the service API discover request. Further, the CCF (212) applies the dissemination policy and performs filtering of service APIs information that can be shared to the API invoker (102) yet to be onboarded.

[0073] At step 3, the CCF (212) may send a service API discover response to the API invoker (102) with the list of service API information for which the API invoker (102) has the required authorization. For the API invoker (102) yet to be onboarded, the service API discover response includes the filtered list of service API information relevant for the API invoker (102) yet to be onboarded as mentioned in table 5.

[0074] Information elementStatusDescriptionResultMIndicates the success or failure of the discovery of the service API informationService API information(see　NOTE　2)O(see　NOTE　1)List of service APIs corresponding to the request, including API description such as service API name, service API type, Serving Area Information (optional), interface details (e.g. IP address, port number, URI), protocols, version, data format, Service KPIs (optional), and Network Slice Info (optional).CAPIF core function identity informationO(see　NOTE　1)Indicates the CAPIF core function serving the service API category provided in the query criteriaNOTE　1: The service API information or the CAPIF core function identity information or both shall be present if the Result information element indicates that the service API discover operation is successful. Otherwise both shall not be present.NOTE　2: If topology hiding is enabled for the service API, the interface details shall be the interface details of AEF acting as service communication entry point for the service API. Service API information shall be filtered that can be shared to the un-authenticated API Invoker if the request is from the un-authenticated API Invoker.

[0075] Table　5: Service API discover response

[0076] In an embodiment, the proposed solution is used in supporting the service API discovery over CAPIF interconnection procedures, by the CCF (212) considering the dissemination criteria and restricted service API information from the API publishing function (302) or interconnecting the CCF (212), to determine the service API information to be shared with the requesting entity using the interconnection service API discovery procedures (i.e. Interconnection service API discover request and Interconnection service API discover response).

[0077] Fig. 6 is a flow diagram that illustrate a method for controlling service API dissemination in a communication network system by the API invoker (102) according to an embodiment as disclosed herein. The method may include at least one step (602-606). Each step is explained in further detail below.

[0078] At step (602), the API invoker (102) may generate a service API discover request message by adding an API invoker identity information. The API invoker identity information includes identity information of the API invoker (102) discovering service APIs, which may be of onboarded or yet to be onboarded API invoker. Service APIs serve as interfaces that facilitate communication between various entities across a communication network. These APIs enable entities to request services and share data with one another.

[0079] At step (604), the API invoker (102) may transmit the service API discover request message to the network apparatus (202) including the CCF (212). The CCF (212) is a standardized framework defined by the 3GPP to harmonize the exposure and management of service APIs within telecommunication networks. The CCF (212) enables network operators or entities to securely expose their services to external or third-party providers.

[0080] At step (606), the API invoker (102) may receive a service API discover response message from the network apparatus (202) in response to the service API discover request message. The service API discover response message includes a filtered list of service API information based on a dissemination criteria relevant for at least one of an authorized API invoker (the API invoker (102) and the API invoker (102) yet to be onboarded. The dissemination criteria includes filtered service API information that is accessible to a specific requesting entity (for example, the API invoker (102), the CCF (212)) or service API information that is allowed to be shared based on a specific criteria. The specific criteria is associated with the specific requesting entity based on a current scenario. For example, the scenario may include onboarding the API invoker (102), API discovery by the API invoker (102) yet to be onboarded, API publish to interconnect the CCF (212), and the like.

[0081] Fig. 7 is a flow diagram that illustrate a method for controlling service API dissemination in a communication network system by the network apparatus (202) according to an embodiment as disclosed herein. The method may include at least one step (702-708). Each step is explained in further detail below.

[0082] At step (702), the network apparatus (202) including the CCF (212) may receive a service API discover request message from the API invoker (102). The service API discover request message includes API invoker identity information indicating the API invoker (102) , which may of the onboarded or yet to be onboarded API invoker that discovers service APIs. The API invoker identity information includes identity information of the API invoker (102) discovering service APIs. The service APIs play a crucial role in facilitating communication and data exchange between various entities within the communication network, allowing for effective collaboration and seamless operation. By accurately verifying and authenticating the identity of the API invoker (102), the service APIs can uphold security measures, regulate access control, and promote efficient interactions throughout the communication network.

[0083] At step (704), the network apparatus (202) may retrieve a dissemination criteria relevant for the API invoker (102) yet to be onboarded upon receiving the service API discover request message. The dissemination criteria includes filtered service API information that is accessible to a specific requesting entity (for example, the API invoker (102), the CCF (212)) or service API information that is allowed to be shared based on a specific criteria. The specific criteria is associated with the specific requesting entity based on a current scenario. For example, the scenario may include onboarding the API invoker (102), API discovery by the API invoker (102) yet to be onboarded, API publish to interconnect the CCF (212), and the like.

[0084] At step (706), the network apparatus (202) may generate a service API discover response message in response to the dissemination criteria retrieved. The service API discover response message includes a filtered list of service API information based on the dissemination criteria relevant for at least one of the authorized API invoker and the API invoker (102) yet to be onboarded. For instance, the filtered list of service API information is shared to the API invoker (102) based on a state of the API invoker (102) yet to be onboarded that is yet to be onboarded to the network apparatus (202). At step (708), the network apparatus (202) transmits the service API discover response generated to the API invoker (102).

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

Claims

1.A method performed by an application program interface (API) invoker, the method comprising:transmitting, to a common API framework (CAPIF) core function entity, a service API discover request message including API invoker identity information, wherein the API invoker identity information is associated with whether the API invoker is yet to be onboarded; andreceiving, from the CAPIF core function entity, a service API discover response message including service API information, wherein the service API information includes filtered service APIs information to be shared to the API invoker yet to be onboarded in case that a filtering of service APIs information is performed by the CAPIF core function entity.2.The method of claim 1, wherein the service API information is disseminated based on a requesting entity or a criteria, andwherein the service API information is informed to the CAPIF core function entity.3.The method of claim 1, wherein the service APIs information is filtered based on an API invoker authorization.4.The method of claim 1, wherein the filtering of service APIs information is performed by the CAPIF core function entity based on a requesting entity and a predetermined criteria.5.A method performed by a common API framework (CAPIF) core function entity, the method comprising:receiving, from an application program interface (API) invoker, a service API discover request message including API invoker identity information, wherein the API invoker identity information is associated with whether the API invoker is yet to be onboarded;performing a filtering of service APIs information based on the reception of the service API discover request message; andtransmitting, to the API invoker, a service API discover response message including service API information, wherein the service API information includes filtered service APIs information to be shared to the API invoker yet to be onboarded.6.The method of claim 5, wherein the service API information is disseminated based on a requesting entity or a criteria, andwherein the service API information is informed to the CAPIF core function entity.7.The method of claim 5, wherein the service APIs information is filtered based on an API invoker authorization, andwherein the filtering of service APIs information is performed by the CAPIF core function entity based on a requesting entity and a predetermined criteria.8.An application program interface (API) invoker, the API invoker comprising:a transceiver; andat least one processor configured to:transmit, to a common API framework (CAPIF) core function entity via the transceiver, a service API discover request message including API invoker identity information, wherein the API invoker identity information is associated with whether the API invoker is yet to be onboarded, andreceive, from the CAPIF core function entity via the transceiver, a service API discover response message including service API information, wherein the service API information includes filtered service APIs information to be shared to the API invoker yet to be onboarded in case that a filtering of service APIs information is performed by the CAPIF core function entity.9.The API invoker of claim 8, wherein the service API information is disseminated based on a requesting entity or a criteria, andwherein the service API information is informed to the CAPIF core function entity.10.The API invoker of claim 8, wherein the service APIs information is filtered based on an API invoker authorization.11.The API invoker of claim 8, wherein the filtering of service APIs information is performed by the CAPIF core function entity based on a requesting entity and a predetermined criteria.12.A common API framework (CAPIF) core function entity, the CAPIF core function entity comprising:a transceiver; andat least one processor configured to:receive, from an application program interface (API) invoker via the transceiver, a service API discover request message including API invoker identity information, wherein the API invoker identity information is associated with whether the API invoker is yet to be onboarded,perform a filtering of service APIs information based on the reception of the service API discover request message, andtransmit, to the API invoker via the transceiver, a service API discover response message including service API information, wherein the service API information includes filtered service APIs information to be shared to the API invoker yet to be onboarded.13.The CAPIF core function entity of claim 12, wherein the service API information is disseminated based on a requesting entity or a criteria, andwherein the service API information is informed to the CAPIF core function entity.14.The CAPIF core function entity of claim 12, wherein the service APIs information is filtered based on an API invoker authorization.15.The CAPIF core function entity of claim 12, wherein the filtering of service APIs information is performed by the CAPIF core function entity based on a requesting entity and a predetermined criteria.

Images