FORM 2
THE PATENTS ACT, 1970 (39 of 1970) THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10; rule 13)
TITLE OF THE INVENTION
SYSTEM AND METHOD FOR DEBUGGING ISSUES ARISING DURING EXECUTION OF
COMMUNICATION REQUESTS
APPLICANT
JIO PLATFORMS LIMITED
of Office-101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad -
380006, Gujarat, India; Nationality : India
The following specification particularly describes
the invention and the manner in which
it is to be performed

RESERVATION OF RIGHTS
[001] 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 (herein after 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
[002] The present disclosure relates to wireless cellular communications,
and specifically to a system and a method for debugging real time issues encountered during execution of Hyper Text Transfer Protocol (HTTP/2) requests or Diameter requests by a Network Function (NF).
DEFINITION
[003] 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 to indicate otherwise.
[004] The term NF as used herein, refers to a Network Function that is a
functional element for policy control decision and flows-based charging control functionalities. The PCF provides functions such as, Policy rules for application and service data flow detection, gating, Quality of Service (QoS), and flow-based charging to Session Management Function (SMF).
BACKGROUND
[005] 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.
[006] Effective debugging techniques are crucial for ensuring smooth
operation of networks, especially in telecom networks. Debugging helps in identifying and resolving issues that may arise during network operations. With the use of debugging, engineers are always able to pinpoint anomalies, errors, and inefficiencies, thus facilitating targeted troubleshooting efforts.
[007] In modern telecommunication networks, particularly within 5G
environments, Network Functions (NFs) handle a high volume of HTTP/2 requests or Diameter requests. These requests are critical for proper functioning of various network services. However, debugging issues that arise during execution of these requests poses significant challenges to network operation teams. Currently available debugging mechanisms use counters, logs, and Extended Detection and Response (XDR) services for debugging an application. These debugging mechanisms may not debug the application in real time. Therefore, operation teams cannot analyze and resolve problems as they happen, leading to delays and inefficiencies. In addition, these debugging mechanisms encounter a record limit issue during debugging. This limitation hampers comprehensive analysis and timely resolution of issues.
[008] Also, the NFs generate a vast amount of data during request
processing. Collecting and analyzing this data in a cohesive manner is challenging when the traditional debugging mechanisms are used. Furthermore, a need for low-latency communication between the NFs and debugging tools is critical. Traditional methods lack in optimizing latency, resulting in delays in data transmission and processing. Furthermore, the traditional debugging mechanism also poses a threat to security of the network. Ensuring the secure transmission of debugging data is

essential to protect sensitive information and maintain the integrity of network operations.
[009] Thus, there is a need to provide an improved real-time debugging
solution that debugs and resolves issues present in the application at runtime.
OBJECTS OF THE PRESENT DISCLOSURE
[0010] Some of the objects of the present disclosure, which at least one
embodiment herein satisfies are as listed herein below.
[0011] It is an object of the present disclosure to provide a system and a
method for debugging real-time issues encountered during execution of Hyper Text Transfer Protocol (HTTP/2) requests or Diameter requests by a Network Function (NF).
[0012] It is an object of the present disclosure to provide a centralized server
data flow design that is dynamic to adapt to multiple kinds of procedures and call flows, as each procedure and call flow may or may not have different parameters which are part of a request/response.
[0013] It is an object of the present disclosure to enable each of NFs to write
data records (for example, clearcodes), which assist in quick troubleshooting.
[0014] It is an object of the present disclosure to provide HTTP/2 as a
standard interface between NF and a centralized server, in order to reduce latency by enabling full request and response multiplexing and minimize protocol overhead via efficient compression of HTTP/2 header fields.
[0015] It is an object of the present disclosure to facilitate an operations
team, i.e. users to gain enhanced capabilities for pinpointing and resolving issues encountered during crucial process of handling HTTP/2 requests or Diameter requests within NF.

[0016] It is an object of the present disclosure to provide a functionality of
throttling a rate at which Streaming Data Records (SDRs) are sent to a centralized server.
SUMMARY
[0017] In an exemplary embodiment, the present invention discloses a
method for debugging issues arising during execution of one or more communication requests. The method includes a step of recording one or more parameters associated with the corresponding one or more communication requests by a network function (NF) application. The method includes a step of processing the one or more communication requests for generating one or more responses of the corresponding one or more communication requests by the NF application, the one or more responses includes one of, error scenarios or success scenarios. The method includes a step of determining if the success scenarios of the corresponding one or more communication requests meet a predefined criteria based on the one or more recorded parameters when the one or more responses are determined to be the success scenarios. The method includes a step of transmitting the one or more communication requests along with one or more identifiers and Streaming Data Records (SDRs) associated with the one or more communication requests to a centralized server based on a predefined rate limit, when at least one of the success scenarios of the corresponding one or more communication requests meet the predefined criteria or when the one or more responses are determined to be the error scenarios.
[0018] In some embodiments, the one or more parameters are selected from
a list of a call flow name, context, a Uniform Resource Locator (URL), query parameters, timestamps, headers, or a combination thereof.
[0019] In some embodiments, the one or more communication requests are
selected from a list of a Hypertext transfer protocol (HTTP)/2 request or a diameter request.

[0020] In some embodiments, the one or more identifiers are selected from
a list of a Network Function name, a call flow name, a unique correlation identifier, or a combination thereof.
[0021] In some embodiments, the method includes a step of recording one
or more response parameters selected from a list of a clearcode, a response code, a response description, or a combination thereof.
[0022] In some embodiments, the predefined criteria includes a requirement
of the success scenarios to be enabled for a call flow name associated with the corresponding one or more communication requests in a predefined configuration.
[0023] In some embodiments, the Streaming Data Records (SDRs) are
selected from the one or more parameters associated with the corresponding one or more communication requests and one or more response parameters.
[0024] In another exemplary embodiment, the present invention discloses a
system for debugging issues arising during execution of one or more communication requests. The system includes a receiving unit configured to receive one or more communication requests at a network function (NF) application. The system further includes a processing unit. The processing unit is configured to: record one or more parameters associated with the corresponding one or more communication requests by the network function (NF) application. The processing unit is configured to: process the one or more communication requests for generating one or more responses of the corresponding one or more communication requests by the NF application, wherein the one or more responses comprises one of, error scenarios or success scenarios. The processing unit is further configured to: determine if the success scenarios of the corresponding one or more communication requests meet a predefined criteria based on the one or more recorded parameters when the one or more responses are determined to be the

success scenarios. The processing unit is further configured to transmit the one or more communication requests along with one or more identifiers and Streaming Data Records (SDRs) associated with the one or more communication requests to a centralized server based on a predefined rate limit, when at least one of the success scenarios of the corresponding one or more communication requests meet the predefined criteria or when the one or more responses are determined to be the error scenarios.
[0025] In some embodiments, the one or more parameters are selected from
a list of a call flow name, context, a Uniform Resource Locator (URL), query parameters, timestamps, headers, or a combination thereof.
[0026] In some embodiments, the one or more communication requests are
selected from a list of a Hypertext transfer protocol (HTTP)/2 request or a diameter request.
[0027] In some embodiments, the one or more identifiers are selected from
a list of a Network Function name, a call flow name, a unique correlation identifier, or a combination thereof.
[0028] In some embodiments, the method includes a step of recording one
or more response parameters selected from a list of a clearcode, a response code, a response description, or a combination thereof.
[0029] In some embodiments, the predefined criteria includes a requirement
of the success scenarios to be enabled for a call flow name associated with the corresponding one or more communication requests in a predefined configuration.
[0030] In some embodiments, the Streaming Data Records (SDRs) are
selected from the one or more parameters associated with the corresponding one or more communication requests and one or more response parameters.

[0031] In an exemplary embodiment, the present invention discloses a user
equipment communicatively coupled with a network. The coupling includes steps of. receiving, by the network, a connection request from the user equipment (UE); sending, by the network, an acknowledgment of the connection request to the user equipment (UE); and transmitting a plurality of signals in response to the connection request. The network is configured for performing a method for debugging issues arising during execution of one or more communication requests. The method includes a step of recording one or more parameters associated with the corresponding one or more communication requests by a network function (NF) application. The method includes a step of processing the one or more communication requests for generating one or more responses of the corresponding one or more communication requests by the NF application, the one or more responses includes one of, error scenarios or success scenarios. The method includes a step of determining if the success scenarios of the corresponding one or more communication requests meet a predefined criteria based on the one or more recorded parameters when the one or more responses are determined to be the success scenarios. The method includes a step of transmitting the one or more communication requests along with one or more identifiers and Streaming Data Records (SDRs) associated with the one or more communication requests to a centralized server based on a predefined rate limit, when at least one of the success scenarios of the corresponding one or more communication requests meet the predefined criteria or when the one or more responses are determined to be the error scenarios.
BRIEF DESCRIPTION OF THE DRAWINGS
[0032] In the figures, similar components and/or features may have the
same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the

specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
[0033] The diagrams are for illustration only, which thus is not a limitation
5 of the present disclosure, and wherein:
[0034] FIG. 1A illustrates an exemplary network architecture in which or
with which embodiments of the present disclosure may be implemented;
10 [0035] FIG. 1B illustrates an exemplary block diagram of a system, in
accordance with an embodiment of the present disclosure;
[0036] FIG. 1C illustrates an exemplary block diagram of an interaction
system enabling interaction between various components involved in a debugging 15 process, in accordance with an embodiment of the disclosure;
[0037] FIG. 1D illustrates an exemplary architecture for debugging issues
encountered during execution of one or more communication requests with a
centralized server, in accordance with an embodiment of the present disclosure;
20
[0038] FIG. 2 illustrates an exemplary flowchart of a process for
transmission of streaming data records to a centralized server via communication
requests, in accordance with an embodiment of the present disclosure;
25 [0039] FIG. 3 illustrates an exemplary computer system in which or with
which embodiments of the present disclosure may be implemented; and
[0040] FIG. 4 illustrates a flowchart of a method for debugging issues
encountered during execution of one or more communication requests, in 30 accordance with an embodiment of present disclosure.
LIST OF REFERENCE NUMERALS 100 – Network architecture
9

102-1, 102-2…102-N – User Equipment
104-1, 104-2…104-N – Users
106 – System
108 – Network 5 110 – Receiving Unit
112 – Memory
114 – Interfacing Unit
116 – Processing Unit
118 – Centralized Server 10 120 – Database
122 – Data Recording Module
124 – Response Generation Module
126 – Analysis Module
128 – Communication Module 15 130 – Interaction System
132 – Network Function (NF) Application
134 – Architecture
136-1, 136-2, 136-3... 136-N – Super Core Regions
138-1, 138-2, 138-3…138-N – Multi-access Edge Computing (MEC) Sites 20 140 – Network Management Platform
200 – Process
300 – Computer system
310 – External storage device
320 – Bus 25 330 – Main memory
340 – Read only memory
350 – Mass storage device
360 – Communication port(s)
370 – Processor 30 400 – Method
10

DETAILED DESCRIPTION
[0041] In the following description, for the purposes of explanation, various
specific details are set forth in order to provide a thorough understanding of 5 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 all of the problems discussed above or might address only some of the 10 problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0042] The ensuing description provides exemplary embodiments only, and
is not intended to limit the scope, applicability, or configuration of the disclosure.
15 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.
20
[0043] 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
25 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.
30 [0044] 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 a flowchart may describe the
11

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 5 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.
[0045] The word “exemplary” and/or “demonstrative” is used herein to
10 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
15 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—in a manner
similar to the term “comprising” as an open transition word—without precluding
any additional or other elements.
20
[0046] 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
25 phrases “in one embodiment” or “in an embodiment” or “in some embodiments” 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.
30
[0047] The terminology used herein is for the purpose of describing
particular embodiments only and is not intended to be limiting of the disclosure. As
12

used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly 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, 5 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 and all combinations of one or more of the associated listed items.
10 [0048] The disclosed system and method facilitate to provide valuable
assistance to an operations team, to effectively debug issues encountered during execution of communication requests within a Network Function (NF). The system may send Streaming Data Records (SDRs) to a centralized server equipped with a capability to collect probing data from various Fifth Generation (5G) network
15 nodes. The SDRs may serve as concise summaries of procedures occurring within a 5G core network, such as, but not limited to, a timestamp of request and response, Uniform Resource Locator (URL), context, query parameter, headers, request and response body parameters, a call flow name, and the like.
20 [0049] Further, the disclosed system and method facilitate seamless
integration of components for data collection, indexing, and visualization of results in a streamlined and efficient debugging workflow, contributing to an overall effectiveness and performance of the operations team.
25 [0050] Various embodiments of the present disclosure will be explained in
detail with reference to FIGs. 1 to 4.
[0051] FIG. 1A illustrates an exemplary network architecture (100) in
which or with which embodiments of the present disclosure may be implemented.
30
[0052] Referring to the FIG. 1A, the network architecture (100) may include
one or more computing devices or one or more user equipment (102-1, 102-2…102-
13

N) that may be associated with one or more users (104-1, 104-2…104-N) and a system (106) in an environment. In an embodiment, the one or more user equipment (102-1, 102-2…102-N) may be communicated to the system (106) through a network (108). A person of ordinary skill in the art will understand that the one or 5 more user equipment (102-1, 102-2…102-N) may be individually referred to as the user equipment (102) and collectively referred to as the user equipment (102). A person of ordinary skill in the art will appreciate that the terms “computing device(s)” and “user equipment” may be used interchangeably throughout the disclosure. Although three user equipment (102) are depicted in the FIG. 1A,
10 however any number of the user equipment (102) may be included without departing from the scope of the ongoing description. Similarly. A person of ordinary skill in the art will understand that the one or more users (104-1, 104-2…104-N) may be individually referred to as the user (104) and collectively referred to as the users (104).
15
[0053] In an embodiment, the user equipment (102) may include smart
devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the user equipment (102) may include, but not limited to, smart phones, smart watches, smart sensors (e.g., mechanical, thermal,
20 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, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users (104) and/or entities, or any
25 combination thereof. A person of ordinary skill in the art will appreciate that the user equipment (102) may include, but not limited to, intelligent multi-sensing, network-connected devices, that can integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
30
14

[0054] In an embodiment, the user equipment (102) may include, but not
limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch 5 computer device, and so on), a Global Positioning System (GPS) device, a laptop, 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.
10 [0055] In an embodiment, the user equipment (102) may include, but is not
limited to, any electrical, electronic, electro-mechanical, or an equipment, or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, a general-purpose computer, a desktop, a personal digital assistant, a mainframe computer, or any other computing device. In
15 another embodiment, the user equipment (102) 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 (104) or the entity such as a touch pad, a touch enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate
20 that the user equipment (102) may not be restricted to the mentioned devices and various other devices may be used.
[0056] In an embodiment, the user equipment (102) may involve collection,
analysis, and sharing of data received from the system (106) via the network (108). 25 In an embodiment, the user equipment (102) may transmit at least one captured data packet over a point-to-point communication channel, a point-to-multipoint communication channel or the network (108) to the system (106).
[0057] Referring to the FIG. 1A, the user equipment (102) may
30 communicate with the system (106) via a set of executable instructions residing on
any operating system. The system (106) may be for example, the system (106) for
debugging issues encountered during execution of communication requests by a
15

Network Function (NF) application (132) (As shown in FIG. 1C). In an exemplary
embodiment, the NF application (132) may be, but not limited to, Session
Management Function (SMF), Policy Control Function (PCF), Policy and Charging
Rule Function (PCRF), Charging Function (CHF) (204), and so forth.
5 Embodiments of the present invention are intended to include or otherwise cover
any type of the NF application (132) including known related art and/or later
developed NF applications. In an exemplary embodiment, the communication
requests may be, but not limited to, Hypertext Transfer Protocol (HTTP/2) requests,
Diameter Requests, and so forth.
10
[0058] In an embodiment, the users (104) may interact with their respective
user equipment (102) to perform actions that generate the communication requests
and transmitted through the network (108) to the system (106). The system (106)
may process the incoming communication requests and captures relevant
15 parameters such as, but not limited to, timestamps, URLs, headers, and request/response body parameters, a call flow name, query parameters, context and so forth. In an embodiment, the request/response body parameters may be decided based on the call flow name. The system (106) then identifies and differentiates between successful and erroneous requests, initiating appropriate debugging
20 processes. The system (106) may further allow the NF application (132) to interact with a centralized server (118) (as shown in FIG. 1B) via HTTP/2 interface for transmitting the communication requests containing debugging data to the centralized server (118). The debugging data includes both error scenarios and few success scenarios such that the success scenarios may depend on a predefined
25 configuration.
[0059] In an embodiment, the network (108) may include, at least one of a
4G network, 5G network, 6G network, or the like. The network (108) may be having one or more nodes that transmit, receive, forward, generate, buffer, store, 30 route, switch or process one or more messages, packets, signals, waves, voltage or current levels. The network (108) may enable the user equipment (102) to
16

communicate with other devices in the network architecture (100) and/or with the system (106). The network (108) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (108) may be implemented as, or include any of a variety of different 5 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, a Public Switched Telephone Network (PSTN), or the like.
[0060] Although the FIG. 1A shows exemplary components of the network
10 architecture (100); however, in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in the FIG. 1A. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other 15 components of the network architecture (100).
[0061] FIG. 1B illustrates an exemplary block diagram of the system (106),
in accordance with an embodiment of the present disclosure.
20 [0062] In an embodiment, the system (106) may include a receiving unit
(110), a memory (112), an interfacing unit (114), a processing unit (116), a centralized server (118) and a database (120). In an embodiment, the processing unit (116) may include a data recording module (122), a response generation module (124), an analysis module (126) and a communication module (128).
25
[0063] In an embodiment, the receiving unit (110) may be configured to
receive the communication requests of call flow scenarios at the NF application (132) (as shown in the FIG. 1C). In an exemplary embodiment, the NF application (132) may receive the communication requests from neighbouring nodes. The
30 neighbouring nodes may be other elements or entities that may interact with the NF application (132). In an aspect, the neighbouring nodes may be physical devices or logical entities that may send and receive the communication requests. In an
17

exemplary embodiment, the neighbouring nodes may be, but not limited to, other network functions, base stations, user devices, gateways, and so forth.
[0064] The memory (112) may be configured to store computer-readable
5 instructions or routines in a non-transitory computer readable storage medium. In an aspect, the memory (112) may be configured to store program instructions that may be executed to perform tasks associated with the system (106). The memory (112) may include any non-transitory storage device including, for example, but not limited to, a volatile memory such as a Random-Access Memory (RAM), or a non-10 volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like. Embodiments of the present invention are intended to include or otherwise type of the memory (112) including known related art and/or later developed technologies.
15 [0065] In an embodiment, the interfacing unit (114) may comprise a variety
of interfaces, for example, interfaces for data input and output devices (I/O), storage
devices, and the like. The interfacing unit (114) may facilitate communication
through the system (106). The interfacing unit (114) may also provide a
communication pathway for various other units/modules of the system (106).
20
[0066] In an embodiment, the centralized server (118) may receive, store,
and index the debugging data or Streaming Data Records (SDR). The centralized
server (118) is equipped with indexing and visualization tools to facilitate real-time
analysis. The centralized server (118) may handle large volume of data and
25 providing real-time insights for troubleshooting. In an exemplary embodiment, the
centralized server (118) may be a probing agent (e.g. Virtual Probe) that collects
the debugging data from network nodes.
[0067] In an embodiment, the database (120) may interact with the
30 centralized server (118) and may offer functionality to manage, capture, storage,
and retrieval of the data. In an embodiment, the database (120) is configured for
serving as a centralized repository for storing the error scenarios and the success
18

scenarios along with the parameters received in the communication requests. In other words, the database (120) may store output as part of the debugging records of the NF application (132) that may be retrieved whenever there is a need to refer the output in future. The database (120) is designed to interact seamlessly with other 5 components of the system (106), such as the data recording module (122), the response generation module (124), the analysis module (126) and the communication module (128), to support a functionality of the system (106) effectively. The database (120) may store the data that may be either stored or generated as a result of functionalities implemented by any of the components of 10 the processing unit (116). In an embodiment, the database (120) may be separate from the system (106).
[0068] The modules are controlled by the processing unit (116) which
execute the computer-readable instructions retrieved from the memory (112). The
15 processing unit (116) further interact with the interfacing unit (114) to facilitate a user interaction and to provide options for managing and configuring the system (106). The processing unit (116) 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
20 on operational instructions.
[0069] In an embodiment, the data recording module (122) may be
configured to record the parameters associated with the communication requests of the call flow scenarios by the NF application (132). The data recording module 25 (122) may be configured to transmit the communication requests and the recorded parameters to the response generation module (124).
[0070] The response generation module (124) may be configured to process
the communication requests for generating one or more responses by the NF 30 application (132). The responses may be one of, the success scenarios or the error scenarios. In an exemplary embodiment, the response generation module (124) may be configured to record one or more response parameters upon processing the
19

communication requests. In an embodiment, the response parameters may be, but not limited to, a clearcode, a response code, a response description, and so forth.
[0071] In an exemplary embodiment, the clearcode may be a specific code
5 that may indicate the responses of the processed communication requests. The clearcode may not be directly exposed to external users (104) (as shown in the FIG. 1A). The clearcode may be used internally to manage the responses of the processed communication requests.
10 [0072] Similarly, the response code may be a standard status code indicating
the responses of the processed communication requests. The response code may be used to inform the users (104) about a status of the communication request. For example, in case of success, the response code may be “200” for HTTP/2 requests indicating the success scenario and in case of error, the response code may be a
15 different code indicating the error scenario.
[0073] Further, the response description may be a human readable
description of the response code, providing more detailed information about the response of the processed communication requests. For example, for 404 response 20 code, the response description may be “not found”.
[0074] Based on the response parameters, the response generation module
(124) may be configured to generate the responses of the corresponding communication requests.
25
[0075] The response generation module (124) may be configured to
determine whether the responses of the processed communication requests include the error scenarios or the success scenarios. In an aspect, the response may be considered as the success scenarios when the communication requests are processed
30 correctly and meets expected outcome as specified by the parameters associated with the corresponding communication requests. In an exemplary embodiment, the response generation module (124) may be configured to determine if the
20

communication request is processed correctly or not based on a valid response code that may be included in the responses of the communication requests. In another aspect, the response may be considered as the error scenarios when the response includes an error response code or an error message. The error response code is 5 generated when the communication requests are not processed successfully due to some errors. The errors may be, but not limited to, invalid parameters, request timeout, service unavailable, and so forth.
[0076] The response generation module (124) may be configured to
10 generate a success condition processing signal when the responses of the corresponding processed communication requests is determined to be the success scenarios. The response generation module (124) may be configured to transmit the generated success condition processing signal to the analysis module (126). In another embodiment, the response generation module (124) may be configured to
15 transmit the error scenarios to the communication module (128) when the responses of the corresponding processed communication requests are determined to be the error scenarios. In an example, the response generation module (124) may be configured to execute a vProbe sending thread for transmitting the error scenarios to the centralized server (118).
20
[0077] In an embodiment, the analysis module (126) may be configured to
determine if the success scenarios of the communication requests meet a predefined criteria based on the received success condition processing signal. The analysis module (126) may be configured to determine if the success scenarios of the
25 communication requests meet a predefined criteria based on the recorded parameters. The predefined criteria may include a requirement of the success scenarios to be enabled for the call flow name that may be associated with the corresponding communication requests in the predefined configuration. The analysis module (126) may be configured to transmit the success scenarios that
30 meets the predefined criteria to the communication module (128). In an example,
21

the analysis module (126) may be configured to execute a vProbe convertor thread for transmitting the success scenarios to the centralized server (118).
[0078] The communication module (128) may be configured to process the
5 communication requests based on at least one of, the error scenarios, the success scenarios or a combination thereof. The communication module (128) may be configured to transmit the processed communication requests as HTTP/2 requests along with one or more identifiers to the centralized server (118). In an exemplary embodiment, the identifiers may be, but not limited to, a Network Function name, 10 the call flow name, a unique correlation identifier, and so forth.
[0079] In an embodiment of the present invention, the communication
module (128) may be configured to transmit the communication requests along with the debugging data or the SDRs to the centralized server (118) based on a 15 predefined rate limit. The SDRs may include, but not limited to, the recorded parameters of the corresponding communication requests and the response parameters. The recorded parameters of the communication requests may be, but not limited to, the timestamps, the URLs, the headers, the request/response body parameters, the call flow name, the query parameters, the context and so forth. 20 Further, the response parameters may be, but not limited to, the clearcode, the response code, the response description, and so forth. In an embodiment, the SDRs may serve as concise summaries of procedures occurring within a 5G core network. The summaries may include information about the success scenarios or the error scenarios that may be transmitted to the centralized server (118), allowing for real-25 time monitoring and analysis of network performance and behavior.
[0080] As used herein, the term “predefined rate limit” may be a rate at
which the error scenarios or the success scenarios are transmitted to the centralized server (118), ensuring efficient and controlled data transmission. In an exemplary 30 embodiment, a job schedular such as, a quartz scheduler may be utilized to manage the predefined rate limit.
22

[0081] Although the FIG. 1B shows an exemplary block diagram of the
system (106); however, in other embodiments, the system (106) may include fewer components, different components, differently arranged components, or additional functional components than depicted in the FIG. 1B. Additionally, or alternatively, 5 one or more components of the system (106) may perform functions described as being performed by one or more other components of the system (106).
[0082] FIG. 1C illustrates an exemplary block diagram of an interaction
system (130) for enabling an interaction between various components involved in 10 a debugging process, in accordance with an embodiment of the disclosure.
[0083] As illustrated, the interaction system (130) may comprise the NF
application (132) that may include logic for handling various types of network functions and generating the responses based on the incoming communication
15 requests. In an exemplary embodiment, the NF application (132) may process the HTTP/2 requests or the Diameter requests. The NF application (132) may interact with the centralized server (118) through the HTTP/2 interface for transmitting the processed communication requests to the centralized server (118). The HTTP/2 interface may enable full request and response multiplexing and may minimize
20 protocol overhead via efficient compression of HTTP/2 header fields. For security purpose, the HTTP/2 interface may also utilize encryption protocols to secure data transmission.
[0084] FIG. 1D illustrates an exemplary architecture (134) for debugging
25 issues encountered during execution of the communication request with the centralized server (118), in accordance with an embodiment of the present disclosure.
[0085] The architecture (134) spans multiple super core regions (136-1,
30 136-2, 136-3... 136-N) (hereinafter collectively referred to as the super core regions
(136) and individually referred to as the super core regions (136)), each including
cloud-native network functions (NFs) (132-1, 132-2, 132-3…132-N) (hereinafter
23

collectively referred to as the network functions (132) and individually referred to as the network functions (132)) and multi-access edge computing (MEC) sites (138-1, 138-2, 138-3…138-N) (hereinafter collectively referred to as the MEC sites (138) and individually referred to as the MEC sites (138)), which are integrated and 5 managed by the centralized server (118) including the database (120) (as shown in the FIG. 1B).
[0086] In an exemplary embodiment, four super core regions (west, east,
north, and south) (136) are shown, however, it may be appreciated that there may 10 exist any number of super core regions (136). The super core regions (136) are geographically distributed to ensure wide coverage and low latency for network services.
[0087] The network functions (132) may include 5G NFs and 4G NFs. The
15 5G NFs may be specifically designed for 5G networks, leveraging cloud-native principles for scalability and flexibility. The 4G NFs may be designed for 4G networks, also leveraging cloud-native architecture for improved performance and manageability.
20 [0088] The MEC sites (138) form edge computing infrastructure that brings
computation and data storage closer to a location where it is needed, improving
response times and saving bandwidth. The MEC sites (138) support both the 4G
and 5G network functions (132), enabling efficient handling of the data and services
at the network edge.
25
[0089] Further, the centralized server (118) such as, the Virtual probes
(vProbes) may be deployed across the network (108) (as shown in the FIG. 1A) to
capture and analyze real-time traffic data. The centralized server (118) may collect
the data from various network functions (132) and the MEC sites (138), providing
30 insights into network performance and issues.
[0090] Further, the architecture (134) may include a network management
platform (140) that may be implemented as a centralized platform responsible for
24

aggregating, processing, and analyzing the incoming traffic data from the centralized server (118). The network management platform (140) may understand the context of the data being processed, allowing for more accurate analysis. Further, the network management platform (140) operates entirely through 5 software, ensuring flexibility and scalability. Also, the network management platform (140) may seamlessly be integrated with various network components to provide comprehensive monitoring and debugging capabilities. The flow of data collected by the centralized server (118) from the different network functions (132) and the MEC sites (138) is sent to the network management platform (140) to 10 centralize the debugging process and provide real-time insights into network performance issues. The analysis techniques employed at the network management platform (140) may involve machine learning algorithms, anomaly detection, and real-time visualization tools.
15 [0091] Therefore, the architecture (134) of the FIG. 1D helps to
continuously monitor the network performance, providing real-time feedback to network operators. It further enables proactive identification and resolution of potential issues before they impact end-users.
20 [0092] FIG. 2 illustrates an exemplary flowchart of a process (200) of
transmission of data records to the centralized server (118) via the communication requests, in accordance with an embodiment of the present disclosure.
[0093] As illustrated, at step (202), the NF application (132) may record the
25 parameters of the communication request, for example, the context, the URL, the query parameters, etc., and the timestamp after receiving the communication request. This step may ensure that all the relevant parameters are captured for subsequent analysis.
30 [0094] At step (204), after processing of the request, the NF application
(132) may record the response parameters including the clearcode, the response code and the response description. This step may include evaluating the
25

communication request and determining the appropriate response based on a predefined logic.
[0095] At step (206), the NF application (132) accesses the call flow
5 scenario based on the determined response. If the response indicates a presence of the success scenario, then the process (200) may proceed to a step (208) and if the response indicates a presence of the error scenario, then the process (200) may proceed to a step (212). In an aspect, the response may be considered as the success scenario when the communication request is processed correctly and meets
10 expected outcome as specified by the parameters associated with the communication request. In an exemplary embodiment, the process (200) may determine if the communication request is processed correctly or not based on a valid response code that is included in the response. In another aspect, the response may be considered as the error scenario when the response includes an error
15 response code or an error message. The error response code is generated when the communication request is not processed successfully due to some errors. The errors may be, but not limited to, invalid parameters, request timeout, service unavailable, and so forth.
20 [0096] At the step (208), the NF application (132) may check whether the
success scenarios for the particular call flow name is enabled or not. If the call flow name is enabled, then the NF application (132) may further proceed to the step (212). Otherwise, the process (200) may proceed to a step (210).
25 [0097] At the step (210), the NF application (132) may ignore the success
scenarios and ends a flow of the process (200).
[0098] At the step (212), the communication request as the HTTP/2 request
may be processed for communicating with the centralized server (118)
30
[0099] At step (214), the communication request may be transmitted to the
centralized server (118) based on the predefined rate limit.
26

[00100] FIG. 3 illustrates an exemplary computer system (300) in which or
with which embodiments of the present disclosure may be implemented. As shown 5 in the FIG. 3, the computer system (300) may include an external storage device (310), a bus (320), a main memory (330), a read only memory (340), a mass storage device (350), a communication port (360), and a processor (370). A person skilled in the art will appreciate that the computer system (300) may include more than one processor (370) and the communication ports (360). The processor (370) may 10 include various modules associated with embodiments of the present disclosure.
[00101] In an embodiment, the external storage device (310) may be any
device that is commonly known in the art such as, but not limited to, a memory
card, a memory stick, a solid-state drive, a hard disk drive (HDD), and so forth.
15
[00102] In an embodiment, the bus (320) may be communicatively coupled
with the processor(s) (370) with the other memory, storage, and communication
blocks. The bus (320) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI
Extended (PCI-X) bus, a Small Computer System Interface (SCSI), a Universal
20 Serial Bus (USB) or the like, for connecting expansion cards, drives and other
subsystems as well as other buses, such a front side bus (FSB), which connects the
processor (370) to the computer system (300).
[00103] In an embodiment, the main memory (330) may be a Random Access
25 Memory (RAM), or any other dynamic storage device commonly known in the art.
The Read-only memory (340) 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 (370).
30
[00104] In an embodiment, the mass storage device (350) 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, a
27

Parallel Advanced Technology Attachment (PATA) or a 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., 5 an array of disks (e.g., SATA arrays).
[00105] Further, the communication port (360) 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 fiber, a serial port, a parallel port, or other 10 existing or future ports. The communication port (360) may be chosen depending on the network (108), such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (300) connects.
[00106] Optionally, operator and administrative interfaces, e.g., a display, a
15 keyboard, a joystick, and a cursor control device, may also be coupled to the bus (320) to support a direct operator interaction with the computer system (300). Other operator and administrative interfaces may be provided through network connections connected through the communication port (360). Components described above are meant only to exemplify various possibilities. In no way should 20 the aforementioned exemplary computer system (300) limit the scope of the present disclosure.
[00107] FIG. 4 illustrates a flowchart of a method (400) for debugging issues
encountered during execution of one or more communication requests, in 25 accordance with an embodiment of present disclosure.
[00108] Step (402) includes a step of recording one or more parameters
associated with the corresponding one or more communication requests by a
network function (NF) application (132).
30
[00109] Step (404) includes a step of processing the one or more
communication requests for generating one or more responses of the corresponding
28

one or more communication requests by the NF application (132), wherein the one or more responses comprises one of, error scenarios or success scenarios.
[00110] Step (406) includes a step of determining if the success scenarios of
5 the corresponding one or more communication requests meet a predefined criteria based on the one or more recorded parameters when the one or more responses are determined to be the success scenarios.
[00111] Step (408) includes a step of transmitting the one or more
10 communication requests along with one or more identifiers and Streaming Data
Records (SDRs) to a centralized server (118) based on a predefined rate limit, when
at least one of the success scenarios of the corresponding one or more
communication requests meet the predefined criteria or when the one or more
responses are determined to be the error scenarios.
15
[00112] In an embodiment, the one or more parameters are selected from a
list of a call flow name, context, a Uniform Resource Locator (URL), query
parameters, timestamps, headers, or a combination thereof.
20 [00113] In some embodiments, the one or more communication requests are
selected from a list of a Hypertext transfer protocol (HTTP/2) request or a diameter request.
[00114] In some embodiments, the one or more identifiers are selected from
25 a list of a Network Function name, a call flow name, a unique correlation identifier, or a combination thereof.
[00115] In some embodiments, the method (400) includes a step of recording
one or more response parameters selected from a list of a clearcode, a response 30 code, a response description, or a combination thereof.
29

[00116] In some embodiments, the predefined criteria includes a requirement
of the success scenarios to be enabled for a call flow name associated with the corresponding one or more communication requests in a predefined configuration.
5 [00117] In some embodiments, the Streaming Data Records (SDRs) are
selected from the one or more parameters associated with the corresponding one or more communication requests and one or more response parameters.
[00118] In an embodiment, the present disclosure discloses a user equipment
10 (UE) communicatively coupled with a network. The coupling including a step of receiving, by the network, a connection request from the user equipment (UE). The coupling including a step of sending, by the network, an acknowledgment of the connection request to the UE. The coupling including a step of transmitting a plurality of signals in response to the connection request. The network is configured 15 for implementing the method for debugging issues arising during execution of one or more communication requests.
[00119] The present disclosure provides a technical advancement in the field
of network function operations and management. This advancement addresses
20 limitations of existing solutions by enabling real-time debugging through generation and analysis of Streaming Data Records (SDRs). The inventive aspects include seamless integration of data collection, indexing, and visualization components, which offer significant improvements in performance and operational efficiency. By implementing this invention, network function applications can
25 capture and process request and response parameters, determine success and error scenarios based on predefined criteria, and transmit HTTP/2 requests containing the SDRs to a centralized server for analysis. This results in enhanced troubleshooting capabilities, reduced downtime, and improved overall network reliability, thereby achieving a desired outcome of efficient network management.
30
[00120] While the foregoing describes various embodiments of the present
disclosure, other and further embodiments of the present disclosure may be devised
30

without departing from the basic scope thereof. The scope of the present disclosure is determined by the claims that follow. The present disclosure is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the present disclosure when combined with information and knowledge available to the person having ordinary skill in the art.
[00121] 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
[00122] The present disclosure provides a system and a method for
debugging real-time issues encountered during execution of Hyper Text Transfer Protocol (HTTP/2) requests or Diameter requests by a Network Function (NF).
[00123] The present invention provides a centralized server data flow design
that is dynamic to adapt to multiple kinds of procedures and call flows, as each procedure and call flow may or may not have different parameters which are part of a request/response.
[00124] The present invention enables each of NFs to write data records (for
example, clearcodes), which assist in quick troubleshooting.
[00125] The present invention provides HTTP/2 as a standard interface
between NF and a centralized server, in order to reduce latency by enabling full

request and response multiplexing and minimize protocol overhead via efficient compression of HTTP/2 header fields.
[00126] The present invention facilitates an operations team, i.e. users to gain
enhanced capabilities for pinpointing and resolving issues encountered during crucial process of handling HTTP/2 requests or Diameter requests within NF.
[00127] The present invention provides a functionality of throttling a rate at
which data records are sent to a centralized server.

We Claim:
1. A method (400) for debugging issues arising during execution of one or more
communication requests, the method (400) comprising steps of:
recording one or more parameters associated with the corresponding one or more communication requests by a network function (NF) application (132);
processing the one or more communication requests for generating one or more responses of the corresponding one or more communication requests by the NF application (132), wherein the one or more responses comprises one of, error scenarios or success scenarios;
determining if the success scenarios of the corresponding one or more communication requests meet a predefined criteria based on the one or more recorded parameters when the one or more responses are determined to be the success scenarios; and
transmitting the one or more communication requests along with one or more identifiers and Streaming Data Records (SDRs) associated with the one or more communication requests to a centralized server (118) based on a predefined rate limit, when at least one of the success scenarios of the corresponding one or more communication requests meet the predefined criteria or when the one or more responses are determined to be the error scenarios.
2. The method (400) as claimed in claim 1, wherein the one or more parameters
are selected from a list of a call flow name, context, a Uniform Resource
Locator (URL), query parameters, timestamps, headers, or a combination
thereof.

3. The method (400) as claimed in claim 1, wherein the one or more communication requests are selected from a list of a Hypertext transfer protocol (HTTP)/2 request or a diameter request.
4. The method (400) as claimed in claim 1, wherein the one or more identifiers are selected from a list of a Network Function name, a call flow name, a unique correlation identifier, or a combination thereof.
5. The method (400) as claimed in claim 1, comprising a step of recording one or more response parameters selected from a list of a clearcode, a response code, a response description, or a combination thereof.
6. The method (400) as claimed in claim 1, wherein the predefined criteria comprises a requirement of the success scenarios to be enabled for a call flow name associated with the corresponding one or more communication requests in a predefined configuration.
7. The method (400) as claimed in claim 1, wherein the Streaming Data Records (SDRs) are selected from the one or more parameters associated with the corresponding one or more communication requests and one or more response parameters.
8. A system (106) for debugging issues arising during execution of one or more communication requests, wherein the system (106) comprising:
a receiving unit (110) configured to receive one or more communication requests at a network function (NF) application (132); a processing unit (116) configured to:
record one or more parameters associated with the corresponding one or more communication requests by the network function (NF) application (132);
process the one or more communication requests for generating one or more responses of the corresponding one or more communication requests by the NF application (132), wherein the

one or more responses comprises one of, error scenarios or success scenarios;
determine if the success scenarios of the corresponding one or more communication requests meet a predefined criteria based on the one or more recorded parameters when the one or more responses are determined to be the success scenarios; and
transmit the one or more communication requests along with one or more identifiers and Streaming Data Records (SDRs) associated with the one or more communication requests to a centralized server (118) based on a predefined rate limit, when at least one of the success scenarios of the corresponding one or more communication requests meet the predefined criteria or when the one or more responses are determined to be the error scenarios.
9. The system (106) as claimed in claim 8, wherein the one or more parameters are selected from a list of a call flow name, context, a Uniform Resource Locator (URL), query parameters, timestamps, headers, or a combination thereof.
10. The system (106) as claimed in claim 8, wherein the one or more communication requests are selected from a list of a Hypertext transfer protocol (HTTP)/2 request or a diameter request.
11. The system (106) as claimed in claim 8, wherein the one or more identifiers are selected from a list of a Network Function name, a call flow name, a unique correlation identifier, or a combination thereof.
12. The system (106) as claimed in claim 8, wherein the processing unit (116) is configured to record one or more response parameters selected from a list of a clearcode, a response code, a response description, or a combination thereof.

13. The system (106) as claimed in claim 8, wherein the predefined criteria comprises a requirement of the success scenarios to be enabled for a call flow name associated with the corresponding one or more communication requests in a predefined configuration.
14. The system (106) as claimed in claim 8, wherein the Streaming Data Records (SDRs) are selected from the one or more parameters associated with the corresponding one or more communication requests and one or more response parameters.
15. A user equipment (102) communicatively coupled with a network (108), the coupling comprises steps of:
receiving, by the network (108), a connection request from the user equipment (UE) (102);
sending, by the network (108), an acknowledgment of the connection request to the UE (102); and
transmitting a plurality of signals in response to the connection request, wherein the network (108) is configured for performing a method (400) for debugging issues arising during execution of one or more communication requests as claimed in claim