DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
METHOD AND SYSTEM FOR MANAGING APPLICATION PROGRAMMING INTERFACE (API) TRAFFIC IN A COMMUNICATION NETWORK
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3.PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to the field of wireless communication networks, more particularly relates to a method and a system for managing Application Programming Interface (API) traffic in the wireless communication networks.
BACKGROUND OF THE INVENTION
[0002] Generally, now days, traffic management in a communication network has become a major concern across the world. The traffic is generally the requests transmitted from a consumer to a server via a CAPIF (Common API Framework). The CAPIF provides a framework for accessing northbound APIs (Application Programming Interface). The API is an application/set of defined rules that enable different applications or more computer programs to communicate with each other.
[0003] In a normal functioning scenario between the consumer and the server, the consumer generally transmits the requests to a load balancer. The load balancer will distribute the requests among one or more servers via the APIs. There could also be situations when the consumer may access the APIs to a greater extent, maybe for malicious purposes or for any additional tasks, by transmitting multiple requests (API calls) from the consumer to the server. The API calls are basically transmitting the requests from the consumer to the server instructing the API to provide service or information. This may lead to high API traffic at the respective APIs, due to which the respective APIs may consume more time for responding to the API calls or may not respond to the API calls at all. In particular, the ability of the APIs to enable different applications or computer programs to communicate with each other is substantially hampered.
[0004] In order to manage the API traffic of the APIs by the consumer, generally API throttling and rate limiting tasks are performed manually by applying the rules or policies by modifying the algorithm or code of the APIs.
[0005] API throttling is a process of limiting the number of API calls or requests the user (herein the consumer) can make in a time period. Further, a rate limit is the maximum number of API calls that may be allowed in a particular time interval in the communication network.
[0006] In order to maintain optimal traffic at the APIs, performing tasks such as API throttling and rate limiting manually consumes more time and is a cumbersome task and due to manual intervention, there may be possibilities of errors that may occur during the process, thereby affecting the efficiency of the system.
[0007] In view of the above, there is a dire need for a system and method for AI (Artificial Intelligence)-ML (Machine Learning) based API (Application Programming Interface) throttling and rate limiting, which ensures that time consumed for handling the traffic of the API by the consumer is substantially reduced.
SUMMARY OF THE INVENTION
[0008] One or more embodiments of the present disclosure provide a method and a system for managing Application Programming Interface (API) traffic in a communication network.
[0009] In one aspect of the present invention, the method for managing the Application Programming Interface (API) traffic in the communication network is disclosed. The method includes the step of transmitting, by one or more processors, a request from an API consumer to a server. The method includes the step of configuring, by the one or more processors, API traffic management rules in response to detection of high traffic of the requests at one or more API consumers. The method includes the step of pinging, by the one or more processors, an API current status request to the server to determine current configurations of the one or more APIs. The method includes the step of receiving, by the one or more processors, a response from the one or more APIs in response to the API current status request. The method includes the step of preparing and transmitting, by the one or more processors, a final response configuration report of the APIs to the API consumer.
[0010] In one embodiment, the step of configuring of the API traffic management rules further comprises dynamically setting, by the one or more processors, the rules in real-time based on the traffic patterns detected at the one or more APIs.
[0011] In another embodiment, the API traffic management rules include API throttling and rate limiting rules based on a training model.
[0012] In another embodiment, the API throttling and rate limiting rules are part of the training model that learns historic patterns of traffic at the one or more APIs and dynamically sets management rules based on the learnt patterns.
[0013] In yet another embodiment, the method further comprises continuously updating, by the one or more processors, the training model based on changes in the environment of the communication network.
[0014] In yet another embodiment, the API throttling and rate limiting rules include predefined parameters including standard usage quotas and rate limits based on subscriptions, APIs, resources, and complexity.
[0015] In yet another embodiment, the method further comprises dynamically adding or adjusting, by the one or more processors, predefined parameters and rules which are runtime configurable.
[0016] In yet another embodiment, the API current status request includes checking the mode of API calls, whether in synchronous or asynchronous mode, and adjusting the traffic management rules accordingly.
[0017] In another aspect of the present invention, the system for managing the Application Programming Interface (API) traffic in the communication network is disclosed. The system includes a transmitter configured to transmit a request from an API consumer to a server. The system includes a traffic management unit configured to dynamically configure API traffic management rules in response to detection of high traffic of the requests at one or more API consumers. The system includes a status request unit configured to ping an API current status request to the server to determine current configurations of the one or more APIs. The system includes a response receiving unit configured to receive a response from the one or more APIs in response to the API current status request. The system includes a report generation unit configured to prepare and transmit a final response configuration report of the APIs to the API consumer.
[0018] In yet another aspect of the present invention, a User Equipment (UE) is disclosed. One or more primary processors communicatively coupled to one or more processors. The one or more primary processors coupled with a memory. The memory stores instructions which when executed by the one or more primary processors causes the UE to transmit a request to the one or more processors in order to avail one or more services provided by the server.
[0019] In yet another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by a processor is disclosed. The processor is configured to transmit a request from an Application Programming Interface (API) consumer to a server. The processor is configured to configure API traffic management rules in response to detection of high traffic of the requests at one or more API consumers. The processor is configured to ping an API current status request to the server to determine current configurations of the one or more APIs. The processor is configured to receive a response from the one or more APIs in response to the API current status request. The processor is configured to prepare and transmit a final response configuration report of the APIs to the API consumer.
[0020] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0022] FIG. 1 is an exemplary block diagram of an environment for managing Application Programming Interface (API) traffic in a communication network, according to one or more embodiments of the present disclosure;
[0023] FIG. 2 is an exemplary block diagram of a system for managing the API traffic in the communication network, according to one or more embodiments of the present disclosure;
[0024] FIG. 3 is a schematic representation of a workflow of the system of FIG. 2 communicably coupled with a User Equipment (UE), according to one or more embodiments of the present disclosure;
[0025] FIG. 4 is a block diagram of an architecture that can be implemented in the system of FIG.2, according to one or more embodiments of the present disclosure;
[0026] FIG. 5 is a block diagram of an architecture of a CAPIF framework, according to one or more embodiments of the present disclosure; and
[0027] FIG. 6 is a flow diagram illustrating a method for managing the API traffic in the communication network, according to one or more embodiments of the present disclosure.
[0028] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0029] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0030] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0031] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0032] The present invention relates to a system and a method for managing an Application Programming Interface (API) traffic in a communication network. The present invention is able to ensure that the time consumed for handling the API traffic is substantially reduced. The disclosed system and method aim at enhancing efficiency of the system by automatically configuring the API throttling and rate limit depending on the API traffic in the communication network. In particular, the present invention provides a unique approach of implementing the API throttling and rate limit rules for determining optimal parameters such as throttle and rate limit of the API to handle and process the requests from an API consumer to a destination server based on the API throttling and rate limit configurations provided by a CAPIF (Common API Framework) rule engine, API throttling and rate limit rule engine and a training model.
[0033] Referring to FIG. 1, FIG. 1 illustrates an exemplary block diagram of an environment 100 for managing an Application Programming Interface (API) traffic in a communication network 105, according to one or more embodiments of the present invention. The environment 100 includes the communication network 105, a User Equipment (UE) 110, a server 115, and a system 120. The UE 110 aids a user to interact with the system 120 for transmitting multiple requests to one or more processors 205 (shown in FIG.2) in order to avail one or more services provided by the server 115. In an embodiment, the user is one of, but not limited to, a network operator or a service provider. In an embodiment, multiple requests, include, but are not limited to, data requests, service requests, authentication requests, configuration requests, notification requests, query requests, and the like. In an embodiment, the one or more services include, but not limited to, data management services, communication services, transaction services, user authentication and security services, and the like. The API traffic management refers to the process of controlling and optimizing the flow of data between a consumer and the server 115, which ensures that the multiple requests are handled efficiently, securely, and reliably. In an embodiment, the consumer includes, but not limited to, the user, a client application, or another service. The consumer sends the multiple requests to access or interact with the one or more services hosted on the server 115. The term “user” and “consumer” are used interchangeably herein there, without limiting the scope of the disclosure.
[0034] For the purpose of description and explanation, the description will be explained with respect to the UE 110, or to be more specific will be explained with respect to a first UE 110a, a second UE 110b, and a third UE 110c, and should nowhere be construed as limiting the scope of the present disclosure. Each of the UE 110 from the first UE 110a, the second UE 110b, and the third UE 110c is configured to connect to the server 115 via the communication network 105. In an embodiment, each of the first UE 110a, the second UE 110b, and the third UE 110c is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as smartphones, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device.
[0035] The communication network 105 includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The communication network 105 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0036] The server 115 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise, a defense facility, or any other facility that provides content.
[0037] The environment 100 further includes the system 120 communicably coupled to the server 115 and each of the first UE 110a, the second UE 110b, and the third UE 110c via the communication network 105. The system 120 is configured for managing the API traffic in the communication network 105. The system 120 is adapted to be embedded within the server 115 or is embedded as the individual entity, as per multiple embodiments of the present invention.
[0038] Operational and construction features of the system 120 will be explained in detail with respect to the following figures.
[0039] FIG. 2 is an exemplary block diagram of a system 120 for managing the API traffic in the communication network 105, according to one or more embodiments of the present disclosure.
[0040] The system 120 includes a processor 205, a memory 210, a user interface 215, and a database 250. For the purpose of description and explanation, the description will be explained with respect to one or more processors 205, or to be more specific will be explained with respect to the processor 205 and should nowhere be construed as limiting the scope of the present disclosure. The one or more processor 205, hereinafter referred to as the processor 205 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions.
[0041] As per the illustrated embodiment, the processor 205 is configured to fetch and execute computer-readable instructions stored in the memory 210. The memory 210 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 210 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.
[0042] The user interface 215 includes a variety of interfaces, for example, interfaces for a Graphical User Interface (GUI), a web user interface, a Command Line Interface (CLI), and the like. The user interface 215 facilitates communication of the system 120. In one embodiment, the user interface 215 provides a communication pathway for one or more components of the system 120. Examples of the one or more components include, but are not limited to, the user equipment 110, and the database 250.
[0043] The database 250 is one of, but not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 250 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0044] Further, the processor 205, in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 205. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 205 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for processor 205 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor 205. In such examples, the system 120 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 120 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.
[0045] In order for the system 120 to manage API traffic in the communication network 105, the processor 205 includes a transmitter 220, a traffic management unit 225, a training model 230, a status request unit 235, a response receiving unit 240, and a report generation unit 245 communicably coupled to each other. In an embodiment, operations and functionalities of the transmitter 220, the traffic management unit 225, the training model 230, the status request unit 235, the response receiving unit 240, and the report generation unit 245 can be used in combination or interchangeably.
[0046] The transmitter 220 is configured to transmit the request from an Application Programming Interface (API) consumer 405 (as shown in FIG.4) to the server 115. The API consumer 405 represents an entity (which could be a client application, service, or the user) that makes the request to use the API. The request typically needs specific data or services from the server 115. The request is for retrieving data, sending data for processing, or invoking certain operations on the server 115. The server 115 is the destination where the API consumer 405 request is sent. The server 115 processes the request, typically hosts the API and the necessary resources or services required to perform the request and provides a response back to the API consumer 405. In an embodiment, the request includes, but is not limited to API calls, HTTP requests (GET, POST, PUT, DELETE), or service invocations. The requests received from the consumer pertain to utilizing one or more services provided by the server 115. In an embodiment, the one or more services, include, but not limited to, web services, data services, authentication and authorization services, communication services, and the like.
[0047] Upon transmitting the request from the API consumer 405 to the server 115, the traffic management unit 225 is configured to dynamically configure API traffic management rules in response to detection of high traffic of the requests at one or more API consumers 405. The high traffic is detected based on one or more metrics. In one embodiment, the one or more metrics include, but not limited to, request rate, error rate, response time, and server load. Based on the one or more metrics, the one or more API traffic rules are applied to the API gateway 420 (as shown in FIG.4). In an embodiment, the API traffic management rules include API throttling and rate limiting rules based on the training model 230. In one embodiment, the training model 230 includes, but is not limited to, Artificial intelligence/Machine Learning (AI/ML) model. The traffic management unit 225 is configured to dynamically set the API traffic management rules in real-time based on the traffic patterns detected at the one or more APIs. In an embodiment, the API throttling and rate limiting rules are part of the training model 230 within the traffic management unit 225 that learns historic patterns of traffic at the one or more APIs and dynamically sets management rules based on the learnt patterns.
[0048] The traffic management unit 225 is configured to utilize the training model 230 to assess traffic patterns and behaviors across the APIs. In an exemplary embodiment, a news website’s API notices a surge in traffic from a particular geographical region during a major local event or breaking news. The API may need to reroute traffic or allocate more resources to handle the regional spike, ensuring that global users are not affected. The training model 230 enables the system 120 to make real-time decisions and adjustments, ensuring optimal performance and resource allocation, and predict potential issues such as traffic surges, bottlenecks, or anomalies before occurrence.
[0049] The traffic management unit 225 automatically tweaks the API throttling and rate limiting rules based on the insights gained from the training model analysis. In an embodiment, the insights include, but not limited to, traffic patterns, performance metrics, anomaly detection, resource utilization, and the like. The training model 230 within the traffic management unit 225 is continuously updated based on changes in the environment of the communication network 105. The training model 230 utilizes a variety of ML techniques, such as supervised learning model, unsupervised learning model and reinforcement learning. In one embodiment, the supervised learning model is a type of machine learning algorithm, which is trained on a labeled dataset, which means that each training dataset is paired with an output label. The goal of supervised learning is to learn a mapping from inputs to outputs, so the supervised learning model predicts the output for new, unseen data. In one embodiment, the unsupervised learning is a type of machine learning algorithm, which is trained on data without any labels. The unsupervised learning algorithm tries to learn the underlying structure or distribution in the data in order to discover patterns or groupings. In one embodiment, the reinforcement learning is a type of machine learning where an agent learns to make decisions by performing actions in an environment to maximize cumulative reward. The agent receives feedback in the form of rewards or penalties based on the actions taken and learns a path that maps the states of the environment to the best actions.
[0050] The traffic management unit 225 is further configured to utilize predefined parameters in the API throttling and rate limiting rules. In an embodiment, the predefined parameters are specific criteria or settings that the traffic management unit 225 uses to implement the API throttling and rate limiting rules. The predefined parameters in the API throttling and rate limiting rules including standard usage quotas and rate limits based on various criteria such as subscriptions, APIs, resources, and complexity. The standard usage quotas define the maximum number of API calls allowed within a certain timeframe. The rate limits set the speed at which the API requests can be processed. The type or level of subscription user can influence the rate limits and throttling applied to the API requests. In an exemplary embodiment, premium subscribers might have higher usage quotas compared to free-tier users, which ensures that the users with different subscription plans experience different levels of access, aligning with the service levels. In an embodiment, the predefined parameters and rules within the traffic management unit 225 are runtime configurable. The predefined parameters and rules within the traffic management unit 225 can be adjusted or configured during runtime and modified while the system is operational without needing to stop or restart the service. The predefined parameters and rules are adjusted or modified by rate limits, timeouts, or quotas. For example, if the current rate limit is 1000 requests per minute, it might be increased to 1500 requests per minute based on traffic conditions. The API traffic management rules are changed to enable or disable throttling or adjusting prioritization settings.
[0051] Upon dynamically configuring the API traffic management rules in response to detection of high traffic of the requests at one or more API consumers 405, the status request unit 235 is configured to ping an API current status request to the server 115 to determine current configurations of the one or more APIs. The API is pinged to determine its current status and configurations involves sending a request to the API and receiving a response that provides information about the API's state. The status request unit 235 transmits the ping request to the API to check the current status and configuration of the API. The ping request is implemented using different protocols or methods, such as HTTP requests. In an exemplary embodiment, the HTTP GET request includes to request the information from the API, determines a path for API status endpoint, specifies domain of the server 115, and includes the OAuth token for authentication, if required. The API current status request is a specific type of request sent to the server 115, asking for the most recent configuration details of the one or more APIs and to obtain the current operational state or settings of the APIs. In an embodiment, the API current status includes, but not limited to, operational state, performance metrics, configuration details, resource utilization, security and authentication, and service-level metrics. The status request unit 235 is responsible for sending the API current status request to the server 115 to check the current state or configuration of the APIs after any changes have been made. The status request unit 235 essentially pings the server 115 to retrieve the most up-to-date information about the current state or configuration of the one or more APIs.
[0052] The status request unit 235 is further configured to determine the mode of the API calls, whether in synchronous or asynchronous mode. In the synchronous mode, the API consumer 405 waits for the server 115 response before proceeding, which means that the API calls are blocking, and the consumer does not move forward until it receives a response. In the asynchronous mode, the API consumer 405 does not wait for the server 115 response and continues processing other tasks. The response is handled separately, often using callbacks or promises, making the API calls non-blocking. The status request unit 235 is further configured to adjust the traffic management rules based on the determination of the mode of the API calls. After determining the mode of the API calls, the status request unit 235 modifies the traffic management rules to optimize performance and resource allocation based on the information. For synchronous API calls, where immediate responses are critical, the status request unit 235 prioritizes the requests, ensuring process of the request quickly to avoid delays. For asynchronous API calls, which do not require immediate responses, the status request unit 235 applies different rules, such as deprioritizing these requests or batching them to optimize server resources.
[0053] Upon pinging the API current status request to the server 115, the response receiving unit 240 is configured to receive the response from the one or more APIs in response to the API current status request. The status request unit 235, pings the server 115 with the request to determine the current status of the one or more APIs. Once the server 115 processes the request, it generates the response containing the current status information of the APIs. In an embodiment, the response includes details such as the API configurations, operational states, or any other relevant information that the system needs to manage traffic or performance.
[0054] The report generation unit 245 is configured to prepare and transmit a final response configuration report of the APIs to the API consumer 405. In an embodiment, the final response configuration report includes, but not limited to, operational state, response times, request rates, rate limits, throttling settings, and any other relevant metrics or configurations. The operational state indicates that the API is up and available. The performance metrics include details of the average response time, how many requests are being handled, and the error rate. The configuration details specify the rate limits, throttling settings, and request prioritization rules. The resource utilization provides information on server load and bandwidth usage. In an embodiment, the final response configuration report provides up-to-date information about the API’s status or configuration to the consumer to make informed decisions or take appropriate actions based on the information. The report aid to the API consumer 405 and the network operator to monitor the API performance, configurations, and take necessary actions based on the provided information.
[0055] By doing so, the system 120 is able to, advantageously, automatically configure the throttling and rate limiting of the APIs, substantially reducing time consumption of handling the traffic. The system 120 ensures the process of handling the traffic of the API, which improves processing speed of the processor 205, and reduces memory space requirement.
[0056] FIG. 3 is a schematic representation of a workflow of the system 120 of FIG. 2 communicably coupled with a User Equipment (UE), according to one or more embodiments of the present disclosure. More specifically, FIG. 3 illustrates the system 120 configured for managing the API traffic in the communication network 105. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE 110a for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0057] As mentioned earlier in FIG.1, in an embodiment, the first UE 110a may encompass electronic apparatuses. These devices are illustrative of, but not restricted to, modems, routers, switches, laptops, tablets, smartphones (including phones), or other devices enabled for web connectivity. The scope of the first UE 110a explicitly extends to a broad spectrum of electronic devices capable of executing computing operations and accessing networked resources, thereby providing users with a versatile range of functionalities for both personal and professional applications. This embodiment acknowledges the evolving nature of electronic devices and their integral role in facilitating access to digital services and platforms. In an embodiment, the first UE 110a can be associated with multiple users. Each of the first UE 110a is communicatively coupled with the processor 205.
[0058] The first UE 110a includes one or more primary processors 305 communicably coupled to the one or more processors 205 of the system 120. The one or more primary processors 305 are coupled with a memory 310 storing instructions which are executed by the one or more primary processors 305. Execution of the stored instructions by the one or more primary processors 305 enables the first UE 110a to transmit multiple requests to the one or more processors 205 in order to avail one or more services provided by the server 115.
[0059] Furthermore, the one or more primary processors 305 within the first UE 110a are uniquely configured to execute a series of steps as described herein. This configuration underscores the processor 205 capability to stitch the subscriber profile with the trace data. The coordinated functioning of the one or more primary processors 305 and the additional processors, is directed by the executable instructions stored in the memory 310. The executable instructions facilitate effective task distribution and management among the one or more primary processors 305, optimizing performance and resource use.
[0060] As mentioned earlier in FIG.2, the system 120 includes the one or more processors 205, the memory 210, the user interface 215, and the database 250. The operations and functions of the one or more processors 205, the memory 210, the user interface 215, and the database 250 are already explained in FIG. 2. For the sake of brevity, a similar description related to the working and operation of the system 120 as illustrated in FIG. 2 has been omitted to avoid repetition.
[0061] Further, the processor 205 includes the transmitter 220, the traffic management unit 225, the training model 230, the status request unit 235, the response receiving unit 240, and the report generation unit 245. The operations and functions of the transmitter 220, the traffic management unit 225, the training model 230, the status request unit 235, the response receiving unit 240, and the report generation unit 245 are already explained in FIG. 2. Hence, for the sake of brevity, a similar description related to the working and operation of the system 120 as illustrated in FIG. 2 has been omitted to avoid repetition. The limited description provided for the system 120 in FIG. 3, should be read with the description provided for the system 120 in the FIG. 2 above, and should not be construed as limiting the scope of the present disclosure.
[0062] FIG. 4 is a block diagram of an architecture 400 that can be implemented in the system of FIG.2, according to one or more embodiments of the present disclosure. The architecture 400 of the system 120 includes an API consumer 405, an Edge Load Balancer (ELB) 410, an Identity and access Management (IAM) 415, an API gateway 420, and an API service repository 455.
[0063] The architecture 400 of the system includes an API consumer 405. In an embodiment, the API consumer 405 develops applications or web sites using the APIs. In particular, the API consumer 405 are the users of APIs. In an embodiment, the API consumer 405 may transmit the request to a load balancer such as the ELB 410. The ELB 410 is configured to automatically distribute the incoming API traffic from entities such as the API consumer 405 across multiple targets, such as servers 115. In the present invention, the request may be sent from the API consumer 405 to the server 115 requesting network resources from the server 115.
[0064] The architecture 400 further includes the IAM 415. In an embodiment, the IAM 415 is a web service that facilitates securely control access to system resources. The IAM 415 is configured to centrally manage permissions or provides authentication to the API consumer 405.
[0065] The ELB 410 transmits the API traffic to the API gateway 420. The API gateway 420 is a data-plane entry point for API calls that represent consumer requests to target applications and services. The API gateway 420 typically performs request processing based on one or more predefined policies, including authentication, authorization, access control, Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) offloading, routing, and load balancing.
[0066] The API gateway 420 further includes an API orchestration configuration 425, an API throttling and rate limit rule configuration 430, an API sync call 435, an API response collection 440, an API throttling and rate limit rule engine 445, and an API async call 450.
[0067] The API orchestration configuration 425 is the process of integrating multiple APIs from different sources and reorganizing them into a consolidated set of outputs. The orchestration involves coordinating the communication and interaction between the APIs, as well as managing data flow, security, and other aspects of API integration. The API orchestration configuration 425 allows multiple ways of routing from the east bound API calls to multiple westbound API calls.
[0068] In the present invention, a common API Framework (CAPIF) rule engine is configured to manage API traffic using the API throttling and rate limit rule configuration 430 and the API throttling and rate limit rule engine 445. In the present invention, the API throttling and rate limiting rule configuration 430 and API throttling and rate limiting rule engine 445 consists of the training model 230. Depending on the high traffic detected at the one or more APIs (which may be due to multiple requests sent by the API consumer 405 or over utilization of the APIs by the consumer by carrying out substantial additional tasks). The API throttling and rate limiting rule configuration 430 are dynamically configured in real time in order to optimally handle the API traffic flow and restrict the consumer from over utilizing the APIs. The API throttling is a process of limiting the number of API calls or requests the user, herein the consumer can make in a time period. Further, the rate limit is the maximum number of API calls that may be allowed in a particular time interval in the communication network.
[0069] The API gateway 420 further includes the API sync call 435 and the API async call 450. In an embodiment, the API call may refer to the API request for allowing one application to request data or services from another application. If an API call is in synchronous mode, it is referred to as that of a code execution block (or wait) for the API call to return before continuing. In particular, API call in synchronous mode indicates that until a response is returned by the API, the application will not execute any further functions, which could be perceived by the user as latency or performance lag in the application.
[0070] Further, when the API call is made to the one or more APIs in asynchronous mode, the web service may allow users to conduct multiple requests at the same time without waiting for the previous request to be executed. This means that the server may process multiple requests at the same time, decreasing the APIs overall response time.
[0071] The API response collection 440 may include the location where the data or information that is returned from the server 115 is stored when the API request is transmitted. Further, when the API call is made to the one or more APIs in the asynchronous mode, the web service may allow the users to conduct multiple requests at the same time without waiting for the previous request to be executed. In this regard, the server 115 may process multiple requests at the same time, decreasing the APIs overall response time.
[0072] The architecture 400 of the system 120 further includes API service repository 455. The API service repository 455 includes, but not limited to, databases, data lakes, data containers, persistence cache and distributed cache, etc. The API service repository 455 may be a catalogue in which all the services available on the communication network 105 are stored.
[0073] FIG. 5 is a block diagram of an architecture of the Common API Framework (CAPIF) 500, according to one or more embodiments of the present disclosure.
[0074] The CAPIF framework 500 includes a Service Capability Server/Application Server (SCS/AS) 505, the CAPIF 510, an analysis platform 515, a Service Capability Exposure Function (SCEF) 520, a Network Exposure Function (NEF) 525, a domain adapter 530, a 4G Evolved Packet System (EPS) 535, a 5G core Service Based Architecture (SBA) 540, a private 5G network 545, a massive Machine Type Communication (mMTC)/Internet of Things (IoT) services 555, an Enhanced Mobile Broadband (eMBB) service provider 560, the API gateway for mobile applications 565, and an Element Management System (EMS) 570.
[0075] The SCS/AS 505 enables seamless integration between external applications and core network capabilities. The SCS abstracts network capabilities and offers them as standardized APIs, while the AS contains the application logic that uses these APIs to provide services to users. The SCS exposes and manages network capabilities (like sending SMS, checking user location, etc.) to external application servers through the APIs. The AS handles application-specific tasks (like user requests), processes the tasks, and calls the necessary APIs (often provided by the SCS) to access the network services required to fulfill those requests. Further, the SCS/AS 505 is connected with the SCEF 520 and the CAPIF 510 via a Hypertext Transfer Protocol (HTTP)/ WebSocket (WS).
[0076] The CAPIF 510 is a framework designed by a Third Generation Partnership Project (3GPP) to provide a standardized way of exposing network services as the APIs, making it easier for application developers to access the network functions. The CAPIF ensures that the APIs are exposed securely, protecting the underlying network infrastructure. The CAPIF mainly utilizes the API gateway 420 to act as an intermediary that handles the API requests from third-party applications, ensuring proper routing, security, and policy enforcement. In another aspect, the CAPIF provides the API gateway 420 to transform the request to consumer, destination entities, or host applications.
[0077] The analysis platform 515 refers to a module or system responsible for monitoring, analyzing, and managing the data related to the APIs exposed by network functions. The analysis platform 515 ensures optimal performance, security, and usage efficiency of the APIs and provides insights into their operations.
[0078] The SCEF 520 includes an application server 520a and a distributed and clustered data system 520b. The SCEF 520 is key component that allows third-party applications and external systems to securely access and interact with the services and capabilities provided by a mobile network operator via HTTP 2.0. The SCEF 520 acts as an intermediary between the external applications and the network's core functions, offering a secure and standardized way to expose network services such as IoT management, location services, and communication APIs. The SCEF 520 acts as a secure interface between the application server 520a and the mobile network, handling security (authentication and authorization), traffic management (throttling, rate limiting), and protocol translation. In the distributed and clustered data system 520b are deployed across multiple physical or virtual servers located in different geographic locations. This ensures that the system can handle a large number of API requests from the application server 520a spread over different regions and improve response times by routing requests to the nearest server.
[0079] The SCEF 520 handles protocol translations and abstracts the complexity of internal 3GPP protocols (e.g., Diameter, NAS) from external applications, providing them with simplified API-based access. Further, the SCEF 520 handles the 4G EPS 535. The 4G EPS 535 is the core architecture used in 4G networks to deliver high-speed data, voice, and multimedia services. The 4G EPS 535 is part of an Evolved Packet Core (EPC), which is the backbone of a Long-Term Evolution (LTE) network, and it supports both packet-switched (PS) services, such as internet browsing and video streaming, and voice over LTE (VoLTE).
[0080] The NEF 525 serves as a key interface that securely exposes network capabilities and services of the 5G system to external applications or third-party services, such as Application Servers (AS) 525a. The NEF 525 allows authorized access to various network functions and data through APIs while ensuring secure and controlled communication between external parties and the core network. The NEF 525 often works in environments with the distributed and clustered data systems 525b. The NEF is necessary to manage the scalability, and reliability needs of the network. Further, the NEF 525 handles the 5G core SBA 540.
[0081] The domain adapter 530 connects the CAPIF 510 with the Application Server 530a, enabling communication between the CAPIF 510 and the applications running on these servers. The domain adapter 530 ensures that requests and responses between the CAPIF 510 and the AS 530a are correctly formatted and understood. The domain adapter 530 further includes the private 5G network 550, the mMTC/IoT services 555, the eMBB service provider 560, and the API gateway for applications 565.
[0082] The EMS 570 is a system within the CAPIF 510 that handles the creation, management, and lifecycle of various entities, which can include users, applications, services, and other components necessary for the operation of the CAPIF framework 500.
[0083] FIG. 6 is a flow diagram illustrating a method 600 for managing the API traffic in the communication network 105, according to one or more embodiments of the present disclosure. For the purpose of description, the method 600 is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0084] At step 605, the method 600 includes the step of transmitting the request from the API consumer 405 to the server 115 by the transmitter 220. The API consumer 405 represents an entity that makes the request to use the API. The request typically needs specific data or services from the server 115. The server 115 is the destination where the API consumer 405 request is sent. The server 115 processes the request, typically hosts the API and the necessary resources or services required to perform the request and provides a response back to the API consumer 405.
[0085] At step 610, the method 600 includes the step of dynamically configuring the API traffic management rules in response to detection of high traffic of the requests at one or more API consumers 405 by the traffic management unit 225. In an embodiment, the API traffic management rules include API throttling and rate limiting rules based on the training model 230. The traffic management unit 225 is configured to dynamically set the API traffic management rules in real-time based on the traffic patterns detected at the one or more APIs. In an embodiment, the API throttling and rate limiting rules are part of the training model 230 within the traffic management unit 225 that learns historic patterns of traffic at the one or more APIs and dynamically sets the API throttling and rate limiting rules based on the learnt patterns.
[0086] At step 615, the method 600 includes the step of pinging the API current status request to the server 115 to determine current configurations of the one or more APIs by the status request unit 235. The API current status request is a specific type of request sent to the server 115, asking for the most recent configuration details of the one or more APIs and to obtain the current operational state or settings of the APIs. The status request unit 235 is responsible for sending the API current status request to the server 115 to check the current state or configuration of the APIs after any changes have been made. The status request unit 235 essentially pings the server 115 to retrieve the most up-to-date information about the current state or configuration of the one or more APIs.
[0087] At step 620, the method 600 includes the step of receiving the response from the one or more APIs in response to the API current status request by the response receiving unit 240. The status request unit 235, pings the server 115 with the request to determine the current status of the one or more APIs. Once the server 115 processes the request, it generates the response containing the current status information of the APIs. In an embodiment, the response includes details such as the API configurations, operational states, or any other relevant information that the system needs to manage traffic or performance.
[0088] At step 625, the method 600 includes the step of preparing and transmitting the final response configuration report of the APIs to the API consumer 405 by the report generation unit 245. In an embodiment, the final response configuration report provides up-to-date information about the API’s status or configuration to the consumer to make informed decisions or take appropriate actions based on the information.
[0089] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 205. The processor 205 is configured to configure in real time one or more API traffic rules and parameters for at least one of a plurality of APIs experiencing high traffic based on detection of high traffic in at least one of the plurality of APIs. The processor 205 is configured to transmit, a ping request to the at least one of plurality of APIs experiencing high traffic in at least one of, a synchronous and an asynchronous mode. The processor 205 is configured to receive, a response pertaining to the ping request from the at least one of the plurality of APIs experiencing high traffic. The processor 205 is configured to transmit a final response configuration report to the consumer based on the received response pertaining to the ping request from the at least one of the plurality of APIs.
[0090] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-6) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0091] The present disclosure provides technical advancement for configuring the API depending on the API traffic in the communication network. The present invention is able to ensure that the time consumed for handling the API traffic is substantially reduced. The present disclosure automatically configures the API throttling and rate limit depending on the API traffic in the communication network. In particular, the present invention provides a unique approach of implementing the API throttling and rate limit rules for determining optimal parameters such as throttle and rate limit of the API to handle and process the requests from the API consumer to the server based on the API throttling and rate limit configurations provided by a CAPIF (Common API Framework) rule engine, API throttling and rate limit rule engine and the training model .
[0092] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS

[0093] Environment - 100
[0094] Network-105
[0095] User equipment- 110
[0096] Server - 115
[0097] System -120
[0098] Processor - 205
[0099] Memory - 210
[00100] User interface-215
[00101] Transmitter– 220
[00102] Traffic management unit– 225
[00103] Training model– 230
[00104] Status request unit– 235
[00105] Response receiving unit- 240
[00106] Report generation unit- 245
[00107] Database- 250
[00108] Primary processor-305
[00109] Memory– 310
[00110] Architecture- 400
[00111] API consumer- 405
[00112] Edge Load Balancer- 410
[00113] Identity and Access Management- 415
[00114] API gateway- 420
[00115] API orchestration configuration- 425
[00116] API throttling and rate limit rule configuration- 430
[00117] API sync call- 435
[00118] API response collection- 440
[00119] API throttling and rate limit rule engine - 445
[00120] API async call- 450
[00121] API service repository- 455
[00122] SCS/AS- 505
[00123] CAPIF- 510
[00124] Analysis platform- 515
[00125] SCEF- 520
[00126] Application server- 520a
[00127] Distributed and clustered data system- 520b
[00128] NEF-525
[00129] Application server- 525a
[00130] Distributed and clustered data system- 525b
[00131] Domain adapter- 530
[00132] Application server- 530a
[00133] Distributed and clustered data system- 530b
[00134] 4G EPS- 535
[00135] 5G core SBA- 540
[00136] Private 5G network- 550
[00137] mMTC/IoT services- 555
[00138] eMBB service provider- 560
[00139] API gateway for mobile applications- 565
[00140] EMS- 570

,CLAIMS:CLAIMS
We Claim:
1. A method (600) for managing Application Programming Interface (API) traffic in a communication network (105), the method (600) comprising the steps of:
transmitting, by one or more processors (205), a request from an API consumer to a server (115);
configuring, by the one or more processors (205), API traffic management rules in response to detection of high traffic of the requests at one or more API consumers;
pinging, by the one or more processors (205), an API current status request to the server to determine current configurations of the one or more APIs;
receiving, by the one or more processors (205), a response from the one or more APIs in response to the API current status request; and
preparing and transmitting, by the one or more processors (205), a final response configuration report of the APIs to the API consumer (405).

2. The method (600) as claimed in claim 1, wherein the step of configuring of the API traffic management rules further comprises dynamically setting, by the one or more processors (205), the rules in real-time based on the traffic conditions detected at the one or more APIs.

3. The method (600) as claimed in claim 1, wherein the API traffic management rules include API throttling and rate limiting rules based on a training model (230).
.
4. The method (600) as claimed in claim 1, wherein the API throttling and rate limiting rules are part of the training model (230) that learns historic patterns of traffic at the one or more APIs and dynamically sets the API throttling and rate limiting rules based on the learnt patterns.

5. The method (600) as claimed in claim 3, wherein the method (500) further comprises continuously updating, by the one or more processors (205), the training model (230) based on changes in the environment of the communication network (105).

6. The method (600) as claimed in claim 1, wherein the API throttling and rate limiting rules include predefined parameters including standard usage quotas and rate limits based on subscriptions, APIs, resources, and complexity.

7. The method (600) as claimed in claim 1, wherein the method (500) further comprises dynamically adding or adjusting, by the one or more processors (205), predefined parameters and rules which are runtime configurable.

8. The method (600) as claimed in claim 1, wherein the API current status request includes checking the mode of API calls, whether in synchronous or asynchronous mode, and adjusting the traffic management rules accordingly.

9. A system (120) for managing Application Programming Interface (API) traffic in a communication network (105), the system (120) comprising:
a transmitter (220) configured to transmit a request from an API consumer (405) to a server (115);
a traffic management unit (225) configured to dynamically configure API traffic management rules in response to detection of high traffic of the requests at one or more API consumers;
a status request unit (235) configured to ping an API current status request to the server to determine current configurations of the one or more APIs;
a response receiving unit (240) configured to receive a response from the one or more APIs in response to the API current status request; and
a report generation unit (245) configured to prepare and transmit a final response configuration report of the APIs to the API consumer (405).

10. The system (120) as claimed in claim 9, wherein the traffic management unit (225) is configured to dynamically set the API traffic management rules in real-time based on the traffic patterns detected at the one or more APIs.

11. The system (120) as claimed in claim 9, wherein the API traffic management rules include API throttling and rate limiting rules based on a training model (230).

12. The system (120) as claimed in claim 9, wherein the API throttling and rate limiting rules are part of the training model (230) within the traffic management unit (225) that learns historic patterns of traffic at the one or more APIs and dynamically sets the API throttling and rate limiting rules based on the learnt patterns.

13. The system (120) as claimed in claim 11, wherein the training model (230) within the traffic management unit (225) is continuously updated based on changes in the environment of the communication network (105).

14. The system (120) as claimed in claim 9, wherein the traffic management unit (225) is further configured to utilize predefined parameters in the API throttling and rate limiting rules, including standard usage quotas and rate limits based on various criteria such as subscriptions, APIs, resources, and complexity.

15. The system (120) as claimed in claim 9, wherein the predefined parameters and rules within the traffic management unit (225) are runtime configurable.

16. The system (120) as claimed in claim 9, wherein the status request unit (235) is further configured to determine the mode of API calls, whether in synchronous or asynchronous mode, and to adjust the traffic management rules based on this determination.

17. A User Equipment (UE) (110), comprising:
one or more primary processors (305) communicatively coupled to one or more processors (205), the one or more primary processors (305) coupled with a memory (310), wherein said memory (310) stores instructions which when executed by the one or more primary processors (305) causes the UE (110) to:
transmit, a request to the one or more processors (205) in order to avail one or more services provided by the server (115); and
wherein the one or more processors (205) is configured to perform the steps as claimed in claim 1.

18. A non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by a processor (205), causes the processor (205) to:
transmit a request from an Application Programming Interface (API) consumer to a server (115);
configure API traffic management rules in response to detection of high traffic of the requests at one or more API consumers;
ping an API current status request to the server to determine current configurations of the one or more APIs;
receive a response from the one or more APIs in response to the API current status request; and
prepare and transmit a final response configuration report of the APIs to the API consumer (405).