Method and system for controlling flow of one or more requests in a network
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- JIO PLATFORMS LTD
- Filing Date
- 2025-11-18
- Publication Date
- 2026-06-04
Smart Images

Figure IN2025051816_04062026_PF_FP_ABST
Abstract
Description
METHOD AND SYSTEM FOR CONTROLLING FLOW OFONE OR MORE REQUESTS IN A NETWORKRESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD
[0002] The present disclosure relates generally to the field of telecommunication networks. The present disclosure relates to a system and a method for controlling flow of one or more requests in a network.DEFINITIONS
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used indicates otherwise.
[0004] The term “Network Function (NF)” used hereinafter in the specification refers to a component within a fifth generation (5G) network architecture that performs specific roles and services. The design of NFs in 5G allows for greater flexibility, scalability, and efficiency compared to previous generations of mobile networks. Each NF operates independently but may interconnect with other NFs to support a wide range of services. Examples of the network functions (NFs) include a User Plane Function (UPF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Exposure Function (NEF), and a PolicyControl Function (PCF).
[0005] The term “Access and Mobility Management Function (AMF)” used hereinafter in the specification refers to a network function tasked with overseeing essential processes related to user session registration, authentication, and management of user mobility. This function plays a pivotal role in ensuring that subscribers maintain continuous connectivity while transitioning across different network domains.
[0006] The term “Unified Data Management (UDM)” used hereinafter in the specification refers to a network function that manages user-related data such as user credentials, subscription details, and service preferences. The UDM updates the user- related data based on changes in network subscription or network conditions. The AMF interacts with the UDM to retrieve user authentication data and subscription information during connection establishment.
[0007] The term “Short Message Service Function (SMSF)” used hereinafter in the specification, refers to a network function that handles the activation and deactivation of user equipment (UE). The SMSF manages message session establishment, modification, and termination to facilitate reliable communication between the UE and a network.
[0008] The term “Network Repository Function (NRF)” used hereinafter in the specification, refers to a centralized repository for all the NFs in the network. The NRF allows the NFs to discover and communicate with each other. The NFs are registered with the NRF to provide information about their capabilities and available services. The NF registration process enables maintaining an updated repository of all NFs in the network.
[0009] The term "Public Land Mobile Network (PLMN)” used hereinafter in the specification refers to a network that is accessible by the users using the UEs and operated by the network operators. The PLMN provides communication services tousers, such as voice call access, SMS and data services.
[0010] The term “rate limiting” used hereinafter in the specification refers to a process for controlling the flow of one or more requests sent by the NF to the NRF by implementing limits on the number of requests over a specified time interval, which may be a second, minute, or hour.
[0011] The term “configurable range” used hereinafter in the specification refers to a parameter that may be adjusted within certain limits to control the flow of the requests sent to the NRF.
[0012] These definitions are in addition to those expressed in the art.BACKGROUND
[0013] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0014] In modern networks, such as fifth-generation (5G) and sixth-generation (6G) communication networks, a service-based network architecture is enabled. The service-based architecture is a group of interconnected network functions (NFs), where each NF provides a service to the other NF in the network. The network functions may include a short message service function (SMSF), an access and mobility management function (AMF), a unified data management (UDM), a session management function (SMF), a policy control function (PCF) and a network repository function (NRF). The NFs communicate with each other through a communication protocol over the network. The NRF is the primary NF in the service-based architecture that helps to register allthe NFs using a service registration procedure. Additionally, the NFs utilize the NRF as a database to discover the services offered by other NFs through the service discovery and service authentication procedures. The NRF handles multiple requests from various NFs in the network.
[0015] Each NF sends discovery requests for every Public Land Mobile Network (PLMN) ID to which it is associated. When multiple NFs initiate their startup processes concurrently, the NRF may be inundated with requests, quickly exceeding its processing capacity. As the central aggregation point for these requests, the NRF is particularly vulnerable to being overwhelmed. This overload may result in slow response times, service outages, and resource exhaustion, impacting on critical resources such as central processing unit (CPU), memory, and bandwidth. The unregulated influx of discovery requests significantly strains the NRF, potentially degrading its performance and stability. Consequently, the NRF may struggle to maintain its core functions, including managing the service repository, processing incoming service requests, and handling network configurations. Such challenges may lead to delays, timeouts, and failures in service discovery, adversely affecting overall network functionality and user experience.
[0016] In a conventional method, discovery requests in the NRF are handled through manual intervention, which consumes both time and effort. Additionally, manual operations are prone to errors that may further exacerbate the burst situation, leading to a deadlock. Using load balancing, cache memory, and monitoring through alerts to handle the discovery requests is a cumbersome and tedious process that degrades the network performance.
[0017] There is, therefore, a need in the art to provide a method and a system that can mitigate the disadvantages of the prior art.OBJECTIVES OF THE DISCLOSURE
[0018] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0019] An objective of the present disclosure is to provide a system and a method for controlling flow of one or more requests in a network.
[0020] Another objective of the present disclosure is to provide a system and a method for regulating traffic directed at a Network Repository Function (NRF) within a 5G Core Network (5GCN). By regulating traffic in a controlled manner, the system enhances the overall stability and performance of the NRF.
[0021] Another objective of the present disclosure is to provide a system and a method that enhances system stability by minimizing sudden spikes in the data traffic, thereby allowing the NRF to operate smoothly and consistently.
[0022] Another objective of the present disclosure is to provide a system and a method that allows the NRF to handle varying levels of traffic as network demands evolve, thereby enhancing scalability and flexibility of the network.
[0023] Another objective of the present disclosure is to provide a system and a method for enforcing rate limiting to control the flow of the one or more requests sent from a network function (NF) (e.g., short message service function (SMSF)) to the NRF.
[0024] Another objective of the present disclosure is to provide a system and a method for reducing burst traffic on the NRF by controlling the one or more requests from the NF.
[0025] Yet another objective of the present disclosure is to provide a system and a method for monitoring and restricting the one or more requests based on a predefined range and time.
[0026] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.SUMMARY
[0027] In an exemplary embodiment, a method for controlling the flow of one or more requests in a network is described. The method includes receiving, by a processing engine, at least one request from a network function (NF). The method includes accessing, by a rate limiter module of the processing engine, a counter value associated with a network repository function (NRF) from a database. The method further includes transmitting, by the rate limiter module of the processing engine, the at least one received request to the NRF based on the counter value. The method also includes calculating, by the rate limiter module of the processing engine, a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value. The last refreshed time is accessed from the database. The method further includes performing, by the rate limiter module of the processing engine, a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network.
[0028] In an embodiment, the method further includes collecting, by a receiving unit, one or more configurable ranges via a user interface (UI). The one or more configurable ranges comprise a defined time interval value, a rate value, and the counter value. The method further includes initializing, by the processing engine, the one or more configurable ranges in the rate limiter module for controlling the flow of one or more requests in the network.
[0029] In an embodiment, transmitting the at least one received request to the NRF based on the counter value further includes determining whether to transmit each request of the at least one request by iteratively performing: determining, by the ratelimiter module of the processing engine, whether the counter value is a non-zero value; upon determining that the counter value is the non-zero value, transmitting, by the rate limiter module of the processing engine, a first request of the at least one received request to the NRF; decrementing, by the rate limiter module of the processing engine, the counter value by one; and identifying, by the rate limiter module of the processing engine, a second request of the at least one request as the first request, until all requests of the at least one request are transmitted to the NRF or the counter value becomes zero.
[0030] In an embodiment, upon determining that the counter value is zero, the method further includes halting, by the rate limiter module of the processing engine, the transmission of the at least one received request towards the NRF until the counter value is reset.
[0031] In an embodiment, performing the reset operation on the counter value further comprises determining, by the rate limiter module, whether the calculated time difference exceeds the defined time interval value; upon determining that the calculated time difference exceeds the defined time interval value, updating, by the rate limiter module, the counter value as the counter value received from the UI; and updating, by the rate limiter module, the last refreshed time based on a time associated with the reset operation of the counter value.
[0032] In an embodiment, upon determining that the calculated time difference does not exceed the defined time interval value, the rate limiter module uses the same counter value to control the flow of one or more requests in the network.
[0033] In another exemplary embodiment, a system for controlling flow of one or more requests in a network is disclosed. The system includes a memory, and a processing engine coupled to the memory and configured to execute instructions stored in the memory. The processing engine is configured to receive at least one request froma network function (NF). The processing engine further includes a rate limiter module. The rate limiter module is configured to access a counter value associated with a network repository function (NRF) from a database. The rate limiter module is further configured to transmit the at least one received request to the NRF based on the counter value. The rate limiter module is further configured to calculate a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value, wherein the last refreshed time is accessed from the database. The rate limiter module is further configured to perform a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network.
[0034] In yet another exemplary embodiment, the present disclosure provides a computer program product comprising a non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors, cause the one or more processors to execute a method for controlling flow of one or more requests in a network. The method includes receiving, by a processing engine, at least one request from a network function (NF). The method includes accessing, by a rate limiter module of the processing engine, a counter value associated with a network repository function (NRF) from a database. The method further includes transmitting, by the rate limiter module of the processing engine, the at least one received request to the NRF based on the counter value. The method also includes calculating, by the rate limiter module of the processing engine, a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value. The last refreshed time is accessed from the database. The method further includes performing, by the rate limiter module of the processing engine, a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0035] 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 is 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.
[0036] FIG. 1 illustrates an exemplary network architecture of a system for controlling flow of one or more requests in a network, in accordance with an embodiment of the present disclosure.
[0037] FIG. 2 illustrates an exemplary block diagram of the system, in accordance with an embodiment of the present disclosure.
[0038] FIG. 3 illustrates an exemplary system architecture depicting interaction between a Short Message Service Function (SMSF) and a Network Repository Function (NRF) in the network, in accordance with an embodiment of the present disclosure.
[0039] FIG. 4 illustrates an exemplary flow chart for controlling the flow of the one or more requests in the network, in accordance with an embodiment of the present disclosure.
[0040] FIG. 5 illustrates another exemplary flow chart for controlling the flow of the one or more requests in the network, in accordance with the present disclosure.
[0041] FIG. 6 illustrates an exemplary flow chart of a method for controllingthe flow of the one or more requests in the network, in accordance with the present disclosure.
[0042] FIG. 7 illustrates an example computer system in which or with which the embodiments of the present disclosure may be implemented.
[0043] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture102 - User(s) 104 - User Equipments (UEs)106 - Network108 - System200 - Block diagram202 - Receiving unit 204 - Memory206 - Interface(s)208 - Processing engine210 - Rate limiter module212 - Database300 - System Architecture302 - Short Message Service Function (SMSF)304 - Network Repository Function (NRF)400, 500, 600 - Flow Diagram700 - Computer system710 - External Storage Device720 - Bus730 - Main Memory740 - Read Only Memory750 - Mass Storage Device760 - Communication Port770 - ProcessorDETAILED DESCRIPTION
[0044] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any ofthe features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0045] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0046] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0047] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0048] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0049] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0050] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, 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. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that theterms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
[0051] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment, as well as other embodiments of the disclosure, will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0052] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when the second-generation (2G) technology was introduced. The third generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth generation (4G) technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, fifth generation (5G) technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. Further, 6G successor to 5G is expected to provide significantly high data speed with reduced latency, which may offer improvedconnectivity for a vast number of devices concurrently. The capabilities of 6G enable new types of applications and services, such as advanced augmented reality (AR) and virtual reality (VR), holographic communications, and more immersive digital experiences. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (loT) connectivity, and more efficient use of network resources. The sixth generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way of connecting and interacting with technology.
[0053] In a network, there are various network functions (NFs), such as an access and mobility management function (AMF), a short message service function (SMSF), a unified data management (UDM), a session management function (SMF), a policy control function (PCF) and a network repository function (NRF). Each NF handles multiple requests received from other NFs or a user equipment (UE). The NRF is a primary function that maintains the profiles of the NF and their support services in the network. The NRF facilitates a centralized registry to discover and communicate one NF with another NF. The NRF enables network functions such as the AMF, the UDM, and others to register their services and capabilities. This registration allows other NFs to discover available services within the network. By maintaining an updated repository of registered NFs, the NRF facilitates service discovery. When an NF needs to communicate with another NF, it queries the NRF to find the appropriate service endpoints based on its requirements. The NRF supports dynamic updates to service information. The NFs may send updates regarding changes in their status, availability, or capabilities, ensuring that the NRF reflects the current state of the network. The NRF performs a service registration procedure with each NF in the network. Each of the NF in the network, upon initialization or a change in service of the NF, registers its service and capabilities with the NRF. At times, the NRF faces a burst of traffic in the network.The burst traffic in the network refers to a sudden increase in data transmission that exceeds the normal operational capacity of the network. The burst traffic impacts various aspects of the network performance, such as latency, packet loss, and overall throughput. In such cases, the NRF may implement the traditional method of load balancing to address the burst traffic conditions. The load balancing technique distributes the network traffic and computing load to the peer NRFs in the network. However, this process involves increased complexity, dependency on the load balancers, routing complexity, compatibility issues and security issues. Also, if the load balancers fail, the performance of the NT's in the network may be degraded. At times, load balancers in the NRF require timely updates and monitoring to ensure security and performance, which may need manual intervention. The manual intrusion increases the network downtime, affecting the overall network performance.
[0054] Hence, the present disclosure addresses the shortcomings of existing solutions. The present disclosure relates to a method and system for controlling the flow of one or more requests in a network. The method involves implementing a rate limiter module at the SMSF to control the flow of requests sent toward the NRF by enforcing limits on the number of requests over a specified time interval. The present disclosure may be configured to employ a rate-limiting approach to manage the flow of the discovery requests sent from the SMSF to the NRF. The rate-limiting approach enforces specific limits on the number of requests that may be sent over defined time intervals, such as seconds or minutes. The rate-limiting approach operates based on a configured maximum number of discovery requests that can be dispatched to the NRF within a designated time unit and value. By setting these parameters, the system ensures that the NRF is not overwhelmed by simultaneous requests, thereby maintaining optimal performance and stability. The rate-limiting approach may be integrated seamlessly with various traffic flows. Each instance of rate limiting can be customized with a unique set of limits and time intervals, enabling flexible and targeted traffic management. This adaptability ensures that different network functions mayimplement rate limiting according to their specific operational needs, contributing to a more efficient overall network environment.
[0055] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGS. 1- 7.
[0056] FIG. 1 illustrates an exemplary network architecture (100) of a system (108) controlling flow of one or more requests in a network (106), in accordance with an embodiment of the present disclosure.
[0057] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2... 104-N) associated with one or more users (102-1, 102-2... 102 -N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2... 102-N) may collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2... 104-N) may be collectively referred to as the UE (104). Although only three UEs (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.
[0058] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE (104) may include, but is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not limited to, intelligent, multi-sensing, network- connected devices, that may integrate seamlessly with each other and / or with a central server or a cloud- computing system or any other device that is network-connected.
[0059] Additionally, in some embodiments, the UE (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a tablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, 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 capabilities, and the like. In an embodiment, the UE (104) may include, but is not limited to, any electrical, electronic, electromechanical, or 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, wherein the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.
[0060] Referring to FIG. 1, the UE (104) may communicate with the system (108) through the network (communication network) (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one of a fifth generation (5G) network, sixth generation (6G) network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and / or with the system (108). The network (106) mayinclude a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.
[0061] In an embodiment, the network (106) may 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 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, or some combination thereof.
[0062] In an embodiment, the UE (104) is communicatively coupled with the network (106). The system (108) may receive a connection request from the UE (104). The system (108) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request. Once the connection is established, the system (108) may be configured to control the flow of one or more requests towards a network repository function (NRF).
[0063] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may performfunctions described as being performed by one or more other components of the network architecture (100).
[0064] FIG. 2 illustrates an exemplary block diagram (200) of the system (108), in accordance with an embodiment of the present disclosure. The system (108) may be configured to control the flow of one or more requests towards the NRF. In an embodiment, controlling the flow of the one or more requests means regulating the rate at which the requests are transmitted from a network function (NF), towards the NRF, to prevent burst traffic or overload at the NRF.
[0065] In an embodiment, the system (108) may be embedded with the NF. The NF may be a Short Message Service Function (SMSF). In an aspect, the SMSF may be configured to support sending or receiving a short message service (SMS) over a NAS (Non-Access Stratum) using the network (106). The NAS is configured as a bridge between the UE (104) and the network (106). The NAS enables traffic and signaling of messages between the network (106) and the UE (104). The SMSF is configured to check SMS management subscription data and conduct SMS delivery, SMS charging, and relaying messages between the UE (104) and a service center (SC). The SC is responsible for relaying, storing, and forwarding the SMS between a short message entity and UE (104) in the network (106). The short message entity may include an SMS gateway that enables sending, receiving, or storing short messages. For example, the SMS gateway bridges the SMSF and the UE to route SMS messages. The SMS gateway handles different messaging protocols, such as a short message peer-to-peer protocol (SMPP), a Hypertext Transfer Protocol (HTTP), or a Simple Mail Transfer Protocol (SMTP), to ensure compatibility across diverse network systems. The gateway manages message delivery, retries for undelivered messages and provides delivery reports to the sender. The SMS gateway plays a vital role in the SMSF by enhancing reliable message delivery and other services.
[0066] Referring to FIG. 2, the system (108) may include one or moreprocessing engines (208). The processing engines (208) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processing engines (208) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). 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 random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0067] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output (I / O) devices, storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a processing engine (208) and a database (212).
[0068] In an embodiment, the SMSF may communicate with one or more other NFs in the network to receive and send messages. The one or more other NFs may include an access and mobility management function (AMF) and a unified data management (UDM). For example, the SMSF may communicate with the AMF using a reference point. The reference point may be an N20 interface. The N20 interface facilitates the exchange of signaling messages related to SMS service management. The SMSF triggers one or more messages to the AMF to authorize the SMS service in the network. For example, the SMSF may send the user details to the AMF forvalidation. The user details may be validated based on the user identity, such as an international mobile equipment identity (IMEI) or an international mobile subscriber identity (IMSI). The AMF communicates the registration status of the UE in the SMSF. The AMF updates the SMSF about the UE’s new location, allowing effective message routing and delivery.
[0069] In an exemplary aspect, the SMSF may communicate with the UDM to retrieve subscriber information for processing SMS messages, such as the user service preferences and subscription status. For example, when the user attempts to send or receive an SMS, the SMSF may check with the UDM to verify the service status of the user. The SMSF may check for an active status of the subscriber. If the UDM communicates that the user is active in the network with a subscribed plan, then the SMSF may initiate the message delivery.
[0070] In an embodiment, the system (108) may include a receiving unit (202) that may be configured to receive one or more messages from the one or more NFs. The one or more messages may include a data message, a control message, an error message, a configuration message and a status message. For example, the one or more NFs may send the data messages to transfer the data using the network. The one or more NFs may send the control messages to restrict the control flow of data in the network.
[0071] In an embodiment, the processing engine (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine (208). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non- transitory machine-readable storage medium and the hardware for the processing engine (208) may comprise a processing resource (for example, one or moreprocessors), to execute such instructions. In the present examples, the machine- readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine (208). In such examples, the system may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing engine (208) may be implemented by electronic circuitry.
[0072] The processing engine (208) may include a rate limiter module (210). The rate limiter module (210) implements a technique to control the amount of traffic sent or received by each network function (NF) over a number of requests and a time duration. The time duration may be a second, a minute, or an hour. For example, the configured ranges may be 5 requests in one second. The rate limiter module (210) monitors the network resources, prevents misuse or overload from malicious users, and maintains the quality of service of the network (106).
[0073] The rate limiter module (210) may be configured to control the traffic flow of the one or more requests towards the NRF in the network (106). The rate limiter module (210) restricts the number of requests that the NRF may process in the network within a time frame (time duration). The time frame refers to a specific duration or period until the rate limiter module sends the request to the NRF. For example, if the rate limiter module (210) is set with a time frame of 10 requests in 1 minute. The rate limiter module (210) may allow only up to 10 requests in 1 minute. Then, the rate limiter module (210) pauses the flow of requests to the NRF. In an aspect, the rate limiter module (210) enables a technique to restrict the amount of incoming and outgoing traffic to or from the network or the NF. The rate limiter module (210) helps to prevent the abuse of network resources and protects against sudden spikes in traffic that may overload the system (108). For example, the rate limiter module (210) mayprovide a feedback to the users when the limit is reached. The feedback may summarize the request execution process and the status of the requests. The feedback may include a status code, a response header, an error message, a number of retry attempts, and a rate limit.
[0074] In an embodiment, the receiving unit (202) may be configured to collect one or more inputs from a user / network operator using the UE (104) through a user interface. The user interface may be a mobile application or an application programming interface (API) downloaded in the UE (104). The API may be a web application, a mobile application, or a webpage. For example, the mobile application may be configured to communicate with the network using the UE (104). In some examples, the mobile application may be a software application or an application from an application distribution platform. The one or more inputs may include one or more configured ranges. For example, the system (108) may be automatically updated based on the configured ranges by analyzing the network parameters received from the one or more NFs. The user may update the one or more configurable ranges in real time. The updates in the one or more configured ranges get automatically reflected in the rate limiter module (210). The collected one or more inputs may be stored in the memory (204) or the database (212). The one or more configured ranges may include a time unit, a unit value (a defined time interval value), a rate value and a counter value. For example, the configured range may be a threshold for each parameter, such as the time unit, unit value, rate and the counter value. The rate may be set as 5 requests. The time unit may be set as 1 minute. The unit value may be 0. The unit value may represent a time parameter such as seconds. The unit value may be a timer. The counter value may be set to the rate.
[0075] In an aspect, the time unit may be a second, a minute, or an hour. The unit value may indicate a remaining time to reset. The rate may represent the number of request limits. The counter value may be configured to keep track of the number ofrequests to be processed within the time unit. For example, the receiving unit (202) may receive the configured ranges from the user using the UE (104). The time unit may be set as 1 minute. The rate may be set as 5 requests. The counter value may be set as the number of requests limit, which is 5. For example, if the 2 requests are processed in 24 seconds, the remaining time may be 36 seconds. The unit value tracks the remaining time.
[0076] In an embodiment, upon collecting the one or more configurable ranges, the processing engine (208) may be configured to initialize the one or more configured ranges in the rate limiter module (210) to control the flow of one or more requests toward the NRF. The processing engine (208) may trigger one or more requests toward the NRF based on the one or more configured ranges. The configured ranges may be initialized while implementing a method for controlling the flow of one or more requests.
[0077] In order to control the flow of one or more requests, the processing engine (208) may receive at least one request from the NF (e.g., SMSF). The at least one request may be, but is not limited to, a discovery request, a registration request, an update request, a subscription request, and a heartbeat request. For example, the processing engine (208) may trigger a registration request to register each NF with the NRF to register the availability and capability of the NF in the network (106). The discovery request allows the NF to request information about the registered NF in the NRF. The requested information may include the status and capability of the other NF. The update request may allow the NF to send updates to the NRF regarding the latest status and capabilities of the NF. The subscription request may enable the NF in the network to subscribe to other NFs (e.g., AMF, UDM, etc.) in the network using the NRF. The heartbeat request provides the NF to confirm that the other NFs are active and operating using the NRF.
[0078] In an embodiment, upon receiving the at least one request, rate limitermodule (210) of the processing engine (208) may be configured to access the counter value associated with the NRF from the database (212). In an embodiment, the database (212) storing the counter value may reside within the NRF and maintain a table mapping NF to corresponding counter values. In an alternative embodiment, the database (212) may be part of a local datastore of the processing engine (208) that implements the rate limiter module (210). The database (212) may be queried by the rate limiter module (210) using a unique NF identifier to retrieve the counter value and timestamp information.
[0079] In an embodiment, the rate limiter module (210) may be configured to determine, in an iterative manner, whether to transmit each request of the at least one received request to the NRF based on a counter value (also referred to as “a counter”). The counter value represents the number of allowable requests that may be transmitted to the NRF within a defined time interval.
[0080] During operation, the rate limiter module (210) may iteratively perform a determination process for each incoming request. Specifically, the rate limiter module (210) first determines whether the counter value is a non- zero value. To determine whether the counter value is a non-zero value, the rate limiter module (210) may access the current counter value stored in the database (212) or in a local memory cache of the processing engine (208). The rate limiter module (210) compares the retrieved counter value against a predefined threshold, typically zero, to evaluate whether additional requests may be transmitted within the current time interval. If the retrieved counter value is greater than zero (e.g., counter value > 0), the rate limiter module (210) interprets this as a non-zero state, indicating that one or more transmission slots remain available for the ongoing time window.
[0081] Upon determining that the counter value is non-zero, the rate limiter module (210) transmits a first request of the at least one received request to the NRF. Following successful transmission, the counter value is decremented by one to reflect1 that one transmission has been completed within the current time interval. The rate limiter module (210) then identifies a second request of the at least one received request as the first request for the subsequent iteration. The iterative determination continues until either all the received requests have been transmitted to the NRF or the counter value reaches zero.
[0082] To determine that the counter value has reached zero, the rate limiter module (210) may continuously monitor the counter value after each successful transmission. The rate limiter module (210) retrieves the most recent counter value from the database (212) or its internal cache and performs a comparison operation to check whether the counter value is equal to zero (e.g., counter value = 0). When the comparison result is true, the rate limiter module (210) identifies that the current time interval has reached its maximum allowable number of request transmissions.
[0083] Upon determining that the counter value has reached zero, the rate limiter module (210) halts further transmission of requests toward the NRF. Any remaining unprocessed requests may be temporarily queued or paused. The rate limiter module (210) maintains the halted state until the counter value is reset. The reset operation is triggered when the elapsed time since the last refresh equals or exceeds a defined time interval value, such as one minute or one second, as configured via the user interface.
[0084] In an exemplary configuration, the rate limiter module (210) may be initialized with a rate of 5 requests per one-minute interval. Accordingly, the counter value is initially set to 5. Each time a request is transmitted to the NRF, the counter value is decremented by 1. For example, when the first request is transmitted, the counter value is reduced to 4, and the process continues until the counter reaches 0. When the counter value reaches 0, the rate limiter module (210) halts further request transmission and resumes only after the counter is reset based on the defined time interval. The iterative determination and halting process ensures that all requests aretransmitted to the NRF in a controlled and time-regulated manner, thereby preventing burst traffic and maintaining a balanced load on the NRF.
[0085] In an embodiment, the rate limiter module (210) may be further configured to calculate a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value. The current timestamp may include a current time and a date of the system (108). The last refreshed time may be a timestamp of the last access to the cache to retrieve the configured value. The last refreshed time may be accessed from the database (212).
[0086] In an exemplary aspect, the rate limiter module (210) calculates the. elapsed time by subtracting the last refreshed time from the current time. For example, if the current time is 11:44 AM and the last refreshed time is 11:40 AM, the elapsed time is 4 minutes. The rate limiter module (210) then compares this elapsed time against a configured time unit or defined time interval value. If the elapsed time exceeds the configured time unit, for example, if the defined interval is 3.5 minutes, the rate limiter module (210) determines that a new time window has begun and triggers the reset operation.
[0087] In an embodiment, the rate limiter module (210) may be further configured to perform a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network (106). The rate limiter module (210) may continuously monitor the time difference between a current timestamp and a last refreshed time stored in the database (212). This time difference represents the elapsed time since the last counter reset. During the reset operation, the rate limiter module (210) refreshes or reinstates the counter value to the preconfigured rate limit (for example, 50 requests) received via the UI. This ensures that the next set of requests may be transmitted within the newly started time interval, maintaining regulated flow and preventing uncontrolled request bursts toward the NRF.
[0088] To perform the reset operation on the counter value, the rate limiter module (210) may determine whether the calculated time difference exceeds the defined time interval value by comparing the calculated time difference against a defined time interval value, which is a configurable parameter received from the UI. If the rate limiter module (210) determines that the calculated time difference exceeds the defined time interval value, the rate limiter module (210) updates the counter value using the counter value received from the UI, effectively replenishing the number of allowable requests within the next interval. For example, if the defined rate is 5 requests per minute and the defined time interval value is 1 minute, then when the elapsed time exceeds 1 minute, the rate limiter module (210) resets the counter value to 5. This reset enables the rate limiter module (210) to transmit new requests during the next time interval.
[0089] Upon performing the reset operation, the rate limiter module (210) may also update the last refreshed time in the database (212) to reflect the time of the most recent reset operation. For example, if the last refreshed time is stored as 11:40 AM, and the rate limiter module (210) determines that the time difference exceeded the defined time interval value at 11:50 AM, the last refreshed time is updated to 11:50 AM.
[0090] Conversely, if the calculated time difference does not exceed the defined time interval value, the rate limiter module (210) does not perform the reset operation. Instead, the rate limiter module (210) continues to use the existing counter value to control the flow of requests in the network (106). For example, if only 30 seconds have elapsed since the last reset and the defined interval is one minute, the rate limiter module (210) maintains the current counter value (for example, 2 remaining requests) and continues operation without modification.
[0091] In an embodiment, the database (212) includes data (e.g., counter value corresponding to one or more NFs, a last refreshed time, a defined time interval value,a rate value, and logs related to the execution of reset operations or flow control decisions, user information, provisioning details, error logs, network configuration parameters, historical user data, etc.) that may be either stored or generated as a result of functionalities implemented by any of the components of a processor or the processing engine (208). In an embodiment, the rate limiter module (210) may provide a framework wherein a certain configured parameter, such as the rate, the time unit, and the unit value, is assigned for a particular flow of requests in the network. The rate limiter module (210) may be configured to monitor the flow / traffic of the requests with the help of time unit and unit value fields. Further, the rate limiter module (210) may be configured to perform internal checks to determine whether to allow the flow / traffic or restrict it until the next reset is done for the configured parameters.
[0092] In an embodiment, the memory may use a last refreshed parameter that may store the timestamp of the last cache access. This is crucial for determining when the next reset of available hits should occur.
[0093] In an embodiment, the rate limiter module (210) may use a time unit parameter and a unit value parameter that the rate limiter module may use to set a time unit (e.g., seconds, minutes). The unit value parameter indicates how many milliseconds should pass before the rate limit resets.
[0094] In an embodiment, the rate limiter module (210) may use a remaining hits parameter to track how many requests can still be made within the current time interval. At startup, the remaining hits parameter is set to the specified rate (for example, 50 requests). As the NFs initiate requests, the rate limiter module operates by decrementing the remaining hits parameter with each request processed. This internal tracking mechanism ensures the system maintains an accurate count of the requests available within the current time interval. When the remaining hits parameter reaches zero, the maximum allowable requests for that interval have been exhausted. Consequently, the rate limiter module denies any subsequent requests until the ratelimit is reset, which occurs at the end of the defined time unit. This reset operation replenishes the remaining hits parameter back to the original specified rate, thereby allowing for the acceptance of new requests in the subsequent time interval.
[0095] In an embodiment, a cacheHit operation is an internal functionality invoked by the rate limiter module (210) during the execution of each request.
[0096] In an embodiment, the present disclosure is configured to:• calculate the time that has passed since the last refresh by subtracting the last refreshed timestamp from the current timestamp. This helps determine whether it’s time to reset the remaining hits.• captures the current system time with each flow (request). This timestamp is essential for calculating the elapsed time since the last refresh.• calculate the time (elapsed time) that has passed since the last refresh by subtracting the last refreshed timestamp from the current timestamp. This helps determine whether it’s time to reset the remaining hits.• If the elapsed time exceeds the defined interval (determined by the time unit and the unit Value), reset the remaining Hits to the initial given Rate (counter value) and update the last refreshed timestamp. This ensures that requests can resume after the specified time period.• update the last cacheHit to reflect the time of the most recent successful cache access, maintaining a log of when the cache was last used.• decrement the count of remaining hits each time it is called. This signifies that a cache access has occurred, reducing the available quota.• Finally, the cacheHit operation makes a decision that indicates whether there are remaining hits available. If the remaining hits are zero or below, it indicates that no more flow can be executed for that timeduration, thus denying further access and eventually controlling the traffic rate.• Whenever the discovery request flow is executed at startup for a configured set of PLMN IDs, it has to pass through the Rate Limiter module. All the above checks and processing ensure whether to grant that request and process it ahead towards NRF or wait for the next reset of rate limit within the configured time unit.
[0097] In an operative aspect, the SMSF may need to send the discovery requests to the NRF for the configured set of Public Land Mobile Network (PLMN) IDs, with a rate limit set to allow a maximum of 10 requests every minute. The method begins by calculating the time elapsed since the last refresh. For instance, if the last request was sent at 10:00:00 AM, the system captures the current timestamp when a new request flow is initiated. If the current time is 10:01 : 30 AM, the elapsed time is 90 seconds. This step is crucial for determining whether it is time to reset the count of remaining hits.
[0098] In an operative aspect, the SMSF checks whether the elapsed time exceeds the defined interval of 60 seconds (one minute). In this example, as 90 seconds have passed, it indicates that it is time to reset the rate limit. The method then resets the count of remaining hits to the initial value of 10 and updates the last refreshed timestamp to the current time of 10:01:30 AM. The reset enables the SMSF to resend requests after the specified period.
[0099] When the SMSF sends the discovery request, the system may update last CacheHit to reflect the time of this successful request, indicating the cache was last accessed at 10:01:30 AM. The SMSF decrements the remaining Hits count each time the request is processed. For example, if the SMSF sends the request at this timestamp, the count goes from 10 to 9. The decrement signifies that cache access has occurred, and the available quota has been reduced.
[0100] After processing each request, the system (108) performs a decisionmaking check on the remaining Hits. Further requests are denied if the count is zero or below, effectively controlling the traffic rate sent to the NRF. If the remaining hits are still above zero, the request is granted and processed by the NRF. Whenever the discovery request flow is executed at startup for the configured PLMN IDs, it may pass through the rate limiter module (210), which ensures compliance with the defined rate limits.
[0101] In summary, the rate-limiting mechanism effectively manages the flow of discovery requests, preventing the NRF from becoming overwhelmed while ensuring that requests are processed in a controlled manner. By utilizing timestamps, managing hit counts, and enforcing resets based on defined intervals, the system (108) maintains optimal performance and stability within the 5G core network.
[0102] Although FIG. 2 shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other system components (108).
[0103] FIG. 3 illustrates an exemplary system architecture (300) depicting interaction between the SMSF and the NRF in the network, in accordance with an embodiment of the present disclosure.FIG. 3 is explained in conjunction with FIGS. 1 - 2.
[0104] In an embodiment, the system architecture (300) may include the SMSF (302) and the NRF (304). In an aspect, the SMSF (302) may be configured to handle short message service traffic. The SMSF (302) ensures that the SMS is delivered seamlessly across the network (106). The SMSF (302) facilitates communicationbetween different network technologies, for example, between the 4G and the 5G networks. The SMSF (302) handles SMS messages in the network (106), including routing, storage, and forwarding messages.
[0105] In an embodiment, the NRF (304) may be configured to enable efficient service discovery, management and load balancing of the NFs in the network (106). The NRF (304) maintains a real-time updated repository of available NFs and their capabilities. The NRF (304) provides information about the availability and load of various network functions, such as the SMSF (302), a session management function, and an access and mobility management function (AMF). The NRF communicates with the SMSF (302) using a Nnrf interface. The Nnrf interface is a service-based interface for the NRF (304). In addition, the NF provides a service for the other NF through the Nnrf interface, and the other NF may obtain, through the Nnrf interface, the service provided by the NF.
[0106] In an aspect, the Nnrf interface with a service discovery function (for example, SMSF) may be configured to receive a discovery request from the NF, such as a requesting NF, discover one or more NF instances based on at least one service, application, or subscription requirement obtained according to the discovery request, and respond to the discovery request with the one or more discovered NF instances, providing information regarding those instances. In this context, the service discovery function may include an NRF service (producer) for receiving and replying to discovery requests associated with an NF service (consumer) of the requesting NF instance. Additionally, or alternatively, the service discovery function may include an NRF service (producer) for receiving subscription requests and providing notifications or publications associated with an NF service (consumer) of the requesting NF instance.
[0107] In an aspect, the NRF (304) operates within the context of a list of PLMN. The NRF (304) maintains the list of PLMNs. The list of PLMNs may includeone or more PLMN identifiers (IDs). The PLMN ID may be a unique identifier for the network (106). For example, the PLMN ID includes a Mobile Country Code (MCC), and a Mobile Network Code (MNC). The MCC represents the country where the mobile network operates, while the MNC identifies the specific network within that country. These identifiers enable the NRF to effectively distinguish between various networks that the UE (104) may connect to, especially during network roaming scenarios. The PLMN IDs allow the NRF to (304) to distinguish between the networks the UE (104) is connected to during network roaming. The NRF (304) supports registering, updating, and deregistering the NF within the PLMNS.
[0108] When the UE (104) roams between different PLMNs, the NRF capability to manage PLMN IDs becomes crucial. The NRF ensures that the appropriate network functions are registered and discovered based on the active PLMN. This functionality allows seamless service continuity as the UE moves across different network boundaries. Moreover, the NRF supports essential operations such as registering, updating, and deregistering network functions within the context of these PLMNs. When an NF registers with the NRF, it provides its capabilities and service information linked to a specific PLMN ID, allowing the NRF to maintain an up-to-date repository of available services. If the status of an NF changes, such as service updates or a transition to a different PLMN, the NRF can update its records accordingly. Similarly, when an NF is no longer operational or associated with a specific PLMN, the NRF can deregister it, ensuring that the repository remains accurate and reflects the current network landscape.
[0109] For example, the UE (104) travels from Country A to Country B. In Country A, the UE is connected to a network identified by a specific PLMN ID (e.g., MCC: 123, MNC: 456). Upon entering Country B, the UE connects to a different network with another PLMN ID (e.g., MCC: 789, MNC: 012). For instance, the network in Country A is represented by the PLMN ID (123, 456), while the network inCountry B is represented by (789, 012). These identifiers enable the network to manage user connections effectively, especially in roaming scenarios. As the UE transitions between networks, various NFs come into play. For example, the AMF manages user access and mobility, while the SMF handles session establishment and management. When the UE registers with the network in Country A, the AMF registers with the NRF, providing information about its services linked to PLMN ID (123, 456). Similarly, when the UE roams into Country B, the new AMF and SMF register with the NRF using their respective PLMN ID (789, 012).
[0110] The NRF maintains the list of available services and their PLMN associations. When the UE connects to the network in Country B, it requests services such as data or voice. The SMSF in Country B queries the NRF via the Nnrf interface to discover the available services registered under the new PLMN ID. The NRF responds with a list of services and corresponding NFs that are active in Country B, enabling the SMSF to establish necessary connections for the UE. Throughout this process, the NRF continually updates its repository to reflect the current status of registered NFs across both PLMNs. This dynamic management ensures that the UE can seamlessly transition between services as it roams, thereby maintaining a high- quality user experience.
[0111] In an embodiment, the NRF (304) may be configured to provide service operation to the NFs in the network (106). The service operation is used to: register the NF in the NRF (304) by providing the NF profile of the requesting NF to the NRF (304), and the NRF (304) marks the requesting NF as available to be discovered by other NFs; register services associated with an existing NF in the network (106); and register NRF information in another NRF, which is used for forwarding or redirecting service discovery requests.
[0112] FIG. 4 illustrates an exemplary flow chart (400) for controlling the flow of one or more requests in the network (106), in accordance with an embodiment of thepresent disclosure. FIG. 4 is explained in conjunction with FIGS. 1 - 3.
[0113] At step 402, the rate limiter module (210) may initiate to manage one or more requests sent to the NRF (304) from the SMSF (302). The rate limiter module (210) may be coupled with the SMSF (302). In an aspect, the rate limiter module (210) regulates the number of requests sent to the NRF (304) from the SMSF (302). For example, the request may be a discovery request. The discovery request may be initiated with the NRF (304) to locate the other NF, such as the AMF or the UDM, that provides a specific service or function required for an operation. For example, the operation may be a user authentication operation by the SMSF (302). The SMSF (302) may send and receive messages across the network (106). The SMSF (302) may receive the message from the UE (104) using the network (106). The SMSF (302) may authenticate the UE (104) based on the user identity, such as an international mobility equipment identity (IMEI). The user identity authentication is performed by the SMSF (302) with the help of the AMF. In such scenarios, the SMSF (302) may initiate a discovery request towards the NRF (306).
[0114] At step 404, the rate limiter module (210) may determine whether the request comes within the configured range from the SMSF (302). The rate limiter module (210) may receive the one or more requests from the SMSF (302) and send the requests to the NRF (304) based on the configurable range. For example, the configurable range may be set during the initialization of the rate limiter module of the system (108). The configurable range may be set as 5 requests per second. The counter value may be set to 5. The counter value may be decremented by 1 for each request being sent from the NRF (304). For example, if 2 requests are initiated from the SMSF (302) to the NRF (304), the rate limiter module checks the number of requests initiated. The rate limiter module sends the 2 requests to the NRF (304).
[0115] At step 406, the rate limiter module (210) may check the counter value for sending the request to the NRF (304). For example, if 6 requests are initiated fromthe SMSF (302), the rate limiter module may send the 5 requests in one second. The rate limiter module pauses the one request and waits for a counter reset. The rate limiter module (210) performs the check for the counter reset. The counter may be reset to the number of requests 5 again. Again, the rate limiter module may resume sending the paused request.
[0116] At step 408, the rate limiter module (210) may send the request to the NRF (304). For example, the rate limiter module may send the request to NRF (304), if the request is within the range of the configurable range. For example, if 5 requests are sent from SMSF (302). The rate limiter module may send all the 5 requests in one second to the NRF (304).
[0117] FIG. 5 illustrates another exemplary flow chart for controlling the flow of the one or more requests in the network (106) by interacting between the SMSF (302) and the NRF (304), in accordance with the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1 - 4.
[0118] At step 502, the SMSF (302) may send the one or more requests to the NRF (304). The one or more requests comprise a registration request, a de-registration request, a discovery request, and a heartbeat request. For example, the SMSF (302) may initiate one or more requests received from the other NF in the network (106). The SMSF (302) may initiate the heartbeat request to perform a periodic check on the other NF in the network (106). The SMSF (302) may check for the availability of the AMF, for which the SMSF (302) may initiate the heartbeat request to the NRF (304).
[0119] At step 504, the SMSF (302) may send / receive the one or more requests based on a list of PLMNs to discover the NFs in the network (106). For example, the list of PLMNs may include an operator name and a PLMN ID. Each PLMN is identified using the PLMN ID. At step 506, the SMSF (302) may determine whether the incoming request is less than the configurable range using the rate limiter module. The rate limitermodule checks whether the incoming request is within the configurable range. For example, the configurable range may be 5 requests per second. The incoming request may be 4. These 4 requests are sent to the NRF (304) as it is within the range of the configurable value.
[0120] At step 508, if the incoming request exceeds the configurable range, the rate limiter module pauses or halts the request that is to be sent to the NRF (304). The rate limit module remains in a current PLMN until the configurable range is reset. For example, the incoming request is received from the first PLMN. The incoming request received is 5 requests. The configurable range is 3 requests in 1 second. The counter value may be set to 3. The rate limiter module may send 3 out of the 5 incoming requests in 1 second and wait for the counter value to reset. Meanwhile, the incoming requests are received from the second PLMN. The rate limiter module (210) may stay with the first PLMN to complete the operation and then move to the second PLMN. Conversely, at step 510, if the incoming request is within the configurable range, the requests are sent to the NRF (304). For example, the incoming requests received are 3. The rate limiter module (210) may send the request to the NRF (304) as the number of incoming requests received is within the configurable range.
[0121] When the NF needs to discover available services, the NF initiates a discovery request. The NRF iterates through its list of PLMNs, checking each PLMN to identify which network functions are registered and available for the specific services requested. During the iteration, the NRF compares the service requirements provided in the discovery request against the services registered under each PLMN. This matching process ensures that only relevant network functions that meet the specified criteria are considered. Once the iteration is complete, the NRF compiles a list of discovered network functions that are available under the relevant PLMNs. This list includes information about the capabilities of each function, allowing the requesting NF to make informed decisions. Finally, the NRF responds to the discoveryrequest with the compiled information, detailing the available network functions along with their associated PLMN IDs. This response enables the requesting NF to establish the necessary connections or services.
[0122] For example, if an SMSF in a UE wants to establish a data session, it sends a discovery request to the NRF. The NRF then iterates through its list of PLMNs, say PLMN A (MCC: 123, MNC: 456) and PLMN B (MCC: 789, MNC: 012). It checks which NFs, such as the AMF and UDM, are registered and capable of providing data session services under each PLMN.
[0123] After the iteration, if the NRF finds that both PLMN A and PLMN B have available instances of the required NFs, it compiles this information and sends it back to the SMSF. This allows the SMSF to choose the appropriate NF based on its operational needs and the current network conditions.
[0124] In an operative aspect, for the requester NF or SMSF to obtain information about the NF and / or NF service(s) registered or configured in a specific Public Land Mobile Network (PLMN) or slice, the requester may initiate a discovery procedure with the NRF. This is achieved by specifying the type of the NF and, optionally, a list of specific services it attempts to discover. The requester may also include service parameters, such as slicing-related information.
[0125] Additionally, the requester NF may provide NF Set information to facilitate the reselection of NF instances within that set and specify any required supported features of the NF. For NFs that access subscription data, like the Home Subscriber Server (HSS) or Unified Data Management (UDM), the NRF may need to resolve the NF Group ID associated with a subscriber identifier. If the NRF does not have the configuration mapping stored locally, it may retrieve the NF Group ID from the User Data Repository (UDR) using a Nudr GroupIDmap Query service operation.
[0126] In cases of indirect communication, the SMSF may route the request tothe intended target. If the requester NF is configured to delegate the discovery process, it may omit the direct discovery procedure and allow the SMSF to handle it on its behalf instead. The requester NF may then add any necessary parameters to assist the SMSF in performing the discovery and selection.
[0127] In an embodiment, during such discovery operations, a large volume of requests may be generated concurrently by multiple NFs, including the SMSF, toward the NRF. To prevent overload or burst traffic conditions, the present disclosure provides a rate-limiting mechanism implemented within the SMSF. The rate limiter module dynamically monitors and regulates the number of discovery or registration requests transmitted to the NRF based on configurable parameters such as rate, time interval, and counter value. This ensures controlled and stable request flow, thereby maintaining NRF performance and overall network stability.
[0128] FIG. 6 illustrates an exemplary flow chart of a method (600) for controlling the flow of the one or more requests in the network (106), in accordance with the present disclosure. The method (600) may be implemented by the processing engine (208), which may include the rate limiter module (210), and other components described with reference to FIGS. 1-5. The method (600) of FIG. 6 is explained in conjunction with FIGS. 1 - 5.
[0129] At step 602, the processing engine (208) receives at least one request from the NF. The NF may include, for example, the SMF, the SMSF (302), or any other core network function configured to initiate discovery or registration requests toward the NRF (304).
[0130] At step 604, the rate limiter module (210) of the processing engine (208) accesses a counter value associated with the NRF (304) from a database (212). The counter value represents a number of requests that may be transmitted to the NRF (304) within a defined time interval. In an embodiment, the database (212) may be locatedeither at the NRF (304) or maintained locally by the processing engine (208) as part of its memory, and stores the counter value along with a last refreshed time for tracking time-based reset operations.
[0131] At step 606, the rate limiter module (210) of the processing engine (208) transmits the at least one received request to the NRF (304) based on the counter value. In an embodiment, the transmitting process is performed iteratively for each request, where the rate limiter module (210) determines whether to transmit each request of the at least one received request by performing the following operations, determining, by the rate limiter module (210) of the processing engine (208), whether the counter value is a non- zero value, upon determining that the counter value is the non-zero value, transmitting, by the rate limiter module (210) of the processing engine (208), a first request of the at least one received request to the NRF, decrementing, by rate limiter module (210) of the processing engine (208), the counter value by one, and identifying, by the rate limiter module of the processing engine, a second request of the at least one request as the first request, until all requests of the at least one request are transmitted to the NRF or the counter value becomes zero.
[0132] At step 608, the rate limiter module (210) of the processing engine (208) calculates a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value. The last refreshed time is accessed from the database (212). The calculated time difference indicates how much time has elapsed since the last counter reset, enabling the rate limiter module (210) to decide whether a new time window has started.
[0133] At step 610, the rate limiter module (210) of the processing engine (208) performs a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network (106). Performing the reset operation on the counter value further includes determining, by the rate limiter module (210), whether the calculated time difference exceeds the defined time interval value,upon determining that the calculated time difference exceeds the defined time interval value, updating, by the rate limiter module (210), the counter value as the counter value received from the user interface (UI), and updating, by the rate limiter module (210), the last refreshed time based on a time associated with the reset operation of the counter value.
[0134] In one example, if the configured time interval value is 1 minute and the rate value is 5, the counter value may be reset to 5 when the elapsed time exceeds one minute, thereby allowing the next set of 5 requests to be transmitted within the subsequent interval.
[0135] If the calculated time difference does not exceed the defined time interval value, the rate limiter module (210) continues to use the same counter value to control the flow of one or more requests in the network (106). This ensures that requests are transmitted only within the configured limits of the current time interval and that premature resets are avoided.
[0136] In one embodiment, prior to the transmission process, the method (600) may further include collecting, by the receiving unit (202), one or more configurable ranges via the UI. The one or more configurable ranges may include a defined time interval value, a rate value, and the counter value. The processing engine (208) may initialize these configurable ranges within the rate limiter module (210) for controlling the flow of one or more requests in the network (106). These configurable ranges enable network administrators to dynamically adjust flow control behavior according to operational requirements.
[0137] Further, upon determining that the counter value has reached zero, the rate limiter module (210) halts the transmission of the at least one received request toward the NRF (304) until the counter value is reset. During this period, additional requests may be queued or held within the processing engine to prevent overload onthe NRF (304). Once the counter value is reset based on the time difference exceeding the defined time interval value, the rate limiter module (210) resumes transmission of the queued requests in accordance with the updated counter limit.
[0138] Accordingly, the method (600) ensures that the flow of requests in the network (106) is dynamically controlled, based on configurable time and rate parameters, thereby preventing burst traffic toward the NRF (304) and ensuring optimal performance and stability of the 5G core network.
[0139] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present disclosure may be implemented.
[0140] As shown in FIG. 7, the computer system (700) may include an external storage device (710), a bus (720), a main memory (730), a read-only memory (740), a mass storage device (750), a communication port (760), and a processor (770). A person skilled in the art will appreciate that the computer system (700) may include more than one processor (770) and communication ports (760). The processor (770) may include various modules associated with embodiments of the present disclosure.
[0141] In an embodiment, the communication port (760) may be any of an RS- 232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication port (760) may be chosen depending on the network (106), such as a Local Area Network (LAN), a Wide Area Network (WAN), or any network to which the computer system (700) connects.
[0142] In an embodiment, the memory (730) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (740) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor (770).
[0143] In an embodiment, the mass storage device (750) may be any current or future mass storage solution, which may be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).
[0144] In an embodiment, the bus (720) communicatively couples the processor(s) (770) with the other memory, storage, and communication blocks. The bus (720) may be, e.g., a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such as a front side bus (FSB), which connects the processor (770) to the computer system (700).
[0145] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and cursor control device, may also be coupled to the bus (720) to support direct operator interaction with the computer system (700). Other operator and administrative interfaces may be provided through network connections connected through the communication port (760). The components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (700) limit the scope of the present disclosure.
[0146] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to makeand use the invention when combined with information and knowledge available to the person having ordinary skill in the art.
[0147] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
[0148] In an exemplary embodiment, a system for controlling flow of one or more requests in a network is disclosed. The system includes a memory, and a processing engine coupled to the memory and configured to execute instructions stored in the memory. The processing engine is configured to receive at least one request from a network function (NF). The processing engine further includes a rate limiter module. The rate limiter module is configured to access a counter value associated with a network repository function (NRF) from a database. The rate limiter module is further configured to transmit the at least one received request to the NRF based on the counter value. The rate limiter module is further configured to calculate a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value, wherein the last refreshed time is accessed from the database. The rate limiter module is further configured to perform a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network.
[0149] In another exemplary embodiment, the present disclosure provides a computer program product comprising a non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors, cause the one or more processors to execute a method for controlling flow of one or more requests in a network. The method includes receiving, by a processing engine, at least one request from a network function (NF). The method includes accessing, by a rate limiter module of the processing engine, a counter value associated with a network repository function (NRF) from a database. The method further includes transmitting, by the rate limiter module of the processing engine, the at least one received request to the NRF based on the counter value. The method also includes calculating, by the rate limiter module of the processing engine, a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value. The last refreshed time is accessed from the database. The method further includes performing, by the rate limiter module of the processing engine, a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network.
[0150] The present disclosure offers significant technical advancements in managing and controlling the flow of discovery or registration requests towards the NRF within a 5G core network. These advancements overcome the limitations of existing solutions that allow unregulated, burst traffic toward the NRF, especially during network startup or recovery phases, by introducing a rate limiter framework that dynamically governs the transmission of requests from network functions (NFs) such as the SMF or SMSF. Unlike conventional systems, which handle request bursts in a reactive manner or rely on static throttling rules, the present disclosure provides a proactive and configurable rate-limiting mechanism that operates on a per-time- interval basis using a counter-based control logic. The disclosed system continuously monitors a counter value, a defined time interval, and a rate value configured through a user interface (UI) to determine whether new requests may be transmitted to the NRF.When the counter value reaches zero, the system automatically halts further transmissions and resumes only upon the occurrence of a reset event determined by comparing the elapsed time with the configured interval. This intelligent and modular control ensures that traffic flow toward the NRF remains stable, predictable, and selfregulated, even during high-load conditions or simultaneous NF startups.
[0151] Furthermore, the present disclosure introduces a time-based reset operation that synchronizes the counter reset with real-time system events, thereby maintaining consistent transmission rates without external intervention. The configurable ULbased approach allows network operators to dynamically adjust rate limits and intervals without requiring system restarts or manual configuration changes. This flexibility enhances network responsiveness and adaptability under varying operational conditions. By implementing this rate-limiting technique, the present disclosure ensures optimal utilization of NRF processing resources, minimizes signaling overload, and maintains service continuity across network functions. Additionally, it improves the overall reliability and performance of the 5G core network by ensuring that discovery procedures are executed in a controlled manner, reducing the risk of request drops, timeouts, and synchronization delays. Overall, the present disclosure enhances network stability, scalability, and operational efficiency while enabling a seamless and standards-adaptable mechanism for traffic regulation across 5G network functions.
[0152] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.ADVANTAGES OF THE PRESENT DISCLOSURE
[0153] The present disclosure, as described above, offers several technical advantages, including, but not limited to:
[0154] The present disclosure prevents overload on a Network Repository Function (NRF) by limiting the number of requests triggered toward the NRF using a Session Management Function (SMSF).
[0155] The present disclosure improves the quality of service in the network by controlling the request traffic. This ensures that the NRF maintains optimal performance levels even during peak load conditions.
[0156] The present disclosure reduces the risk of downtime by effectively managing incoming requests toward the NRF from various network functions (NFs). This minimizes the likelihood of network crashes, processing delays, or service interruptions.
[0157] The present disclosure enables dynamic adjustment of rate limits based on changing traffic patterns in the network, allowing the system to adapt in real time to varying network loads and operational conditions.
[0158] The present disclosure avoids excessive or unnecessary request transmissions by users or network functions that may otherwise consume valuable network resources and adversely impact overall network performance.
[0159] The present disclosure regulates network traffic to prevent burst traffic conditions in the network, thereby maintaining stable communication and consistent throughput across all network elements.
[0160] The present disclosure stabilizes request traffic toward the NRF, contributing to enhanced performance, reliability, and scalability of the overall network.
Claims
We claim:
1. A method (600) for controlling flow of one or more requests in a network (106), the method (600) comprising: receiving (602), by a processing engine (208), at least one request from a network function (NF); accessing (604), by a rate limiter module (210) of the processing engine (208), a counter value associated with a network repository function (NRF) (304) from a database (212); transmitting (606), by the rate limiter module (210) of the processing engine (208), the at least one received request to the NRF (304) based on the counter value; calculating (608), by the rate limiter module (210) of the processing engine (208), a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value, wherein the last refreshed time is accessed from the database (212); and performing (610), by the rate limiter module (210) of the processing engine (208), a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network (106).
2. The method (600) as claimed in claim 1, further comprising: collecting, by a receiving unit (202), one or more configurable ranges via a user interface (UI), wherein the one or more configurable ranges comprise a defined time interval value, a rate value, and the counter value; and initializing, by the processing engine (208), the one or more configurable ranges in the rate limiter module (210) for controlling the flow of one or more requests in the network (106).
3. The method (600) as claimed in claim 1, wherein transmitting the at least one received request to the NRF (304) based on the counter value further comprises: determining whether to transmit each request of the at least one request by iteratively performing: determining, by the rate limiter module (210) of the processing engine (208), whether the counter value is a non-zero value; upon determining that the counter value is the non-zero value, transmitting, by the rate limiter module (210) of the processing engine (208), a first request of the at least one received request to the NRF (304); decrementing, by the rate limiter module (210) of the processing engine (208), the counter value by one; and identifying, by the rate limiter module (210) of the processing engine (208), a second request of the at least one request as the first request, until all requests of the at least one request are transmitted to NRF (304) or the counter value becomes zero.
4. The method (600) as claimed in claim 3, further comprises: upon determining that the counter value is zero, halting, by the rate limiter module (210) of the processing engine (208), the transmission of the at least one received request towards the NRF (304) until the counter value is reset.
5. The method (600) as claimed in claim 3, wherein performing the reset operation on the counter value further comprises: determining, by the rate limiter module, whether the calculated time difference exceeds the defined time interval value; upon determining that the calculated time difference exceeds the defined time interval value, updating, by the rate limiter module, the counter value as the counter value received from the UI ; and updating, by the rate limiter module, the last refreshed time based on a time associated with the reset operation of the counter value.
6. The method (600) as claimed in claim 3, further comprising: upon determining that the calculated time difference does not exceeds the defined time interval value, using, by the rate limiter module, the same counter value to control the flow of one or more requests in the network (106).
7. A system (108) for controlling flow of one or more requests in a network (106), the system (108) comprising: a memory (204); a processing engine (208) coupled to the memory and is configured to execute instructions stored in the memory (204) to: receive at least one request from a network function (NF); the processing engine (208) further comprises a rate limiter module (210), wherein the rate limiter module (210) is configured to: access a counter value associated with a network repository function (NRF) (304) from a database (212); transmit the at least one received request to the NRF (304) based on the counter value;calculate a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value, wherein the last refreshed time is accessed from the database (212); and perform a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network (106).
8. The system (108) as claimed in claim 7, further configured to: collect one or more configurable ranges via a user interface (UI) by a receiving unit (202), wherein the one or more configurable ranges comprise a defined time interval value, a rate value, and the counter value; and initialize the one or more configurable ranges in the rate limiter module (210) for controlling the flow of one or more requests in the network (106) by the processing engine (208).
9. The system (108) as claimed in claim 7, wherein for transmitting the at least one received request to the NRF (304) based on the counter value, the rate limiter module (210) is further configured to: determine whether to transmit each request of the at least one request by iteratively performing: determine whether the counter value is a non- zero value; upon the determination that the counter value is the non-zero value, transmitting, by the rate limiter module (210) of the processing engine (208), a first request of the at least one received request to the NRF (304); decrement the counter value by one; andidentify a second request of the at least one request as the first request, until all requests of the at least one request are transmitted to the NRF (304) or the counter value becomes zero.
10. The system (108) as claimed in claim 9, wherein the rate limiter module (210) is further configured to: upon determining that the counter value is zero, halt, the transmission of the at least one received request towards the NRF (304) until the counter value is reset.
11. The system (108) as claimed in claim 9, wherein for performing the reset operation on the counter value, the rate limiter module (210) is further configured to: determine whether the calculated time difference exceeds the defined time interval value; upon the determination that the calculated time difference exceeds the defined time interval value, updating, the counter value as the counter value received from the UI; and update the last refreshed time based on a time associated with the reset operation of the counter value.
12. The system (108) as claimed in claim 9, wherein the rate limiter module (210) is further configured to: upon the determination that the calculated time difference does not exceed the defined time interval value, using, the same counter value to control the flow of one or more requests in the network (106).
13. The system (108) as claimed in claim 9, wherein the rate limiter module (210) is further configured to: upon the determination that the calculated time difference does not exceed the defined time interval value, the same counter value is used to control the flow of one or more requests in the network (106).
14. A computer program product comprising a non-transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to execute a method (600) for controlling flow of one or more requests in a network (106), the method (600) comprising: receiving at least one request from a network function (NF); accessing a counter value associated with a network repository function (NRF) (304) from a database (212); transmitting the at least one received request to the NRF (304) based on the counter value; calculating a time difference between a current timestamp and a last refreshed time to determine when to reset the counter value, wherein the last refreshed time is accessed from the database (212); and performing a reset operation on the counter value based on the calculated time difference to control the flow of one or more requests in the network (106).