Method and system for voice call muting detection

Abstract

The present disclosure relates to method and system for detecting voice call muting The method includes establishing PDU session for communication between UE [102] and IMS [304], sending AAR message to PCF [122] to add custom IE for RTP, generating a SMPolicy update notification message comprising media-based rules, transmitting SMPolicy update notification message to SMF [108], identifying voice call for which muting to be identified, inserting custom field in the SMPolicy update notification message, creating PDR with custom field for identifying the RTP SDF for the voice call in response to SMPolicy Update Notification message, sending PFCP Session Modification Request to UPF, detecting muting event during the voice call, sending SDR messages indicating the occurrence of muting, correlating, the SDR messages to identify muting events, determining an occurrence of voice call muting events based on correlated data and generating KPI reports for call muting based on determined occurrences.

Description

METHOD AND SYSTEM FOR VOICE CALL MUTING DETECTIONTECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to wireless communication systems. More particularly, embodiments of the present disclosure relate to method and system for voice call muting detection in a communication system.BACKGROUND

[0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.

[0003] Wireless communication technology has rapidly evolved over the past few decades, with each generation bringing significant improvements and advancements. The first generation of wireless communication technology was based on analog technology and offered only voice services. However, with the advent of the second generation (2G) technology, digital communication and data services became possible, and text messaging was introduced. The third generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth generation (4G) technology revolutionized wireless communication with faster data speeds, better network coverage, and improved security. Currently, the fifth generation (5G) technology is being deployed, promising even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users.

[0004] In communication system, when two parties communicate over any channel, voice data travels in the form of packets. During the communication, call muting occurs frequently. ‘Call muting’ is a period that occurs between the call during which voice is not heard by any party (calling party and / or called party) due to packet loss or packet delay in network, frequent radio link failures, high RRC re-establishment time, frequent handover, or the like reasons. The network may face problem in detection of the call muting occurrence and often rely on radio side fordetection of call muting. The existing solution of call muting detection is neither efficient nor effective and is more dependent on radio side. Further, in the prior arts only limited number of calls can be analysed and during handover procedure, complete analysis for voice call muting detection is not possible.

[0005] Thus, there exists an imperative need in the art to provide an efficient system and method for detecting voice call muting.SUMMARY

[0006] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.

[0007] An aspect of the present disclosure may relate to a method for detecting voice call muting in a communication network. The method includes stabli shing, by a processing unit, a packet data unit (PDU) session for voice communication between a user equipment (UE) and an IP multimedia subsystem (IMS). Further, the method encompasses sending, by the IMS, an authentication and authorization request (AAR) message to a policy control function (PCF) to add a custom information element (IE) for a real-time transport protocol (RTP) rule. The method further encompasses generating, by the PCF, a session management policy (SMPolicy) update notification message comprising media-based rules, and transmitting the SMPolicy update notification message to a Session Management Function (SMF). The method further includes identifying, by the PCF, based on the media-based rules, a voice call for which muting is to be identified. Furthermore, the method includes inserting, by the PCF, a custom field in the SMPolicy update notification message. The method further includes creating, by the SMF, a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message. The method further encompasses sending, by the SMF, a packet forwarding control protocol (PF CP) Session Modification Request to the UPF comprising the PDR for initiating a voice call processing. The method further includes detecting, by a user plane function (UPF), a muting event during the voice call based on analysis of RTP SDF. Further, the method includes sending, by the UPF, a set of stream data record (SDR) messages indicating the occurrence and detection time of the muting event. The method further includes correlating, by the processing unit, the set of SDR messages from the UPF with corresponding PDR from the SMF to identify muting events. Furthermore, themethod encompasses determining, by the processing unit, an occurrence of voice call muting events based on the correlated data. Further, the method includes generating, by the processing unit, key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

[0008] In an exemplary aspect of the present disclosure, the method further comprises sending, by the PCF, a SMPolicy Update Notify Response message to the IMS following the transmission of the SMPolicy Update Notification to the SMF.

[0009] In an exemplary aspect of the present disclosure, the stream detail record (SDR) message comprises at least one of a timestamp flow creation, a timestamp flow deletion, a session identifier, a user identifier, a type of SDR flow, a direction of muting, and a UPF ID.

[0010] In an exemplary aspect of the present disclosure, detecting by the UPF, the muting event comprises comparing a difference of a talk-spurt and a silence spurt with a predefined mute threshold time.

[0011] In an exemplary aspect of the present disclosure, the generating of KPI reports, by the processing unit, is based on a predetermined criteria selected from the group consisting of Cellwise, Call-wise, State-wise, during Handover (HO) or No Handover (NO-HO), and Daily, Weekly, and Monthly intervals, wherein the predefined criteria comprises one of a muting occurrence, a HO Call analysis, and a Downlink Muting KPIs.

[0012] Another aspect of the present disclosure may relate to a system for detecting voice call muting in a communication network. The system includes a processing unit, configured to establish a packet data unit (PDU) session for voice communication between a user equipment (UE) and an Internet Protocol (IP) multimedia subsystem (IMS). Furthermore, the system includes an IMS to at least the processing unit, the IMS is configured to send an authentication and authorization request (AAR) message to a policy control function (PCF) to add a custom information element (IE) for a real-time transport protocol (RTP) rule. The system further encompasses a PCF. The PCF is configured to generate a session management policy (SMPolicy) update notification message comprising media-based rules, and transmitting the SMPolicy update notification message to a Session Management Function (SMF). The PCF further configured identify, based on the media-based rules, voice call for which muting is to be identified, and insert a custom field in the SMPolicy update notification message. Further the system includes the SMF.The SMF is configured to create a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message, and send a packet forwarding control protocol (PF CP) Session Modification Request to the UPF [comprising the PDR for initiating the voice call processing. Furthermore, the system includes a user plane function (UPF). The UPF is configured to detect a muting event during the voice call based on analysis of RTP SDF and send a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event. The system further includes a processing unit. The processing unit is configured to correlate the set of SDR messages from the UPF with corresponding PDR from the SMF to identify muting events, determine an occurrence of voice call muting events based on the correlated data, and generate key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

[0013] Yet another aspect of the present disclosure relates to a User Equipment for detecting voice call muting in a communication network, the UE comprising a processor. The processor is configured to establish, a packet data unit (PDU) session for voice communication between a user equipment (UE) and an IP multimedia subsystem (IMS). Furthermore, the processor is configured to send, to the IMS, an authentication and authorization request (AAR) message to a policy control function (PCF) to add a custom information element (IE) for a real-time transport protocol (RTP) rule. The processor is configured to facilitate generating key performance indicator (KPI) reports for the voice call muting, wherein the generation of KPI reports is based on generating, by the PCF, a session management policy (SMPolicy) update notification message comprising mediabased rules and transmitting the SMPolicy update notification message to a Session Management Function (SMF). The generation of the KPI reports is based on identifying, by the PCF, based on the media-based rules, a voice call for which muting is to be identified. Further, generation of the KPI reports is based on inserting, by the PCF, a custom field in the SMPolicy update notification message, generation of the KPI reports is based on creating, by the SMF, a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message. Also, the generation of the KPI reports is based on sending, by the SMF, a packet forwarding control protocol (PFCP) Session Modification Request to the UPF

[0106] comprising the PDR for initiating processing of the voice call. Furthermore, the generation of the KPI reports is based on detecting, by a user plane function (UPF), a muting event during the voice call based on analysis of RTP SDF. The generation of the KPI reports is based on sending, by the UPF, a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event. Furthermore, the generation ofthe KPI reports is based on correlating, by the processing unit, the set of SDR messages from the UPF with corresponding PDR from the SMF to identify muting events. The generation of the KPI reports is based on determining, by the processing unit, an occurrence of voice call muting events based on the correlated data. The generation of the KPI reports is based on generating, by the processing unit, key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

[0014] Yet another aspect of the present disclosure may relate to a non-transitory computer readable storage medium storing instructions for detecting voice call muting in a communication network, the instructions include executable code which, when executed by one or more units of a system, cause: a processing unit of the system to establish a packet data unit (PDU) session for voice communication between a user equipment (UE) and an IP multimedia subsystem (IMS). Further, the instructions include executable code which, when executed causes an IMS of the system to send an authentication and authorization request (AAR) message to a policy control function (PCF) to add a custom information element (IE) for a real-time transport protocol (RTP) rule. Further, the instructions include executable code which, when executed cause a PCF of the system to: generate a session management policy (SMPolicy) update notification message comprising media-based rules; and transmit the SMPolicy update notification message to a Session Management Function (SMF); identify, based on the media-based rules, voice call for which muting is to be identified; and insert a custom field in the SMPolicy update notification message. Further, the instructions include executable code which, when executed causes an SMF of the system to: create a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message; and send a packet forwarding control protocol (PFCP) Session Modification Request to the UPF comprising the PDR for initiating the voice call processing. Further, the instructions include executable code which, when executed causes a UPF of the system to detect a muting event during the voice call based on analysis of RTP SDF; and send a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event. Further, the instructions include executable code which, when executed causes the processing unit of the system to: correlate the set of SDR messages from the UPF with corresponding PDR from the SMF to identify muting events; determine an occurrence of voice call muting events based on the correlated data; and generate key performance indicator (KPI) reports for call muting based on the determined occurrences.OBJECTS OF THE INVENTION

[0015] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.

[0016] It is an object of the present disclosure to provide a system and a method for voice call muting detection.

[0017] It is another object of the present disclosure to provide a system and a method for voice call muting detection with 5G core network functions such as UPF, PCF and SMF without depending on radio side components of network.

[0018] It is another object of the present disclosure to provide a system and a method for voice call muting detection during handover between radio and also supports for all calls or specific region or subscriber or other conditions based on PCF, UPF and SMF based analysis for muting detection.DESCRIPTION OF THE DRAWINGS

[0019] 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. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system according to the disclosure are illustrated herein to highlight the advantages of the disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry commonly used to implement such components.

[0020] FIG. 1 illustrates an exemplary block diagram representation of 5th generation core (5GC) network architecture.

[0021] FIG. 2 illustrates an exemplary block diagram of a computing device upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.

[0022] FIG. 3 illustrates an exemplary block diagram of a system for detecting voice call muting in a communication network, in accordance with exemplary implementations of the present disclosure.

[0023] FIG. 4 illustrates a method flow diagram for detecting voice call muting in a communication network in accordance with exemplary implementations of the present disclosure.

[0024] FIG. 5 illustrates an exemplary embodiment of the system for voice call muting detection in a communication network, in accordance with exemplary implementations of the present disclosure.

[0025] FIG. 6 illustrates an exemplary sequence diagram indicating the process for voice call muting detection between two parties in communication system where the PDU session is pre- established, in accordance with exemplary implementations of the present disclosure.

[0026] FIG. 7 illustrates an exemplary sequence diagram indicating the process for voice call muting detection between two parties in communication system in case of an existing ongoing call, in accordance with exemplary implementations of the present disclosure.

[0027] The foregoing shall be more apparent from the following more detailed description of the disclosure.DETAILED DESCRIPTION

[0028] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter may each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above.

[0029] 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 bemade in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0030] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail.

[0031] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may 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.

[0032] 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 — in a manner similar to the term “comprising” as an open transition word — without precluding any additional or other elements.

[0033] As used herein, a “processing unit” or “processor” or “operating processor” includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. A processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a (Digital Signal Processing) DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor or processing unit is a hardware processor.

[0034] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smartdevice”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a mobile communication device”, “a communication device” may be any electrical, electronic, and / or computing device or equipment, capable of implementing the features of the present disclosure. The user equipment / device may include, but is not limited to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any other computing device which is capable of implementing the features of the present disclosure. Also, the user device may contain at least one input means configured to receive an input from at least one of a transceiver unit, a processing unit, a storage unit, a detection unit and any other such unit(s) which are required to implement the features of the present disclosure.

[0035] As used herein, “storage unit” or “memory unit” refers to a machine or computer-readable medium including any mechanism for storing information in a form readable by a computer or similar machine. For example, a computer-readable medium includes read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices or other types of machine-accessible storage media. The storage unit stores at least the data that may be required by one or more units of the system to perform their respective functions.

[0036] As used herein “interface” or “user interface refers to a shared boundary across which two or more separate components of a system exchange information or data. The interface may also be referred to a set of rules or protocols that define communication or interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.

[0037] All modules, units, components used herein, unless explicitly excluded herein, may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc.

[0038] As used herein the transceiver unit include at least one receiver and at least one transmitter configured respectively for receiving and transmitting data, signals, information, or a combination thereof between units / components within the system and / or connected with the system.

[0039] As discussed in the background section, the current known solutions have several shortcomings. The present disclosure aims to overcome those shortcomings and other existing problems in this field of technology by providing method and system for detecting voice call muting in a communication network.

[0040] FIG. 1 illustrates an exemplary block diagram representation of 5th generation core (5GC) network architecture, in accordance with exemplary implementation of the present disclosure. As shown in FIG. 1, the 5GC network architecture

[0100] includes a user equipment (UE)

[0102] , a radio access network (RAN)

[0104] , an access and mobility management function (AMF)

[0106] , a Session Management Function (SMF)

[0108] , a Service Communication Proxy (SCP)

[0110] , an Authentication Server Function (AUSF)

[0112] , a Network Slice Specific Authentication and Authorization Function (NSSAAF)

[0114] , a Network Slice Selection Function (NSSF)

[0116] , a Network Exposure Function (NEF)

[0118] , a Network Repository Function (NRF)

[0120] , a Policy Control Function (PCF)

[0122] , a Unified Data Management (UDM)

[0124] , an application function (AF)

[0126] , a User Plane Function (UPF)

[0128] , a data network (DN)

[0130] , wherein all the components are assumed to be connected to each other in a manner as obvious to the person skilled in the art for implementing features of the present disclosure.

[0041] The Radio Access Network (RAN)

[0104] is the part of a mobile telecommunications system that connects user equipment (UE)

[0102] to the core network (CN) and provides access to different types of networks (e.g., 5G network). It consists of radio base stations and the radio access technologies that enable wireless communication.

[0042] The Access and Mobility Management Function (AMF)

[0106] is a 5G core network function responsible for managing access and mobility aspects, such as UE registration, connection, and reachability. It also handles mobility management procedures like handovers and paging.

[0043] The Session Management Function (SMF)

[0108] is a 5G core network function responsible for managing session-related aspects, such as establishing, modifying, and releasing sessions. Itcoordinates with the User Plane Function (UPF) for data forwarding and handles IP address allocation and QoS enforcement.

[0044] The Service Communication Proxy (SCP)

[0110] is a network function in the 5G core network that facilitates communication between other network functions by providing a secure and efficient messaging service. It acts as a mediator for service-based interfaces.

[0045] The Authentication Server Function (AUSF)

[0112] is a network function in the 5G core responsible for authenticating UEs during registration and providing security services. It generates and verifies authentication vectors and tokens.

[0046] The Network Slice Specific Authentication and Authorization Function (NSSAAF)

[0114] is a network function that provides authentication and authorization services specific to network slices. It ensures that UEs can access only the slices for which they are authorized.

[0047] Further, the Network Slice Selection Function (NSSF)

[0116] is a network function responsible for selecting the appropriate network slice for a UE based on factors such as subscription, requested services, and network policies.

[0048] The Network Exposure Function (NEF)

[0118] is a network function that exposes capabilities and services of the 5G network to external applications, enabling integration with third-party services and applications.

[0049] The Network Repository Function (NRF)

[0120] is a network function that acts as a central repository for information about available network functions and services. It facilitates the discovery and dynamic registration of network functions.

[0050] The Policy Control Function (PCF)

[0122] is a network function responsible for policy control decisions, such as QoS, charging, and access control, based on subscriber information and network policies.

[0051] The Unified Data Management (UDM)

[0124] is a network function that centralizes the management of subscriber data, including authentication, authorization, and subscription information.

[0052] The Application Function (AF)

[0126] is a network function that represents external applications interfacing with the 5G core network to access network capabilities and services.

[0053] The User Plane Function (UPF)

[0128] is a network function responsible for handling user data traffic, including packet routing, forwarding, and QoS enforcement.

[0054] The Data Network (DN)

[0130] refers to a network that provides data services to user equipment (UE) in a telecommunications system. The data services may include but are not limited to Internet services, private data network related services.

[0055] FIG. 2 illustrates an exemplary block diagram of a computing device

[0200] upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure. In an implementation, the computing device

[0200] may also implement a method for detecting voice call muting in a communication network utilising the system. In another implementation, the computing device

[0200] itself implements the method for detecting voice call muting in a communication network using one or more units configured within the computing device

[0200] , wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.

[0056] The computing device

[0200] may include a bus

[0202] or other communication mechanism for communicating information, and a hardware processor

[0204] coupled with bus

[0202] for processing information. The hardware processor

[0204] may be, for example, a general-purpose microprocessor. The computing device

[0200] may also include a main memory

[0206] , such as a random-access memory (RAM), or other dynamic storage device, coupled to the bus

[0202] for storing information and instructions to be executed by the processor

[0204] , The main memory

[0206] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the processor

[0204] , Such instructions, when stored in non-transitory storage media accessible to the processor

[0204] , render the computing device

[0200] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device

[0200] further includes a read only memory (ROM)

[0208] or other static storage device coupled to the bus

[0202] for storing static information and instructions for the processor

[0204] ,

[0057] A storage device

[0210] , such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus

[0202] for storing information and instructions. The computingdevice

[0200] may be coupled via the bus

[0202] to a display

[0212] , such as a cathode ray tube (CRT), Liquid crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying information to a computer user. An input device

[0214] , including alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus

[0202] for communicating information and command selections to the processor

[0204] , Another type of user input device may be a cursor controller

[0216] , such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor

[0204] , and for controlling cursor movement on the display

[0212] , The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.

[0058] The computing device

[0200] may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic which in combination with the computing device

[0200] causes or programs the computing device

[0200] to be a special-purpose machine. According to one implementation, the techniques herein are performed by the computing device

[0200] in response to the processor

[0204] executing one or more sequences of one or more instructions contained in the main memory

[0206] , Such instructions may be read into the main memory

[0206] from another storage medium, such as the storage device

[0210] , Execution of the sequences of instructions contained in the main memory

[0206] causes the processor

[0204] to perform the process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.

[0059] The computing device

[0200] also may include a communication interface

[0218] coupled to the bus

[0202] , The communication interface

[0218] provides a two-way data communication coupling to a network link

[0220] that is connected to a local network

[0222] , For example, the communication interface

[0218] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface

[0218] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface

[0218] sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

[0060] The computing device

[0200] can send messages and receive data, including program code, through the network(s), the network link

[0220] and the communication interface

[0218] , In the Internet example, a server

[0230] might transmit a requested code for an application program through the Internet

[0228] , the ISP

[0226] , the local network

[0222] , the host

[0224] , and the communication interface

[0218] , The received code may be executed by the processor

[0204] as it is received, and / or stored in the storage device

[0210] , or other non-volatile storage for later execution. The computing device

[0200] may be associated with a system (further explained in FIG. 3).

[0061] Referring to FIG. 3, an exemplary block diagram of a system

[0300] for detecting voice call muting / muting event(s) in a communication network, is shown, in accordance with the exemplary implementations of the present disclosure. The system

[0300] comprises at least one processing unit

[0302] , at least one session management function unit

[0108] , at least one User Plane Function unit

[0128] , at least one IP multimedia subsystem

[0304] , and at least one policy control function

[0122] , Also, all of the components / units of the system

[0300] are assumed to be connected to each other unless otherwise indicated below. As shown in the figures all units shown within the system should also be assumed to be connected to each other. Also, in FIG. 3 only a few units are shown, however, the system

[0300] may comprise multiple such units or the system

[0300] may comprise any such numbers of said units, as required to implement the features of the present disclosure. Further, in an implementation, the system

[0300] may be present in a user device to implement the features of the present disclosure. The system

[0300] may be a part of the user device / or may be independent of but in communication with the user device (may also referred herein as a UE). In another implementation, the system

[0300] may reside in a server or a network entity. In yet another implementation, the system

[0300] may reside partly in the server / network entity and partly in the user device.

[0062] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various components / units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.

[0063] The system

[0300] is configured for detecting voice call muting in a communication network, with the help of interconnection between the components / units of the system

[0300] , The system

[0300] may be implemented for voice call muting detection with core network functions including but not limited to the UPF

[0108] , the PCF

[0122] and the SMF

[0128] without depending on radio components of network. The system

[0300] further may be implemented for voice call muting detection during handover between radio network based on, but not limited to the PCF

[0122] , the UPF

[0108] and the SMF

[0128] based analysis. The system

[0300] may be further implemented to support voice call muting detection in specific regions, at specific time periods or for specific user based on the PCF

[0122] , the UPF

[0108] and the SMF

[0128] , The system

[0300] may further be implemented on or in conjunction with an analysis platform (for instance-ATOM) to analyse call data records gathered from the PCF

[0122] , the UPF

[0108] and the SMF 128] to detect Voice Call Muting.

[0064] The system

[0300] includes a processing unit

[0302] , configured to establish a packet data unit (PDU) session for voice communication between a user equipment (UE)

[0102] and an Internet Protocol (IP) multimedia subsystem (IMS)

[0304] ,

[0065] In an implementation of the present disclosure, when an existing ongoing call is going on between users or the call has been established just now, as mentioned in 5G architecture in FIG. 1, a user equipment

[0102] is in connection with the 5th generation core network. The UE

[0102] may be associated with the system

[0300] ,

[0066] In the ongoing call session, the connection between the user equipment

[0102] and an IMS

[0304] is already ongoing, which may have been initiated before, the IMS network

[0304] authenticates the user equipment

[0102] and establishes the Packet data Unit (PDU) session for the user equipment

[0102] , The PDU session refers to a connection between a user and the network for transfer of data packets between them during a session. The processing unit

[0302] sets up the Packet Data Unit (PDU) session for voice communication between the User Equipment (UE)

[0102] and the IP Multimedia Subsystem (IMS)

[0304] , This session is the foundation for the voice call and the data exchange that follows.

[0067] The system

[0300] further includes the IMS

[0304] , configured to send an authentication and authorization request (AAR) message to a policy control function (PCF)

[0122] to add a custom information element (IE) for a real-time transport protocol (RTP) rule.

[0068] In an implementation of the present disclosure, the IMS

[0304] sends an Authentication and Authorization Request (AAR) message to the Policy Control Function (PCF)

[0122] , The AAR message requests the addition of a custom Information Element (IE) specifically designed for a Real-Time Transport Protocol (RTP) rule. This custom IE is crucial for identifying and managing the data packets related to the voice call. The custom field refers to additional parameters stored in the UDR for the voice call which may contain a session identifier to identify the call. The custom field may be added to identify the RTP rule for the voice call.

[0069] Further, the system

[0300] includes the Policy Control Function (PCF)

[0122] configured to generate a session management policy (SMPolicy) update notification message. The SMPolicy update notification message comprises media-based rules and the PCF

[0122] is further configured to transmit the SMPolicy update notification message to a Session Management Function (SMF)

[0108] , The PCF

[0122] is further configured to identify, based on the media-based rules, the voice call for which muting is to be identified. The media-based rules refer to information elements (IE) for creating policy rules for identification of a call as a video call or a voice call when a call is initiated. The identification is done based on media-based rules to identify if a voice call or a video call is going on in the 5th Generation Core Network. For example, the media-based rules may monitor the packet size and frequency of data packets. If the PCF

[0122] detects consistently small packets at regular intervals, the data packets may be identified as a voice call based on the mediabased rules. The PCF

[0122] further inserts a custom field in the SMPolicy update notification message. The custom field may be inserted when a user is provisioned to the 5thgeneration network. The custom field may not be modified during a call. For instance, when the request for the call is initiated by the user, the PCF

[0122] may identify the request and insert the custom field during processing of the request for the call. The PCF

[0122] , is configured to send a SMPolicy Update Notify Response message to the IMS

[0304] following the transmission of the SMPolicy Update Notification to the SMF

[0108] ,

[0070] In an implementation of the present disclosure, a Session Management Policy (SMPolicy) update notification message containing media-based rules is created by the PCF

[0122] , The PCF

[0122] then transmits this message to the Session Management Function (SMF)

[0108] , The mediabased rules are important for managing how the session data is handled and processed, especially concerning voice data.

[0071] The system

[0300] further includes the Session Management Function (SMF)

[0108] that is configured to create a packet detection rule (PDR) with the custom field for identifying the RTPsession description framework (SDF) for the voice call in response to the SMPolicy Update Notification message. The PCF

[0122] may insert the custom field for voice muting. The custom field may be a part of a sub custom field in the RTP SDF for the voice call. Furthermore, the SMF

[0108] is configured to send a packet forwarding control protocol (PFCP) Session Modification Request to the UPF

[0128] , The PFCP Session Modification Request comprises the PDR for initiating the voice call processing. The packet detection rule refers to defining a set of criteria to help the SMF

[0108] to identify the required network traffic. The set of criteria includes but may not be limited to an IP address of the UE

[0102] , a session identifier, and the like. The SMF

[0108] may identify the required traffic based on the traffic on the IP address of the UE

[0102] ,

[0072] Furthermore, the system

[0300] includes a user plane function (UPF)

[0128] that is configured to detect a muting event during the voice call based on analysis of RTP SDF and send a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event. The muting event refers to a period that occurs during the voice call where voice is not heard either to “A Party” or “B Party” due to packet loss or packet delay. The detection of the muting event includes comparing a difference of a talk-spurt and a silence spurt with a predefined mute threshold time. When the difference between the talk-spurt and the silence-spurt breaches the pre-defined mute threshold time, the difference may be identified as the muting event. The stream detail record (SDR) message comprises at least one of a timestamp flow creation, a timestamp flow deletion, the session identifier, a user identifier, a type of SDR flow, a direction of muting, and the like. The timestamp flow creation refers to a timestamp when the RTP SDF was created.

[0073] The timestamp flow deletion refers to a timestamp when the RTP SDF was deleted. The session identifier (session ID) refers to an identifier which may be used to distinguish an individual session from various session in systems, such as a communication network, databases, and the like. A user identifier (user ID) refers to a unique identifier assigned to a user to distinguish one user from another user in a system like communication network. The Streaming Data Record (SDR) flow refers to the process by which signals are processed in an SDR system. The processing of the radio signal may be done using a software instead of a hardware. Direction of muting refers to identifying in which direction is the muting occurring, either in transmitting or receiving direction. The UPF

[0128] is configured to compare a difference of the talk-spurt and the silence spurt with the predefined mute threshold time. The predefined mute threshold time may be defined by the system

[0300] or a user. For instance, the predefined mute threshold time is set by the system

[0300] at around 5 seconds. The talk-spurt refers to the time during which continuous talk activityis identified, whereas the silence spurt refers to the time during which continuous silence activity is identified. If the difference between the talk-spurt and the silence spurt is more than 5 seconds, it will be identified as muting event. If the difference between the talk-spurt and the silence spurt is less than 5 seconds, it will be identified as a speech event.

[0074] For another instance, the predefined mute threshold time is set by the user at around 11 seconds. If the difference between the talk-spurt and the silence spurt is more than 11 seconds as required by the user, it will be identified as muting event. If the difference between the talk-spurt and the silence spurt is less than 11 seconds, it will be identified as a speech event. The user may change the predefined mute threshold time for every call muting detecting session.

[0075] The processing unit

[0302] is further configured to correlate the set of SDR messages from the UPF

[0128] with corresponding PDR from the SMF

[0108] to identify the muting event determine an occurrence of the muting event based on the correlated data, and generate key performance indicator (KPI) reports for call muting based on the determined occurrences. The processing unit

[0302] generates KPI reports based on a predetermined criteria selected from the group consisting of a Cell-wise, a Call-wise, during a Handover (HO) or a No Handover (NO-HO), a Daily interval, a Weekly interval, and a Monthly interval, wherein the predefined criteria comprise one of a muting occurrence, an HO Call analysis, a Downlink Muting KPIs. The cell-wise generation of KPI report includes monitoring KPIs for each cell in the communication network. The call-wise generation of KPI report refers to monitoring individual call sessions to generate a call performance report.

[0076] The Handover and the No-Handover KPI report generation includes monitoring KPI in specific circumstances during the handover sessions or during the sessions when no handover is performed to assess the handover and the no-handover report. Further, the KPI reports can be generated at the daily interval, the weekly interval, or the monthly interval for performance in a network. The KPIs will be monitored in all these circumstances for the predefined criteria, which may be the muting occurrence. The muting occurrence is defined as when the processing unit

[0302] identifies the muting event. For instance, the KPIs may be monitored in each call session where the muting event is identified. The KPI report may be generated at a weekly interval, every Friday where the criteria to monitor is handover call analysis. The report may include the weekly data for a handover call analysis.

[0077] The HO call analysis refers to analysis of a call performance during a handover. For instance, KPI analysis may be used to analyse the call performance during the handover for a month. The KPIs will be analysed during the handover every day for a month to identify muting events in a call performance during the handover. The downlink muting KPIs refers to analysis of downlink muting. The downlink muting may be defined as a temporary muting event of a cell to reduce interference and improve the overall network performance.

[0078] In an implementation of the present disclosure, the determination of voice call muting events involves accessing the SDR and PDR messages, and parsing these messages to extract relevant information including session IDs, voice quality value, and the like. Further, the predetermined criteria for determining muting event include but may not be limited to packet loss, latency and the like events which indicate a muting event. Further, the processing unit

[0302] calculates the KPIs based on the threshold to see whether there is a muting event or not.

[0079] In an example, a telecom operator may be an individual or group of individuals that provide 5G services. For instance, the telecom operator may notice that some customers are experiencing brief periods of silence or "muting" during voice calls, leading to customer dissatisfaction. A customer initiates a voice call using their smartphone (User Equipment, UE). The telecom operator may initiate the system

[0300] to detect the muting event in the voice call initiated by a customer, or the system

[0300] may automatically be initiated to detect the muting event when a voice call initiation is detected by the system

[0300] ,

[0080] The network's processing unit

[0302] establishes a Packet Data Unit (PDU) session between the smartphone (UE)

[0102] and the operator's IP Multimedia Subsystem (IMS)

[0304] , During call setup, the IMS

[0304] sends the Authentication and Authorization Request (AAR) message to the Policy Control Function (PCF)

[0122] , requesting to add a custom Information Element (IE) for managing Real-Time Transport Protocol (RTP) data. The custom IE refers to a non-standard IE. The custom IE may be implemented by the telecom operator to transfer information which may not be covered in a standard IE. IE are components of signalling messages used to exchange information between network entities. The custom IE may allow to send customized information. The PCF

[0122] may add the custom IE to a list of existing IES and allocate a list of specific rules for the IE. The PCF

[0122] generates a Session Management Policy (SMPolicy) update notification with specific media-based rules and sends it to the Session Management Function (SMF)

[0108] , The SMF

[0108] , upon receiving the SMPolicy update, creates the Packet Detection Rule (PDR) with a custom field that helps in identifying RTP data specific to the voice call. As the voice callprogresses, the User Plane Function (UPF)

[0128] continuously monitors the RTP data. It detects a moment where the voice signal is lost for a few seconds - a muting event. The UPF

[0128] records this muting event and sends a Stream Detail Record (SDR) message indicating the time and occurrence of the muting.

[0081] The method implemented by the system as defined in FIG. 3 is explained in detail in FIG. 4. Referring to FIG. 4, illustrates a method flow diagram for detecting voice call muting in a communication network. In an implementation the method

[0400] is performed by the system

[0300] , Further, in an implementation, the system

[0300] may be present in a server device to implement the features of the present disclosure. Also, as shown in FIG. 4, the method

[0400] starts at step

[0402] ,

[0082] At step

[0404] , the method includes establishing, by a processing unit

[0302] , a packet data unit (PDU) session for voice communication between a user equipment (UE)

[0102] and an IP multimedia subsystem (IMS)

[0304] , The UE

[0102] may be associated with the system

[0300] ,

[0083] In an implementation of the present disclosure, when an existing ongoing call is going on between users or it has been established just now, the connection between the user equipment

[0102] an IMS

[0304] is already ongoing, which may have been initiated before, the IMS network

[0304] authenticates the user equipment

[0102] and establishes the Packet data Unit (PDU) session for the user equipment

[0102] , The PDU session refers to a connection between a user and the network for transfer of data packets between them during a session. The processing unit

[0302] sets up the Packet Data Unit (PDU) session for voice communication between the User Equipment (UE)

[0102] and an IP Multimedia Subsystem (IMS)

[0304] , This session is the foundation for the voice call and the data exchange that follows.

[0084] Next at step

[0406] , the method encompasses sending, by the IMS

[0304] , an authentication and authorization request (AAR) message to a policy control function (PCF)

[0122] to add a custom information element (IE) for a real-time transport protocol (RTP) rule.

[0085] In an implementation of the present disclosure, an Authentication and Authorization Request (AAR) message is sent by the IMS

[0304] to the Policy Control Function (PCF)

[0122] , This message requests the addition of a custom Information Element (IE) specifically designed for a Real-Time Transport Protocol (RTP) rule. This custom IE is crucial for identifying and managing the data packets related to the voice call. The custom field refers to additional parameters storedin the UDR for the voice call which may contain a session identifier to identify the call. The custom field may be added to identify the RTP rule for the voice call.

[0086] Further at step

[0408] , the method includes generating, by the PCF

[0122] , a session management policy (SMPolicy) update notification message comprising media-based rules and transmitting the SMPolicy update notification message to a Session Management Function (SMF)

[0108] , The method comprises sending, by the PCF

[0122] , a SMPolicy Update Notify Response message to the IMS

[0304] following the transmission of the SMPolicy Update Notification to the SMF

[0108] ,

[0087] In an implementation of the present disclosure, a Session Management Policy (SMPolicy) update notification message containing media-based rules is created by the PCF

[0122] , The PCF

[0122] then transmits this message to the Session Management Function (SMF)

[0108] , These rules are important for managing how the session data is handled and processed, especially concerning voice data.

[0088] Next at step

[0410] , the method encompasses identifying, by the PCF

[0122] , based on the media-based rules, the voice call for which muting is to be identified. The media-based rules refer to information elements (IE) for creating policy rules for identification of a call as a video call or a voice call when a call is initiated. The identification is done based on media-based rules to identify if a voice call or a video call is going on in the 5th Generation Core Network. For example, the media-based rules may monitor the packet size and frequency of data packets. If the PCF

[0122] detects consistently small packets at regular intervals, the data packets may be identified as a voice call based on the media-based rules. Next at step

[0412] , the method includes inserting, by the PCF

[0122] , a custom field in the SMPolicy update notification message.

[0089] Further, at step

[0414] , the method includes creating, by the SMF

[0108] , a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message.

[0090] Next, at step

[0416] , the method encompasses sending, by the SMF

[0108] , a packet forwarding control protocol (PFCP) Session Modification Request to the UPF

[0106] comprising the PDR for initiating a voice call processing.

[0091] In an implementation of the present disclosure, the PFCP Session Modification Request comprises the PDR for initiating the voice call processing. The packet detection rule refers to defining a set of criteria to help the SMF

[0108] to identify the required network traffic. The set of criteria includes but may not be limited to an IP address of the UE

[0102] , a session identifier, and the like. The SMF

[0108] may identify the required traffic based on the traffic on the IP address of the UE

[0102] ,

[0092] Further at step

[0418] , the method includes detecting, by a user plane function (UPF)

[0128] , a muting event during the voice call based on analysis of RTP SDF. The method further comprises detecting by the UPF

[0128] , the muting event comprises comparing a difference of a talk-spurt and a silence spurt with a predefined mute threshold time.

[0093] The predefined mute threshold time maybe defined by the system

[0300] or maybe by defined by a user. For instance, the predefined mute threshold time is set by the system

[0300] at around 5 seconds. The talk-spurt refers to the time during which continuous talk activity is identified, whereas the silence spurt refers to the time during which continuous silence activity is identified. If the difference between the talk-spurt and the silence spurt is more than 5 seconds, it will be identified as muting event. If the difference between the talk-spurt and the silence spurt is less than 5 seconds, it will be identified as a speech event.

[0094] For another instance, the predefined mute threshold time is set by the user at around 11 seconds. If the difference between the talk-spurt and the silence spurt is more than 11 seconds as required by the user, it will be identified as muting event. If the difference between the talk-spurt and the silence spurt is less than 11 seconds, it will be identified as a speech event. The user may change the predefined mute threshold time for every call muting detecting session.

[0095] Next at step

[0420] , the method includes sending, by the UPF

[0128] , a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event. The stream detail record (SDR) message comprises at least one of a timestamp flow creation, a timestamp flow deletion, a session identifier, a user identifier, a type of SDR flow, a direction of muting, and a UPF ID.

[0096] Further, at step

[0422] , the method includes correlating, by the processing unit

[0302] , the set of SDR messages from the UPF

[0128] with corresponding PDR from the SMF

[0108] to identify muting events.

[0097] Next at step

[0424] , the method includes determining, by the processing unit

[0302] , an occurrence of voice call muting events based on the correlated data.

[0098] At step

[0426] the method includes generating, by the processing unit

[0302] , key performance indicator (KPI) reports for call muting based on the determined occurrences. The generating of KPI reports by the processing unit

[0302] is based on a predetermined criteria selected from the group consisting of Cell-wise, Call-wise, State-wise, during Handover (HO) or No Handover (NO-HO), and Daily, Weekly, and Monthly intervals, wherein the predefined criteria comprises one of a muting occurrence, a HO Call analysis, and a Downlink Muting KPIs. The cell-wise generation of KPI report includes monitoring KPIs for each cell in the communication network. The call-wise generation of KPI report refers to monitoring individual call sessions to generate a call performance report. The Handover and the No- Handover KPI report generation includes monitoring KPI in specific circumstances during the handover sessions or during the sessions when no handover is performed to assess the handover and the no-handover report. Further the KPI reports can be generated at the daily interval, the weekly interval, or the monthly interval for performance in a network. The KPIs will be monitored in all these circumstances for the predefined criteria, which may be the muting occurrence. For instance, the KPIs will be monitored in each call session where the muting event is identified. The KPI report will be generated at a weekly interval, every Friday where the criteria to monitor is handover call analysis. The report may include the weekly data for a handover call analysis.

[0099] The HO call analysis refers to the analysis of call performance during the handover. For instance, the defined criteria for KPI analysis are used to analyse the call performance during the handover for every month. The KPIs will be analysed during a handover every day for a month to identify muting events in a call performance during a handover. The downlink muting KPIs refers to analysis of downlink muting. Downlink muting may be defined as a temporary muting event a cell to reduce interference and improve the overall network performance.

[0100] The method terminates at step

[0428] ,

[0101] FIG. 5 is an exemplary illustration of the system and method as explained in FIG. 3 and FIG. 4. Referring to FIG. 5, it illustrates an exemplary embodiment of the system for voice call muting Detection in a communication network, in accordance with exemplary implementations of the present disclosure.

[0102] As shown in FIG. 5, during communication, IMS

[0304] PDU session is pre-established. IMS

[0304] sends AAR message to PCF

[0122] to add custom IE for RTP rule, which includes RTP and RTCP Meta sub-components AVP. The PCF

[0122] sends SMPolicy UpdateNotify Media Based Rules message to SMF

[0108] , In response to this message, the SMF

[0108] sends SMPolicy_UpdateNotify Response message to the PCF

[0122] , Further, the PCF

[0122] sends AAA message to the IMS

[0304] , Next, the SMF

[0108] sends the PFCP Session Modification Request PDR, QER and FAR (Custom IE to be added) message to the UPF

[0128] and the PDR Event for call starts at the SMF

[0108] , The UPF

[0128] sends the PFCP Session Modification Response message to the SMF

[0108] and voice call processes between the UE

[0102] and the IMS

[0304] via the UPF

[0128] , Next, the UPF

[0128] detects the muting event for sending in the SDR. The IMS

[0304] sends the STR (termination of call) message to the PCF

[0122] , Further, SMPolicy based message and response message exchange between the PCF

[0122] and the SMF

[0108] , The PCF

[0122] sends STA message to the IMS

[0304] , The SMF

[0108] sends PFCP Session Modification Request PDR, QER and FAR to be removed message to the UPF

[0128] , The UPF

[0128] sends SDR message to an ATOM

[0514] for Muting Events and PFCP Session Modification Response to the SMF

[0108] , The Analytics, Troubleshooting, and Optimization Management (ATOM) system

[0514] is connected to the UPF

[0128] , the SMF

[0108] and the IMS

[0304] through a Northbound Interface (NBI) integration. The NBI integration refers to an output-based interface, i.e., the ATOM

[0514] is configured to send the generated KPI’s to the UPF

[0128] , the SMF

[0108] and the IMS

[0304] ,

[0103] In preferred embodiments, the ATOM

[0514] analyses SDRs from the UPF

[0128] , PDRs from the SMF

[0108] and CDRs from CTAS. For an example, in case of the UPF

[0106] SDR, where direction of muting is uplink as follows: IMS

[0304] / SUPI is received from the UPF

[0128] should be matched with the SMF

[0108] records. The Session-ID from the UPF

[0128] should be matched with the Session-ID from the SMF

[0108] for corresponding SUPI. The ATOM

[0514] may check the muting timestamp array to recover the number of muting events for that call and also individual muting timestamp. Further, processing is performed between the UPF

[0128] and the SMF

[0108] , The ATOM

[0514] records the UE

[0102] location field denoting Cell ID, when muting is detected.

[0104] In a preferred embodiment, the ATOM

[0514] calculates muting occurrence, based on number of muting events per Cell ID for all the calls. It may also be calculated based on per call per Cell ID. ATOM

[0514] may use Cell wise, Call wise, State wise, HO / No HO / All, Daily / Weekly / Monthly criteria for generating KPI reports. The cell wise generation of KPI reportincludes monitoring KPIs for each cell in the communication network. The call-wise generation of KPI report refers to monitoring individual call sessions to generate a call performance report. The Handover and the No- Handover KPI report generation includes monitoring KPI in specific circumstances during the handover sessions or during the sessions when no handover is performed to assess the handover and the no-handover report. Further the KPI reports can be generated at the daily interval, the weekly interval, or the monthly interval for performance in a network. The KPIs will be monitored in all these circumstances for the predefined criteria, which may be the muting occurrence. For instance, the KPIs will be monitored in each call session where the muting event is identified. The KPI report will be generated at a weekly interval, every Friday where the criteria to monitor is handover call analysis. The report may include the weekly data for a handover call analysis.

[0105] The HO call analysis refers to the analysis of call performance during the handover. For instance, the defined criteria for KPI analysis to analyse the call performance during the handover for every month. The KPIs will be analysed during a handover every day for a month to identify muting events in a call performance during a handover. The downlink muting KPIs refers to analysis of downlink muting. Downlink muting may be defined as a temporary muting event of a cell to reduce interference and improve the overall network performance.

[0106] An exemplary illustration of the exemplary system architecture as explained in Fig. 5 for detecting voice muting is further explained in FIG. 6. Referring to FIG. 6, an exemplary method flow diagram

[0600] for detecting voice call muting in a communication network for a pre- established PDU session. In an implementation the method

[0600] is performed by the system

[0500] , Further, in an implementation, the system

[0500] may be present in a server device to implement the features of the present disclosure.

[0107] When a user equipment

[0102] initiates a connection with the IMS

[0304] , the IMS network

[0304] authenticates the user equipment

[0102] and establishes a Packet data Unit (PDU) session for the user equipment

[0102] , A PDU session refers to a connection between a user and the network for transfer of data packets between them during a session. The processing unit

[0302] sets up the Packet Data Unit (PDU) session for voice communication between User Equipment (UE) and an IP Multimedia Subsystem (IMS). This session is the foundation for the voice call and the data exchange that follows.

[0108] At step 1, the IMS

[0304] sends an Authentication and Authorization Request (AAR) message to a Policy Control Function (PCF)

[0122] , This message requests the addition of a custom Information Element (IE) specifically designed for a Real-Time Transport Protocol (RTP) rule. This custom IE is crucial for identifying and managing the data packets related to the voice call.

[0109] At step 2, the PCF

[0122] creates a Session Management Policy (SMPolicy) update notification message containing media-based rules. The PCF

[0122] further transmits this message to the Session Management Function (SMF)

[0108] , These rules are important for managing how the session data is handled and processed, especially concerning voice data.

[0110] At step 3, the SMF

[0108] creates an SMPolicy update Notification response and sends the response to the PCF

[0122] , The response comprises a confirmation of the updating of rules in the SMF

[0108] for handling and processing of data.[OHl] At step 4, the PCF

[0122] sends a response to the IMS

[0304] on a successful addition of the custom IE.

[0112] At step 5, in response to receiving the SMPolicy Update Notification response, the SMF

[0108] generates a Packet Detection Rule (PDR) equipped with a custom field for an event of starting of the call. This field is essential for identifying the RTP Session Description Framework (SDF) for the voice call, enabling the system to distinguish voice call data packets. The PFCP Session Modification Request comprises the PDR for initiating the voice call processing. The packet detection rule refers to defining a set of criteria to help the SMF

[0108] to identify the required network traffic. The set of criteria includes but may not be limited to an IP address of the UE

[0102] , a session identifier, and the like. The SMF

[0108] may identify the required traffic based on the traffic on the IP address of the UE

[0102] ,

[0113] The User Plane Function (UPF)

[0128] monitors the voice call and detects any muting events based on the analysis of RTP SDF. Muting events can include moments where voice data is lost or delayed, impacting call quality. It documents the occurrence and the exact time when each muting event was detected.

[0114] At step 7, upon detecting a muting event, the PCF

[0122] sends out a set of Session termination request to the IMS

[0304] , An Analytics, Troubleshooting, and Optimization Management (ATOM) system

[0514] is connected to the UPF

[0128] , the SMF

[0108] and the IMS

[0304] through a Northbound Interface (NBI) integration. The NBI integration refers to an outputbased interface, i.e., the ATOM

[0514] is configured to send the generated KPI’s to the UPF

[0128] , the SMF

[0108] and the IMS

[0304] , The Analytics, Troubleshooting, and Optimization Management (ATOM)

[0514] system receives these SDR messages. It correlates them with the corresponding PDRs from the SMF. This process is key to accurately identifying and understanding the muting events. Identification is done based on media-based rules to identify if a voice call is going on in the 5th Generation Core Network. For example, the media-based rules may be to monitor the packet size and frequency of data packets. If the PCF

[0122] detects consistently small packets at regular intervals, the data packets may be identified as a voice call.

[0115] At step 8, the PCF

[0122] sends a SMPolicy update notify media-based rules to the SMF

[0108] to update the rules in the SMF

[0108] ,

[0116] At step 9, the SMF

[0108] further sends a response comprising an SMPolicy update notify response to the PCF

[0122] back.

[0117] At step 10, the PCF

[0122] sends back a session termination accept response to the IMS

[0304] ,

[0118] At step 11, the PFCP session modification request for removal of PDR is sent to the UPF

[0128] form the SMF

[0108] , wherein at step 12, the UPF

[0128] sends back a response for the modification request to the SMF

[0108] ,

[0119] Based on the correlated data, the ATOM system determines the occurrences of voice call muting events. This step is crucial for analysing the frequency and patterns of muting events in the network. The ATOM system generates Key Performance Indicator (KPI) reports for call muting. These reports are based on the determined occurrences and can be customized based on various criteria like Cell ID, call type, handover status, and time intervals (Daily, Weekly, Monthly). These reports provide valuable insights for network performance and quality of service monitoring. The cell-wise generation of KPI report includes monitoring KPIs for each cell in the communication network. The call-wise generation of KPI report refers to monitoring individual call sessions to generate a call performance report. The Handover and the No- Handover KPI report generation includes monitoring KPI in specific circumstances during the handover sessions or during the sessions when no handover is performed to assess the handover and the no-handover report. Further the KPI reports can be generated at the daily interval, the weekly interval, or the monthlyinterval for performance in a network. The KPIs will be monitored in all these circumstances for the predefined criteria, which may be the muting occurrence. For instance, the KPIs will be monitored in each call session where the muting event is identified. The KPI report will be generated at a weekly interval, every Friday where the criteria to monitor is handover call analysis. The report may include the weekly data for a handover call analysis.

[0120] The HO call analysis refers to the analysis of call performance during the handover. For instance, the defined criteria for KPI analysis to analyse the call performance during the handover for every month. The KPIs will be analysed during a handover every day for a month to identify muting events in a call performance during a handover. The downlink muting KPIs refers to analysis of downlink muting. Downlink muting may be defined as a temporary muting event a cell to reduce interference and improve the overall network performance.

[0121] In an exemplary embodiment, the PCF sends a response back to the IMS after transmitting the SMPolicy Update Notification to the SMF, acknowledging the successful update of the session management policy. Further, the SMF sends a Packet Forwarding Control Protocol (PFCP) Session Modification Request to the UPF, which includes the PDR for initiating voice call processing. After detecting a muting event, the UPF sends a PFCP Session Modification Response back to the SMF.

[0122] In an example, a telecom operator that provides 5G services. The operator has noticed that some customers are experiencing brief periods of silence or "muting" during voice calls, leading to customer dissatisfaction. A customer initiates a voice call using their smartphone (User Equipment, UE). The network's processing unit establishes a Packet Data Unit (PDU) session between the smartphone and the operator's IP Multimedia Subsystem (IMS). During call setup, the IMS sends an Authentication and Authorization Request (AAR) message to the Policy Control Function (PCF), requesting to add a custom Information Element (IE) for managing Real-Time Transport Protocol (RTP) data. The PCF generates a Session Management Policy (SMPolicy) update notification with specific media-based rules and sends it to the Session Management Function (SMF). The SMF, upon receiving the SMPolicy update, creates a Packet Detection Rule (PDR) with a custom field that helps in identifying RTP data specific to this voice call. As the voice call progresses, the User Plane Function (UPF) continuously monitors the RTP data. It detects a moment where the voice signal is lost for a few seconds - a muting event. The UPF records this muting event and sends a Stream Detail Record (SDR) message indicating the time and occurrence of the muting. The Analytics, Troubleshooting, and Optimization Management(ATOM) system receives the SDR and correlates it with the PDR from the SMF to confirm and understand the muting event. The ATOM system analyses the data and determines that the muting event was due to a temporary packet loss in the network. Based on this and other detected events, the ATOM system generates a KPI report. This report shows the frequency and patterns of call muting events, helping the network operator to identify problem areas in the network. With the insights from the KPI reports, the telecom operator can take targeted actions to improve the network infrastructure, thus reducing the occurrence of call muting and enhancing customer satisfaction. This method offers a comprehensive way to monitor and improve call quality in a modern telecommunications network.

[0123] The sequence of the illustrative embodiments as explained in FIG. 5 and FIG. 6 will be explained in further detail in FIG. 7. Referring to FIG. 7, it illustrates a sequence diagram indicating the process for Voice Call muting Detection between two parties in communication system in case of an existing ongoing call.

[0124] When an existing ongoing call is going on between users, the connection between the user equipment

[0102] an IMS

[0304] is already ongoing. The connection may have been initiated before, but the detection is performed in the middle of the call. The IMS network

[0304] authenticates the user equipment

[0102] and establishes a Packet data Unit (PDU) session for the user equipment

[0102] , A PDU session refers to a connection between a user and the network for transfer of data packets between them during a session. The processing unit

[0302] sets up the Packet Data Unit (PDU) session for voice communication between User Equipment (UE)

[0102] and an IP Multimedia Subsystem (IMS)

[0304] , This session is the foundation for the voice call and the data exchange that follows.

[0125] At step 1, the IMS

[0304] sends an Authentication and Authorization Request (AAR) message to a Policy Control Function (PCF)

[0122] , This message requests the addition of a custom Information Element (IE) specifically designed for a Real-Time Transport Protocol (RTP) rule. This custom IE is crucial for identifying and managing the data packets related to the voice call.

[0126] At step 2, the PCF

[0122] creates a Session Management Policy (SMPolicy) update notification message containing media-based rules. The PCF

[0122] then transmits this message to the Session Management Function (SMF)

[0108] , These rules are important for managing how the session data is handled and processed, especially concerning voice data.

[0127] At step 3, the SMF

[0108] creates an SMPolicy update Notification response and sends the response to the PCF

[0122] , The response comprises a confirmation of the updating of rules in the SMF

[0108] for handling and processing of data.

[0128] At step 4, the PCF

[0122] sends a response to the IMS

[0304] on a successful addition of the custom IE.

[0129] At step 5, in response to receiving the SMPolicy Update Notification response, the SMF

[0108] generates a Packet Detection Rule (PDR) equipped with a custom field for an event of starting of the call. This field is essential for identifying the RTP Session Description Framework (SDF) for the voice call, enabling the system to distinguish voice call data packets.

[0130] The User Plane Function (UPF)

[0128] monitors the voice call and detects any muting events based on the analysis of RTP SDF. Muting events can include moments where voice data is lost or delayed, impacting call quality. It documents the occurrence and the exact time when each muting event was detected.

[0131] The present disclosure further discloses a User Equipment for detecting voice call muting., The UE comprises a processor

[1004] , The processor

[1004] is configured to establishing, by a processing unit

[0302] , a packet data unit (PDU) session for voice communication between a user equipment (UE)

[0102] and an IP multimedia subsystem (IMS)

[0304] , The processor

[1004] is configured to facilitate generating key performance indicator (KPI) reports for the voice call muting. The generation of KPI reports is based on sending, by the IMS

[0304] , an authentication and authorization request (AAR) message to a policy control function (PCF)

[0122] to add a custom information element (IE) for a real-time transport protocol (RTP) rule. Further, generation of KPI reports is based on generating, by the PCF

[0122] , a session management policy (SMPolicy) update notification message comprising media-based rules and transmitting the SMPolicy update notification message to a Session Management Function (SMF)

[0108] and identifying, by the PCF

[0122] , based on the media-based rules, a voice call for which muting is to be identified. Also, generation of the KPI reports is based on inserting, by the PCF

[0122] , a custom field in the SMPolicy update notification message and creating, by the SMF

[0108] , a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message. The generation of the KPI reports is based on sending, by the SMF

[0108] , a packet forwarding control protocol (PFCP) Session Modification Request to the UPF

[0128] comprising the PDR for initiating processing ofthe voice call and detecting, by a user plane function (UPF)

[0128] , a muting event during the voice call based on analysis of RTP SDF. The generation of the KPI reports is based on sending, by the UPF

[0128] , a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event and correlating, by the processing unit

[0302] , the set of SDR messages from the UPF

[0128] with corresponding PDR from the SMF

[0108] to identify muting events. In addition, the generation of the KPI reports is based on determining, by the processing unit

[0302] , an occurrence of voice call muting events based on the correlated data and lastly the generation of the KPI reports is based on generating, by the processing unit

[0302] , key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

[0132] The present disclosure further discloses a non-transitory computer readable storage medium storing instructions for detecting voice call muting in a communication network, the instructions include executable code which, when executed by one or more units of a system, causes: a processing unit

[0302] of the system

[0300] to establish a packet data unit (PDU) session for voice communication between a user equipment (UE)

[0102] and an IP multimedia subsystem (IMS)

[0304] , Further, the instructions include executable code which, when executed causes an IMS

[0304] of the system

[0300] to send an authentication and authorization request (AAR) message to a policy control function (PCF)

[0122] to add a custom information element (IE) for a real-time transport protocol (RTP) rule. Further, the instructions include executable code which, when executed causes a PCF

[0122] of the system to: generate a session management policy (SMPolicy) update notification message comprising media-based rules, and transmitting the SMPolicy update notification message to a Session Management Function (SMF)

[0108] ; identify, based on the media-based rules, voice call for which muting is to be identified; and insert a custom field in the SMPolicy update notification message. Further, the instructions include executable code which, when executed cause an SMF

[0108] of the system

[0300] to: create a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message and send a packet forwarding control protocol (PFCP) Session Modification Request to the UPF

[0128] comprising the PDR for initiating the voice call processing. Further, the instructions include executable code which, when executed cause a UPF

[0128] of the system

[0300] to detect a muting event during the voice call based on analysis of RTP SDF; and send a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event. Further, the instructions include executable code which, when executed cause the processing unit

[0302] of the system

[0300] to: correlate the set of SDR messages from the UPF

[0128] with corresponding PDR from the SMF

[0108] to identify muting events; determine an occurrence of voice call muting events based on the correlated data;and generate key performance indicator (KPI) reports for call muting based on the determined occurrences.

[0133] As is evident from the above, the present disclosure provides a technically advanced solution of Voice Call muting Detection. The method and system of the invention provides solution with no dependence on Radio component for Muting detection. All calls may be analysed by solution for muting detection rather than only limited sample. The method provides analysis in near real time thus report will be much near to real time as compared to logs-based solution. During handover between radio, complete analysis may not be available at the radio side, however, with proposed solution using 5G core network function nodes, analysis during handover is also possible. The proposed invention may help out to network operator for determining the network performance and planning the deployment network resources based on detecting how often and number of times Call muting happens in the network. The present disclosure provides a system and method for Voice Call Muting detection with core network functions such as UPF, PCF and SMF without depending on radio side components of network. The present disclosure further provides a system and a method for Voice Call Muting detection during handover between radios based on PCF, UPF and SMF based analysis. The present disclosure further provides a system and a method which support Voice Call Muting detection in specific regions, during specific time periods or for specific subscribers based on PCF, UPF and SMF based analysis. The present disclosure further provides a system and a method which uses an analysis platform (such as ATOM) to analyse the call data records and data gathered from PCF, UPF and SMF to detect Voice Call Muting.

[0134] While considerable emphasis has been placed herein on the disclosed embodiments, it will be appreciated that many embodiments can be made and that many changes can be made to the embodiments without departing from the principles of the present disclosure. These and other changes in the embodiments of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

Claims

We Claim:

1. A method for detecting voice call muting in a communication system, the method comprising: establishing, by a processing unit [302], a packet data unit (PDU) session for voice communication between a user equipment (UE) [102] and an IP multimedia subsystem (IMS) [304]; sending, by the IMS [304], an authentication and authorization request (AAR) message to a policy control function (PCF) [122] to add a custom information element (IE) for a realtime transport protocol (RTP) rule; generating, by the PCF [122], a session management policy (SMPolicy) update notification message comprising media-based rules, and transmitting the SMPolicy update notification message to a Session Management Function (SMF) [108]; identifying, by the PCF [122], based on the media-based rules, a voice call for which muting is to be identified; inserting, by the PCF [122], a custom field in the SMPolicy update notification message; creating, by the SMF [108], a packet detection rule (PDR) with the custom field for identifying an RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message; sending, by the SMF [108], a packet forwarding control protocol (PFCP) Session Modification Request to a UPF [106] comprising the PDR for initiating processing of the voice call; detecting, by a user plane function (UPF) [128], a muting event during the voice call based on analysis of RTP SDF; sending, by the UPF [128], a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event; correlating, by the processing unit [302], the set of SDR messages from the UPF [128] with corresponding PDR from the SMF [108] to identify muting events; determining, by the processing unit [302], an occurrence of voice call muting events based on the correlated data; andgenerating, by the processing unit [302], key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

2. The method as claimed in claim 1, wherein further comprises: sending, by the PCF [122], a SMPolicy Update Notify Response message to the IMS [304] following the transmission of the SMPolicy Update Notification to the SMF [108],3. The method as claimed in claim 1, wherein the stream detail record message (SDR) comprises at least one of a timestamp flow creation, a timestamp flow deletion, a session identifier, a user identifier, a type of SDR flow, a direction of muting, and a UPF ID.

4. The method as claimed in claim 1, wherein detecting by the UPF [128], the muting event comprises comparing a difference of a talk-spurt and a silence spurt with a predefined mute threshold time.

5. The method as claimed in claim 1, wherein generating of KPI reports, by the processing unit [302], is based on a predetermined criteria selected from the group consisting of Cell-wise, Call-wise, State-wise, during Handover (HO) or No Handover (NO-HO), and Daily, Weekly, and Monthly intervals, wherein the predefined criteria comprises one of a muting occurrence, a HO Call analysis, and a Downlink Muting KPIs.

6. A system for detecting voice call muting in a communication system, the system comprising: a processing unit [302], configured to establish a packet data unit (PDU) session for voice communication between a user equipment (UE) [102] and an Internet Protocol (IP) multimedia subsystem (IMS) [304]; an IMS [304] connected to at least the processing unit [302], the IMS [304] is configured to send an authentication and authorization request (AAR) message to a policy control function (PCF) [122] to add a custom information element (IE) for a real-time transport protocol (RTP) rule; a PCF [122], configured to:generate a session management policy (SMPolicy) update notification message comprising media-based rules, and transmitting the SMPolicy update notification message to a Session Management Function (SMF) [108]; identify, based on the media-based rules, voice call for which muting is to be identified; and insert a custom field in the SMPolicy update notification message; the SMF [108], configured to: create a packet detection rule (PDR) with the custom field for identifying a RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message; and send a packet forwarding control protocol (PF CP) Session Modification Request to a UPF [128] comprising the PDR for initiating processing of the voice call; a user plane function (UPF) [128], configured to: detect a muting event during the voice call based on analysis of RTP SDF; and send a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event; and the processing [302] unit, configured to: correlate the set of SDR messages from the UPF [128] with corresponding PDR from the SMF [108] to identify muting events; determine an occurrence of voice call muting events based on the correlated data; and generate key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

7. The system as claimed in claim 6, wherein the PCF [122], is configured to send a SMPolicy Update Notify Response message to the IMS [304] following the transmission of the SMPolicy Update Notification to the SMF [108],8. The system as claimed in claim 6, wherein the stream detail record (SDR) message comprises at least one of a timestamp flow creation, a timestamp flow deletion, a session identifier, a user identifier, a type of SDR flow, a direction of muting, and a UPF ID.

9. The system as claimed in claim 6, wherein the UPF [128], to detect the muting event, is configured to compare a difference of a talk-spurt and a silence spurt with a predefined mute threshold time.

10. The system as claimed in claim 6, the processing unit [302] generates KPI reports based on a predetermined criteria selected from the group consisting of Cell-wise, Call-wise, Statewise, during Handover (HO) or No Handover (NO-HO), and Daily, Weekly and Monthly intervals, wherein the predefined criteria comprises one of a muting occurrence, a HO Call analysis, and a Downlink Muting KPIs.

11. A user equipment (UE) for detecting voice call muting comprising: a processor [1004] configured to:- establish a packet data unit (PDU) session for voice communication between the user equipment (UE) [102] and an IP multimedia subsystem (IMS) [304]; and- send, to the IMS [304], an authentication and authorization request (AAR) message to a policy control function (PCF) [122] to add a custom information element (IE) for a realtime transport protocol (RTP) rule, wherein the processor [1004] is configured to facilitate generating key performance indicator (KPI) reports for the voice call muting, wherein the generation of KPI reports is based on:-generating, by a Policy Control Function (PCF) [122], a session management policy (SMPolicy) update notification message comprising media-based rules, and transmitting the SMPolicy update notification message to a Session Management Function (SMF) [108]; identifying, by the PCF [122], based on the media-based rules, a voice call for which muting is to be identified; inserting, by the PCF [122], a custom field in the SMPolicy update notification message; creating, by a Session Management Function (SMF) [108], a packet detection rule (PDR) with the custom field for identifying an RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message;sending, by the SMF [108], a packet forwarding control protocol (PFCP) Session Modification Request to the UPF [106] comprising the PDR for initiating processing of the voice call; detecting, by a user plane function (UPF) [128], a muting event during the voice call based on analysis of RTP SDF; sending, by the UPF [128], a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event; correlating, by a processing unit [302], the set of SDR messages from the UPF [128] with corresponding PDR from the SMF [108] to identify muting events; determining, by the processing unit [302], an occurrence of voice call muting events based on the correlated data; and generating, by the processing unit [302], key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

12. A non-transitory computer-readable storage medium storing instructions for performing real-time analysis of Key Performance Indicators (KPIs) for voice call muting detection in a communication network, the storage medium comprising executable code which, when executed by one or more units of a system, causes: a processing unit [302], configured to establish a packet data unit (PDU) session for voice communication between a user equipment (UE) [102] and an Internet Protocol (IP) multimedia subsystem (IMS) [304]; an IMS [304], configured to send an authentication and authorization request (AAR) message to a policy control function (PCF) [122] to add a custom information element (IE) for a real-time transport protocol (RTP) rule; a PCF [122], configured to: generate a session management policy (SMPolicy) update notification message comprising media-based rules, and transmitting the SMPolicy update notification message to a Session Management Function (SMF) [108], identify, based on the media-based rules, voice call for which muting is to be identified, and insert a custom field in the SMPolicy update notification message,- the SMF [108], configured to:create a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the voice call in response to the SMPolicy Update Notification message, and send a packet forwarding control protocol (PF CP) Session Modification Request to the UPF [128] comprising the PDR for initiating processing of the voice call; a user plane function (UPF) [128], configured to: detect a muting event during the voice call based on analysis of RTP SDF, and send a set of stream record (SDR) messages indicating the occurrence and detection time of the muting event; and - the processing [302] unit, configured to: correlate the set of SDR messages from the UPF [128] with corresponding PDR from the SMF [108] to identify muting events, determine an occurrence of voice call muting events based on the correlated data, and generate key performance indicator (KPI) reports for the voice call muting based on the determined occurrences.

Images