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 DETECTING ANOMALIES IN A CALL FLOW OF 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
[001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, integrated circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (herein after referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
TECHNICAL FIELD
[002] The present disclosure relates generally to a field of wireless communication networks. More particularly, the present disclosure relates to a system and a method for detecting anomalies in a call flow of an Internet Protocol (IP) multimedia subsystem (IMS) network.
DEFINITION
[003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[004] The term “Internet protocol (IP) Multimedia Subsystem (IMS) network,” as used herein, refers to standardized architectural framework used in telecommunications networks to provide voice (e.g., Voice over IP (VoIP)), multimedia services (e.g., text messages), and other real-time services. The IMS network enables network operators and service providers to deliver a wide range of multimedia and real-time services to network subscribers over IP networks.
[005] The term “Session Initiation Protocol (SIP),” as used herein, refers to a signaling protocol used to create, modify, and terminate multimedia sessions in IMS networks. The SIP is responsible for establishing communication sessions between network identities and managing the flow of multimedia content.
[006] The term “call flow” as used herein, refers to a sequence of signaling messages exchanged between network entities during the establishment, modification, and termination of a multimedia session within the IMS network. The call flow includes the interactions and transactions that occur as a result of SIP requests and responses between various network components.
[007] The term “anomaly” as used herein, refers to an irregularity or deviation from the expected behavior or outcome in the call flow within the IMS network. The anomaly may be an unexpected failure, error, or quality issue that disrupts the normal operation of a communication session. Examples of anomalies include, but are not limited to, call setup failures, call release failures, media quality issues, call routing errors, and signaling errors. These anomalies can impact the performance and reliability of the network and may be identified through detailed analysis of call detail record (CDR).
[008] The term “Call Detail Record (CDR),” as used herein, refers to a record generated by telecommunication network elements and interfaces that documents various attributes of a voice call or other telecommunication transactions, such as text messages. The CDR typically include information about the duration, origin, destination, and other details related to the call or transaction.
[009] The term “clear code identifier” as used herein, refers to a ten digit code inserted into a CDR that provides a standardized representation of the outcome of a call flow. The clear code identifier includes multiple data fields that categorize the result of the call flow, including success, internal or external failure, and detailed error or response information.
[0010] The term “SIB Module” refers to a network component within the IMS network, specifically the Serving Call Session Control Function (S-CSCF), Interrogating Call Session Control Function (I-CSCF), or Breakout Gateway Control Function (BGCF) collectively refer to as a SIB module. The SIB modules are involved in managing and processing SIP messages and sessions within the IMS network.
[0011] The term “Serving Call session control function (S-CSCF)” refers to a network component that is configured for managing sessions in an IMS architecture. The S-CSCF is responsible for managing and controlling the signaling and session control processes for voice and multimedia sessions. It handles tasks such as routing SIP messages, managing user sessions, enforcing service policies, and interacting with other IMS network elements to establish, modify, and terminate multimedia sessions.
[0012] The term “Interrogating Call Session Control Function (I-CSCF)” refer to a network component in the IMS architecture that performs a role of querying and routing incoming SIP requests to the appropriate Serving Call Session Control Function (S-CSCF). The I-CSCF is responsible for querying the Home Subscriber Server (HSS) to retrieve user profile information and determining the correct S-CSCF to handle the request based on the user’s profile and session requirements.
[0013] The term “Breakout Gateway Control Function (BGCF)” refer to a network component in the IMS architecture that manages the interworking between the IMS network and other external networks, such as the Public Switched Telephone Network (PSTN) or other telecommunication networks. The BGCF handles the breakout of calls from the IMS network to external networks and performs functions such as routing, signaling, and media handling.

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. 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] The network operators and service providers deploy an internet protocol (IP) multimedia subsystem (IMS) network to deliver different multimedia and real-time services to network subscribers. The key element in the IMS framework is a Session Initiation Protocol (SIP). The SIP is a signaling protocol selected by 3rd Generation Partnership Project (3GPP) to create and control multimedia sessions between multiple network identities participating in the multimedia session of the IMS network.

[0017] During network operation, various network entities involved in a session are configured to send information for developing a Call Detail Record (CDR). The CDRs are generated by the calls conducted over telecommunication network elements and interfaces. The CDRs are used to document various attributes of a voice call or other telecommunication transaction (e.g., text message) that pass through those telecommunication network elements. The generated CDRs are used for various purposes by a network operator, such as billing, analytics, logging, law enforcement, investigations etc. The analysis of the CDR data provides information related to the voice call monitoring, such as inbound calls, outbound calls, dropped calls, abandoned calls, and unanswered calls. The CDR data helps the network operators to track details of various telecommunication activities of the network subscribers so that the network operator can make necessary changes to improve productivity and efficiency at all service levels.

[0018] Conventional techniques for analyzing the information from the CDRs, are cumbersome and time consuming for the network operators since these techniques need extensive measures such as log checking and tracing for analyzing the CDR data. Further, the manual and extensive nature of these techniques may lead to delays in detecting and resolving issues or anomalies in the IMS call flows, which may affect network performance and service quality.

[0019] There is, therefore, a need for a system and a method that overcomes the limitations of the prior art.

SUMMARY
[0020] In an exemplary embodiment, a method for detecting anomalies in a call flow of an internet protocol (IP) multimedia subsystem (IMS) network is disclosed. The method includes receiving, by a processing engine, at least one call detail record (CDR) associated with the call flow from a user equipment (UE). The method further includes inserting, by the processing engine, at least one clear code identifier in the at least one received CDR to generate at least one modified CDR. The at least one clear code identifier comprises a plurality of data fields. The method further includes analyzing, by the processing engine, the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network.

[0021] In some embodiments, the at least one clear code identifier includes a predefined structure having ten digits.

[0022] In some embodiments, a first data field of the plurality of data fields in the at least one clear code identifier indicates an outcome of the call flow, and the outcome of the call flow comprises one of an internal failure due to an internal error, an external failure due to an external error, and a successful completion of the call flow.

[0023] In some embodiments, the first data field of the plurality of data fields is positioned at a first position from a left side of the at least one clear code identifier, such that the first data field starting with a numeric value ‘1’ indicates the internal failure generated due to the internal error within at least one internal module, wherein the first data field starting with a numeric value ‘2’ indicates the external failure received from an external network interface, and wherein the first data field starting with a numeric value ‘3’ denotes the successful completion of the call flow.

[0024] In some embodiments, for the internal failure, a second data field and a third data field of the plurality of data fields in combination indicate the at least one internal module causing the internal failure.

[0025] In some embodiments, for the external failure, the second data field and the third data field of the plurality of data fields in combination indicate the external network interface and a protocol of at least one external source responsible for causing the external failure.

[0026] In some embodiments, a fourth data field, a fifth data field, a sixth data field, and a seventh data field of the plurality of data fields in combination indicate either at least one internal response generated by the at least one internal module, or at least one external response received by the at least one external network interface.

[0027] In some embodiments, an eighth data field, a ninth data field, and a tenth data field of the plurality of data fields in combination indicate a final response of a session initiation protocol (SIP) associated with the at least one internal module, and the final response represents at least one of a successful transaction or a failure transaction associated with the SIP.

[0028] In some embodiments, the at least one anomaly comprises one of a call setup failure, a call release failure, a media quality issue, a call routing error, and a signaling error.

[0029] In another exemplary embodiment, a system for detecting anomalies in a call flow of an internet protocol (IP) multimedia subsystem (IMS) network is described. The system comprises a memory, and a processing engine communicatively coupled with the memory, configured to receive at least one call detail record (CDR) associated with the call flow from a user equipment (UE). The processing engine is further configured to insert at least one clear code identifier in the at least one received CDR to generate at least one modified CDR. The at least one clear code identifier comprises a plurality of data fields. The processing engine is further configured to analyze the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network.

[0030] In another exemplary embodiment, a user equipment (UE) is described. The UE is communicatively coupled with an internet protocol (IP) multimedia subsystem (IMS) network, the coupling comprises steps of receiving, by the IMS network, a connection request from the UE, sending, by the IMS network, an acknowledgment of the connection request to the UE and transmitting a plurality of signals in response to the connection request, the IMS network is configured for performing a method for detecting anomalies in a call flow of the IMS network. The method includes steps of receiving, by a processing engine, at least one call detail record (CDR) associated with the call flow from a user equipment (UE). The method further includes inserting, by the processing engine, at least one clear code identifier in the at least one received CDR to generate at least one modified CDR. The at least one clear code identifier comprises a plurality of data fields. The method further includes analyzing, by the processing engine, the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network.

OBJECTIVES OF THE PRESENT DISCLOSURE
[0031] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0032] An objective of the present disclosure is to provide a system and a method for analyzing a call flow of an internet protocol (IP) multimedia subsystem (IMS) network.
[0033] Another objective of the present disclosure is to provide a system and a method for detecting anomalies in the call flow of the IMS network.
[0034] Another objective of the present disclosure is to provide a system and a method in which a clear code identifier is implemented in a Call Detail Record (CDR) for analyzing and troubleshooting the call flow of the IMS network.
[0035] Another objective of the present disclosure is to implement the clear code identifier in the CDR to enhance the efficiency and accuracy of troubleshooting processes in the IMS network.
[0036] Another objective of the present disclosure is to provide a system and method that reduces the time and effort required to analyze the call flow by automating the categorization of call flow outcomes and errors.
[0037] 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

[0038] 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.
[0039] FIG. 1 illustrates an exemplary network architecture for implementing a system for detecting anomalies in a call flow of an internet protocol (IP) multimedia subsystem (IMS) network, in accordance with an embodiment of the present disclosure.
[0040] FIG. 2A illustrates an exemplary block diagram of the system configured for detecting anomalies in the call flow of the IMS network, in accordance with an embodiment of the present disclosure.
[0041] FIG. 2B illustrates an exemplary system architecture of the system for detecting anomalies in the call flow of the IMS network, in accordance with an embodiment of the present disclosure.
[0042] FIG. 3 illustrates an exemplary format of a clear code identifier to be inserted in a call detail record (CDR), in accordance with an embodiment of the present disclosure.
[0043] FIG. 4 illustrates an exemplary flow diagram of a method for detecting anomalies in the call flow of the IMS network, in accordance with an embodiment of the present disclosure.
[0044] FIG. 5 illustrates an example computer system in which or with which the embodiments of the present disclosure may be implemented.
[0045] The foregoing shall be more apparent from the following more detailed description of the disclosure.

LIST OF REFERENCE NUMERALS
100 – Network architecture
102 – Users
104 – User Equipment
106 – Network
108 – System
200A – Block Diagram
202 – Processor(s)
204 – Memory
206 – Interfaces(s)
208 – Processing engine
210 – Receiving unit
212 – Provisioning unit
214 – Database
200B – System architecture
216 – Evolved Packet Core (EPC) Network
218 – Internet protocol (IP) Multimedia Subsystem (IMS) Network
220 – Other Network Node
300 – An exemplary format of a Clear Code Identifier
400 – Flow diagram
500 – Computer System
510 – External Storage Device
520 – Bus
530 – Main Memory
540 – Read Only Memory
550 – Mass Storage Device
560 – Communication Port
570 – Processor
DETAILED DESCRIPTION
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] As the wireless technologies are advancing, there is a need to cope up with the 5G requirements and deliver a high level of service to the customers. Thus, analyzing the call flow data outcome of an internet protocol (IP) multimedia subsystem (IMS) network is becoming crucial day by day. The call flow outcome of the IMS network includes troubleshooting and analyzing the details of successful calls, and failed calls that occurred at a call detail record (CDR) of the UE in the wireless network. Further, there is a need to efficiently identify the exact location of the anomalies such as call failure errors (e.g., call setup failure, a call release failure, a media quality issue, a call routing error, and a signaling error) in the CDR and debug the identified error as soon as possible. The existing techniques for troubleshooting and analyzing the call flow data outcome of the IMS network are inefficient since these techniques require analyzing and log checking of the CDR, and then tracing and identifying the location of the call failure errors in the analyzed CDR. Thus, the available techniques result in a time consuming and a complex approach for analyzing the call flow data outcomes of the IMS network, particularly when the wireless network is facing multiple call failure errors and when there is a requirement to analyze a huge amount CDR. Further, the available techniques are not efficient and are generally failed to locate the call failure errors in the CDR, especially during the need of providing real-time support to the mobile customers.
[0059] Accordingly, the present disclosure aims to overcome the above-mentioned problems by providing an improved system and a method that facilitates an efficient approach for analyzing and detecting anomalies in the call flow outcomes of the IMS network, thereby speeding up the troubleshooting process.
[0060] The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1 – FIG. 5.
[0061] FIG. 1 illustrates an exemplary network architecture (100) for implementing a system (108) for detecting anomalies in a call flow of the IMS network, in accordance with an embodiment of the present disclosure. In an embodiment, the IMS network (i.e., a network 106), for example may be a wireless network, a Long-Term Evolution (LTE) network, a Fourth Generation (4G) network, a Fifth Generation (5G) network, a Sixth Generation (6G) network, and the like.
[0062] 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 UEs (104). Although only three UEs (104) are depicted in FIG. 1, however, any number of the UEs (104) may be included without departing from the scope of the ongoing description.
[0063] In an embodiment, the UEs (104) may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UEs (104) may include, but are 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 UEs (104) may include, but not limited to, intelligent, multi-sensing, network-connected devices, that may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0064] Additionally, in some embodiments, the UEs (104) may include, but 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 UEs (104) may include, but are 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 UEs (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.
[0065] Referring to FIG. 1, the UEs (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 comprise the IMS network. 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.
[0066] In FIG. 1, the UE (104) may communicate with the system (108) through the network (106). In particular, the UE (104) may be communicatively coupled with the network (106). The coupling including steps of receiving, by the network (106), a connection request from the UE (104). Upon receiving the connection request, the coupling including steps of sending, by the network (106), an acknowledgment of the connection request to the UE (104). Further, the coupling including steps of transmitting a plurality of signals in response to the connection request. The plurality of signals is responsible for communicating with the system (108) to detect anomalies in the call flow of the network (106) (e.g., IMS network).
[0067] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0068] 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).
[0069] FIG. 2A illustrates an exemplary block diagram (200A) of the system (108), in accordance with an embodiment of the present disclosure.
[0070] Referring to FIG. 2A, in an embodiment, the system (108) may include one or more processor(s) (202). 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 a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0071] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output 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 (214).
[0072] In an embodiment, the processing engine (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine (208). In 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.
[0073] In an embodiment, the database (214) 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). In an embodiment, the database (214) may be indicative of including, but not limited to, a relational database, a distributed database, a cloud-based database, or the like.
[0074] In an embodiment, the processing engine (208) may include a plurality of units. The plurality of units of the processing engine (208) may include, but is not limited to, a receiving unit (210), and a provisioning unit (212).
[0075] The receiving unit (210) is configured to receive at least one call detail record (CDR) associated with the call flow from the UE (104). The CDR may include information related to the call. For example, if the UE (104) initiates a call, the CDR may include data relevant to that particular call session, such as a time when the call is initiated, a duration of the call setup phase, a signaling messages exchanged during the call setup, details about the end of the call, including the reason for termination (e.g., normal hang-up, or dropped call) and the time the call ended, and information on any anomalies or errors that occurred during the call. The receiving unit is configured with communication protocols such as Session Initiation Protocol (SIP) or Diameter to receive the CDRs. Once received, the receiving unit parses the CDRs to extract relevant details, such as call duration, timestamps, and identifiers. This information is then stored in the database or processed in real-time to facilitate network monitoring, analysis, and reporting.
[0076] In particular, the CDR may include call identification information, which includes a unique Call Identifier (ID) and identifiers for the UE involved in the call. The information helps in tracking and referencing the specific call session. Further, the CDR may include the call session details, which captures the start time and end time of the call, as well as the total duration of the call session. This allows for precise measurement of how long the call lasted and the timing of events during the call. Further, the CDR may include call type, indicating whether the call is voice, video, text, or a combination of these services. Additionally, the CDR may include the session type, noting whether the session is incoming or outgoing.
[0077] Further, the CDR may include information about the network details, which includes the IMS network that handles the call, such as Serving Call Session Control Function (S-CSCF), Interrogating Call Session Control Function (I-CSCF), and Breakout Gateway Control Function (BGCF). It also covers the network interfaces used during the call. Further, the CDR may include protocol information, which is crucial for understanding the communication process, detailing session initiation protocol (SIP) methods, responses, and status codes. The CDR may also include signaling and media protocols used throughout the call session. Further, the CDR may include the call flow data which include logs events occurring during the call, such as call setup, call transfer, and call termination. Furthermore, the CDR may include details about any errors or failures during the call and assesses the call quality by documenting metrics such as latency, jitter, and packet loss.
[0078] Once the CDR is received from the UE (104), the provisioning unit (212) in communication with the processing engine (208) is configured to insert at least one clear code identifier in the at least one received CDR to generate at least one modified CDR. The insertion process may involve embedding the clear code identifier into the received CDR. The provisioning unit (212) may analyze the received CDR to determine the appropriate placement for the at least one clear code identifier, which could be based on predefined rules or call attributes. The predefined rules and call attributes are essential in determining the insertion of clear code identifiers into the CDRs. The predefined rules are established criteria that guide the insertion process based on specific conditions, such as the type of service used, geographical location, or call duration. For instance, a rule may specify that any CDR related to international calls should include a particular identifier for regulatory tracking. Call attributes, on the other hand, encompass the metadata associated with each call, including the caller identifier (ID), timestamp, call type (voice, video, or data), destination number, and network type (like 4G or 5G). The provisioning unit may modify the CDR structure by either adding a new field specifically for the identifier or updating an existing field, while maintaining compliance with the CDR format to ensure interoperability with other systems present in the network. After insertion, the at least one modified CDR undergoes validation to confirm that the at least one clear code identifier is accurately integrated and does not disrupt the overall integrity of the record. The at least one clear code identifier includes a predefined structured data format that includes a plurality of data fields (e.g., ten digits), each serving a specific purpose in categorizing and detailing the outcomes of the call flow. In particular, the at least one clear code identifier (also referred to as a ten digit clear code identifier) includes ten distinct data fields i.e., a first data field, a second data field, a third data field, and so forth up to the tenth data field. Each data field is designed to capture and encode particular information about the call flow outcomes once inserted into the CDR.
[0079] Following the insertion of the at least one clear code identifier, the provisioning unit (212) in communication with the processing engine (208) may further analyze the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network. The at least one anomaly includes one of a call setup failure, a call release failure, a media quality issue, a call routing error, and a signaling error. For example, if a call is unexpectedly dropped, the analysis may reveal whether the issue was due to a setup failure or a media quality problem. In a more elaborate way, once the clear code identifier has been inserted into the received CDR, the result is the at least one modified CDR that incorporates the plurality of data fields designed to provide a detailed outcomes of the call flow. The at least one modified CDR may include ten specific data fields, each serving a distinct purpose in representing detailed outcomes of the call flow (e.g., entire lifecycle of a call, including initiation, management, and termination) along with potential anomalies or quality issues that may arise throughout the call flow. The at least one modified CDR may help network operators to diagnose issues more precisely. For example, the at least one modified CDR may differentiate between internal errors (e.g., problems within network components like S-CSCF, I-CSCF, BGCF) and external errors (e.g., issues originating from external network interfaces). The detailed outcomes of the call flow may be presented once the process of analyzing the at least one modified CDR is completed.
[0080] The process of analyzing the at least one modified CDR may include examining each of the data fields to identify any anomalies in the call flow of the IMS network. Each data field of the plurality of data field within the at least one modified CDR may encode critical information that may help in resolving one or more call failure issues in the call flow.
[0081] By way of an example, the first data field in the at least one modified CDR indicates the overall outcome of the call flow. The outcome of the call flow may be categorized into one of an internal failure, an external failure, or a successful completion of the call flow. The internal failure signifies an error originating within the IMS network components, such as the S-CSCF, I-CSCF, or BGCF (collectively referred to as SIB modules). The external failure represents an error caused by an external source, such as an external network interface or service provider (e.g., Internet Service Providers (ISPs), Voice over IP (VoIP) Providers, Public Switched Telephone Network (PSTN) Gateways, and roaming networks). Additionally, the successful completion indicates that the call flow proceeded without any issues.
[0082] In an example, the first data field of the plurality of data fields is positioned at a first position from a left side of the at least one clear code identifier, such that the first data field starting with a numeric value ‘1’ indicates the internal failure generated due to the internal error within at least one internal module, wherein the first data field starting with a numeric value ‘2’ indicates the external failure received from an external network interface, and wherein the first data field starting with a numeric value ‘3’ denotes the successful completion of the call flow.
[0083] For the internal failures, the combination of the second and third data fields specifies the name of the internal modules (e.g., the SIB modules) responsible for the error or issue. For example, if the S-CSCF module encountered an issue, the clear code would reflect this by indicating the S-CSCF as the source of the failure. This may allow precise identification of which internal module needs to be addressed.
[0084] In the case of external failures, the second and third data fields indicate the external network interface, and the protocol included. For instance, if the failure is due to a problem with an external network interface, such as a Public Switched Telephone Network (PSTN) gateway connecting the IMS network to traditional phone networks, these data fields may indicate the specific PSTN gateway (e.g., PSTN-Gateway-01) and the signaling protocol (e.g., Integrated Services Digital Network (ISDN) User Part or Signaling System No. 7 (SS7)) involved in the failure. If the failure is related to SIP communication with an external Voice over Internet Protocol (VoIP) service provider, these data fields may provide details about the SIP protocol version (e.g., SIP v2.0) and the external VoIP service (e.g., SIP Provider ABC).
[0085] The fourth data field, fifth data field, sixth data field, and seventh data field of the clear code identifier collectively represent either internal responses generated by the internal modules or external responses received from the external interfaces. Examples of internal responses may include status updates that reflect the success or failure of various operations within the IMS network. For example, a response from the S-CSCF may indicate whether a session initiation request is processed successfully or encountered an error. Further, the internal responses may include error codes that provide diagnostic information about specific problems encountered during call processing, such as failures in call setup or routing issues. Additionally, the internal response may include system logs detailing significant events, warnings, and errors generated by the internal modules, which are crucial for understanding the sequence of events leading to an anomaly. Furthermore, the interaction details between the internal modules, including messages exchanged between the S-CSCF and I-CSCF during a call session, may also help in tracing the call flow and identify any discrepancies or communication issues that may have contributed to the anomaly.
[0086] External responses, on the other hand, may involve interactions between the IMS network and external interfaces or systems. These final responses may include network interface responses, which are acknowledgments or errors received from the external systems with which the IMS network communicates. For example, if the IMS network sends a request to an external application server, the response from that server, whether success or failure, is recorded. Protocol messages are also part of external responses, including SIP responses from external systems that indicate the outcome of transactions with external entities, such as the success or failure of call setup. External error codes provide information related to problems originating outside the IMS network, such as connectivity issues or service availability problems. Additionally, data exchange logs track the flow of information between the IMS network and external systems, helps to identify discrepancies or issues in external interactions that may lead to anomalies in the call flow.
[0087] By analyzing both the internal and external responses, the processing engine may determine whether the responses contributed to any anomalies detected in the call flow. This analysis may allow for effective diagnosis and resolution of issues by distinguishing between the internal issues and external network-related issues.
[0088] Finally, the eighth, ninth, and tenth data fields together indicate the final response of the session initiation protocol (SIP) sent by the SIB modules to the IMS network. The final response signifies whether the SIP transaction associated with the call is successful or failed. For example, a final response may indicate that a call setup is completed successfully or that a failure occurred, providing a complete view of the SIP transaction’s outcome. The final response may be a success message (such as, a SIP 200 OK) indicating that the request is successfully processed, or an error message (such as, a SIP 4xx or 5xx series response) indicating different types of errors or failures.
[0089] Therefore, by analyzing the at least one modified CDR with the plurality of data fields, the provisioning unit (212) may identify various anomalies such as call setup failures, call release failures, media quality issues, call routing errors, and signaling errors. For instance, if the final SIP response indicates a failure and the internal response fields point to an error generated by the S-CSCF module, this analysis reveals potential issues (e.g., malfunctioning network components, misconfigurations, or disruptions in the signaling pathways) within the IMS network. This approach to analyzing the at least one modified CDR ensures that anomalies are detected with greater accuracy and that their root causes are more easily identified.
[0090] Although FIG. 2A shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2A. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).
[0091] Referring to FIG. 2B, an exemplary system architecture (200B) for detecting anomalies in the call flow of the IMS network (218) is illustrated, in accordance with an embodiment of the present disclosure. In an embodiment, the IMS network (218) may correspond to the network (106) of FIG. 1.
[0092] A long-term evolution radio access network (LTE RAN) includes a user equipment (UE) (104) that is connected to an Evolved Packet Core (EPC) network (216) for establishing a calling session to an enhanced Node B (eNodeB) (not shown in FIG. 2B). The EPC network (216) is configured to provide inter alia control of radio access within the LTE RAN. The EPC network (216) includes various components (not shown in FIG. 2B) such as home subscriber server (HSS) component, serving gateway (S-GW), packet data network (PDN) Gateway (P-GW), and mobility management entity (MME). The HSS component has been carried forward from Universal Mobile Telecommunications System (UMTS) and Global System for Mobile Communications (GSM) and is a central database that contains information about all the network operator's subscribers. The P-GW communicates with the packet data networks, using Service Gateway Interface. Each PDN is identified by an access point name (APN). The P-GW performs the same role as the General Packet Radio Services (GPRS) support node (GGSN) and the serving GPRS support node (SGSN) with UMTS and GSM. The serving gateway (S-GW) acts as a router, and forwards data between the eNodeB and the P-GW.
[0093] A Policy Control and Charging Rules Function (PCRF) is a component which is responsible for policy control decision-making, as well as for controlling the flow-based charging functionalities in the Policy Control Enforcement Function (PCEF), which resides in the P-GW. The P-GW interfaces with other packet data networks, e.g., the IMS network (218). The IMS network (218) is configured to deliver multimedia communications services such as voice, video and text messaging over IP networks and thus is configured to interface with another network node (220). In an example a proxy call session control function (P-CSCF) node acts as an entry point of the IMS network (218). The UE (104) is registered with the P-CSCF node.
[0094] Within the IMS network (218), several types of Session Initiation Protocol (SIP) servers known as CSCF are used to process SIP signaling packets in the IMS network (218) domain. 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 the first point of contact for the IMS network (218), and the P-CSCF forwards the registration requests received from the UE (104) 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 S-CSCF is the central node of the signaling plane. The S-CSCF handles SIP registrations of the mobile users.
[0095] The IMS network (218) further includes a Breakout Gateway Control Function (BGCF) that is a SIP proxy server which includes routing functionality based on mobile customer telephone numbers. The BGCF provides breakout functionality in the IMS network (218) which allows communication between different networks, such as a packet-switched (PS) network and a circuit-switched (CS) network. The BGCF selects the network in which PSTN breakout functionality must occur. The BGCF is used for routing calls from the IMS network (218) to a phone in a Circuit Switched 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.
[0096] In a telecommunication network various network entities involved in a calling session are configured to send information for developing CDR during the network operation. The CDRs are generated by the calls conducted over telecommunication network elements and interfaces. The CDRs are used to document various attributes of a voice call or other telecommunication transaction (e.g., text message etc.,) that passes through that UE (104).
[0097] In an implementation, to analyze the call flow data outcome of the IMS network (218), the provisioning unit (212) receives the CDR from the UE (104) via the IMS network (218). The provisioning unit (212) is configured to insert the clear code identifier in the CDR to generate the at least one modified CDR. The provisioning unit (212) is configured to analyze the at least one modified CDR with the inserted clear code identifier having a plurality of data fields. The clear code identifier helps the network operator to identify and debug the errors due to failed calls in the IMS network (218). The clear code identifier provides an efficient technique for identifying and addressing the successful and failed calls in the IMS network (218) which enhances the development productivity and minimizes downtime caused by troubleshooting the call data flow outcomes of the IMS network (218).
[0098] Referring to FIG. 3 an exemplary format (300) of the clear code identifier inserted in the CDR is illustrated, in accordance with an embodiment of the present disclosure.
[0099] In an aspect, the clear code identifier may include a plurality of data fields. In an implementation, the clear code identifier includes a unique ten digit code in a format “xxxxxxxxxx” that provides categorization of the call flow outcomes of the IMS network (218).
[00100] In an implementation, a first data field ‘1’ (302) (e.g., 1-digit) of the ten digit clear code identifier indicates a nature of the call flow data outcome. For example, the first data field starting with a numeric value ‘1xxxxxxxxx’ denotes an internal error generated due to an internal voice call failure that occurs within S-CSCF, I-CSCF and BGCF (SIB) module of the IMS network (218). Further, the first data field starting with a numeric value ‘2xxxxxxxxx' denotes a voice call failure due to an external error received from an external network interface of an external source. Further, the first data field starting with a numeric value '3xxxxxxxxx' denotes a successful completion of a call in the IMS network (218).
[00101] In an implementation, a second data field and a third data field (e.g., 2-digits) of the clear code identifier in combination indicate the details of an external network interface and a protocol of the external source responsible for the occurrence of the external voice call failure in the IMS network (218).
[00102] In an implementation, the second data field and the third data field (e.g., 2-digits) of the clear code identifier in combination indicate the details of the SIB module name (304) responsible for causing the internal voice call failure in the IMS network (218).
[00103] In an implementation, a fourth data field, a fifth data field, a sixth data field, and a seventh data field (e.g., 4-digits) of the clear code identifier in combination indicates internal codes (306) generated by SIB module for each voice call of the call flow data outcome of the IMS network (218).
[00104] In another implementation, the fourth data field, the fifth data field, the sixth data field, and the seventh data field of the clear code identifier indicates external codes received by the external interfaces for each voice call of the call flow data outcome of the IMS network (218).
[00105] In an implementation, an eighth data field, a ninth data field, and a tenth data field (e.g., 3-digits) of the clear code identifier in combination indicates a final response of a session initiation (SIP) protocol (308) sent by the SIB module to the IMS network (218).
[00106] As will be appreciated, although ten digits have been described, the clear code identifier may have more than ten or less than ten digits, in one or more embodiments of the present disclosure.
[00107] Therefore, each data fields of the clear code identifier inserted into the CDR provides a simplified and efficient solution for troubleshooting the missed and failed calls in the call flow data of the IMS network (218). Further, the debugging time for locating the errors generated due to the failed calls in the call flow data can be reduced since the exact location of failed call errors in the call flow data of the IMS network (218) may be identified. Therefore, the overall reliability of the telecommunication network can be increased.
[00108] FIG. 4 illustrates an example flow diagram of a method (400) for detecting anomalies in the call flow of the IMS network (218), in accordance with an embodiment of the present disclosure.
[00109] At step (402), the method (400) includes receiving, by a processing engine, at least one call detail record (CDR) associated with the call flow from the UE (104). The CDR may include information related to the call. For example, if the UE (104) initiates a call, the CDR may include data relevant to that particular call session, such as a time when the call is initiated, a duration of the call setup phase, a signaling messages exchanged during the call setup, details about the end of the call, including the reason for termination (e.g., normal hang-up, dropped call) and the time the call ended, and information on any anomalies or errors that occurred during the call.
[00110] At step (404), the method (400) includes inserting, by the processing engine, at least one clear code identifier in the at least one received CDR to generate at least one modified CDR. The at least one clear code identifier includes a predefined structure having a plurality of data fields (e.g., ten digits). The plurality of data fields includes a first data field, a second data field, a third data field, a fourth data field, a fifth data field, a sixth data field, a seventh data field, an eighth data field, a ninth data field, and a tenth data field.
[00111] At step (406), the method (400) includes analyzing, by the processing engine, the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network. In an embodiment, the at least one anomaly includes one of a call setup failure, a call release failure, a media quality issue, a call routing error, and a signaling error.
[00112] In some embodiments, the first data field of the plurality of data fields in the at least one clear code identifier indicates an outcome of the call flow, and the outcome of the call flow comprises one of an internal failure due to an internal error, an external failure due to an external error, and a successful completion of the call flow.
[00113] In some embodiments, the first data field of the plurality of data fields is positioned at a first position from a left side of the at least one clear code identifier, such that the first data field starting with a numeric value ‘1’ indicates the internal failure generated due to the internal error within at least one internal module. The first data field starting with a numeric value ‘2’ indicates the external failure received from an external network interface. Further, the first data field starting with a numeric value ‘3’ denotes the successful completion of the call flow.

[00114] In some embodiments, for the internal failure, the second data field and the third data field of the plurality of data fields in combination indicate the at least one internal module causing the internal failure.

[00115] In some embodiments, for the external failure, the second data field and the third data field of the plurality of data fields in combination indicate the external network interface and a protocol of at least one external source responsible for causing the external failure.

[00116] In some embodiments, the fourth data field, the fifth data field, the sixth data field, and the seventh data field of the plurality of data fields in combination indicate either at least one internal response generated by the at least one internal module, or at least one external response received by the at least one external network interface.
[00117] In some embodiments, the eighth data field, the ninth data field, and the tenth data field of the plurality of data fields in combination indicate a final response of a session initiation protocol (SIP) associated with the at least one internal module, and the final response represents at least one of a successful transaction or a failure transaction associated with the SIP.

[00118] In one exemplary embodiment, the present disclosure discloses the UE (104) communicatively coupled with the IMS network (218). The coupling comprises steps of receiving, by the IMS network (218), a connection request from the UE (104), sending, by the IMS network (218), an acknowledgment of the connection request to the UE (104) and transmitting a plurality of signals in response to the connection request. The IMS network (218) is configured for performing a method (400) for detecting anomalies in the call flow of the IMS network (218). The method (400) includes steps of: receiving (402), by a processing engine (208), at least one call detail record (CDR) associated with the call flow from the UE (104). The method (400) further includes inserting (404), by the processing engine (208), at least one clear code identifier in the at least one received CDR to generate at least one modified CDR. The at least one clear code identifier includes a plurality of data fields. The method (400) further includes analyzing (406), by the processing engine (208), the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network (218).
[00119] FIG. 5 illustrates an exemplary computer system (500) in which or with which embodiments of the present disclosure may be implemented.
[00120] As shown in FIG. 5, the computer system 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.
[00121] 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.
[00122] 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 (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (570) to the computer system.
[00123] 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.
[00124] 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.
[00125] The present disclosure provides technical advancement related to the analysis and troubleshooting of call flows within the IMS network. This advancement addresses the limitations of existing solutions by introducing a clear code identifier integrated into the CDRs. The disclosure involves the inventive aspect of using a ten digit clear code that categorizes call flow outcomes into internal failures, external failures, and successful completions, with detailed information about errors and responses. This approach offers significant improvements in troubleshooting efficiency, accuracy in identifying anomalies, and overall network management. By implementing the clear code identifier in the CDR, the disclosed invention enhances the ability to detect and analyze issues in IMS call flows, resulting in faster resolution of network problems, improved network performance, and better service quality for end-users.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00126] The present disclosure provides a system and a method for detecting anomalies in the call flow of an internet protocol (IP) multimedia subsystem (IMS) network.
[00127] The present disclosure provides a system and a method that enhances the troubleshooting by incorporating a clear code identifier into a call detail record (CDR). The system allows for the categorization and identification of various call flow outcomes, including internal failures, external errors, and successful completions.
[00128] The present disclosure provides the clear code identifier for resolving issues within the IMS network by providing the exact location, nature and source of the at least one anomaly. This reduces the time and effort required for troubleshooting, thereby increasing overall operational efficiency.
[00129] The present disclosure improves accuracy in detecting the at least one anomaly by incorporating the clear code identifier into the CDR to categorize call flow outcomes, which helps in pinpointing specific issues or anomaly and understanding their impact on network performance.
[00130] Further, present disclosure reduces the debugging time for locating the call failure errors in the call flow of the IMS network, since the exact location of failed call errors in the call flow of the IMS network can be identified. Therefore, the overall reliability of the network is increased.

,CLAIMS:Claims
We claim:
1. A method (400) for detecting anomalies in a call flow of an internet protocol (IP) multimedia subsystem (IMS) network (218), the method (400) comprising:
receiving (402), by a processing engine (208), at least one call detail record (CDR) associated with the call flow from a user equipment (UE) (104);
inserting (404), by the processing engine (208), at least one clear code identifier in the at least one received CDR to generate at least one modified CDR, wherein the at least one clear code identifier comprises a plurality of data fields; and
analyzing (406), by the processing engine (208), the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network (218).

2. The method (400) as claimed in claim 1, wherein the at least one clear code identifier comprises a predefined structure having ten digits.

3. The method (400) as claimed in claim 1, wherein a first data field of the plurality of data fields in the at least one clear code identifier indicates an outcome of the call flow, and wherein the outcome of the call flow comprises one of an internal failure due to an internal error, an external failure due to an external error, and a successful completion of the call flow.

4. The method (400) as claimed in claim 3, wherein the first data field of the plurality of data fields is positioned at a first position from a left side of the at least one clear code identifier, such that the first data field starting with a numeric value ‘1’ indicates the internal failure generated due to the internal error within at least one internal module, wherein the first data field starting with a numeric value ‘2’ indicates the external failure received from an external network interface, and wherein the first data field starting with a numeric value ‘3’ denotes the successful completion of the call flow.

5. The method (400) as claimed in claim 3, wherein for the internal failure, a second data field and a third data field of the plurality of data fields in combination indicate the at least one internal module causing the internal failure.

6. The method (400) as claimed in claim 3, wherein for the external failure, the second data field and the third data field of the plurality of data fields in combination indicate the external network interface and a protocol of at least one external source responsible for causing the external failure.

7. The method (400) as claimed in claim 1, wherein a fourth data field, a fifth data field, a sixth data field, and a seventh data field of the plurality of data fields in combination indicate either at least one internal response generated by the at least one internal module, or at least one external response received by the at least one external network interface.

8. The method (400) as claimed in claim 1, wherein an eighth data field, a ninth data field, and a tenth data field of the plurality of data fields in combination indicate a final response of a session initiation protocol (SIP) associated with the at least one internal module, and wherein the final response represents at least one of a successful transaction or a failure transaction associated with the SIP.

9. The method (400) as claimed in claim 1, wherein the at least one anomaly comprises one of a call setup failure, a call release failure, a media quality issue, a call routing error, and a signaling error.

10. A system (108) for detecting anomalies in a call flow of an internet protocol (IP) multimedia subsystem (IMS) network (218), the system (108) comprising:
a memory (204); and
a processing engine (208) communicatively coupled with the memory (204), configured to:
receive at least one call detail record (CDR) associated with the call flow from a user equipment (UE) (104);
insert at least one clear code identifier in the at least one received CDR to generate at least one modified CDR, wherein the at least one clear code identifier comprises a plurality of data fields; and
analyze the at least one modified CDR to identify at least one anomaly in the call flow of the IMS network (218).

11. The system (108) as claimed in claim 10, wherein the at least one clear code identifier comprises a predefined structure having ten digits.

12. The system (108) as claimed in claim 10, wherein a first data field of the plurality of data fields in the at least one clear code identifier indicates an outcome of the call flow, and wherein the outcome of the call flow comprises one of an internal failure due to an internal error, an external failure due to an external error, and a successful completion of the call flow.

13. The system (108) as claimed in claim 12, wherein the first data field of the plurality of data fields is positioned at a first position from a left side of the at least one clear code identifier, such that the first data field starting with a numeric value ‘1’ indicates the internal failure generated due to the internal error within at least one internal module, wherein the first data field starting with a numeric value ‘2’ indicates the external failure received from an external network interface, and wherein the first data field starting with a numeric value ‘3’ denotes the successful completion of the call flow.

14. The system (108) as claimed in claim 12, wherein for the internal failure, a second data field and a third data field of the plurality of data fields in combination indicate the at least one internal module causing the internal failure.

15. The system (108) as claimed in claim 12, wherein for the external failure, the second data field and the third data field of the plurality of data fields in combination indicate the external network interface and a protocol of at least one external source responsible for causing the external failure.

16. The system (108) as claimed in claim 10, wherein a fourth data field, a fifth data field, a sixth data field, and a seventh data field of the plurality of data fields in combination indicate either at least one internal response generated by the at least one internal module, or at least one external response received by the at least one external network interface.

17. The system (108) as claimed in claim 10, wherein an eighth data field, a ninth data field, and a tenth data field of the plurality of data fields in combination indicate a final response of a session initiation protocol (SIP) associated with the at least one internal module, and wherein the final response, represents at least one of a successful transaction or a failure transaction associated with the SIP.

18. The system (108) as claimed in claim 10, wherein the at least one anomaly comprises one of a call setup failure, a call release failure, a media quality issue, a call routing error, and a signaling error.

19. A user equipment (UE) (104) communicatively coupled with an internet protocol (IP) multimedia subsystem (IMS) network (218), the coupling comprises steps of:
receiving, by the IMS network (218), a connection request from the UE (104);
sending, by the IMS network (218), an acknowledgment of the connection request to the UE (104); and
transmitting a plurality of signals in response to the connection request, wherein the IMS network (218) is configured to execute a method (400) for detecting anomalies in a call flow of the IMS network (218) as claimed in claim 1.