FORM 2
THE PATENTS ACT, 1970 (39 OF 1970) & THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR VOICE CALL MUTING
DETECTION”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

METHOD AND SYSTEM FOR VOICE CALL MUTING DETECTION
TECHNICAL 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 for detection 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 stablishing, 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 (PFCP) 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, the method 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
5 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
10 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.
15 [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
20 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-
25 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)
30 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
5

send a packet forwarding control protocol (PFCP) 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
5 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
10 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
15 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
20 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 media-based rules and transmitting the SMPolicy update notification message to a Session Management
25 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
30 custom field for identifying the RTP session description framework (SDF) for the
voice call in response to the SMPolicy Update Notification message. Also, the
6

generation of the KPI reports is based on sending, by the SMF, a packet forwarding
control protocol (PFCP) Session Modification Request to the UPF [106] 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
5 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 of the KPI reports is based on correlating, by the
processing unit, the set of SDR messages from the UPF with corresponding PDR
10 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. 15
[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
20 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-
25 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
30 muting is to be identified; and insert a custom field in the SMPolicy update
notification message. Further, the instructions include executable code which, when
7

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
5 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
10 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.
15
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. 20
[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
25 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
30 supports for all calls or specific region or subscriber or other conditions based on
PCF, UPF and SMF based analysis for muting detection.
8

DESCRIPTION OF THE DRAWINGS
[0019] The accompanying drawings, which are incorporated herein, and constitute
5 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
10 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.
15
[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
20 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
25 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. 30
9

[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.
5 [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.
10 [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.
15 [0027] The foregoing shall be more apparent from the following more detailed
description of the disclosure.
DETAILED DESCRIPTION
20 [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
25 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
30 intended to limit the scope, applicability, or configuration of the disclosure. Rather,
the ensuing description of the exemplary embodiments will provide those skilled in
10

the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth. 5
[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
10 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
15 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.
20
[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
25 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
30 similar to the term “comprising” as an open transition word—without precluding
any additional or other elements.
11

[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
5 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,
10 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”,
15 “a smart-device”, “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
20 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
25 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
30 medium includes read-only memory (“ROM”), random access memory (“RAM”),
magnetic disk storage media, optical storage media, flash memory devices or other
12

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.
5 [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
10 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,
15 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.
20 [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.
25 [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.
30 [0040] FIG. 1 illustrates an exemplary block diagram representation of 5th
generation core (5GC) network architecture, in accordance with exemplary
13

implementation of the present disclosure. As shown in FIG. 1, the 5GC network
architecture [100] includes a user equipment (UE) [102], a radio access network
(RAN) [104], an access and mobility management function (AMF) [106], a Session
Management Function (SMF) [108], a Service Communication Proxy (SCP) [110],
5 an Authentication Server Function (AUSF) [112], a Network Slice Specific
Authentication and Authorization Function (NSSAAF) [114], a Network Slice
Selection Function (NSSF) [116], a Network Exposure Function (NEF) [118], a
Network Repository Function (NRF) [120], a Policy Control Function (PCF) [122],
a Unified Data Management (UDM) [124], an application function (AF) [126], a
10 User Plane Function (UPF) [128], a data network (DN) [130], 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) [104] is the part of a mobile
15 telecommunications system that connects user equipment (UE) [102] 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.
20 [0042] The Access and Mobility Management Function (AMF) [106] 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.
25 [0043] The Session Management Function (SMF) [108] is a 5G core network
function responsible for managing session-related aspects, such as establishing, modifying, and releasing sessions. It coordinates with the User Plane Function (UPF) for data forwarding and handles IP address allocation and QoS enforcement.
30 [0044] The Service Communication Proxy (SCP) [110] is a network function in the
5G core network that facilitates communication between other network functions
14

by providing a secure and efficient messaging service. It acts as a mediator for service-based interfaces.
[0045] The Authentication Server Function (AUSF) [112] is a network function in
5 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) [114] is a network function that provides authentication and
10 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) [116] is a network
function responsible for selecting the appropriate network slice for a UE based on
15 factors such as subscription, requested services, and network policies.
[0048] The Network Exposure Function (NEF) [118] is a network function that exposes capabilities and services of the 5G network to external applications, enabling integration with third-party services and applications. 20
[0049] The Network Repository Function (NRF) [120] 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.
25 [0050] The Policy Control Function (PCF) [122] 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) [124] is a network function that
30 centralizes the management of subscriber data, including authentication,
authorization, and subscription information.
15

[0052] The Application Function (AF) [126] is a network function that represents external applications interfacing with the 5G core network to access network capabilities and services. 5
[0053] The User Plane Function (UPF) [128] is a network function responsible for handling user data traffic, including packet routing, forwarding, and QoS enforcement.
10 [0054] The Data Network (DN) [130] 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.
15 [0055] FIG. 2 illustrates an exemplary block diagram of a computing device [200]
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 [200] may also implement a method for detecting voice call muting in a communication network utilising the system. In
20 another implementation, the computing device [200] itself implements the method
for detecting voice call muting in a communication network using one or more units configured within the computing device [200], wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
25 [0056] The computing device [200] may include a bus [202] or other
communication mechanism for communicating information, and a hardware
processor [204] coupled with bus [202] for processing information. The hardware
processor [204] may be, for example, a general-purpose microprocessor. The
computing device [200] may also include a main memory [206], such as a random-
30 access memory (RAM), or other dynamic storage device, coupled to the bus [202]
for storing information and instructions to be executed by the processor [204]. The
16

main memory [206] also may be used for storing temporary variables or other
intermediate information during execution of the instructions to be executed by the
processor [204]. Such instructions, when stored in non-transitory storage media
accessible to the processor [204], render the computing device [200] into a special-
5 purpose machine that is customized to perform the operations specified in the
instructions. The computing device [200] further includes a read only memory
(ROM) [208] or other static storage device coupled to the bus [202] for storing static
information and instructions for the processor [204].
10 [0057] A storage device [210], such as a magnetic disk, optical disk, or solid-state
drive is provided and coupled to the bus [202] for storing information and instructions. The computing device [200] may be coupled via the bus [202] to a display [212], such as a cathode ray tube (CRT), Liquid crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for
15 displaying information to a computer user. An input device [214], including
alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus [202] for communicating information and command selections to the processor [204]. Another type of user input device may be a cursor controller [216], such as a mouse, a trackball, or cursor direction keys, for communicating direction
20 information and command selections to the processor [204], and for controlling
cursor movement on the display [212]. 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.
25 [0058] The computing device [200] 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 [200] causes or programs the computing device [200] to be a special-purpose machine. According to one implementation, the techniques herein are performed by the
30 computing device [200] in response to the processor [204] executing one or more
sequences of one or more instructions contained in the main memory [206]. Such
17

instructions may be read into the main memory [206] from another storage medium,
such as the storage device [210]. Execution of the sequences of instructions
contained in the main memory [206] causes the processor [204] to perform the
process steps described herein. In alternative implementations of the present
5 disclosure, hard-wired circuitry may be used in place of or in combination with
software instructions.
[0059] The computing device [200] also may include a communication interface
[218] coupled to the bus [202]. The communication interface [218] provides a two-
10 way data communication coupling to a network link [220] that is connected to a
local network [222]. For example, the communication interface [218] 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 [218] may be a
15 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 [218] sends and receives electrical,
electromagnetic, or optical signals that carry digital data streams representing
various types of information.
20
[0060] The computing device [200] can send messages and receive data, including
program code, through the network(s), the network link [220] and the
communication interface [218]. In the Internet example, a server [230] might
transmit a requested code for an application program through the Internet [228], the
25 ISP [226], the local network [222], the host [224], and the communication interface
[218]. The received code may be executed by the processor [204] as it is received, and/or stored in the storage device [210], or other non-volatile storage for later execution. The computing device [200] may be associated with a system (further explained in FIG. 3). 30
18

[0061] Referring to FIG. 3, an exemplary block diagram of a system [300] 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 [300] comprises at least one processing unit [302], at least one session
5 management function unit [108], at least one User Plane Function unit [128], at
least one IP multimedia subsystem [304], and at least one policy control function [122]. Also, all of the components/ units of the system [300] 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
10 other. Also, in FIG. 3 only a few units are shown, however, the system [300] may
comprise multiple such units or the system [300] may comprise any such numbers of said units, as required to implement the features of the present disclosure. Further, in an implementation, the system [300] may be present in a user device to implement the features of the present disclosure. The system [300] may be a part of
15 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 [300] may reside in a server or a network entity. In yet another implementation, the system [300] may reside partly in the server/ network entity and partly in the user device.
20
[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
25 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
30 of the present disclosure.
19

[0063] The system [300] is configured for detecting voice call muting in a
communication network, with the help of interconnection between the
components/units of the system [300]. The system [300] may be implemented for
voice call muting detection with core network functions including but not limited
5 to the UPF [108], the PCF [122] and the SMF [128] without depending on radio
components of network. The system [300] further may be implemented for voice call muting detection during handover between radio network based on, but not limited to the PCF [122], the UPF [108] and the SMF [128] based analysis. The system [300] may be further implemented to support voice call muting detection in
10 specific regions, at specific time periods or for specific user based on the PCF [122],
the UPF [108] and the SMF [128]. The system [300] may further be implemented on or in conjunction with an analysis platform (for instance-ATOM) to analyse call data records gathered from the PCF [122], the UPF [108] and the SMF 128] to detect Voice Call Muting.
15
[0064] The system [300] includes 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].
20
[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 [102] is in connection with the 5th generation core network. The UE [102] may be associated with the
25 system [300].
[0066] In the ongoing call session, the connection between the user equipment
[102] and an IMS [304] is already ongoing, which may have been initiated before,
the IMS network [304] authenticates the user equipment [102] and establishes the
30 Packet data Unit (PDU) session for the user equipment [102]. The PDU session
refers to a connection between a user and the network for transfer of data packets
20

between them during a session. The processing unit [302] sets up the Packet Data Unit (PDU) session for voice communication between the User Equipment (UE) [102] and the IP Multimedia Subsystem (IMS) [304]. This session is the foundation for the voice call and the data exchange that follows. 5
[0067] The system [300] further includes the 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.
10
[0068] In an implementation of the present disclosure, the IMS [304] sends an Authentication and Authorization Request (AAR) message to the Policy Control Function (PCF) [122]. The AAR message requests the addition of a custom Information Element (IE) specifically designed for a Real-Time Transport Protocol
15 (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.
20 [0069] Further, the system [300] includes the Policy Control Function (PCF) [122]
configured to generate a session management policy (SMPolicy) update notification message. The SMPolicy update notification message comprises media-based rules and the PCF [122] is further configured to transmit the SMPolicy update notification message to a Session Management Function (SMF) [108]. The PCF
25 [122] 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
30 Network. For example, the media-based rules may monitor the packet size and
frequency of data packets. If the PCF [122] detects consistently small packets at
21

regular intervals, the data packets may be identified as a voice call based on the
media-based rules. The PCF [122] further inserts a custom field in the SMPolicy
update notification message. The custom field may be inserted when a user is
provisioned to the 5th generation network. The custom field may not be modified
5 during a call. For instance, when the request for the call is initiated by the user, the
PCF [122] may identify the request and insert the custom field during processing of the request for the call. 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].
10
[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 [122]. The PCF [122] then transmits this message to the Session Management Function (SMF) [108]. The media-based rules are important for
15 managing how the session data is handled and processed, especially concerning
voice data.
[0071] The system [300] further includes the Session Management Function (SMF) [108] that is configured to create a packet detection rule (PDR) with the custom
20 field for identifying the RTP session description framework (SDF) for the voice call
in response to the SMPolicy Update Notification message. The PCF [122] 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 [108] is configured to send a packet forwarding control protocol (PFCP) Session
25 Modification Request to the UPF [128]. 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 [108] to identify the required network traffic. The set of criteria includes but may not be limited to an IP address of the UE [102], a session identifier, and the like. The SMF [108] may identify the
30 required traffic based on the traffic on the IP address of the UE [102].
22

[0072] Furthermore, the system [300] includes a user plane function (UPF) [128]
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
5 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
10 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.
15 [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
20 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 [128] is configured to
25 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 [300] or a user. For instance, the predefined mute threshold time is set by the system [300] 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
30 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
23

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
5 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.
10
[0075] The processing unit [302] is further configured to correlate the set of SDR messages from the UPF [128] with corresponding PDR from the SMF [108] 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
15 muting based on the determined occurrences. The processing unit [302] 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
20 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
25 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
30 be the muting occurrence. The muting occurrence is defined as when the processing
unit [302] identifies the muting event. For instance, the KPIs may be monitored in
24

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. 5
[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
10 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
15 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 pre-determined 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 [302] calculates the
20 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
25 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 [300] to detect the muting event in the voice call initiated by a customer, or the system [300] may automatically be initiated to detect the muting event when a voice call initiation is detected by the system [300].
30
25

[0080] The network's processing unit [302] establishes a Packet Data Unit (PDU)
session between the smartphone (UE) [102] and the operator's IP Multimedia
Subsystem (IMS) [304]. During call setup, the IMS [304] sends the Authentication
and Authorization Request (AAR) message to the Policy Control Function (PCF)
5 [122], 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
10 may allow to send customized information. The PCF [122] may add the custom IE
to a list of existing IEs and allocate a list of specific rules for the IE. The PCF [122] generates a Session Management Policy (SMPolicy) update notification with specific media-based rules and sends it to the Session Management Function (SMF) [108]. The SMF [108], upon receiving the SMPolicy update, creates the Packet
15 Detection Rule (PDR) with a custom field that helps in identifying RTP data
specific to the voice call. As the voice call progresses, the User Plane Function (UPF) [128] continuously monitors the RTP data. It detects a moment where the voice signal is lost for a few seconds – a muting event. The UPF [128] records this muting event and sends a Stream Detail Record (SDR) message indicating the time
20 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
25 [400] is performed by the system [300]. Further, in an implementation, the system
[300] may be present in a server device to implement the features of the present disclosure. Also, as shown in FIG. 4, the method [400] starts at step [402].
[0082] At step [404], the method includes establishing, by a processing unit [302],
30 a packet data unit (PDU) session for voice communication between a user
26

equipment (UE) [102] and an IP multimedia subsystem (IMS) [304]. The UE [102] may be associated with the system [300].
[0083] In an implementation of the present disclosure, when an existing ongoing
5 call is going on between users or it has been established just now, the connection
between the user equipment [102] an IMS [304] is already ongoing, which may
have been initiated before, the IMS network [304] authenticates the user equipment
[102] and establishes the Packet data Unit (PDU) session for the user equipment
[102]. The PDU session refers to a connection between a user and the network for
10 transfer of data packets between them during a session. The processing unit [302]
sets up the Packet Data Unit (PDU) session for voice communication between the User Equipment (UE) [102] and an IP Multimedia Subsystem (IMS) [304]. This session is the foundation for the voice call and the data exchange that follows.
15 [0084] Next at step [406], the method encompasses 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 real-time transport protocol (RTP) rule.
20 [0085] In an implementation of the present disclosure, an Authentication and
Authorization Request (AAR) message is sent by the IMS [304] to the Policy Control Function (PCF) [122]. 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
25 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.
[0086] Further at step [408], the method includes generating, by the PCF [122], a
30 session management policy (SMPolicy) update notification message comprising
media-based rules and transmitting the SMPolicy update notification message to a
27

Session Management Function (SMF) [108]. The method 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].
5 [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 [122]. The PCF [122] then transmits this message to the Session Management Function (SMF) [108]. These rules are important for managing how the session data is handled and processed, especially concerning voice data.
10
[0088] Next at step [410], the method encompasses identifying, by the PCF [122], 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
15 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 [122] 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 [412], the
20 method includes inserting, by the PCF [122], a custom field in the SMPolicy update
notification message.
[0089] Further, at step [414], the method includes creating, by the SMF [108], a
packet detection rule (PDR) with the custom field for identifying the RTP session
25 description framework (SDF) for the voice call in response to the SMPolicy Update
Notification message.
[0090] Next, at step [416], the method encompasses sending, by the SMF [108], a
packet forwarding control protocol (PFCP) Session Modification Request to the
30 UPF [106] comprising the PDR for initiating a voice call processing.
28

[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 [108]
to identify the required network traffic. The set of criteria includes but may not be
5 limited to an IP address of the UE [102], a session identifier, and the like. The SMF
[108] may identify the required traffic based on the traffic on the IP address of the UE [102].
[0092] Further at step [418], the method includes detecting, by a user plane function
10 (UPF) [128], a muting event during the voice call based on analysis of RTP SDF.
The method further comprises 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.
15 [0093] The predefined mute threshold time maybe defined by the system [300] or
maybe by defined by a user. For instance, the predefined mute threshold time is set by the system [300] 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
20 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
25 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. 30
29

[0095] Next at step [420], the method includes sending, by the UPF [128], 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
5 identifier, a type of SDR flow, a direction of muting, and a UPF ID.
[0096] Further, at step [422], the method includes 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. 10
[0097] Next at step [424], the method includes determining, by the processing unit [302], an occurrence of voice call muting events based on the correlated data.
[0098] At step [426] the method includes generating, by the processing unit [302],
15 key performance indicator (KPI) reports for call muting based on the determined
occurrences. The 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
20 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
25 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
30 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,
30

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
5 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
10 cell to reduce interference and improve the overall network performance.
[0100] The method terminates at step [428].
[0101] FIG. 5 is an exemplary illustration of the system and method as explained
15 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 [304] PDU session is pre-
20 established. IMS [304] sends AAR message to PCF [122] to add custom IE for RTP
rule, which includes RTP and RTCP Meta sub-components AVP. The PCF [122]
sends SMPolicy_UpdateNotify Media Based Rules message to SMF [108]. In
response to this message, the SMF [108] sends SMPolicy_UpdateNotify Response
message to the PCF [122]. Further, the PCF [122] sends AAA message to the IMS
25 [304]. Next, the SMF [108] sends the PFCP Session Modification Request PDR,
QER and FAR (Custom IE to be added) message to the UPF [128] and the PDR
Event for call starts at the SMF [108]. The UPF [128] sends the PFCP Session
Modification Response message to the SMF [108] and voice call processes between
the UE [102] and the IMS [304] via the UPF [128]. Next, the UPF [128] detects the
30 muting event for sending in the SDR. The IMS [304] sends the STR (termination
of call) message to the PCF [122]. Further, SMPolicy based message and response
31

message exchange between the PCF [122] and the SMF [108]. The PCF [122] sends
STA message to the IMS [304]. The SMF [108] sends PFCP Session Modification
Request PDR, QER and FAR to be removed message to the UPF [128]. The UPF
[128] sends SDR message to an ATOM [514] for Muting Events and PFCP Session
5 Modification Response to the SMF [108]. The Analytics, Troubleshooting, and
Optimization Management (ATOM) system [514] is connected to the UPF [128],
the SMF [108] and the IMS [304] through a Northbound Interface (NBI)
integration. The NBI integration refers to an output-based interface, i.e., the ATOM
[514] is configured to send the generated KPI’s to the UPF [128], the SMF [108]
10 and the IMS [304].
[0103] In preferred embodiments, the ATOM [514] analyses SDRs from the UPF [128], PDRs from the SMF [108] and CDRs from CTAS. For an example, in case of the UPF [106] SDR, where direction of muting is uplink as follows: IMS
15 [304]/SUPI is received from the UPF [128] should be matched with the SMF [108]
records. The Session-ID from the UPF [128] should be matched with the Session-ID from the SMF [108] for corresponding SUPI. The ATOM [514] 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
20 UPF [128] and the SMF [108]. The ATOM [514] records the UE [102] location
field denoting Cell ID, when muting is detected.
[0104] In a preferred embodiment, the ATOM [514] calculates muting occurrence, based on number of muting events per Cell ID for all the calls. It may also be
25 calculated based on per call per Cell ID. ATOM [514] 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 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
30 Handover and the No- Handover KPI report generation includes monitoring KPI in
specific circumstances during the handover sessions or during the sessions when no
32

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
5 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.
10 [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
15 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.
20 6, an exemplary method flow diagram [600] for detecting voice call muting in a
communication network for a pre-established PDU session. In an implementation the method [600] is performed by the system [500]. Further, in an implementation, the system [500] may be present in a server device to implement the features of the present disclosure.
25
[0107] When a user equipment [102] initiates a connection with the IMS [304], the IMS network [304] authenticates the user equipment [102] and establishes a Packet data Unit (PDU) session for the user equipment [102]. A PDU session refers to a connection between a user and the network for transfer of data packets between
30 them during a session. The processing unit [302] sets up the Packet Data Unit
(PDU) session for voice communication between User Equipment (UE) and an IP
33

Multimedia Subsystem (IMS). This session is the foundation for the voice call and the data exchange that follows.
[0108] At step 1, the IMS [304] sends an Authentication and Authorization Request
5 (AAR) message to a Policy Control Function (PCF) [122]. 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.
10 [0109] At step 2, the PCF [122] creates a Session Management Policy (SMPolicy)
update notification message containing media-based rules. The PCF [122] further transmits this message to the Session Management Function (SMF) [108]. These rules are important for managing how the session data is handled and processed, especially concerning voice data.
15
[0110] At step 3, the SMF [108] creates an SMPolicy update Notification response and sends the response to the PCF [122]. The response comprises a confirmation of the updating of rules in the SMF [108] for handling and processing of data.
20 [0111] At step 4, the PCF [122] sends a response to the IMS [304] on a successful
addition of the custom IE.
[0112] At step 5, in response to receiving the SMPolicy Update Notification response, the SMF [108] generates a Packet Detection Rule (PDR) equipped with a
25 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 [108] to identify
30 the required network traffic. The set of criteria includes but may not be limited to
34

an IP address of the UE [102], a session identifier, and the like. The SMF [108] may identify the required traffic based on the traffic on the IP address of the UE [102].
[0113] The User Plane Function (UPF) [128] monitors the voice call and detects
5 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 [122] sends out a set of
10 Session termination request to the IMS [304]. An Analytics, Troubleshooting, and
Optimization Management (ATOM) system [514] is connected to the UPF [128],
the SMF [108] and the IMS [304] through a Northbound Interface (NBI)
integration. The NBI integration refers to an output-based interface, i.e., the ATOM
[514] is configured to send the generated KPI’s to the UPF [128], the SMF [108]
15 and the IMS [304]. The Analytics, Troubleshooting, and Optimization Management
(ATOM) [514] 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
20 example, the media-based rules may be to monitor the packet size and frequency of
data packets. If the PCF [122] detects consistently small packets at regular intervals,
the data packets may be identified as a voice call.
[0115] At step 8, the PCF [122] sends a SMPolicy update notify media-based rules
25 to the SMF [108] to update the rules in the SMF [108].
[0116] At step 9, the SMF [108] further sends a response comprising an SMPolicy update notify response to the PCF [122] back.
30 [0117] At step 10, the PCF [122] sends back a session termination accept response
to the IMS [304].
35

[0118] At step 11, the PFCP session modification request for removal of PDR is sent to the UPF [128] form the SMF [108], wherein at step 12, the UPF [128] sends back a response for the modification request to the SMF [108]. 5
[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
10 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
15 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,
20 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
25 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
30 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
36

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
5 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
10 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
15 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
20 (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
25 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
30 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
37

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
5 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.
10 [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.
15 [0124] When an existing ongoing call is going on between users, the connection
between the user equipment [102] an IMS [304] is already ongoing. The connection may have been initiated before, but the detection is performed in the middle of the call. The IMS network [304] authenticates the user equipment [102] and establishes a Packet data Unit (PDU) session for the user equipment [102]. A PDU session
20 refers to a connection between a user and the network for transfer of data packets
between them during a session. The processing unit [302] sets up the Packet Data Unit (PDU) session for voice communication between User Equipment (UE) [102] and an IP Multimedia Subsystem (IMS) [304]. This session is the foundation for the voice call and the data exchange that follows.
25
[0125] At step 1, the IMS [304] sends an Authentication and Authorization Request (AAR) message to a Policy Control Function (PCF) [122]. 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
30 managing the data packets related to the voice call.
38

[0126] At step 2, the PCF [122] creates a Session Management Policy (SMPolicy)
update notification message containing media-based rules. The PCF [122] then
transmits this message to the Session Management Function (SMF) [108]. These
rules are important for managing how the session data is handled and processed,
5 especially concerning voice data.
[0127] At step 3, the SMF [108] creates an SMPolicy update Notification response and sends the response to the PCF [122]. The response comprises a confirmation of the updating of rules in the SMF [108] for handling and processing of data. 10
[0128] At step 4, the PCF [122] sends a response to the IMS [304] on a successful addition of the custom IE.
[0129] At step 5, in response to receiving the SMPolicy Update Notification
15 response, the SMF [108] 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.
20 [0130] The User Plane Function (UPF) [128] 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.
25 [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 [302], a packet data unit (PDU) session for voice communication between a user equipment (UE) [102] and an IP multimedia subsystem (IMS) [304]. The processor [1004] is configured to facilitate
30 generating key performance indicator (KPI) reports for the voice call muting. The
generation of KPI reports is based on sending, by the IMS [304], an authentication
39

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. Further, generation of KPI reports is based on generating, by the PCF [122], a
session management policy (SMPolicy) update notification message comprising
5 media-based rules and transmitting the SMPolicy update notification message to a
Session Management Function (SMF) [108] and identifying, by the PCF [122], 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 [122], a custom field in the SMPolicy update notification message and creating, by the SMF [108],
10 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 [108], a packet forwarding control protocol (PFCP) Session Modification Request to the UPF [128] comprising the PDR for initiating processing of the voice
15 call and detecting, by a user plane function (UPF) [128], 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 [128], a set of stream detail record (SDR) messages indicating the occurrence and detection time of the muting event and correlating, by the processing unit [302], the set of SDR messages from the UPF [128] with
20 corresponding PDR from the SMF [108] to identify muting events. In addition, the
generation of the KPI reports is based on determining, by the processing unit [302], 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 [302], key performance indicator (KPI) reports for the voice call muting based on
25 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
30 executed by one or more units of a system, causes: a processing unit [302] of the
system [300] to establish a packet data unit (PDU) session for voice communication
40

between a user equipment (UE) [102] and an IP multimedia subsystem (IMS) [304].
Further, the instructions include executable code which, when executed causes an
IMS [304] of the system [300] to send an authentication and authorization request
(AAR) message to a policy control function (PCF) [122] to add a custom
5 information element (IE) for a real-time transport protocol (RTP) rule. Further, the
instructions include executable code which, when executed causes a PCF [122] 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) [108];
10 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 [108] of the system [300] to: create a packet detection rule (PDR) with the custom field for identifying the RTP session description framework (SDF) for the
15 voice call in response to the SMPolicy Update Notification message and send a
packet forwarding control protocol (PFCP) Session Modification Request to the UPF [128] comprising the PDR for initiating the voice call processing. Further, the instructions include executable code which, when executed cause a UPF [128] of the system [300] to detect a muting event during the voice call based on analysis of
20 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 [302] of the system [300] to: correlate the set of SDR messages from the UPF [128] with corresponding PDR from the SMF [108] to identify muting events; determine an
25 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
30 advanced solution of Voice Call muting Detection. The method and system of the
invention provides solution with no dependence on Radio component for Muting
41

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.

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 real-time 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; and
generating, 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 (PFCP) 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, 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.
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 real-time 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.