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
SYSTEM AND METHOD FOR DETECTING ANAMOLIES IN AN APPLICATION PROGRAMMING INTERFACE SERVICE

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 generally to a wireless communication system, and in particular, to a method and a system for detecting anomalies and generating notifications towards applications routing agents in the wireless communication system.
BACKGROUND OF THE INVENTION
[0002] A telecommunication network may undergo service degradation due to system errors, exceptions, or any other kind of failure. In a backend, there are multiple applications that run in an active mode that serve a telecommunication traffic in the telecommunication network. When one of these services is down due to any error (e.g. network fluctuation or any other kind of exception), it is desirable to predict such errors proactively before their occurrence, i.e. before the actual service degradation. In other words, it desirable to analyse patterns of errors, so that the occurrence of such errors can be predicted beforehand and therefore service degradation can be avoided. Due to system errors, exceptions, and Application Programming Interface (API) call failures, quality of service of the telecommunication network is degraded.
[0003] There is, therefore, a need for detection at an early stage whenever there is any service degradation, API call degradation, or increase in a response time.
SUMMARY OF THE INVENTION
[0004] One or more embodiments of the present disclosure provide a system and a method for detecting anomalies in an API service.
[0005] In one aspect of the present invention, the method of detecting anomalies in an API service is disclosed. The method includes receiving, by one or more processors, an API call request from a user equipment. Further, the method includes validating, by the one or more processors, a token for the API call request. Further, the method includes extracting, by the one or more processors, an API key from the token when the token is determined to be valid. Further, the method includes routing, by the one or more processors, the API call request to an API service provider by using the API key. Further, the method includes generating by the one or more processors, a negative token response when the token is determined to be invalid. Further, the method includes sending, by the one or more processors, the negative token response to the user equipment; wherein the invalid token indicates existence of anomalies in the API service.
[0006] In an embodiment, further, the method includes validating, by the one or more processors, a plan and access control when the token is valid, wherein in the plan and access control, an API exposing function obtains an access control policy from a CAPIF by sending a GET message to the CAPIF with an API exposing function identifier and an API identification.
[0007] In an embodiment, further, the method includes requesting, by the one or more processors, for a transformation logic when the plan and access control is determined to be valid. The transformation logic transforms headers and QueryParam while detecting anomalies in the API service. The headers in the API request includes metadata about the API call request, such as authentication tokens, content type, and user agent. The transformation logic for the headers involves standardizing or extracting relevant information from the headers to facilitate anomaly detection. In an example, the API service is monitoring for anomalies related to unauthorized access attempts. In this context, the headers of incoming API requests includes an authorization token. The QueryParam is part of a uniform resource locator (URL) associated with the API call request and carries data that influences the behavior of the API call request. The transformation logic for the QueryParam involves interpreting information (e.g., unusual client behavior information, unauthorized access information or the like) to detect the anomalies effectively. Further, the method includes generating, by the one or more processors, a log file for the API call request when the plan and access control is determined to be valid, the log file is used to identify patterns in one or more API call requests and predict one or more errors in the one or more API call requests. Further, the method includes analysing, by the one or more processors, the log file to identify a type of the API call request, pattern in the API response, one or more error types and anomalies in the API service.
[0008] In an embodiment, the API call request is enriched and a session identifier is created based on the transformation logic, and wherein the enriched API call request is forwarded to an API provider to get the API response.
[0009] In an embodiment, further, the method includes generating, by the one or more processors, a negative access response when the plan and access control is determined to be invalid.
[0010] In an embodiment, validating of the token comprises checking a structure, signature, expiration, and intended use of the token, while detecting unusual usage patterns to identify potential anomalies or security threats in the API call request.
[0011] In an embodiment, the token used for the API call request is received from a client application running in the UE and is included in an authorization header of the API call request.
[0012] In another aspect of the present invention, the system of detecting anomalies in an API service application routing is disclosed. The system includes a receiving unit, a validating unit, an extracting unit, a routing unit and a response unit. The receiving unit receives an API call request from a user equipment. The validating unit validates a token for the API call request. The extracting unit extracts an API key from the token, when the token is determined to be valid. The routing unit routes the API call request to an API provider by using the API key. The response unit creates a negative token response when the token is determined to be invalid, and send the negative token response to the user equipment, the invalid token indicates existence of anomalies in the API service application routing.
[0013] In another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions is disclosed. The computer readable instructions, when executed by a processor, cause the processor to validate a token for the API call request. The processor is further configured to extract an API key from the token when the token is determined to be valid. Further, the processor is configured to route the API call request to an API provider by using the API key. The processor is further configured to generate a negative token response when the token is determined to be invalid. The processor is further configured to send the negative token response to the user equipment, where the invalid token indicates existence of anomalies in the API service.
[0014] 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
[0015] 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.
[0016] FIG. 1 is an exemplary block diagram of an environment for detecting anomalies in an API service, according to various embodiments of the present disclosure.
[0017] FIG. 2 is a block diagram of a system of FIG. 1, according to various embodiments of the present disclosure.
[0018] FIG. 3 is an example schematic representation of the system of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system.
[0019] FIG. 4 is a flow diagram illustrating an internal call flow for detecting anomalies in the API service, in accordance with some embodiments.
[0020] FIG. 5 is a flowchart of a method of detecting anomalies and generating notifications towards applications routing agents, in accordance with some embodiments.
[0021] FIG. 6 illustrates a system architecture for detecting anomalies and generating notifications towards the applications routing agents, in accordance with some embodiments.
[0022] FIG. 7 is an exemplary flow diagram illustrating the method for detecting anomalies in the API service, according to various embodiments of the present disclosure.
[0023] Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.
[0024] The foregoing shall be more apparent from the following detailed description of the invention.

DETAILED DESCRIPTION OF THE INVENTION
[0025] 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.
[0026] 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.
[0027] 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.
[0028] Before discussing example, embodiments in more detail, it is to be noted that the drawings are to be regarded as being schematic representations and elements that are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software or a combination thereof.
[0029] Further, the flowcharts provided herein, describe the operations as sequential processes. Many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of operations maybe re-arranged. The processes may be terminated when their operations are completed, but may also have additional steps not included in the figured. It should be noted, that in some alternative implementations, the functions/acts/ steps noted may occur out of the order noted in the figured. For example, two figures shown in succession may, in fact, be executed substantially concurrently, or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
[0030] Further, the terms first, second etc… may be used herein to describe various elements, components, regions, layers and/or sections, it should be understood that these elements, components, regions, layers and/or sections should not be limited by these terms. These terms are used only to distinguish one element, component, region, layer or section from another region, layer, or a section. Thus, a first element, component, region layer, or section discussed below could be termed a second element, component, region, layer, or section without departing form the scope of the example embodiments.
[0031] As used herein, the singular forms “a,” “an,” and “the,” are intended to include the plural forms as well, unless the context clearly indicates otherwise. As used herein, the terms “and/or” and “at least one of” include any and all combinations of one or more of the associated listed items. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
[0032] Unless specifically stated otherwise, or as is apparent from the description, terms such as “processing” or “computing” or “calculating” or “determining” of “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device/hardware, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[0033] The present disclosure relates to detecting anomalies and generating notifications towards application routing agents. The application routing agents are integral to managing API traffic and ensuring that requests are correctly directed and handled. In the realm of anomaly detection, they are crucial for monitoring and identifying deviations in API usage patterns that could indicate security threats, performance issues, or other unexpected behaviors. Their ability to log, analyze, and act on routing data helps in maintaining the health and security of API services. Each request in a communication network goes through a Common API Framework (CAPIF). The CAPIF is a gateway that analyses service patterns, request response patterns, error codes and all the exceptions. Further, the CAPIF logs files and dumps them to a databases. Later, the logged files can be used to identify patterns and predict the errors and therefore the service degradation.
[0034] In an example, various thresholds are defined in the CAPIF. For example, a timeout of more than 80% for a particular service can be defined as a threshold indicating that the system will be going down because of the errors. Before reaching the higher threshold, the concerned users (e.g., stakeholders or the like) can be informed so that they can perform analysis or take appropriate actions.
[0035] FIG. 1 illustrates an exemplary block diagram of an environment (100) for detecting anomalies in an API service, according to various embodiments of the present disclosure. The environment (100) comprises a plurality of user equipment’s (UEs) (102-1, 102-2, ……,102-n). The at least one UE (102-n) from the plurality of the UEs (102-1, 102-2, ……102-n) is configured to connect to a system (108) via a communication network (106). Hereafter, label for the plurality of UEs or one or more UEs is 102.
[0036] In accordance with yet another aspect of the exemplary embodiment, the plurality of UEs (102) may be a wireless device or a communication device that may be a part of the system (108). The wireless device or the UE (102) may include, but are not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch, a computer device, and so on), a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication or Voice Over Internet Protocol (VoIP) capabilities. In an embodiment, the UEs (102) may include, but are not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as 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, where the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen and the like. It may be appreciated that the UEs (102) may not be restricted to the mentioned devices and various other devices may be used. A person skilled in the art will appreciate that the plurality of UEs (102) may include a fixed landline, and a landline with assigned extension within the communication network (106).
[0037] The communication network (106), may use one or more communication interfaces/protocols such as, for example, Voice Over Internet Protocol (VoIP), 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as Code Division Multiple Access (CDMA), CDMA2000, Wideband CDMA (WCDMA), Radio Frequency Identification (e.g., RFID), Infrared, laser, Near Field Magnetics, etc.
[0038] The communication network (106) 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 (106) may include, but is not limited to, a Third Generation (3G) network, a Fourth Generation (4G) network, a Fifth Generation (5G) network, a Sixth Generation (6G) network, a New Radio (NR) network, a Narrow Band Internet of Things (NB-IoT) network, an Open Radio Access Network (O-RAN), and the like.
[0039] The communication network (106) may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The communication network (106) may also include, 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, a VOIP or some combination thereof.
[0040] One or more network elements can be, for example, but not limited to a base station that is located in the fixed or stationary part of the communication network (106). The base station may correspond to a remote radio head, a transmission point, an access point or access node, a macro cell, a small cell, a micro cell, a femto cell, a metro cell. The base station enables transmission of radio signals to the UE (102) or a mobile transceiver. Such a radio signal may comply with radio signals as, for example, standardized by a 3rd Generation Partnership Project (3GPP) or, generally, in line with one or more of the above listed systems. Thus, a base station may correspond to a NodeB, an eNodeB, a Base Transceiver Station (BTS), an access point, a remote radio head, a transmission point, which may be further divided into a remote unit and a central unit. The 3GPP specifications cover cellular telecommunications technologies, including radio access, core network, and service capabilities, which provide a complete system description for mobile telecommunications.
[0041] The system (108) is communicatively coupled to a server (104) via the communication network (106). The server (104) can be, for example, but not limited to a standalone server, a server blade, a server rack, an application server, a bank of servers, a business telephony application server (BTAS), a server farm, a cloud server, an edge server, home server, a virtualized server, one or more processors executing code to function as a server, or the like. In an implementation, the server (104) may operate at various entities or a single entity (include, but is not limited to, a vendor side, a service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, a defense facility side, or any other facility) that provides service.
[0042] The environment (100) further includes the system (108) communicably coupled to the server (e.g., remote server or the like) (104) and each UE of the plurality of UEs (102) via the communication network (106). The remote server (104) is configured to execute the requests in the communication network (106).
[0043] The system (108) is adapted to be embedded within the remote server (104) or is embedded as an individual entity. The system (108) is designed to provide a centralized and unified view of data and facilitate efficient business operations. The system (108) is authorized to access to update/create/delete one or more parameters of their relationship between the requests for the API service, which gets reflected in real-time independent of the complexity of network.
[0044] In another embodiment, the system (108) may include an enterprise provisioning server (for example), which may connect with the remote server (104). The enterprise provisioning server provides flexibility for enterprises, ecommerce, finance to update/create/delete information related to the requests for the API service in real time as per their business needs. A user with administrator rights can access and retrieve the requests for the API service and perform real-time analysis in the system (108).
[0045] The system (108) 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 business telephony application server (BTAS), 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 implementation, system (108) may operate at various entities or single entity (for example include, but is not limited to, a vendor side, service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, ecommerce side, finance side, a defense facility side, or any other facility) that provides service.
[0046] However, for the purpose of description, the system (108) is described as an integral part of the remote server (104), without deviating from the scope of the present disclosure. Operational and construction features of the system (108) will be explained in detail with respect to the following figures.
[0047] FIG. 2 illustrates a block diagram of the system (108) provided for detecting anomalies in the API service, according to one or more embodiments of the present invention. As per the illustrated embodiment, the system (108) includes one or more processors (202), a memory (204), an input/output interface unit (206), a display (208), an input device (210), and a database (214). Further the system (108) may comprise one or more processors (202). The one or more processors (202), hereinafter referred to as the processor (202) 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. As per the illustrated embodiment, the system (108) includes one processor. However, it is to be noted that the system (108) may include multiple processors as per the requirement and without deviating from the scope of the present disclosure.
[0048] An information related to the request related to the API service may be provided or stored in the memory (204) of the system (108). Among other capabilities, the processor (202) is configured to fetch and execute computer-readable instructions stored in the memory (204). The memory (204) 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 (204) may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0049] The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like. In an embodiment, the system (108) may include an interface(s). The interface(s) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as input/output (I/O) devices, storage devices, and the like. The interface(s) may facilitate communication for the system. The interface(s) may also provide a communication pathway for one or more components of the system. Examples of such components include, but are not limited to, processing unit/engine(s) and the database (214). The processing unit/engine(s) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s).
[0050] The information related to the requests related to the API service may further be configured to render on the user interface (206). The user interface (206) may include functionality similar to at least a portion of functionality implemented by one or more computer system interfaces such as those described herein and/or generally known to one having ordinary skill in the art. The user interface (206) may be rendered on the display (208), implemented using Liquid Crystal Display (LCD) display technology, Organic Light-Emitting Diode (OLED) display technology, and/or other types of conventional display technology. The display (208) may be integrated within the system (108) or connected externally. Further the input device(s) (210) may include, but not limited to, keyboard, buttons, scroll wheels, cursors, touchscreen sensors, audio command interfaces, magnetic strip reader, optical scanner, etc.
[0051] The database (214) may be communicably connected to the processor (202) and the memory (204). The database (214) may be configured to store and retrieve the request pertaining to features, or services or workflow of the system (108), access rights, attributes, approved list, and authentication data provided by an administrator. In another embodiment, the database (214) may be outside the system (108) and communicated through a wired medium and a wireless medium.
[0052] Further, the processor (202), 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 (202). 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 (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor (202). In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by an electronic circuitry.
[0053] In order for the system (108) to detect anomalies in the API service, the processor (202) includes a receiving unit (216), a validating unit (218), an extracting unit (220), a routing unit (224) and a response unit (226). The receiving unit (216), the validating unit (218), the extracting unit (220), the routing unit (224) and the response unit (226) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor (202). 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 (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by the electronic circuitry.
[0054] In order for the system (108) to detect the anomalies (e.g., system errors, exceptions, network fluctuation, or any other kind of failure) in the API service, the receiving unit (216), the validating unit (218), the extracting unit (220), the routing unit (224) and the response unit (226) are communicably coupled to each other. In an exemplary embodiment, the receiving unit (216) receives an API call request from the UE (102). The API call request refers to an individual interaction initiated by a client to access or manipulate resources provided by the API. The API call request typically includes details like the endpoint being accessed, a Hypertext Transfer Protocol (HTTP) method (e.g., GET, POST), headers, and any request parameters or payload.
[0055] Further, the validating unit (218) validates a token for the API call request. In an embodiment, the validating of the token involves checking its structure, signature, expiration, and intended use, while also detecting unusual usage patterns to identify potential anomalies or security threats in the API call request. In an example, a token structure validation ensure a token format matching expected patterns (e.g., JWT or OAuth tokens). When the token is determined to be valid, the extracting unit (220) extracts an API key from the token. The API key, derived from the token, is a unique identifier used to authenticate and authorize the API call request. By monitoring its usage patterns and implementing rate limits, the user of the system (108) can detect anomalies and potential security threats effectively.
[0056] By using the API key, the routing unit (224) routes the API call request to an API provider (412) (as shown in FIG. 4). The response unit (226) creates a negative token response when the token is determined to be invalid, and sends the negative token response to the UE (102). The invalid token indicates the existence of anomalies in the API service application routing.
[0057] Further, the validating unit (218) validates a plan and access control when the token is valid. In the plan and access control, the API exposing function obtains the access control policy from the CAPIF (404) by sending a GET message to the CAPIF (404) with an API exposing function identifier and the API identification. The GET message may include an API invoker ID for retrieving access control policy of the requested API invoker. Upon receiving the GET message, the CAPIF (404) verifies the identity of the API exposing function and determines if the API exposing function is authorized to obtain the access control policy corresponding to the API identification. If the API exposing function is authorized to obtain the access control policy, the CAPIF (404) responds with the access control policy information corresponding to the API identification and the API invoker ID (if present) in the GET message. If authorization check is not successful, the AEF is provided with a failure indication via an obtain access control policy response.
[0058] The API invoker is typically provided by a 3rd party application provider who has service agreement with a PLMN operator. The CAPIF (404) authenticates the API invoker, provides the authorization information and service API discovery. The API exposing function (AEF) is the provider of the service APIs and is also the service communication entry point of the service API. An API publishing function (APF) enables the API provider to publish the service APIs information. An API management function (AMF) enables the API provider to perform administration of the Service APIs.
[0059] Further, the extracting unit (220) requests for a transformation logic when the plan and access control is determined to be valid.
The transformation logic minimizes code (or instruction) changes as most of the work is done using transformations. The client or within the server internally will get the desired output/input. By this, the proposed method may not only manipulate the request or response but also the method can transform the headers and QueryParam. In an example, if the client doesn’t want all the parameters in response, so by transformation user will get the response according to their convenience. So it adds flexibility and efficiency to the code.
[0060] IsHeaderTransformationRequired:- It will check if any header transformation is required when client request with their headers to destination or when destination provide response to client via the CAPIF. This transformation is done by the CAPIF. For example, the client is sending header as user-id but destination wants that to be userId.
[0061] isQueryParamTransformationRequired:- It will check if there is any query parameter transformation required when client request to destination with or when destination provide response to client. This transformation is done by the CAPIF. For example, the destination is sending QueryParam as user-name and clients need that as UserName.
[0062] isBodyTransformationRequired:- It will check whether there should be a transformation in request body sent by a client or the response body sent by the destination via the CAPIF. This transformation is done by the CAPIF. For example, the client is sending customerId in body but destination need it as consumerId.
[0063] The transformation logic transforms headers and QueryParam while detecting anomalies in the API service. The headers in the API request includes metadata about the API call request, such as authentication tokens, content type, and user agent. The transformation logic for the headers involves standardizing or extracting relevant information from the headers to facilitate anomaly detection. In an example, the API service is monitoring for anomalies related to unauthorized access attempts. In this context, the headers of incoming API requests includes an authorization token. The QueryParam is part of a uniform resource locator (URL) associated with the API call request and carries data that influences the behavior of the API call request. The transformation logic for the QueryParam involves interpreting information (e.g., unusual client behavior information, unauthorized access information or the like) to detect the anomalies effectively.
[0064] Further, the extracting unit (220) generates a log file for the API call request when the plan and access control is determined to be valid. The log file is used to identify patterns in one or more API call requests and predict errors in the one or more API call requests. Further, the extracting unit (220) analyses the log file to identify a type of the API call request, pattern in the API response, one or more error types and anomalies (e.g. network fluctuation, server error or the like) in the API service. The type of the API call request refers to the HTTP method or action specified by the request, such as GET, POST, PUT, DELETE, etc. Each type of the API call request typically corresponds to different operations. The GET retrieves data from the server. Anomalies in this regard, may include unexpected data requests or unusually high volumes of GET requests. The POST submits data to the server. Anomalies in this regard, might involve unusual payload sizes, unexpected data formats, or high submission rates. The PUT updates existing data on the server. Anomalies in this regard, could include unauthorized updates or changes to data that should not be modified. The DELETE removes data from the server. Anomalies in this regard, may involve attempts to delete sensitive or large amounts of data unexpectedly. The patterns in the API responses involve the expected structure, content, and behavior of responses. By monitoring deviations from these patterns, such as unusual formats, unexpected data, abnormal response times, and atypical status codes, the user can detect anomalies that might indicate security threats, performance issues, or other operational problems.
[0065] The API call request is enriched and a session identifier is created based on the transformation logic. The enriched API call request is forwarded to the API provider (412) to get the API response. Further, the response unit (226) generates a negative access response when the plan and access control is determined to be invalid, and sends the negative access response to the UE (102).
[0066] The example for detecting anomalies in the API service is explained in FIG. 4 to FIG. 6.
[0067] FIG. 3 is an example schematic representation of the system (300) of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE (102-1) and the system (108) for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0068] As mentioned earlier, the first UE (102-1) includes one or more primary processors (305) communicably coupled to the one or more processors (202) of the system (108). The one or more primary processors (305) are coupled with a memory (310) which stores instructions which are executed by the one or more primary processors (305). The execution of the stored instructions by the one or more primary processors (305) causes the UE (102-1) to send the API call request to the one or more processers (202).
[0069] As mentioned earlier, the one or more processors (202) is configured to transmit a response content related to the API call request to the UE (102-1). More specifically, the one or more processors (202) of the system (108) is configured to transmit the response content to at least one of the UE (102-1). A kernel (315) is a core component serving as the primary interface between hardware components of the UE (102-1) and the system (108). The kernel (315) is configured to provide the plurality of response contents hosted on the system (108) to access resources available in the communication network (106). The resources include one of a Central Processing Unit (CPU), memory components such as Random Access Memory (RAM) and Read Only Memory (ROM).
[0070] As per the illustrated embodiment, the system (108) includes the one or more processors (202), the memory (204), the input/output interface unit (206), the display (208), and the input device (210). The operations and functions of the one or more processors (202), the memory (204), the input/output interface unit (206), the display (208), and the input device (210) are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure. Further, the processor (202) includes the receiving unit (216), the validating unit (218), the extracting unit (220), the routing unit (224) and the response unit (226). The operations and functions of the receiving unit (216), the validating unit (218), the extracting unit (220), the routing unit (224) and the response unit (226) are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure.
[0071] Referring now to FIG. 4, a flow diagram of an internal call flow (400) is illustrated for detecting anomalies in the API service, in accordance with some embodiments. FIG. 4 shows microservices through which the API call flow passes through. Before calling any API, an authorization may be performed by a consumer (402) to obtain an OAuth token through the CAPIF (404) and an Edge Load balancer (ELB) (406) at step S402-S406. The ELB (406) is an integral part (microservices) of the CAPIF (404). To get the OAuthtoken, the process has to be initiated by the consumer (402). The OAuthtoken has validity along with some expiry time. At step S408-S414, once the OAuthtoken is obtained, some rules are encrypted along with the token. Further, once the consumer (402) has the OAuthtoken, the consumer (402) can call the APIs one by one at step S416. The API call is initiated by the consumer (402) along with the OAuthtoken and the token is validated through the ELB (406). Therefore, each API call request goes through the ELB (406) and the CAPIF (404).
[0072] All call logs are captured along with their respective status, success code, or failure code. The AMS (408) may check activities such as if a plan is associated with the consumer (402). So once everything is found to be OK, the request is transmitted to the API provider (412) at step S418-step S424. At step S426- step S432, the API provider (412) may provide the data which is required by the consumer (402) or whatever an API related operation is done by the API provider (412). Once these operations are performed, a response is returned back to the ELB (406) where the ELB (406) returns the same response to the consumer (402).
[0073] For API call request, each and every call log is maintained. The logs may contains each and every parameter which is used by the CAPIF (404) to create the pattern for early prediction of any error or exceptions or any unwanted conditions. Similarly, a health check (e.g., checking connectivity, interface level details, network fluctuations, etc.,) runs behind the scene as a background process to determine the pattern for early prediction of any error or exceptions or any unwanted conditions.
[0074] Therefore, in every service provider, service API, consumer provisioning, and API call flow, all the data (e.g., call status, status code, messages, time stamp etc.) are captured and stored. This data is used for creating patterns and decision rule. Further, this data is used by the system (300) to improve service call flow. The process runs in the background to detect failure (e.g., microservice connectivity, frequent call failure with a particular API provider instance, etc.,). The failure information is analyzed and used by the system (300) for proactive resolution of problems.
[0075] In a nutshell, the CAPIF (404) validates each API call request and further validates the API key and token for each call. If the token is valid, the CAPIF (404) allows the API call request to move into the system (300). The customer API key (for example) is extracted from the token. Further, API key validation is performed. Based on the API key, a customer plan and access control are checked. If the check is found to be OK, the call reaches the API providers (412) for every API call request. Otherwise, the API call request is rejected. If the consumer API key and plan are OK, then the request enrichment is done and based on available API provider instance and destination instance is picked, using round-robin fashion. Once the API call reaches the API provider (412), the API provider (412) does the functionality and prepare the response accordingly. The API provider (412) also notifies customer application via the CAPIF (404) for every call event if applicable. It should be noted that the call logs are maintained in a pre-defined format. The call logs contain all status codes, operation status, operation messages, time stamp. Counters are also maintained for every service API call.
[0076] For every API service call, each time the request reaches the CAPIF (404), it maintains all call logs. The call logs contain all required data that is required for any failure or upcoming failure pattern. Accordingly, in the CAPIF (404), an artificial intelligence/machine learning (AI/ML) module works in advance to inform stakeholders that the service may be impacted in the future. The health check is performed for all interconnected modules at pre-defined intervals by using the AI/ML module. The health check process continuously monitors all microservices and analyzes a health report. If the threshold (for example, 60%) is breached, it notifies the users using alerts and suggests possible solutions for the problem based on previous knowledge. The threshold is set by the CAPIF (404) or the API provider (412).
[0077] Referring now to FIG. 5, a flowchart of a method of detecting anomalies and generating notifications towards applications routing agents is illustrated, in accordance with some embodiments.
[0078] At step 502 and step 504, when the API service call is initiated, it will validate the token. If the token is invalid, then the negative response is sent to the end user at step 510. At step 506, if the token is found to be valid, the API key is validated, and that is provided to the consumers early on, i.e. before calling the service API. As such, the API is validated first. At step 508 and step 514, if the API key is valid, the request goes to validate the plan and access control and the call log is maintained at step 516. Then, it is checked whether the plan and access control is valid or not at step 518. At step 510, if not, a negative response is generated. At step 520 and step 522, if the plan and access control is valid, the method proceeds to request enrichment or transformation logic. As a result, the request enrichment is performed and session ID is generated. Thereafter, the request reaches the API provider to get the response. The process is stopped at step 512 after getting the negative response.
[0079] FIG. 6 illustrates a system architecture (600) for detecting anomalies and generating notifications towards the applications routing agents, in accordance with some embodiments. In the system architecture (600), various components are descried below:
[0080] The API consumer (602a, 602b) is any application that developers or enterprise want to use this API for their use cases. The CAPIF (404) included in a common API gateway (626) for the API consumer (602a, 602b), API repository for API providers and also deals with security and authorization.
[0081] The Access Management System (AMS) (408) performs plan check, access control policy check, and enrichment of the API call request. The ELB (406) provides functionality to route the API call request to a destination application based on rules like round robin, context-based routing, header-based routing, or TCP based routing. The IAM (410) is responsible for identity and access management related to the API call request.
[0082] A persistent database (620) is a database for all persistent records. The persistent database (620) is scalable, documents oriented, and a schema free database. A distributed cache (622) is an in-memory data structure store, used as a database, cache, and message broker. The distributed cache (622) supports almost all types of data structure to store data.
[0083] A UI API Dashboard (624) is an UI of the CAPIF (404) where rich user interface is available to visualize the data and perform configuration. The API providers (412a-412n) is an application that hosts the APIs and use the CAPIF (404) to expose their APIs. A troubleshooting platform (e.g., ATOM or the like) (610) is responsible for Artificial Intelligence/Machine Learning (AI/ML) decisions.
[0084] A marketplace platform (606) is a platform which is available in public domain. Here, the API consumer (602a, 602b) can create account and login with credentials. After login, the user can explore API repository and purchase the APIs. A subscription engine (604) is a backend application of the marketplace platform (606) where all user related data along with their subscription details are stored. An Element Management System (EMS) (612) is responsible for FCAPS management.
[0085] One cache is a unified data cache/data store that temporarily stores historical data, intermediate results, or patterns related to the API's performance and usage and connected with a Subscriber Identity Module (SIM) SWAP API (614). The common API gateway (626) hosts the SIM SWAP API (614). The SIM SWAP API (614) refers to an interface that allows an application to interact with services related to the process of swapping or updating SIM cards for the UEs (102). The SIM SWAP API (614) is often used to detect and manage anomalies associated with SIM card swaps, which can be a security risk and a sign of potential fraud.
[0086] The system includes the Common API gateway (626) having the CAPIF (404). At the consumer end, the API consumers (e.g. a developer, a playground, an enterprise, etc.) (602a, 602b) can onboard themselves to the CAPIF (404) and the CAPIF (404) may manage the onboarding process. Separate API providers may exist (such as API provider 1, API provider 2, API provider 3). Further, services like SIM SWAP and all other offline services may be made available to the consumer. This section communicates with the common API gateway (626) in order to expose its APIs, and is connected with the Element Management System (EMS) (612) for backup and for restoring all details. The EMS (612) is communicably connected with the CAPIF (404) for backup and restore. The EMS (612) enhances the operational efficiency of the API services by providing comprehensive management capabilities, ensuring that the APIs are performant, secure, and reliable. This complete platform is a marketplace or subscription engine (604) from where the consumer can purchase the API if they want 5G related API, 4G related API, or any other kind of API. Therefore, the consumer may register with the marketplace platform (606), which is publicly available via on the internet. The consumers can register and onboard themselves, and explore the available APIs which are available in the API gateway. Further, the consumer can purchase those APIs and choose the plan, and then use those APIs in their application.
[0087] The troubleshooting platform (610) is a separate system which analyzes all the Call Detail Record (CDR) or all these status code. The CDR provides detailed records of call activities for various purposes such as billing, fraud detection, network management, and customer service. As such, the troubleshooting platform (610) is a tool that provides analysis to the API analyzer, which is a part of the common API gateway (626), and can be used for performing early prediction of any exceptions. The UI API dashboard (624) is an angular based dashboard from where all the available data can be seen from where all APIs can be managed. The common API gateway (626) performs operations (like CAPIF (404), AMS (408), ELB (406), IAM (410)) in combination with the troubleshooting platform (610). The common API gateway (626) is connected with the API analytics unit (608) and the UI API dashboard (624). The CAPIF (404) is connected with a SSA Exposure function (614), a SSA DC MS (616) and a streaming platform (618).
[0088] For example, there may be 3 or 4 API providers, but if one of the API provider is not performing well, then the ELB (406) will not route request to that particular API provider, because their threshold is breached. Further, the ELB (406) informs the CAPIF (404) about the API provider which is not performing well. Thereafter, the stakeholders are informed early on, so as to allow them to perform operations of debugging or some analysis with respect to that API provider.
[0089] FIG. 7 is a flow chart (500) illustrating a method for detecting anomalies in an API service, according to various embodiments of the present system. Explanations concerning various steps of the method are not indicated herein below to avoid repetition. It should not be construed as limiting the scope of the present disclosure, as explanation for the various steps are provided in explanations for FIGs. 1-6 above.
[0090] At step 702, the method includes receiving an API call request from a user equipment. At step 704, the method includes validating the token for the API call request. At step 706, the method includes extracting the API key from the token when the token is determined to be valid.
[0091] At step 708, the method includes routing the API call request to an API service provider by using the API key. At step 710, the method includes generating the negative token response when the token is determined to be invalid. At step 712, the method includes sending the negative token response to the user equipment, where the invalid token indicates existence of anomalies in the API service.
[0092] Below is the technical advancement of the present invention:
[0093] The proposed method and system provide various advantages including proactive detection of the system failure. For example, the threshold can be defined as 80% CPU usage or memory usage. Based on the threshold, the notification may be provided to the respective stakeholders to enable better management of the available application instances. Further, the proposed method provides for protection from resource crunches. For example, for one resource, there can be multiple instances running at the back end. In case one instance is not performing well, then the request can be routed to the available instances automatically. As such, this allows for utilizing the system efficiently. Further, the proposed method provides suggestions and pattern creation for better performance and decision making based on available API call logs. The call logs capture all the information, for example, from status code, error code exceptions, etc. By analysing these call logs, a pattern may be created for detection of service impact related issues at early stages.
[0094] The proposed method further provide for better management of available application instance for efficient scaling and system utilization. The techniques further provide for auto resolution suggestions and notification for the API call failure. For example, when a threshold is breached, a notification is sent to the concerned user. The suggestions can be provided based on previous (historical) issues and corresponding solutions, so as to enable auto resolving of the issues.
[0095] The proposed method further allows obtaining health status of all dependent entities. For example, there are multiple instances of microservices. The techniques allow us to keep track of status or health check of the applications by continuously monitoring the status of the applications. The monitoring may include checking whether all the IP ports are reachable (live) or not, whether stacks are up or not, whether network is stable or not, etc. Such parameters are actively monitored and if any parameter is found to be not performing well, the concerned users are notified.
[0096] The proposed method provides for proactive detection of the system failure, protection from resource crunches, generating suggestions and pattern creation for better performance and decision making, and better management of available application instance for efficient scaling and system utilization.
[0097] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIGS. 1-7) 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.
[0098] Method steps: A person of ordinary skill in the art will readily ascertain that the illustrated steps 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.
[0099] 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
[00100] Environment - 100
[00101] UEs– 102, 102-1-102-n
[00102] Server - 104
[00103] Communication network – 106
[00104] System – 108
[00105] Processor – 202
[00106] Memory – 204
[00107] User Interface – 206
[00108] Display – 208
[00109] Input device – 210
[00110] Database – 214
[00111] Receiving unit– 216
[00112] Validating unit – 218
[00113] Extracting unit – 220
[00114] Routing engine – 224
[00115] Response unit – 226
[00116] System - 300
[00117] Primary processors -305
[00118] Memory– 310
[00119] Kernel– 315
[00120] Example system - 400
[00121] Consumer – 402
[00122] CAPIF – 404
[00123] ELB – 406
[00124] AMS – 408
[00125] IAM - 410
[00126] Service provider – 412, 412a-412n
[00127] API consumer – 602a, 602b
[00128] Subscription engine – 604
[00129] Market place platform – 606
[00130] API analytics unit – 608
[00131] Troubleshooting platform – 610
[00132] EMS – 612
[00133] SSA Exposure function – 614
[00134] SSA DC MS – 616
[00135] Streaming platform – 618
[00136] Persistent database - 620
[00137] Cache database - 622
[00138] UI API dashboard - 624
[00139] Common API Gateway - 626
,CLAIMS:CLAIMS
We Claim:
1. A method of detecting anomalies in an Application Programming Interface (API) service, the method comprising the steps of:
receiving, by one or more processors (202), an API call request from a user equipment (102);
validating, by the one or more processors (202), a token for the API call request;
extracting, by the one or more processors (202), an API key from the token when the token is determined to be valid;
routing, by the one or more processors (202), the API call request to an API service provider (412) by using the API key;
generating by the one or more processors (202), a negative token response when the token is determined to be invalid; and
sending, by the one or more processors (202), the negative token response to the user equipment (102), wherein the invalid token indicates existence of anomalies in the API service.

2. The method as claimed in claim 1, further comprising:
validating, by the one or more processors (202), a plan and access control when the token is valid, wherein in the plan and access control, an API exposing function obtains an access control policy from a CAPIF (404) by sending a GET message to a CAPIF (404) with an API exposing function identifier and an API identification.

3. The method as claimed in claim 2, further comprising:
requesting, by the one or more processors (202), for a transformation logic when the plan and access control is determined to be valid, wherein the transformation logic transforms headers and QueryParam while detecting anomalies in the API service;

generating, by the one or more processors (202), a log file for the API call request when the plan and access control is determined to be valid; and
analysing, by the one or more processors (202), the log file to identify a type of the API call request, one or more error types and anomalies in the API service.

4. The method as claimed in claim 3, wherein the API call request is enriched and a session identifier is created based on the transformation logic, and wherein the enriched API call request is forwarded to the API provider (412) to get the API response.

5. The method as claimed in claim 2, further comprising:
generating, by the one or more processors (202), a negative access response when the plan and access control is determined to be invalid.

6. The method as claimed in claim 1, wherein validating of the token comprises checking a structure, signature, expiration, and intended use of the token, while detecting unusual usage patterns to identify potential anomalies or security threats in the API call request.

7. The method as claimed in claim 1, wherein the token used for the API call request is received from a client application running in the UE (102) and is included in an authorization header of the API call request.

8. A system (108) of detecting anomalies in an Application Programming Interface (API) service application routing, wherein the system (108) comprises:
a receiving unit (216) to receive an API call request from a user equipment (102);
a validating unit (218) to validate a token for the API call request;
an extracting unit (220) to extract an API key from the token, when the token is determined to be valid;
a routing unit (224) to route the API call request to an API provider (412) by using the API key; and
a response unit (226) to generate a negative token response when the token is determined to be invalid, and send the negative token response to the user equipment (102), wherein the invalid token indicates existence of anomalies in the API service application routing.

9. The system (108) as claimed in claim 8, wherein the validating unit (218) is further configured to:
validate a plan and access control when the token is valid, wherein in the plan and access control, an API exposing function obtains an access control policy from a CAPIF (404) by sending a GET message to a CAPIF (404) with an API exposing function identifier and an API identification.

10. The system (108) as claimed in claim 8, wherein the extracting unit (220) is further configured to:
request for a transformation logic when the plan and access control is determined to be valid, wherein the transformation logic transforms headers and QueryParam while detecting anomalies in the API service;
generate a log file for the API call request when the plan and access control is determined to be valid; and
analyse the log file to identify a type of the API call request, one or more error types and anomalies in the API service.

11. The system (108) as claimed in claim 10, wherein the API call request is enriched and a session identifier is created based on the transformation logic, and wherein the enriched API call request is forwarded to an API provider to get the API response.

12. The system (108) as claimed in claim 9, wherein the response unit (226) is further configured to:
generate a negative access response when the plan and access control is determined to be invalid, and send the negative access response to the user equipment (102).

13. The system (108) as claimed in claim 8, wherein validate of the token comprises checking a structure, signature, expiration, and intended use of the token, while detecting unusual usage patterns to identify potential anomalies or security threats in the API call request.

14. The system (108) as claimed in claim 8, wherein the token used for the API call request is received from a client application running in the UE (102) and is included in an authorization header of the API call request.

15. A User Equipment (UE) (102-1), comprising:
one or more primary processors (305) communicatively coupled to one or more processors (202) of a system (108), 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 (102-1) to:
send an API call request to the one or more processers (202);
wherein the one or more processors (202) is configured to perform the steps as claimed in claim 1.