DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
SYSTEM AND METHOD FOR THREAD LOG DUMPING IN A NETWORK
2. APPLICANT(S)
Name Nationality Address
JIO PLATFORMS LIMITED INDIAN Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India
3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

RESERVATION 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 or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
FIELD OF THE DISCLOSURE
[0002] The present disclosure relates generally to the field of wireless communication network. More particularly, the present disclosure relates to a system and a method for performing thread log dumping in a network.
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 expression ‘threads’ used hereinafter in the specification refers to smallest units of execution within a process that share the same resources but execute independently, enabling concurrent or parallel operations within a computing environment.
[0005] The expression ‘thread log dumping’ used hereinafter in the specification refers to a process of extracting and recording log data specific to individual threads within a system for analysis and troubleshooting.
[0006] The expression ‘process identifier (ID)’ used hereinafter in the specification refers to a unique numerical value assigned by an operating system to distinguish and manage individual processes running inside an application during execution.
[0007] The expression ‘module identifier (ID)’ used hereinafter in the specification refers to a unique identifier assigned to a specific module within a software system or application, associated with a particular process, used to distinguish and manage different functional units or components within that process.
[0008] The expression ‘thread ID’ used hereinafter in the specification refers to a unique numerical value assigned to a specific thread within a process, used to distinguish and manage individual threads running concurrently or in parallel within that process.
[0009] The expression ‘S-CSCF’ used hereinafter in the specification refers to a Serving Call Session Control Function. The S-CSCF is a core component in an internet protocol (IP) Multimedia Subsystem (IMS) network that manages session control, call routing, and user registration.
[0010] The expression ‘I-CSCF’ used hereinafter in the specification refers to an Interrogating Call Session Control Function. The I-CSCF queries other network elements to locate the appropriate S-CSCF for routing Session Initiation Protocol (SIP) requests.
[0011] The expression ‘BGCF’ used hereinafter in the specification refers to a Breakout Gateway Control Function. The BGCF manages the routing of calls between the IMS network and external networks, such as the Public Switched Telephone Network (PSTN), by converting and directing the calls appropriately.
[0012] The expression ‘SIB’ used hereinafter in the specification refers to a network component within the IMS network, specifically the S-CSCF, the I-CSCF, or the BGCF collectively referred to as a SIB. The SIB is involved in managing and processing SIP messages and sessions within the IMS network.
[0013] The expression ‘CLI’ used hereinafter in the specification refers to a command line interface that enables interaction between a device or a software program by allowing a user to enter commands into a text terminal, a terminal emulator, or a remote shell client. The input commands are processed by a command line interpreter which initiates operations corresponding to the entered command.
BACKGROUND
[0014] 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.
[0015] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog technology that offered only voice services. Further, when the second-generation (2G) technology was introduced, text messaging and data services became possible. The third-generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth-generation (4G) technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, the fifth-generation (5G) technology is being deployed, with even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (IoT) connectivity, and more efficient use of network resources. The sixth generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way we connect and interact with technology.
[0016] As wireless technologies advance, meeting 6G demands and delivering high-quality services to customers becomes crucial. Additionally, it’s essential to identify and debug real network issues efficiently, without significantly impacting network performance. The rapid advancement of technology and the widespread adoption of digital networks have resulted in increasingly complex systems that require efficient data management and analysis. As organizations become more reliant on interconnected systems for their operations, the need for effective monitoring and troubleshooting mechanisms has become critical. However, traditional methods of logging network activities often present significant challenges, particularly in environments with heavy traffic volumes. The traditional logging techniques that capture extensive data across all modules can lead to overwhelming amounts of information. The data overload can strain system resources, resulting in performance degradation that negatively impacts overall service quality. When network administrators are faced with large amount of log data, it becomes cumbersome to examine through the information to identify relevant issues. Consequently, the time required to diagnose and resolve problems can increase significantly, leading to prolonged network outages and disruptions in business operations.
[0017] Moreover, the continuous logging of all network activities can quickly consume available storage, necessitating frequent maintenance and management of log data. The continuous logging can further complicate the troubleshooting process, as administrators are forced to prioritize which logs to retain and analyze. As a result, critical information may be lost or overlooked, hindering effective incident response.
[0018] There is, therefore, a need in the art to provide a method and a system that can overcome the shortcomings of the existing prior arts.
SUMMARY OF THE DISCLOSURE
[0019] In an exemplary embodiment, the present disclosure relates to a system for performing thread log dumping in a network. The system comprises a receiving unit configured to receive at least one request corresponding to at least one process from a user equipment (UE). A processing engine is coupled with the receiving unit to receive the at least one request and is further coupled with a memory to execute a set of instructions stored in the memory. The processing engine is configured to extract one or more parameters from the received at least one request. The processing engine is configured to configure the one or more extracted parameters to determine at least one thread log data associated with the at least one process. The processing engine is configured to dump the at least one determined thread log data based on the one or more configured parameters.
[0020] In an embodiment, the one or more extracted parameters include at least one of a process identifier (ID), a thread identifier (ID), and a module identifier (ID).
[0021] In an embodiment, the one or more extracted parameters are configured through a user interface (UI) during a runtime of the at least one process.
[0022] In an embodiment, the processing engine is further configured to create at least one file associated with the at least one dumped thread log data.
[0023] In an exemplary embodiment, the present disclosure relates to a method for performing thread log dumping in a network. The method comprises receiving, by a receiving unit, at least one request corresponding to at least one process from a user equipment (UE). The method comprises extracting, by a processing engine, one or more parameters from the received at least one request. The method comprises configuring, by the processing engine, the one or more extracted parameters to determine at least one thread log data associated with the at least one process. The method comprises dumping, by the processing engine, the at least one determined thread log data based on the one or more configured parameters.
[0024] In an exemplary embodiment, the present disclosure relates to a user equipment (UE) communicatively coupled with a network. The coupling includes steps of receiving, by the network, at least one request corresponding to at least one process from the UE. The network is configured to extract one or more parameters from the received at least one request. The network is configured to configure the one or more extracted parameters to determine at least one thread log data associated with the at least one process. The network is configured to dump the at least one determined thread log data based on the one or more configured parameters. The network is configured to transmit the at least one dumped thread log data to the UE.
[0025] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
OBJECTIVES OF THE DISCLOSURE
[0026] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0027] An objective of the present disclosure is to efficiently perform thread log dumping in a Serving Call Session Control Function (S-CSCF), Interrogating Call Session Control Function (I-CSCF), or Breakout Gateway Control Function (BGCF) (collectively referred to as SIB) in a network.
[0028] Another objective of the present disclosure is performing thread log dumping of a particular process running inside an application in the multi-process architecture.
[0029] Another objective of the present disclosure is performing thread log dumping of a particular thread within a module that resides inside the application, facilitating debugging of real network problems.
[0030] Another objective of the present disclosure performing thread log dumping of a particular thread by combining the logging of both thread and module within a process to generate a more specific and detailed log output.
[0031] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0032] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0033] FIG. 1 illustrates an exemplary network architecture for implementing a system for performing thread log dumping in a network, in accordance with an embodiment of the present disclosure.
[0034] FIG. 2 illustrates an exemplary block diagram of the system for performing the thread log dumping in the network, in accordance with an embodiment of the present disclosure.
[0035] FIG. 3 illustrates an exemplary flow diagram of a method for performing the thread log dumping in the network, in accordance with an embodiment of the present disclosure.
[0036] FIG. 4 illustrates an exemplary system architecture for performing the thread log dumping in the network, in accordance with an embodiment of the present disclosure.
[0037] FIG. 5 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0038] FIG. 6 illustrates another exemplary flow diagram of the method for performing the thread log dumping in the network, in accordance with an embodiment of the present disclosure.
[0039] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100 – Network architecture
102-1, 102-2…102-N – Plurality of Users
104-1, 104-2…104-N – Plurality of User Equipments
106 – Network
108 – System
200 – Block Diagram
202 – Processor(s)
204 – Memory
206 – Interfaces(s)
208 – Processing Engine
210 – Database
212 – Receiving unit
300, 600 - Flow Diagram
500 - Computer System
510 - External Storage Device
520 - Bus
530 - Main Memory
540 - Read-Only Memory
550 - Mass Storage Device
560 - Communication Ports
570 – Processor
DETAILED DESCRIPTION
[0040] In the following description, for the purposes of explanation, various specific details are set forth to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0041] 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.
[0042] 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.
[0043] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0044] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0045] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0046] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
[0047] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical, and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices, and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery, and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.
[0048] It should be noted that the terms such as “monitoring”, “detecting”, “dumping”, “determining”, “checking”, or the like, refer to the action and processes of a computer system.
[0049] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital Signal Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.
[0050] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), and now fifth generation (5G), and more such generations are expected to continue in the forthcoming time.
[0051] Radio Access Technology (RAT) refers to the technology used by mobile devices/ User Equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and 5G. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
[0052] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation. In high-traffic network environments, logging can pose significant challenges, particularly due to the sheer volume of data generated and the complexities introduced by multi-threading. When every action, request, or event is logged across multiple modules, the resulting data can become overwhelming. The information overload makes it difficult for network administrators to monitor through logs to identify relevant events, leading to potential delays in troubleshooting and increased downtime. Further, the performance impact of extensive logging can slow down the network itself, as resources are consumed by logging activities instead of handling user requests.
[0053] The presence of multiple threads operating within the same module adds another layer of complexity. Each thread may interact with shared resources concurrently, leading to interleaved log entries that can obscure the sequence of events. This interleaving complicates root cause analysis, as identifying the order of operations becomes challenging. As a result, critical events may be lost amidst the noise of extensive logging, making it difficult to pinpoint the source of issues.
[0054] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing an improved system and a method for performing thread log dumping in the network. In an embodiment, the present disclosure provides a system and a method of thread log dumping that addresses the challenges associated with logging in high-traffic network environments. By implementing a thread-specific logging mechanism, the present disclosure enables the targeted capture of log data for individual threads within a module. The present disclosure allows for a more granular view of operations, facilitating the identification and analysis of issues that arise from concurrent thread interactions. In contrast to traditional logging techniques that indiscriminately capture all activities, the thread log dumping technique prioritizes relevant events associated with each thread. Thus, the present disclosure reduces the overall volume of log data but also enhances the clarity of the logs, making it easier for network operators/administrators to trace the sequence of events and pinpoint the root causes of problems.
[0055] The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1 – FIG. 6.
[0056] FIG. 1 illustrates an exemplary network architecture (100) for implementing a system (108) for performing thread log dumping in a network (106), in accordance with an embodiment of the present disclosure.
[0057] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2…104-N) associated with one or more users (102-1, 102-2…102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2…102-N) may collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2…104-N) may be collectively referred to as the UE (104). Although three UEs (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.
[0058] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UE (104) may include, but is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but is not limited to, intelligent, multi-sensing, network-connected devices, which may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0059] Additionally, in some embodiments, the UE (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but is not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.
[0060] Referring to FIG. 1, the UE (104) may communicate with the system (108) through the network (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one of a 5G network, 6G network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and/or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.
[0061] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a radio access network (RAN), a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0062] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104). The network (106) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request.
[0063] In an embodiment, the UE (104) is connected to an evolved packet core (EPC) network for establishing a calling session to an enhanced Node B (eNodeB). The EPC network includes various components such as a home subscriber server (HSS), serving gateway (S-GW), packet data network (PDN) Gateway (P-GW), and mobility management entity (MME). The P-GW interfaces with other packet data networks, e.g., an internet protocol (IP) Multimedia Subsystem (IMS) network. The IMS network is configured to deliver multimedia communications services such as voice, video and text messaging over internet protocol (IP) networks and thus is configured to interface with another network node. A proxy call session control function (P-CSCF) node acts as an entry point of the IMS network. The UE is registered with the P-CSCF node.
[0064] Within the IMS network, several types of session initiation protocol (SIP) servers known as CSCF are used to process SIP signaling packets in the IMS network. The CSCF is responsible for SIP session control, user authentication, call routing, and controlling the generation of call detail records (CDRs). The P-CSCF is a first point of contact for the IMS network, and the P-CSCF forwards the registration requests received from the UE to an interrogating CSCF (I-CSCF) and forwards the SIP messages to a serving CSCF (S-CSCF). The I-CSCF interrogates the HSS to obtain the address of a relevant S-CSCF to process the SIP initiation request. The I-CSCF interconnects with an interconnect session border controller (I-SBC) that addresses the boundary requirements where network service provides interconnect and exchange inbound and outbound SIP sessions. The S-CSCF is the central node of the signaling plane. The S-CSCF handles SIP registrations of mobile users. A Breakout Gateway Control Function (BGCF) is a SIP proxy server which includes routing functionality based on mobile customer telephone numbers. The BGCF provides breakout functionality in the IMS network which allows communication between different networks, such as a packet-switched (PS) network and a circuit-switched (CS) network. The BGCF is used for routing calls from the IMS network to a phone in the CS network, e.g., the public switched telephone network (PSTN) or public land mobile network (PLMN). The BGCF forwards the signaling to the selected PSTN/PLMN network with the help of a media gateway control function (MGCF) that acts as a gateway to the PSTN/CS network over the IMS network. The S-CSCF, I-CSCF and BGCF together form a SIB module of the IMS network.
[0065] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).
[0066] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for performing the thread log dumping in the network (106), in accordance with an embodiment of the present disclosure.
[0067] Referring to FIG. 2, in an embodiment, the system (108) may include one or more processor(s) (202), a memory (204), interface(s) (206), a processing engine (208), a receiving unit (212) and a database (210). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in the memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0068] In an embodiment, the interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices (I/O), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a processing engine (208) and a database (210).
[0069] The processing engine (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine (208). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine (208). In such examples, the system may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing engine (208) may be implemented by electronic circuitry. In an embodiment, the database (210) includes data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (202) or the processing engine (208).
[0070] In an embodiment, the receiving unit (212) is configured to receive at least one request corresponding to at least one process from the UE (104). In an embodiment, each request corresponds to at least one process within the system (108). In an embodiment, in case of the S-CSCF, of the SIB module, the receiving unit (212) may receive the at least one request related to at least one process such as call setup, session management, or user registration. In case of the I-CSCF, the receiving unit (212) may receive the at least one request that involves processes that includes routing the at least one request to the appropriate S-CSCF based on user profiles. Further, for the BGCF, the receiving unit (212) may receive the at least one request that may pertain to at least one process that includes managing the interconnection between different networks during a call. In an embodiment, the at least one process corresponding to the at least one request from the UE (104) may include a session initiation process, an authentication process, a configuration updating process, an error reporting process, a resource allocation process, etc. In an embodiment, the receiving unit (212) may receive the at least one request associated with at least one process associated with different components of SIB module such as High Availability (HA) Manager process, and Logger Manager (LGM) process etc. In an embodiment, the receiving unit (212) is configured to handle incoming requests from the UE (104) by establishing a communication link through suitable protocols and interfaces. The receiving unit (212) uses protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP) for data transfer and Hypertext Transfer Protocol (HTTP)/Hypertext Transfer Protocol Secure (HTTPS) for web communication, along with interfaces like Application Programming Interfaces (APIs) for structured interaction. The request received by the receiving unit (212) may encompass one or more parameters to ensure proper handling and processing. The request may include a request type, indicating the action to be performed, such as initiating a call, registering a user, or accessing a service. The request may include a process identifier (ID), module ID, or thread ID. The request may include user identifier information, such as the subscriber’s user ID or phone number. The request may include session information that provides details about the requested session, including parameters like media capabilities or call type (voice or video). Upon receiving the request, the receiving unit (212) routes the request to the processing engine (208) for further processing and execution based on the request’s type and one or more parameters.
[0071] In an embodiment, the processing engine (208) is coupled with the receiving unit (212) to receive the at least one request and is further coupled with a memory (204) to execute a set of instructions stored in the memory (204). In an embodiment, the processing engine (208) is configured to extract one or more parameters from the at least one received request. In an embodiment, the one or more extracted parameters include at least one of a process ID, a thread ID, and a module ID. In an embodiment, the process ID uniquely identifies a running process within the system. In an embodiment, the thread ID specifies a particular thread of execution within the running process. In an embodiment, the module ID denotes a specific software module or component involved in the running process. In an embodiment, the processing engine (208) is configured to analyze the request to extract the one or more parameters. For example, if the request involves initiating a log dump for a particular thread, the processing engine (208) is configured to extract the thread identifier (ID) to locate and manage the relevant thread’s logs. If the request includes logging information related to a specific process or module, the processing engine (208) is configured to extract the process ID and the module ID to ensure that the logs are correctly associated with the corresponding process and module. In an embodiment, the modules may be associated with S-CSCF, I-CSCF, and BGCF of the network (106). In an embodiment, the processing engine (208) is configured to extract parameters from the received request through a systematic process that involves several key steps. For example, the processing engine (208) is configured to parse the request to decode its structure according to predefined formats or protocols. For example, if the request is formatted using a protocol like HTTP or Session Initiation Protocol (SIP), the processing engine (208) is configured to read the data fields and headers to identify relevant information. In an embodiment, the processing engine (208) is configured to use pattern-matching techniques or predefined schemas to locate one or more parameters such as process IDs, thread IDs, or module IDs within the request. For example, if the request includes a header field labeled “Process ID” or a specific JavaScript Object Notation (JSON) attribute, the processing engine (208) is configured to identify and isolate this information. By parsing the request and isolating the one or more extracted parameters, the processing engine (208) is configured to direct the log dumping process to the appropriate thread, process, or module, ensuring that the log data is accurately collected and managed.
[0072] In an embodiment, the processing engine (208) is configured to configure the one or more extracted parameters to determine at least one thread log data associated with the at least one process. In an embodiment, the one or more extracted parameters are configured through a user interface (UI) such as a command line interface (CLI) during a runtime of the at least one process. In an embodiment, configuring the one or more extracted parameters involves retrieving specific log data associated with the corresponding process, thread or module based on the one or more extracted parameters, such as process IDs, thread IDs, or module IDs. For example, once the processing engine (208) is configured to extract the process ID and the thread ID from a request, the processing engine (208) utilizes the one or more extracted parameters to query a log database or logging system to find and compile log entries related to that particular process, thread and module respectively. In an embodiment, at least one thread log data encompasses information collected about individual threads associated with various processes in the IMS network. The data includes user data, such as caller identifier (ID), which helps identify who is initiating a session, enabling analysis of user behaviors and call patterns. Additionally, session data is logged, capturing details like timestamps, call duration, and session status, providing a comprehensive view of communication interactions. Furthermore, network instance information is recorded, detailing the specific network components involved in processing the session, such as the S-CSCF, I-CSCF, or BGCF. In an embodiment, the one or more extracted parameters are configured through the CLI during the runtime of the process by allowing real-time adjustment and control of the parameters used for managing or monitoring the process. For example, once the parameters such as process IDs, thread IDs or module IDs are extracted from a request, they can be input or modified using CLI commands. This may involve entering commands into the CLI, which configures the system (108) to interact with or retrieve logs and data specific to the identified process, thread or module, respectively.
[0073] In an embodiment, the processing engine (208) is configured to dump the at least one determined thread log data based on the one or more configured parameters. In an embodiment, the processing engine (208) is configured to create at least one file associated with the at least one dumped thread log data. In an embodiment, the at least one file may be created at the LGM of the SIB module. The LGM is responsible for managing the logging processes within the SIB module. The LGM performs log collection which involves gathering logs from a plurality of processes of the SIB module. The LGM performs log storage where logs are organized and stored in a structured format to facilitate easy retrieval. The LGM further performs log analysis which provides tools for searching and analyzing log data to identify trends, issues, or anomalies. In an embodiment, if the one or more extracted parameters include the thread ID and the process ID, the processing engine (208) is configured to query the log storage system to locate all log entries that correspond to the one or more extracted parameters. Further, once the relevant log data is identified, the processing engine (208) is configured to execute a dump operation. In an example the dump operation may involve exporting or saving the collected log data into a specified format or location for analysis. The dumping process might involve writing the logs to a file, database, or logging system, allowing users to review and analyze the data to diagnose issues, understand system behavior, or perform other tasks. Once the log data for a specific process or thread is determined, the processing engine (208) is configured to generate at least one file to store the log data. For example, if the extracted parameters specify the thread ID, the processing engine (208) is configured to create a file which includes all the log entries related to that thread. Further, the examples of the dumping process include exporting log data to a file, such as creating a .log or .txt file that captures all entries related to a specific thread ID or process ID for analysis. Another example is inserting the log data into a database, where it can be stored in a table for structured querying and long-term retention.
[0074] FIG. 3 illustrates an exemplary flow diagram of a method (300) for performing the thread log dumping in the network (106), in accordance with an embodiment of the present disclosure.
[0075] In an embodiment, there are a plurality of servers that reside in the SIB. The plurality of servers are configured to execute a plurality of processes (P1, P2, P3, P4,…., Pn) that are running inside at least one application. In an aspect of the present disclosure, there are a plurality of threads (Thread-1, Thread -2, Thread -3, Thread-4) that resides in at least one target process from the plurality of processes (P1, P2, P3, P4,…., Pn). In an aspect of the present disclosure, there are a plurality of modules (Module-1, Module-2, Module-3, Module-4, Module-5…, Module-n) that resides in the plurality of processes (P1, P2, P3, P4,…., Pn) that are running in the at least one application. In an example, during step (302) (Dump-type-1) of the flow sequence (300), all thread logs of a particular process (P4) from the plurality of processes (P1, P2, P3, P4…. Pn) are dumped within the SIB.
[0076] In an example, at step (304) (Dump-type-2) of the flow sequence (300), all thread logs of Thread-2 of the process (P4) from the plurality of processes (P1, P2, P3, P4…. Pn) are dumped within the SIB.
[0077] In an example, at step (306) (Dump-type-3) of the flow sequence (300), all thread logs of Module-3 of the process (P4) from the plurality of processes (P1, P2, P3, P4…. Pn) are dumped within the SIB.
[0078] In an example, at step (308) and step (310) of the flow sequence (300), it is possible to dump a particular thread log data of Thread-2 and Module-3 of the process (P4) from the plurality of processes (P1, P2, P3, P4…. Pn) within the SIB.
[0079] FIG. 4 illustrates an exemplary system architecture (400) for performing the thread log dumping in the network (106), in accordance with an embodiment of the present disclosure.
[0080] In an embodiment, the system architecture (400) consists of multiple blades and components that facilitate efficient signaling, session management, and service delivery through the integration of S-CSCF, I-CSCF, and BGCF functionalities in the SIB module In an embodiment, the system architecture (400) is comprised of multiple blade servers, each integrating a variety of applications and processes critical for managing intricate network operations. Specifically, Blade Server 1 (Blade1), Blade Server 2 (Blade2), Blade Server 3 (Blade3), Blade Server 4 (Blade4), and Blade Server 5 (Blade5) are part of the system architecture (400), with each blade hosting distinct applications and running various processes. Blade1, designated as the Master High Availability Manager (HA(M)), oversees overall high availability management across the network, ensuring that services remain uninterrupted by managing redundancy and failover processes. Blade2, classified as the Slave Availability Manager (HA(S)), works in conjunction with the master server to support high availability and handle failover scenarios, thus enhancing the system’s resilience. Blade3, Blade4 and Blade5 are categorized based on their performance capabilities, with Blade3 being the highest-performing (HA(PL1)), Blade4 having a moderate performance level (HA(PL2)), and Blade5 categorized as the lowest performance level (HA(PL3)). This performance-based categorization allows for effective load balancing and resource allocation across the servers.
[0081] The system architecture (400) includes a range of specialized processes running within these servers. The Logger Manager (LGM) process, for instance, is responsible for capturing and managing log data, recording system events, errors, and operational details to facilitate troubleshooting and performance monitoring. The High Availability (HA) Manager process provides a specialized messaging mechanism that enables inter-process communication regarding their operational states. Each process can send updates about its status and subscribe to notifications about other processes states, thereby maintaining synchronization and responding to system changes in real-time.
[0082] Additionally, the system architecture (400) features several other key processes such as the Fault and Configuration Manager (SYSM) that handles system fault detection and configuration management, ensuring system stability and proper settings. The Diameter Load Balancer (DIALB) distributes Diameter protocol traffic to balance the load among servers, crucial for authentication, authorization, and accounting functions. The Legal Intercept Manager (LIM) ensures compliance with legal interception requirements by managing the monitoring of communications. The SIP Load Balancer (SIPLB) distributes SIP traffic to optimize performance and manage communication sessions efficiently. The SIPLB may include a plurality of load balancers such as SIPLB0, SIPLB1 etc. Further, multiple Business Logic Processors (sib) handle various business logic and rules essential for the applications, facilitating process automation and decision-making in the SIB module. In an embodiment, the sib may include sib01, sib11, sib21, sib31… etc. that represent the various business logic processors within the SIB module. Each instance is tailored for specific functions related to session management, call processing, and multimedia service features of the SIB module. For example, sib11, sib111, sib211 might handle core call setup and teardown processes. Further, sib21, sib121, sib221 could be focused on monitoring call quality or integrating with external services. Additional instances like sib31 and sib41 expand functionality, possibly dealing with more complex features such as call routing or media handling integration with S-CSCF, I-CSCF, and BGCF.
[0083] Thus, the comprehensive system architecture (400) including configuration of blade servers and processes ensures a robust, scalable, and efficient system capable of managing complex network operations, maintaining high availability, and adhering to performance and compliance standards. In an example, the shaded portions of the process types include the active instances, and the unshaded portions include the standby instances.
[0084] FIG. 5 illustrates a computer system (500) in which or with which the embodiments of the present disclosure may be implemented.
[0085] As shown in FIG. 5, the computer system (500) may include an external storage device (510), a bus (520), a main memory (530), a read-only memory (540), a mass storage device (550), communication port(s) (560), and a processor (570). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The processor (570) may include various modules associated with embodiments of the present disclosure. The communication port(s) (560) 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(s) (560) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects.
[0086] The main memory (530) may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (540) 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 (570). The mass storage device (550) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage device (550) includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks.
[0087] The bus (520) communicatively couples the processor (570) with the other memory, storage, and communication blocks. The bus (520) may be, e.g., a Peripheral Component Interconnect / Peripheral Component Interconnect Extended bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (570) to the computer system.
[0088] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (520) to support direct operator interaction with the computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (560). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.
[0089] FIG. 6 illustrates another exemplary flow diagram of the method (600) for performing the thread log dumping in the network (106), in accordance with an embodiment of the present disclosure.
[0090] At step 602, the method (600) includes receiving, by a receiving unit (212), at least one request corresponding to at least one process from a user equipment (UE) (104). In an embodiment, each request corresponds to at least one process within the system (108). In an embodiment, the at least one process corresponding to the at least one request from the UE (104) may include a session initiation process, an authentication process, a configuration updating process, an error reporting process, a resource allocation process etc.
[0091] At step 604, the method (600) includes extracting, by a processing engine (208), one or more parameters from the received at least one request. In an embodiment, the one or more extracted parameters include at least one of a process identifier (ID), a thread identifier (ID), and a module identifier (ID). In an embodiment, the process ID uniquely identifies a running process within the system. In an embodiment, the thread ID specifies a particular thread of execution within the running process. In an embodiment, the module ID denotes a specific software module or component involved in the running process.
[0092] At step 606, the method (600) includes configuring, by the processing engine (208), the one or more extracted parameters to determine at least one thread log data associated with the at least one process. In an embodiment, the one or more extracted parameters are configured through a user interface (UI) (e.g., a command line interface (CLI)) during a runtime of the at least one process. In an embodiment, configuring the one or more extracted parameters involves retrieving specific log data associated with the corresponding process, thread or module based on the one or more extracted parameters, such as process IDs, thread IDs, or module IDs. For example, once the processing engine (208) is configured to extract the process ID and the thread ID from the request, the processing engine (208) utilizes the one or more extracted parameters to query a log database or logging system to find and compile log entries related to that particular process, thread and module respectively.
[0093] At step 608, the method (600) includes dumping, by the processing engine (208), the at least one determined thread log data based on the one or more configured parameters. In an embodiment, the method comprises creating at least one file associated with the at least one dumped thread log data. In an example, the dump operation may involve exporting or saving collected log data into a specified format or location for analysis. In an embodiment, the dumping process might involve writing the logs to a file, database, or logging system, allowing users to review and analyze the data to diagnose issues, understand system behavior, or perform other tasks. In an embodiment, once the log data for a specific process or thread is determined, the processing engine (208) is configured to generate at least one file to store the log data.
[0094] In an exemplary embodiment, the present disclosure relates to a user equipment (UE) communicatively coupled with a network. The coupling includes steps of receiving, by the network, at least one request corresponding to at least one process from the UE. The network is configured to extract one or more parameters from the received at least one request. The network is configured to configure the one or more extracted parameters to determine at least one thread log data associated with the at least one process. The network is configured to dump the at least one determined thread log data based on the one or more configured parameters. The network is configured to transmit the at least one dumped thread log data to the UE.
[0095] The present disclosure provides technical advancement related to logging and debugging within multiprocess architectures by introducing a refined approach to log management. The present disclosure enables targeted dumping of logs for specific processes, modules, and threads, offering enhanced precision in error identification and troubleshooting. The present disclosure allows for the combination of thread and module-level logs within a process, delivering a comprehensive view of system operations that facilitates more accurate and efficient analysis. By reducing irrelevant data and streamlining the debugging process, the present disclosure optimizes resource utilization and system performance, addressing complex debugging tasks with greater effectiveness. Further, the present disclosure enables focused logging of specific threads associated with particular processes, rather than capturing logs for the entire system. The targeted approach allows developers and network administrators to quickly identify and analyze relevant data when troubleshooting issues, drastically reducing the time spent sifting through excessive log information. By concentrating on the threads that are actively involved in a session or experiencing problems, teams can expedite root cause analysis and implement fixes more efficiently. As a result, the present disclosure not only enhances operational efficiency but also minimizes downtime, leading to improved service delivery and user satisfaction.
[0096] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.
TECHNICAL ADVANTAGES
[0097] As is evident from the above, the present disclosure described herein above has several technical advantages including:
- efficiently performing thread log dumping in a network;
- performing thread log dumping of a particular process running inside an application in the multi-process architecture;
- performing thread log dumping of a particular thread within a module resides inside the application, facilitating debugging of real network problems; and
- performing thread log dumping of a particular thread by combining the logging of both thread and module within a process to generate a more specific and detailed log output.
,CLAIMS:Claims
We claim:
1. A system (108) for performing thread log dumping in a network (106), the system (108) comprising:
a receiving unit (212) configured to receive at least one request corresponding to at least one process from a user equipment (UE) (104);
a processing engine (208) coupled with the receiving unit (212) to receive the at least one request and is further coupled with a memory (204) to execute a set of instructions stored in the memory (204), the processing engine (208) is configured to:
extract one or more parameters from the received at least one request;
configure the one or more extracted parameters to determine at least one thread log data associated with the at least one process; and
dump the at least one determined thread log data based on the one or more configured parameters.

2. The system (108) as claimed in claim 1, wherein the one or more extracted parameters include at least one of a process identifier (ID), a thread identifier (ID), and a module identifier (ID).

3. The system (108) as claimed in claim 1, wherein the one or more extracted parameters are configured through a user interface (UI) during a runtime of the at least one process.

4. The system (108) as claimed in claim 1, wherein the processing engine (208) is further configured to create at least one file associated with the at least one dumped thread log data.

5. A method (600) for performing thread log dumping in a network (106), the method (600) comprising:
receiving (602), by a receiving unit (212), at least one request corresponding to at least one process from a user equipment (UE) (104);
extracting (604), by a processing engine (208), one or more parameters from the received at least one request;
configuring (606), by the processing engine (208), the one or more extracted parameters to determine at least one thread log data associated with the at least one process; and
dumping (608), by the processing engine (208), the at least one determined thread log data based on the one or more configured parameters.

6. The method (600) as claimed in claim 5, wherein the one or more extracted parameters include at least one of a process identifier (ID), a thread identifier (ID), and a module identifier (ID).

7. The method (600) as claimed in claim 5, wherein the one or more extracted parameters are configured through a user interface (UI) during a runtime of the at least one process.

8. The method (600) as claimed in claim 5, further comprising creating at least one file associated with the at least one dumped thread log data.

9. A user equipment (UE) (104) communicatively coupled to a network (106), the coupling comprising steps of:
receiving, by the network (106), at least one request corresponding to at least one process from the UE (104);
wherein the network is configured to:
extract one or more parameters from the received at least one request;
configure the one or more extracted parameters to determine at least one thread log data associated with the at least one process;
dump the at least one determined thread log data based on the one or more configured parameters; and
transmit the at least one dumped thread log data to the UE (104).