FORM 2
THE PATENTS ACT, 1970 (39 OF 1970) & THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR MANAGING INCOMING NETWORK REQUESTS ON AN
OVERLOADED PRODUCER NETWORK FUNCTION”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

METHOD AND SYSTEM FOR MANAGING INCOMING NETWORK REQUESTS ON AN OVERLOADED PRODUCER NETWORK FUNCTION
TECHNICAL FIELD
[0001] Embodiments of the present disclosure generally relate to network performance management systems. More particularly, embodiments of the present disclosure relate to methods and systems for managing incoming network requests on an overloaded producer network function (producer NF).
BACKGROUND
[0002] The following description of the 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 is used only to enhance the understanding of the reader with respect to the present disclosure, and not
as admissions of the prior art.
[0003] Wireless communication technology has rapidly evolved over the past few decades, with each generation bringing significant improvements and advancements. The first generation of wireless
communication technology was based on analog technology and offered only voice services. However,
with the advent of the second-generation (2G) technology, digital communication and data services became possible, and text messaging 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 wireless communication with faster data
better network coverage, and improved security. Currently, the fifth-generation (5G) technology is
being deployed, promising even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users.
[0004] As per standard, an overloaded Network Function (producer microservice) can reject requests
received from a consumer network function with a status code such as 503/429/307. It is emphasized that such an approach requires processing the complete request and thereafter rejecting with a suitable response code such as a response code 503/429/307 and response data, which adds to additional processing of application request-response to an already overloaded application. This further puts the
application server in more overloaded condition. Such an approach, is therefore, counter-productive and
only adds to the load of an already overloaded server. It is also noted here that communication between a consumer network function and producer network function happens through HTTP/2 stream even
2

when the producer network function can reject requests received from the consumer network function, thus increasing the load even further on the overloaded producer network function.
[0005] Thus, there exists an imperative need in the art to optimize signalling of requests when a
5 Network Function (producer microservice) is overloaded, which the present disclosure aims to address.
SUMMARY
[0006] This section is provided to introduce certain aspects of the present disclosure in a simplified
10 form that are further described below in the detailed description. This summary is not intended to
identify the key features or the scope of the claimed subject matter.
[0007] An aspect of the present disclosure may relate to a method for managing incoming network requests on an overloaded producer network function (producer NF). The method comprising steps of
15 receiving, by a transceiver unit, at a producer NF, a network request from a consumer network function
(consumer NF), wherein the network request is to establish a communication between the consumer NF and the producer NF to access one of a plurality of microservices running on the producer NF. Further, the method comprises steps of processing, by a processing unit, at the producer NF, the network request, wherein processing the network request comprises parsing the received network request on a network
20 protocol level. Further, the method comprises steps of determining, by a determination unit, at the
producer NF, one of an acceptance and a rejection, of the network request, based on the processing of the network request and a status of the microservice.
[0008] In an exemplary aspect of the present disclosure, the parsing the received network request on a
25 network protocol level comprises reading a header of the network request.
[0009] In an exemplary aspect of the present disclosure, the method further comprises based on one of the acceptance and the rejection of the network request, transmitting, by the producer NF, an acknowledgement to the consumer NF. 30
[0010] In an exemplary aspect of the present disclosure, the rejection, by the producer NF, of the network request, is based on an overloaded status of the microservice.
[0011] In an exemplary aspect of the present disclosure, in the event of the rejection of the network
35 request, transmitting, by the producer NF, an internal error response as a response to the consumer NF.
3

[0012] In an exemplary aspect of the present disclosure, the internal error response further comprises an excessive load error message.
[0013] In an exemplary aspect of the present disclosure, the acceptance, by the producer NF, of the
5 network request, is based on a non-overloaded status of the microservice.
[0014] In an exemplary aspect of the present disclosure, the method further comprises in the event of
the acceptance of the network request, transmitting, by the producer NF, an overload control
information (OCI) header information and a load control information (LCI) header information as a
10 response to the consumer NF.
[0015] In an exemplary aspect of the present disclosure, the network request is a HTTP/2 network request message.
15 [0016] Another aspect of the present disclosure may relate to a system for managing incoming network
requests on an overloaded producer network function (producer NF). The system comprises a transceiver unit, at a producer NF, configured to receive a network request from a consumer network function (consumer NF), wherein the network request is to establish a communication between the consumer NF and the producer NF to access one of a plurality of microservices running on the producer
20 NF. Further, the system comprises a processing unit, at the producer NF, configured to process the
network request, wherein processing the network request comprises parsing the received network request on a network protocol level. Further, the system comprises a determination unit, at the producer NF, configured to determine one of an acceptance and a rejection, of the network request, based on the processing of the network request and a status of the microservice.
25
[0017] Yet another aspect of the present disclosure may relate to a non-transitory computer readable storage medium storing instructions for managing incoming network requests on an overloaded producer network function (producer NF), the instructions include executable code which, when executed by one or more units of a system, causes: a transceiver unit to receive at a producer NF, a
30 network request from a consumer network function (consumer NF), wherein the network request is to
establish a communication between the consumer NF and the producer NF to access one of a plurality of microservices running on the producer NF; a processing unit to process at the producer NF, the network request, wherein processing the network request comprises parsing the received network request on a network protocol level; and a determination unit to determine at the producer NF, one of
35 an acceptance and a rejection, of the network request, based on the processing of the network request
and a status of the microservice.
4

OBJECTS OF THE DISCLOSURE
[0018] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below. 5
[0019] It is an object of the present disclosure to provide a system and a method for managing incoming network requests on an overloaded producer network function (producer NF).
[0020] It is another object of the present disclosure to provide a solution that ensures early recovery of
10 a Network Function (producer microservice) from an overload condition.
[0021] It is yet another object of the present disclosure to provide a solution that does not add to a load of already overloaded Network Function (producer microservice).
15 DESCRIPTION OF THE DRAWINGS
[0022] 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
20 drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the
principles of the present disclosure. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system according to the disclosure are illustrated herein to highlight the advantages of the disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry
25 commonly used to implement such components.
[0023] Figure 1 illustrates an exemplary block diagram representation of 5th generation core (5GC) network architecture.
30 [0024] Figure 2 illustrates an exemplary block diagram of a computing device upon which the features
of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.
[0025] Figure 3 illustrates an exemplary block diagram of a system for managing incoming network
35 requests on an overloaded producer network function (producer NF), in accordance with exemplary
implementations of the present disclosure.
5

[0026] Figure 4 illustrates an exemplary method flow diagram indicating the decision making involved in the method and process for managing incoming network requests on an overloaded producer network function (producer NF), in accordance with exemplary embodiments of the present disclosure.
5 [0027] Figure 5 illustrates a method flow diagram for managing incoming network requests on an
overloaded producer network function (producer NF) in accordance with exemplary implementations of the present disclosure.
[0028] The foregoing shall be more apparent from the following more detailed description of the
10 disclosure.
DETAILED DESCRIPTION
[0029] In the following description, for the purposes of explanation, various specific details are set
15 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 may 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. 20
[0030] 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
25 arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0031] 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, processes, and other
30 components may be shown as components in block diagram form in order not to obscure the
embodiments in unnecessary detail.
[0032] Also, it is noted that individual embodiments may be described as a process which is depicted
as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although
35 a flowchart may describe the operations as a sequential process, many of the operations may be
performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A
6

process is terminated when its operations are completed but could have additional steps not included in a figure.
[0033] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example,
5 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
10 other similar words are used in either the detailed description or the claims, such terms are intended to
be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0034] As used herein, a “processing unit” or “processor” or “operating processor” includes one or
15 more processors, wherein processor refers to any logic circuitry for processing instructions. A processor
may be a general-purpose processor, a special purpose processor, a conventional processor, a digital
signal processor, a plurality of microprocessors, one or more microprocessors in association with a
Digital Signal Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated
Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The
20 processor may perform signal coding data processing, input/output processing, and/or any other
functionality that enables the working of the system according to the present disclosure. More specifically, the processor or processing unit is a hardware processor.
[0035] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smart-device”,
25 “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a
mobile communication device”, “a communication device” may be any electrical, electronic and/or
computing device or equipment, capable of implementing the features of the present disclosure. The
user equipment/device may include, but is not limited to, a mobile phone, smart phone, laptop, a
general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any
30 other computing device which is capable of implementing the features of the present disclosure. Also,
the user device may contain at least one input means configured to receive an input from unit(s) which are required to implement the features of the present disclosure.
[0036] As used herein, “storage unit” or “memory unit” refers to a machine or computer-readable
35 medium including any mechanism for storing information in a form readable by a computer or similar
machine. For example, a computer-readable medium includes read-only memory (“ROM”), random
access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices
7

or other types of machine-accessible storage media. The storage unit stores at least the data that may be required by one or more units of the system to perform their respective functions.
[0037] As used herein “interface” or “user interface refers to a shared boundary across which two or
5 more separate components of a system exchange information or data. The interface may also be referred
to a set of rules or protocols that define communication or interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.
10 [0038] All modules, units, components used herein, unless explicitly excluded herein, may be software
modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type
15 of integrated circuits, etc.
[0039] As used herein the transceiver unit include at least one receiver and at least one transmitter configured respectively for receiving and transmitting data, signals, information or a combination thereof between units/components within the system and/or connected with the system.
20
[0040] As discussed in the background section, the current known solutions have several shortcomings because the conventional approach required the processing of the complete request by an overloaded network function (NF) to even reject the received request at the overloaded Network Function (NF). This adds to additional processing of application request-response to an already overloaded NF
25 (producer microservice). The present disclosure aims to overcome the above-mentioned and other
existing problems in this field of technology by providing method and system of managing incoming network requests on an overloaded producer network function (producer NF), which processes the header of the request and accordingly accepts or rejects the request based on the load status of the producer microservice. The present disclosure aims to cut off the additional time that is implemented
30 in processing the complete request, and further ensures that the Network Function (producer
microservice) is not overloaded with additional requests in case of an overload status of the Network Function (producer microservice).
35 [0041] Figure 1 illustrates an exemplary block diagram representation of 5th generation core (5GC)
network architecture, in accordance with exemplary implementation of the present disclosure. As shown in figure 1, the 5GC network architecture [100] includes a user equipment (UE) [102], a radio access
8

network (RAN) [104], an access and mobility management function (AMF) [106], a Session
Management Function (SMF) [108], a Service Communication Proxy (SCP) [110], an Authentication
Server Function (AUSF) [112], a Network Slice Specific Authentication and Authorization Function
(NSSAAF) [114], a Network Slice Selection Function (NSSF) [116], a Network Exposure Function
5 (NEF) [118], a Network Repository Function (NRF) [120], a Policy Control Function (PCF) [122], a
Unified Data Management (UDM) [124], an application function (AF) [126], a User Plane Function (UPF) [128], a data network (DN) [130], wherein all the components are assumed to be connected to each other in a manner as obvious to the person skilled in the art for implementing features of the present disclosure.
10
[0042] Radio Access Network (RAN) [104] is the part of a mobile telecommunications system that connects user equipment (UE) [102] to the core network (CN) and provides access to different types of networks (e.g., 5G network). It consists of radio base stations and the radio access technologies that enable wireless communication.
15
[0043] Access and Mobility Management Function (AMF) [106] is a 5G core network function responsible for managing access and mobility aspects, such as UE registration, connection, and reachability. It also handles mobility management procedures like handovers and paging.
20 [0044] Session Management Function (SMF) [108] is a 5G core network function responsible for
managing session-related aspects, such as establishing, modifying, and releasing sessions. It coordinates with the User Plane Function (UPF) for data forwarding and handles IP address allocation and QoS enforcement.
25 [0045] Service Communication Proxy (SCP) [110] is a network function in the 5G core network that
facilitates communication between other network functions by providing a secure and efficient messaging service. It acts as a mediator for service-based interfaces.
[0046] Authentication Server Function (AUSF) [112] is a network function in the 5G core responsible
30 for authenticating UEs during registration and providing security services. It generates and verifies
authentication vectors and tokens.
[0047] Network Slice Specific Authentication and Authorization Function (NSSAAF) [114] is a
network function that provides authentication and authorization services specific to network slices. It
35 ensures that UEs can access only the slices for which they are authorized.
9

[0048] Network Slice Selection Function (NSSF) [116] is a network function responsible for selecting the appropriate network slice for a UE based on factors such as subscription, requested services, and network policies.
5 [0049] Network Exposure Function (NEF) [118] is a network function that exposes capabilities and
services of the 5G network to external applications, enabling integration with third-party services and applications.
[0050] Network Repository Function (NRF) [120] is a network function that acts as a central repository
10 for information about available network functions and services. It facilitates the discovery and dynamic
registration of network functions.
[0051] Policy Control Function (PCF) [122] is a network function responsible for policy control
decisions, such as QoS, charging, and access control, based on subscriber information and network
15 policies.
[0052] Unified Data Management (UDM) [124] is a network function that centralizes the management of subscriber data, including authentication, authorization, and subscription information.
20 [0053] Application Function (AF) [126] is a network function that represents external applications
interfacing with the 5G core network to access network capabilities and services.
[0054] User Plane Function (UPF) [128] is a network function responsible for handling user data traffic, including packet routing, forwarding, and QoS enforcement. 25
[0055] Data Network (DN) [130] refers to a network that provides data services to user equipment (UE) in a telecommunications system. The data services may include but are not limited to Internet services, private data network related services.
30 [0056] Figure 2 illustrates an exemplary block diagram of a computing device [200] (also referred
herein as a computing system) upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure. In an implementation, the computing device [200] may also implement a method for managing incoming network requests on an overloaded producer network function (producer NF) utilising the system. In another implementation,
35 the computing device [200] itself implements the method for managing the incoming network requests
on the overloaded producer network function (producer NF) using one or more units configured within
10

the computing device [200], wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
[0057] The computing device [200] may include a bus [202] or other communication mechanism for
5 communicating information, and a hardware processor [204] coupled with the bus [202] for processing
information. The hardware processor [204] may be, for example, a general-purpose microprocessor. The computing device [200] may also include a main memory [206], such as a random-access memory (RAM), or other dynamic storage device, coupled to the bus [202] for storing information and instructions to be executed by the processor [204]. The main memory [206] also may be used for storing
10 temporary variables or other intermediate information during execution of the instructions to be
executed by the processor [204]. Such instructions, when stored in non-transitory storage media accessible to the processor [204], render the computing device [200] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device [200] further includes a read only memory (ROM) [208] or other static storage device coupled to the bus
15 [202] for storing static information and instructions for the processor [204].
[0058] A storage device [210], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [202] for storing information and instructions. The computing device [200] may be coupled via the bus [202] to a display [212], such as a cathode ray tube (CRT), Liquid crystal Display
20 (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying
information to a computer user. An input device [214], including alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus [202] for communicating information and command selections to the processor [204]. Another type of user input device may be a cursor controller [216], such as a mouse, a trackball, or cursor direction keys, for communicating direction information and
25 command selections to the processor [204], and for controlling cursor movement on the display [212].
This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.
[0059] The computing device [200] may implement the techniques described herein using customized
30 hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination
with the computing device [200] causes or programs the computing device [200] to be a special-purpose
machine. According to one implementation, the techniques herein are performed by the computing
device [200] in response to the processor [204] executing one or more sequences of one or more
instructions contained in the main memory [206]. Such instructions may be read into the main memory
35 [206] from another storage medium, such as the storage device [210]. Execution of the sequences of
instructions contained in the main memory [206] causes the processor [204] to perform the process
11

steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.
[0060] The computing device [200] also may include a communication interface [218] coupled to the
5 bus [202]. The communication interface [218] provides a two-way data communication coupling to a
network link [220] that is connected to a local network [222]. For example, the communication interface
[218] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a
modem to provide a data communication connection to a corresponding type of telephone line. As
another example, the communication interface [218] may be a local area network (LAN) card to provide
10 a data communication connection to a compatible LAN. Wireless links may also be implemented. In
any such implementation, the communication interface [218] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
15 [0061] The computing device [200] can send messages and receive data, including program code,
through the network(s), the network link [220] and the communication interface [218]. In the Internet example, a server [230] might transmit a requested code for an application program through the Internet [228], the ISP [226], the local network [222], the host [224] and the communication interface [218]. The received code may be executed by the processor [204] as it is received, and/or stored in the storage
20 device [210], or other non-volatile storage for later execution.
[0062] Referring to Figure 3, an exemplary block diagram of a system [300] for managing incoming network requests on an overloaded producer network function (producer NF) [302], is shown, in accordance with the exemplary implementations of the present disclosure. The system [300] comprises
25 at least one producer network function (producer NF) [302], at least one transceiver unit [306], at least
one processing unit [308], at least one determination unit [310], and at least one storage unit [312]. Also, all of the components/ units of the system [300] are assumed to be connected to each other unless otherwise indicated below. As shown in the figures all units shown within the system [300] should also be assumed to be connected to each other. Also, in Figure 3 only a few units are shown, however, the
30 system [300] may comprise multiple such units or the system [300] may comprise any such numbers of
said units, as required to implement the features of the present disclosure. Further, in another implementation, the system [300] may reside in a server or a network entity.
[0063] Further, in accordance with the present disclosure, it is to be acknowledged that the
35 functionality described for the various the components/units can be implemented interchangeably.
While specific embodiments may disclose a particular functionality of these units for clarity, it is
recognized that various configurations and combinations thereof are within the scope of the disclosure.
12

The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure. 5
[0064] The system [300] is configured for managing the incoming network requests on the overloaded producer network function (producer NF) [302], with the help of the interconnection between the components/units of the system [300].
10 [0065] The system [300] comprises the transceiver unit [306], at the producer NF [302]. Said
transceiver unit [306] is configured to receive a network request from the consumer network function (consumer NF) [304], wherein the network request is to establish a communication between the consumer NF [304] and the producer NF [302] to access one of a plurality of microservices running on the producer NF [302]. Further, the network request is a HTTP/2 network request message.
15
[0066] Herein, the Producer NF [302] may relate to a network function that facilitates the plurality of microservices. Further, the consumer NF [304] may relate to a network function that is accessing the one or more microservices from the plurality of microservices. Herein, the consumer NF [304] may involve a network function from one of an Access and Mobility Management Function (AMF), Session
20 Management Function (SMF) and similar known in the art, that is accessing the one or more
microservices.
[0067] Further, the producer NF [302] refers to a network function that generates or produces data, services, or resources in response to requests or triggers from the consumer NF [304]. The Producer NF
25 [302] is responsible for creating and providing various services, such as data processing, authentication,
mobility management, or media streaming, among others. Further, the plurality of microservices associated with the Producer NF [302] may be a microservice that is responsible for the data processing, the authentication, the mobility management and any other service provided by the Producer NF [302]. The Producer NF [302] may generate information or perform actions that are consumed by the consumer
30 NF [304] and/or by end-user devices.
[0068] Furthermore, the consumer NF [304] refers to a network function that utilizes or consumes the
data, services, or resources produced by the Producer NF [302]. The consumer NF [304] rely on the
information provided by the Producer NF [302] to perform their designated tasks or deliver services to
35 the end-user devices. The consumer NF [304] is responsible for processing, analyzing, or forwarding
data received from the Producer NF [302] in order to enable the seamless flow of information within the telecommunications network. In short, the Producer NF [302] generate data or services, while the
13

consumer NF [304] utilize or consume the generated data or services, collectively the Producer NF [302] and the consumer NF [304] contributes to the delivery of telecommunications services and functionalities.
5 [0069] Further, the transceiver unit [306] may facilitate an effective communication between
the consumer NF [304] and the producer NF [302] within the network. The primary purpose of the transceiver unit [306] is to receive the network request from the one or more consumer NF [304], and accordingly managing the connections between the consumer NF [304] and the producer NF [302] based on the network request.
10
[0070] Further, the network request is the HTTP/2 network request message. The HTTP/2 is an upgraded version of a Hyper Text Transfer Protocol (HTTP) protocol, which are used for transferring one or more information from one entity to another (here from one network function to another). Herein, the HTTP/2 network request message indicates a request message received at the producer NF [302]
15 via the HTTP/2 protocol. The HTTP/2 protocol is able to support multiplexing and allows the producer
NF [302] to receive a plurality of network requests.
[0071] For example: in an implementation of the present disclosure, considering a producer network function (NF) A, may be associated with a microservice (assuming a Service Based Architecture (SBA)). Further, the Producer NF A may receive a message request from a consumer network function (NF) Z such as (Session Management Function (SMF)). Herein, the message request may relate to an authentication of a user equipment (UE) on a Home Subscriber Server (HSS). Further, in accordance with the present disclosure, the transceiver unit [306] at the Producer NF A may receive the request from the consumer NF Z and may further act accordingly to facilitate the authentication of the user equipment (UE).
[0072] The system [300] further comprises the processing unit [308], at the producer NF [302], the
processing unit [308] is configured to process the network request, wherein processing the network
request comprises parsing the received network request on a network protocol level. Further, the parsing
30 the received network request on the network protocol level comprises reading a header of the network
request
[0073] Post receiving the network request at the transceiver unit [306], the processing unit [308]
connected with the transceiver unit [306] may further, processes the received network request. The
35 processing unit [308] process the received network request by parsing the network request at the
network protocol level, implying that the processing unit [308] parses the received network request for
14

reading the header of the network request. The term parsing as mentioned above may refer to a process
of converting a set of data (here the header of the network request) from one data from to another data
form such as parsing the data to convert the machine readable data to a human readable data. The
processing unit may further identify the readable data within a set of information associated with the
5 network request, wherein the set of information is stored in the storage unit [312]. Herein, the header
of the network request may comprise information related to the network request, which may include an
identifier, a type of request, and a target microservice from at least one of the plurality of microservices
which the consumer NF [304] requires to access at the Producer NF [302]. The header of the network
request may further contain any form comprising data values such as a computer readable form in a
10 predefined format, or authentication data, and other data that may value for processing the received
network request.
[0074] Herein the term ‘target microservice’ reflects at least one specific microservice from the plurality of microservices that the consumer NF [304] desires to access at the producer NF [302].
15 Further, a status of the target microservice may indicate the availability of the target microservice at the
producer NF [302]. For example: in an implementation of the present disclosure, considering the above-mentioned scenario, post receiving the network request by the transceiver unit at the producer NF A, a processing unit at the producer NF A, may further parse the header of received network request in order to determine one or more relevant details from the network request such as an identifier of UE, a type
20 of request, and a target microservice at the SBA. (here, the target microservice may relate to the
microservice at the SBA, such as HSS that is used for authenticating the UE).
[0075] The system [300] further comprises the determination unit [310], at the producer NF [302], the
determination unit [310] is configured to determine one of an acceptance and a rejection, of the network
25 request, based on the processing of the network request and a status of the microservice.
[0076] Post identifying the target microservice at the producer NF [302], the determination unit [310] may further determine one of the acceptance and rejection of the receiving network request based on the status of the target microservice. The determination unit [310] may firstly determine the status of
30 the target microservice at the producer NF [302], as the producer NF [302] may include one or more
microservices, and each microservice from the one or more microservices may a have a pre-defined capacity for executing a number of network request, and based on the total number of current request executed at each microservice from the one or more microservices, the determination unit [310] may detect an availability for acceptance of a new network request at the target microservice of the producer
35 NF [302].
15

[0077] Further, the acceptance, by the producer NF [302], of the network request, is based on a non-
overloaded status of the microservice. Further, the transceiver unit [306] is further configured to
transmit an acknowledgement to the consumer NF [304], based on one of the acceptance and the
rejection of the network request. The transceiver unit [306] is further configured to transmit an overload
5 control information (OCI) header information and a load control information (LCI) header information
as a response to the consumer NF [304].
[0078] In case, the target microservice is operating under a pre-defined capacity associated with the network request at the target microservice (current load), implying that the target microservice has the
10 non-overload status. Thereafter, the determination unit [310] may further provide acceptance to the
network request, which further allows the consumer NF [304] to access the target microservice at the producer NF [302]. Post acceptance of the received network request, the transceiver unit [306] may further transmits the acknowledgement message to the consumer NF [304], regarding the acceptance of the network request.
15
[0079] The transceiver unit [306] may further send the OCI header information and the LCI header information as the response to the consumer NF [304]. Herein, the OCI header information may incorporate an information regarding the potential for overload of the network request at the target microservice, and the LCI header information may incorporate information regarding the current
20 capacity of the target microservice. Herein, the term ‘current capacity’ (current load) of the target
microservice may refer to the total number of requests that are being handled by the producer NF [302]. Further, the term ‘potential of overload’ may refer to a warning notification to notify that the current capacity of the target microservice nearing the pre-defined capacity of the target microservice.
25 [0080] For example: in an implementation of the present disclosure, considering the above-mentioned
scenario, post identifying the target microservice (here SBA), a determining unit at the producer NF may further determine the current number of request running at the SBA. In case, the SBA is running under its pre-defined capacity and is able to take a new network request. Then, the transceiver unit at the producer NF may further transmit an acknowledgement message, a transmit overload control
30 information (OCI) and load control information (LCI) as a response to the consumer NF.
[0081] Further, the rejection, by the producer NF [302], of the network request, is based on an
overloaded status of the microservice. In the event of rejection of the network request, the transceiver
unit [306], is further configured to transmit an internal error response as a response to the consumer NF
35 [304]. Further, the internal error response further comprises an excessive load error message.
16

[0082] In case the target microservice is operating beyond the pre-defined capacity associated with the network request at the target microservice, implying that the target microservice has the overload status. Thereafter, the determination unit [310] may reject the received network request, in order to prevent any further overloading of the target microservice. 5
[0083] Post rejection of the received network request the transceiver unit [306] may further transmits
the acknowledgement message to the consumer NF [304], regarding the rejection of the network
request. The transceiver unit [306] may transmit the internal error response in response to the consumer
NF [304], in case of the rejection of received network request. Herein the internal error may correspond
10 to a RST-STREAM (reset stream) message.
[0084] Herein, the RST-STREAM message of the HTTP/2 protocol allows the producer NF [302] to indicate to the consumer NF [304] that a previous stream i.e., the network request may be cancelled by sending a RST_STREAM frame. 15
[0085] Herein, the internal error response may further comprise the excessive load error message, implying that the network request is terminated due to the overload status of the target microservice.
[0086] For example: in an implementation of the present disclosure, considering the above-mentioned
20 scenario, in case the determination unit at the producer NF A may determine that the current number of
request running at the SBA is beyond the pre-defined capacity of the SBA or is similar to the pre¬
defined capacity of the SBA. Then, transceiver unit at the producer NF A may further transmit an
acknowledgement message, regarding the rejection of the current network request. The transceiver unit
at the producer NF A may further send an internal error response which may include an excessive
25 overload message as a response to the consumer NF Z. The excessive overload message may indicate
that the target microservice is handing multiple network requests and the current network request is rejected to prevent overloading of the network request.
[0087] Referring to Figure 4, an exemplary method [400] flow diagram indicating the decision making
30 involved in the method [400] and process for managing incoming network requests on an overloaded
producer network function (producer NF) [302], in accordance with exemplary embodiments of the present disclosure is shown. In an implementation, the method [400] may be implemented by the system [300]. Further, in an implementation, the system [300] may be present in a server device to implement the features of the present disclosure. 35
[0088] The method [400] starts at step [402] and proceeds to step [404].
17

[0089] At step [404], the method [400] reads overloading settings (pre-defined capacity) for each of microservices of a plurality of microservices, that are running at the producer network function (NF) [302].
5 [0090] At step [406], the method [400] waits for a new network request at the producer NF [302].
[0091] At step [408], the method [400] successfully receives a new network request at the producer NF [302], where the new network request may relate to accessing of one or more microservices from the plurality of microservices. 10
[0092] At step [410], the method [400] processes the received network request, to determine one or more target microservice from the plurality of microservices and accordingly check the overload settings of the target one or more microservices.
15 [0093] At step [412], in case, the method [400] determines that the overload settings of the of the one
or more target microservice is positive, implying that the one or more target microservice is overloaded, and simultaneously the system [300] rejects the received network request by sending a RST_STREAM message back to the one or more consumer NF [304].
[0094] At step [414], in case, the method [400] determines that the overload settings of the of the target one or more microservices is negative, implying that one or more target microservice is available to receive new network request, then the system [300] accepts the received network request and responds with a OCI (Overload control information) header information and a LCI (Local Channel Identifier) header information to notify the overload settings of the one or more target microservice to the one or more consumer NF [304].
[0095] At step [416], the method [400] further follows the step [406] and waits for another network request at the producer NF [302].
30 [0096] Thereafter, the method [400] terminates.
[0097] Referring to Figure 5, a method [500] flow diagram [500] for managing incoming network
requests on an overloaded producer network function (producer NF) [302], in accordance with
exemplary implementations of the present disclosure is shown. In an implementation the method [500]
35 is performed by the system [300]. Further, in an implementation, the system [300] may be present in a
server device to implement the features of the present disclosure. Also, as shown in Figure 5, the method [500] starts at step [502] and proceeds to step [504].
18

[0098] At step [504], the method [500] comprises receiving, by a transceiver unit [306], at a producer
NF [302], a network request from a consumer network function (consumer NF) [304], wherein the
network request is to establish a communication between the consumer NF [304] and the producer NF
5 [302] to access one of a plurality of microservices running on the producer NF [302]. Further, the
network request is a HTTP/2 network request message.
[0099] Herein, the Producer NF [302] may relate to a network function that facilitates the plurality of
microservices. Further, the consumer NF [304] may relate to a network function that is accessing the
10 one or more microservices from the plurality of microservices. Herein, the consumer NF [304] may
involve a network function from one of an Access and Mobility Management Function (AMF), Session Management Function (SMF) and similar known in the art, that is accessing the one or more microservices.
15 [0100] Further, the Producer NF [302] refers to a network function that generates or produces data,
services, or resources in response to requests or triggers from the consumer NF [304]. The Producer NF [302] is responsible for creating and providing various services, such as data processing, authentication, mobility management, or media streaming, among others. Further, the plurality of microservices associated with the Producer NF [302] may be a microservice that is responsible for the data processing,
20 the authentication, the mobility management and any other service provided by the Producer NF [302].
The Producer NF [302] may generate information or perform actions that are consumed by the consumer NF [304] and/or by end-user devices.
[0101] Furthermore, the consumer NF [304] refers to a network function that utilizes or consumes the
25 data, services, or resources produced by the Producer NF [302]. The consumer NF [304] rely on the
information provided by the Producer NF [302] to perform their designated tasks or deliver services to
the end-user devices. The consumer NF [304] is responsible for processing, analyzing, or forwarding
data received from the Producer NF [302] in order to enable the seamless flow of information within
the telecommunications network. In short, the Producer NF [302] generate data or services, while the
30 consumer NF [304] utilize or consume the generated data or services, collectively the Producer NF
[302] and the consumer NF [304] contributes to the delivery of telecommunications services and functionalities.
[0102] Further, the transceiver unit [306] may facilitate an effective communication between the
35 consumer NF [304] and the producer NF [302] within the network. The primary purpose of the
transceiver unit [306] is to receive the network request from the one or more consumer NF [304], and
19

accordingly managing the connections between the consumer NF [304] and the producer NF [302] based on the network request.
[0103] Further, the network request is the HTTP/2 network request message. The HTTP/2 is an
5 upgraded version of a Hyper Text Transfer Protocol (HTTP) protocol, which are used for transferring
one or more information from one entity to another (here from one network function to another). Herein, the HTTP/2 network request message indicates a request message received at the producer NF [302] via the HTTP/2 protocol. The HTTP/2 protocol is able to support multiplexing and allows the producer NF [302] to receive a plurality of network requests.
10
[0104] For example: in an implementation of the present disclosure, considering a producer network function (NF) A, may be associated with a microservice (assuming a Service Based Architecture (SBA)). Further, the Producer NF A may receive a message request from a consumer network function (NF) Z such as (Session Management Function (SMF)). Herein, the message request may relate to an
15 authentication of a user equipment (UE) on a Home Subscriber Server (HSS). Further, in accordance
with the present disclosure, the transceiver unit [306] at the Producer NF A may receive the request from the consumer NF Z and may further act accordingly to facilitate the authentication of the user equipment (UE).
20 [0105] At step [506], the method [500] further comprises steps of processing, by a processing unit
[308], at the producer NF [302], the network request, wherein processing the network request comprises parsing the received network request on a network protocol level. Further, in an implementation of the present disclosure herein, the parsing the received network request on a network protocol level comprises reading a header of the network request.
25
[0106] The method [500] further states that, post receiving the network request at the transceiver unit [306], the processing unit [308] connected with the transceiver unit [306] may further, processes the received network request. The processing unit [308] process the received network request by parsing the network request at the network protocol level, implying that the processing unit [308] parses the
30 received network request for reading the header of the network request. The term parsing as mentioned
above may refer to a process of converting a set of data (here the header of the network request) from one data from to another data form such as parsing the data to convert the machine readable data to a human readable data. The processing unit may further identify the readable data within a set of information associated with the network request, wherein the set of information is stored in the storage
35 unit [312]. Herein, the header of the network request may comprise information related to the network
request, which may include an identifier, a type of request, and a target microservice from at least one of the plurality of microservices which the consumer NF [304] requires to access at the Producer NF
20

[302]. The header of the network request may further contain any form comprising data values such as a computer readable form in a predefined format, or authentication data, and other data that may value for processing the received network request.
5 [0107] Herein the term ‘target microservice’ reflects a at least one specific microservice from the
plurality of microservices that the consumer NF [304] desire to access at the producer NF [302]. Further,
a status of the target microservice may indicate the availability of the target microservice at the producer
NF [302]. For example: in an implementation of the present disclosure, considering the above-
mentioned scenario, post receiving the network request by the transceiver unit at the producer NF A, a
10 processing unit at the producer NF A, may further parse the header of received network request in order
to determine one or more relevant details from the network request such as a identifier of UE, a type of request, and a target microservice at the SBA. (here, the target microservice may relate to the microservice at the SBA, such as HSS that is used for authenticating the UE).
15 [0108] At step [508], the method [500] further comprises steps of determining, by a determination unit
[310], at the producer NF [302], one of an acceptance and a rejection, of the network request, based on the processing of the network request and a status of the microservice.
[0109] The method [500] further states that post identifying the target microservice at the producer NF
20 [302], the determination unit [310] may further determine one of the acceptance and rejection of the
receiving network request based on the status of the target microservice. The determination unit [310]
may firstly determine the status of the target microservice at the producer NF [302], as the producer NF
[302] may include one or more microservices, and each microservice from the one or more
microservices may a have a pre-defined capacity for executing a number of network request, and based
25 on the total number of current request executed at the each microservice from the one or more
microservices, the determination unit [310] may detect an availability for acceptance of a new network request at the target microservice of the producer NF [302].
[0110] The method [500] further comprises that the acceptance, by the producer NF [302] of the
30 network request, is based on a non-overloaded status of the microservice. The method [500] further
comprises transmitting, by the producer NF [302], an acknowledgement to the consumer NF [304]
based on one of the acceptance and the rejection of the network request. Further, in the event of the
acceptance of the network request, transmitting, by the producer NF [302], an overload control
information (OCI) header information and a load control information (LCI) header information as a
35 response to the consumer NF [304].
21

[0111] The method [500] further discloses that in case, the target microservice is operating under a
pre-defined capacity associated with the network request at the target microservice (current load),
implying that the target microservice has the non-overload status. Thereafter, the determination unit
[310] may further provide acceptance to the network request, which further allows the consumer NF
5 [304] to access the target microservice at the producer NF [302]. Post acceptance of the received
network request, the method may further comprises transmitting by the transceiver unit [306] the acknowledgement message to the consumer NF [304], regarding the acceptance of the network request.
[0112] The transceiver unit [306] may further send the OCI header information and the LCI header information as the response to the consumer NF [304]. Herein, the OCI header information may incorporate an information regarding the potential for overload of the network request at the target microservice, and the LCI header information may incorporate information regarding the current capacity of the target microservice. Herein, the term ‘current capacity’ (current load) of the target microservice may refer to the total number of requests that are being handled by the producer NF [302]. Further, the term ‘potential of overload’ may refer to a warning notification to notify that the current capacity of the target microservice nearing the pre-defined capacity of the target microservice.
[0113] For example: in an implementation of the present disclosure, considering the above-mentioned
scenario, post identifying the target microservice (here SBA), a determining unit at the producer NF
20 may further determine the current number of request running at the SBA. In case, the SBA is running
under its pre-defined capacity and is able to take a new network request. Then, the transceiver unit at the producer NF may further transmit an acknowledgement message, a transmit overload control information (OCI) and load control information (LCI) as a response to the consumer NF.
25 [0114] The method [500] further comprises that the rejection by the producer NF [302], of the network
request is based on an overloaded status of the microservice. Further, in the event of the rejection of the network request, transmitting, by the producer NF [302], an internal error response as a response to the consumer NF [304]. Further, in an implementation of the present disclosure herein, the internal error response further comprises an excessive load error message.
30
[0115] The method [500] further explains that in case the target microservice is operating beyond the pre-defined capacity associated with the network request at the target microservice, implying that the target microservice has the overload status. Thereafter, the determination unit [310] may reject the received network request, in order to prevent any further overloading of the target microservice.
35
[0116] Post rejection of the received network request the transceiver unit [306] may further transmits the acknowledgement message to the consumer NF [304], regarding the rejection of the network
22

request. The transceiver unit [306] may transmit the internal error response in response to the consumer NF [304], in case of the rejection of received network request. Herein the internal error may correspond to a RST-STREAM (reset stream) message.
5 [0117] Herein, the RST-STREAM message of the HTTP/2 protocol allows the producer NF [302] to
indicate to the consumer NF [304] that a previous stream i.e., the network request may be cancelled by sending a RST_STREAM frame.
[0118] Herein, the internal error response may further comprise the excessive load error message,
10 implying that the network request is terminated due to the overload status of the target microservice.
[0119] For example: in an implementation of the present disclosure, considering the above-mentioned
scenario, in case the determination unit at the producer NF A may determine that the current number of
request running at the SBA is beyond the pre-defined capacity of the SBA or is similar to the pre-
15 defined capacity of the SBA. Then, transceiver unit at the producer NF A may further transmit an
acknowledgement message, regarding the rejection of the current network request. The transceiver unit
at the producer NF A may further send an internal error response which may include an excessive
overload message as a response to the consumer NF Z. The excessive overload message may indicate
that the target microservice is handing multiple network requests and the current network request is
20 rejected to prevent overloading of the network request.
[0120] The method [500] terminates at step [510].
[0121] The present disclosure further discloses a non-transitory computer readable storage medium
25 storing instructions for managing incoming network requests on an overloaded producer network
function (producer NF) [302], the instructions include executable code which, when executed by one
or more units of a system [300], causes: a transceiver unit [306] to receive at a producer NF [302], a
network request from a consumer network function (consumer NF) [304], wherein the network request
is to establish a communication between the consumer NF [304] and the producer NF [302] to access
30 one of a plurality of microservices running on the producer NF [302]; a processing unit [308] to process
at the producer NF [302], the network request, wherein processing the network request comprises
parsing the received network request on a network protocol level; and a determination unit [310] to
determine at the producer NF [302], one of an acceptance and a rejection, of the network request, based
on the processing of the network request and a status of the microservice.
35
[0122] As is evident from the above, the present disclosure provides a technically advanced solution for managing incoming network requests on an overloaded producer network function (producer NF)].
23

The present solution enables microservices server to reject HTTP/2 request message as soon as a request
message header is received and send an RST_STREAM in response. This mechanism ensures an early
recovery of the Network Function (producer microservice) from overload condition, as further load is
not placed on Network Function (producer microservice) in case of an overload status of the Network
5 Function (producer microservice).
[0123] While considerable emphasis has been placed herein on the disclosed
implementations, it will be appreciated that many implementations can be made and that many changes
can be made to the implementations without departing from the principles of the present disclosure.
10 These and other changes in the implementations of the present disclosure will be apparent to those
skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

We Claim:
1. A method [500] for managing incoming network requests on an overloaded producer network
5 function (producer NF) [302], the method [500] comprising:
receiving, by a transceiver unit [306], at a producer NF [302], a network request from a consumer
network function (consumer NF) [304], wherein the network request is to establish a
communication between the consumer NF [304] and the producer NF [302] to access one of a
plurality of microservices running on the producer NF [302];
processing, by a processing unit [308], at the producer NF [302], the network request, wherein processing the network request comprises parsing the received network request on a network protocol level; and 15
determining, by a determination unit [310], at the producer NF [302], one of an acceptance and a rejection, of the network request, based on the processing of the network request and a status of the microservice.
2. The method [500] as claimed in claim 1, wherein the parsing the received network request on the
network protocol level comprises reading a header of the network request.
3. The method [500] as claimed in claim 1, further comprising:
based on one of the acceptance and the rejection of the network request, transmitting, by the
producer NF [302], an acknowledgement to the consumer NF [304].
4. The method [500] as claimed in claim 1, wherein the rejection, by the producer NF [302], of the
network request, is based on an overloaded status of the microservice.
5. The method [500] as claimed in claim 4, wherein, in an event of the rejection of the network
request, transmitting, by the producer NF [302], an internal error response as a response to the consumer NF [304].
6. The method [500] as claimed in claim 5, wherein the internal error response further comprises an
excessive load error message.
25

7. The method [500] as claimed in claim 1, wherein the acceptance, by the producer NF [302], of
the network request, is based on a non-overloaded status of the microservice.
8. The method [500] as claimed in claim 7, further comprising:
in an event of the acceptance of the network request, transmitting, by the producer NF [302], an
overload control information (OCI) header information and a load control information (LCI) header information as a response to the consumer NF [304].
9. The method [500] as claimed in claim 1, wherein the network request is a HTTP/2 network request message.
10. A system [300] for managing incoming network requests on an overloaded producer network
function (producer NF) [302], the system [300] comprising:
a transceiver unit [306], at a producer NF [302], the transceiver unit [306] configured to receive
a network request from a consumer network function (consumer NF) [304], wherein the network request is to establish a communication between the consumer NF [304] and the producer NF
a processing unit [308], at the producer NF [302], the processing unit [308] configured to process
the network request, wherein processing the network request comprises parsing the received network request on a network protocol level; and
determine one of an acceptance and a rejection, of the network request, based on the processing
of the network request and a status of the microservice.
11. The system [300] as claimed in claim 10, wherein, the parsing the received network request on
the network protocol level comprises reading a header of the network request.
12. The system [300] as claimed in claim 10, wherein the transceiver unit [306] is further configured
to:
transmit an acknowledgement to the consumer NF [304], based on one of the acceptance and the rejection of the network request. 35
13. The system [300] as claimed in claim 10, wherein the rejection, by the producer NF [302], of the
network request, is based on an overloaded status of the microservice.
26

14. The system [300] as claimed in claim 13, wherein, in an event of rejection of the network request,
the transceiver unit [306], is further configured to transmit an internal error response as a response
to the consumer NF [304].
15. The system [300] as claimed in claim 14, wherein the internal error response further comprises
an excessive load error message.
16. The system [300] as claimed in claim 10, wherein, the acceptance, by the producer NF [302], of
the network request, is based on a non-overloaded status of the microservice.
17. The system [300] as claimed in claim 16, wherein, in an event of acceptance of the network
request, the transceiver unit [306], is further configured to transmit an overload control
information (OCI) header information and a load control information (LCI) header information
as a response to the consumer NF [304].
18. The system [300] as claimed in claim 10, wherein the network request is a HTTP/2 network
request message.