System and method for debugging issues arising during execution of communication requests
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- JIO PLATFORMS LTD
- Filing Date
- 2024-07-12
- Publication Date
- 2026-05-27
AI Technical Summary
Current debugging mechanisms for network functions (NFs) in telecom networks, particularly in 5G environments, face challenges in real-time debugging of HTTP/2 and Diameter requests, leading to delays and inefficiencies due to limitations in data collection, analysis, and latency optimization, as well as security concerns.
A system and method that record parameters associated with communication requests, process these requests to generate responses, and transmit them along with identifiers and Streaming Data Records (SDRs) to a centralized server based on a predefined rate limit, enabling real-time debugging and analysis.
This solution enables real-time debugging and resolution of issues during the execution of communication requests, reducing downtime and improving network reliability by facilitating efficient data transmission and analysis.
Smart Images

Figure IN2024051187_23012025_PF_FP_ABST
Abstract
Description
SYSTEM AND METHOD FOR DEBUGGING ISSUES ARISING DURING EXECUTION OF COMMUNICATION REQUESTSRESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, integrated circuit (IC) layout design, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (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
[0002] 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
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] 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
[0005] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section mayinclude 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.
[0006] 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.
[0007] 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.
[0008] 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 isessential to protect sensitive information and maintain the integrity of network operations.
[0009] 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 thesuccess 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.
[0032] In an exemplary embodiment, the present invention discloses a computer program product comprising a non-transitory computer-readable medium including instructions that, when executed by one or more processors, cause the one or more processors to perform 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 morecommunication 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
[0033] 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.
[0034] The diagrams are for illustration only, which thus is not a limitation of the present disclosure, and wherein:
[0035] FIG. 1A illustrates an exemplary network architecture in which or with which embodiments of the present disclosure may be implemented;
[0036] FIG. IB illustrates an exemplary block diagram of a system, in accordance with an embodiment of the present disclosure;
[0037] FIG. 1C illustrates an exemplary block diagram of an interaction system enabling interaction between various components involved in a debugging process, in accordance with an embodiment of the disclosure;
[0038] FIG. ID 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;
[0039] 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;
[0040] FIG. 3 illustrates an exemplary computer system in which or with which embodiments of the present disclosure may be implemented; and
[0041] FIG. 4 illustrates a flowchart of a method for debugging issues encountered during execution of one or more communication requests, in accordance with an embodiment of present disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture102-1, 102-2. . . 102-N - User Equipment104-1, 104-2...104-N - Users106 - System108 - Network110 - Receiving Unit112 - Memory114 - Interfacing Unit116 - Processing Unit118 - Centralized Server120 - Database122 - Data Recording Module124 - Response Generation Module126 - Analysis Module128 - Communication Module130 - Interaction System132 - Network Function (NF) Application134 - Architecture136-1, 136-2, 136-3... 136-N - Super Core Regions138-1, 138-2, 138-3... 138-N - Multi-access Edge Computing (MEC) Sites140 - Network Management Platform200 - Process300 - Computer system310 - External storage device320 - Bus330 - Main memory340 - Read only memory350 - Mass storage device360 - Communication port(s)370 - Processor400 - MethodDETAILED DESCRIPTION
[0042] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0043] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0044] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0045] 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 operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0046] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, anyaspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive — in a manner similar to the term “comprising” as an open transition word — without precluding any additional or other elements.
[0047] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” 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.
[0048] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.
[0049] The disclosed system and method facilitate to provide valuable assistance to an operations team, to effectively debug issues encountered duringexecution 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 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.
[0050] 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.
[0051] Various embodiments of the present disclosure will be explained in detail with reference to FIGs. 1 to 4.
[0052] FIG. 1A illustrates an exemplary network architecture (100) in which or with which embodiments of the present disclosure may be implemented.
[0053] Referring to the FIG. 1 A, the network architecture ( 100) may include one or more computing devices or one or more user equipment ( 102- 1 , 102-2... 102- 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 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, however any number of the user equipment (102) may be included without departing from the scope of the ongoing description. Similarly. A person ofordinary 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).
[0054] In an embodiment, the user equipment (102) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) 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, 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 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.
[0055] 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 headmounted display computer device, a head-mounted camera device, a wristwatch 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.
[0056] 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 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 that the user equipment (102) may not be restricted to the mentioned devices and various other devices may be used.
[0057] In an embodiment, the user equipment (102) may involve collection, analysis, and sharing of data received from the system (106) via the network (108). 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).
[0058] Referring to the FIG. 1A, the user equipment (102) may 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 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. 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.
[0059] In an embodiment, the users (104) may interact with their respective user equipment (102) to perform actions that generate the communication requestsand transmitted through the network (108) to the system (106). The system (106) may process the incoming communication requests and captures relevant 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 processes. The system (106) may further allow the NF application (132) to interact with a centralized server (118) (as shown in FIG. IB) 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 configuration.
[0060] 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, 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 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 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.
[0061] Although the FIG. 1A shows exemplary components of the network 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 components of the network architecture (100).
[0062] FIG. IB illustrates an exemplary block diagram of the system (106), in accordance with an embodiment of the present disclosure.
[0063] 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).
[0064] 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 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 exemplary embodiment, the neighbouring nodes may be, but not limited to, other network functions, base stations, user devices, gateways, and so forth.
[0065] The memory (112) may be configured to store computer-readable 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 nonvolatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like. Embodiments of the present invention are intended toinclude or otherwise type of the memory (112) including known related art and / or later developed technologies.
[0066] 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).
[0067] 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 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.
[0068] In an embodiment, the database (120) may interact with the 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 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 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 the processing unit (116). In an embodiment, the database (120) may be separate from the system (106).
[0069] The modules are controlled by the processing unit (116) which execute the computer-readable instructions retrieved from the memory (112). The 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 on operational instructions.
[0070] 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 (122) may be configured to transmit the communication requests and the recorded parameters to the response generation module (124).
[0071] The response generation module (124) may be configured to process the communication requests for generating one or more responses by the NF 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 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.
[0072] In an exemplary embodiment, the clearcode may be a specific code 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. 1 A). The clearcode may be used internally to manage the responses of the processed communication requests.
[0073] Similarly, the response code may be a standard status code indicating the responses of the processed communication requests. The response code may beused 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 different code indicating the error scenario.
[0074] 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 code, the response description may be “not found”.
[0075] Based on the response parameters, the response generation module (124) may be configured to generate the responses of the corresponding communication requests.
[0076] 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 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 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 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.
[0077] The response generation module (124) may be configured to generate a success condition processing signal when the responses of the corresponding processed communication requests is determined to be the successscenarios. 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 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).
[0078] 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 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 meets the predefined criteria to the communication module (128). In an example, the analysis module (126) may be configured to execute a vProbe convertor thread for transmitting the success scenarios to the centralized server (118).
[0079] The communication module (128) may be configured to process the 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, the call flow name, a unique correlation identifier, and so forth.
[0080] 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 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. 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 realtime monitoring and analysis of network performance and behavior.
[0081] 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 embodiment, a job schedular such as, a quartz scheduler may be utilized to manage the predefined rate limit.
[0082] Although the FIG. IB 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. IB. Additionally, or alternatively, 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).
[0083] FIG. 1C illustrates an exemplary block diagram of an interaction system (130) for enabling an interaction between various components involved in a debugging process, in accordance with an embodiment of the disclosure.
[0084] 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 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 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.
[0085] FIG. ID illustrates an exemplary architecture (134) for debugging issues encountered during execution of the communication request with the centralized server (118), in accordance with an embodiment of the present disclosure.
[0086] The architecture (134) spans multiple super core regions (136-1, 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 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 managed by the centralized server (118) including the database (120) (as shown in the FIG. IB).
[0087] In an exemplary embodiment, four super core regions (west, east, north, and south) (136) are shown, however, it may be appreciated that there may exist any number of super core regions (136). The super core regions (136) aregeographically distributed to ensure wide coverage and low latency for network services.
[0088] The network functions (132) may include 5G NFs and 4G NFs. The 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.
[0089] 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.
[0090] 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 insights into network performance and issues.
[0091] Further, the architecture (134) may include a network management platform (140) that may be implemented as a centralized platform responsible for 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 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) tocentralize 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.
[0092] Therefore, the architecture (134) of the FIG. ID 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.
[0093] 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.
[0094] As illustrated, at step (202), the NF application (132) may record the 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.
[0095] 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 communication request and determining the appropriate response based on a predefined logic.
[0096] At step (206), the NF application (132) accesses the call flow 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 expected outcome as specified by the parameters associated with thecommunication 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 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.
[0097] 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).
[0098] At the step (210), the NF application (132) may ignore the success scenarios and ends a flow of the process (200).
[0099] At the step (212), the communication request as the HTTP / 2 request may be processed for communicating with the centralized server (118)
[0100] At step (214), the communication request may be transmitted to the centralized server (118) based on the predefined rate limit.
[0101] FIG. 3 illustrates an exemplary computer system (300) in which or with which embodiments of the present disclosure may be implemented. As shown 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 include various modules associated with embodiments of the present disclosure.
[0102] 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.
[0103] 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 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).
[0104] In an embodiment, the main memory (330) may be a Random Access 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).
[0105] 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 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., an array of disks (e.g., SATA arrays).
[0106] 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 existing or future ports. The communication port (360) may be chosen dependingon the network (108), such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (300) connects.
[0107] Optionally, operator and administrative interfaces, e.g., a display, a 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 the aforementioned exemplary computer system (300) limit the scope of the present disclosure.
[0108] FIG. 4 illustrates a flowchart of a method (400) for debugging issues encountered during execution of one or more communication requests, in accordance with an embodiment of present disclosure.
[0109] 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).
[0110] Step (404) 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 (132), wherein the one or more responses comprises one of, error scenarios or success scenarios.
[0111] Step (406) 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.
[0112] Step (408) includes a step of transmitting the one or more communication requests along with one or more identifiers and Streaming Data Records (SDRs) to a centralized server (118) based on a predefined rate limit, whenat 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.
[0113] 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.
[0114] 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.
[0115] 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.
[0116] 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 code, a response description, or a combination thereof.
[0117] 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.
[0118] 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.
[0119] In an embodiment, the present disclosure discloses a user equipment (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 aplurality of signals in response to the connection request. The network is configured for implementing the method for debugging issues arising during execution of one or more communication requests.
[0120] The present disclosure provides a technical advancement in the field of network function operations and management. This advancement addresses 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 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.
[0121] While the foregoing describes various embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised 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.
[0122] 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 thedisclosure 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
[0123] 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).
[0124] 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.
[0125] The present invention enables each of NFs to write data records (for example, clearcodes), which assist in quick troubleshooting.
[0126] 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.
[0127] 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.
[0128] The present invention provides a functionality of throttling a rate at which data records are sent to a centralized server.
Claims
CLAIMSWe 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 theone 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 1.
16. A computer program product comprising a non- transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform 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 requestsby 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.